LV Style guidelines for large scale machine automation ...?

[MogaRaghu]

I have been asked to ( possibly ) do some corrections to a machine code. This machine is a large gear box testing machine that runs 24/7 is various user selected modes. Been in operation for almost 7 years now and still running. 

The vendor who wrote code for the machine is not there now and we have been asked to bring in some upgrades ... the source code is there. Its done in LV20017. But one look at the code made me rethink if its even possible to start. No comments of any kind and it was even a challenge to fit visible code in the width part of the monitor ( you can then atleast scroll up/down) 

For large level automation ( the machine has four PCI cards and three of them are multifunctional ones ) does it always get this messy ? ( OK somethings cannot be small but even then we make it such that the width is well within the monitor width. ) 

I am just attaching two snap shots ...for comments 😉

[softball]

Hi

I will not comment on the general development strategies one can use. Won't help you with this problem.

But looking at the screen dumps then I don't see much 'action' in the code. Just a mess of wires, long and short, going in all directions.

If I should do anything about this I would mentally consider this as a variation of a Tetris game. Here, move things around until the wires are as short as possible and follows the dataflow principle, left => right. As few wire breaks as possible. All the classic advice's for old school LabVIEW programming. You may temporary need a big 8K display to stretch and still view everything. But once organized then you can compact the code into a manageable size.

All the vertical lines are a sure sign of an initially small design where the coder then ran out of space to add code and then simple wired off into unused space.

After this interesting work ( it's a game ! ) it should be much easier to figure what the code actually does. Hopefully.

Regards

[crossrulz]

I have done several large projects and they do not devolve into a rat's nest like that.  My first thought here would be to break up this mess into smaller loops, each taking care of a single thing.  For instance, I would have a single loop to just do the saving of the test results.  You communicate to this loop through a queue.  I would do something similar for each DAQ task.  This allows you to modularize each task into its own VI and turn your top-level code into something pretty small.

[Minions]

Also, one could create some sub-vi's containing many of these case statements to help clean up this layout.  This would help to identify the Left-to-Right dataflow; this allows for standardizing inputs to the left and outputs to the right.

[aputman]

My company received a VI from a vendor that looked very similar to this (yours is much worse).  It was one large VI where the main portion of the code was in a big while loop and all of the button actions were put in case structures scattered throughout the code.  One of these days, I would like to remake this VI using a proper state machine but, by some miracle, the software works as is and I have no immediate need to mess with it. 

How I would go about this monumental task that you have before you:

• MAKE A BRANCH OF THE CODE IN YOUR REPOSITORY (MANDATORY)
• I highly recommend learning the JKI State Machine (string-based state queue).
• Many of these case structures that I see in your code can be (easily???) converted to states.
• Throw all of those variables into data clusters, grouped by their function. 
• Break the core functionality of the code into multiple states...don't put it all in one state.
• Create some macros (sequences of states) that define the core functionality of the code.
• Do not use long-running loops in state machine.  Instead, call the macro repeatedly.
• Document as you go because it will be a learning process for you to understand the code.
• Don't add the new functionality until this refactored code is working as intended.
• A small amount of scrolling is acceptable for me.  I try to limit the scrolling to vertical only.

[Yamaeda]

Sub vi's are a thing ...

[softball]

Hi again

Interesting responses to the problem situation described and shown in screen dumps.

To the other responders : Do you really want to change the code introducing new loops and whatever before even knowing what the code does ?

I would never ever change the code, unless I know what it does. Never break the actually functional code. Just move items around until the code makes sense. It may require a really big screen in the process, but so be it. Only then change code.

This have been so for me since 1995.

Regards

[crossrulz]

---

@softball wrote:

To the other responders : Do you really want to change the code introducing new loops and whatever before even knowing what the code does ?

I would never ever change the code, unless I know what it does. Never break the actually functional code. Just move items around until the code makes sense. It may require a really big screen in the process, but so be it. Only then change code.

---

Most of the responses were based on the question of whether or not "large" projects always just turn into this rat's nest.  So it was more of a "The original developer should have structured this program better."

With that said, whenever I am handed a program like this, I usually insist on having at least a full week just for understanding the current code.  After that, I will make my suggestions as far as a refactor or complete rewrite.

[Kyle97330]

---

@Minions wrote:

Also, one could create some sub-vi's containing many of these case statements to help clean up this layout.  This would help to identify the Left-to-Right dataflow; this allows for standardizing inputs to the left and outputs to the right.

---

I was going to suggest something similar but there are a few problems with that based on what I can see from the screenshots.  The two big ones are use of local variables/terminals inside case structures, and the large amount of input wires to the case statements as they exist now.  If you were just to use the "Create subVI from selection" function it likely wouldn't work because it would be over the limit for the number of wires currently entering and exiting the various structures, and local variables/terminals currently inside the case structures would make this even worse as the "Create subVI" operation attempts to replace them with a by-reference Value property node, which requires yet another input wire for the reference.

So I would actually start with the wires.  Just start seeing what can be bundled together into clusters and start using those.  It'll remove some of the spaghetti from multiple wires, but add space for the bundle/unbundle nodes.  The nodes would give an extra benefit of adding some small amount of "documentation" in that you can see what a wire does by its name visually at the Unbundle by name node instead of having to trace it back to where it came from.

For the local variables and terminals inside assorted case structures, I would suggest creating a messaging system of some kind in a separate parallel loop.  Instead of writing to the terminal or variable directly, it would enqueue a message to the loop that would then put the value into the appropriate control/indicator. 

If you can manage both of those, then for any structure that you can get down to having a reasonable amount of wires connected to it, turn that into a subVI.  I would define "reasonable" as being no more than 14 inputs/outputs combined, with no more than 10 of those being one of the two types.  That would allow you to make a subVI as a 5-3-3-5 connection pane without having backwards wires plus also having a spare input and output for error wires since most of the diagram doesn't appear to have those.

[Quiztus2]

Even if so far I only refactored my own code, it took me always much more time than I have expected. 
How do you make sure that your refactored code works the same than this mess?

This smells like a potential economical desaster.

I would think which hardware resources your new functionality would share with this spaghetti and cut only this hardware control out of it into a FGV . Then I would create the new functionality next to this mess in a seperate module in order to leave as much of this mess as it is.