RavensFan -- you are (not surprisingly) correct about the Feedback Node and that Option setting. So where is the Cycle? I don't see it, but then, there's a Stacked Frame Sequence, where wires go in and out "chaotically" (instead of neatly through Shift Registers or Tunnels, and can be arranged to encourage straight parallel wires, making inputs and outputs "obvious", another reason that NI "banned" the Stacked Sequence Frame to discourage such chaos).
Almost all of the Frames (all but Frame 5) appear to do almost nothing, setting or getting a few (often Local) Variables, or Property Nodes, most with no "wired" (from outside) inputs. Frame 5 has massive code, many inputs, but because they are in a Frame structure and not straight, it is extremely difficult to say what the wires coming into the Frame are originating outside the encompassing Case Structure.
Assuming that this code is supposed to do something reasonably important, and will need to be maintained and possibly modified, I would urge you to do the following:
- Isolate Frame 5. Starting from the center and working outward, start encapsulating code elements into sub-VIs to begin to bring Order out of Chaos.
- Try to identify a "function" or a "reason" for each bit of code that you make into a sub-VI. There is something called the Single Responsibility Principle that says (I'm paraphrasing) "A Sub-VI should do One Thing and Do It Well". Give your sub-VIs Icons (a simple Box with 3 short text lines is fine, "Find Max" or "Fit Sine" or "Get Final Value", so you'll be able to "see what is happening" by reading the Icons of the sub-VIs lined up sequentially on the Error Line.
- Use the default 4-2-2-4 Connector Pane on all of your sub-VIs, with Error In and Error Out at the lower corners. Use the Error Line.
- Keep your wires as straight and horizontal as possible.
- Your goal is to have many fewer wires (can you say "Cluster"?) and code (sub-VIs and wires) that fit in a Laptop Screen.
- Rather than using Local Variables as though they were, say Matlab or C variables, and causing some confusion by reading and writing them in multiple Frames, why not use a wire (strung between Shift Register terminals) as the Variable? Wires (in LabVIEW) are for Data, and Loop + Shift Register = Memory.
Note that this "advice" can be summed up in two words (which I have said to some of my LabVIEW colleagues, most of who are still speaking to me) -- Start Over! The steps above are one way to "replace from the inside .out", but it is often easier and more effective to design from the "outside in". But do keep the Single Responsibility Principle in mind -- at every level, you want to say "What does this Code (or sub-VI) do", and "bury" inside it the Messy Details of How it does it. As you start coding the How, see if that can't be broken down into simpler "One-Thing" Steps. Simple Code is Simple to Test, Simple to Understand, and Simple to Debug (but it might be so intuitively obvious that it needs no debugging). Building the next level from known Simple Code That Works ultimately leads to Top Level Code that Works.
Bob "Philosopher" Schor
