LabVIEW Documentation Survey

[becktho]

@TiTou:

Yes, you're right. I sometimes try to use an express vi, just to find out that it is useless for me. Either because of its overhead or because it does not exactly do what I want. Luckily I could develop my own express vis, but unfortunately it was not necessary up to now. I once just had a try.

Anyway - I understand NI's point of view. In the end NI is a company which wants to make profit, so they definitely have to attract new users somehow.

[IanW]

Like others I gave up with the survey after several pages.

I'm afraid I usually end up going round in circles with the help system, often not finding the answers I need. I then resort to either the forums or search for tutorials on the web.

Maybe it's my age but I realy miss the user manuals, even in pdf form.

Ian

[Ray.R]

I'd be repeating what Ian and the others have said.

The "Help" in Labview is... not helpful... (politically correct term)...

*** EDIT ***

Just how long does it take to go through this survey??  Man it's slow!!

😮

Message Edited by JoeLabView on 09-27-2006 04:07 PM

[PhillipBrooks]

Not a very good survey, and SLOW is right! Maybe the hosting company should change it's name from surveymonkey.com to surveysloth.com

Message Edited by Phillip Brooks on 09-28-2006 07:39 AM

[IEC]

I agree that labview's remedial side is being shown too strongly.  I have just been learning about the use of threads and semaphores and all the really really cool higher level functions labview has to offer, and I love it.  Though, as for the express VIs I never use them (except for the uber-simple display user message one which will retrieve either a numerical, boolean, or string).  I think NI should concentrate more on the advanced side of labview and draw in programmers from all languages to use it which think that it's just a toy. 

Has anyone ever tried to write an operating system using labview?  I don't know if it could be done, but if it can, it should be.  That would get a whole lot of programmers to switch over. 

LV's like the original macintosh, it's a better computer but since it's so easy to use people think it's a toy and limited in its features.  My first mac LCII with 16Mhz 68030 Motorola proc. and 4 mb ram was the hot stuff! 

[tst]

---

@IEC wrote:

Has anyone ever tried to write an operating system using labview?  I don't know if it could be done, but if it can, it should be.  That would get a whole lot of programmers to switch over. 

LV's like the original macintosh, it's a better computer but since it's so easy to use people think it's a toy and limited in its features.  My first mac LCII with 16Mhz 68030 Motorola proc. and 4 mb ram was the hot stuff! 

---

I wouldn't overstate the point. G is a great language, but an LV program would not outperform an optimized C program and probably not a well written C program either. LV is great and very easy to use, but that comes at the cost of taking some control away from the programmer, control which would probably be crucial when writing certain kind of software.

You could probably theoretically use LV to write an operating system by implementing some of the stuff the operating system needs yourself, but that OS would be sitting on top of LV which would be sitting on top of your real OS and would NOT be a very good performer. You would not have real access to all the hardware and memory management stuff you will need to write a real OS. In the end, LV is a very high level language and as such only suitable for certain tasks.

[Andrew_Boniface]

For G/Labview to be used to write an operating system, it would need to have an option to compile as a stand-alone program on the target system.  This could be fit into the target options one sees in a project directory.   I see no reason Labview could not be optimized as well as C could.  Because of Labview's potential for hiding complexity, it will take some discipline to avoid using complex (time or space consuming) operations too freely because they look simple.  This is a risk with any high-level language. 

As demand for speed motivates a shift toward greater parallelism, and a departure from the Von Neumann machine (CPU separate from Memory, data moves from one to the other one word at a time, one direction at a time), G (or some other graphical programming language) will become more attractive.  Well, maybe not, but text based laguages, especially ones like C *, will become less attractive, to the point where G would be a clear favorite.

* as opposed to say APL or LISP.

---

@IEC wrote:

Has anyone ever tried to write an operating system using labview?  I don't know if it could be done, but if it can, it should be.  That would get a whole lot of programmers to switch over. 

LV's like the original macintosh, it's a better computer but since it's so easy to use people think it's a toy and limited in its features.  My first mac LCII with 16Mhz 68030 Motorola proc. and 4 mb ram was the hot stuff! 

---

I wouldn't overstate the point. G is a great language, but an LV program would not outperform an optimized C program and probably not a well written C program either. LV is great and very easy to use, but that comes at the cost of taking some control away from the programmer, control which would probably be crucial when writing certain kind of software.

You could probably theoretically use LV to write an operating system by implementing some of the stuff the operating system needs yourself, but that OS would be sitting on top of LV which would be sitting on top of your real OS and would NOT be a very good performer. You would not have real access to all the hardware and memory management stuff you will need to write a real OS. In the end, LV is a very high level language and as such only suitable for certain tasks.

[Ray.R]

APL... A Programming Language..

Andrew, I think you're giving away your age 😉

It was an interesting language..  A bit Greeky 😄

[Andrew_Boniface]

		Re: Writing an OS in G
JoeLabView said:

            Andrew, I think you're giving away your age

Well, how old am I?   Hint:  I do not know my Vietnam draft lottery number, but maybe I should have, even though it turned out not to matter.

My mention of <geek> APL </geek> was because it seems to be one of the most parallel-oriented text language I know, in a SIMD kind of way.

[Ben]

Here are doc improvement ideas. If you have more or comments on these ideas, fire away!

1) Power-User have been asking for info on buffer re-use by LV functions. EVERY function should mention clearly if it re-uses buffers and under which conditions those buffers are re-used.

2) We need "re-training" notes. These are notes that tell power-user were to find the new functionality. EG How to do you save an application hiarchy in LV8 ?"

3) All GUI objects should be discussed in the context of the control editor. There have historically been a lot of secrets revealed by passing through that door.

I'll update this thread with more ideas as they come.

Please add to this list if you have other ideas to improve the LV documentation.

"Trying to make LV better one post at a time"

Ben