We have a logger that has been installed for a long time, which has started skipping scans. There are some failed sensors, but I haven't spotted parts of the program which would be delayed by that as they are analogue measurements. The logger is reporting main scans skipping. The main part of the program I can see that might have delays is a section communicating over RS232, but that is running in a slow scan so shouldn't cause the main scan to skip?
I wondered if there is any way to debug remotely which part of the program is causing this? Clearly the skipped scan counters show if it is the main scan or slow scans, but I need to determine which lines or sections cause the issue. I've previously done this by sending a modified program containing lots of timers to see how long execution has taken to each point. Is there any other way to do this which would disrupt the data collection less-LoggerNet debugging tools? There have been a few watchdog errors on the logger over the years, so maybe it is a logger hardware issue?
Your best clues are the values in the Status table. Look at MeasureTime, ProcessTime, and MaxProcTime. The values are in microseconds. If the program compiles in pipeline mode, measure time and process time can happen at the same time. In sequential mode, you add them together.
Be mindful of any instruction like SerialIn with a timeout parameter. If the sensor failed, you will be reaching the maximum timeout.
Thanks for the reply. The program is sequential, and those values add up to more than the main scan interval, which agrees with the skipping of main scans, but doesn't help me determine where in the program the issue arises?
Look at what measurements on the station are giving incorrect values, and focus on the instructions used to measure those. Particular digital measurement, because those have timeouts which can be long.
For the benefit of others searching the forum I think the 'InstructionTimes' instruction comes fairly close to what I was looking for. It would involve sending a new program though.