Running program on other machines

[LarsUlrich]

The company I work for has had me learning labview and writing some basic programs to perform some tests that we do.  I have been writing the programs at my computer, building an executable out of them, putting them on CDs and giving them to the people who are actually going to be running them.  The other computers also have the same version of labview installed (8.5) as the computer I have been writing the programs on.

All of these programs involve GPIB instrument control and I have seen a similar problem pop up a couple times.

A couple of programs (after building a .exe and writing to a cd) will run a few times without issue on the other computers, but will then be unable to communicate with the instruments they control.  An error message does not appear and break the program, and the program itself runs through from start to finish, but it does not communicate with one or all of the GPIB devices it is supposed to control.

For example:  One program controls a function generator to preform a frequency sweep.  There are indicators that show what frequency the sweep should be on.  This indicator updates as it should (it seems like the program IS running through the sweep correctly, just that the data never gets to the device).

A second example:  Another program calibrates a LISN by runing a frequency sweep and measuring the output through a DVM.  Again, the program itself continues to run (no communication error messages that stop the program), and the sweeper even works (it DOES communicate with the signal generator, though this is a different signal generator than in the other program) but the program does not communicate with the voltmeter.  It runs through the sweep just fine but it doesn't store any data.

With both of these programs we have switched out the malfunctioning instrument and the GPIB cable to see if that was the problem, it wasn't.

The strange thing is that both of these programs worked when I built them.  The first program I talked about worked for 4 hours on friday, as an executable, on the other tech's computer, but then it suddenly stopped.  Nothing about the program changed because it is a .exe file.

Any ideas?  I am kind of stumped.

[LarsUlrich]

Has no one else had this problem?  A working executable that loses its ability to communicate with the GPIB instruments that it is intended to control?

[LarsUlrich]

Update on something I just tried:

Tech's computer + CD + instrument = doesn't work

My computer + CD + instrument = works just fine

So it has to have something to do with the tech's computer that he is running it on.  Again, the program worked fine for a few hours on Friday on the tech's computer, are there any known bugs that can cause communication problems like this?

[LarsUlrich]

More info on the Tech's computer issues:

When he opens the .exe file and clicks the control that should start the sweep, nothing happens.  The "listen" light lights up on the gpib device, but the remote lights and talk lights don't turn on.  If he then breaks the program (either by the designated stop button or the stop sign on the top left) and then runs it again (via the arrow on the top left), the listen light lights up just the same, but this time the program runs through the sweep.  It still has a communication issue with the device and the commands never make it to the function generator, but the program "thinks" that it is successfully running.  For some reason you now need to stop the program and restart it before it will even attampt to run correctly.

[aeastet]

Is there an attach command where you tell the device what system is attached to it? If so then I would say that you are not closing references to the orginal device when a new one is attached. If not I would look for coditions like this where one system connects but does not let go.

If you power down the device and restart it and only have the tech computer attach to it does it work?

Do you have this problem aif a different system is trying to attach without restart?

[Albert.Geven]

Hi

You are talking about the stop buttone in the upper left.

This is NOT a stop but an ABORT buton.

Strange things can happen to an IOsystem when it is used.

Do you have the installer include all the IO systems. e.g. did you add visa to the installer or did you check the software versions to be the same on target computer and compile system?

It also can be an instable computer, maybe with a too soft power on the usb ports or do you use a normal pci gpib board?

just some ideas.

[LarsUlrich]

Thanks for the ideas.

Yes, I was talking about the abort button, and i know it is not the way we should be stopping this program (there is a real stop button programmed in the way it is supposed to be) but I was just trying everything.

We have had Visa problems on the tech's computer before, but by reinstalling the latest visa package we were able to fix all that.

We don't use a normal gpib board, instead we use a national instruments, gpib-usb hub.  We have a few, so we changed out the one he was using and tried the one from my cpu and the problem still continued.

Also, I AM able to send commands to the device via NI MAX on the tech's computer (which is also a laptop?  Idk if there are issues with laptops or not)  Just not through labview.

[aeastet]

If you are using USB you have to be careful. When anyone plugs in a USB device it reassigns the USB ports. If you plug in a thumb drive or anything. I would suspect that is what is happening.

[Albert.Geven]

try a powered usb hub to prevent power problems and check the power settings (shut down unused usb ports) to save battery power.

[LarsUlrich]

hmm...

So the tech just stopped by my office and gave some good/weird news.

It will work, if and only if he goes into NI MAX and clicks "scan for instruments" before he runs the program.

As I said in one of the earlier posts, when we run the program, the remote light doesn't light up, only the listen light does.

Apparently, if we go into NI MAX and "scan for instruments" the remote light will then light up.

Once the remote light is on, we can then run the program and it will handle the GPIB device just fine.

The driver I am using was downloaded from the NI driver database (and again, I don't have to do this on my cpu, only on the tech's cpu) so I don't think the driver is the issue.