Help/Ideas on Cleaning a Section of Code

[BaggettBagel]

I have a state machine in relatively clean condition, but the “take measurements” state is quite messy and would like some feedback on making it more readable/useable for others coming in after me.

The program takes a list of steps in a sweep, takes the measurement at each step, outputs to a graph, repeats based on the number of cycles given, and if enabled repeats all of that for each step in the sweep of a back gate/power supply. Based on whether the back gate is enabled or not, output is altered slightly, which is what the case structure on the bottom half is for.

I've considered changing/reordering my data control/type def file, but I'm not sure if making any one of the clusters more compact would be a good idea, or which bit of data would work best in which cluster.

I also need to attach the error output of the measurement VI to the loop's stop condition, as well as the error stream below, but I wanted to attempt to tidy up before adding any more to the mess.

I've attached a screenshot of the state in question, as well as an edited version of the program containing only the state in question, hopefully it would be enough but I don't know how helpful or broken it will be without the custom VIs (I've never posted code here before). If having more of the code would be helpful, I might be able to post, but I'm not sure how much of it you'd want. I also don't work every day but I'll try to respond asap.

[BaggettBagel]

I forgot to mention a question I had; I want to get rid of the feedback node at the output of the 2nd loop, but the only method I could think of to get rid of it would be to add a flat sequence, and cut the case structure up into two case structures, but I'm not sure if the 2nd call to the boolean would be worth it performance wise. Which would be better, removing the feedback node, or keeping the single case structure?

[altenbach]

Sorry, posting by phone, can only look at picture.

You feedback node got probably auto inserted because you have a circular dependency. The lower loop depends on output from the upper loop stack, but that depends on output from the lower loop. You need to enforce proper data flow, and that has nothing to do with cases and sequences.

Sorry, cannot say more, because I can't tell what's in the other case.

[dsb@NI]

if you use two case structures, one around the *Output DC* subVI and another around the *Append BG subVI, you can remove the feedback node.

other minor feedback:
replace these:

with unbundle and bundle by name equivalents 

---

This is an atypical pattern; I would expect you to write to the local before the sweep and write to the indicator after the while loop, but you do you.

---

Definitely connect/merge errors that might be generated by your subVIs. 

[Yamaeda]

Sometimes it be like that. You can remove the 1st unbundle, the Unbundle by name can point to sub elements directly. (Same for the bundle at the end, you can point to full clusters, sub elements and whatnot)

You can remove 1 inner for loop by combining them, if you feel that makes it easier to read. Just multiply Cycles and Steps and use a Modulo to extract Current step and cycle.

[dsb@NI]

---

@BaggettBagel wrote:

I forgot to mention a question I had; I want to get rid of the feedback node at the output of the 2nd loop, but the only method I could think of to get rid of it would be to add a flat sequence, and cut the case structure up into two case structures, but I'm not sure if the 2nd call to the boolean would be worth it performance wise. Which would be better, removing the feedback node, or keeping the single case structure?

---

REMOVE THE FEEDBACK NODE!

You don't have to add a flat sequence as dataflow will make sure those inner For Loops run after the output is updated.

[Yamaeda]

If you split the Case into 2, you can remove the Feedback node. Now you'll return old/offset values.

[dsb@NI]

I trust the OP to get previous/current/next right.

That feedback node kills readability for me.

[altenbach]

---

dsb@NI wrote:

I trust the OP to get previous/current/next right.

That feedback node kills readability for me.

---

I still believe that the feedback node got auto-inserted and that option should be off by default. There are several ideas explaining why LabVIEW should never do that! (start reading here and the links to other discussions/ideas). Please kudos all!

LabVIEW should never alter and convolute dataflow just to "fix" a broken run button!

[Yamaeda]

---

dsb@NI wrote:

I trust the OP to get previous/current/next right.

That feedback node kills readability for me.

---

I'm not so sure OP realised the output from the Feedback will be 1 behind.