Imagine that you have a datalogger station three hours away that gathers your measurement data. To physically get to your station, not only do you have to drive for three hours, but then you have to hike for an hour up a snow-covered mountain.
A couple of days ago, you made a change to your CRBasic datalogger program and were unsure of the effects of the update. But you needed to make the change and proceeded to send the updated program to the datalogger. Unfortunately, that was the last you heard from your station.
Although you discovered what was wrong in your datalogger program that caused you to lose communication, you now have to wait for a clear day so you can make the trek up the mountain to correct the program. Wouldn’t it be a lot easier if you could get your station up and running again without having to make a trip to the site?
The good news is that there is a simple solution that can prevent your program update from causing a loss of communication with your station. Within your CRBasic program, use the RunProgram() instruction, and reference the program name that your new program will be replacing. In the example below, the RunProgram() instruction is referencing a previous program named ProgNameRev1.cr6. Notice that the RunProgram() instruction is placed within a conditional If Then/EndIf instruction—just below a timer.
Recommended for You: For additional help and information regarding how the instruction works, refer to the CRBasic Editor Help for the RunProgram() instruction. To access the file, highlight RunProgram in the instruction list, and click the Help button above the list.
‘ProgNameRev2 'Main Program BeginProg Scan (1,Sec,0,0) Public ChangeBackTimer ‘Declaration of variable ChangeBackTimer = Timer (10,Min,0 ) ‘Result of timer is assigned to variable If ChangeBackTimer >= 10 Then ‘Conditional statement evaluates variable RunProgram ("CPU:ProgNameRev1.cr6",4) ‘Points to another program on CPU, Set to run now. EndIf NextScan EndProg
This code allows your newly uploaded program to run for 10 minutes (enough time to test whether or not your communication has been affected). Then it reverts back to your previous program automatically.
If you send the new program, your datalogger seems to be operating as planned, and communication is operating normally, you can proceed to comment out or delete the “ChangeBack” portions of your code. Then send the program again. Congratulations! Your station is now up and running, your datalogger has resumed logging data, and you didn’t have to spend hours traveling back and forth to your station site to do it. Although the RunProgram() instruction has many other uses, in this application, it may just save you from an unexpected trip.
Note: As fantastic as this application may sound, the RunProgram() instruction is not a fail-safe instruction. Possible complications can arise when combining RunProgram() with other instructions such as SetSetting(). Contact Campbell Scientific if you are using the SetSetting() instruction in your program(s).
Tip: It is always a good practice to download your data frequently and keep a current backup of your datalogger program and configuration file.
If you think the RunProgram() instruction can help you in your application, I invite you to try it out a few times with your unique programs in your office. If you have any questions or comments about using the instruction, post them below.