BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView vs LabWindows/CVI


@Todd_Lesher wrote:

It would be faster to make the change in LV than it would be to generate an invoice.


Perhaps you meant,  "It would be faster [ for Todd ] to make the change in LV than it would be to generate an invoice."

 

If your example is like other "simple" things I've encountered in LV then it could take me hours or days, if not weeks, to do it. But finding out how in LV has been a problem for me. I've been stuck many times in LV with no idea what was wrong, let alone how to fix it.

 

I've even found it hard to get LV help on a forum because I didn't know how to explain the problem. Sending somebody a code snippet is certainly easier in LW than in LV.

 

I seldom get stuck in LW. If I do it's easier to find another C coder to talk to than a LV coder.

 

Message 191 of 221
(10,921 Views)

Then don't use LabVIEW.

0 Kudos
Message 192 of 221
(10,922 Views)

It was just a code fragment, not a translation.  Actually nothing wrong with the goto if it is not abused.  Look at all the NI code, they use goto error all the time.  In the K&R book, it is made clear that goto is not used in any example, but only becuse it is often abused.

 

The error checking allows more flexibilty step by step, but making the case for LabVIEW, I say not.

 

The translation of the LabVIEW example to a CVI example would be about 10 lines of code all scrunched together with no comments.

Count the blocks in the LabVIEW, that would be the number of function calls in CVI.

 

So you look at the LabVIEW code, let's see, hummm, this goes here into that, and this goes here, then to here, and so on.

