I am using LV 8.6 Developer with the DSC module installed. Also, I'm using WinXP Service Pack 3.
I am trying to create a VI that will interact with an OPC server connected to some equipment.
I've created shared variables to read the value of tags in my OPC server exactly according to the instructions on this page:
For some reason though, the value of the shared value never updates to reflect the value on the server.
When I follow the tag on the OPC QuickClient, it updates just fine, but somehow the value of the shared variable isn't updating.
I also tried retreiving this data using the DataSocket method in the "Multiple OPC Items Monitor.vi" example, but running that VI crashes LabView every time.
Also, I can create a shared variable and write to tags using a VI, but I can't read them.
It seems like I'm *this* close to getting the shared variables to work. Any suggestions?
I just went through the tutorial you linked and everything worked perfectly.
Have you successfully made the NI-OPC server work and update correctly?
Are your variables updating in the Variable Manager Watched Variables?
Are you reading the shared variable more than once in your code and wiring it to an indicator inside aloop?
Thanks for looking through this for me.
The NI-OPC Server seems to communicate okay. When I map a variable to one of the sine wave channels, it updates.
Same thing goes for the Variable Manager...I can see values from the NI-OPC Server just fine, but not from my own OPC server. The OPC Quick Client module is able to read values from my OPC server just fine though.
The shared variable is wired to an indicator inside a while loop, yes.
Since the Quick Client appears to work and the Shared Variable doesn't, are there differences between the OPC communication standards used by the two? Would that even be something I could troubleshoot?
What OPC server are you connecting to?
Have you tried communicating a variable just through front panel datasocket?
And, as always, check your DCOM settings, although since you can successfully communicate with the NI-OPC server, I believe these should be just fine.
I'm using a proprietary OPC server from Applikon Biotechnologies.
When I try to bind to the OPC data source from the front panel directly, LabView just outright crashes.
I have checked the DCOM settings, and everything appears as it should be. I've tried running this with the server and the client on one machine as well as over the network. The behavior is the same in both settings.
Thanks for your patience and suggestions,
It seems we have two issues here, not sure yet whether they are related, but datasocket should definitely work for us.
When exactly is it crashing? Can you right click on a control, go to databinding, and then select a variable? Is it popping an error message, or just closing labview completely?
There is a known issue with 8.5 databinding with dynamically called vi's, are you calling the vi dynamically?
I'm pretty new to LV, so you'll have to forgive me if it shines through in my replies. I'm not entirely sure what you mean by "dynamically calling" a vi.
Using a single VI, I can right click on a control and select a variable through the data binding tab. If I browse to my variable via the shared variable protocols, the behavior is the same as seen in my original post. If I use the DataSocket binding, LV crashes during immediately after the VI starts to run.
No worries, Wes.
DSC connectivity issues are sometimes hard to diagnose, especially with proprietary servers.
First, the datasocket crash:
Sorry I didn't look back at your original post. This is probably completely unrelated, but I still think it should be checked out. LabVIEW crashes with no error, but when you open it up, does it allow you to investigate the error? This should generate a report, usually a cpp log, which is helpful for us to diagnose potential problems. If you could get that report, I would appreciate it.
Second, the Shared Variables:
We established that the OPC quickclient updates the variable. You mentioned that it does not updated in the Shared Variable Manager. In 8.6, this was replaced by the Distributed System Manager. In there, there is a quality code. Good = there is something going on with your deadband Bad = Network or Connectivity Issues
Have you tried passing different data types? (string, dbl, integer)
I would try a different computer, a different OPC server (if you can), anything to try and isolate what is causing it. Have you had this particular server running in the past?
To answer your questions...
DataSocket: NI doesn't give me the option to investigate the error when I restart the program. I did a search for .cpp files, but none turned up. I did collect the error report that Windows generates, and I attached it. I'm not sure if that would be something useful or not.
SharedVariables: I went to use the Distributed System Manager to take a look at the variables. For both my shared variable as well as the tags on the I/O data source, the data type is listed as "advanced" and the quality is "unknown bad." I collected the logs from the I/O server and attached them. Oddly, when I look through there, I see some Quality=BAD and some VT_ILLEGAL flags. The deadband is set to zero, and the update rate is 1,000ms.
Also, I've configured the DCOM and Local Security Policy settings as described in numerous support articles, and my Windows Firewall is turned off. The OPC server and LabView reside on the same computer.
I suppose the confusing thing is why the QuickClient works fine, but the SVE doesn't.
I've tried this on three different computers with the same results in all cases. Currently, LV and the OPC server is the only software installed on any machine. The only other OPC server I have access to is the LV server, and it seems to work okay.
One thing I find odd is that NI OPC Client Status is still under your OPC1 tree...are you sure you created a new I/O server and selected your OPC server? Make sure to start from scratch to be sure.