How NOT to code large applications

[Michael Aivaliotis]

I vowed then never again to criticize code like that in public unless the person who wrote it was there and had told us to pull no punches. Good grief, I'd hate to have to critique the first couple of VIs/project that I did.

I agree and do not critize code, and believe me I see lots of LabVIEW code. I say any code that works is beautiful.

I do take the gloves off when the client is in the difficult situation of think a 'few minor tweeks' are all that is needed to add: User log-in, data basing, etc.

I say let them have it! People who've been programming in a bubble all their lives need to be shaken up. I'm sorry, how else are we to improve the overall quality of the stuff we have to dig through on a daily basis. Let's say it like it is. It's crappy code. I sometimes see it here on the forums too, people parlaying "advanced" read: obfuscated, programming techniques.

My answer to customer's requests for feature additions to existing badly written code: No problem, anything can be done (it really can). It will only cost you x dollars. If they disagree, all the better, I need my weekends for personal time, not for digging through some interns "learning" project. I just hope if you are the programmer who ends up doing the fix that you are honest with the customer about the amount of work required. Let's not whore ourselves out to the lowest bidder.

Bottom line, as long as I have breath in me I will educate and preach proper programming standards, regardless of the audience response. Hopefully, if enough of us blow in the right direction, we can start a wind of change in the world of badly written LabVIEW code.

[Barrie]

Hear! Hear!

I would rather be despised for my opinons, than for not having any.

Barrie

[Phillip Brooks]

I say let them have it! People who've been programming in a bubble all their lives need to be shaken up.

I agree. It doesn't have to be a blast from a shotgun with both barrels, though. I recently demonstrated the fact that you can expand the Index Array function to someone. He had 12 discreet Index Array functions connected to the same array, with one index input to each. They were indexing elements 0-11. I showed him a "trick" and he nearly fell out of his chair. This is someone who has been programming in LabVIEW for 6 years. He's also fond of globals and locals and sequences that nested 5 and six deep ; he blows up when he can't create a sequence local in my code to move data around.

I feel like I've got a good handle on all the features/functions of LaBVIEW (5 years+ I just completed the Intermediate I & II classes) and now need to think at a higher level. Many LabVIEW users are just that; users. If you need to create sequence, then a sequence is what you must use! Sort of like an apprentice tradesman; if the only tool you have is a hammer, then everything looks like a nail!

[alphaone]

Eventually,

You'll get to the point of being asked to fix some existing LabVIEW code. Although this is not the worse I've seen, the sheer size of the block diagram is spectcular!

Even on my wide-screen laptop 17" it still is several screen wide.

Notice the liberal use of local variables! :headbang:

Now I develop by this structure" TestStand + LV".

Because TestStand can provide a "Frame" for your testing flow.But ,in LV,the control of test flow is so complex.I use LV just to develop a test case.

[skfink]

my current project (my first) is measured in pixel around 8000 Pixel in width and maybe 1200 heigh.

Of course I could create some subVI's, but it's quite difficult to seperate the code because everything affects everything.

I would like to upload a picture, but my screen has "only" 1440 x 900 Pixels and I'm not going to take 12 Screenshots

[Louis Manfredi]

Of course I could create some subVI's, but it's quite difficult to seperate the code because everything affects everything.

Hi Skfink:

Programs where everything affects everything are very scary :!: When I've written such programs, they rarely work the first time I try them, and tend to get worse the more I work on them :ninja: ... I usually end up chucking the whole thing, and carefully re-defining my objectives in a way that they can be broken down into somewhat independent logical chunks (sub-vis) that interact with each other in fairly straighforward ways.

Don't be afraid to bundle logically related wires into clusters so they can be passed between vi's without a huge amount of clutter-- The processing cost of bundling and unbundling is almost nil, orders of magnitude less than the human cost of debugging a multi-screen program. Use globals if you must (preferably LV 2 style), even repeat the same calculation over again if passing the results of a calculation around makes for clutter on the diagram--- Do whatever you have to to break the program up into modules

Good luck, but take it from an old codger, if the diagram is wider or taller than the screen, you'll need a lot of luck, and if its wider and taller than the screen, you'l probably need a lot more than just luck :!:

Best Regards, :beer: Louis

[skfink]

...if the diagram is wider or taller than the screen, you'll need a lot of luck, and if its wider and taller than the screen, you'l probably need a lot more than just luck :!:

I can hardly imagine a program that is not wider or taller than my screen. Only the loading in saving of the variables take together more than the screen. And the terminals (I dont use terminals in the code, only variables ( for better overview)) plus the initialisation with the property nodes take nearly a 2nd screen.

