Shared Variables deployment failed

[cblanchard]

I agree that since you are running into this issue on your cRIO-9063 as well that this is likely not a hardware issue.  Moreover, it seems best to try some troubleshooting steps within your code.

After doing additional research I have also found that the software "Ni-TimeSync" may be causing your cRIO to disconnect. If you do have this software and are not planning to use it in your programs could you try to remove it and see I the behavior changes?

Also, would you be able to attach a screenshot of your code where the shared variables are being updated?  I may be able to better identify the source of the problem by looking at a portion of your code.

-cblanchard

[bjlv]

I am not using NI-TimeSync, so that should not be the cause.  The RT Main shows the section of hte code on the cRIO that writes the shared variable that goes away.  The FPGA toplevel shows how the array gets filled with data that is also a shared variable.  There is more code in both those VIs, but these sections are typical.  Good Luck.

[cblanchard]

Hi bjlv,

I do not see anything that stands out as incorrect in the CRIO RT Main.png.  Additionally, the FPGA toplevel.png appears to be the same screenshot.  Would you be able to reattach the toplevel screenshot?

-cblanchard

[bjlv]

Oops on the FPGA screenshot, I edited the shot and apparently got my clipboard wrong.  As to the problem I have with the cRIO going silent, I am beginning to wonder if I have a corrupted project.  I tried removing chunks of the code from RT Main to see if I could find a chunk that causes the problem.  Nothing isolated it, but in the process I got some variation in the behavior that I could affect just by re-deploying the code, or by recompiling the same code and deploying that.  I did a project copy and minor rebuild to move it from the original 9066 to the brand new 9063, but that probably was not enough to avoid the corruption if that is what I have.  I don't get any error messages from LabVIEW or from Distributed System Manager (except -66460 sometimes on bootup) that tell me anything is wrong, but the cRIO goes silent to everybody after about 4 minutes, and then comes back 3 minutes later.  Data acquisition and writing to file on the cRIO continues during the silence.

[bjlv]

I have created a new project using the old VIs to see if that was the issue.  There is something wrong now that prevents my full RT Main from deploying from the project, even though it will build without errors.  The stripped out version that eliminates most of the shared variable writing by the cRIO, keeping only the heartbeat variable active, will deploy from the project, and seems to work without the silences happening.  If I deploy that stripped version as a startup, it runs, but only updates the heartbeat once at boot, and never again even though it should toggle TRUE/FALSE every 200msec.  Is that a clue?

[cblanchard]

Hi bjlv,

I looked through both of the screenshots but did not identify anything that may be creating the silences that you are experiencing.

The fact that the heartbeat only updates once in your last test suggests that there may need to be some changes to the timing in your code. Some questions that may help identify the source of these errors are:

1. In the test that you mention are there any other parts of your project function properly, or is your all of your code only executing once?  

2.  How are you configuring the 200mS wait?  Are you placing a wait function in a while loop?

-cblanchard

[bjlv]

I only have two loops left in the stripped version that sort of worked.  The heartbeat loop is the one in the RT Main screenshot, athough the 200 msec constant is just off screen to the left.  The timing of the while loop is as shown, a wait in the while loop.  The local for the stop goes to a button on the front panel, which can't be clicked when it runs booted on the cRIO.  That local is initialized to FALSE earlier in the code, so there is no reason for it to ever go TRUE.  This stripped code was my try at identifying the section that caused the problem by removing everything that did actual work.  There is nothing left that can still be functional, so I don't really have anything else that can still run when this piece stops.  The other loop left is using a different shared variable to set up the data acquisition mode.  That has an event structure, so it waits for a value to change sent by the Host PC, which I am not triggering in these tests.  The silence happens when no action has been requested by the host, this code is idling along and goes silent on its own, returning a few minutes later when it works from the development environment.  Why it seems to run the loop only once when run as deployed is a mystery to me.

[cblanchard]

At this point you have certainly done a lot of troubleshooting to identify what is causing the behavior.  Were you able to try and run a portion of your code that does not include any shared variables?  If that does not work then the source of the issue could involve something more than the shared variables.

What Compilation Tools and which version of LabVIEW  are you using?  Are you using our Compile Cloud Service?  I would like to verify the compatibility of the tools you are using with your LabVIEW version.

If worst comes to worst you could now try to move the shared variables to your host computer.  You mentioned that you would like to run the program with the PC disconnected, but that may be a good temporary solution. 

I also feel it may be helpful to read through this link to see if any changes stick out to you.

[bjlv]

I am using the local compile server with LabVIEW 15.0.1f1 32 bit.  NI Update service thinks I am up to date on the software support for cRIO.  I do see some communication issues with the cRIO even if I run no LabVIEW code.  I have reformatted the cRIO hard drive and reinstalled the cRIO software, and still have issues with the cRIO not responding when I try to run my RT Main from the LabVIEW project.  It checks for conflicts, and doesn't always get an answer from the cRIO, preventing me from running anything.

[bjlv]

OK, I have really gone backwards on this one.  I did a disk reformat and reinstall of the cRIO software, and I can not deploy to the cRIO anymore.  I always get a failure to connect with the target system error.  What is worse, the communications dropouts are still present.  If I watch a channel output from Mod1 (a 9223) in the chassis using Distributed System Manager, I see voltages bouncing with noise for about 3 or 4 minutes, then no communication for 2 or 3 minutes, and then back to noise.  This is fresh from the reformat and reload of the cRIO software without any of my code deployed to the cRIO.  I even tried a software restart from NI-MAX with RT and FPGA code disabled without success.  Is there a way to get this completely back to factory settings beyond what I have done already?