Section 10. Troubleshooting
10.4 Troubleshooting — Status Table
Information in the Status table lends insight into many problems. The appendix
Status Table and Settings
(p. 603) documents Status table registers and provides
some insights as to how to use the information in troubleshooting.
Review the section Status Table as Debug Resource
(p. 485). Many of these errors
match up with like-sounding errors in the Station Status utility in datalogger
support software.
10.5 Programming
Analyze data soon after deployment to ensure the CR1000 is measuring and
storing data as intended. Most measurement and data-storage problems are a
result of one or more CRBasic program bugs.
10.5.1 Program Does Not Compile
Although the CRBasic Editor compiler states that a program compiles OK, the
program may not run or even compile in the CR1000. This is rare, but reasons
may include:
• The CR1000 has a different (usually older) operating system that is not fully
compatible with the PC compiler. Check the two versions if in doubt. The
PC compiler version is shown on the first line of the compile results.
• The program has large memory requirements for data tables or variables and
the CR1000 does not have adequate memory. This normally is flagged at
compile time, in the compile results. If this type of error occurs, check the
following:
o Copies of old programs on the CPU: drive. The CR1000 keeps copies of
all program files unless they are deleted, the drive is formatted, or a new
operating system is loaded with DevConfig
(p. 111).
o That the USR: drive, if created, is not too large. The USR: drive may be
using memory needed for the program.
o that a program written for a 4 MB CR1000 is being loaded into a 2 MB
CR1000.
o that a memory card (CF) is not available when a program is attempting to
access the CRD: drive. This can only be a problem if a TableFile() or
CardOut() instruction is included in the program.
10.5.2 Program Compiles / Does Not Run Correctly
If the program compiles but does not run correctly, timing discrepancies are often
the cause. Neither CRBasic Editor nor the CR1000 compiler attempt to check
whether the CR1000 is fast enough to do all that the program specifies in the time
allocated. If a program is tight on time, look further at the execution times. Check
the measurement and processing times in the Status table (MeasureTime,
ProcessTime, MaxProcTime) for all scans, then try experimenting with the
InstructionTimes() instruction in the program. Analyzing InstructionTimes()
results can be difficult due to the multitasking nature of the logger, but it can be a
useful tool for fine tuning a program.
481
To Next Page
Loading...
Need help?
General
