Merging Host.vi and RT.vi in a single GUI

[barido]

Hi guys,

I am working on a project right now and I need some help.

My aim is to combine the RT.vi file and Host.vi file in a single .vi (or GUI) file to establish a user-friendly interface. I am using cRIO-9022 for the Real-time measurement and I also use an FPGA interface. I either need to open up the file from host side or RT side.  When I use OpenVI Reference on RT side to open up the file in Host side, I get a warning like this:

which makes no sense for me because I know the file is there.

When I use OpenVI Reference on Host side to open up the file in RT side, I get a warning like this:

When I checked online for solution of this error, they say that I should save the file before running which I do.

In addition, I scanned the internet to find out any other methods possible to combine these two files but it seems like this is the least messy way. I would be really grateful if you guys can suggest some solutions to either solve this error or provide any other possible method. In the end, what I would like create is something like this:

Two tabs coming from the host and one tab coming from the RT which executes each page regarding the open tab. I have to add the fact that I am not a really experienced user of LabVIEW so I would appreciate if you can explain any possible solution with a bit of detail. Thanks a lot.

Baris

[P@Anand]

I believe you are transferring the data from RT to Host and display. Your RT VI is resides in the RT once you deploy and you cannot call the VI directly. I would suggest you to create a display for the RT in the same Host and dispaly similar to the RT. You can either have it in the same VI or have a different VI in the host and use a sub panel to display its front panel. You can synchronize the RT GUI display with the actual RT VI based on its execution. In general RT is not meant for GUI display.

[barido]

Thanks for the reply P@Anand.

The thing is that I have to choose some parameters as inputs in the RT file. So every time I have to open it up and type the new parameters in and then run the file. So I don't think I can just create a display in the Host folder. But still I would like to know how exactly I can do the thing that you recommended. I am not really experienced with LabVIEW and I don't know how to design a display for the RT file in the Host folder. I would appreciate if you can elaborate more.

[Bob_Schor]

RT programs don't have a Front Panel, per se.  You can pass data to them, but generally need to do this through TCP/IP.  One of the Sample Projects that ships with LabVIEW shows how to do this, using Network Streams to implement a Queued Message Handler across the Host/Remote divide.

Bob Schor

[barido]

Hey Bob, thanks for the answer.

I partially solved the problem with the help of VI Server.lvproj in the Find Examples:

I created an Open VI Reference Function in Host.vi with type specifier VI Refnum which matches my RT.vi file. I added all the inputs and outputs from my RT.vi file to this Host.vi file. The problem right now is, this Open VI Reference works only if I run the RT.vi file once before running the Host.vi file. Once I run the RT.vi file, I can treat the section where I control the inputs of RT.vi file in the Host.vi perfectly. Otherwise, it gives me the following error:

I think this is because the RT device wants me to deploy the required files first or maybe there is some other reason. I spent all my day trying to solve this issue. I would be grateful if someone can help me out.

Baris

[crossrulz]

The RT code should be running on an RT target.  It does NOT run on your desktop (as much as people seem to think it does).  So VI Server calls should be be working here at all.  As has been said, you need to set up some sort of communcations scheme between your desktop and the RT target.  Network Streams seem to work the best in my experience.  With this setup, you send commands to the RT to set your parameters and another command to tell it to run.  You can use another command to tell it to stop (which should really just send it back to an idle state).

[nathand]

That's correct: when you start your RT target, there are no VIs loaded on it and no application running. You need to deploy the RT VIs in order to get them into memory on the RT target. Alternatively, you could build and deploy an RT startup application or startup VIs, so that your RT code would be running when you reboot the RT target. See these links:

Building and Deploying a Stand-Alone Real-Time Application (Real-Time Module)

Configuring Startup VIs on LabVIEW Real-Time Targets with a Source Distribution

Startup VIs vs Startup Executables on a Real-Time Operating System

[nathand]

---

@crossrulz wrote:

So VI Server calls should be be working here at all.

---

I think you meant to have a "not" in there, but that would make the statement incorrect. VI server works fine over TCP to an RT target.

[P@Anand]

---

@nathand wrote:

Alternatively, you could build and deploy an RT startup application or startup VIs, so that your RT code would be running when you reboot the RT target. See these links:

Building and Deploying a Stand-Alone Real-Time Application (Real-Time Module)

Configuring Startup VIs on LabVIEW Real-Time Targets with a Source Distribution

Startup VIs vs Startup Executables on a Real-Time Operating System

---

This what i would suggest. Generally we keep the RT code running all the but we execute the core part only when the Host communication is established and rest of the times it will execute in a low priority and wait for Host communication. In this way you don't have to worry about executing the RT code at all and Just start the Host and keep going. 

[Bob_Schor]

Sorry if this seems like a silly question, but are you developing your Real-Time Application using LabVIEW Project?  If so, do you have a Real-Time Target as part of your Project?  In my own RT Project, the top section of code is targetted in "My Computer", i.e. it is "normal" LabVIEW.  Any VI (and, in particular, the Top Level VI) can be "Run" from within the Project just by right-clicking and choosing Run.  In addition to that, I have a Build section where I can build a Stand-alone Executable that can run as a .EXE without opening LabVIEW.

In the lower half of Project Explorer, the RT Target is shown, and the code that will ultimately run on the Target is arranged in Virtual folders.  As with the Host code, I can right-click a VI and choose Run -- when I do, LabVIEW attempts to (a) connect to the RT Target, (b) download (or "deploy") the VI and all associated code to the Remote's memory, and (c) start running the code on the Remote.  As with the Host, the Build section lets me build a "Real-time Executable", an RTEXE file, that can be saved on disk on the Remote, and can be set to run as the Startup Executable when the Remote reboots (or boots the first time).

That's how I have my RT code configured -- the RTEXE runs when the Remote reboots.  The first thing it does is to fire up Network Stream "listeners" which (very patiently) wait for my Host application to "reach out and touch someone" (oops, I mean "initiate a Connection").  True, this could be days, but the Real-Time platform has nothing else to do ...

BS