how to creat dos-based programs in Labview

[prober]

Hi all. All I'm dying to know is can I creat a dos-based program in Labview which runs under dos or in a dos window under windows. I'm not talking about calling external codes or something. Let's just say i want to write a program which shows "hello world" on the screen in dos. I really want you to understand what im trying to ask very well so im gonna give an example from C++ and Pascal and let u all consider that i want to write the same program in Labview that gives the same output.

In C++

main (){

cout<< "hello world" endl1;

system("pause");

return 0;

}

in Pascal

begin

Wrtie('hello world');

Repeat until keypressed;

end.

Briefly, I want to write a program in Labview that will do the same thing as the programs above do. How can i do that?

thank you all very much...

[gb119]

Ummm, I'm pretty sure you can't (easily). LabVIEW doesn't give you access to the standard input/output and pretty much assumes that you are running under a GUI. There are various tricks one can do to make it not run with any GUI e.g. running as a Windows service, but even a compiled LabVIEW application doesn't run inpendently of the runtime and that assumes a GUI.

The broader question is why? LabVIEW is great for many things, but writing console programs is not one of them.

[Ton Plomp]

QUOTE (prober @ Apr 19 2008, 01:01 PM)

Hi all. All I'm dying to know is can I creat a dos-based program in Labview which runs under dos or in a dos window under windows.

Briefly, I want to write a program in Labview that will do the same thing as the programs above do. How can i do that?

thank you all very much...

DOS is dead, and LabVIEW has never worked in DOS.

QUOTE (Gavin Burnell @ Apr 19 2008, 01:59 PM)

The broader question is

why?

LabVIEW is great for many things, but writing console programs is not one of them.

That's true, but I ask if prober is really wanting that?

Here's my attempt:

Ton

[prober]

QUOTE (tcplomp @ Apr 19 2008, 12:46 PM)

That's true, but I ask if prober is really wanting that?

Absolutelly not. The program you sent is not what i want to write in LabVIEW.

QUOTE (Gavin Burnell @ Apr 19 2008, 11:59 AM)

The broader question is

why?

LabVIEW is great for many things, but writing console programs is not one of them.

ok people, Dos was a reference point. I mean I'm just trying to find out what i can do using LabVIEW and what i can't do. I was curious about if there is some limitation on LabVIEW that stops me from creating very different things than just creating programs about measurements and data acquisition. I think you would agree that a programing language can be considered a kitchen, and if you are a good chef then you can create anything you want. So what if I want to create an operating system in LabVIEW. It's so obvious that i would need to start by a console program which doesn't need another operating system to run. It must run alone.

You all are making me think that I cannot create a program in Labview that runs alone without needing anything else to run. And that all the programs I write need Windows to run. Are these true? if so can we say that LabVIEW is not one of those programing languages that are considered a kitchen and you can only create windows based programs in LabVIEW(or another GUI operating system like Linux)?

[orko]

Okay, okay...calm your jets, prober. You were very specific in your original post that you wanted DOS, so your answers (since LabVIEW will compile executables for Windows, Windows Mobile/CE, LabVIEW Real-Time, Linux, and Mac OS X off the top of my head...) were rightly directed to the point that DOS is ancient history. If you wanted to find out more about something else, then you should have asked a different question.

QUOTE (prober @ Apr 19 2008, 04:22 PM)

I was curious about if there is some limitation on LabVIEW that stops me from creating very different things than just creating programs about measurements and data acquisition.

I haven't found any such limitation. The idea that LabVIEW is just for measurements and DAQ is about as ancient as DOS... Have you looked at some of its features? That my friend is only skimming the surface, as you can see by taking a tour of just this forum and seeing what people are doing with LabVIEW. It ain't just for measurements.

What are you going to be using it for?

QUOTE (prober @ Apr 19 2008, 04:22 PM)

So what if I want to create an operating system in LabVIEW. It's so obvious that i would need to start by a console program which doesn't need another operating system to run. It must run alone.

The only thing that is obvious so far is that we still don't know exactly what you are asking. You want to build an operating system from LabVIEW? First off, why? Second off, what does that have to do with comparing it to C++? Are you truly interested in writing a kernel/driver level from scratch with LabVIEW...? Someone correct me if I'm wrong, but isn't the LabVIEW RealTime O/S just that?

QUOTE (prober @ Apr 19 2008, 04:22 PM)

You all are making me think that I cannot create a program in Labview that runs alone without needing anything else to run. And that all the programs I write need Windows to run. Are these true? if so can we say that LabVIEW is not one of those programing languages that are considered a kitchen and you can only create windows based programs in LabVIEW(or another GUI operating system like Linux)?

