LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Start EXE on Linux RT From UI "Desktop"

I have a cRIO 9035 running NI Linux RT with embedded UI enabled.

 

I can deploy and run my application as a startup exe - but this requires a reboot to run. Is there a way to simple "run" the application from the "Linux" "desktop"?

 

Why? Users are going to interact with this system and they see a computer - I can allow the users to close the application (which may be useful for a variety of reasons) but they cannot "restart" the application simply (a double click for example), or at least I don't know how to do it. 

 

Any ideas?

0 Kudos
Message 1 of 10
(4,669 Views)

A RT exe should always run, and do not let the user "close it", but I am not sure what you mean about this? Closing the UI window? What is the benefit if the user can stop the RT exe running??

 

Anyway, what you could do is to put a button on the GUI, and if the user requires this, you can programmatically restart a RT application. See the methods here: http://digital.ni.com/public.nsf/allkb/B9C4DA1E5F3BACBA862578C000633B76

0 Kudos
Message 2 of 10
(4,634 Views)

A philosophical question I suppose...

 

What "is" NI Linux RT? Is it an actual OS? Or only (and exclusively) for running a LabVIEW RT application?

 

I would argue that is it closer to an OS (and that is a good thing!). This makes it more flexible and dynamic (loading new device drivers, file management, etc.). In this, it is more and more like a "normal" PC and in this, you could imagine doing more than just running a single RT EXE (once!) per boot.

 

Right now, I'm mostly looking for a way to clear an EXE completely from memory and restart it. This seems like it could be simple and intuitive.

 

Rebooting the whole thing to achieve this seems a bit silly to me.

 

edit: spell check!

0 Kudos
Message 3 of 10
(4,630 Views)

The power of an RT OS is that, it is not like a normal OS 🙂 If you want a normal OS, use a PC and run Windows or Linux on it...But you will lose reliability, determinism and tight timing...

 

"you could imagine doing more than just running a single RT EXE (once!) per boot."

No, you should design your RT app in a way it does not require reboot. Why would I run an RT exe "once"? It should run continuously...
🙂 Use a State Machine and program the features as required, as simple as it is.

I do not know if it is possible what you want: only to "reload/restart the EXE". What is your problem with the normal reboot (which is an off-normal thing anyway)?

0 Kudos
Message 4 of 10
(4,609 Views)

Hmmm, 

 

I want it both ways: a real time OS and the flexibility of a PC. Yes, I think I can have it both ways 🙂

 

And why not? I suppose you might argue that I "should" use it like the days of yore and think of it like a PLC. It is not a PLC, it is not a Microcontroller, it is a full computer - why not embrace that?

 

Obviously there are a million ways to solve a problem and if I have to wait for a reboot if I am lazy and cannot fully recover from all error observed in my application then I suppose I will have to embrace that. 

 

I guess it comes back to the idea that this thing has a fairly full OS, it has a desk top, it obviously can run my application, it lets me close that application, why can't it let me start it with a click?

 

To be clear this is all fine, chose the platform for a reason and it was *not* to use it exactly like a PC. But is *was* to have an embedded UI - the UI on my PC lets me start things, my phone lets me start things - I guess I still don't see a compelling reason why the NI Linus RT OS doesn't (what my application "should" do is a bit beside the point I think...).  

0 Kudos
Message 5 of 10
(4,602 Views)

I understand what you want. But imho a stand alone NI RT product will not and should not cover your needs. What you described I think is better to do with a headless, always running RT OS on a reliable RT hardware (PXI, etc.), plus a normal PC. The PC can communicate via Ethernet with the RT OS, so the user gets the "usual OS experience".

 

This is what we do for example in one of our recent projects: we measure radioactivity levels with multiple ionization chambers connected to picoamp meters. These picometers are connected to PXI units via GPIB interfaces. A "master PXI" is connected to a Siemens PLC which takes care of logging, warnings, safety measures in case of accidents, etc...

