CRBasic program errors

Analyze data soon after deployment to ensure the data logger is measuring and storing data as intended. Most measurement and data-storage problems are a result of one or more ClosedCRBasicCampbell Scientific's BASIC-like programming language that supports analog and digital measurements, data processing and analysis routines, hardware control, and many communications protocols. program bugs. Watch a video: CRBasic | Common Errors - Identifying and fixing common errors in the CRBasic programming language.

Program does not compile

When a program is compiled, the ClosedCRBasic EditorThe CRBasic programming editor; stand-alone software and also included with LoggerNet, PC400, and RTDAQ software. checks the program for syntax errors and other inconsistencies. The results of the check are displayed in a message window at the bottom of the main window. If an error can be traced to a specific line in the program, the line number will be listed before the error. Double-click an error preceded by a line number and that line will be highlighted in the program editing window. Correct programming errors and recompile the program.

Occasionally, the CRBasic Editor compiler states that a program compiles OK; however, the program may not compile in the data logger itself. This is rare, but reasons may include:

  • The data logger has a different operating system than the computer compiler. Check the two versions if in doubt. The computer compiler version is shown on the first line of the compile results. Update the computer compiler by first downloading the executable OS file from When run, the executable file updates the computer compiler. To update the data logger operating system, see Updating the operating system.

  • The program has large memory requirements for data tables or variables and the data logger does not have adequate memory. This normally is flagged at compile time in the compile results. If this type of error occurs: 

Program compiles but does not run correctly

If the program compiles but does not run correctly, timing discrepancies may be the cause. 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 data logger, but it can be a useful tool for fine-tuning a program. For more information, see Information tables and settings (advanced).

See the CRBasic Editor help for detailed instruction information and program examples: