pass VISA resource between loops with queue

[flongnos]

Hello Everyone,

I am just getting familiar with queues and the producer/consumer template, and I am facing difficulty to pass data between loops using queues, especially data of the type "VISA Resource Name".

Indeed it seems impossible to cable "VISA Resource Name" as an input of Enqueue Element, as well as an output of Dequeue Element.

Can I still try to convert this type into something these VIs can accept? Or should I adopt another approach, and which one?

Thank you a lot for your help.

Florian

[MaveenD]

Hi Florian,

U can still try to give the visa resource name but first a change in approach with different patterns

queue with events and queues in data collection.

[flongnos]

Hi Maveen,

Yes, I will use different queues for events and for data collection.

Actually my question here is, to be more specific, how to pass the "VISA Resource name" variable from one loop to another. I need this variable to send successive GPIB commands from parallel processes, to the same instrument.

[moderator1983]

---

@flongnos wrote:

I am facing difficulty to pass data between loops using queues, especially data of the type "VISA Resource Name".

Indeed it seems impossible to cable "VISA Resource Name" as an input of Enqueue Element, as well as an output of Dequeue Element.

---

There should be absolutely no problem while sending the data of the type "VISA Resource Name"... Can you share the part code, where you feel its not possible to share this specific data of the type "VISA Resource Name"...???

---

@flongnos wrote:

Can I still try to convert this type into something these VIs can accept? Or should I adopt another approach, and which one?

---

Ideally you should choose the queue data type as a cluster of two elements [Variant (data), Typ-def enum(state)].. If you're not understanding what I;m trying to say here, probably you should check this link.

Coming back to your question, you have to convert it to exactly what your queue is supposed to accept (that is what you defined as 'element data type' while using the "Obtain Queue" function)

[flongnos]

Hi moderator1983,

Thank you, it was actually that: I didn't define properly the queue type using the "Obtain queue" VI.

I actually read the article you just fowarded to me, that's a good source indeed. But at that time I didn't know how to define this cluster of  [Enum, Variant], but I finally found out (clustering Enum and Variant constants, and converting the resulting indicator into a constant).

My concern now is how to send back the VISA Resource Name to the main loop. Let me explain a little more my showstopper here.

Within a producer/consumer template, only the producer(s) can add elements to the queue while consumer can dequeue elements to use them internally. 

Let's say now we have 2 loops, how can we have:

1/ Loop #1 queue up an element into the queue

2/ Loop #2 dequeue the element

3/ Loop #2 queue up an element into the queue (same or different?)

4/ Loop #1 dequeue this element

The purpose of this is to:

a) Hand over the baton to the loop #2  from the loop #1, passing the VISA Resource Name ==> Loop#1 = Producer & Loop#2 = Consumer

b) Handing back the baton to loop #1 from the loop #2, passing back the VISA Resource Name  ==>  Loop#2 = Producer & Loop#1 = Consumer

Is such a chain of action possible, and how to implement it?

[johnsold]

If you need to send data back to Loop #1, use two queues. One for each direction.  You should only dequeue in one place or the data will get impossibly confused. (and the programmer, too).

Lynn

[moderator1983]

---

@flongnos wrote:

My concern now is how to send back the VISA Resource Name to the main loop. 

---

Generally Producer loop have Event structure (to handle the user interactions), and in such cases you might want to pass the data (from Consumer loop or any part of LabVIEW application) using dynamic event registration. I always prefer that.

But if there is no Event structure available in the Producer loop then, as suggested by @johnsold, you can create either an additional queue or a notifier.

[ikonen]

I'm just guessing here because you haven't elaborated on what your loops do other than need to pass messages back and forth, but I think you're still confused as to what you should be queueing and what the jobs of the loops are.

As you noted you CAN enqueue data of type "visa resource name" by using Obtain Queue, but I'm finding it hard to imagine why you would want to, as opposed to enqueing the data retrieved from a VISA read (or a command to send to VISA write).  Visa Resource Names don't typically change during a single experiment unless you have some option for the user to change which instrument you're collecting data from (or controlling) during the experiment.  If the resource name is not changing between loop iterations, you can just pass it in once with a wire.  Do you have some programming process within each loop that dynamically determines what instrument the OTHER loop needs to communicate with?  Or you are just trying to coordinate access to the same resource so the loops don't conflict with each other?  You might look at using a semaphores instead.  

Producer / Consumer is a good model for use with external data collection, but *typically* the idea is that the data acquisition process (IE all the VISA related commands) happens entirely in the producer loop and data analysis / display / logging happens in the consumer (along with user interface handling).  With multiple instruments independently acquiring data at their own rep rates, it can be expanded to multiple producers and a single consumer (as the others noted, parallel loops shouldn't be trying to dequeue a single queue or you'll probably get a race condition, but there's no harm in having multiple loops adding content to a single queue as long as consumer can handle the results), but each different instrument would get it's own loop.  

[flongnos]

Thank you johnsold and moderator1983 for the suggestion.

I would prefer to use an additional queue as dynamic event registration seems a bit hard to master for me right now.

So far I have not been able to test if it works in my LV project, as I am currently debugging other stuff. When everything else works, I'll give some feedback.

Regards,

Florian

[flongnos]

Thank you ikonen to help me put things together.

Well, you are right that VISA Resource Name for a given equipment is the same throughout the whole VI execution.

In my case, here, I'm dealing with a Probing station, to which I send various kinds of commands and from which I can also retrieve few pieces of information (cassette status, wafer status, wafer ID, position of the probecard at a given time, etc..).

In my VI, I have many sub-VIs corresponding to each individual GPIB command that can be sent to this prober. Wiring the VISA Resource Name between the various sub-VIs allows for execution of the commands in the right order.

In my queued state machine, one loop is dedicated to send specific commands to the prober and the other loop operates the wafer map in real time.
In the Wafer Map, when I double click on one die position, I need to retrieve corresponding position on the prober (at least with the start die position), and send the commands to move the probecard to the new position. Subsequently, on the wafer map, the color of the new DUT is updated. For these two sub-VIs I require the VISA Resource Name to pass through the loop.

But when the Wafer Map loop is executing this operation, the main loop should be in IDLE state.

To sum up, I want to send commands to the same instrument in two different loops. So, what I thougth out from your comment is that I can open and close the VISA in the EVENT LOOP (as in the architecture shown here http://expressionflow.com/2007/10/labview-queued-state-machine-architecture/) and provide the VISA Resource Name to the two loops (Prober Control Interface & Wafer Map) in parallel.

So I will try this out. Do you think that makes more sense now?

Florian