But thanks for advise, I will try to get rid of code using subVI's, So I have to make a lot more of my variables global.

[JackHamilton]

As I am giving lectures on Coding Architecture in LabVIEW I've been collecting these gems.

Another example of "Extreme Data Flow Programming" this is aptly named "Run Away"

[jpdrolet]

GASP! *faints*

[Barrie]

Ok, you can't fool me. You're making these up. Right?

You took a photo of a large scale IC and converted it to LabVIEW, right?

Please tell me I'm right !!

Barrie

[Steve Watts]

It must be harder to program like that, than to do it properly! :laugh:

[Nico]

That's terrific. :headbang:

I'm surpised if it works properly...

[BChandler]

I think one of NI's biggest mistakes, with LV, was to allow diagrams bigger than the screen.

Think how different code would be, if scroll bars on diagrams had never been invented!

-WDC

[Barrie]

I think one of NI's biggest mistakes, with LV, was to allow diagrams bigger than the screen.

Think how different code would be, if scroll bars on diagrams had never been invented!

-WDC

Indeed!

Sounds like a good wish list item, if not a hard limit, then at least a warning, perhaps in the VI Analyzer.

How about a diagram size limit that is password protected and you can't get the password until you pass your ACLD?

[Michael Aivaliotis]

As I am giving lectures on Coding Architecture in LabVIEW I've been collecting these gems.

Another example of "Extreme Data Flow Programming" this is aptly named "Run Away"

I hope you got paid by the wiring node...

[peteski]

I hope you got paid by the wiring node...

Maybe this is what can happen if one gets paid by the wiring node!

, then again, maybe I'm the kettle and I'm making remarks about the pot over there...

-Pete Liiva

[Wolfram]

As I am giving lectures on Coding Architecture in LabVIEW I've been collecting these gems.

Another example of "Extreme Data Flow Programming" this is aptly named "Run Away"

Great debugging challenge...

[DredPirate]

Great examples of bad code so far. But there are times that huge sub vi's are ok. I have a program that scans 100,000 samples per second for 60 seconds over 4 channels and displays all of the data on the graph (well not all of the data as I do a decimation to speed the graph). Every time I pass an array for one VI to another LV allocates memory from windows to make a copy of my data (buffer allocations is the slowest operation in LV after display updates). So I created a huge VI to create a 16 channel FIFO buffer (12 for later updates), aquire the data, and decimate the data.

I spent a good deal of time eliminating any buffer allocation I could. It may not be the prettiest thing but its fast.

I have included a small example to show just how slow buffer allocations are. Every time you build an array you allocate memory from windows.

I should post a new thread on this subject. but here it is anyway.

Download File:post-3219-1129256215.vi

[aledain]

Every time I pass an array for one VI to another LV allocates memory from windows to make a copy of my data (buffer allocations is the slowest operation in LV after display updates).

This doesn't happen under all circumstances. If you're careful about it you can reduce memory copy operations to just those at application start. IF the same wire (talking arrays here specifically) goes into and comes out of a sub-vi, then the memory is (sometimes) not copied within the sub-vi. The array is passed by reference (if you get my drift). Within that sub-vi, a copy is made only wherever a 'branch' occurs where that branch undergoes some transformation (eg branch 0, nothing; branch 1 * a constant) OR if the array is not manipulated in-place. So in the example, if you return branch 0 and branch 1 from the sub-vi then you have duplicated your data (and a copy will have been made). So if the sub-vi modifies the data, make sure that the change is done 'in-place'.

Some array tools are specifically designed to be used in place, such as the replace array element. Using these in-place tools will not force a copy of the array. Think of it as processing the arry by substitution directly into the memory itself. If you need to allocate an array within a FOR loop (for versions prior to about 6.1, I believe) the only 'in-place' way to do it is to pre-allocate, use the replace array element and truncate the array post loop.

Another thing to watch out for here is the use of indicators on the sub-vi's panel. If you run within the dev environ, then having a ~MB array branch to an indicator just for the sake of viewing the data, may mean a memory allocation, and will certainly slow your application (as you say) due to screen updates.

Furthermore, when a wire goes through a case structure, make sure at least one case has nothing happen to the wire. This (IIRC) enforces the 'by reference' passage of the data.

And while we're at it, did you realise that wiring your array into the top node of a multiple/add etc is NOT the same as wiring it from below. The top is best.

[Rolf Kalbermatter]

