LabVIEW project deployment from VI and/or executable

[Bill in Phoenix]

Various PXI chassis and controllers

LabVIEW Professional Development System

LabVIEW 2010 Service Pack 1

We have a couple of PXI chassis that are running LabVIEW RT. When we finish the engineering of our products, we will be installing this PXI/LabVIEW RT setup in our manufacturing environment. We also have people inIndiathat work, remotely during our night time, using these PXI chassis. I have built and installed my LabVIEW RT module as an executable on the PXI controller to automatically start on reboot. If no one attempts to load any other code on the PXI controller, I can reboot the PXI controller and my PC software still communicates with the RT software using TCP/IP. In the mornings, my PC software will not be able to communicate with the PXI controller. I do not know if the people inIndiaare doing anything that would cause this. I have found that if I open my project, go to my “Build Specifications”, and “Run as startup” to redeploy the software, it will again work. We have many engineers working on various parts of the project. I am not always here to assist them in the method of redeploying the software. I decided to attempt to write a LabVIEW VI which would deploy the software for them. This will only work on the test PC that has LabVIEW installed. I am enclosing what I have completed to date. I have a couple of issues that I would like to ask about. I might mention that since we have multiple PXI chassis/controllers, the software will find all of them on the network and then set the project to point to the PXI chassis/controller being requested.

1. Is there a simple way to perform the “Run as startup”, “Deploy”, “Set as Startup”, etc functions that are shown in project through a LabVIEW VI passing the IP address and location of the project file to the functions?
2. I have noticed that when I am in LabVIEW development mode the “Project.Open” method will work correctly. When I run it from an executable, I will get a file not found type error. I put in a popup window that would show the project file path that the executable would use and it is correct. I am unsure why this behaves differently.
3. Looking at the “Deployment Progress” window created by project, I attempted to perform the same functionality or so I hope. Although there seems to be differences between yesterday and today. See enclosed JPG files. I did determine how to get a list of the libraries. However, when I attempted to deploy them, some failed because they were part of an “.LLB” file. Once I removed those libraries, the deploy libraries worked.
4. Lastly, I got my main RT VI and then found all subVIs.I am able to deploy them without issue. I am not sure if I have everything deployed. This is why a simpler function to just execute the functions as they appear in project would be helpful.

Thank you for any comments, opinions, or ideas that you have on this subject.

Bill

[Bob_Schor]

I've got a related question.  I've "inherited" a Real-Time system written in LabVIEW 7, well before Project.  We would build an executable on the PC for the PC part.  For the PXI part, we'd "target" the PXI, open the top-level VI destined to run on the PXI, do a "Save with Options" to make it into an LLB, then FTP this to the PXI.  It was not set to run as a start-up VI -- instead, we used VI Server (from the Host PC program) to start it running.

I've recently been working on re-designing this application and running it on LabVIEW 2010 or 2011.  I've used Project to separate the Host and Remote parts of the code, and have successfully run it after "hand-deploying" the Remote code to the PXI.  What I'd like to do is something similar to the method we used in LabVIEW 7, namely build an EXE for the Host, build a <Something> for the PXI, FTP the PXI code, then use VI Server to start the PXI code running.  I'm not sure, however, just what the <Something> should be!  It doesn't really make sense to use an LLB, does it?  I've seen references to Packed Libraries, but haven't found a good discussion or tutorial to give me guidance.  I'll try to keep an eye on this thread ...

Bob Schor

[Bill in Phoenix]

Bob,

You probably have already found this on the NI site, but you might want to read the LabVIEW Real-Time Module User Manual, Getting Started with LabVIEW Real-Time Module, and any others that you can find.

