Generators in Labview (lazy programming)

[KasperWUR]

Thank you Bob for your continued help and advice. I am learning so much, your free improvements are very much appreciated!

I have tried everything you suggested and completely see your point. My while loop solution is doing a lot of uneccesary work that the event case structure can circumvent, freeing up a lot of CPU time for other processes.

I updated my solution to an event case, here's a snippet:

It seems that I am no longer able to use the shift registers of the previous solution. I used local variables instead to work around this. I remember hearing that it is bad practice to use too many variables, so I am curious if there is a better way to do this.

Just one thing about the case structure: I don't really like that the new factorialgenerator.vi doesn't work as a standalone function. It always needs to be wrapped in a loop in order to work. I guess this makes testing/debugging a bit more annoying, any thoughts on this? (e.g. In python I could use an 'if name == main' block to wrap my function in a loop only if run the file directly)

In any case thanks once again and I would be interested to hear more if you have the time.

Best,

Kasper

[altenbach]

---

@KasperWUR wrote:

I updated my solution to an event case, here's a snippet:

---

That's not a snippet, just a plain old image. (we cannot tell what's in the other events or cases, pretty useless for debugging)

• Terminals of latch action booleans belong inside their respective event case, not on the toplevel diagram. (Do you know why?).
• Nothing prevents you from using shift registers. Obviously you are doing something wrong but you are not showing us what you tried.
• Do you know why there is a coercion dot? Obviously you have datatype mismatch.
•  

[wiebe@CARYA]

---

@KasperWUR wrote:

Just one thing about the case structure: I don't really like that the new factorialgenerator.vi doesn't work as a standalone function. It always needs to be wrapped in a loop in order to work. I guess this makes testing/debugging a bit more annoying, any thoughts on this?

---

That is a very good notion. This should annoy you!

The function has a state, and you're choosing to keep this state in a loop. You're choosing to not make a sub VI for the function. 

So far, you kept state in locals and shift registers (that should work just fine in an event structure).

You could also keep the state in a class's private data. This would give you a more reusable function. Note that you'd still need to keep the class in a shift register, to preserve the class's state. The class is used just like a cluster.

If the state is global, you can make a FGV (Functional Global Variable) to keep the state. It would still be a global. I'd prefer a by wire solution (like a class), but FGV are used a lot.

Note that no matter which solution you choose, somewhere the state needs to be kept. This has to be in a local, (private) global, shift register (thus a loop), feedback node or reference (queue, DVR, etc.).

Keeping the state in a class or FGV is nicer because it encapsulates the solution, and hides the implementation for the outside.