LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT Shared Variable Engine stops publishing

I have an RT system (PXI-8106) that hosts quite a few network published shared variables (NPSVs) for communicating to a Host PC. My Host and RT executables have been functioning fine on their respective systems for weeks, but just recently, I started running into problems with my NPSVs. My Host application has indicators to display DAQ data being acquired on the RT target and transferred via NPSV, and lately the application will update normally fine for several hours and then the displays will stop updating all of a sudden. If I reboot the RT target, the communication is restored...for a couple hours, anway, until we get another NPSV lockup. I can see no rhyme or reason as to why it stops updating the variables when it does; it seems to just randomly crap out.

 

It just happened again, so I brought my development laptop down to run the Distributed System Manager. Sure enough, the NPSVs all stopped updating (latest timestamp was about 30 min previous to my check). I know, however, that the RT system is still running (I can open remote front panels), and none of the NPSV calls use their error input clusters, so an upstream error would not be causing the issue. Also of note, I have a couple NPSVs that are aliased to PSP URLs (NI_SystemState\CPULoad), which do continue to update while the remaining NPSVs do not. So that seems to indicate to me that it is not a networking issue, nor is it a Shared Variable Engine issue.

 

I also programmatically deploy the NPSV library from the Host to the RT target on initialization, so I know they are deployed properly. Redeploying does not kickstart the RT SVE into updating. The only thing that seems to solve the problem (albeit temporarily) is a reboot of the RT target.

 

Does anyone have any ideas as to what might be causing the RT to stop updating the NPSVs? I have already check the NPSV Troubleshooting KB (http://digital.ni.com/public.nsf/websearch/6E37AC5435E44F9F862570D2005FEF25?OpenDocument), and none of those suggestions appear applicable in this case (most address networking issues that result in never being able to read the NPSVs in the first place, whereas my problem is NPSV communication dropping out arbitrarily). Has anyone else run into such a problem?

 

Thanks!

0 Kudos
Message 1 of 6
(1,959 Views)
EDIT: I should also note that none of my shared variables are configured to use buffering. Also, I am only using Shared Variable Nodes for the reading/writing; I am not using the Read Variable.vi or Write Variable.vi VIs. [What--if any--is the difference between those methods, by the way?]
0 Kudos
Message 2 of 6
(1,956 Views)
I am seeing very similar behavior in my configuration. I have a WinXP system (LV2009) communicating with a RT PXI system using network shared variables to send control state updates and monitor status. The system worked fine until recently when the shared variable read on the host side started failing randomly, usually after 6-14 hours of running. The RT portion of the code is deployed as an exe. Memory usage and CPU utilization on the RT side are quite low and stable. I'm at a loss on how to troubleshoot the problem.     
0 Kudos
Message 3 of 6
(1,942 Views)

I think I have an idea as to why my NPSV communication was freezing. One of my NPSVs is a 2D String Array of Alarm History Data, which just published infomation about alarms that have been triggered on the RT system; each new alarm appends a 10 element string array onto the 2D string array. For the most recent testing we were running, there was a recurring alarm condition that was not applicable (i.e. did not need to be handled--it just kept adding new elements onto the history array), and I am guessing that the array may have just gotten too big. When the RT target kept updating the NPSV (at 1 Hz) with more and more 2D String Data, it may have caused a buffer overflow for the shared variable.

 

I will attempt to recreate the problem on another system to verify the cause.

0 Kudos
Message 4 of 6
(1,928 Views)

You might want to try to use a more RT-safe method to publish your alarms.

 

If you are using the RT Scan Engine you can use the Fault API to publish any user defined alarms.

If you need to roll your own then consider forming an persistant array of alarm records which gets updated (not appended necessarily) for each

alarm instance.  Repeat alarms are indicated by incrementing a count field within an alarm record.

 

0 Kudos
Message 5 of 6
(1,923 Views)

How u able to solve the proble. i am using CRIO 9073 i also facing similar problem but in my case i have two controllers and one PC. but the problem comes most of the time in updating data from  controller with same IP.


@sachsm wrote:

You might want to try to use a more RT-safe method to publish your alarms.

 

If you are using the RT Scan Engine you can use the Fault API to publish any user defined alarms.

If you need to roll your own then consider forming an persistant array of alarm records which gets updated (not appended necessarily) for each

alarm instance.  Repeat alarms are indicated by incrementing a count field within an alarm record.

 


 

0 Kudos
Message 6 of 6
(1,210 Views)