Race Conditions

[aaodeh]

I am relativelly new to LV programming and I am currently writting a simulation program which uses boolean arrays to simulate a production line. I am using a logical bit shift to simulate a downstreaming product. Each array represents a piece of equiptment on the productions line. The problem I am having occurs when I try to "handoff" an element from one array to another. When the "product" comes to the end of array A, I hand it off to array B. Yet, as I do so, array B (which can run faster than Array A (and vice-versa)) writes the sinlge element several times into its array. I have tried using queues, semaphores, rendavous, USRs  and notifiers to stop this problem but to no avail. My Code/SubVI is attatched.

Thank You Ahead of Time

[altenbach]

It is difficult to test without seeing all the missing subVIs.

Queues should work just fine. Your lower two loops run at the same rate, so they should be combined into one. I would also keep the arrays in shift registers. Try to avoid locals, globals, and value properties.

[aaodeh]

The loops in the array can each run at varying speeds. Here are the remainng subvis.

[Vince]

On Jul 30, 11:40 am, aaodeh <x...@no.email> wrote:
>I am relativelly new to LV programming and I am currently writting a simulation program which uses boolean arrays to simulate a production line. I am&nbsp;using a&nbsp;logical bit shift to simulate&nbsp;a&nbsp;downstreaming product. Each array represents a piece of equiptment on&nbsp;the productions line. The problem I am having&nbsp;occurs when I try to "handoff" an element from one array to another.&nbsp;When the "product" comes to the end of array A, I hand it off to array B. Yet,&nbsp;as I do so, array B (which can run faster than Array A (and vice-versa)) writes the&nbsp;sinlge element several times into its array. I have tried using queues, semaphores, rendavous, USRs &nbsp;and notifiers to stop this problem but to no avail.&nbsp;My Code/SubVI is attatched.
>&nbsp;
>Thank You Ahead of Time
>
>LineSimulation.vi:http://forums.ni.com/attachments/ni/170/262196/1/LineSimulation.vi
>
>ShiftingArrayTes2t.vi:http://forums.ni.com/attachments/ni/170/262196/2/ShiftingArrayTes2t.vi

Change your globals to local variable, repost, make sure to post Test
Bolean.vi, untitled.vi, and Part clock.vi. Or any other portions of
your project that are need to open.

[altenbach]

---

@Vince wrote:
Change your globals to local variable, ...

---

That change woud be completely irrelevant with respect to the observed race conditions. 😉

[aaodeh]

 I have changed the global variables to local variables and posted all the subVIs

[TreyB_NI]

---

altenbach wrote: 

Queues should work just fine. Your lower two loops run at the same rate, so they should be combined into one. I would also keep the arrays in shift registers. Try to avoid locals, globals, and value properties.

---

I agree with these suggestions.  However, with the newest VI, those loops are actually running at separate rates.  PPM is a separate variable from different clusters.  Just a bit misleading.

The bottom most loop doesn't wait on a change in handoff, it just runs whenever.  There's nothing to control the data flow such that the bottom loop waits in the change of the middle loop in the variable handoff.  You should use queues to create rigid data flow.

Also, remove that write to the local variable Feeder Bit in the top loop.  You are already writing to the corresponding indicator, so there's need to write to the local variable.


Trey B
Applications Engineering
National Instruments

Message Edited by Trey B on 07-31-2007 10:03 AM

[aaodeh]

I tried adding queues/notifiers/semaphores and although they prevent race conditions, they also prevent my producer and consumers loops from running at two different speeds ( both loops will go the speed of the slowest loop). I need a way to prevent race conditions while running the loops at two different speeds.

Thanks,

Message Edited by aaodeh on 07-31-2007 01:26 PM

[altenbach]

Well, if there is data dependency, it does not seem to be very useful to spin the consumer faster than the producer, but if you really want to do so, read from the queue with a small timeout and add a case structure where your either spin the loop idly (in case of timeout) or process the queue data (in case of pending queue data).

[aaodeh]

My objective is to index the bottom loop's array faster than the top loop's array. The only way I was able to do this was by allowing  the bottom loop to run faster than the top loop. Will your method still be appropriate?