I can hardly imagine a program that is not wider or taller than my screen. Only the loading in saving of the variables take together more than the screen. And the terminals (I dont use terminals in the code, only variables ( for better overview)) plus the initialisation with the property nodes take nearly a 2nd screen.

But thanks for advise, I will try to get rid of code using subVI's, So I have to make a lot more of my variables global.

The solution to this are subVIs and state machines and in my case also LV 2 style globals to encapsulate specific data and its operation on them. With this you can always get diagrams that fit onto a 1024*756 screens. My LabVIEW programs involving sometimes 800 and more VIs of all sorts of complexity seldom go over this margin and if they do it is only about the outer case or loop structure on one or two sides but never real code.

An no, this does not require globals at all. I only use globals for some simple status variables such as a global application abort and application constants but never for other data variables. If I have to grade a diagram made by someone else, any globals other than simple booleans, or application constants automatically give negative points. So does not using state machines for user interface handling or not using subVIs. (and spaghetti code also scores high in my negative list).

Rolf Kalbermatter

[peteski]

This doesn't happen under all circumstances. If you're careful about it you can reduce memory copy operations to just those at application start. IF the same wire (talking arrays here specifically) goes into and comes out of a sub-vi, then the memory is (sometimes) not copied within the sub-vi. The array is passed by reference (if you get my drift). Within that sub-vi, a copy is made only wherever a 'branch' occurs where that branch undergoes some transformation (eg branch 0, nothing; branch 1 * a constant) OR if the array is not manipulated in-place. So in the example, if you return branch 0 and branch 1 from the sub-vi then you have duplicated your data (and a copy will have been made). So if the sub-vi modifies the data, make sure that the change is done 'in-place'.

Some array tools are specifically designed to be used in place, such as the replace array element. Using these in-place tools will not force a copy of the array. Think of it as processing the arry by substitution directly into the memory itself. If you need to allocate an array within a FOR loop (for versions prior to about 6.1, I believe) the only 'in-place' way to do it is to pre-allocate, use the replace array element and truncate the array post loop.

Another thing to watch out for here is the use of indicators on the sub-vi's panel. If you run within the dev environ, then having a ~MB array branch to an indicator just for the sake of viewing the data, may mean a memory allocation, and will certainly slow your application (as you say) due to screen updates.

Furthermore, when a wire goes through a case structure, make sure at least one case has nothing happen to the wire. This (IIRC) enforces the 'by reference' passage of the data.

And while we're at it, did you realise that wiring your array into the top node of a multiple/add etc is NOT the same as wiring it from below. The top is best.

Just a comment. It has always seemed to me that efficient programming in Labview (algorithm wise) is somewhat akin to "Akido" (though I'm no expert on martial arts :ninja: ). Whereas variables, arrays, pointers to variables and pointers to arrays are explicitly declared in those other "text" based languages, in labview we have to "imply" such things by how we "flow" the data.

BTW, I once had a colleague refer to Labview as looking like programming in hieroglyphics. I don't know why I liked that comment, but I did.

[Götz Becker]

While trying to find out why one of my FGPA-VI wont rebuilt anymore (I havent touched the code... it just broke ) I found some evil looking SubVI connection panels in the FPGA part of the vi.lib. Looks like a quick and dirty "Create subvi from selection". The main thing i dont understand... if i have the time to create a custom icon, it just dont makes any sense not to clean up the connection panel!?! :headbang:

[Grampa_of_Oliva_n_Eden]

While trying to find out why one of my FGPA-VI wont rebuilt anymore (I havent touched the code... it just broke ) I found some evil looking SubVI connection panels in the FPGA part of the vi.lib. Looks like a quick and dirty "Create subvi from selection". The main thing i dont understand... if i have the time to create a custom icon, it just dont makes any sense not to clean up the connection panel!?! :headbang:

That example answers the earlier voiced question regarding why the LV devlopment environment does not force good style. I do have to wonder if that is due to the code being developed using scripting.

Ben

[PaulG.]

It looks like a C-programmer tries LabVIEW

Exactly. I've cleaned up code I inherited from a lousy LV programmer. He was also a lousy C programmer.

[manic]

The worst example of bad labview code i've ever seen was a monstrous 16 MB VI without any subVI. I guess it had about 300 screen sizes, when viewed in 1280x1024 px. Something like 20 screens wide and 15 screens high.

Unfortunately, i can't provide an image of that thing...(not only because of the size, but due to legal reasons)

Fortunately, i wasn't the guy to redesign that piece of LV-**** :laugh: