huge block diagram

[monmouth]

I have inherited a VI which has a huge block diagram meaning that I would have to hold and drag the mouse for at least 15 seconds to get from the "left" to the "right".

How do I connect something from the left to something on the right?

The guy was using global variables.

[GerdW]

Hi monmouth,

refactor that VI to reduce the block diagram size. Much better than wiring from left to right in a huge diagram...

[monmouth]

That's not an option because the front panel must be unchanged.

It is a VI that processes 100+ bytes and uses the bits and bytes to set LEDs and other items on the front panel. I would say at least 200 elements.

.

[GerdW]

Hi monmouth,

you don't need to change the frontpanel while changing the block diagram...

Handling "100+ bytes" is nothing. Even a simple CSV text is usually way bigger...

Having 200+ elements on the front panel might sound big, but can be a sign of bad UI design. (But that fits to a huge block diagram and being unwilling to improve it.)

[RavensFan · Accepted solution]

You can create subVI's without changing the front panel.. Layout of the front panel is not determined by the size of the block diagram.

What you can try, if you really want to continue down this route, is you can start a wire and click on the block diagram to leave it hanging broken.  Then scroll the window.  Then click on the wire and start stretching if further until your almost run of the screen and tack it down to the block diagram again leaving it broken.  Do that for however many time you need to.

Another possibility, create a small structure like a single frame flat sequence.  Connect your new wire to that creating a tunnel.  Then you can drag that structure across the block diagram (scroll, drag, scroll drag,) until you get it close to where you need to go.  Wire through the sequence, then into your destination.  Then remove the sequence frame.  You'll basically being using ti to anchor down your wire and stretch it for you.  The previous idea runs the risk that your dangling wire winds up accidentally disappearing after a mis-click.

With either idea, when done, right click the wire and chose wire cleanup.

[Kevin_Price]

1.  I like RavensFan's suggestion of anchoring the wire to something to prevent losing it as you scroll & drag.

2. If you didn't already know this, once you drag something far enough to make the screen scroll, you can speed up the scroll rate by holding down the <SHIFT> key.

3. Tales from the trenches (in 3-part harmony dissonance):

a. I have also inherited a few pieces of semi-monstrous code.  At times, the expedient course of action was to hold my nose & let the code stay monstrous while making the smallest possible modifications.  

    Caution: this hasn't always worked out nicely.  With such code beasts, minor changes can result in significant and hard to anticipate side effects.

b. Another approach is to try to refactor and modularize the code.  To do this well requires you to gain a solid understanding of both how the code functions *and* how it's structured.

    Caution: this might be a waste of time.  Usually, code that spans across so many screens was never structured coherently in the first place.  Sometimes code sprawl is so far gone that it just isn't worth the effort to tame it. 

c.  When you find yourself spending a lot more time tracing through code to see *how* it does things rather than spending time understanding *what* it does, that can be a signal that it's time to just rewrite the thing from scratch.

    Caution: this might be a waste of time too.  Modifications may be risky, but there's at least a chance of seeing quick success.  A total rewrite raises the floor on the time you'll spend fixing code, and there's no guarantee that it lowers the ceiling.

-Kevin P

your little bluebird of happiness

[monmouth]

---

@Kevin_Price wrote:

1.  I like RavensFan's suggestion of anchoring the wire to something to prevent losing it as you scroll & drag.

2. If you didn't already know this, once you drag something far enough to make the screen scroll, you can speed up the scroll rate by holding down the <SHIFT> key.

3. Tales from the trenches (in 3-part harmony dissonance):

a. I have also inherited a few pieces of semi-monstrous code.  At times, the expedient course of action was to hold my nose & let the code stay monstrous while making the smallest possible modifications.  

    Caution: this hasn't always worked out nicely.  With such code beasts, minor changes can result in significant and hard to anticipate side effects.

b. Another approach is to try to refactor and modularize the code.  To do this well requires you to gain a solid understanding of both how the code functions *and* how it's structured.

    Caution: this might be a waste of time.  Usually, code that spans across so many screens was never structured coherently in the first place.  Sometimes code sprawl is so far gone that it just isn't worth the effort to tame it. 

c.  When you find yourself spending a lot more time tracing through code to see *how* it does things rather than spending time understanding *what* it does, that can be a signal that it's time to just rewrite the thing from scratch.

    Caution: this might be a waste of time too.  Modifications may be risky, but there's at least a chance of seeing quick success.  A total rewrite raises the floor on the time you'll spend fixing code, and there's no guarantee that it lowers the ceiling.

-Kevin P

your little bluebird of happiness

---

I like RavensFan idea too.

But I had a good chuckle with your tales from the trenches. I can totally relate.

[Bob_Schor]

My two biggest jobs involved monstrous Block Diagrams (I printed one out just to see all of it -- at half-size (so one page as printed = 2 x 2 = 4 pages at "normal size", I ended up with 10 pages across and 2 pages tall.  I definitely started over.  Took a bit of time, but we ended up with (a) code that worked, (b) code that collected data twice as fast, (c) code that didn't throw errors every few minutes, (d) had a much cleaner and clearer data structure (both for configuration and for outputting data), and (e) was easily modified to admit new stimulus and recording paradigms.  And did I say that everything was documented (because I wrote the VI documentation as I wrote the VIs)?

If you have a sufficiently huge problem, if you understand what needs to be done (it helps if you can write down the major requirements), and if you have some time to do the job right, "Starting Over" can be a big Win.

Bob Schor

[pallen]

One thing that might help tackle the "sprawl" a little at a time is to make use of "Create SubVI" in the Block Diagram Edit Menu.  

Before making any changes to complicated code though, I would bring your project into some kind of Source Code Control if it isn't already.  I like TortoiseSVN.  

Commit your code often, and comment your commits.  This way, if you break something and can't track down what happened through the mass of code, you can very easily roll your code back to before you made that change.  

[billko]

---

@pallen wrote:

One thing that might help tackle the "sprawl" a little at a time is to make use of "Create SubVI" in the Block Diagram Edit Menu.  

Before making any changes to complicated code though, I would bring your project into some kind of Source Code Control if it isn't already.  I like TortoiseSVN.  

Commit your code often, and comment your commits.  This way, if you break something and can't track down what happened through the mass of code, you can very easily roll your code back to before you made that change.  

---

A little caveat about this is if the code is poorly written - which is likely, given the problem being solved - making a subVI from existing code may force dataflow, eliminating a race condition that needed to be there.  My code, which usually consists of many simple modules - isn't very susceptible to this, but with huge, sprawling code, it could be a significant worry.