Auto-update of 2120 startup application using compact flash

[Duvelle]

Just getting started with a 2120, but have one "tricky" question.  I want to have my executable run off the controller's memory, not the compact flash; however I also want the executable to check for software updates on a compact flash card.  In other words, if there is a compact flash card present when the app (controller) starts, and the executable on it appears correct (size, name check), then copy the file to that controller's startup folder to replace the existing app...  The executable would bypass normal operation at that point, provide LED feedback to alert the user to reset the controller (& remove card), and "voilà"!  We have an almost automatic compact-flash updatable, self-starting application...

Question(s):

- do I need to worry about whether I'm building the app to the controller's memory, to compact flash, or locally (to later copy onto compact flash)?

- are there any issues with having a program copy an update over itself in this way (different types of memory, when used, etc...)? Alternative would be to have a 2-stage app: 1 checks for update, launches the 2nd if no update (single app would be cleaner)

- am I missing anything else?

Thanks,

Phil

[Graziano]

Hi!
  If I understand correctly... You can do following steps:

   - you develop your application for cFP2120, and download it to cFP's C: disk, then you can copy it to a compact flash. I am referring to a "developing" cFP2120.

   - in field, you have another cFP2120, running an application that you created before, and you insert compact flash with new exe.  You reboot controller.

   - the resident application checks for updates, and find it on CF card.  This boot application copies executable from CF to C: disk, (maybe better if you use .par extentions until opy does not finish!).

   - You manually (or programmatically) reboot controller with new application.

   This was my idea, but, because of customer doesn't asked me to proceed in implementing it, so I stopped, but I'm always interested in knowing if this can work.

   Some problems with this may be the coerence of libraries.....  Please, if you find this way succesful, let me know....


   Another possible solution is to use the "open VI reference" method, but I am not used with it.....

   Hope I wasn't too confusing

graziano

[Duvelle]

quick update...  I just started playing with a compact flash card and already found something interesting.  There doesn't seem to be any generic way to check if a card is present or not.  The only way is to look for something specific (i.e. look for a specific executable name/path, get file size or something along those lines) and continue based on the error out.(error 7 I think if file not found).

I will update again after I've had a chance to try a few more things.  If anyone has done this before, has any other suggestions, please do tell.

Phil

[Graziano]

Hi!
   In fact, it's difficult to check for compact flash; sometimes, running in debug mode, you get errors if you doesn't handle it correctly. That's why I would suggest not to start your application from CF; you can  put the exe in CF, and then make the FieldPoint copy the exxe to a C: drive directory, and then reboot and execute the program.

   You can do the following: the Fieldpioint module checks for switch 3 state: if it is ON it starts default application, if it is OFF it searchs for the Compact Flash card, and try to copy new exe....

   Whatever will be your solutions, it will be usefull to get your feedback... 

   Bye, and have a nice day!

graziano

[bburress]

Hi Duvelle,
    Perhaps the best way to approach this would be to have two executable programs on the cFP.  The startup.rtexe will check for a new version of software on compact flash.  If it finds that new software, it copies it onto the cFP and begins running it.  If it doesn't find new software, it runs the existing file.  This way would require no reboot or anything, as the startup.rtexe would never change, just the actual .exe it would call would change.  Just an idea.

[Duvelle]

Graziano, I'm sorry if I confused you somehow, but I never intended to run the application off the compactflash.  Copying the file over to "C:" (startup folder) was always my plan.  The only potential issues I see are: if the startup application is being run right off the memory it's stored in, then the file copy could corrupt data; also I saw in another thread someone had problems when an application was compiled to the compactflash card directly, as opposed to the hard drive and then copied over...  So I definitely need to identify a reliable way to compile the application before I can deploy it (by compact flash, ftp or otherwise) to the controller.

Brian, I realize having 2 separate applications is an option: it's in fact an option I stated in the original post.  But for various reasons a single application here is much preferred if possible.

Again I will update here as I get more results,

Phil

[Graziano]

Hi Duvelle,
   I keep saying that I'm interested in what you're doing, so lety me know about developements!

   I think that the problem of corrupted data will always be present.... you can solve it this way:
   
      1) the application copies the new .exe from CF card, to C drive

      2) the old application is not deleted, but it will be given a name such as "oldexe.exe".

      3) if new application doesn't work, you can switch back to old application.

   The last step is quite difficlut, because you need a mechanism to detect system crashes, or invalid .exes, I think you can involve the watchdog, and some configuration file to do this.

   I mean, if watchdog rise, you can save to a config file that current .exe make the FP crash, and then reboot.  So, next time FP wakes up, it will change back new .exe with "oldexe.exe".

    My idea is quite confused, I know, and I didn't implement it, so maybe you'll find errors......

   Have a nice day!

graziano

[Duvelle]

I was able to run some basic tests yesterday and found the following issues:

• difficulty deleting all files in the startup folder of the controller (prefer to start with "clean folder" to avoid corrupted data with copy/overwrite)
• initially unable to copy sub-folders / files
• otherwise completely able to access the compact flash drive as a storage device, as expected
• without DLL files in the data sub-folder (deleted during the "update" process but not copied from CF) the application still works just fine on reset...  if the DLL files are not needed why do they get deployed?
• how can I delete an executable in the controller's startup folder?  Even with a 2-application approach I need to be able to delete the old so I can add the new...  I can't seem to delete the application programmatically, or even with the application stopped and using ftp.

I need to do some more work on this before I can report more progress.  If anyone has any suggestions though please let me know.

Thanks,

Phil

[bburress]

Hey Phil,
    I'm not sure that the Real-Time OS will allow you to affect files that are currently in use, just as Windows locks files from being deleted while they are in use.  That is the main reason I suggested using the 2 application method.  Have startup.rtexe just check for a new version of another executable that is being held in a separate folder.  That way the startup folder is only being used for startup.rtexe. 

[jhannam01]

Phil,

  I am dealling with similar issues, currently I have resorted to do it all over TCP/IP.  I have been using the System Replication vi that NI has released.  I have thought through that same problem and think that you are going to run into problems, given the current functionality that is exposed to us.  Many of the files can only be deleted or overwritten in install mode.  The problem is when you boot into install mode you can run an application to delete the files.  Sorry I could'nt be more helpful on the exact problem but maybe it is a possible alternative