My code must communicate with Analog Inputs, Analog Outputs, Discrete I/Os, ARINC 429 (Ballard and/or Condor cards), LVDTs, and CAN for now. I use configuration files to define what each system will be using making my software very flexible in adapting to the PXI configuration. Due to the production environment, we do not want LabVIEW on all of those stations. I built stand-along executables for the PC and RT systems. We can then put the LabVIEW run-time engine on the production PCs saving us a lot of money on licenses. This also keeps the production people from messing with the code. I have separate modules that all connect to the PXI chassis using TCP with different port numbers for each type of IO equipment. On the RT system, I have a module for each of type of IO equipment. The RT module creates a listener to wait for a connection from the PC or multiple PCs should that situation happen. You have to keep track of that within the software. Then, when the RT module gets a message from the PC, it will process the message and return any data, if that was what was requested. When running as a RT executable, you would need to go into the bios of the RT controller during boot-up and set the flag that allows the startup executable to run. The documentation for the controller will tell you how to do that. As long as no one messes with the code on the RT system, every time you cycle power, it will run your executable. Your software, on both ends, must be able to handle network drops or network slow downs. There are different types of communication protocols to use. It would be your decision on what you believe will work best in your situation.

I hope this helps.

Bill

[Che_T. · Accepted solution]

Hi Bill,

Without knowing what your colleagues are doing, it may or may not be expected behavior that you're not able to reconnect to it.  However, it seems like your workaround is to redeploy the executable.  Information on how to do that can be found at the following links:

For an executable

http://digital.ni.com/public.nsf/allkb/9794D5D24933FD31862572C60052FA1A?OpenDocument

For a VI

http://digital.ni.com/public.nsf/allkb/A7DBA869C000B5AE862570B2007C4170?OpenDocument

I would recommend checking to see if you can ping your target in the morning if you're not able to connect to it.  If you cannot, then it's possible that thread starving is occurring and all network communications are sluggish or dead.

Regards,

[JonP]

Bill, sorry to drag up this old thread but you touched on a problem that I too am seeing:

2. I have noticed that when I am in LabVIEW development mode the “Project.Open” method will work correctly. When I run it from an executable, I will get a file not found type error. I put in a popup window that would show the project file path that the executable would use and it is correct. I am unsure why this behaves differently.

Did you ever find the reason for this? It is happening in LabVIEW 2015 with me, as you say it runs fine from the IDE but if I build the code into a LabVIEW DLL and try to call it from a .exe on the same workstation I get a file not found error with exactly the same path to the lvproj file. I am assuming the runtime engine handles this call differently in some way.

[Bob_Schor]

I apologize for not following up on my Post of almost seven years ago.  About two years after that Post, I had found a way to deploy my Real Time Project as dual Executables, an EXE that ran on the Host, and an RTEXE that ran on the PXI Target, set to Run as the Startup Application.

As it happened, I had LabVIEW 2012 (later updated to 2014) installed on the Host, connected via a dedicated line to a second NIC on the Host with an IP in the non-routable 10.0 sub-net to the Target PXI, so it appeared in the Project. 

The Build Spec had the following settings:

• Information page
  • Target Filename:  S-Lab RT 2.3.rtexe
  • Local Destination:  C\Users\Public\Documents\S-Lab Builds\S-Lab 2.3\S-Lab\S-Lab RT
  • Target Destination:  c:\ni-rt\startup\S-Lab RT 2.3
• Source Files -- S-Lab RT.vi is the only entry, in Startup VIs
• Destination -- Label and Path same as on Information Page
• Other choices left as default

After Building, I did a Deploy and set it to Run at Startup (of the PXI).  The RT Code, itself, was set so that when the Host exited, the Target code also exited, with the last VI being a request (using the Restart VI) to reboot itself.  I also wrote a "Reboot" TimeStamp into a Reboot Log on the PXI as a record of the Restart (why not?).

I hope this answers your question.

Bob Schor

[JonP]

Bob, that is useful information in the context of the overall thread but not to me, as I am interested in whether Bill (not Bob!) found the answer to the subsidiary problem he found, see bullet point 2. in his original post. I am not even using LabVIEW RT (thankfully ).