(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
