LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reconnect to a VI running on an RT Target

   When I first started using RT, if I remember correctly, there was a fairly simple mechanism for reconnecting a front panel on your desktop to the copy of that VI that was already running on the RT target.  Either that method no longer exists, or I just can't find out what it is.  I've searched the forums, and have come up pretty empty.  I found a method that was claimed to work back on LV 7 days, but it does not work for my hardware and software.  I found another link that basically says you can't do it - that the RT p rogram has to be restarted to reconnect the front panel.  Can anyone verify or clarify?

Thanks,

    DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 1 of 17
(4,734 Views)

The answer is ... it depends.  In the Good Old Days, RT code was packaged as an .LLB and saved on the PXI.  It could then be started with a VI Server call (assuming that it was "sitting idle" and not running at the time).  More "modern" practice seems to be to build the RT code as an "RT Executable", .rtexe, with the idea that this starts when the PXI starts because it is configured to run at StartUp.  These RT programs usually reboot the Target when they exit, so they'll be "started" again automatically.

 

I've actually got to run to a class, but if you can provide a few more details (such as the version of LabVIEW, whether the code is an LLB or an RTEXE, etc.), I'll answer this evening (if noone chimes in earlier).

 

BS

0 Kudos
Message 2 of 17
(4,726 Views)

Thanks, Bob.

Ideally, the question is very general.   E.g. it would be great if NI had a KB article on how to do this for various targets and various versions of LV.  (I would have thought that this would be a pretty common feature request...)

Specifically, I am using LV 2013.  The target is a cRIO-9074.

 

Regards,

    DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 3 of 17
(4,723 Views)

Well, I have been wrestling with this, myself.  My current RT routine, built with LabVIEW 2012, uses an RTEXE on the RT side, and currently ends with the RT doing a reboot of itself to reload.  I'm trying to modify it so that it simply returns to a "resting" condition, waiting for the Host PC to re-establish contact.  I'm using Network Streams for communication, with the "engine" on the RT side.  

 

A related problem that I haven't satisfactorily solved is how to "pick and choose" from a variety of RT routines.  Clearly one can run multiple Host routines (simply call them up and hit "Run"), but short of re-deploying, how can you (at Run Time) designate the corresponding "multiple RT Targets" that go with the particular Host?  [Of course, in Development Mode, I can simply do the deployment, but this doesn't work well "in the field"].

 

Haven't come up with a solid solution yet.  Some ideas include something akin to a loader on the RT side that communicates with the Host and "plugs in" the appropriate RT code.  Another possibility is to have the Host fiddle with the RT Configuration File to designate one of several RTEXE routines as "Start-Up", then reboot the PXI.  In any case, nothing "elegant" suggests itself.

 

BS

0 Kudos
Message 4 of 17
(4,698 Views)

Bob,

    I haven't used VI server on an RT target, but it apparently is supported.  How about writing a small "control" program that runs on the RT at boot-up, and which looks at a shared variable or a file token to determine the name of an RT LV program it should run?

    In my case, I really just want to reconnect to the RT VI that is already running.  I often want to debug it, probe it, watch the indicators, etc., without interrupting it, hence without restarting it.


DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 5 of 17
(4,689 Views)

... there was a fairly simple mechanism for reconnecting a front panel on your desktop to the copy of that VI that was already running on the RT target.  Either that method no longer exists, or I just can't find out what it is. 


I'm using LV2012, but it works as expected. When a RT VI is running on the RT target and my VIs have not been modified, I can reconnect to the RT VI.

I know 2 methods to do this:

1) just click the run button on the main RT VI

2) right-click the target in the project and select "Connect"

 

Both methods work fine for me in LV2012.

 

What do you get when you try these methods?

 

0 Kudos
Message 6 of 17
(4,670 Views)

Hi DaveT,

 

Have you tried this?

 

From a LabVIEW menu: Select Operate -> Debug Application or Shared Library

Enter IP address (NOTE: You have to press Enter - clicking off doesn't work!?)

If startup.exe shows up, it found the cRIO.

Press Connect

 

The RT app must be built with "Enable debugging" selected (Advanced menu in Build Properties).

 

steve

----------------------------------------------------------------------------------------------------------------
Founding (and only) member of AUITA - the Anti UI Thread Association.
----------------------------------------------------------------------------------------------------------------
0 Kudos
Message 7 of 17
(4,662 Views)

Bob,

 

> Well, I have been wrestling with this, myself. ...

 

I'm a fan of Network Streams, so at the risk of hijacking the thread, I'll chime in on your post.

 

For my systems, the RT software has three main loops.

 

  • State Machine Loop - Instrument Control and Monitoring
  • Command Stream Loop - Network Stream Reader - Gets commands (with optional data) from Host
  • Data Stream Loop - Network Stream Writer - Sends data from instruments and status info

The State Machine has two states: Safe and Run. At startup or if a Network Stream is lost, it goes to the Safe State.
If the Network Stream Loops lose connection, they loop on trying to reconnect.
This keeps my hardware in a safe state and the RT code ready for commands when the Host connects.

 

To relate this to your example, you could have a common command in each RTEXE that can load a requested RTEXE and reboot.

(I haven't looked at the mechanics of what it would take to make this work.)

 

steve

----------------------------------------------------------------------------------------------------------------
Founding (and only) member of AUITA - the Anti UI Thread Association.
----------------------------------------------------------------------------------------------------------------
0 Kudos
Message 8 of 17
(4,649 Views)

To relate this to your example, you could have a common command in each RTEXE that can load a requested RTEXE and reboot.

(I haven't looked at the mechanics of what it would take to make this work.)

 

steve


Well, I did, but I wasn't clever enough to think of doing this on the RT side.  I also wanted to avoid the downtime involved in the reboot operation.  My solution was PC driven, which meant that I had to get the appropriate file from the Target via FTP, modify it, FTP it back, then get the Target to reboot.  Obviously simpler if the Target handles the modification of its own file ...

 

So here's the "magic".  On the Target, there should be a file C:\ni-rt.ini that has information on the Target system and software.  [This is certainly true on my PXI controllers, and I presume RIOs are the same].  In section LVRT, key RTTarget.ApplicationPath should contain the name of the RTEXE that runs when the system is rebooted.  In my case, I built an RT Executable and said "Run as Startup", so my file contains the following:

 

RTTarget.ApplicationPath=c:\ni-rt\startup\S-Lab 2_0_0\S-Lab RT 2_0_0.rtexe

 

[I chose to put my Startup EXEs in their own folder(s) at Build time]

 

Now all you need to do is to call the Restart VI on the Target.  Of course, this is buried -- look in Measurement I/O Palette, System Configuration, Software, and there is Restart.  I wire a Constant to the Session In connector and set it to "localhost", and it works fine.

 

Bob Schor

 

0 Kudos
Message 9 of 17
(4,639 Views)

Dan_u,

    I thought I knew the answer to your question, but I wanted to be able to try it first and make sure of what I was seeing.  Here's what I find:
    In my current situation, the VI is NOT loaded on the RT as the startup executable.  I open it from the project and run it each time I power on.  In this case:  I run the VI once.  Leave it running on the RT but close the panel on the host.  If I run the VI on the host again, it starts over.  (Oddly, I expected it to complain that there was already something running on the target, but it did not.)  If I just disconnect the RT from the project, then right click and select Connect, it connects, but the VI does not start running.

    E.g. I don't see either of your methods working.  This is in LV 2013.  Could that be the reason, or is it because you are dealing with a start-up executable?

Thanks,

    DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 10 of 17
(4,536 Views)