Labview 8.2 is very forgivable..

[napview]

Well so were the previous versions (probably >5x). This comes to compiling time vs. other text-based programming languages. Errors are easy to find in matter of seconds. The problem with G style programming is in a very big complex program (hard to see EVERYTHING at once) but if carefully planned out small sub vis can tremendously reduce the display screen area of the block diagrams. So the rule of thumb is to start with small compact working vis then work it up but why I had to say this again.

[rolfk]

---

@napview wrote:

Well so were the previous versions (probably >5x). This comes to compiling time vs. other text-based programming languages. Errors are easy to find in matter of seconds. The problem with G style programming is in a very big complex program (hard to see EVERYTHING at once) but if carefully planned out small sub vis can tremendously reduce the display screen area of the block diagrams. So the rule of thumb is to start with small compact working vis then work it up but why I had to say this again.

---

Hey why are your colors still yellow/gold instead of blue? Sounds like you were hired by the NI marketing departement Sorry couldn't resist but this solitair post with such verbage just sounds a bit like marketing hype eventhough I would agree with what you say.

Rolf Kalbermatter

Message Edited by rolfk on 01-19-2007 08:51 AM

[Wiebe@CARYA]

"napview" <x@no.email> wrote in message news:1169170807916-465841@exchange.ni.com...
Well so were the previous versions (probably &gt;5x). This comes to compiling time vs. other text-based programming languages. Errors are easy to find in matter of seconds. The problem with G style programming is in a very big complex program (hard to see EVERYTHING at once) but if carefully planned out small sub vis can tremendously reduce the display screen area of the block diagrams. So the rule of thumb is to start with small compact working vis then work it up but why I had to say this again.


A lot of programs (not just LabVIEW) are a mess because they started small and where worked up...


I'd say: start with small compact working vi's for each subsystem, like devices, file storage (call it the prototyping stage). Then design or reuse a working architecture. Then put it all together.


Regards,


Wiebe.

[napview]

"Sounds like you were hired by the NI marketing departement"

No but marketing does make lots of $$$ and really LV is still the primary tool for me at work to bring home bread and butter. But every day at it there are always more surprising things to learn new tricks and best ways even the codes were working as intended but the hardest and most time consuming part is to debug and improve them.

Then it is also true in other programming languages that can easily get messy but truth to LV is the old say "spaghetti  code" with lots of 'pretty' pinky wires. It is even more fun when finding hidden variables, wires and structures in someone's LV diagrams whether that was done on purpose or not.