02-17-2010 12:50 PM
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!
02-17-2010 01:04 PM
02-17-2010 06:26 PM
02-18-2010 07:42 AM
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.
02-18-2010 09:32 AM
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.
09-29-2011 01:43 AM
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.