LabVIEW
Steps to remotely develop, debug and compile to a Windows machine?
Hello Tobin,
It seems like the error you're experiencing might have something to do with the installer, which leads me to question that when you build the installer, have you ensured that the device compatible DAQmx drivers are installed alongside any other required drivers that are needed to allow the VI to operate successfully?
If so, what do you mean by they don't function properly? Are you given any error codes or can you just see no output on the device?
If this is quite a complicated VI that you're trying to install, is it possible that you could try creating a simple VI and installer for the remote computer to see whether or not you can get any I/O to work? This should give us a better idea about just where the problem could be however it seems it could be likely that there is some form of driver incompatibility with the installed program.
With respect to your ambition to remotely develop VIs in LabVIEW, would it be possible to make use of the Remote Desktop Connection program found in Start > All Programs > Accessories > Remote Desktop Connection? This program allows external, full control of a separate computer that has granted access. If both computers you're trying to develop on run Windows then this should be a simple solution for remote development. However, the computer you're assisting will need to have it's own copy of LabVIEW in order to develop any software.
@Tobin wrote:
Thanks for your reply Alex,
Here's some more detail. This application was originally created by someone else, so I am not intimately familiar with every part of the program. In my efforts to maintain the code, I've just made simple changes like a value here, a timer there, etc.
In my first attempts to modifiy the code, the target pc and hardware were in a different state (North Carolina), so I copied the code, modified and compiled it and sent back the exe. The person on-site reported that it wasn't working (no more detail). I tried replicating the directory structure on my pc and repeat the compile, but that didn't help. Ultimately, I connected to the target pc via remote desktop and used the target PC's development system to compile the exe. Since the development system must be removed from the target pc, remote desktop won't help anymore.
Because the original code is functional on the target machine, all of the needed drivers should already be present.
Even if I don't use an installer, I should be able to copy the exe from my computer to the target computer and run it. I think that any references to MAX hardware or tasks that exist on the target computer and not on my development computer are part of the cause.
If I compile on my pc, the missing hardware affects the compile result.
The target pc is on a production line and controlling the factory automation and DAQ. I won't be allowed to stop the production for some experimentation. because the development system is still installed, I can make a change in about 10 minutes.
I was hoping for a solution that would allow me to use my laptop computer with the development system to connect to the target pc and utilize the hardware that is connected to the target pc and run a debug session similar to what is done with an RT system on a PXI chassis. Compile the exe on the laptop and copy or install it to the target pc.
Tobin
Hi Tobin,
In order to properly understand whether or not it may be a problem with your build process, is there any chance you could take the original file and build it with no changes using the process you're using and then see if that works? If it doesn't, then it'd be useful to make a complete comparison of the entire working software to the software you've coded and see if you can match the project entirely. If you can build the VI using the same process and see it work back on the development computer, then there has to be something that could be mismatching what the hardware setup is expecting over in North Carolina. If the build fails using the exact same VI, then there has to be something we're missing on our end of the development.
In terms of the problems with it running on site, I think you'd need to discuss in greater detail with the on-site user about just what error is occuring.
You should try to find out:
- Are the installer guidelines being followed correctly? Is it being placed in appropriate directory, with the correct priveledges?
- Are any error dialogue boxes being returned at all, either during operation or during the installer stage?
- If the executable is running, what outputs can be seen? Is it nothing at all? Are any measurements being displayed, or any peculiar looking outputs?
Hopefully this will give us a much better idea of just what we're dealing with.
In terms of driver compatibility, you must ensure your VI calls the right version of drivers that matches the hardware being used. It'd be good to get a list of all of the hardware you need to interface with and ensure that the software you're producing is compatible.
It's also worth checking the possibility that a later version of the drivers could have been installed when you built your version of the program, and whether or not there could be an incompatibility since then. If it's possible for anyone on site to access the Measurement and Automation Explorer (MAX), tell them to E-Mail you a System Report by right clicking on My System and selecting > Create Report. The technical report option would be good in this instance. You may need to talk them through this process via telephone if they're not too computer literate. Hopefully this will give us some clues on what sort of development environment you should try to match exactly in your code; be sure that you're building to the correct version of the Runtime Engine they're using too.
Sorry about all of the questions, but there are so many possibilities with something like this, we have to account for everything.
As for testing hardware I/O on an external computer, if you could produce a VI with all of the functionality you'd require for test; so for example controls and indicators through to the hardware you wish to interact with, you could send this VI over and make use of remote Application Control. For this you'd need to make sure that they allow access to your computer to connect to it by configuring their Machine Access IP Address blocklist accordingly. They'll need to go to Tools > VI Server > Machine Access > Add and allow your IP address to connect through there. Because of Dynamic IP Address Allocation through DHCP, you may just want to let the machine allow access to all remote IPs (By adding a * as the allowed IP Address, where * is a wildcard), although this is dangerous as it will grant access to all external computers wishing to communicate with their VI Server.
Below I've created a simple example of how to Stop a Running VI on an external computer; you can modify this control to suit the VI you develop for testing. Ensure that you allow connections to be permitted to your computer for the initial localhost test (Leave the IP address control blank).
This VI made to blink a light:
Can be stopped by this VI that references it:
I hope you find this attachment useful; if you have a previous version to LabVIEW 2010 I'll downconvert it for you.
@Tobin wrote:
Alex,
Thank you for your detailed reply. I'll try what you suggest, but I think we may be getting away from my ultimate goal.
First of all, the target computer and the entire production line has been moved to our facility. I can take my laptop and walk out to the target computer. I want to connect a cross-over network cable from my laptop to the target computer to do my work.
When the target computer and production line was in North Carolina, the LabVIEW program was maintained by an outside contract firm. It is unclear at the moment if our company paid the contractor to transfer the LabVIEW license to us. Now that I am responsible for maintaining this program, I need to remove the development system from the target computer until we determine if we actually own that license.
Because this is on a production line, I must wait until the line is shut down because of a program problem, or a shortage of parts, or some other issue not caused by me.
I not looking for troubleshooting tips for why my code doesn't work on a separate computer so much as I'm looking for the standard procedure for debugging and compiling while connected to the target Windows computer and its hardware. Is it identical to debugging on an RT system?
Tobin,
In terms of debugging, there a couple of options that you could try:
- Export and Import MAX: To debug the target PC's system, you could try retrieving its exact settings in MAX and replicating them in your own computer. This will allow your development PC to simulate the test environment. On your target PC, go to MAX and right click on My System and choose Export. This will produce an .nce file which you can then import into your development system's MAX through the same menu. This will replicate the response and connectivity of all of the hardware of your target PC which allows you to run your VI as if it were on the target computer.
- Build an .EXE with Debugging Enabled: When you build your application for the target PC, in the Advanced section of the Build Specifications check the Enable Debugging option and then build as normal. To debug this external VI, when it is running on the target PC (With all of the IP configuration settings I informed you about earlier, also with TCP/IP enabled) you can debug it from your host VI by going to Operate > Debug Application or Shared Library and enter the target's IP address. When the VI is running on the target computer, it will show up as an option allowing you to connect to it. Control of the VI will then be delegated to your development computer.
