LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Building and Deploying Real Time Application

Hi everyone.

 

I am trying to use deploy a Real-Time application to the cbRIO-0651 but I am getting this error. When I click "ok" the VI runs but it reads a constant 0 signal rather than the sine wave it should be reading from the Real TIme VI

 

NI Conflict Resolution.png

Download All
0 Kudos
Message 1 of 8
(4,103 Views)

It just means you already have a deployed application. It's a warning in case you accidentally overwrite an application already deployed to the RT controller. Any action that changes the code which is already running on the controller will cause that warning (e.g. running interactively, deploying a new RT executable etc.).

 

Note that you can only have 1 VI running on the controller at a time (either by running interactively or as the 'Startup VI' of your RT executable).


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 8
(4,090 Views)

The conflict message is normal and nothing to worry about.

Your target is set to autoexecute a program on startup, and this is a warning that you will interrupt that and start running your new program.

 

That is normal behavior.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 3 of 8
(4,088 Views)

The problem I am getting is that the program is supposed to be bringing sine wave data from the RT device to the host VI on my PC.

 

It works when I open them up and run them.

 

But when I got to the section of the tutorial about using application build and deployment, rather than seeing a sine wave I am seeing a constant "DC" value. Its not on zero so it must be reading a value but it's not a sine wave.

0 Kudos
Message 4 of 8
(4,024 Views)

It's not the warning that's your problem.  Your code just doesn't work.  You'll want to focus on why that is rather than worry about the warning.  Don't let the red herring mess with you.

Message 5 of 8
(4,010 Views)

Ok but where might the problem be? If I run the code on the RT and then run the host VI code it works fine. Its only when I try to deploy the code to the RT as a Real Time Application under build specifications that I get the problem.

0 Kudos
Message 6 of 8
(3,990 Views)

Try some basic debugging techniques.

 

In your RT program, disregard the measurement and set the variable result to 123.456.

Does your host see the value?

Yes:  host <-> RT is ok, look for a measurement problem.

No: problem in host <-> RT link - maybe addressing is wonky because of RTEXE vs. .VI

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 7 of 8
(3,980 Views)

When you build an RTEXE, you have several things you can do with it from the Project.  First, you can Deploy it.  This means it gets transferred to your RT Target and put somewhere (you decide where when you build it).  Next, from the Project, you can Run it.  This (obviously) starts it running, and, in your case, generating a signal to send to you.  Finally, you can set it so that it automatically runs when you start the RT Target.  I'm guessing that this is the step that you missed.  If you do this final step, then every time you turn your RT Target on, your code starts running, generating signals, etc., and whenever your Host program starts, hey, there's a signal coming from my Target.

 

See if this applies to your situation.

 

Note that this implies that an RT Target, by design, only does "one thing" when it is turned on, namely it runs whatever (single) RT Program you told it to run.  If you are coming from an older pre-Project version of LabVIEW (such as LabVIEW 7.0) where the Host could "connect" and start one of a number of RT .llbs (there were no RTEXEs) using VI Server, this "lack of run-time choice" might seem something of a bummer (it drove me crazy trying to make the leap with a large Experiment Control routine I was trying to "modernize").  I really wanted a choice at run-time for the code running on the Target.  

 

This seems to be a Design Choice that NI made, one I've come to live with and respect.  We still deploy multiple RTEXE's to the Target, but I have a routine now that I run on the Host that presents me with a list of options that could be the Start-up code running on the Target.  I choose one of them, it basically changes the Target's .ini file to make the selected RTEXE the start-up code, then reboots the Remote.  Fortunately, RT controllers no longer use floppy drives as their boot medium, so within 15 seconds or so, it is running the chosen routine.

 

Bob Schor

Message 8 of 8
(3,966 Views)