Shared variable engine OPC delay

[kallen_H]

Hello All,

I've got a bit of a problem with the delay time of updates between a non NI OPC server and a shared variable engine OPC client. I am using the redion OPC software OPCWorx with a database of around 120 tags to monitor and log data from a small pilot plant. The OPCWorx server has been configured with a 500ms update rate and the NI OPC client as the same. So here is my problem; logged updates occur no faster that 2.5s which is fine as we are exporting in 3 sec intervals (would still like to increase the performance of this to around 1 sec) but the main nuisance is the delay in changing control registers in the PLCs. The controls and indicators are directly bound to the shared variable items where by a change in a boolean control on the front panel to the indicated response can range from 5 to sometimes 15 seconds delay. If I bind the same control and indicator directly to the OPC item through the data socket the delay in response is almost unnoticeable at around 1 sec. I have increased the update/logging dead bands of the shared variables which seemed to help but only by a second or so.

Im wondering what the limitations of using an OPC shared variable engine is and if this is expected or have I gone wrong somewhere. All the variables are configured as non buffered and to have single writers.

A few changes have been suggested;

- Upgrading the PC. The current hardware is AMD Phenom 2 3.21GHz processor, 4GB of ram running windows XP.

- Using Modbus over ethernet instead of OPC.

This is the first major use of the DSC module and using the shared variable engine as an OPC client so any information or insight to help with this would be much appreciated. 

[Aix-La-Chapelle]

Hi kallen_H,

Is there anything else changed in the code aside from datasockets versus the shared variables?  What kind of delay do you see in Distributed System Manager?  I have a white paper article that goes into shared variables some, and can help with benchmarking them:

http://www.ni.com/white-paper/4679/en

Let me know if this helps!

[kallen_H]

Hello Aix,

Thank you for the reply.

No I have not changed any other code apart from changing the data binding of one front panel control and one front panel indicator to the DSPT server OPC items. The same delay experienced in the logging exists when viewed in the distributed systems manager. It is only when a user change in a shared variable the 5 - 15 second response is present.

What I have done is created a new project and OPC shared variable library with only 4 of the tags out of the 120 odd to control and monitor a tank level. Using the same settings as the 120 variable library for the 4 tags this is able to log at the set 500ms intervals and there is no difference between the shared variable binding and the data socket binding with a delay of less than 1 sec between the change in control and response. Would this indicate the PC running the SVE and server is not powerful enough to keep up with the amount of data it is trying to process?

Thanks for the link also, I used this as a reference a few times before.

Regards,

Kallen.

[Aix-La-Chapelle]

Hi Kallen,

The Shared Variable Engine can become bogged down when there are more than 100 shared variables.  This may be what you are experiencing.  We can check buffering for the variables and disable it, and that should improve performance slightly.  As it is, using datasockets may be the best method for over 100 shared variables.  I apologize for the inconvenience.

Here are some KnowledgeBase articles that can be of use with regards to this issue:

How Does Buffering Work for Shared Variables?

http://digital.ni.com/public.nsf/allkb/5A2EB0E0BC56219C8625730C00232C09?OpenDocument

Why Is Accessing IO Variables Through The Shared Variable Interface So Slow?

http://digital.ni.com/public.nsf/allkb/F18AEE4BE7C9496B86257614000C43DF?OpenDocument

[kallen_H]

Thanks Aix,

Reading through the second link you provided has incited a few more questions. First, as I am using the SVE as an OPC client does this mean for every read and write operation of the variables, including the logging, it opens and closes each variable every time it is read or written to? Also is this the same for direct binding of the front panel controls/indicators? If this is the case, as I have not set a trigger for the logging to occur and therefore happens indefinably how do I keep the connection to the shared variables open? I am only using a few nodes in the block diagram its self to do some auxiliary data processing for user information. Does this mean I should use nodes for all front panel items?

Using the data socket for control is fine but is it possible to use it for logging into the citadel database as well without too much work around? Ill try this method and see what I can achieve.

May also look at a PC hardware upgrade also.

Thanks again,

Kallen.

[Aix-La-Chapelle]

Hi Kallen,

The variable refnum is opened when it is accessed, it is then closed when a timeout to it on the network occurs.  This occurs when you don't explicitly close the network connection to the variable.  It will remain open until the timeout occurs.  It seems those variables that are bound to front panel controls/indicators are directly linked to the shared variable.  From this, I believe the connection is always open for those particular variables. 

As for logging with datasockets,  I haven't been able to find very much in the terms of examples for it.  The best I have found is this white paper with regards to logging: http://www.ni.com/white-paper/6579/en