LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT——what's about the VI running in degug mode

I have a puzzle:   what's about the differrence between [Debug] mode and [Stande alone] mode ? Because of my working,  I need change the RT programe very often, so i would not like to run the RT programe in [Stand alone] mode   Will the [Debug ] mode influent the RT programe's efficecy???

0 Kudos
Message 1 of 4
(2,908 Views)

 I'm not completely sure I understand your question, so this answer might not be appropriate.

 

If you are developing a LabVIEW-RT program, you should be working in LabVIEW Project, running on a PC (or possibly a MAC, but I have no MAC experience).  In your Project, part of your code will live in the "My Computer" section -- call this the Host code.  The rest will live in what I'll call the "Remote" section, the section that is connected to your RT system.

 

When you are developing, you can test your Remote code in a manner similar to how you'd test Host code.  You Deploy it to the Remote system, then (on the Remote System part of Project) you open the VI you wish to monitor.  When you deploy it, it is not (yet) running, but if you go to the Front Panel of the top-level Remote VI, you can click the Run button and it will start to execute.  You can place probes, breakpoints, set Highlight Execution, etc.  You need to be aware, however, that anything that shows on your Host display requires TCP/IP traffic to the Remote, so the Remote might be running much more slowly.  However, if you are viewing something that only updates a few times per second, that should be less of a worry.

 

Another "trick" you can use is to not monitor at all, but to create a log file (I call mine a Debug file) that writes whatever you tell it to a log file on the remote.  It should be possible to write simple records without taking appreciable time from the Remote (less than 1 millisecond/write), and if you place the Writes where you think you are having trouble, you can potentially "catch" the problem as it occurs.

 

Bob Schor

0 Kudos
Message 2 of 4
(2,894 Views)

@Bob_Schor wrote:

Another "trick" you can use is to not monitor at all, but to create a log file (I call mine a Debug file) that writes whatever you tell it to a log file on the remote.  It should be possible to write simple records without taking appreciable time from the Remote (less than 1 millisecond/write), and if you place the Writes where you think you are having trouble, you can potentially "catch" the problem as it occurs.


Another trick (assuming your RT system has a serial port) is to use the console output of the RT.  This will allow you to send serial messages to give ideas of what is running, timing, random "probe" values, etc.  This will save you the hassle of using WebDAV or FTP to get the "debug" file, you just need a serial port and something listening to it to get your data.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 4
(2,879 Views)

Thanks for your reply still

I mean that: 

When i finish my RT progame development work,   

——I do not deploy the VI to the RT, which need  define a   startup vi (when the RT powered up the VI will begin run on……)

——I just run the VI by clicking  the RUN BUTTON ICON on the panel or pressing keyborad CTRL+R

 

Now i want to know :the VI's running performance will degrade contrast to deploying the VI to RT and starup th VI by powering up the RT

0 Kudos
Message 4 of 4
(2,809 Views)