BreakPoint
Rube Goldberg Code
So we could just put a state enum in a shift register as every reasonable person would do
OR... (wait for it) ...
We could also constantly push it in an out of a queue ( ... and I am not making this up!). I think Rube Goldberg would have been very proud!
Search LabVIEW like a graph! 
@VinnyAstro wrote:
The only advantage I find here would be to be able to add various states at the back and front. while with a simple shift register it requires a bit more manipulation.
The advantage of using the queue is being able to enqueue multiple states at once. But this is geared more towards a sequencer than a state machine. This is also a variation of the JKI State Machine.
@crossrulz wrote:
@VinnyAstro wrote:
The only advantage I find here would be to be able to add various states at the back and front. while with a simple shift register it requires a bit more manipulation.
The advantage of using the queue is being able to enqueue multiple states at once. But this is geared more towards a sequencer than a state machine. This is also a variation of the JKI State Machine.
Yes, if we want to enqueue a sequence of multiple states we also need to adjust the rest of the code to handle that. Nothing wrong with that. Here we would typically have the enqueue and dequeue in parallel loops.
Here we have a 1:1 relationship of each state dequeuing and enqueueing exactly one "next state" ( all in the same loop!) and if we would forget to enqueue (e.g. not enqueue the initial state, the program would lock up forever and if we would enqueue more than one the queue would grow forever.).
@altenbach wrote:
@crossrulz wrote:
@VinnyAstro wrote:
The only advantage I find here would be to be able to add various states at the back and front. while with a simple shift register it requires a bit more manipulation.
The advantage of using the queue is being able to enqueue multiple states at once. But this is geared more towards a sequencer than a state machine. This is also a variation of the JKI State Machine.
Yes, if we want to enqueue a sequence of multiple states we also need to adjust the rest of the code to handle that. Nothing wrong with that. Here we would typically have the enqueue and dequeue in parallel loops.
Here we have a 1:1 relationship of each state dequeuing and enqueueing exactly one "next state" ( all in the same loop!) and if we would forget to enqueue (e.g. not enqueue the initial state, the program would lock up forever and if we would enqueue more than one the queue would grow forever.).
I'm not arguing your points. I was only pointing out that there is a good use of using a queue to maintain your states. But I will reiterate: I would not do this for a state machine; it is useful for a sequencer.
As far as forgetting to enqueue and then your queue is empty, I have code in my library to handle that (go to an error state if the queue is empty). The queue growing forever is another issue. There is not much you can do about that from a library perspective. That would be on the programmer of the sequencer.
Sometimes Rube Goldberg code can be deduced from words alone (seen here)
QUOTE: "When I dragged over several indicator/controls and try to create local variables or references,...., but if I just drag over say 100 controls, what is the logic behind the order of created local variable and reference label/icons?"
(On a side note, I recommend to not comment in that thread. Seriously)
@altenbach wrote:
(On a side note, I recommend to not comment in that thread. Seriously)
Jenny luckily took care of that. It’s a typical case of wanting to show they know better and challenging everybody having any critique. I pity his students if he really is teaching.
@rolfk wrote:
@altenbach wrote:
(On a side note, I recommend to not comment in that thread. Seriously)
Jenny luckily took care of that. It’s a typical case of wanting to show they know better and challenging everybody having any critique. I pity his students if he really is teaching.
Wow, that thread got really out of hand. And the guy actually believes that his approach is better.
@johntrich1971 wrote:
@rolfk wrote:
@altenbach wrote:
(On a side note, I recommend to not comment in that thread. Seriously)
Jenny luckily took care of that. It’s a typical case of wanting to show they know better and challenging everybody having any critique. I pity his students if he really is teaching.
Wow, that thread got really out of hand. And the guy actually believes that his approach is better.
When all you know is a hammer, every problem tends to look like a nail. And some are so fixed in their believes that they will refuse any advice that there are a zillion other tools out there than just a hammer.
One of his future threads, he will likely start, will be about how totally useless and crappy LabVIEW is, because his beautifully and painstakingly designed application is so badly maintainable.Python, C#, even Basic is so much more superior, because you can use Ctrl-C, Ctrl-V a zillion times and the order is always consistent! 😀
The problem is never with us, always with the others. 😁
