LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Startup of Real-Time process

Solved!
Go to solution

I have 2 questions related to LabVIEW Real-Time. I am using LabVIEW 2010 Service Pack 1. We have a PXI-8186 embedded Controller running the Real-Time.

 

1) I have my software written to communicate using TCP/IP. The real-time software runs the "TCP Create Listener" and then the "TCP Wait on Listener" to look for connections from the PC. This all runs fine within the LabVIEW project. I then build the executable and deploy it to the real-time system setting it up to run during startup. I set the target name to be my program name "Test program.rtexe" rather than the "startup.rtexe". I am not sure if that makes a difference. I did see other files in the startup folder on the real-time system that were named something else. My question(s) are: can the name be any name that we want and does the real-time system execute all programs contained within the startup folder or is there some other method needed to indicate which programs to execute?

 

2) Is there a way to monitor or view what programs are running on the real-time system? Like the Task Manager on a windows system. The reason that I ask is that after I reboot the PXI system and without using the project program, I can not establish communication with my test program running on the real-time system. I am not sure if the software is running on the real-time system, if it established the network interface that it was suppose to, etc. to determine why I can not communicate with it. Any help on various methods to determine if the software is actually running would help.

 

Thank you for any and all help that you can give.

 

Bill

0 Kudos
Message 1 of 9
(3,371 Views)
Message 2 of 9
(3,363 Views)

Thank you for the information. I did check the things that were mentioned.

 

[LVRT]
RTTarget.ApplicationPath=/c/ni-rt/startup/my_startup.rtexe
RTTarget.LaunchAppAtBoot=True

 

My "RTTarget.ApplicationPath" file name did contain a space character within it. I put double quotes around it. Everytime that I would build and deploy it, the variable would be set back to the filename with no quotes. I changed my file name to a name without any spaces in the name. I do not know if that would be an issue or not.

 

I was able to output the time using UDP and capture that on the PC. I attempted to look at the TCPIP code and eventually forgot how I got the UDP to work and now it will not work. So, I believe the problem is that I do not have the TCPIP set up correctly on the RT stand alone system/module. My belief in this analysis is based on:

 

1. The software runs correctly when everything is executed within the project.

2. If I run the real-time module within project and run the PC side stand-alone executable on my PC, that works. I would believe that the PC executable is working correctly.

 

The only problem is when I attempt to run both the stand-alone executable for my PC and the stand-alone executable on the RT system, they do not like each other.

 

I have been developing LabVIEW for 15 years. I am new to the Real-Time system/module. I do not understand exactly how that needs to be setup to execute TCPIP correctly. The system was setup by someone else and since I am a contractor, they will not give me Admin priviledge on my PC. So I do not know if either of these systems were setup correctly,

 

Any help that you can give on exactly what needs to be configured on the RT system to make sure TCPIP runs on it would be helpfull.

 

Thank you,

 

Bill

0 Kudos
Message 3 of 9
(3,352 Views)

As you saw, the name should be dependent on the .ini file path that was created when you built the application.  Check what the path of the exe in NI-RT.ini.  It should look something like:  

RTTarget.ApplicationPath=c:\ni-rt\startup\startup.rtexe

RTTarget.LaunchAppAtBoot=True


The only vi that will be executed will be the one that is named in the .ini file.  It will run any subvi's that are present in that startup vi however.

 

To track your VI's running on a RT target you can use NI Real-Time Execution Trace Toolkit

 

I would suggest using the following example to make sure that communication is occurring correctly between your host and target.  In LabVIEW go to Tools >> Example Finder.  In there select Addons and Toolkits >> Real-Time >> Network Communication >> TCP Communication.lvproj      

Scott A
SSP Product Manager
National Instruments
Message 4 of 9
(3,318 Views)

I cannot figure out how to make the    Real-Time Execution Trace Toolkit (LabVIEW)   work. I open the sessions listed but the show some other IP address. I am not sure how to look at my RT system. I did modify the project file in the ...\examples\tracetool with the correct IP address but could not get that to work. This seems to be another of those useless tools and drivers that NI got free from some user and now promotes as their own.

 

I tried the examples that you mentioned. They work fine within project. When I build the executables and then deploy them, I get the following error on the PC side. This is doing the same thing as my code.

 

Error 63 occurred at TCP Open Connection in TCP Communication - Host.vi

0 Kudos
Message 5 of 9
(3,313 Views)

Hey there,

 

So to make use of the Real Time Execution Trace Toolkit you have to add the Execution Trace Tool VIs to capture the timing and execution data of VI and thread events for applications running on an RT target. The Real-Time Execution Trace Tool displays the timing and event data, or trace session, on the host computer.

 

The following article may help with the error you are getting Error 63 Using VI Server to Launch VI on Remote Machine  The right permissions need to be granted so that the Host and Target can communicate to each other.  Also firewalls can interfere with this communication so you may need to allow exceptions if you have a firewall present.

Scott A
SSP Product Manager
National Instruments
Message 6 of 9
(3,310 Views)

Thank you for the information.

 

The link that you gave and the links contained within that page are from LabVIEW 5.1, 7.?, etc. While some of that may still apply, I did not find anything that helped the issue.

 

At this point I am going to quit working with on this. I will tell these guys that they will need to purchase a LabVIEW license for each of the manufacturing stations that they plan to build. They will not be happy, but there seems to be something lost in the translation when even the NI engineers can not explain what might be going on.

 

 

If anyone ever determines how to get stand-alone executables, with TCPIP on the real-time system, working, please pass that along for all future folks going that route.

0 Kudos
Message 7 of 9
(3,294 Views)

The TCP Communication example which can be found in LabVIEW under Help >> Find Examples >> Toolkits and Modules >> Real-Time >> Network Communcation should let you have a easy way to deploy and communicate to your real-time target.  If you are unable to get that example working after building the stand alone executables please let me know.

Scott A
SSP Product Manager
National Instruments
Message 8 of 9
(3,284 Views)
Solution
Accepted by topic author Bill in Phoenix

Finally found the problem.

 

It would appear that, at least in the 2 embedded controllers that we have on site, the controllers have a flag in the BIOS that will disable the startup file from executing on the real-time system. Once I set the flag to "NO", everything works. The flag is named:

 

"Disable Startup VI" under the "LabVIEW RT" tab in the BIOS.

 

This is a good option if the startup VI becomes corrupted or was not debugged before deploying.

 

0 Kudos
Message 9 of 9
(3,277 Views)