system exec vi path problem

[Mikael.Peterson]

Hello

I have a problem with the system exec vi. To begin with; the program works and the reason that I'm posting here is that I want to make the program a little bit more functional and remove an annoying bug.

My Front panel consist of two buttons, two path controls, one picture control and one string indicator. I intend to use this vi to enumerate CCD-cameras on my computer, select on of them and acquire an image and then display them on the front panel. This is accomplished by two calls to external exe-files using system exec vi. In the block diagram, I have arranged the two calls in an event structure encapsulated by a while loop so I can make the calls during run-time using the two buttons.

The first button is used to acquire images from a CCD-camera. When I push the first button ("acquisition button") the path from the first path control (points towards the acquisition program executable) is sent to an system exec vi (the folder path and file name separated) and the collected image is then displayed in the picture controller.

The second button is used to list the cameras available on the computer. In the same manner as with the acquisition the path string from the second path controller is feed to another system exec vi that lists the cameras and displays them in the text box.

Now to the problem. When I start the program I start by selecting the two executables in their respective path controls, for example the acq exe followed by the enum exe. If I then press the acq button the system exec vi associated with that path is launched and the picture appears. If I then press the enum cam button I get a file dialog that wants me to locate the enum executable (even though the correct path is specified in its corresponding path control). If I select the path (again) when the dialog is prompted the program works fine and the enumerated cameras are shown in the string indicator. But if I now push the acquisition button a dialog appears asking me to locate the acq executable, and when I do, the acq works fine but again, I can't enumerate cameras until I respecify that path control.

So the successful load of a system exec seems to depend not only on the path provided but also on the most recently loaded path to any path control if there are multiple system exec.

I'm grateful for any help provided. Hope that my question is clear enough and not to specific.

I run labview 8.6

/Mikael

[smercurio_fc · Accepted solution]

You are stripping the path you are providing and sending just the name of the file as the command line. This assumes that the command window has the PATH environment variable set so that the executable can be found. You cannot assume this. You should be specifying the full path to the executable as the command line. Be sure to include the path within quotes.

A comment regarding code: What is the point of that loop? It does nothing. Neither does the sequence frame. You do not want an event structure to be tied down waiting for something to happen. If you're going to start something that might take a while then you should look at using an architecture such as the producer-consumer. You want the event structure to finish quickly so you can continue to respond to events.

[Mikael.Peterson]

Thank you for your quick response. It sounds reasonable, I will try it first thing in the morning.

Regarding the code, when I run the program I want all "processes" (i.e., acquiring image and enumerate cameras) to be user generated, e.g., by pushing a button. Perhaps there are simpler and more efficient ways to do this. This was the first thing that caught my eye when I looked for solutions online and it has worked well so far. Perhaps I should mention that I'm a newbie with no formal training in Labview. There might be some issues later on if I use this type of event generation?

Once again, thanks for your help.

[smercurio_fc]

Well, the issue isn't so much with event generation as much as event handling. The event structure must complete the case before it can return to watching for events. If you have code inside the event case that sits there for a long time then the UI will appear to be unresponsive. That's why it's usually better to hand off the event handling to another loop and let the event structure return to responding to UI events.