LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to prevent cRIO Scan Engine Warning 66030

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?

0 Kudos
Message 1 of 5
(3,688 Views)

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!

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 2 of 5
(3,678 Views)

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.

0 Kudos
Message 3 of 5
(3,676 Views)

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?

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
Message 4 of 5
(3,670 Views)

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.

0 Kudos
Message 5 of 5
(3,666 Views)