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
Summary of Contents for CR1000
Page 2: ......
Page 4: ......
Page 6: ......
Page 32: ......
Page 36: ......
Page 38: ......
Page 40: ......
Page 60: ...Section 4 System Quickstart Figure 16 PC200W View Line Graph 60 ...
Page 96: ......
Page 98: ...98 ...
Page 302: ......
Page 453: ...Section 8 Operation Figure 115 Using the Keyboard Display 453 ...
Page 456: ...Section 8 Operation Figure 118 Real Time Custom 456 ...
Page 457: ...Section 8 Operation 8 8 1 3 Final Memory Tables Figure 119 Final Memory Tables 457 ...
Page 458: ...Section 8 Operation 8 8 2 Run Stop Program Figure 120 Run Stop Program 458 ...
Page 460: ...Section 8 Operation Figure 122 File Edit 460 ...
Page 461: ...Section 8 Operation 8 8 4 PCCard Memory Card Display Figure 123 PCCard CF Card Display 461 ...
Page 478: ......
Page 506: ......
Page 536: ......
Page 636: ......
Page 642: ......
Page 644: ......
Page 676: ......
Page 677: ......