How to Prevent a Program Update from Causing a Loss of Communication

by Robert Hyatt | Updated: 11/10/2016 | Comments: 3

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.


Area / Application

Product Category

Activity

Corporate / News

Enter your email address:



Suggest an Article

Is there a topic you would like to learn more about? Let us know. Please be as specific as possible.

Leave this field empty

Communication failure between weather station and computer

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.


Share This Article


About the Author

Robert L. Hyatt is 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 datalogger to monitor and control it.

View all articles by this author.


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.

Please log in or register to comment.