LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Shared Variables deployment failed

Solved!
Go to solution

I have a project in LV2015 that uses a cRIO-9066 hosting shared variables.  The host PC loses the connection to them after times of about 4 minutes, and about 3 minutes later, they are connected again.  The cRIO can be idle (waiitng for a command from the host PC), or doing a DAQ task saving to a USB stick connected to the cRIO when the connection is lost.  The cRIO will continue the saving to USB locally during the time the shared vaiables are not communicating.  The Host PC sees the cRIO in Distributed System Manager and NI-MAX during the lost connection, but gets no information from it until the connection is restored.  I have reloaded all the cRIO software and reloaded the cRIO firmware without solving the problem.  Any ideas where I should be looking?

0 Kudos
Message 1 of 24
(3,739 Views)

Hi bjlv,

 

I would probably start by monitoring the CPU usage of your cRIO. If your cRIO's CPU is railed, the real-time operating system will prioritize its code functionality and can stop responding to network communication effectively taking it off the network. If this happens, it usually will stop hosting network published shared variables as well. 

 

I would add some code to your RT vi to monitor how much of your CPU is being used. If you see numbers above like 80-90%, we can probably assume that is whats causing it. 

-----------------------------------------------
Brandon Grey
Certified LabVIEW Architect

0 Kudos
Message 2 of 24
(3,701 Views)

Thanks for the advice.  I should have said that I looked at CPU amd memory usage, and they were in ranges that should be fine.  The CPUs never get above about 25%, and the highest I have seen the memory is 70%.  The CPUs are usually around 6% when the code is idle and reach the 20-25% range when DAQ and saving to file is active.  The memory is usually around 50-55% but has reached 68%.  I think the problem is somewhere else.

0 Kudos
Message 3 of 24
(3,696 Views)

Have you tried moving the shared variables to be hosted to the PC instead of the cRIO to see if that makes any difference?

 

Also, if you are wanting every value to be saved, you probably will want to save the values to disk since Network published shared variables are tag data and you may miss a value if you are depending on the PC to just read the variables. 

-----------------------------------------------
Brandon Grey
Certified LabVIEW Architect

0 Kudos
Message 4 of 24
(3,680 Views)

I haven't tried moving the shared variables to the Host PC, but since the cRIO won't tell NI-Max or Distributed System Manager anything while the shared variables don't update, I feel that the communications side of the cRIO has failed.  The shared variables are being used to let the user know what is going on, not to log any data, so missing that feedback is not too important.  What is important is that a shared variable is used to tell the cRIO to log or not to log, set relays, and things that should happen as soon as the Host PC wants them to.  That does not happen when the shared variables are unresponsive.  The Host PC has some things that it controls the timing of, like how long to measure a particular configuration, and then change the relays and measure again.  This fails when the cRIO is not listening to commands through the shared variables.  To repeat the symptom, the shared variables work for a few minutes, then go silent for a few minutes, and then come back on their own.  This repeats all day.  I am beginning to suspect that the cRIO is damaged somehow.

0 Kudos
Message 5 of 24
(3,672 Views)

Hello bjlv,

 

As GreyGrey mentioned, it would still be a good step to try moving the shared variables to your Host PC. Shared variables sometimes behave differently when on the Host PC.

 

Also, did this behavior just start and were your shared variables updating properly at any stage of development?

 

Last of all, do you have another cRIO-9066 or development computer that you could test your setup on?  This could help give us more insight into the source of the error.

0 Kudos
Message 6 of 24
(3,653 Views)

I did have the cRIO working fine at one time.  It sat idle for a while, then I started an upgrade to the Host PC code and discovered the problem.  Even the older code had the same symptom of the cRIO dropping all ethernet communication and then restoring it.  This happens with the 3 different PCs it was tried with.  I do not have a different 9066 to test on.  I did get a period of about 10 hours where the problem did not occur after the first time I updated the firmware, but the problem was back the next day and did not go away the next time I reloaded the firmware.  I tried changing 24V power supplies out of desperation, and that worked.  It still worked the next day.  I went back to the first power supply to prove that the problem followed the power supply, and it did not.  Now that first power supply has also had 8 hours of problem free running.  I really do not know what is causing the problem.  I can still consider moving the shared variables to the Host PC, but right now it would not prove anything one way or another.  Thanks for the suggestions though.

0 Kudos
Message 7 of 24
(3,649 Views)

Hi bjlv,

 

Based on the posts of other customers and your comments it still seems that this may still be related to the CPU load, even though it did not appear to be a problem during your testing.  Another person had a similar issue which is explained in this forum.  Most of the useful suggestions to handle this are on the second page of this forum.  

 

Has your test with the first power supply continued to work since your last post?

0 Kudos
Message 8 of 24
(3,628 Views)

So far the system has been working fine, no matter which power supply is used.  Until the problem is back, I don't know that I will try any changes since I would not be able to tell if they were helping.  I understand your point about the CPU load, but having never seen it rise over 25% it seems unlikely to me that it would rise high enough to be the problem.

0 Kudos
Message 9 of 24
(3,616 Views)

I didn't have access to the hardware for a while, but it is now back and the problem remains.  I also have a cRIO-9063 now, and they both have the problem, so I don't think this is a hardware issue.  One extra thing I have seen, that was probably true all along, is that it is not just the shared variable that goes quiet for a while, it is the whole cRIO.  Distributed System Manager shows all communication lost during the quiet periods, as does NI-MAX.  The LabVIEW project can't deploy anything during a quiet period either, with an unable to communicate to target error.  I will believe that my code is the issue, but I don't understand how I can get days of no glitching followed by a day where the glitch happens every 3 or 4 minutes.  The code, deployed and booting in the cRIO at this point, should either always work or always glitch I would think.  I have not moved the shared variable hosting to the PC, but I would really like them to stay on the cRIO since I want the system to work even when the PC disconnects and goes away for awhile.  The PC is expected to do this sometimes for a day or more.  The shared variables are used for commands from the PC to change acquisition conditions on the cRIO, and there are 2 booleans acting as heartbeats to let each end know about the status of each other. One acquisition mode sends live data to the PC for archiving, but all the others save data to a USB stick on the cRIO.

0 Kudos
Message 10 of 24
(3,567 Views)