LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Very complicated labview block diagram

 

Hello,

 

I've taken over the development in LabView of a break tester program for heavy trucks. As you see in the attachment the block diagram is very complicated and intricate. I don't know if I manage to go on with this code. I think maybe we should start all over again to make the code and program much more efficient. Today, the program still works OK.

 

Please see the attachment and give me an advice what to do; Either start all over again or work on the same code. What would you do? 

I'm used to build program with an event driven state machine. Just ignore the error messages when opening the program.

 

I hope you can advice me what to do.

 

I can mention that the program has like 150 subVI's!

 

best regards,
Paal
 

0 Kudos
Message 1 of 15
(4,515 Views)

I've not yet received our LabVIEW 2015 distribution, so I can't take a look at your "very complicated VI".  I can tell you that I took over a program written in LabVIEW 7.0, with 770 VIs and 196 TypeDefs to one written with LabVIEW 2012 having 870 VIs and 148 TypeDefs.  The original code was completely undocumented (no Description entry on any VI), some of the VIs were huge (>20 screens required to see it all), while the new routine follows the following principles:

  • Every VI has an Icon to make it easily identified on the Block Diagram
  • Every VI has a Description listing the Inputs, Outputs, and main purpose
  • With very rare exceptions, every VI's block diagram fits on a single screen

Since the code was developed, we've gone through three additional Version changes (it's controlling a behavioral experiment, and the Experimenters wanted to do new and different things.  Development of the new versions took typically 2-3 weeks to complete, including updating the analysis software to allow it to work with data files from the current and earlier versions.

 

So don't be afraid of multiple VIs.  The question is does an individual VI have a well-defined function, is there sufficient documentation that you (or someone else) can understand how to utilize it in a new situation, and do the various VIs "play well with each other".

 

Bob Schor

Message 2 of 15
(4,497 Views)

Hello,

 

I've attached a picture of main block diagram taken with the navigation window. You can have a look at it if you want and give your opinion..

 

br,
Paal

0 Kudos
Message 3 of 15
(4,464 Views)

You must have huge monitors.

 

The shown window  (the white part of the navigation window) would only be able to show perhaps one of your bigger loops and everything else would be off screen if I opened your code on my computer.  Your window seems to be about twice as big both vertically and horizontally.

 

I don't see that many subVI's in your code.  Nothing that looks like it contains 150 subVI's.  Maybe you have a couple of NI's subVI's in there which tend to have a lot of levels below that and that is boosting your subVI count.  But I don't see but a few subVI's that were created by the original programmer

.

 

Work on getting rid of those stacked sequence structures.  There is also an unhealthy dependence on local and global variables.  If you have a lot of data to store that needs to be accessed by multiple parts of the program, use a functional global variable or action engine.  Then you'd be able to access that data in the new subVI's you create and not just at the top level of your program where you have the local variables.

 

0 Kudos
Message 4 of 15
(4,430 Views)

Yikes!  Local variables everywhere.  Some loops that probably do not need to be separate.  Huge stacked sequence structure...

 

Personally, I would be on the rewrite bus.  This could use a good architecture review.  A lot could be done with a Queued Message Handler (using Queues or User Events to send data around instead of local variables).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 15
(4,428 Views)

Thank you for your reply. The picture is not so clear due to its resolution. But there are for instance 75 events in the upper left loop containing subVI's. There are 20 enum states in the loop next to the event loop almost each of the states containing stacked sequences (between 10 to 40 frames each ) and of course many subVI's with even more sequences. I think the whole program has to be stripped down and rebuilt.

 

0 Kudos
Message 6 of 15
(4,412 Views)

Looking at it, the one redeeming quality is that it does seem to be broken down into various modules (the various loops on the diagram). You could start by trying to convert each one of these into a single SubVI and then re-factor the SubVI to fix the broken local variables with a (queue driven) state machine and a proper communication mechanism (e.g. queues/user events).

 

Once you've done that for the modules, you can then look to tidy up the event structure to have each 'event' fire a message to the different modules and/or a 'main' command handler on the top level.

 

You definitely want to ditch most of the locals as they can introduce race conditions and lose all of the stacked sequence structures.

 

I'm always on the fence about throwing everything away and starting again - I think you need to think carefully about what problems you might introduce or hidden reasoning why something was done in a certain way when throwing everything away and in this case I think you can re-factor parts of the code at a time and then check everything still works properly before moving onto the next one.


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 7 of 15
(4,401 Views)

I think Sam is giving very good advice.  I do think your code is salvageable.

 

The fact that all the loops are using local variables or terminals tends to tie them directly to your main VI.  But setting up a message system where subVI's can report screen updates back up to the main VI will help decouple that.

 

Interesting, I have never seen local variables of error terminals used before.

Message 8 of 15
(4,391 Views)

@RavensFan wrote:

Interesting, I have never seen local variables of error terminals used before.


At a previous job it was a staple ware. 🙂 How else would you send the error information between the sequence and case frames?

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 15
(4,352 Views)

I've never needed to send errors elsewhere before.  I either showed them at the loop, logged them to a file, or usually handled them right there.  If another loop needed to know about the error, I didn't want it to know what the error was and figure out what to do.  I let the loop that caused the error determine what the other loops needed to know and send commands.

0 Kudos
Message 10 of 15
(4,340 Views)