Hardware Developers Community - NI sbRIO & SOM

cancel
Showing results for 
Search instead for 
Did you mean: 

compile RT EXE

hello, i have a (maybe stupid) problem:

from Labview the RT Vi behaves like it should. After compiling and run it as a startup (and after reboot the SOM) the system does not react as it should...

Any suggestions?

Thank you in advance.

0 Kudos
Message 1 of 13
(6,939 Views)

Hi Nico,

Are you using any of the unsupported features listed in this knowledge base?

Unsupported LabVIEW Features on NI Linux Real-Time Targets

Specifically look out for the features that work when running with a front panel (interactive mode) but fail when the front panel is disconnected (RT EXE).

The following features only work on an RT target with a front panel connection:

  • Front panel property nodes and control references
    Note - An RT target updates the values of property nodes and control references asynchronously, meaning a property node or control reference might not contain the latest value of the indicator or control.
  • Dialog VIs and functions
  • VI Server front panel functions

I know it can be difficult to debug a stand alone application because the debug interface is disconnected.  You could consider building a debuggable executable to gain insight into your RT EXE.  If the system appears to work correctly when debugging is connected, then the issue (in my experience) is likely related to one of the front panel issues listed above, or a race condition induced issue. 

These are general tips based on my experience, and without further info, it can be difficult to guess what may be going wrong.

Regards,

spex

Spex
National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 2 of 13
(5,872 Views)

thanks, that wasnt the case, but i could find the problem:

i want to read the mac adress of the som using the fillowing:

Unbenannt.jpg

So, what can i do now? it runs in development mode on the som, but not in compiled rtexe...

0 Kudos
Message 3 of 13
(5,872 Views)

@ spex:

can you help?

0 Kudos
Message 4 of 13
(5,872 Views)

Nico,

Do receive an error when you try to run the above code as an rtexe?

Does LabVIEW fail to compile the rtexe?

Can you try building a seperate build spec around this above code? I want to make sure we don't have a setting to exlude a required library.

Kyle Hartley
Senior Embedded Software Engineer

0 Kudos
Message 5 of 13
(5,872 Views)

hello Kyle,

yes the error is number: 1055

no, the compiler is does not fail.

its not easy to seperate this as we would not see the error...(no FP)

Thanks for your help.

0 Kudos
Message 6 of 13
(5,872 Views)

Nico,


You can use a shared variable to pass the error to the network and can view the shared variable in Distributed System Manager or with a LabVIEW VI on your host. Also simply log the error to disk.

Are you getting error 1055 displayed on the error out terminal connected to connect to system vi or on the error out from the property node?

Kyle Hartley
Senior Embedded Software Engineer

0 Kudos
Message 7 of 13
(5,872 Views)

the error occurs at the system init VI (like seen on the Block diagram picture)

0 Kudos
Message 8 of 13
(5,872 Views)

Did you install software from the recommended software set in MAX?

     You select CompactRIO 14.x (LabVIEW 2014) etc or did you use custom install?

     Can you try formatting the SOM from MAX and reinstall software on the SOM from MAX? Be sure to install NI System configuration, There may be a subfeature of hardware support also.


I haven't gotten my hands on a SOM yet but I confirmed it worked fine on a 9068 (same OS and processor)

Kyle Hartley
Senior Embedded Software Engineer

0 Kudos
Message 9 of 13
(5,872 Views)

Kyle and Nico,

The portion of code that I was worried about is if "localhost" will always resolve correctly.  There are 3 network interfaces on the SOM, so I wonder if the SW is resolving 'localhost' differently when the application is running headless?  Or what if the code is running before an IP address is resolved because the Ethernet driver is still waiting for a response from a DHCP server?  When running connected, then you can be sure that the Ethernet stack has established a connection before the application code executes.

I don't have a lot of spare cycles to try this out, and its unlikely I would replicate your network environment either.

-spex

Spex
National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 10 of 13
(5,872 Views)