in CVI you just read what it does. No interpretation of icons (vi's) just read it.  Simple.

 

If this were a one to one comparison, there would be comments all over the LabVIEW "block diagram", but I seldom see that level of documentation.  And, no, it is not that LabVIEW does not need it, in fact even simple calls/blocks should have comments.

 

 

 

0 Kudos
Message 193 of 221
(10,922 Views)

querty999,

 

I agree, snippits of code are much eaiser to share than screen shots (or zips). When you go to a lot of help for LabVIEW you more often than not you get a screen shot  of a vi block daigram with all sorts of icons which need to be interpreted (along with some text).  Some vi's may be ones you have never seen before and thus there is no way to click a screen shot and tell you what each vi means.  Once you know it, it is easier but not not faster.

In one post I said by the time I find the vi, click it, drop it and connect the wires and make them pretty, I am already onto the next lines of code in CVI.  So I was reminded about Quick Drop.  No savings there, you have to call up quick drop, and either type in a vi name or scroll through the list.  In CVI I just type (no reaching for the mouse) or doing that typing with one hand.

 

Yes, and C coders abound so even a C coder can read your CVI snippit a point you in the right direction in most cases.

 

 

 

 

0 Kudos
Message 194 of 221
(10,909 Views)

@Romsky wrote:

querty999,

 

No savings there, you have to call up quick drop, and either type in a vi name or scroll through the list.  In CVI I just type (no reaching for the mouse) or doing that typing with one hand.


Typing with one hand, you mean like QuickDrop?

0 Kudos
Message 195 of 221
(10,902 Views)

@Romsky wrote:

It was just a code fragment, not a translation.  Actually nothing wrong with the goto if it is not abused.  Look at all the NI code, they use goto error all the time.  In the K&R book, it is made clear that goto is not used in any example, but only becuse it is often abused.

 

The error checking allows more flexibilty step by step, but making the case for LabVIEW, I say not.

 

The translation of the LabVIEW example to a CVI example would be about 10 lines of code all scrunched together with no comments.

Count the blocks in the LabVIEW, that would be the number of function calls in CVI.

 

So you look at the LabVIEW code, let's see, hummm, this goes here into that, and this goes here, then to here, and so on.

in CVI you just read what it does. No interpretation of icons (vi's) just read it.  Simple.

 

If this were a one to one comparison, there would be comments all over the LabVIEW "block diagram", but I seldom see that level of documentation.  And, no, it is not that LabVIEW does not need it, in fact even simple calls/blocks should have comments.

 


Personaly I'd rather see 10 lines of code that do important things instead of trying to see through all the boilerplate (like the large number of repetitions of the work "status").   In the LabVIEW code, I can quickly identify the key words "Open", "Table", "Columns", and "Read" that tell me I'm looking at a Database access.  It takes longer to sift through the verbose text code for the key words "xml", "points", etc.   To really understand either code, I would have to access descriptions of the various functions.  Which is trivial in LabVIEW and I suspect trivial in LabWindows.

 

Also, I'm not big on useless documentation ('Point_Save' means "Save the Point "?  Wow, thanks for explaining that.  And "Termination" is for "Termination"?).  

0 Kudos
Message 196 of 221
(10,898 Views)

Yes, assuming you are "mousing" at the moment, rather than release the mouse, you use the other hand.

 

But when typing text, both hands are dedicated to the keyboard (and switching to mousing and back is rare).

 

Becuase I have to do a lot of typing and mousing in LabView, fragments of time are lost switching, that adds up.

 

LabVIEw is not totally graphical.mosue driven, a lot of still needs to be typed.  Mostly the CVI mousing in done in the UIRs and then the switch to code to instrunct what each control does.

 

 

 

0 Kudos
Message 197 of 221
(10,896 Views)

@Romsky wrote:

So you look at the LabVIEW code, let's see, hummm, this goes here into that, and this goes here, then to here, and so on.

in CVI you just read what it does. No interpretation of icons (vi's) just read it.  Simple.


In a well written LabVIEW program, you just follow the wire and know exactly where the data comes from and where it is going.

 

In CVI, you don't just "read what it does". The text code to brain parsing is actually much more complicated, You need to recognize groups of letters as the names of functions, you need to recognize all variables and make assumptions on where they got modified last, and you need to delineate the start and end of e.g. loops and parse it into an understanding of the program structure. Getting the program structure right relies on indentation and can get very difficult with deeply stacked loops.

 

In contrast, loops in LabVIEW are fully delineated. We know exactly what is inside and outside. Once your visual cortex has learned the pattern recongition of these constructs, things are much easier to comprehend in LabVIEW.

 

Don't underestimate the power of visual pattern recognition. Sure there are chess master that can play a game by just looking at the game in a text notation or even play blind, but being able to look at the board seems much easier and direct and will give a higher ELO rating (everything else being the same). You can reconize a relative within milliseconds of looking at a face (even if it is black&white and very low resolution!), but if you would read a text description of the same person, things are much more ambiguous. A skilled cartoonist can draw the face of a politician with a few lines and it is immediately recognizable, even if all features are way exagerrated and distorted. Try that with plain text! 😄

Of course you could just write the name in text, but you'll lose all metadata such as the facial expressions.

 

We can start new code anywhere on a blank diagram, but text programmers are forced to start with the first line. The liberty to place code anywhere on a 2D canvas can be intimidating for people that are trained in German burecracy. We can place new parallel code above, below, to the right or to the left of existing LabVIEW code. This can be very disconcerting to users trained to neatly place line after line. 😄  

 

 

0 Kudos
Message 198 of 221
(10,893 Views)

I understand what you mean about the visual cortex and how it plays in all this. But LabVIEW is not all connected by wires, there are local and global variables for instance, so even then there are constructs just like textual CVI.

 

Why is it not  all done with wires? Because I assume it would make a mess of the graphical canvas.

 

How is a loop not delineated in C?  In LabVIEW you can also have loops within loops and you can see them in C as well, but after a while the LabView screen is huge, in CVI it is long.  Same difference.

 

But one can start text code at any level, top down, bottom up any anywhere in between.

 

For example if I write a for loop it may be done this way:

 

for()

{
}

 

then

 

for()

{

 x = x + 1;
}

 

then

 

for(y = 0; y< 10; y++)

{

 x = x + 1;
}

 

Code can be placed above, below, to the left or the right at any time.

 

So, in this very crude example, the for construct may be created first, then the block context, then the loop parameters.  The final result is neat and orderly but it may not have been typed or visualized that way.

 

I have no problem with 2D, 3D, or multidimensional space.  In fact many hardware/software folks like me draw 2D schematics all the time so I don't think you can generalize that text based people have a problem or are intimidated with a 2D canvas, it is more on how that canvas is being used in LabVIEW.

 

As far of recognition of an icon or a word. One can bring the word into the mind much faster and leave more of the visual cortex free for other things.  In my case when I code I "see" a lot what I need to do in my mind and type the code while I work a solution. I don't visualize in LabVIEW no would I want to, my visualizations are often 3D and can be a bit abstract.  When make a a schematic, it is simply connecting blocks with wires, all I see is the artwork on how I want the trace to look, the physical (component) part of the task I had already finished before I even started. 

 

[in a friendly and since voice] Also, please rethink using the term "German bureaucracy" in this context, it could be very insulting to some people (it was to me). But no harm no foul.

 

 

 

 

 

0 Kudos
Message 199 of 221
(10,881 Views)

@Romsky wrote:

 

[in a friendly and since voice] Also, please rethink using the term "German bureaucracy" in this context, it could be very insulting to some people (it was to me). But no harm no foul.

 


Well Altenbach knows all about the german mentality and the famous levels of german bureaucracy since he (AFAIK) lived quite a while in Basel, just a stone's throw from Germany.

 

Why exactly is the usage of the term insulting to you?

0 Kudos
Message 200 of 221
(10,850 Views)