datasocket write speed to OPCservers

[Another Steve]

Hi all,

I'm using labview for communicating with a Micrologix 1500 PLC (over DF1) using NI OPCservers. I find that using the datasocket write VI (with a wired connection id from the datasocket open vi) that it can only put through about 30 writes per second. Multiple parallel calls to datasocket write are still restricted to the same rate. This is not a limitation in the VI itself as writing to the labview demo opc server will run through 10^5 or so per second on my system. I appreciate that the serial speed limits comms from the OPC server to the PLC, but between Labview and the OPC server there should be no such limitation. If it is doing its job well shouldn't it just queue up the writes as fast as they arrive and ideally then only write the most recent value - or is this a setting in the OPCserver that I can change??? Overall I don't have too many writes to do and can fit well within the serial ports capabilities, but I would like to write them in bursts to the server and have them written to the PLC from there - and not have labview locked up in the meantime. It appears perhaps as though the server is waiting for acknowledgement from the PLC before allowing the datasocket write to complete, which I dont see as necessary. 30 write per second is well below even the limitations of the serial port speed.


Another sympton perhaps of the same thing is the reads and writes timing out if the OPC to PLC connection is broken. Can't the OPCserver still keep accepting writes from datasocket?

If I've overlooked some setup option, or if there is some other quirk that can improve this I would be very pleased to hear it. Other software packages are not an option at this stage of the development.

[Eli_S]

Hello,

The reason why when using the Demo OPC Server you can write data much master that you can with real hardware, is because the Demo server is just a simulation and the data is actually only being written/read to and from RAM which can operate much much faster than hardware. Additionallly, when talking to actual hardware there are a lot of commands that are handled by the driver under the hood, which take a lot of time. Actual data transfer latencies through the serial port also play a role in this delay.

[Another Steve]

Hi,

Thanks for the comment, but I think this was the whole point I was trying to make - the datasocket to OPCserver connection IS a software connection, and shouldn't have any dependence on hardware. It is the OPSserver that is doing the hardware connection with all the lags and comms overheads and speed limitations that you mention. My problem is that my Labview program locks up waiting for the datasocket write VI to return. I would like the OPCserver to accept all my writes rapidly and then do the job of dishing this up to the PLC in its own time.

It has now occured to me know that I can write my own wrapper for the the write vi by writing to my own write buffer, then running a separate parralel loop to feed these through to the OPCserver. This is what an OPCserver is though isn't it???? A buffer for reading and writing from other systems???. If I had time to write this properly (checking for redundancy from overwrites to the same address etc) then I could then just knock up some DF1 drivers pretty quickly, and wouldn't need an OPCserver at all. 🙂

Does any one have experience with datasocket and RSlinx in relation to the above issues?

Cheers,

[Eli_S]

Hi,

Eventhough OPC server connection is a software connection, if you are addressing a tag bound to a PLC, the drivers will wait for the communication to reach the final target. (LabVIEW all the way to the PLC). Being this the case, you not only have a software connection but you also have the connection between the OPC server and the PLC which has its own delays. What you are trying to do is to modify the way the communication is handled by allowing the OPC server to act as a buffer and have it handle the delays without holding up LabVIEW. This cannot be done because that would mean changing the way the drivers work.

I think your suggestion of using a queue and a producer-consumer architecture would do what you are trying to do and its pretty quick and easy to implement.

[Another Steve]

Hi,

Yes, that confirms my suspicions as to how it was working - waiting for confirmation of the write before returning.

My hope was that the server or the vi had an option not to wait for confirmation. Even better would be for the write vi to handle multiple simultaneous calls - why cant it be waiting for confirmation on a dozen different writes at the same time? Aside from limitation over and above the serial comms speed, a programming problem arises if one of the tags does time out. The whole write system gets tied up.

What would happen if I copied the write vi to write2.vi and called this in parralel to a call to write.vi? would it do two writes at once?

Interestingly, I have reported in another post that the open datasocket vi *doesn't* appear to wait for confirmation of the connection before returning, meaning that initial reads from the connection return incorrect results (quality 0) for the first 100ms or so. The open vi should be waiting for confirmation in my opinion, and the write vi optionally. Its back to front.....

Cheers,

Steve

[Eli_S]

Hi Steve,

Your suggestion of having duplicate write VI's is interesting but I am not sure if it would work or not. One problem I do see with that is that if you have dependencies in the data you are writing, there is potential for trouble because of race conditions.

[Another Steve]

I've finally had a check through the help documentation and there really is something going wrong. The datasocket write vi has a timeout value wired which can be set to (and defaults to) '0' which is supposed to be a setting which *does not* wait for the result of the write before returning. There is either a coding error so it is not doing what it should, or the server has some glitch in it which makes it really slow. Would love to know if any one else has this problem with other comms protocols.

[erls]

I'm having the exact same problem.  LabVIEW 7.1 / RSLinx OPC Server / Windows Server 2003

The write.vi freezes up the application untill it gets a confirmation of the write. 

I'm trying to use the Timeout feature on the write.vi but as you mentioned, there must be a coding error since that feature doesn't properly.  As i see it, if the confirmation is not received within XX amount of time, then it should time out and come out of that state.  Unfortunately, it does not.

I just started a new post regarding a Blocking Datasocket Write so i don't have any solution for this at this time.

If you have found a work around i certainly would like to hear about it.

Thanks.

[Another Steve]

i,

Interesting to hear that you have similar problems with RSlinx and an earlier labview version. It appears the problem is with the datasocket write code then.

According to the documentation for datasocket write, wiring '0' to the timeout (or not wiring it as this is the default) should mean the vi automatically returns without waiting for any confirmation. This should run really fast, but doesn't get any faster than about 30 writes/s on my system. Something is locking up the vi that it isn't escaping from.

Hopefully they will fix it. I'll keep an eye on your other thread.

S

[erls]

here is the topic i started a couple days ago:

http://forums.ni.com/ni/board/message?board.id=170&thread.id=359864