From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
09-08-2015 06:22 PM
When I right click my RT target in Project Explorer and select connect I get the same conflict error as the one in this article.
"This VI is part of a Real-Time Startup Application. All VIs on the target will be closed if you choose to apply and continue with deployment."
However, already have Disable Autodeploy Variables checked. I just want to connect to the startup application, not reset and redeploy. Why is this conflict happening?
Solved! Go to Solution.
09-08-2015 08:28 PM
That KB is talking about how to connect to the RT VI from your Host VI. Every step is discussing how to use the Host VI. You don't need to connect to the RT target in your project to do this. You just need to set up your architecture in a way that your Host VI can talk to the RT Target and allow the RT Target to run autonomously when you're not connected with the Host VI.
What is it you're actually trying to do? If you give us an idea, we can help you figure out a way to setup your application to do that. If you just want to connect to the project, you'll need to do as the dialog claims.
09-09-2015 05:51 AM
I'm not sure if you can connect to a RT vi that is already running like that. When I need to do this I re-deploy the RT exe as "Do not run as startup" then open the RT vi from the project and hit the run button from there.
I would be interested if there is a different way of doing it though...
09-09-2015 09:21 AM
Clicking "Connect" connects (duh!) your PC's "idea" of what the RT system is/should be doing with the RT system which may or may not be doing the "expected" thing. The "model" of the RT system on the PC, exemplified by settings in the Project, needs to be correct -- what the "Error Message" is telling you is that there is an inconsistency, and inviting you to correct it. Once you do that, the next Connect should be OK (unless you change the model on the Host, or on the Remote, for that matter ...).
Bob Schor
09-10-2015 10:47 AM
@natasftw wrote:
What is it you're actually trying to do? If you give us an idea, we can help you figure out a way to setup your application to do that. If you just want to connect to the project, you'll need to do as the dialog claims.
I was hoping I'd be able to connect and see the startup VI front panel. I want to see the status of the VI's I set as "startup" in the RT. I'm having trouble talking to them via the psp shared variables that they are supposed to be serving.
@toddy wrote:
I'm not sure if you can connect to a RT vi that is already running like that. When I need to do this I re-deploy the RT exe as "Do not run as startup" then open the RT vi from the project and hit the run button from there.
I would be interested if there is a different way of doing it though...
If that's the only option then I guess I'm fine with that. I just couldn't find any other information on this conflict error.
09-10-2015 11:47 AM
When you run an RT application, or set VIs to run at startup on an RT target, you cannot connect to the RT target within the development environment without stopping the application or those VIs. You can, however, configure the RT target to share a remote front panel, and connect to that. You can also enable remote debugging.
I hope one of those links helps answer your question; please post if you need further clarification.
09-10-2015 12:45 PM
Aha! Thanks. I have been using other debug options, namely RT Debug String.vi to find my real problem: I needed to set the "Disconnect Type Definitions" option in the build settings as stated in this KB article. Otherwise the VI will not run as a startup executable. There should be some sort of error or at least a warning during the build process when this option is not set while targeting RT, don't you think?
09-10-2015 01:11 PM
@Eric_Pope wrote:
Aha! Thanks. I have been using other debug options, namely RT Debug String.vi to find my real problem: I needed to set the "Disconnect Type Definitions" option in the build settings as stated in this KB article. Otherwise the VI will not run as a startup executable. There should be some sort of error or at least a warning during the build process when this option is not set while targeting RT, don't you think?
What version of LabVIEW are you using? I've never run into this particular bug, maybe I got lucky that I wasn't working on any RT targets in the affected versions. While I'm not currently working on any RT projects to confirm, I'm fairly certain that I have used type definitions in real-time applications in the past few years without checking the Disconnect Type Definitions option and without having problems.