Need to execute a sub-VI continuously, while others are executed on demand.

[dbrosnan]

I'm running into a problem while trying to develop a set of controls for a scanning probe microscope. I have a PID control which governs the height of the probe above the sample (feedback input is through a PCI DAQ card), and which needs to run at all times. I also have a scan control which raster-scans the area of interest as defined in the input. Both of these programs work fine on their own. the problem I am encountering is: due to the nature of the position control equipment, these controls must be consolidated into a single VI (the "device handle" can only be called in one program at a time). The PID needs to execute constantly and in real time, while the scan needs to execute only on command. is there a relatively simple way to call a sub-VI such that it will run continuously at a high priority, while allowing another to be called on demand? Specifically, I need to avoid either sub-VI becoming caught in a "while" or "case" structure and refusing to allow the other to execute.

[johnsold]

I think you have two issues. One is running the VIs in parallel. That is easy. Simply make sure that they do not have any data dependency between them.

The second is the implication that the output to the equipment is a shared resource. There are several ways of handling that, but it is hard to recommend one without knowing more about your system. One way is to encapsulate the outputs in a VI like an Action Engine (AE). You need to be careful that each call to the AE will return in less time than the higher priority loop needs.

Are you running a Real Time system or a consumer OS? How fast does the PID loop update? How long does it take to send a position command to the instrument? Can the instrument queue up multiple commands or does it need to complete execution of one command before the next is sent? How long does that take?

Lynn

[dbrosnan]

I suppose I should have included a bit more information in my original post.
I am running under windows XP, the PID updates once per millisecond via analog voltage reading, the instrument can queue commands but there's no current need to do so as the speed with which I need to issue commands is significantly below the USB polling rate.

also, the problem with execution in parallel is that while the VI's are effectively independent, they both need to receive the same device ID from the controlling DLL. Unfortunately, the device ID command can't be called separately in each VI due to hardware restrictions, which is the reason I was looking for some sort of background execution option.

I'm attaching the VI's themselves to make the situation a bit more clear as well.

thanks for your input.

[vt92]

How about parallel while loops?  You could call the DLL which generates the handle first, then wire the output (handle) to a shift register on both while loops.  Or.. if the handle is dynamic, use a LabVIEW class structure to hold the handle value so that both loops can share the data or use a LV2.0 type global (uninitialized shift register) to hold the value.  

[dbrosnan]

I'm kind of embarassed I didn't think of that myself, but initializing the device handle outside of a pair of parallel while loops works beautifully with a couple other minor tweaks.
thanks for the help.