RT ocasional error

[NAKeel]

Hi Bill,

That is definitely strange behavior.  The real time system manager uses CPU and network resources, so it is possible that it is masking a problem by changing the timing on the target.  Does this problem occur if you monitor the target with the Distributed System Manager instead of the RTSM?  

Also, you could try changing your queues to RT FIFOs and removing the event structure.  The dequeue element VI will wait until there is an element in the queue before it runs, so there is no need for the event structure.  I am not sure if there is any relationship between those items and LabVIEW crashing, but it might be worth trying.  If you still run into crash problems, please post your project and I will try to reproduce the issue.

Nick Keel 

Applications Engineering 

National Instruments

[Bill_in_Detroit]

Nick:  Just to close out this issue I want to post what ended up to be the resolution of the problem I was having.  It turns out that the UDP messaging I was using to send status from the real time chassis out to the rest of the world was falling asleep or losing its connection somehow after some random period of time and that was killing my process since everything was connected via the Stop action engine I was using.  I removed the error that was occuring as a trouble source (and the Stop action engine I was using) and the problem has not reoccured since my last post.  I guess using the real time system manager to monitor processor and memory load of the PXI controller from my remote host somehow kept the UDP links opened in the background and obscured the problem I was seeing by preventing it from happening.  This is another one of those "gotchas" that no amount of background reading or research can help with. 

It reminds me of the scientific paradox that you can observe something but sometimes the very act of observing influences that which is being observed.

Bill