LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Updating values from OPC server on startup

I'm using LabVIEW to create a screen to display data from an OPC server (KepSERVER). I've been using standard indicators and have been linking them to the OPC server with the Datasocket system. The system works well for rapidly updating values. The issue I'm having is that if I start the LabVIEW application it doesn't always update all of the values on the screen from the OPC. Of course this is only noticeable on the variables that don't change rapidly. Sometimes only a few of the relatively static values are updated, sometimes 90% of them are, I haven't figured out why this changes. The OPC has the correct values, it just seems that LabVIEW is not polling all of them.

Is there a fix or this? Should I be pulling the data from the OPC in a different manner?

Thanks.
0 Kudos
Message 1 of 4
(3,204 Views)
npower,

You mentioned that your indicators are bound to your OPC server items though DataSocket. I assume that each of the front panel LEDs are green when the program is running? This would tell us that the DataSocket communication channel is successfully established. If this connection is established, then I’ve got a few suggestions/questions that may help for troubleshooting:

1) Could you possibly try using Server Explorer (or any other OPC client) to read the values of the variables from your OPC server. This would check to be sure that the communication problem is between LabVIEW and the OPC server, and not that the values are not current in the OPC server. The Sever Explorer download site is linked below.
2) If you use the DataSocket API, do you get the same results? You can test this by creating DataSocket Reads on the block diagram, and wiring the outputs to indicators.
3) Do the values on the indicators ever update? What I mean is that when you start running the program, do the relatively static values update when they are changed or never at all?
 
Server Explorer:
http://digital.ni.com/softlib.nsf/websearch/34E67FA9F8FF7A0686256AE60054198C?OpenDocument

0 Kudos
Message 2 of 4
(3,192 Views)
So I've been able to isolate this problem a little more. My links seem to be correct (I do have a green light on the front panel and eventually the values will update if you change them).

The problem appears to be only with fields that are Read/Write. Read fields update properly from the start. I've come up with a work around but it's not ideal. I created a property node for the Datasocket>>Mode. sending a value of "3" sets read/write mode, sending a "2" sets "read" mode. So I made a button that toggles the 3 to a 2 for one "scan" and then sets it back to 3. This reads all the values in then returns the controls to read/write mode. It's cumbersome but I can make this work.

Thanks for the help and if you have further advice on how to automate this procedure I'd appreciate it.
0 Kudos
Message 3 of 4
(3,185 Views)
npower,

What may be going on here is that because these controls are set up in read/write mode, it is not clear whether the OPC server or LabVIEW should be writing to the variable. Essentially, the LabVIEW code runs and writes the control’s default value to the OPC server. Because it will then wait on a value change to update, you see the delay. You could verify this by using an OPC Client to read the value stored on the OPC server when this occurs.

As you have discovered, forcing the control to be in read mode at the program start will remove this indeterminism. You should be able to set this property node to read then back to read/write programmatically in your code without a toggle button. I assume you have some loop running in your code: I would create a case structure that has a case for the first loop iteration to perform this setup process. Please let me know if you run into any further trouble putting this solution into code. Thanks!

-Mike
0 Kudos
Message 4 of 4
(3,182 Views)