modifying same variable in different loops

[flongnos]

Hello Everyone,

I am using an event-controlled producer/consumer architecture where both loops run processes acting on a common variable.

To be more specific, I intend to modify a Picture Indicator both in the consumer and producer loops. Therefore I need to share this variable between the two loops.

I thought the best way for that was to use the Picture Indicator as part of a Functional Global Variable:
1/ Initialization of the FGV, which is a cluster containing the Picture Indicator

2/ In both loops, the Picture Indicator latest value is extracted from the FGV using a "Read" action

3/ The Picture Indicator value is wired through different processes that might change it partially or totally

4/ Finally, in both loops the Picture Indicator updated values are wired as input of the FGV.

Above is the ideal case, I would have expected to work. However this is not working, and what I actually implemented is:

a) In the producer loop, the Picture Indicator is updated through a shift register, and at the same time the new value is stored in the FGV

b) In the consumer loop, the Picture Indicator is retrieved from the FGV, and its updated value is stored in the FGV (as in the ideal case)

Then I don't why this is not working. I use other FGVs in my VI, and that are modified by both loops, but THEY work..

My VI is really big, so I can't take a picture of it. Then I provide you with simplified scheme of what is my current architecture, and the one I target. I hope it helps.

Thank you.

Florian

[altenbach]

What does the event structure do?

Seems like full of race conditions because parallel code can read-modify-write the FGV at the same time and whoever writes last wins the race.

In the lower loop on the right, how do you ensure that the reading happens after the writing?

[JÞB]

a FGV is not going to help here (Although it is a start)  If you mean a true LV2 global that only has set and get actions.  What you do need is an Action Engine to encapsulate all of the actions you need to take on the image.  Without a single point of entry for all actions you risk creating a race condition where your loops are acting on the image at the same time and overwriting changes made in the other loop.

[crossrulz]

---

flongnos wrote:a) In the producer loop, the Picture Indicator is updated through a shift register, and at the same time the new value is stored in the FGV

---

Why are you saving the value in multiple places?  The point of the FGV is to keep control of the data.  You break that by saving the data in another shift register.  All access to the data should be through that FGV.

[flongnos]

Hi altenbach,

To make things more clear, the Picture Indicator is used to display in Real Time the Wafer Map of the Prober.

The Picture Indicator contains a grid of rectangles, each representing one die.

There are two event structures:

1/ the top one enqueuing elements to be dequeued by the consumer. And the kind of elements enqueued here are enum to select cases of the case structure, in the consumer.

2/ the one at the bottom looks out for mouse events linked to the Picture Indicator such as:

                 - Mouse Move to extract XY coordinates on the Picture Indicator

                 - Mouse Down to either change the color of an element inside Picture Indicator OR command the prober to go to the die corresponding to the selected element of the Picture Indicator

Actually, in my VI, I use a multi tab on the Front Panel. Commands that act on the Picture Indicator for the consumer are in a different tab than the commands for the Producer.
The user can not trigger them simultaneously, so I think access to the FGV is only done in one place.

As it is now, in the consumer loop, the FGV is read and written outside from the case structure. Therefore, in any case, event the IDLE the FGV might be accessed... but that's just pure assumption...

What do you think?

In the lower loop on the right, I actually did not implement sequential operation...

[flongnos]

Hello Jeff,

My FGV is a cluster of 4 variables, and the only operations that I perform is:

1/ Initialize

2/ Set data: all data are stored in the FGV

3/ Set Picture Indicator: only the new value of the PI is stored, and other variables are kept the same through the internal shift registers

4/ Read: all variables are kept constant through the internal shift registers and are passed as outputs

No action is performed on the Picture Indicator inside the FGV, it's not an Action Engine here. So I guess it's a true LV2 global, right?

All actions are performed in the producer and consumer loops. And because I need the Mouse Events to be always active, so far I didn't find another way than placing the event structure in a separate loop.

But I'm just starting on Labview, so maybe I skipped something...

[flongnos]

If of any help, here is the sub-VI (zipped) corresponding to the FGV mentionned above.

Thanks.

Regards,

Florian

[stevem181 · Accepted solution]

Hi Florian,

The two FGV Reads on the left side of your lower loops will be a problem unless you use data flow to control them. These FGV Reads (as shown) will occur at startup and then after the structure in each loop completes. When you really want them to "read" when a queue item arrives or in the Picture Loop - when new values are available.

The Consumer loop is pretty easy to deal with. Just run the Dequeue "error out" to the "error in" on your FGV. This will ensure that the FGV Read happens when you get a new item.

The Picture Event loop is a bit tricky. You could send a User Event from the Consumer loop (after your FGV Write) to the Picture Event loop. In that Picture Loop User Event, put an FGV Read. This ensures that you will get the changes made in the Consumer Loop. The only downside to this approach is that the Picture Loop always runs once when a change is made in the Consumer Loop. You could use a boolean to prevent the picture from being written (also ensures the picture is always written after the Event Structure Completes).

Here is an example:

steve

[flongnos]

Hello Steve,

Thank you for your suggestion. I was planning to use dynamic user events like you said, with enforcing dataflow.

However my VI specifications are to have a Picture Indicator that I can modify continuously.

But finally I found much simpler to merge the two Event Structures, as the Wafer Map Picture Indicator is a pure GUI element.

I also at the end only use FGV to store variables that I write only once at VI start (in one place) and that I read many times in the two loops (not for all cases though). Then there might be no race conditions.

Processes for the Wafer Map are executed in the Event Structure with sub-VIs.

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. 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.

As I only modify the Wafer Map in one place (Event Structure), I therefore no longer need to worry about sharing it between the two loops.

Thank you all, I really learnt a lot!

Regards,

Florian