10-15-2014 06:39 PM - edited 10-15-2014 06:40 PM
Hello,
I have an application that does a lot of stuff, including reading from an NI 9213 Thermocouple card, which is on an expansion chassis connected to a RT cRIO Target. The application is run on the RT Target. My specific problem is pertaining to a behavioral difference between opening a connection to the thermocouple channels in Debugging mode (clicking the run-arrow on the VI) and opening the connection via a Build Specification (clicking Run as Startup).
During runtime, the VI writes to a text file on the cRIO's harddrive. I have attached two text files, one from Debugging mode and one from Run as Startup mode. I only have two thermocouples plugged in (ch1 and ch15). From the text file you can see that the connection opens without an error in Debugging mode, but throws an error in Startup mode. I have also attached a snippet showing the VI I have been using for testing.
Some notes:
Nothing with the VI is changed between each run type.
The Build Specification has the attached VI selected as the Startup VI, everything else is default
Has anybody else out there had a similar problem like this? I feel like the debugging mode should act indentically to the normal Startup deployment. Otherwise, what's the point?
Thanks,
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
Solved! Go to Solution.
10-16-2014 03:07 PM
Hi James,
Essentially RIO started propagating some errors in 2013 that they didn't in the past. The work around we used for VeriStand customers was to require that customers don't leave "empty" connections to thermocouples since you can still get data for the first N thermocouples until one is not connected.
10-16-2014 04:19 PM
Thanks for the reply. I moved the two thermocouples I have to channels 0 and 1 to see if that fixed the problem, but I still get the same errors. See attached text files for debugging mode and Run as Startup mode once again.
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
10-17-2014 12:15 PM
Hi James,
I looked further into the error code from the log and found the following information:
You may get this error if you attempt to write to the SharedVariableIO property node frequently. The error arises because the shared variable being configured temporarily becomes inactive while the property change is made in the Shared Variable Engine.
The best way to prevent this error is to use event based programming instead of writing to the shared variable inside of a loop.
It is also suggested to use a DataSocket Write to write to the property rather than using the SharedVariableIO property node . Using the property node forces an update to the intermediate shared variable refnum property map. This propagates changes to the Shared Variable Engine, whereas using the DataSocket API writes the new property value directly to the Shared Variable Engine.
An example of the URL for the Hi alarm level property would be\\localhost\process name\variable name.Alarms.Hi.level
. It is also recommended that you use appropriate error handling on shared variable reference nodes, rather than letting the VI handle its errors automatically which stops your VI if an error occurs.
And also:
This error can occur if you have an incorrect Path specified under your Bind to Source section for the shared variable. This could be as simple as a typographical error in the defined path.
You may also see one of the following more descriptive messages if you are auto deploying the shared variable when running a VI:
Error -1950679035 occurred at ni_tagger_lv_Read
The shared variable does not exist.
If the path of your bound shared variables seems to be correct, then your DCOM and/or firewall settings may be preventing your computer from having access to the individual variables in the shared variable engine.
DCOM and/or firewall settings may be preventing your computer from having access to the individual variables in the shared variable engine. The Shared Variable Engine uses an OPC server to pass information, and this uses specific ports that may be blocked. Please follow the instructions found in Using OPC via DCOM with Microsoft Windows XP Service Pack 2 to unblock the specific ports and to set the DCOM security settings for OPC client access.
11-06-2014 05:34 PM
I've fixed the problem! Or at least worked around it by fixing a different bug. This other bug occurred the same way this bug did, only at Run as Startup. I'll summarize for you:
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'