Semaphores and queue together. Is it necessary?

[F._Schubert]

Queues 'break' dataflow.

This is necessary to communicate between two (or more) parallel loops. You will always need something that 'breaks' dataflow in these situations, such as global variables (bad), LV2globals/Action Engines, ... Queues are a very elegant solution to manage this.

Felix 

[dan07]

F. Schubert

You are right about Queue "breaking" the dataflow. I've been reading some posts about queue and this function is really very nice. When you have a very small VI with no SUBvis, is "possible" to use local variables in a safe way, because you can see everything in one single block diagram. If you have a main VI with two or three SUBvis, you can use Globals... but I prefer to don't use them in any circunstance. I prefer to wire everything and keep away from race conditions. I never saw a situation that globals and locals were the only option. There is always another way to do the same thing.

Dan07

[Ben]

---

Daklu wrote:

---

Lucither wrote:

Has given me something to think about as i have to admit that sometimes i fall into the trap of writing 'Function machines' as you have called it.

---

I think everyone does; it's part of the learning process.  Below is a diagram of a QSM I had a hand in creating just last year.  (Of course, I didn't create the diagram until it became too hard to follow the execution in code.)  This is just the diagram for the Start Test button!  This project is what prompted me to examine the QSM and look for better ways to implement it.

---

So THAT is the reason you were asking about diagraming the QSM.

Thank you very much for the nice posts you have contributed to the this thread Daklu!

I going to tag this one so I can find when i need it.

Ben

[dan07]

Does anybody had problems viewing the QSM diagram? I can't read anything on it.

Thanks

Dan07

[battler.]

Yeah, can't read it.  Would it really help?

[Daklu]

---

dan07 wrote:

Does anybody had problems viewing the QSM diagram? I can't read anything on it.

---

I purposely reduced the size to a point where the states themselves are unreadable to protect proprietary information.  My intent is to illustrate the complexity that can easily occur as you add functionality to a QSM.  Except for the red and yellow circles, each one is a separate state in this state function machine.  That's a lot of cases to trace through trying to make sure the branching logic is correct for all user scenarios.

While developing this state diagram I discovered a significant bug in our state function machine.  Under certain situations one of the states would queue up additional states expecting that they would be executed next.  Sometimes there would already be states in the queue that would be executed first, and which would in turn add more states to the queue.  This resulted in parallel execution paths being interleaved on the queue that would have caused completely unpredictable behavior.  Note this bug wasn't discovered through testing--had we seen it at runtime it would have been difficult to replicate and identify--but by code analysis.  Code analysis is much harder to do in a QSM than in a block diagram that uses standard flow control prims.

The PreTestValidation and ExecuteTestCases blocks I added after figuring out the state transitions.  If I ever have to do significant coding on that part of the project I'll condense all the states in each of those blocks into high-level sub vis and use standard flow control rather than relying on a queue.