How to Prevent a Program Update from Causing a Loss of Communication
by Robert Hyatt | Updated: 11/10/2016 | Comments: 5
Blog Topics
Area / Application
Product Category
Corporate / News
Search the Blog
Subscribe to the Blog
Set up your preferences for receiving email notifications when new blog articles are posted that match your areas of interest.
Suggest an Article
Is there a topic you would like to learn more about? Let us know. Please be as specific as possible.
Imagine that you have a data logger 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 data logger 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 data logger. Unfortunately, that was the last you heard from your station.
Although you discovered what was wrong in your data logger 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 data logger 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 data logger 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 data logger 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.
About the Author
Robert L. Hyatt was a Support and Implementation Engineer at Campbell Scientific, Inc. He received his Bachelor of Science from Utah State University in Engineering Technologies and Environmental Science before joining Campbell Scientific in 2007. Robert has two passions: farming and solar energy. He enjoys recording data all around him, from solar collection and temperatures out in the field to energy usage in the house. No matter the project, Robert loves to include a Campbell Scientific data logger to monitor and control it.
Comments
kcopeland | 11/10/2016 at 02:32 PM
This is a good function! If I understand correctly, this does not help if your program has a compilation error. We've recently run into a problem with functions specific to OS29 are being sent to remote loggers with OS27.04 and the onboard compiler fails and our port controlled modem does not turn back on. We need a way to run a program when compile fails.
sonoautomated | 11/11/2016 at 03:49 PM
Mr. Copeland, That is indeed another exception, thanks for that input. I will submit this to engineering to see what can be done. If something does come about, you can be sure it will be on a new OS that you will need to upload. :) --Cheers my friend.
thinkitcodeit | 11/17/2016 at 02:30 AM
You could implement a default.cr1 (or cr# depending on the logger type) which restores communications. In the event of a program failing to compile or run and in the event after a power cycle there is no running program then the datalogger will automatically run this default program for you. It is a great way to put some basic comms startup code in that is tried and tested to ensure you get access back.
luisfgranada | 06/07/2018 at 06:56 AM
Hello, I have a problem when using this instruction. The program is the following:
Public NumFiles
Public Files(10) As String
Const MeasurementProgram = "CPU:Template.CR1"
Dim i
BeginProg
Scan (1,Sec,3,0)
NumFiles = FileList("CPU",Files())
For i = 1 To NumFiles
If StrComp(Files(i),MeasurementProgram) = 0 Then
RunProgram (MeasurementProgram,4)
EndIf
Next i
NextScan
EndProg
What I do is to look in the memory "CPU" for a particular program. In the example (CPU:Template.CR1). If it founds it, then try to run it. The problem is that if the program is not in the memory the instruction RunProgram should not run (beacause is in the IF loop) but it does. I have tested the loop and is fine. Could you help?
Thanks
sonoautomated | 06/07/2018 at 08:45 AM
Dear Luisfgranada,
On a logger I just wiped clean with the latest OS, I was not able to replicate your problem with my Test.CR1 program.
But then I decided to upload a program named “Template.cr1”, the RunProgram instruction in my Test.CR1 program would look for it, and as expected, it found it. So rather than deleting the Template.CR1, I decided to hide it using the FileManage instruction. So at this point, the File Control Dialog Box no longer had a file called Template.cr1 listed, but when I ran my Test.cr1, program it still found the file called Template.CR1 and began running it instead; As it should have.
Is it possible that you have a hidden program that you can’t see? This may be the reason the RunProgram instruction is finding this file you think does not exist. If this is the case, you have at least two options. 1- You may use the FileManage instruction to delete that hidden file. 2- You may upload the lasted OS to the logger. Before updating your logger with the latest OS, please remember to download any data and programs you might need, and maybe do a full logger backup. Backing up your logger is always a clever idea and can be done from Device Configuration Utility.
I hope this has been helpful. Please let me know if you have any more questions.
Please log in or register to comment.