LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reconnect to a VI running on an RT Target

Dave,

I also used that setup. I started a RT VI from the project, then disconnected. When I either connect again or press the run button on the RT VI again it successfully connects to the deployed RT VI. I don't have LV2013 (or 2014), so I don't know if something behaves differently.

Of course if I modified the RT VI in the meantime I will get a dialog asking if I want to cancel the connect operation or deploy my modified VI.

 

When you close the RT VI panel on the host, I guess you disconnect from the RT before? Otherwise probably closing the panel will stop execution. Are you sure the RT VI is still running when you close the panel?

 

Daniel

 

0 Kudos
Message 11 of 17
(1,642 Views)

@Dave_Thomson wrote:

<del>
    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


Steve mentioned already about the remote debugging, and I have used it also many times. Unfortunately it doesn't help always, because it changes the execution speed of your code, and you cannot see how things happen in real.

Take a look at the Real-Time Execution Trace Toolkit. I think it comes with LabVIEW Real Time at no additional cost. I use also log files for debugging during development time and 'Conditional Disable Symbols' in order to disable the log functionality for production executables.

 

0 Kudos
Message 12 of 17
(1,634 Views)

@Dave_Thomson wrote:

    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.


In your situation, it sounds like you have the following scenario:

  • You have a program "always running" on the RT Target, which you (normally?  always?) start before the Host code.
  • Stopping the Host code does not stop the program on the RT Target.  This allows the Host to restart and "resume the dialog" with the Remote.

If this is true, this explains everything you've said, above.  [I'm a little confused by "If I run the VI on the host again, it starts over" -- I assume "it" refers to the Host program, not the Remote].

 

In an early stage of my current RT project, I tried to "have my cake and eat it, too" -- I developed some code that would force-deploy the RT code to the Remote and start it running (with VI Server) -- it was very messy, tempermental, and prone to failure, not something you'd want Users (meaning not LabVIEW Gurus) to handle.  It also didn't allow executables easily, so I gave it up.

 

BS

0 Kudos
Message 13 of 17
(1,624 Views)

@dan_u wrote:

Dave,

I also used that setup. I started a RT VI from the project, then disconnected. When I either connect again or press the run button on the RT VI again it successfully connects to the deployed RT VI. I don't have LV2013 (or 2014), so I don't know if something behaves differently.

Of course if I modified the RT VI in the meantime I will get a dialog asking if I want to cancel the connect operation or deploy my modified VI.

 

When you close the RT VI panel on the host, I guess you disconnect from the RT before? Otherwise probably closing the panel will stop execution. Are you sure the RT VI is still running when you close the panel?

 

Daniel

 


Same for me, when in the dev environment. I actually just recetly learned this trick. They key is connect/disconnect from the project.

 

However, I know the feedback has been given back to NI that this is a BIG gap between PLC programming and LabVIEW programming. They see their cRIOs as potentially being a PLC competitor. But the lack of consistency in how connecting to the application will actually function, along with the fact that changes can't be made in real time without a complete stop and redeploy will keep this from being fully competitive for the time being as far as I can tell. Ok, my segway is done.

0 Kudos
Message 14 of 17
(1,619 Views)

Sorry for the confusion.  I'm afraid I haven't quite explained my use case adequately.  I actually have two use cases, which are slightly different...

 

1) The RT program is not set as Startup on the cRIO.  I open the project.  I open the RT program.  Run it.  It connects and runs.  I open and run the Host program.  Everything is running.  Now if I close the RT program window on the host, the RT program on the cRIO stops running.  This is the system I have now in front of me and I finally was able to verify this for sure.  I thought the RT program would continue to run on the cRIO, but the data stops coming in to the host program, so I now believe that closing the VI windows stops the program on the cRIO.  Hence this use case no longer fits my original question.  There is no need to re-connect to the RT program, since it isn't still running.  If I restart it, it restarts on the cRIO.  (Note that I never disconnect from the project.  That would also stop the data from coming over from the RT program on the cRIO.)

 

2) This is the interesting use case, but unfortunately I don't have access to it right now to test and verify.  In this case, the RT program is set to run as Start-up on the cRIO.  So the steps are:  Power on the cRIO.  The RT program starts running.  Run the host program.  It is getting data from the RT program.  But now I want to debug the RT program.  If I open the RT VI on the host and run it, it warns me that it will stop running the program on the cRIO.

 

   I think that this second use case is actually making sense.  It isn't just a VI running on the cRIO, it's a compiled startup program.  So I would need to use the earlier-mentioned mechanism for setting "allow debug" in the executable, then connect to the executable in debug mode.

 

   I hope that is making more sense.  I think everything is explained, and I'm not missing any option to "reconnect".

 

Thanks for the feedback.


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 15 of 17
(1,588 Views)

I was referring to your case 1. If you close the FP of the RT VI it will stop execution. But if you just right-click the target in the project and select "Disconnect" (while the RT VI is running) the RT VI will continue to run and you will continue to get data. This will NOT stop execution.

In this case, clicking the run button on the RT VI or connecting to the RT target from the project will connect to the running RT VI.

 

I don't have experience with case 2.

 

0 Kudos
Message 16 of 17
(1,556 Views)

Thanks.  That does make more sense.  I tried it out this morning and (mostly) got it to work.  When I run the VI again after disconnecting from the project, the deployment window never completes.  E.g. after a few minutes, the VI becomes live and has data in it.  But the deployment window hangs.  I hit cancel, and got the deployment window to leave, and the VI was still running.  So it works, I guess, but I find that to be odd behavior.

-------------------------------------------------------------
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 17 of 17
(1,506 Views)