pass VISA resource between loops with queue

[ikonen · Accepted solution]

I'd say the big picture is still a little fuzzy...specifically it sounds like the "wafer map" is a pure GUI element and not a physical device, but I'm not sure, and I'm not sure what you mean now by the "main" loop, or how you're dividing probe communication between the two loops.

Regardless...you know what you really need to do, so I'll just offer a tip that might be wrong if I've made some wrong assumption about the rest of you code:

I would wager you can do what you want without splitting probe communication between two loops, and ultimately the code will be simpler and more clear (changing now might be a complete rewrite from scratch, though...you'll have to decide if it's really worth it if your code is already almost working).  The real advantage of using parallel loops in LabView is when there are cases where you want both loops to run WITHOUT waiting for each other.  E.G. if you were controlling two different probes from the same Labview program, you don't want to hold one up while the other is working.  Or separate loops for user interface processing and other actions.  If both loops are regularly talking to the same instrument, there isn't much point in splitting the work across loops because now you have to prevent simultaneous operations which was largely the point of having separate loops in the first place.  Using a single loop to process communication with the probe regardless of what type of action / query is being processed prevents overlapping interaction.  

Following the architecture in that link, you probably want the user interface loop to be the producer and the probe actions to be handled in the consumer loop (and the logic handled by a state machine):  Commands to the probe from the UI (like go here) are sent in by enqueuing a simple string or enumerated constant (perhaps a cluster containing the command and some addition data from the UI (like where to go)).  Automatic processes for the probe, like a long test sequence with multiple steps, are controlled by having one iteration of the state machine loop launch automatically into the next iteration without reading queue of user commands.  Or you could have it enqueue the next step into the same command queue used by the user interface if you're okay with the user being able to interject commands in the middle of the process). When the probe is doing nothing the state machine goes into some idle state and waits for the commands queue to get another command from the UI loop.  

If a probe "state" can take a long time to process and you don't want to tie up the user interface for other activities (tying up the consumer loop during a long test, for example) you can handle "quick" UI events right in the event structure without the need to enqueue anything for the probe, or you can have another consumer loop (with it's own dedicated queue)...perhaps for a different piece of diagnostic equipment, or for UI triggered events that might take a while, like saving a log file to a remote server.  Or you can use a single consumer to handle all actions even if they don't involve the probe, but then they have to happen sequentially (moving the probe will hold up writing the log file and vice versa).  Your call on the trade off between complexity and performance.

Finally: just a comment on this

"Wiring the VISA Resource Name between the various sub-VIs allows for execution of the commands in the right order."

Yes...but I think the existance of "Visa Resource Out" terminals (and other similar output terminals that mimic an input) is more a nod to clean code.  It's true that it does allow you to enforce data flow (operating in the correct order), but that SHOUD be reduntant because of the error wire.  Error in -> error out wiring actually does pass variable information along to subsequent commands and also enforces data flow by itself.  But you still need to wire the Visa Resource name input, so if you don't wire "...out" to "...in" for sequences, you end up with a comb looking structure with one long horizontal wire holding the resource name and verticle branches coming down to the individual subvis / VISA operations.  It's more obvious that the resource name never changes, and it's perfectly functional, but it's also uglier and takes up more space on the diagram.  So by all means, wire sequential commands in a single structure the way you have been, but when you're jumping through hoops to pass the name across large swaths of your code, you're kind of defeating the purpose.  

[flongnos]

Hello ikonen,

Thank you for your help As you said, the Wafer Map could actually be built as a pure GUI element. Then I merged the event structure basically dedicated to this wafer map, with the event structure controlling the consumer.

My problem before was that to extract current die location on the wafer map, I sent GPIB commands to the prober which in return gave current die position in the prober reference system as well as the position of the home die.

With some processing, I could update the wafer map with the current die position, in the local reference system.

This was simultaneous with some other GPIB command for probecard motion, passed through a queue and executed in the consumer. As a result there was of course a race condition, as the VISA was overflowed with instructions.

My solution was to develop some processing which did not require the GPIB commands to update the wafer map (inside the event structure, for the appropriate events).

For the VISA Resource Name, it is sent to both the event structure and the consumer loop, and it is kept in memory with shift registers passed through both loops.

In the consumer loop, I indeed implemented an IDLE state that is entered after all other operations of the consumer loop. It is a real queued state machine.

All is very clear in my mind now, thank you a lot.

Regards,

Florian