embedded cFP executable does not start

[DavidT]

Hello everyone,

Im trying to run an embedded executable on a cFP-2010 unit. The executable will not start when I reboot my system.
The dip switches are all OFF and the ni-rt.ini file has the LaunchAppatBoot command set to TRUE. Any ideas on what could be causing this failure?
Also, when I download my code to the cFP unit and run the VI, the system works. Any info would be greatly appreciated.

thanks

David

[Aaron_G]

David,

There can be quite a few reasons that your code does not appear to start. However, it may be that your code is starting but errors are occuring lead you to believe the code has not started. When I build applications for FP RT controllers, I utilize the user LEDs (A, B, C, and D) to provide initialization status to the user. For example, I might turn LED A on as the very first action, then load some INI files and if they are successfully loaded and parsed, I will turn LED B Green (or Red if an error occured). Then I may initialize certain servers in the code and use LED C to indicate the success/failure of the server initialization.

Some things to watch out for are hardcoded file paths that are different running embedded vs running via the host. Also, you may want to log the results of the error cluster to a fine on the FP RT unit and ftp the file off after a boot to see what the errors may have been. How do you know that the program is not starting up and giving errors that prevent further execution?

Regards,

Aaron

[DavidT]

Hi Aaron,

I do use the LEDs as indicators to tell me at what stage my code is at. It performs two stages of init. before running the main part of the VI.
I set LED A to 1 in the 1st stage, 0 in the second stage, and iterate b/w 1 & 0 in the main part.
The first stage loads an ini file which has 4 parameters only (the file is present in \ni-rt\startup\data).

The second stage loads some FIFOs.

The third runs the main part of the VI.

My exec is getting stuck in the first stage. (As LED A is held constant at 1).

FYI - I have tried this code on a cFP-2010 unit here in Australia and have had no problems. The unit with which im having trouble with was configured at the same time with the same LV disks here in Aus. (The problematic unit is in the US).

Any further help is appreciated.

Thanks,

David

[Aaron_G]

David,

Since LED A is turning on, it seems like your error is probably between the fist stage and second stage. Take a look at the code in that section. Some specific things to look for are file paths, IP addresses, or other configuration items (e.g FieldPoint item names)  that may be different between the two systems that may be causing an error. Also check for loops that may be getting stuck in an infinite loop condition due to an error (or invalid data as a result of a zero execution FOR loop). You may want to add a VI that logs the contents of the error cluster to a file at various points in the code. It can also, log status messages such as "Loading Config File", "Config File Loaded", to better isolate where/how the system is getting stuck.

Regards,

Aaron

[DavidT]

I have been able to fix this problem. It seems that a subvi which was initialising datasocket connections were the culprit. I had not previously used DS in my program, but recently added them for more functionality. It seems that the DS initialisation (and even DS Writes) throught my program were causing problems. I was either not able to init the exec, or I would lose TCP comms during my tests (where I would lose data). As a result, I have completely removed all datasockets from my program and have been running reliably for almost a week now.

Thanks for all your help and suggestions.

[Aaron_G]

David,

When using DataSockets, especially in an embedded device (e.g. RT targets), I highly recommend using the low-level DataSocket Primitive VIs. Specifically, you should use the DS Open to get a refnum to a DS item, then wire the refnum to the URL input of the DS Read or DS Write VIs. When your program terminates, you should use DS Close to destroy the refnum. Otherwise, every time you read or write a DS URL, you will be opening, reading/writing, and closing the connection to the item which adds substantial overhead and increases the odds of failure. I have used the DS VIs in cFP RT controllers with ~120 items.

Regards,
Aaron