Running a Real-Time executable from inside the CRIO

[britstanger]

Hello 

I am using a cRIO-9030, on which I have deployed my Labview code to as a .rtexe file.

I have configured the code to execute on startup which works fine but as I am developing the code regularly and checking to see if the deployment works as expected I would like to be able to run the VI from the cRIO (not in remote opperation as this has already caused me problems with relative paths), without having to restart the device.

I am have located the .rtexe file but cannot figure out how to get Labview realtime to execute it. I am happy to use the linux terminal if required, this is a research rather than industrial application.

Thanks for taking the time to read and any help would be much appreciated.

[ScotSalmon · Accepted solution]

If you are willing to do some totally unsupported terminal hacking, log in and do "/etc/init.d/nilvrt stop ; /etc/init.d/nilvrt start" to restart LVRT without restarting the entire controller. That'll relaunch your new application. (We really need to add "restart" to that script...)

[britstanger]

Thanks Scot

I am surprised to learn it ia not possible to execute the .rtexe file without having to restart the LVRT software. thanks for this solution hopefully my code will require little tinkering with after i deploy it.

[ScotSalmon]

The rtexe is intended to be a "startup application". Normally for the workflow you're describing (making changes and regularly testing them) you'd be connected interactively and just hitting the run button rather than deploying a new rtexe each time. Can you elaborate on the relative paths problem that forced you to change the workflow? Maybe we can figure that out.

[Jabba]

Hi All,

Thanks for this useful solution. I've got just one extra question. The start / stop is working fine by using a local terminal.

But by using a SSH connection, I'm able to stop the application succesfully, but there is no way to start it again. When I try to start, I have an error saying "X11 proxy : wrong autorisation protocol attempted", even if the X11 is well configured because I'm able to export the single 'Xclock' app display to my XMing client.

Did someone had this issue ? So more did someone try to export the LabVIEW VI front panel through X Server ?

[BradM]

Hi Jabba,

What is your desired result? To have the LabVIEW application UI forwarded to your Windows machine, using your XMing server (over your PuTTY ssh connection), or to have the UI resident to the display connected to the controller?

[Jabba]

Hi Brad,

For debugging purpose, i'd like to have the LabVIEW application UI forwarded to my Windows machine, using my XMing server (over myPuTTY ssh connection).

I'm wondering if this is possible ? Because even if I'm able to forward a basic 'xlock' app from the cRIO to my xming server,  I've got few documented X11 errors when try to start remotly the LaVIEW App through the "/etc/init.d/nilvrt start" script.

[BradM]

OK, so the answer here is a complicated mess, so I would recommend you use something more in line with teh solution that I'd posted earlier about setting up X11VNC.

Basically, the hurdles that stand in your way of forwarding X for a lv application:

• Setting up an X11 server if you don't already have one (you've done this)
• Using trusted X forwarding (which, despite the name, is less secure)
  • Start Xming with -ac, I've not tested this.
• Realize that running the script noted (/etc/init.d/nilvrt) will, in the course of its execution, switch to a different user (lvuser) that does not have the needed bits in place to work with xauth (and, therefore, do X forwarding)
  • Provide a password for lvuser, ssh-login with X forwarding enabled to generate these
• Call the /etc/init.d/lvrt-wrapper script directly (instead of using /etc/init.d/nilrt, which calls lvrt-wrapper), providing the appropriate args, and running as lvuser
  • An alternate is to make X forwarding work across a su userchange, so working with xauth to setup the appropriate authorization, see https://debian-administration.org/article/494/Getting_X11_forwarding_through_ssh_working_after_runni...

After most of this (I use a Linux machine, so I could skip the "setup an X server" step), I was able to get X forwarding working with the startup app.

So, unless you have a really good reason to use X forwarding, I would recommend X11VNC, it's much simpler.

[Jabba]

Thanks for your very détails feedback. I totally agree, the vnc solution is enough.