01-09-2020 11:09 AM
@sbernie2 wrote:
@altenbach earlier seemed to suggest that loops by themselves are wasting processor power.
What altenbach was referring to are what are called "greedy loops". They are polling loops with no waits. You can easily use up 100% of a CPU core just checking a control status. That is wasteful.
@sbernie2 wrote:
Thanks for the input. New plan: Either 1) something like this example where a queue is used to control a state machine running in parallel to a loop that will stop things.
Personally, I am not a fan of that example. A queue that is used for state should either come from inside of the loop using it or outside of the loop, not both. What I have done is have a queue for maintaining state and another queue that is periodically checked for receiving messages from other loops.
01-10-2020 09:36 AM
Thanks again. Let me see if I'm understanding you correctly:
@crossrulz wrote:
@sbernie2 wrote:
Thanks for the input. New plan: Either 1) something like this example where a queue is used to control a state machine running in parallel to a loop that will stop things.
Personally, I am not a fan of that example. A queue that is used for state should either come from inside of the loop using it or outside of the loop, not both. What I have done is have a queue for maintaining state and another queue that is periodically checked for receiving messages from other loops.
You're saying that we need a queue with the list of possible states inside a loop along with a second queue which gets messages also in that same loop. The second queue is checking every say, 200 ms that there aren't any messages from another loop.
I appreciate any of the points above that you can address. I'm mostly confused about the purpose of the messages queue, unless it's just a way of adding information to the state queue which must be created inside the loop that uses it.
01-10-2020 11:04 AM
I haven't been following the thread *super* closely, but I'll throw this in. I don't use a queue for holding states- a "state" is a current value, so I store State in a shift register, usually with an enum, along with other state data. I have found that when I tried to make this pattern with a queue, where each state enqueued the "next" thing to do, that I just ran into problems, because I was trying to treat a state like a subVI. If you have a "state" that you call from other "states" to just "do something", then it's usually better to just put that in a subVI you can call instead of trying to iterate through states.