Programmatically Move EXE file to RT-target and modify INI to start EXE upon restart. Then Restart RT target.

[teslaaaa]

I am trying to:

1. upload the rtexe, to the real time target
2. download the ni-rt.ini file from the RT target to the local disk
3. Change the RTApp.StartupApplication path to point at newly uploaded rtexe
4. upload the edited ini-file to the RT target
5. reboot
6. new rtexe should start running

When I manualy deploy the RT application thru the project explorer and manualy restart the RT-target runs fine.

However if I follow the steps above using the attached VI, upon restart it does not start the EXE and loses connection with the RT.

When I try to reconnect it says:

"Errors were detected in the target log when connecting to the target:

LabVIEW:  (Hex 0x63B) The RT target does not have enough memory to load the startup application."

Now why would there be enough memory when the EXE is deployed thru the project explorer, but not enough when the EXE is moved manualy?

If there is an easier or better process for accomplishing this objective, please suggest.

Thanks,

[nathand]

Have you checked the format of the generated rt.ini file? Sometimes the LabVIEW Config File VIs write INI files slightly differently (quoting around strings, format of paths) than the INI files that are generated automatically by LabVIEW (such as the rt.ini).

Also, it might be easier to rename the old rtexe file, then upload the new one (named startup.rtexe). That way you don't have to mess with the ini file at all. A coworker wrote some code to do this and it worked fine.

[teslaaaa · Accepted solution]

Problem solved.  Problem was never in the INI file.

Apparently using the intimidate FTP function of "FTP Store Multiple.vi" used to move the EXE file to the rt target must modify the file somehow. Instead I just used the FTP "Put multiple files.vi", and all works fine.

[nathand]

Yup - the problem is you were using ASCII mode (the default) instead of BINARY mode for the transfer. In ASCII mode it converts line endings, which of course is not what you want when transferring a binary file. You just need to change the false constant to true, in the "build file specifications cluster" loop.