LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can I use text based code in Labveiw


Rene_B wrote:


Sorry, but your example is just wrong. You can return anything you want in C (thousands of paramters if you want to).



I read tst's reply as meaning that both C and LabVIEW follow Computer Science principles of being able to return multiple arguments. LabVIEW does this pretty neatly with the connector pane; but the only way I can think of doing this in C is to define a struct, and declare a function's return datatype as the struct.

_____________________________
- Cheers, Ed
0 Kudos
Message 11 of 24
(2,064 Views)

@Rene_B wrote:

@tst wrote:

Second, assuming you continue to use it, go and read Mark's reply again, and then try to have fun. LV uses a completely different paradigm from C and some people have a very hard time wrapping their heads around it, but if you can make the transition, you'll find that LV has some very interesting computer science principals behind it and that you get all kinds of cool perks (small example - functions can have more than one return parameter, and it's completely intuitive).



Sorry, but your example is just wrong. You can return anything you want in C (thousands of paramters if you want to).


No, functions in C can only return one value. You can pass in (as straight "pass by value" or "pass by reference") as many as the stack will hold. Get your terminology straight. Smiley Wink

0 Kudos
Message 12 of 24
(2,047 Views)

@Rene_B wrote:


Sorry, but your example is just wrong. You can return anything you want in C (thousands of paramters if you want to).



Since when? You could create a struct, as suggested, or you could use thousands of pointers as inputs, which you'll the reuse as "outputs", but C does not have anything like this function, which has four return paramters quite naturally:

 

Outputs.png

 

 

 

In any case, that was just a small example of some advantages that LV has. There are many others, just like there are disadvantages. It's up to you to decide whether you like it or not, but it would be advisable to make that decision with an open mind and after giving it a real shot.


___________________
Try to take over the world!
0 Kudos
Message 13 of 24
(2,013 Views)

I don't understand... what's is so great about labview. 

graphical programming is pretty easy to use, untill you end up having to write nested loops, which is a necessity in almost any semi-complicated 2d array algorithms, such as dijkstra's algorithm.

Personally, I cringe whenever I try to nest any loops in labview, not to mention nested if statements (granted that there maybe better alternatives to nested if statements implemented in labview).

 

Lastly, I'm guessing labview can't possibly be faster than C in terms of compilation and execution. Since both languages(?) are compiled to machine language (more like assembly). Either way it all depends on how efficiently the compilers convert the language into machine language.

I feel like C or C++ or any other text based language with compilation of graphical modules could do the same thing as labview and more.

 

Or it could prevent a lot of complains, if it simply made a "C node", much like the formula node. taking inputs and giving outputs.

Waaait, if they were to do that, it would make the modules in the programming tab entirely useless xP

Just my opinion ^.^

0 Kudos
Message 14 of 24
(1,969 Views)

@Sighs wrote:

I don't understand... what's is so great about labview. 

graphical programming is pretty easy to use, untill you end up having to write nested loops, which is a necessity in almost any semi-complicated 2d array algorithms, such as dijkstra's algorithm.

Personally, I cringe whenever I try to nest any loops in labview, not to mention nested if statements (granted that there maybe better alternatives to nested if statements implemented in labview).

 


I'd say situations like that are worse in a text based language than in LabVIEW.  In a text based language it is much harder to visualize where loops begin and end, and how if-then-else structures are embedded in each other.

 

Generally, there is no need to next things too deeply.  If you're nesting structures more than 2 or 3 layers deep, then you are probably doing something wrong and need to rethink your architecture.  And that is going to be the case in any language whether text or graphical.

 

Please try a little harder to make your first post in the LabVIEW forum something worthwhile than trying to start some sort of flame war.Smiley Surprised

Message 15 of 24
(1,957 Views)

Sighs wrote:

... graphical programming is pretty easy to use, untill you end up having to write nested loops, 


So you are saying that nested loop are somehow magically simpler in text based programs?


Sighs wrote:

Lastly, I'm guessing labview can't possibly be faster than C in terms of compilation and execution. Since both languages(?) are compiled to machine language (more like assembly). Either way it all depends on how efficiently the compilers convert the language into machine language.


What the h311 does that mean? As soon as you have a multicore machine, LabVIEW will outshine any text based code because it can naturally and automatically parallelize tasks as needed. This is much more difficult in text based languages.


@Sighs wrote:

I feel like C or C++ or any other text based language with compilation of graphical modules could do the same thing as labview and more.


I have no idea what you are saying here. What is a graphical module?


Sighs wrote:

Or it could prevent a lot of complains, if it simply made a "C node", much like the formula node. taking inputs and giving outputs.

Waaait, if they were to do that, it would make the modules in the programming tab entirely useless xP


Who's complaining? Nobody! 😄


@Sighs wrote:

I don't understand... what's is so great about labview. 

Just my opinion ^.^


Obviously. 😄

 There is nothing "natural" about writing a program using a linear string of printable characters, it is actually very poorly suited for that task and only exists for historical reason. For further food for thought, have a look at my monograph. (a related version was also posted here).

 

 

 

 

 

 

Message 16 of 24
(1,956 Views)
Not trying to start a flame war, just giving my opinion on PARTS of the product.
I'm not saying text based programming is better than graphical programming. There are pros and cons for both, and personally feel that it would be be for the greater good of the programmers, if they were to find a way to combine all the pros from both sides. However, I noticed that in some aspects that Labview's desire to separate themself from the text-based so much that they even rejected some common pros for text-codes.
Followings are few examples I came across:
In terms of nested loops/if statements. I don't like how simple double nested if stament or loop takes up half of the page where the same thing could be done in text based language in 4 lines of code. It's just as much easier to read the text based nested loops long as the coder tabbed correctly (or if you used notepad++ it tabs for you.)
And if you are to have multiple loops in one VI it ends up impossible to look at the entire block diagram without scrolling.
Secondly if you ever have any case structure. You can only look at only one case at a time, even for simple true/false (aka if statement). You soon find yourself clicking away at the arrows on the box trying to find a simple bug in each of the case structure.
in text based coding unless you have 40+ lines in one case structure you won't even have to scroll to look at the "big picture".
And yes you shouldn't have 4+ nested loops, except a good compiler simply finds alternative way to implement unncessary loops, when compiling to machine code.
Additionally, trying to write simple math formula using numeric VI's seems very inefficient.
To reinforce my problem, the labview already tried to address this issue with formula node. to quote:
 

"The Formula Node is a convenient text-based node you can use to perform mathematical operations on the block diagram. You do not have to access any external code or applications, and you do not have to wire low-level arithmetic functions to create equations. In addition to text-based equation expressions, the Formula Node can accept text-based versions of if statements, while loops, for loops, and do loops, which are familiar to C programmers. These programming elements are similar to what you find in C programming but are not identical.

Formula Nodes are useful for equations that have many variables or are otherwise complicated and for using existing text-based code. You can copy and paste the existing text-based code into a Formula Node rather than recreating it graphically."

 

However, this is very limited since only variables in can take in are numeric. If it were to be able to take in strings and booleans, it would make coding for a simple operations much efficient ( at the least in terms of space).

(end of constructive criticism).

 

And to altenbach.

if you don't know how even compiler works in general, then please refrain from cursing in leet.

and I'm guessing you are refferring to multi-core threading. It's probably more difficult to do in C++ than being automatically done, but not sure since i don't know much about it.

 

The general term module is any prewritten code that a coder can simply import to use its functions in his own code. much like the "sub-Vi's"

 

I'm complaining 😛 ❤️

 

and yes. so far the pro I have experienced in labview is that it is capable in producing quickly without much hassel an easy to use GUI. for this I give much props to labview ^.^
 

 

0 Kudos
Message 17 of 24
(1,941 Views)

@Sighs wrote:
And to altenbach.
if you don't know how even compiler works in general, then please refrain from cursing in leet.

The leet was used to circumvent potential forum filters and was not meant as cursing.

 

I already posted a link how the LabVIEW compiler works and that document is valid independently of me knowing how a compiler works. I actually don't know what you are trying to say here. Am I only allowed to "curse in leet" (your words) if I know how the compiler works in general and not otherwise? I am confused by your conditional statement. 😄 And also please don't draw conclusion about my knowledge based on insufficient data. 😄

Message 18 of 24
(1,929 Views)

@Sighs wrote:
Not trying to start a flame war, just giving my opinion on PARTS of the product.
I'm not saying text based programming is better than graphical programming. There are pros and cons for both, and personally feel that it would be be for the greater good of the programmers, if they were to find a way to combine all the pros from both sides. However, I noticed that in some aspects that Labview's desire to separate themself from the text-based so much that they even rejected some common pros for text-codes.
Followings are few examples I came across:
<much deleted>

 

 


And I would argue that your lack of understanding LabVIEW (and based on some of your statements good programming practices in general) lead you to your assumptions. Well written LabVIEW code is extremely easy to read and understand. It is much more difficult to convey as much information as a good block diagram can in text. Remember the old saying, "a picture is worth a thousand words." If you are scrolling code across multiple screens you are writing bad code. You don't write 10000 line procedures in C/C++ so why would you think trying to fit your entire program on one block diagram is a good idea? It is virtually impossible to see parallel execution in a text based language (not to mention it is much more difficult to write). In LabVIEW you can easily see what tasks are parallel and what can be execute at the same time. LabVIEW will utilize all of the available cores on your machine and you don't even have to do anything special.

 

Let's look at current trends and ask a basic question, which language, text or graphical, would be easier to write using a touch screen? It is a lot easier to draw a while loop (graphical) than type out code on a touch screen. Think about the movie Minority Report. Would you want to type your code on that nice wall sized system? Using simple gestures you could easily drop down the graphical elements of LabVIEW. If you think this is pure science fiction take a look a what is selling these days. It is only a matter of time that fully interactive systems (kinect, Wii, etc.) move toward everyday commuting tasks. In some respects it is already happening.

 

From personal experience I have found that anyone who uses LabVIEW and keeps an open mind about it will generally end up preferring it to text based languages. Most who have tried it and espouse how terrible it is generally came into it with the preconceived notion it sucked and never really gave it a chance.

 



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 19 of 24
(1,915 Views)

How do you quote that I'm not saying one is greater than other, then go ahead and talk as if I said text based programming is better than graphical programming.... sighs...

 

And I've never said that "I can't see my whole program in one block diagram!!" I said "if you have double nested loop in your program it takes up half of the screen".

 

And yes, I like very much how labview can run loops in parallel to each other automatically long as it doesn't share any variables.
As I've said before, I don't think the absolute best programming language  would be something that is purely text based or purely graphical based.

I believe the best programming language will be a mix of both, taking the pros and throwing away the cons.

Even labview development sees the benefit/need of implementing pros from text-based programming.
look at formula node/matlab node/mathematica link/DLL

 

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/formula_nodes/

http://zone.ni.com/devzone/cda/tut/p/id/6206

https://decibel.ni.com/content/docs/DOC-1690

 

And to emphasize my intent here:

"I believe the best programming language will be a mix of both graphical and text-based, taking the pros both and throwing away the cons for both."

On that note I'm going to go to hw, in presenting a feature of labview to the electronics II class ^.^ 

0 Kudos
Message 20 of 24
(1,896 Views)