05-27-2011 12:14 PM
I find that when my cRIO cpu spikes briefly I can trigger something bad in the scan engine and it will start spewing 66030 warnings and go into a Fault state.
The only recourse at that point is to reset the cRIO even though the cpu usage has returned to normal. I would like to know if there is anyway to make the scan engine
a little bit more forgiving of cpu spikes?
05-31-2011 04:07 PM
sachsm:
Is that 66030 or -66030?
66030: This I/O variable is referencing an I/O device or channel that is not active in the current I/O mode. Data read may be stale or invalid and data written may not be sent to the output.
-66030: The operation cannot be completed because one of the scanned I/O buses is not in the required I/O mode.
I'm assuming it's the non-negative one, but I just want to be sure.
If so, I think your best bet is to clear that specific warning code and/or use the programmatic Scan Engine configuration and fault handling VIs to correct the Scan Engine.
(The VIs are located in "Measurement I/O --> NI Scan Engine").
Hope that helps!
05-31-2011 04:19 PM
Yes, it is 66030 Warning. The problem is that it cannot be cleared as you stated. Once this 'triggers' something becomes permanently wacked and can only be fixed with a reboot.
I can see by monitoring the DSM cpu usage that the problem occurs when I send my cRIO an external message which causes it to call a GXML vi which spikes the cpu. (BTW, GXML can totally hammer your cRIO, it is horribly inefficient) This cpu spike faults the scan engine and it does not recover.
06-01-2011 02:12 PM - edited 06-01-2011 02:13 PM
sachsm:
Do the "Set/Get Scan Engine Mode" VIs return errors if you run them? From what I've been able to figure out regarding these errors, the Scan Engine drops out of active mode. I was hoping the issue could be smoothed over by toggling it to configuration mode, and then back to active mode.
Would you be willing to post a screen shot of the code where the warning occurs? What VI first throws the warning?
Also, what hardware are you acquiring data on?
06-01-2011 02:19 PM
Ok, I did not try to set the SE mode programmatically. I only tried to toggle the mode in the DSM and it did not work.
The problem only occurs if I invoke the GXML vi in quick succession. Maybe the recursive callstack does not get garbage collected
before the next call and thus the cpu can spike throught the roof. I went ahead and replaced the GXML stuff with my own simplified version and
now all is well so I suppose I will not investigate any further. Thanks for your help.