Start up application issue with cRIO 9063

[JoeWork]

I have an application I am building for a cRIO 9063.  I am using LabVIEW 2015 SP1.  I can work in the LabVIEW project environment and connect with the cRIO and get the application running.  I have also built the application and deployed it to the cRIO to have it run stand alone.  For some reason the stand alone application does not want to run unless a network cable is connected to the cRIO from my development laptop.  I am not connected to the cRIO in LabVIEW when it runs with the network cable connected.

I came across the following article and worked with its list of solution options.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8jFSAS

Problem: Real-Time Application not set as start-up application

Solution: Set as Start-up application

• Already set. 

Problem: Physical NOAPP DIP switch set to “ON”

Solution: Turn off DIP switch.

• No dip switches 

Problem: Controller set to obtain IP address from DHCP server (dynamic IP) but cannot connect to the network

Solution: Set a static IP address if system must boot without network connection.

• Verified with MAX 

Problem: NI-RT.ini (configuration/initialisation file) set incorrectly

Solution: RTTarget.LaunchAppAtBoot in NI-RT.ini must be set to true.

• Couldn’t find this file in the controller 

Problem: Executable running but behaving unexpectedly

Solution: Verify that the executable is behaving as intended.

• Runs fine when connected to network cable. 

Problem: File Layout

Solution: File reference hierarchy must be set up correctly

• Option SET. 

Problem: Property node in the real-time application references front panel object or property

Solution 1: Remove all property nodes that reference front panel objects or properties from the VI.

Solution 2: Enable debugging to include the front panel in the build.

• Option SET.  

Problem: RT OS unable to start required services before start-up application attempts to execute

Solution: Delay the start-up application so that it does not call a service on the RT OS immediately.

• Added 10 second wait before start of RT app. 

Problem: RT application contains type definitions.

Solution: Do not include type definitions in the build of the application.

• Option SET. 

Problem: Real-time target does not support SSE2 instructions

Solution: Disable SSE2 optimisation

• Don’t see option

One thing I was wondering about was the static address.  If that is selected in MAX why would the controller show up as, "CorrosionSensor (169.254.1.2) [Link-local IP Address]".  Is there still an issue with the static IP setting on the port?  

I don't have any property nodes, type defs, or network varibles in the project.

If you have any ideas for things I can try please let me know.

Thanks for your time,

Joe

[BradM]

Two things:

First, you've done a really good job of describing the troubleshooting steps that you've done (which, sadly, some of which are outdated and not really appropriate for NI Linux RT targets), but you didn't really indicate what you are expecting that you are not seeing that leads you to the conclusion that the startup application is not running. Can you describe what you're expecting to see and are not seeing?

Second, a generally-useful thing to check would be to turn on Console Out, and it should indicated that it has loaded the application on boot (or indicate if there's been an issue). Connect a serial cable + null modem adapter (or, if it's built into the cable, just the cable) to see what's going on with the target.

[JoeWork]

I am looking at signals coming out of the Analog Output module that I have in my cRIO as one indication that it is running.  I also have the USER1 and the USER FPGA1 LEDs providing a heartbeat.

All that works fine when starting the cRIO with the network cable is plugged in.  But none of that it working when the cable is not plugged in.

[BradM]

Also:

Physical NOAPP DIP switch is set to "ON"

This has been replaced on newer targets with a soft-DIP, accessible from the target in MAX or the Web Interface

...

NI-RT.ini (configuration/initialisation) set incorrectly

Please, don't manually edit this file. NI is trying to scrub references to this effect, the previous Real-Time Application not set as start-up application handled this possible issue source

...

RT OS unable to start required services before startup application attempts to execute

With NI Linux RT, this isn't really appropriate anymore (a somewhat sane initialization system is being used, compared to older RTOS targets)

...

Real-time target does not support SSE2 instructions

This is not appropriate for these targets (SSE2 refers to x86 targets, the 9063 is a ARM Cortex-A9 architecture target)

[BradM]

---

wrote:

I am looking at signals coming out of the Analog Output module that I have in my cRIO as one indication that it is running.  I also have the USER1 and the USER FPGA1 LEDs providing a heartbeat.

All that works fine when starting the cRIO with the network cable is plugged in.  But none of that it working when the cable is not plugged in.

---

Thanks for the updated information. My next step would be to see what the Console Out shows

[JoeWork]

What is the console output supposed to show or send if I am not actually using it?

I found one control that this page talked about, but it didn't fix the issue.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9kESAS

[TheEngineeringBear]

Some quick steps for you!

1) Try adding a 3-5 second wait at the beginning of the code to see if the RT application is throwing an error at the beginning that is not allowing it to run.

2) Remote Debug by enabling debugable executable in Build Specifications

3) When in doubt, crash logger to track system state 

Would you be able to give us a high level understanding of your application so that we could think a little more specifically about what's going wrong?

-Bear

[JoeWork]

My application is filtering very noisy com bus and providing a clean communication signal out.  The noise is close to the communication frequency.

I was able to get the console output to work and I'm attaching what was sent when trying to start the application without a network cable attached.  I can't tell if there is anything in that file to indicate what the issue is.

In the mean time I will try to work with the crash logger.  I don't think I will be able to remote debug this application when it is actually working like it is supposed to when a network cable is connected to the cRIO.

[BradM]

What the log shows is that the Startup application is being loaded and run, and that it doesn't report any particular issue (we don't see LabVIEW crash and restart or anything like that).

Depending on the size and structure of the application, I'd start looking at adding some sort of logging to the application to see where/how far it gets along and adds some traceability to what the application is doing. Another option is to start disabling parts of the application using the Diagram Disable Structure to see if this changes the behavior.

(Side-note: I would recommend you start looking to use something other than the FTP server for future projects, it is deprecated. Use WebDAV or sftp)

[JoeWork · Accepted solution]

Just wanted to let everyone know that the issue has been found and solved.  Apparently there was an issue with the resource I had selected for the Open FPGA VI Reference.  It contained the IP address of the cRIO.  Not sure why, but I was able to change it and it started working.

Thanks for your help!!!!

Joe