10-06-2008 12:56 PM
Hello,
I am new to NI forums and in desperate need of help or explanations.
I'm having issues with the Datasocket Write module (LabVIEW 7.1) where it becomes blocking. This is causing us serious problems since we're dealing with a real-time control system. I have wired a 1ms timeout value on the Datasocket Write vi and it doesn't seem to have any effect and sometimes, the operation is still blocking, and not only blocking that specific thread but a the whole application.
The application is a gateway between PLCs from Allan-Bradley and NI Real-Time controllers. The gateway resides on a server which has RS Linx OPC Server running as well. The gateway opens connections to about 800 PLC tags and provides direct datasocket Read and Write VI Server references to the client program residing on the R-T controller. There is no local data on the gateway.
The whole set of tags (800) is being polled by the client every 100ms. Once in a while, the client needs to write to certain tags, and in about 99% of those cases, it goes as planned. However, 1% of those cases cause problems, where the entire gateway is blocked by that specific operation, sometimes up to 10 secs. During those 10 secs, we're missing changes in the data which is causing serious problems on operations. It seems to me that he timeout feature on the datasocket write vi is not working properly. If it was, this shouldn't be blocking and we would simply timeout on the Write and would still be able to Read without missing any events. We're almo monitoring the load on the ControlNet cards and everything checks as normal.
Do you have any information regarding Datasocket Write vi timeout or becoming blocking?
Upgrading to LabVIEW 8.1 is not an option at this time.
Regards,
erls
10-07-2008 08:43 PM
Hi erls,
Thanks for sharing your issue with the community. I'd be happy to look into this and hopefully others can provide input from their experiences. I did find a basic article about Datasockets, although I don't believe it answers your question. Here it is for any curious readers: <http://zone.ni.com/devzone/cda/tut/p/id/3224>.
First of all, are you programmatically reading each tag? 800 tags is a lot to be read every 10th of a second. Would it be possible to increase the iteration time? What performance do you absolutely need? Can you elaborate a little bit more on the structure of your program and the way data is flowing from PLC's to the Real-Time controllers?
Second of all, the timeout feature will only activate if the Datasocket Read VI receives no data within the allotted time. It is likely that your VI is receiving data but it's just taking time for that task to complete.
Please share more information with us at your convenience.
Dan Richards
10-08-2008 09:39 AM
(sorry, very long post)
Hello Dan,
The article you suggest does not really answer the question i am asking. Also, in your reply, you talk about the Datasocket Read.vi and its timeout, but that API does work properly. When i read a tag, i don't wait for the data to be updated, i just poll its last value.
What i'm having problems with is the Datasocket Write.vi and its timeout. It was also brought up in a previous topic:
http://forums.ni.com/ni/board/message?board.id=170&message.id=321970&jump=true
Here is a detailed explanation of our real-time control system:
There are 3 major components:
| PLCs | <-----> | RS Linx OPC Server / Gateway (LabVIEW 7.1) | <-----> | PXI-8196 RT Controller |
The RT is the client and polls data from the PLC through the Gateway and OPC Server residing on a seperate server. The RT communicates with the Gateway through VI Server. The Gateway communicates with the OPC Server through Datasockets.
The Gateway runs a thread that opens and maintain the whole set of Datasocket connections to the OPC Server. The Gateway also provides VI References for the client RT and one of those references is a VI that reads all data sockets and outputs a cluster of data (PLC tag values) so the RT can copy that data locally. In other words, the RT has a main polling thread that reads all tags at once every 100ms (ideally). Changes in the data can occur at intervals as small as 200-300ms so that polling rate is needed for this monitoring. However, sometimes, the RT needs to write to PLC tags.
For writing, the RT calls a different VI reference, from a different thread, and the only purpose of that vi is to write to a PLC tag. In other words, when you call that VI by reference, it simply takes the input value you give it and performs a Datasocket Write on the specified tag. While we're writing to a tag, the RT is still polling the status tags. The RT does not write to PLC tags as often as it reads from them.
The Gateway does not have a local data set. Its purpose is to open datasocket connections and maintain them as well as to provide the RT a few VI references for Reading and Writing to PLC tags. In other words, it opens communication channels so the RT can poll the PLC tags.
Our problem is the Timeout feature on the Datasocket Write.vi. It doesn't seem to work. When a value is written to a PLC tag, DS Write api waits for a confirmation from the PLC. 99.9% of the time, that confirmation is received almost right away and the function comes out of its waiting state. However, 0.1% of the time, a delay is introduced in the confirmation coming from the PLC.
In theory, when this delay occurs, the DS Write should timeout (value of 1ms) before getting the confirmation. This is what makes me thing the Timeout feature of the DS Write is not working, because it does not timeout before getting the confirmation and while it is still waiting for it, it blocks the whole Gateway. The consequence of this is that VI reference calls for reading the status tags are also affected, causing us to lose precious data.
We're dealing with 2 problems here. One being the DS Write timeout not working properly and the other being the delay in getting the confirmation from the PLC.
I understand that without that delay, the timeout on DS Write is not necessary. However, having the 2 elements combined has a great impact on our system.
Yesterday, i was in contact with an real time system engineer at NI and he confirmed to me that this timeout issue with DS Write was reported back in 2005 and closed in 2007, which in my opinion corresponds to the release of LabVIEW 8.5. There was no follow up on that issue before it was closed so i'm having that engineer looking into getting more information from the R&D team that worked/closed that problem.
He also suggested a work around for this timeout problem but from what i understand it won't fix the problem but it will only lower the probabilities of trying to write to a PLC tag and catching that delay. Here is his solution:
whenever you are about to write to a PLC tag, do this:
OpenDatasocket (timeout value) ---> Write Datasocket ---> Close Datasocket.
He suggested using the timeout feature of the Datasocket Open vi since that one is known to be working properly. However, like i said previously, there is no garantee that the DS Write will not catch that delay in getting the confirmation anyways. On top of that, you can see how this logic is not performance friendly in the case you need to write multiple times within a very small and time-critical timeframe.
Do you have any other information or suggestions regarding this issue of DS Write timeout? We're also bringing Rockwell Softwares (RS Linx) into this cause the root cause of our problem seems to be the delay in receiving the confirmation.
Thanks,
erls
10-08-2008 10:04 AM
Hi there
just a blind guess: are you using datasocket connection IDs or the URL for Datasocket Write function? See attachment...
10-08-2008 10:10 AM
I open all connections and store IDs (refnums) in a global array.
I just select the right one and input it to DS Write whenever it is called.
10-08-2008 10:13 AM
Oh, OK!
10-08-2008 02:33 PM
Hi erls,
For the sake of sharing the solution with the community, I want to repost here what you have heard or will hear from Mark Sapp, the support person with whom you were speaking. It looks like a corrective action request has been filed to have our engineers see about fixing this issue in future issues. An option to work around this issue would be to upgrade to a later version of LabVIEW to take advantage of the use of shared variables.
Regards,
Dan Richards
10-08-2008 02:46 PM
Yes, i understand that upgrading to a more recent version of LabVIEW would be our best option.
Unfortunately, this project started back in 2003 and includes multiple systems deployed for production throughout Canada and the U.S.
At this time, upgrading to LabVIEW 8.5 is not an option.
10-09-2008 03:12 AM
Hi there
another approach to access datasocket would be the usage of the COM object. see this post:
http://forums.ni.com/ni/board/message?board.id=170&message.id=356874#M356874
I don't know, but maybe you can find a solution then.
10-19-2008 03:04 PM
Hi,
I came across a nice OPC client wrapper from graybox (http://gray-box.net/daawrapper.php) trying to work around the datasocket problems you mention. If you are familiar with calling DLL's from labview it should only take an hour or two to make drop in replacements for the datasocket vi's.
It works well with Kepware, so I'm guessing RSLinx should have no problems. Unfortunately for me I have discovered that NI OPC servers (which is the one I have a licence for) only accepts connections from Labview and not from any other client, including from labview through third party drivers so this is an issue I am still working on...
Cheers,
Steve