I don't understand. We're building applications, dlls that run on multiple O/S platforms. What are you doing with C++/Pascal that is so different?

[Aristos Queue]

G'evening, prober. I understand the questions you're asking... they're the same ones that I had when I first encountered LabVIEW.

LabVIEW is a programming language. Like JAVA or C#, there is a runtime engine that is required for any LV program to execute. That LV engine includes two major components: the execution system and the library of built-in routines. Every LV program is compiled to assembly for the native platform. Many nodes in a LV diagram become direct assembly instructions. Others become just enough assembly to call into the runtime engine -- those are the built-in functions that I mentioned. The execution system is the thread scheduler that provides the parallel scheduling of LabVIEW code and handles the spawning and directing of the operating system threads (the optimal parallelization of code in the compiler is one of the major strengths of LabVIEW compared to other programming languages; details on this topic can be found elsewhere on LAVA and ni.com; I'm not going to delve into them here).

The native compilers for LabVIEW include the desktop environments of Windows, Mac, and Linux. These are the platforms on which LV code can be developed. Native compilers also exist for the so-called "target platforms", including PDA, VXWorks, Pharlap and FPGA. These are platforms that do not have a LV development environment, but the LV development environment can be told to compile for these targets. Each of these is a module that you purchase separately from the basic LV package. The FPGA module is another major differentiator of LV compared to other programming languages -- our compiler goes directly from the LV diagrams to VHDL to FPGA fabric without further programmer intervention. And the parallel nature of LV code means that when we hit FPGA targets, we get complete indepenent execution of parallel sections of code. Quite cool, IMHO.

LV is predicated on a graphical environment. It simply doesn't run without the assumption of at least one top-level application window. So you can invoke a LV exe from a command line, and you can pass it command line arguments, and you can direct output back to the command shell (with difficulty -- it isn't a first-level use case for LabVIEW), but you're going to get a window that opens up while the app is running. You can invoke commands to hide that window, but closing the window will terminate the app. You can write plenty of command line apps using LV, so long as you don't mind that window flickering.

Please forgive user tcplomp -- he was trying to make a point about the display capacities of LV, and I don't think he took "dos app" to be one executable in a pipe/redirect sequence, which is I believe what you're asking about. That's where most programming languages start, but, as I said, that's not a first-level use case for LV. LV starts off assuming a graphics interface and only worries about the command line as a very late afterthought.

[Ton Plomp]

Thanks Aristos for your broad description.

QUOTE (prober @ Apr 20 2008, 12:22 AM)

It must run alone.

...

You all are making me think that I cannot create a program in Labview that runs alone without needing anything else to run.

Prober, can you tell us a little bit more about your background? What is your previous programming history, where do you come from, do you have a direct application in mind or is this a mind-exercise?

Orko is right that LabVIEW real-time comes the most close to what you want. You can even get LabVIEW embedded to write applications for any 32-bit processor (you will need the original compiler tools).

My first reply was more of a redirection in the most plausible direction (the wrong one though)

Ton

[prober]

Whatever...it was a mistake creating such a topic in this forum. You all are dumb except Aristos Queue and Gavin Burnell...

I can't believe you how can't you undersatnd my simple statements and questions...Ban me or do whatever you want for saying that you all are stupid..I'm not gonna keep being a part of this forum...So you can easily ban me i dont care...

I owe a polite thank you to Aristos Queue and Gavin Burnell anyway...And the rest are real stupid...go read books or do something to make ur brain run and to be open-minded....

[Aristos Queue]

Prober: Please cut the others a bit of slack -- most of the users of LV have never programmed in any other programming language. You'll find a lot of these guys are particularly brilliant if you need help solving a problem with LV, but sometimes the parlance of programmers in other languages doesn't translate directly. There are a lot of conversational conventions used among those of us who started off in BASIC, Pascal and C that aren't shared by those who start off in LabVIEW. That's something that LabVIEW marketing frequently brags about -- the top LV programmers are scientists and engineers who have never had any formal CS training: the language is that easy to learn. In this particular instance, you asked for a DOS app. This translates to a LV user as "can I build an EXE that I can launch from the command line". What you intended it to translate as is "can I write a VI that reads from the command line and writes back to the command line".

I hope everyone on both sides can forgive each other. When you're not speaking the same language but you think that you are, it's easy to believe the other side must be completely stupid. Let me assure everyone: Prober wasn't asking a dumb question, and the others weren't trying to be ambiguous.

And now, if you'll excuse me, irony of ironies, I have to get back to writing a report for LV marketing on "how to talk about LV when you're talking to computer scientists". There have been some problems with this. :-)

[Val Brown]

QUOTE (Aristos Queue @ Apr 20 2008, 03:18 PM)

And now, if you'll excuse me, irony of ironies, I have to get back to writing a report for LV marketing on "how to talk about LV when you're talking to computer scientists". There have been some problems with this. :-)

Yes, even though reading and writing STD i/o is pretty direct (esp for an old line Unix hack like me) method for "getting attention", the biggest challenge in "real" programming is generally the GUI -- ie how do you maximally reach and interact with the intended audience/users. No matter how you slice it "dos app" has a very specific connotation and that isn't just "pipeline" or even "standalone" necessarily.

Let me say this all another way. Yes, the big advantage of LV is that no CS background is needed, even for complicated applications. The big problem with many other languages is, CS background is required, even for trivial tasks. This creates an asymmetry that IME frequently lays heavily on the hearts and minds of those with CS backgrounds. FWIW, having started with text-based programming "back in the day" it still seems pretty silly to me that many consider text-based languages to be the "ideal" and LV becomes seen as a "toy" or "incomplete", etc.

I think that, if the original post had called about a STD i/o based pipeline/standalone, it would have been a lot easier to have actually had a conversation.

Now I think I'll go over to an MSDN forum and ask about how to drop an LV event structure into the VS IDE by a straight "drag and drop" of its icon. After all, that IDE handles "by-ref" constructs doesn't it?

[orko]

prober,

Sorry we got off on the wrong foot, and I sincerely hope you got the answer you were looking for from AQ.

Your response was unexpected to say the least, so I re-read the entire thread. To me the responses that you received were non-threatening, with a genuine desire to help you out. We apparently didn't have a full understanding of what your question actually was, so didn't provide the answer you were looking for. The questions that were asked of you were not answered either, which surprised me since forums by nature require a two-way conversation in order to be effective.

I really don't mind if your personal opinion is that I am stupid for trying to clarify a muddied situation. Your accusation was without merit, and I hope you come to realize this. You may stay or go (and I hope that you stay), I just hope that you don't go away with false impressions you gathered based on this blatant miscommunication.

[Ton Plomp]

QUOTE (prober @ Apr 20 2008, 10:27 PM)

You all are dumb except ...

...Ban me or do whatever you want for saying that you all are stupid..

It takes a lot more to be banned from here (allthough I feel attacked).

Feel free to stay, it is nice to have a totally different mind on these kind of forums.

I missed the part that you allready have 2 years of LabVIEW experience, sorry.

I thought you were asking for 'hello world' app. (if you want to introduce programming language and that is all you can supply the language is limited).

Ton (hides under his rock again)

[gb119]

QUOTE (Gavin Burnell @ Apr 19 2008, 11:59 AM)

Ummm, I'm pretty sure you can't (easily). LabVIEW doesn't give you access to the standard input/output a...

QUOTE (Aristos Queue @ Apr 20 2008, 04:21 AM)

-You may also be interested in this article "Command Line Interface for LabVIEW"

To output the results of your

LV

program back to the command line, use the System Exec.vi (which you can find by searching the palettes). It has the ability to output to either standard output or standard error.

Ok, now I'm feeling pretty dumb....

Actually, I can see how the System Exec allows you to access the STDIN/STDOUT of whatever process you are running, but how does one persuade it to connect to the STDIN/STDOUT of the process that launched the LabVIEw app ? I mean if I did something like executing "cmd \c cat -" wouldn't I open a new command shell window which would display whatever I wired up as standard input ? Or am I missing soem trick here ?

[PaulG.]

QUOTE (prober @ Apr 20 2008, 05:27 PM)

...And the rest are real stupid...

"Stupid?!" Your Momma!

[Aristos Queue]

QUOTE (PaulG. @ Apr 21 2008, 08:53 AM)

"Stupid?!" Your Momma!

