blcok diagram zoom - suggestion

[GlenS]

I've been writing a large (I think, anyway) program recently and I've run into the issue of an ever-expanding block diagram.  I'm at the point where I'm inserting code that is really not a problem to write (i.e. it's run-of-the mill and I don't care whether or not I can see it in the overall picture)  but the block diagram will be extensive and is going to make the diagram for the current program even more unwieldy.  This code is only required once in my program so a sub-VI doesn't seem waranted.

What I'm after is comments on the idea of block diagram "zoom" or "code-port" to tackle this problem.  Basically this would work like the mathscript structure already does, i.e. inputs and outputs but you can resize the box how you want and you don't have to see all the code inside.  Double click on the box and the diagram is zooms in to that portion of the code, and then you can zoom back out.  This way you don't have to blow up your block diagram to unreasonable proportions with uninteresting string-assembly code etc.  Does something similar already exist?  Any suggestions?  If not I'll submit it to the product suggestion page.

[Mark_Yedinak]

Why not use subVIs? Either way if you application is getting to the point that you can't fit on a single screen then you probably need to clean things up. Good code is never monolithic, whether it is C or LabVIEW. It simply becomes very difficult to understand. Good use of subVIs helps to make the code more readable and maintainable.

[GlenS]

Point taken, it just seems like a waste to have to name a file, design an icon and specifically put in and wire controls and indicators for such a simple function.  There is also the issue that variable access then requires the establishment and use of shared variables rather than the much easier (and presumably faster and less resource-hungry) local variable.  It also seems to confer too much importance to the function.  All I'm doing is assembling a header string to write to a file, it seems like rather more work than it should be.  I think the system I'm proposing would be a useful alternative to making a sub-VI and would clean up the block diagram in much the same way.  I suppose I'm thinking of it in a way similar to the "conditional disable" structure.  It's not strictly necessary, but it sure can make things quicker and easier at times, and as I understand it quicker and easier is big part of what LabVIEW is about.  Do you still disagree?

[Mark_Yedinak]

For the most part yes, I still disagree though I do understand your point. I generally avoid using local variables so I don't run into the issue you are describing. If you are using lots of local variables this would also indicate that your overall design is suspect. LabVIEW is a data flow language and the design should rely on wires more than on local variables. There are tons of discussions on why it is a good idea to avoid over using local variables.

A bread and butter design for a LabVIEW application is a state machine. State machines are very flexible and easy to modify. They help to describe your system better as well. They make it easy to use the actual wires rather than lots of local variables.

Again, the same comment I made earlier about designing your system to be modular applies. From the sounds of it your design is rather large and monolithic. Without seeing the code I can't be sure. You would be surprised how often you start to reuse code if you start thinking in terms of smaller pieces. Over time you end up developing reuse libraries of code. Even if you don't directly reuse the code you can start to develop application templates that are comprised of similar components that you do modify for a specific application. However your applications start to have a common look and feel to them not only from a user perspective but from a code perspective as well. In the specific example you state here you could have a standard "Format Report Header" VI in your applications. The actual header would vary from application to application but it would be very clear on your block diagram what you are doing. It is much easier to look at a block diagram and understand what "Format Report Header" is doing then to figure out what a bunch of string VIs are doing and what purpose they server. If you used your approach to minimize or hide the code you would still need some indicator such as an icon to give you an idea of what is happening. At this point you are basically at the same point as creating a subVI.

[gchristi1]

I had the problem with ever expanding block diagrams until I started to use state machines and the queued message handler found in the shipped template. I always change the queued message handler because taking messages off the back seems backwards to me, but maybe I'm dyslexic.

[GlenS]

I see what you're saying.  I agree, my code is large and somewhat monolithic.  I have not yet investigated state machines but will definitely do that very soon.  I definitely do use too many variables, certainly more than I am comfortable with.  I'm still somewhat new to LabVIEW and having learnt to program using traditional procedural and OO languages the common form of LabVIEW programs that you allude to is somewhat elusive to me.  Thanks for the input.

[PJS]

Not sure what is meant off the back?  The queued message handler is a FIFO.  You never take off the back, however you can enqueue something to the front if desired. 

There are several threads with different variations of both the queued message handler and traditional state machines, but at the core both accomplish the same purposes and within a genre, they pretty much work the same with differences in implementations of the 'base' code.  But it is a bit of a learning curve to avoid 'tying' up the system such that the user interface is not serviced in a timely manner or to see how to avoid using local or global variables... OR to avoid running 10 trillion wires through shift registers.  But it does come, and in the long run, you will have much more maintainable and easier to understand code.  

If you are interested, on top of the example in the NI example finder, I have another implementation of the core achitecture of a QSM, follow the link in my signature to grab it if you like.  Also there are other forums hosted on other websites that have similiar templates you can use, each with their own pros and cons.  So shop around.  The more architectures you can at least look through, the better your understanding will be, and the easier it will be to solve issues within the architecture you choose to utilize.

-p

[GlenS]

Cheers!  Am pilfering your work right now.  🙂

[GlenS]

I've looked at the example and done a bit of reading and as far as I can see the program I've written is already a state-machine (see attachment, Main.vi - n.b. program incomplete).  I don't really understand the queue business and hence haven't implemented that (does anyone want to explain it in 25 words or less?) and your example uses an extra case structure while mine only uses the event structure but as I see it my program does the same thing as a state machine: it sits in the waiting state until the user does something and then responds.  Am I correct?  If not what am I missing?  Also, I've highlighted the section where I need to insert the code.  I already have a sub-VI to auto-create a filename so like as not I'll put the header/file writing in there but again this is an afterthought and I think could be more easily (and perhaps elegantly?) dealt with by my suggestion.  Thoughts?  Thanks for all the responses by the way, I'm learning a lot and appreciate the input.

Message Edited by GlenS on 11-16-2009 09:10 PM

[jcarmody]

You can wrap your uninteresting code in a Flat Sequence, turn Auto Grow off and shrink it.  Then, when you want to look inside you just resize it (or, turn Auto Grow back on).  I've heard of that being done, with the developer pleased that the entire program fit on one screen!

(EDIT: Please note this is a sarcastic comment. Read the next page for details)

Message Edited by Support on 11-18-2009 08:35 AM