Feedback on state machine

[Dfturner42]

I made a state machine to cycle solenoids when activated. It works how I want with the exception of having to press the start button twice for follow-up cycles (not really a concern for me). I am posting to get any feedback or tips to improve future VIs that I make. I uploaded a 23Q1 and 18 file. Thanks in advance.

[raphschru]

Hi Dfturner42,

Configure your buttons to have one of the "Latch" mechanical actions.

Typically the default action for monostable buttons is "Latch When Released":

The OK, Cancel and Stop buttons are configured like that by default.

The push buttons and switches on the other hand are more often used in "bistable" mode, so they are pre-configured with a "Switch" mechanical action, but this can be changed as you desire using the right-click menu.

Regards,

Raphaël.

[Bob_Schor]

A "memory trick" to remember which Boolean controls (by default) have "Latch until Released" mechanical actions (and are good for "Start" and "Stop" actions) is -- they are all rectangular (like a "Power On" button, or a "Abort" button.  The other "switching" controls look like things you "switch" (a toggle) or have a "bistable" indicator (like a light which is either On or Off -- if it "blinked" momentarily because of a latching mechanism, you might not even see the (momentary) changed state.

Bob Schor

[altenbach]

---

@Dfturner42 wrote:

 I am posting to get any feedback or tips to improve future VIs that I make.

---

A few more overall comments:

• As others have already said, learn about the various mechanical actions.
• Counting is done with integers so there should not be any orange wired anywhere. Should be all blue
• Don't make the front panel and diagram fill the screen. Nobody wants to stare on huge white-space areas. That screen real estate is better used for the online help.
• It would be significantly cleaner to keep the wires anchored to shift registers horizontal and limit the number of wire bends. Code would be much easier to follow.
• Consider using a typedef'd enum instead of strings for the state variable. It guarantees that all states exists and there is no possibility for typos.
• Your VI cannot be stopped, just aborted, so all the code to the right of the while loop can never execute.
• Unless run=TRUE, you have a greedy loop that consumes 100% of a CPU core, spinning the loop like mad! (same for some other states).
• All boolean output tunnels should be "use default if unwired", eliminating all these FASLE constants.
• You should only have one input tunnel into the outer case structure for the counter.
• You can simplify your comparisons.
• Your 1000ms wait is duplicated inside all cases of the innermost case structure so it belongs outside of it.
• All other states also need a reasonable wait.
• a 1000ms wait is almost too long for a responsive program, consider spinning faster and measure elapsed time to decide the next state.
• Avoid right-to-left wires for clarity.
• All controls (run, start, count) should be in the toplevel loop, not buried inside structures. (even more important once you use latch action). It can lead to surprises if e.g. the start button is pressed before the run button.
• The count control should have a reasonable default value. Zero seems not useful.
• I don't see any reason for the RUN button and the outer case structure. What's the purpose?
• I think the entire logic is overly complicated. Can you explain the detailed  requirements of the program?
• etc....

[altenbach]

At this point, I would get rid of all the instrument IO and do a pure simulation until all the logic is worked out. Here's a very simple draft that is probably not operating correctly as needed (because I don't have all the requirements!!!), but should give you some ideas at simplifications. (It definitely need more stuff, e.g. decide what should happen to the count if start is pressed during a sequence or if that's even allowed. Make sure to reset all outputs when the program stops, etc. etc.)