OPC + Datasocket slowdown

[Sirin]

I've been fighting issues with using OPC with the DataSocket VIs for some time. I have managed to get it working to the point where my software no longer crashes, but I still occasionally have issues where the CPU usage skyrockets slowing down my entire process. I've done all of the normal checking for while loops without timers in them, and have not found anything.

I know that the issue is with the OPC communication, as I have the exact same software running elsewhere using RS-232 instead and it never has any problems with CPU usage. I'm just wondering if anyone knows if there are situations where Datasocket will take all of the system's CPU?

My system is a Pentium 3 running Win 2k and LabVIEW 6.1. I should also note that this code I'm running has been compiled into an executable, and uses the old DataSocket compatibility VIs. (I.e. DataSocket Open/DataSocket Read etc etc).

Unfortunately I can't post my source code, or a smaller snippet of source code that reproduces the problem as I have never been able to make my software act up here in my office. (The problem is occuring at a customer site.)

[Andy F.]

Sirin,

So the same OPC and DataSocket code running at the customer site is running a lot slower than the code at your office, is that correct?  I know that network connection problems can slow down DataSocket connections.  You might try to setup a front panel DataSocket connection across the network and use the small connection light to judge if this could be the problem or not.  Is there anything else that is different between the two setups?  Are you using more tags at the customer site?  This could also cause slow program execution. 

I hope this information helps!  Done hesitate to post more if you have more information or questions!

Andy F.

[Sirin]

I guess what I am saying is that the speed is about the same either place; it is just sometimes at the customer site the program will just come to a halt or lose connection or refuse to connect for no particular reason.

We're connecting to about 20-30 tags (about 1/3 write-only and 2/3 read only). The program used to crash all the time because for some reason the datasocket routines could not find the OPC server on the network. The customer has proof that his server was not down during these periods of time. I fixed up the issue by pinging the server before I would perform any datasocket writes, and that stopped the program from crashing. However, I still have problems connecting to the servers sometimes.

The main problem with front panel datasocket is that if it has any problems, it is going to take down my entire program, and unfortunately my program is a mission critical one for the customer. I know that 90% of the time everything works alright, but every once and a while everything aligns correctly to cause my software problems, which causes the customer to call me and complain.

The latest behavior I have seen is that for seemingly no reason, my program slows down to a crawl as if there were a while loop active with no timer in it (i.e. 100% cpu usage). If the OPC connection is restarted (something I have a function for in my software) everything goes back to normal. The problem is that the front panel is so unresponsive when the CPU is loaded down like that the techs that work on my system claim it is "locked up" and just reboot it.

[otoro]

Is putting a wait 1ms multiple or even 0ms multiple inside the while loop help fix the cpu usage ? I think putting a wait multiple cause the control to be released from the tight loop to the Windows OS.

Another thing is that if you use fp control datasocket, have you tried making it have synchronous display. I think this is an option on the control, i know it exist in 7.0.

Or if you really have to use OPC, then use the DSC module. I know the module can handle more connections than datasocket.

[Sirin]

Unfortunately, we can't afford to use DSC as the customer will not pay for the extra expense. I've made sure that all of my while loops in the program have timers in them. I don't use any front panel connections; they're all using the old style Datasocket VIs.

[Andy F.]

The DataSocket VIs should have timeout settings on them.  Have you tried to use these?  One of the outputs is a boolean that indicates if the connection has timed out.  You could use this boolean to run the software for resetting the server, that you mentioned that you had.  This might require a little bit of tinkering with the timeout settings, but if this is causing the issue, then it could be a good solution for you.

Andy F.

[Sirin]

There is no timeout setting on the datasocket write VI. I think you're thinking of the normal datasocket VIs, which I was told by NI tech support not to use with OPC; but to instead use the compatability VIs that are used in the examples. In either case, the "normal" datasocket write VI still causes problems if the server is even the slightest bit not there regardless of the timeout that I set.

[Andy F.]

As yes the compatibility VIs...  It does sound like a network connectivity issue to me.  One thing to test would be to try connecting the OPC server directly to the computer that is running the LabVIEW program using a cross-over cable.  This I understand may not be possible, so another method would be to test the network connection in general.  There are programs that can sniff network traffic to see if packets are being sent/received/dropped, but this may not be ideal either.  One quick way would be to create a very simple LabVIEW program that basically only consistes of a Datasocket front panel connection.   You can monitor the status of the light to test connectivity.

Hope this is helpful!
Andy F.

[Sirin]

Unfortunately, even if I do that; the customer is still going to insist that there are no connectivity problems as he has used his third party product (Linkmaster from Kepware) on that same PC and has seen no issues. I'm also fairly convinced that if I was using the DSC (which is very much expensive overkill) I wouldn't be having any problems either.

I guess I'm just disappointed in the instability that I've seen out of these Datasocket VIs, as they don't really seem up to snuff with everything else I've seen in LabVIEW in terms of reliability. Even if I prove that there are connectivity type issues, the customer will insist that his other stuff works with the OPC server, so why doesn't mine.

The only thing I can think of to do at this point is to enter the servers into the windows hosts file to try to remove some of the network overhead. Do you think that may help things?

[Andy F.]

Another thing you may try would be to update the DataSocket server.  All necessary components are installed with the LabVIEW run-time engine, so it would be a simple matter to do this.  Here is a KB that outlines this:

How Can I Download and Install the Latest Version of DataSocket and DataSocket Server?

The run-time engines for multiple versions of LabVIEW can peacefully coexist, so it will not change any LabVIEW 6.1 functionality.  I hope this helps clear up this communication issue.  Please let me know either way.

Andy F.