Block Diagram is not working properly

[wiebe@CARYA]

---

@akara wrote:

I do not understand what you mean. 

Where are you referring to now?

---

LabVIEW.

[wiebe@CARYA]

---

@akara wrote:

Does LabVIEW have a limitation on the amount of graphs that can be used?

Probably (maybe 10000? maybe 100000?). But that's a new question that should be posted in a new thread.

---

@akara wrote:

What about the case they are placed in different tabs, so the amount of pixels remains low?

---

Where is this coming from? We're talking about your diagram that is too wide. Why are you bringing up entirely new and unrelated subjects?

[wiebe@CARYA]

---

wiebe@CARYA wrote:

---

@akara wrote:

I do not understand what you mean. 

Where are you referring to now?

---

LabVIEW.

---

But seriously, can't bring it easier than this:

Right click those flat sequence frames and convert to stacked sequence frames. Then remove the excessive space with ctrl+alt+mousedrag, or automatic diagram clean up.

The flat sequence frames are those things that you've (mis)used a lot.

[Bob_Schor]

Oh, boy -- I have to (again) agree with Wiebe when he wrote "An absolutely very bad, bad, bad advice (bad), without any doubt."  Unfortunately, he was referring to his suggestion that you turn your (totally-unnecessary) Frame Sequence into a Stacked Frame Sequence (I see there's another thread to ban this Structure -- you probably don't even know what it is because a "partial ban" is already in effect ...).

So there are two issues.  One is the Frame Sequence.  Frames are almost never necessary, particularly if you make use of the Error Line to impose order and sequencing on your code.  The other is the obscene "shape" of your code -- a little too tall, but 30 screens wide?  Impossible to navigate!

Two techniques to "collapse space".  One is to make use of sub-VIs, which take a 32x32 pixel of space on the Block Diagram (which means that on a 1280 x 1024 screen, you can easily place 20 across and 16 high and still have a VI's worth of space between them.  The other is to make use of a Loop + Case Statement structure to "stack code vertically". 

For example, suppose you had three things you wanted to do.  Drop a For Loop and wire 3 to the "N" input so it loops 3 times.  Put a Case Statement inside it, wire the Case selector to the loop Index "i".  Put the code for the first thing in Case 0, Default, second thing in Case 1, and third in Case 2.  These three code segments live "on top of" each other on the Block Diagram.  You can use Shift Registers to pass data from one Case to the next.

Have you heard of a State Machine?  That uses the same principle, a Loop with a Case inside.  LabVIEW has many examples of Loop+Case structures -- it is one of the more common things you'll see in well-designed LabVIEW code.

Resist the temptation to "just start coding, letting things expand as they need and not worrying how it looks, and certainly not planning in advance and organizing your thoughts".  Spend a few hours studying the LabVIEW tutorials and looking at examples of (good) LabVIEW code that do simple tasks -- see how others have used sub-VIs and LabVIEW Structures (without Frames!) to accomplish useful things.

Bob Schor

[altenbach]

Most of your code is a long collection of duplicates that only differ in a few inputs. You only need one instance of it. Unless you are paid by the size of the diagram, your architecture is a very bad idea. It's like buying a new car every time you need to drive to the grocery store. One is enough!

The main reason you currently need the sequence is the fact that you overuse local variables. Once you eliminate them and use wires, the execution order is directly defined by the data dependency and very little can go wrong.

All you need is four graphs and instead of placing dozens of graphs on different tabs, us a single tab and a selector (ring, listbox, radiobutton, shallow empty tab control, etc.) to select which data to show, always re-using the same graphs. If you cannot look at all graphs at the same time anyway. Use a proper event driven UI loop that senses selection changes and updates the graphs accordingly while keeping the UI responsive at all times. If these atomic procedures take a long time, they should execute independently and in parallel.

Changing to a stacked sequence is just putting lipstick on a pig (actually it is worse because it will let you continue spiraling down the same wrong path for a few more iterations until you hit a brick wall anyway!). You have a fundamental conceptual and architectural problem that needs to be solved from the ground up. Imagine you notice a coding error in a small part. If there is only one instance of that code, fixing it is easy. In your case you would need to correct the same mistake in dozens of locations, taking you hours instead of minutes. 

[billko]

---

@altenbach wrote:

Most of your code is a long collection of duplicates that only differ in a few inputs. You only need one instance of it. Unless you are paid by the size of the diagram, your architecture is a very bad idea. It's like buying a new car every time you need to drive to the grocery store. One is enough!

The main reason you currently need the sequence is the fact that you overuse local variables. Once you eliminate them and use wires, the execution order is directly defined by the data dependency and very little can go wrong.

All you need is four graphs and instead of placing dozens of graphs on different tabs, us a single tab and a selector (ring, listbox, radiobutton, shallow empty tab control, etc.) to select which data to show, always re-using the same graphs. If you cannot look at all graphs at the same time anyway. Use a proper event driven UI loop that senses selection changes and updates the graphs accordingly while keeping the UI responsive at all times. If these atomic procedures take a long time, they should execute independently and in parallel.

Changing to a stacked sequence is just putting lipstick on a pig (actually it is worse because it will let you continue spiraling down the same wrong path for a few more iterations until you hit a brick wall anyway!). You have a fundamental conceptual and architectural problem that needs to be solved from the ground up. Imagine you notice a coding error in a small part. If there is only one instance of that code, fixing it is easy. In your case you would need to correct the same mistake in dozens of locations, taking you hours instead of minutes. 

---

Not to mention that, in all likelihood, you're bound to miss at least one instance.