LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bad data from LinOPC server

I am working on a LabVIEW SCADA system which connects to a Eurotherm DCS using the LinOPC server. After startup, all tags with unchanging values (eg setpoints, booleans) return a default value and bad status in the (LabVIEW 7.1) tagengine. Once the value of the tag has changed (either from the DCS or by writting a value [if writeable] the status becomes good and the correct value is returned. I have tried changing the engine update parameters without success. Connecting to the tags in the LinOPC server using NIs Server Explorer produces similar results, but connecting using Eurotherm's iTools OPC Scope returns all values. Has anyone experienced this problem or know of a solution/work around?

0 Kudos
Message 1 of 6
(2,920 Views)

Hi rossg,

I want to make sure that I understand the behavior that you are seeing.  You have several tags on a LinOPC server.  On startup, values that are not updated come up as their default value and with a bad status, is this right?  However, once the values are changed, the values update and the status changes to good, is this right?  Are you saying that before the value is changed and updates, the status of the tag is bad?

0 Kudos
Message 2 of 6
(2,902 Views)

Hi Ben,

 

Thanks for your interest in my problem:

I want to make sure that I understand the behavior that you are seeing.  You have several tags on a LinOPC server. Yes ~600

On startup, values that are not updated come up as their default value and with a bad status, is this right? Yes.  Unchanging analogs return 0 and booleans return false until their value changes and is updated. On my LabVIEW SCADA screens, I change the background color of indicators to: light blue-changed value, red-value in alarm, yellow-bad status. At startup, there is a sea of yellow which gradually disappears. Once the plant has been through a full process run all the tags are good except for those that haven't changed (eg alarms, which are mostly not displayed on screen).

However, once the values are changed, the values update and the status changes to good, is this right?  Yes

Are you saying that before the value is changed and updates, the status of the tag is bad? That appears to be the case. I am not on-site, and mostly when I've been there testing has been limited due to the plant being in operation and while off-site I don't have DCS hardware to connect to LinOPC.

0 Kudos
Message 3 of 6
(2,895 Views)

Hi rossg,

I'm pretty sure that what you are seeing is expected behavior.  Before a value is updated, a tag will be assumed to be its default value.  Additionally, until the value is updated, the status of the tag can't be known to be a good value.  Once the client has received an indication that communication has been established with the tag host, the value will update and the status will be changed to good.  In short, you are seeing what I would expect to see based on your setup.

 

I don't know if there is a way to force a polling of the variable from the client side.  I suspect not, but that may be something you look into if you are concerned about the status of the tags.  As long as the tag status is unknown and not "Bad" I wouldn't worry about it.  One thing you will likely want to do is let your client run for prolonged periods of time so that you you don't have to reinitialize the values as often.

 

I hope that answered your question.

0 Kudos
Message 4 of 6
(2,885 Views)

Thanks Ben, you may be correct, but I would have thought that the server (LinOPC) would have updated all tags at launch. I think it does have values for all tags, because they can be read using another client (iTools OPC Scope). I will try and do some more testing to further clarify this issue.

As you noted in your reply, this issue won't normally be a problem. The exception is the situation where the SCADA program/PC needs to be re-started during a run (which can happen!). In this situation, incorrect statuses & values will be displayed resulting in confusion and possible 'corrective' actions being taken that could compromise the run. This also would lead to a general mistrust of the system. For these reasons I think it is important to find a solution.

0 Kudos
Message 5 of 6
(2,881 Views)

Hey rossg,

Based on the behavior that you are seeing, it seems to me that the values on your server are not being published when a new client (in this case Server Explorer) connects to the server.  When the server does publish a new value, the client reads the value just find.  One thing you could do programmatically from your server would be to write the values of each tag each time a new client connects.  Do you have a way to configure on your OPC server how often your values get written?  For example, do you have a scan rate that you could set to publish all of the values every 5 seconds, or at some other incremement that suited your needs?

 

We don't officially support LabVIEW back as far as version 7.1 or Server Explorer.  We've made a lot of changes over time, and we've basically redone the equivalent of Server Explorer entirely in our Datalogging and Supervisory Control Module..  I'm glad to help you as best as I can, but you would probably be better off moving to the DSC Module for current applications where you are monitoring OPC tags.

0 Kudos
Message 6 of 6
(2,872 Views)