Comment empêcher que la mise à jour de programme puisse causer la perte de communication
par Robert Hyatt | Mis à jour le : 11/10/2016 | Commentaires : 5
Imaginez que vous ayez une station de mesure avec une centrale de mesure, qui enregistre vos données à trois heures de distance. Pour arriver physiquement à votre station, non seulement vous devez conduire pendant trois heures, mais ensuite vous devez faire de la randonnée pendant une heure dans une montagne couverte de neige.
Bien que vous ayez découvert ce qui n'allait pas dans le programme de votre centrale de mesure, et ce qui vous a fait perdre la communication, vous devez maintenant attendre un jour où il fasse beau, afin que vous puissiez faire trajet jusqu'à la montagne pour corriger le programme. Ne serait-il pas beaucoup plus facile si vous pouviez mettre votre station en marche à nouveau sans avoir à faire un voyage sur le site ?
Dans votre programme CRBasic, utilisez l'instruction RunProgram() et faites référence au nom du programme que votre nouveau programme remplacera. Dans l'exemple ci-dessous, l'instruction RunProgram() fait référence à un programme précédent nommé ProgNameRev1.cr6. Notez que l'instruction RunProgram() est placée dans une instruction conditionnelle If Then/EndIf-juste en dessous d'un timer.
|
Recommandé pour vous : Pour obtenir de l'aide et des informations supplémentaires sur le fonctionnement de l'instruction, reportez-vous à l'aide de l'éditeur CRBasic de l'instruction RunProgram(). Pour accéder au fichier, mettez en surbrillance RunProgram dans la liste d'instructions et cliquez sur le bouton d'Aide (Help) au-dessus de la liste. |
‘ProgNameRev2
'Main Program
BeginProg
Scan (1,Sec,0,0)
Public ChangeBackTimer ‘Déclaration de variable
ChangeBackTimer = Timer (10,Min,0 ) ‘Le résultat du timer est assigné à une variable
If ChangeBackTimer >= 10 Then ‘la condition évalue l'état de la variable
RunProgram ("CPU:ProgNameRev1.cr6",4) ‘Pointe vers un autre programme sur le CPU, il est défini pour s'exécuter maintenant.
EndIf
NextScan
EndProg
Ce code permet à votre programme nouvellement téléchargé de fonctionner pendant 10 minutes (suffisamment de temps pour tester si votre communication a été ou non affectée). Ensuite, il revient automatiquement à votre programme précédent.
Si vous envoyez le nouveau programme, si votre centrale de mesure semble fonctionner comme prévu et que la communication fonctionne normalement, vous pouvez procéder à commenter ou à supprimer les parties ''ChangeBack'' de votre code. Puis renvoyer le programme. Félicitations à vous! Votre station est maintenant opérationnelle, votre datalogger a repris les données d'enregistrement, et vous n'avez pas eu à passer des heures à aller et venir sur votre site de station pour le faire. Bien que l'instruction RunProgram() ait beaucoup d'autres utilisations, dans cette application, elle peut juste vous sauver d'un voyage non prévue.
Note : Aussi fantastique que cette application puisse paraître, l'instruction RunProgram() n'est pas une instruction entièrement sécurisée. Des complications possibles peuvent survenir lors de la combinaison de RunProgram() avec d'autres instructions telles que SetSetting(). Contactez Campbell Scientific si vous utilisez l'instruction SetSetting() dans vos programmes.
Astuces : Il est toujours recommandé de télécharger fréquemment vos données et de conserver une sauvegarde de votre programme et de votre fichier de configuration.
Si vous pensez que l'instruction RunProgram() peut vous aider dans votre application, je vous invite à l'essayer quelques fois avec vos programmes dans votre bureau. Si vous avez des questions ou des commentaires sur l'utilisation de l'instruction, postez-les ci-dessous.
A propos de l'auteur
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.
Commentaires
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.