Different behavior between cRIO "Run as Startup" and Debugging Run

[James.M]

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,

[MajorTom]

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. 

[James.M]

MajorTom,

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.

[MajorTom]

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.

[James.M · Accepted solution]

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:

Another bug popped up where a system config VI threw an error because of a missing library. None of it made sense because the library was installed on the cRIO and shouldn't have a problem. Long story short, the problem was that the application was running immediately at startup and that library hadn't properly loaded by that point. So I added a while loop that timed out at 60sec and continuously ran that VI until no error occurred. Turns out it takes approximately 30 seconds from startup, every time. Now this is the reason it didn't occur in developer mode: because the cRIO had already been running for a bit before developer mode would have a chance to deploy.

So now after this 30-second delay that occurs before I run the thermocouple connections is enough time for the variables to initialize or something, and the connection error no longer occurs when i set up the thermocouples.