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.

Remote CR3000 logger not running 2 of the slow scans after resending program

artyb Aug 25, 2020 07:47 AM


I've sent a very slightly modifified program (a version comment and changed 2 average commands for TRH sensors to run 2x rather than 1x for Hygrovue sensor arrays to include the RH element of the array), and then the original (which has been running fine for nearly a year) again to a CR3000 logger and now slow scans 2 and 3 of 4 are not running. These should be doing simple Hygrovue5 measurements, one per slow scan. The program compiles fine, there are no skipped scans, but the last run time of slow scans 2 & 3 is given as 01/01/1990. Everything else is working. OS is CR3000.Std.32.03 Any ideas?

Presumably something has got a bit corrupted (or damaged-any way to tell which?) and reloading the OS would be a good idea. However doing that remotely is risky. How could I ensure that a particular program runs on reboot, and what about baud rate settings for comms?

Thank you,


GaryTRoberts Aug 25, 2020 10:59 AM

What does Status.MaxProcTime and Status.ProcessTime show in your logger. Also, what is the scan rate for the main scan?

What is the scan rate of the 1st slow sequence and how long is it taking to run?

The status table should be showing skipped scans for SlowSequence 2 and 3 if they have never run. What are the status of SkippedSlowScan(1), SkippedSlowScan(2), and SkippedSlowScan(3) in the Status table?

What are the values of Status MaxSlowProcTime(1), MaxSlowProcTime(2) and MaxSSlowProcTime(3)?

These can give you a clue as to which slow scan is eating all the logger processing time or if the main scan is taking up so much time, there isn't room enough to run a slow sequence.

https://help.campbellsci.com/CR1000X/Content/shared/Maintain/Advanced/status-table-info.htm?tocpath=Information%20tables%20and%20settings%20(advanced)%7C_____2 can give you some basic information on each of these fields that will aid in troubleshooting the issue.

The root cause might be there there isn't enough time allowed for the SDI-12 instructions to run and process.

Are the HygroVUE installed on the same SDI-12 port on the CR3000?

artyb Aug 25, 2020 11:53 AM

Hi Gary,

Thanks for the reply. This program has been running for nearly a year... I did look at these values before posting, but for the record:

Main scan is 1s.

Status.MaxProcTime: 155275 usec

Status.ProcessTime: 43413 usec

SkippedSlowScan(1): 0

SkippedSlowScan(2): 0

SkippedSlowScan(3): 0

SkippedSlowScan(4): 0

MaxSlowProcTime(1): 799511

MaxSlowProcTime(2): 0

MaxSlowProcTime(3): 0

MaxSlowProcTime(4): 34557

Slow scan 1 is making a single SDI12 (C7) "MC!" reading from a CH200 and a few array operations as in the program examples and also an avgrun.

Slow scan 2 is SDI12 (C1) Hygrovue5

Slow scan 3 is SDI12 (C3) Hygrovue5

Slow scan 4 is quite a bit of logic to decide whether to run heaters or not, and ultimately controlling SW12V 1 & 2.

All slow scans should run once every 30s.

LastSystemScan: 2020-08-25 17:20:20.05

LastSlowScan(1): 2020-08-25 17:20:00

LastSlowScan(2): 1990-01-01 00:00:00

LastSlowScan(3): 1990-01-01 00:00:00

LastSlowScan(4): 2020-08-25 17:20:00

I have a saved status table from when this was working, with the same program, and that shows:

Status.MaxProcTime: 267443 usec

Status.ProcessTime: 45093 usec

MaxSlowProcTime(1): 804238

MaxSlowProcTime(2): 421336

MaxSlowProcTime(3): 614303

MaxSlowProcTime(4): 91384

So the times for other parts of the program are similar, but if anything higher than now, when part of the program isn't running...

The logger has a CF card BTW.


GaryTRoberts Aug 25, 2020 12:04 PM

Thanks. What version of the OS is in the CR3000?

artyb Aug 25, 2020 12:25 PM

OS is CR3000.Std.32.03 (in 1st post!)

GaryTRoberts Aug 25, 2020 12:46 PM

Arghh. Sorry I missed that. Would you mind sending me both programs? gtroberts -at- campbellsci.com. I will see what I can find.

artyb Aug 25, 2020 12:53 PM

Lots to take in, no problem!

I sent the new program and found the problem, then resent the original program which also now has the problem. I don't think the issue is with the programs?

GaryTRoberts Aug 25, 2020 01:04 PM

Understood, but having your programs will help me recreate what you are seeing or saw. So it would be helpful to get them, if possible.

GaryTRoberts Aug 25, 2020 01:05 PM

Also an xml file of your logger settings would be beneficial as well.

artyb Aug 25, 2020 01:26 PM

Hi Gary,

There is a storm here and I've just lost internet access to the servers at work after retrieving one of the programs. I'll send the other files when I can.


artyb Sep 2, 2020 08:55 AM

Hi Gary,

Just wondered if you'd got any further or if there were any more diagnostics I could do? Advice on how to procede (sending OS remotely and keeping comms working, onsite or replacing the whole logger) would be welcome.

Best Wishes,


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