The most important requirement of the RT application in my case is not tight sync/determinism, but the high reliability what you can NOT gain using a normal OS! When my RT app starts, it must run for a year(s) without touching it, without rebooting it! We programmed the RT side in a way, that any client PXI or subclient picometer can be connected "on the fly", so the master RT OS is never need to be rebooted, it can recognize any client malfunctioning or re-connecting, etc...

 

Beside the two way communication between the RT master and the PLC, we also network publish the front panel of the RT app for diagnostic reasons. But the application is never rebooted even via this remote front panel!

 

You wrote about "...cannot fully recover from all error observed in my application...". You should program your RT applicaton that it does not produce internal error in its finished final version! If the error comes from an external source (client hardware unplugged accidentaly, gets broken, etc.), you do want to HANDLE it, and not reboot the whole application 🙂 Example: Warn the user that a client responds with error, log the error code, take required actions if needed. If the external problem is fixed, either automatically, either by a user, give the option to reconnect the previously failed client. This is the proper way to handle errors, do not "throw the baby out with the bathwater" by rebooting the whole RT applicaton which might control critical processes!

0 Kudos
Message 6 of 10
(4,569 Views)

Have you read NI's description of Linux Real-Time?  They took advantage of the openness of Linux, its "lean-ness", and the fact that the kernel had been written to allow the necessary level of "determinism" that is required for a Real-Time OS.  This is not a "one-size-fits-all", but a "targetted" OS that meets the requirements for Real-Time.

 

I've not used the more modern NI RT platforms, but am running LabVIEW Real-Time on a PXI system, with the PharLap RTOS running on a dual-core Pentium.  My LabVIEW RT code is set to run as Startup.  As GerdW recommends, I "capture", log, and process any Errors that occur, giving the user the option to restart the program (which doesn't cause a reboot -- the program is in a "Do Until I Say To Stop" loop that begins by initializing everything) or to reboot the PXI (which, of course, will also restart the Program, as it is the Startup routine).

 

I have the option on this controller of creating a second partition on the hard drive and installing Windows 7 (or Windows 10, or Linux), and having a Boot Manager that will give me the option of my RT-OS or Windows (without the RT).  I see no need for this -- in my situation, I've got a PC connected to this PXI that interacts with the RT side of the code, the PC handling the User Interface, streaming the data being collected (and streamed to the PC via TCP/IP) to disk, etc.  Indeed, when the user, interacting with the Host program on the PC, decides to stop taking data, the Host code tells the PXI (running the RT code) to reboot, thus ensuring a "clean start" the next time the Host wants to take data.  The 30 seconds or so that it takes the RT side to reboot is generally far shorter than the time between ending one Experiment (from the Host side) and deciding to start another.

 

Bob Schor

0 Kudos
Message 7 of 10
(4,557 Views)

Well NI Linux RT is not your typical Linux desktop distribution. There is no kdm or gdm (desktop manager) that a user can go into to click on pretty icons to start a process.

 

There is however a normal unix shell that you can login to through an ssh connection and on there you can just about do anything that the Linux OS provides. That includes killing and starting processes including the default rtexe program which always resides at a specific location. For the rtexe it may be a little bit more complicated than just entering the rtexe program name on the shell, but because Linux is such an open system there is nothing that prevents you to investigate the Linux startup scripts and see where the initialization for the RT app is added to by the NI tools and to replicate that.

Rolf Kalbermatter
My Blog
Message 8 of 10
(4,556 Views)

Thanks Rolf and thank you all for the replies.

 

This was more a curiosity question for me. I "get" what a RT application/solution is "supposed" to be (and the original question wasn't about good design, although I appreciate the desire to educate others about good design!).

 

The query was really generated from a feeling sort of along the line of what Rolf wrote: "...because Linux is such an open system there is nothing that prevents you..."

 

I like this idea: "nothing prevents you" 🙂

 

 

0 Kudos
Message 9 of 10
(4,546 Views)

I didn't try the suggestions but I stumbled on this post the other day that seems pretty close to what I had originally envisioned.

0 Kudos
Message 10 of 10
(3,776 Views)