For some contract work, I am helping my former employer to connect their industrial control application to an OPC server, to read and write some array items. OPC is a de-facto standard for industrial data exchange, and for 99% of current installations, runs on top of Microsoft’s DCOM. (1, having anything to do with DCOM gets you a point) The application framework for some reason doesn’t support arrays… but enumerating things I don’t like about that framework will take all day.
The OPC server will sit there and accept DCOM connections of some kind, send back connections of some kind… and hopefully everything will work. If something goes wrong in this actually quite complicated process (likely), it doesn’t work. (very likely) And because of the mechanism by which it’s accessed, it’s damned hard to figure out why it doesn’t work. (2)
After trying several OPC client utilities and libraries, each of which fails to connect and read the values for some convoluted inscrutable reason, the Softing toolbox .NET library actually seems workable! (The process of separating the wheat from the chaff in the documentation and “example” code took a long while, but I can’t blame Microsoft for everything)
So, this code implements a simple array read/write command-line client. Tell it server name and item for reads, pass an additional value for writes. (Using hex strings so the industrial control application can easily parse/generate/pass them) Tested it against a few different items and values, no problem!
Using shellexec from within the application to call the utility (with the same parameters as before), and it connects to the server, reads the item, and fails with a item_not_connected error!
Something about the difference in environments between running from a command-line and running from inside the application is causing what appears to be a server problem. (3)
After some further investigation, the application is found to be running commands as a different user, nt authority/system . Is that why it fails? No idea. Windows won’t let me
runas the command as that user without the password, so I can’t test that aspect. (4)
The saga continues…