Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

Reason for SkippedSystemScans


mwassmer Jun 12, 2015 05:08 PM

Although my CR1000 is not reporting any SkippedScans, it is reporting many SkippedSystemScans and I don't understand why.

Here are some facts about my system:
- Program compiled in SequentialMode
- 20 second scan rate
- MaxProcTime: ~9.9 sec
- MeasureTime: ~1.4 sec
- MaxSystemProcTime: ~0.06 sec
- MeasureOps: 682

In a SequentialMode scenario, my understanding is that the MaxProcTime + MeasureTime + MaxSystemProcTime must be less than the scan rate, or else there will be skipped scans or skipped system scans. In my case, the sum of those three times is less than 12 seconds and my scan rate is 20 seconds. Why am I getting skipped system scans if I have an 8 second safety margin?

* Last updated by: mwassmer on 6/12/2015 @ 11:08 AM *


JDavis Jun 22, 2015 02:26 PM

From the information provided, I am not sure either why you would be skipping system scans.

Please post your program or email it to me
jdavis at campbellsci


JDavis Jun 22, 2015 11:03 PM

I don’t have the cause completely nailed down, but the skipped system scans is not a cause for alarm in this case. The LastSystemScan field shows that system scans are occurring on a regular basis.

If you don’t want to see skipped system scans, add the Calibrate instruction in your program before the analog measurements. That will force system scan to occur at that time and disable the background scheduler.

From what I have discovered, the system scans were skipping as a result of the Pulseport within an If statement and a scan that took more than 4 seconds. The conditional usage of a measurement process instruction(Pulseport) meant that the background processes don’t have a schedule set in stone to go off of. The background process looks at 4 second time chunks for available analog hardware time. The background calibration was having to bump itself farther down the schedule until after all the processing. The rescheduling registered skipped system scans, but didn’t prevent system scans from occurring in the latter part of the 20 second scan.

Log in or register to post/reply in the forum.