Your momma was Hitler! (http://en.wikipedia.org/wiki/Godwin%27s_law' rel='nofollow' target="_blank">Canonical end of thread!)

[Götz Becker]

QUOTE (Aristos Queue @ Apr 21 2008, 06:05 PM)

Your momma was Hitler! (http://en.wikipedia.org/wiki/Godwin%27s_law' rel='nofollow' target="_blank">Canonical end of thread!)

Too easy for a real Godwin´s Law case. I doubt that this thread will end here! (Quirk's Exception)

[crelf]

QUOTE (Götz Becker @ Apr 21 2008, 01:17 PM)

Too easy for a real Godwin´s Law case.

I think calling LabVIEW users stupid because you think you're from a dominate race is just like when...

[Karsten]

QUOTE (Gavin Burnell @ Apr 21 2008, 02:57 PM)

Ok, now I'm feeling pretty dumb....

Actually, I can see how the System Exec allows you to access the STDIN/STDOUT of whatever process you are running, but how does one persuade it to connect to the STDIN/STDOUT of the process that launched the LabVIEw app ? I mean if I did something like executing "cmd \c cat -" wouldn't I open a new command shell window which would display whatever I wired up as standard input ? Or am I missing soem trick here ?

Hi Gavin,

By default STDIN and STDOUT have no meaning for a GUI based application (process to be exact...) like LabVIEW. But you can create one for a process does not have this. A use-case would be to output debug information. There is no Native LabVIEW way to do this (as far as I know). The System Exec.vi just executes a process on system level that could have a Console.

I have been using the following VIs that call the Win32 API to create a Console Window for the LabVIEW Process and write to it. I primary use it for debug output so I did not look into reading from the Console.

Download File:post-1819-1217341336.vi Download File:post-1819-1217341345.vi

Tested in LabVIEW 8.5.1 on Windows Vista SP1 32 bit

[Yair]

Nice idea, but wouldn't it be simpler and more robust to write a simple display VI which will do this?

I'm assuming the only advantage (?) that the console window has is that it can recieve messages from the entire process, as opposed to the VI, which should be limited to a single app instance if you use something like a queue to pass the messages.

[gb119]

QUOTE (ktvz @ Jul 29 2008, 03:28 PM)

Hi Gavin,

By default STDIN and STDOUT have no meaning for a GUI based application (process to be exact...) like LabVIEW. But you can create one for a process does not have this. A use-case would be to output debug information. There is no Native LabVIEW way to do this (as far as I know). The System Exec.vi just executes a process on system level that could have a Console.

I have been using the following VIs that call the Win32 API to create a Console Window for the LabVIEW Process and write to it. I primary use it for debug output so I did not look into reading from the Console.

Download File:post-1819-1217341336.vi Download File:post-1819-1217341345.vi

Tested in LabVIEW 8.5.1 on Windows Vista SP1 32 bit

Yes, but the original poster wanted (and I have no idea why other than to show that LabVIEW can't create 'proper' console apps) was to open a console window and type something like "cat input.txt | foo.exe > bar.dat" where foo.exe was a compiled LabVIEW program. So it's easy to see how to hide foo.exe's GUI and there are lots of ways to get that GUI to open a window that is a console window or looks like a console window and spit out text, or even to open a console window and read in text that the user types in. In your examples, if you don't create the console window, what happens when you call GetStdHandle ? If it works as above then that's very nice for answering mavericks who want to use LabVIEW to create a text-mode application

[Val Brown]

QUOTE (Gavin Burnell @ Jul 30 2008, 01:52 PM)

Yes, but the original poster wanted (and I have no idea why other than to show that LabVIEW can't create 'proper' console apps) was to open a console window and type something like "cat input.txt | foo.exe > bar.dat" where foo.exe was a compiled LabVIEW program. So it's easy to see how to hide foo.exe's GUI and there are lots of ways to get that GUI to open a window that is a console window or looks like a console window and spit out text, or even to open a console window and read in text that the user types in. In your examples, if you don't create the console window, what happens when you call GetStdHandle ? If it works as above then that's very nice for answering mavericks who want to use LabVIEW to create a text-mode application

Maybe I'm missing something here but it seems to me that wanting to do that in LV is kind of like wanting to use the Concorde to take the garbage down your driveway to the street.

[LAVA 1.0 Content]

QUOTE (tcplomp @ Apr 21 2008, 01:55 AM)

It takes a lot more to be banned from here (allthough I feel attacked).

Feel free to stay, it is nice to have a totally different mind on these kind of forums.

I missed the part that you allready have 2 years of LabVIEW experience, sorry.

I thought you were asking for 'hello world' app. (if you want to introduce programming language and that is all you can supply the language is limited).

Ton (hides under his rock again)

# In C++

# main (){

# cout<< "hello world" endl1;

# system("pause");

# return 0;

# }

# in Pascal

# begin

# Wrtie('hello world');

# Repeat until keypressed;

# end.

# Briefly, I want to write a program in Labview that will do the same thing as the programs above do. How can i do that?

# thank you all very much...

Ahem.. heh. Understanding where this thread has gone up to this point,... he did specifically ask how to write a hello world program. With no mention

of piping std i/o... So you were being a nice guy and replied with what he asked for.

-Scott