08-26-2011 04:20 PM
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.
Thank you for any comments, opinions, or ideas that you have on this subject.
Bill
Solved! Go to Solution.
08-26-2011 04:48 PM
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
08-26-2011 05:44 PM
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
08-29-2011 03:34 PM
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,
04-19-2018 08:09 AM - edited 04-19-2018 08:10 AM
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.
04-19-2018 10:31 AM
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:
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
04-19-2018 10:38 AM
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 ).