OPC Software Trigger for DATA Control

It wasn't clear for me what means "hardwired digital inputs"? Seems it some divices on-board or modular getting connected (wired) to be controlled. In any case you should have OPC drivers for its to be registered in OPC server. Have you succeed this step? Then you'd create a tags and have intentions to make your controll and connections by means of OPC techology. tag-to-tag. Yes?

There are a lot of reasons why your system does not work. It may be a problem with COM/DCOM. Can you temporary reject iFix OPC-client and use alternative (maybe handwritten on VBA)? Do you have another OPC server? What means yours "for some reason even though the link is on-line and active, we cannot get the tag status to be recognized by the server". That is you have not properly registered devices and threfore tags at your system.

Do not rush refuse off your old "hardwired" devices and try to communicate with software supplier.

Good luck.

You are right, it is probably a DCOM issue. Matrikon makes some products to resolve these types of issues.

Thanks for the input! We will take a look at DCOM.

Greetings!

Thank you so much for the input!

We are currrently running off the hardwired inputs and will not change over to OPC until we get the issues solved. The correct OPC drivers are resident in both the server and the client machines. The hardwired inputs are connected via an OEM PCB mounted in the server. The tags have been created and are visible but they will not update the value.

This a long shot, but if you have created OPC tags, there is a good chance you will have to restart the service before the tags will be available. Restarting the OPC server should accomplish the same thing. Also, I have been able to get "shy" OPC tags working by using 3rd party OPC software (Like OPC Inspector by Factory Soft) to look at the data. Just the act of looking at the data can get it going.

I had have some like troubleshooting experience in my practice 3 years ago. Just OPC client didn't show me real status of relay element that changed it's state from ON to OFF and vise versa. There had been found some decisions to fix it, but all of them were rather like more witchcraft than engineering as most of SCADA technology are not acceptable for me as end user. So I can't recommend its directly. Plus set of recipes what I found for my case didn't work the same way applied to different cases. One time I could resolve a problem downwarding OS to WinNT4/95. Another time I got local access (COM) when both client and server were located on the same PC (it was temporary for studying a problem). Third case having taken in account that relay element has an inertia for switch so I sent there "awaking" series of commands ON/OFF after that "cured" server began to observe state of tag for some time. Fourth case I've used written VBA client-code. I do agree that third part OPC can invoke a problems though according to an idea of SCADA technology it shouldn't be so. Be truth I shun now to recommend and use SCADA unless having non-restricted time for lab testing before its installing.

Hello all!

Thank you all so much for the great input!

Problem was in the DCOM resident in the server due to a configuration mistake made by the vendor during installation. (Missed selections)

Once we were able to get the server to recognize and display the tree items, it was then a simple matter of setting up a paired set of DI & DO tags in the client to transfer the status from the HMI and PLC.

Thanks again and have an awesome weekend!