Producer consumer timing problem

[cookie10]

Hi, I am new to labview and I'm trying to use a Producer-Consumer data pattern. In my producer loop, my application needs to save a temperature data from an agilent every 5 seconds.  For the rest of the loop, everything needs to be as close to real time as possible. If I try a while loop with a wait function or a timed loop, just like in the screenshot, My program gets stuck in the loop. Any advice for my application ?

[altenbach]

A truncated picture full of local variables and questionable constructs is not suitable for any analysis. (Your timed loop will never stop unless you do something elsewhere. Do you? All your IO(?) (grey subVIs) execute in random, unpredictable order because they are all programmed to run in parallel without data dependency. etc etc!)

Please attach your VI!

[Bob_Schor]

If you are "new to LabVIEW", you may not understand how Data Flow works.  You certainly didn't show enough in your "picture of part of your code" (which is like the story 5 blind men examining an elephant and coming up with 5 totally different, and entirely wrong, descriptions of what an elephant is).  For example, you question involves Producer/Consumer design, yet we only seem to see part of the Producer loop, where you put BON (a single value) on the Queue.  Makes no sense to me.

I recommend that, at a minimum, you take this VI, do a "Save for Previous Version (if you are using LabVIEW 2022 or 2023, as many of the more-experienced LabVIEW contributors to the Forum do not upgrade every year -- I'm primarily working in LabVIEW 2019, for example), and attach the VI, itself.  If the Consumer loop is in its own VI, you should include that, as well.

Bob Schor

[JÞB]

We can make some quick observations:

We can open the top level vi if it is attached (see older style Windows Icon top left showing a dark Grey background vice the newer Orange)

The selection of the Enum value to enqueue could be improved. The Enum needs a typedef and either the code predates the typedef glyph or it is not type def'd. Also, consider removing the comparisons driving case selectors! Value < 100 means cases "Default" and "100...+inf" likewise !=0 is "0" and "Default"

[altenbach]

---

@JÞB wrote:
 Value < 100 means cases "Default" and "100...+inf" 

---

A numeric case containing "100..+Inf" would be broken. The correct term would be "101.." to match all integer values greater than 100

(note that cases are integers (and DBLs will be rounded to nearest), so you need to decide on the boundary conditions i.e. if 100 should be included or excluded. If you include it, the match will occur for values >99.5)

[cookie10]

Sorry, I really thought that my problem was so simple that I didn't need to share all my code. There it is in attachement. I basically want to run my producer consumer loops as fast as possible, while have another loop run every 5 seconds. The way I did it in the picture (the 5 second loop is on the side) actually works, but my supervisor doesn't like the idea. So I'm trying to come up with something different but I don't know where to start.

[cookie10]

Sorry, I really thought that my problem was so simple that I didn't need to share all my code. There it is in attachement. I basically want to run my producer consumer loops as fast as possible, while have another loop run every 5 seconds. The way I did it in the picture (the 5 second loop is on the side) actually works, but my supervisor doesn't like the idea. So I'm trying to come up with something different but I don't know where to start.

[cookie10]

I meant the way I did it in my attached code* (5 second loop on the side)

[altenbach · Accepted solution]

Many of the subVIs are still missing.

"As fast as possible" is always a poor choice (unless you are dealing with a pure hard math problems) because any hardware change will change the behavior unpredictably.

As a fist step you need to fix the glaring race conditions as already mentioned.

I assume that you expect your "IO train" to execute left to right, but that's not happening at all. In fact the SCR will happen last because it's input depends on the output of "AMP M". If you want them to execute left-to-right, you need to create a data dependency, for example with the error wire, but now things break because of a dependency loop that requires e.g. a feedback loop. This is just way too unpredictable!

[cookie10]

Thank you !