LabView

[Triffid]

I've just discovered this newsgroup, and looking at the questions I'm
astonished at the sheer difficulty of doing the simplest thing in LabView.
Downloading a special toolkit just to use a right mouse click?!!! Messing
about with extra nodes to construct a simple ring? (see discontinuous
sliders below). More toolboxes to change cursors?

This is the problem with graphical interfaces - they look so gorgeous and
simple at the demo, with salesmen zap controls and graphs right left and
centre, but in the real world they're a nightmare!

Go look at LabWindows CVI. You can do virtually anything straight out the
box. And I mean anything not just data acquisition. I once wrote a network
backup routine with it. In fact it's so comprehensive that NI wants to kill

it. They just released version 6.0 (more of the same with LabView type
buttons) but they didn't make much fuss over it. No special release of the
newsletter to trumpet their new achievement. It's a lot harder to licence a
program that by definition has no limits to hardware I/O and builds run-time
exe's as a matter of course.

So wake up, see the light, and read Kernighan + Ritchie while you still can!

[Gorka Larrea]

Well, you are right... in some aspects.
The real question is: Do we need all the features we want? Personally i do not (normally) ask questions about general data aquisition problems to the newsgroup, i simply open LabVIEW and work. If i want some functional data aquisition program, i get it with no (or not much) effort, everything works right, no problem. But OK, if i need some advanced cosmetics, i need something more, i need Windows API calls and so... but someone surely has programmed them, so i write to the newsgroup, get the location of some interesting FREE tools or examples, get them and use them, analizing them and using that experience in future projects. All of this without writing a simple line of code!
Definitively and knowing that the LabVIEW
community is allways willing to help, i must say that i am awake, i have seen the light, and i love LabVIEW.

[CraigGraham]

As I understand it, LabWindows is the Labview GUI engine but with a C code
backend instead of G. By the very nature of it, C has longer development
times than G. If there are things we wish to do that are not in G, then we
must go into C, by a code interface node or by making a DLL call. What
you're saying is that because some aspects require lower level C code, we
should scrap G entirely, even though in the vast majority of situations G is
perfectly adequate.

You say you're suprised at the sheer difficulty of doing certain things; how
long would it take to, for example, search for an instance of a regular
expression within a string just using native C code, without going to an
external library? Sure there are function libraries you can go out to- but
if you have an issue with "special toolkits" in Labview, I'd guess you're
against their analogues in C. So you'd have to start at the ground up and
write a function to do it before you can get on with the program in hand.
Labview already has such functions as native G primitives.

Your message appears to be based on the qustions that appear here, with no
experience of Labview itself. That is always a dangerous foundation on which
to criticise a language. You may take note of the fact that on Usenet there
is *one* Labview group, whilst there are a great many C groups. You may also
note that there are no problems discussed in this group that are due to the
use of uninitialised pointers, failures to allocate and deallocate memory
and other such things that can waste a great deal of time in C coding.

Siddown wrote in message
news:nlAz7.1230$uh1.373297@news6-win.server.ntlworld.com...
> I've just discovered this newsgroup, and looking at the questions I'm
> astonished at the sheer difficulty of doing the simplest thing in LabView.
> Downloading a special toolkit just to use a right mouse click?!!! Messing
> about with extra nodes to construct a simple ring? (see discontinuous
> sliders below). More toolboxes to change cursors?
>
> This is the problem with graphical interfaces - they look so gorgeous and
> simple at the demo, with salesmen zap controls and graphs right left and
> centre, but in the real world they're a nightmare!

[Triffid]

Obviously, I am new to LabView, and am trying to bring myself up to speed
using the evaluation kit. I have found the learning curve extremely steep,
probably not helped by a half-lifetime of C experience. Really simple
things like moving controls on the page were difficult (CVI doesn't have [or
need] a 'pick' tool)! The first thermometer demo took 30 mins to do in
LabView, as I couldn't work out how to set the ranges, since I expect
everything to be in a properties box, rather than written directly on the
page. It took me 90seconds in CVI, from to a runtime
executable. And then it ran about 5 times as fast. Doubtless programming
LabView gets much quicker with familiarity, though as I write this questions
are apperaing on array handling that would be second nature in C.

It would be easy to trade punches with 'killer features', but it does seem
to me that LabView struggles with any decision/program flow activities,
whilst making straightforward monitoring a doddle. Your comments about
memory problems and dodgy pointers are very common, and are surely one of
the principle reasons that punters are choosing LabView over CVI. Competent
programming is all thats required to combat them though, so are people so
distrustful of their own abilities? Am I bragging to say that it's never
happened to me? And on top of all that, I can make direct calls to the
Windows API, though actually I've hardly ever needed to.

But my main gripe is that I'm being dragged kicking and screaming into an
area that I consider to be deeply inferior (with or without good reason) to
CVI. The user base is 5-10 times that of CVI, and growing. Money forces
the change.

And at least there IS a LabView newsgroup, there is no CVI counterpart!


"Craig Graham" wrote in message
news:3bcee527@newsgroups....
> As I understand it, LabWindows is the Labview GUI engine but with a C code
> backend instead of G. By the very nature of it, C has longer development
> times than G. If there are things we wish to do that are not in G, then we
> must go into C, by a code interface node or by making a DLL call. What
> you're saying is that because some aspects require lower level C code, we
> should scrap G entirely, even though in the vast majority of situations G
is
> perfectly adequate.
>
> You say you're suprised at the sheer difficulty of doing certain things;
how
> long would it take to, for example, search for an instance of a regular
> expression within a string just using native C code, without going to an
> external library? Sure there are function libraries you can go out to- but
> if you have an issue with "special toolkits" in Labview, I'd guess you're
> against their analogues in C. So you'd have to start at the ground up and
> write a function to do it before you can get on with the program in hand.
> Labview already has such functions as native G primitives.
>
> Your message appears to be based on the qustions that appear here, with no
> experience of Labview itself. That is always a dangerous foundation on
which
> to criticise a language. You may take note of the fact that on Usenet
there
> is *one* Labview group, whilst there are a great many C groups. You may
also
> note that there are no problems discussed in this group that are due to
the
> use of uninitialised pointers, failures to allocate and deallocate memory
> and other such things that can waste a great deal of time in C coding.
>
> Siddown wrote in message
> news:nlAz7.1230$uh1.373297@news6-win.server.ntlworld.com...
> > I've just discovered this newsgroup, and looking at the questions I'm
> > astonished at the sheer difficulty of doing the simplest thing in
LabView.
> > Downloading a special toolkit just to use a right mouse click?!!!
Messing
> > about with extra nodes to construct a simple ring? (see discontinuous
> > sliders below). More toolboxes to change cursors?
> >
> > This is the problem with graphical interfaces - they look so gorgeous
and
> > simple at the demo, with salesmen zap controls and graphs right left and
> > centre, but in the real world they're a nightmare!
>
>
>

[CraigGraham]

Siddown wrote in message
news:ubCz7.3489$sF.403246@news2-win.server.ntlworld.com...
> Obviously, I am new to LabView, and am trying to bring myself up to speed
> using the evaluation kit. I have found the learning curve extremely
steep,
> probably not helped by a half-lifetime of C experience. Really simple
> things like moving controls on the page were difficult (CVI doesn't have
[or
> need] a 'pick' tool)! The first thermometer demo took 30 mins to do in
> LabView, as I couldn't work out how to set the ranges, since I expect
> everything to be in a properties box, rather than written directly on the
> page. It took me 90seconds in CVI, from to a runtime
> executable. And then it ran about 5 times as fast. Doubtless programming
> LabView gets much quicker with familiarity, though as I write this
questions
> are apperaing on array handling that would be second nature in C.

Where does criticising the language end and the IDE begin? It took me some
time to get used to the MS Visual Studio IDE, and even now I'm not quite
happy with it; I much prefer to be able to right-click on the object I want
to modify and go through the menus, or as you say edit directly on the page,
than select the object and then mess about with the properties in a window
elsewhere on the screen. I still try to click on captions and type to change
their names periodically in Visual Studio. It will always take time to get
used to the environment, but that's not really avoidable and shouldn't
detract from the language.

> It would be easy to trade punches with 'killer features', but it does seem
> to me that LabView struggles with any decision/program flow activities,
> whilst making straightforward monitoring a doddle. Your comments about

I don't see why- the basic decision making structures are the same in
Labview as in C++.

> memory problems and dodgy pointers are very common, and are surely one of
> the principle reasons that punters are choosing LabView over CVI.
Competent
> programming is all thats required to combat them though, so are people so
> distrustful of their own abilities? Am I bragging to say that it's never
> happened to me? And on top of all that, I can make direct calls to the

Even if you get it right first time, you're still having to spend more time
concentrating on the nuts+bolts of the language rather than dealing with the
problem you're trying to solve.

> But my main gripe is that I'm being dragged kicking and screaming into an
> area that I consider to be deeply inferior (with or without good reason)
to
> CVI. The user base is 5-10 times that of CVI, and growing. Money forces
> the change.

Money ultimately forces every change- but why do you think money forces this
particular change? It's because in most applications the faster development
time in Labview saves more money in man hours than the higher efficiency in
Labwindows/C saves on hardware.

> And at least there IS a LabView newsgroup, there is no CVI counterpart!

Well, Labview is a full language; the bulk of Labwindows programming is
covered by the C newsgroups; the only thing the C newsgroups don't cover is
the GUI.

[Dennis_Knutson]

First of all as LabVIEW user for 10 years and a LabWindows user since version 1 (the bad old DOS days), I consider myself competent in both. Both environments have strengths and weaknesses and while developing in one I've often wished for a feature that the other one had (remember how difficult it used to be have a simple table in LabWindows?).

I daresay most of your comments are due to the fact that you are new to LabVIEW and are still at the bottom of the learning curve. While steep, it is far less steep than faced by a brand new C programmer. That 30 minute LabVIEW demo can be done by myself or any other experienced LabVIEW programmer in a time equal or less than the 90 seconds you mention taking in LabWindows.

"Really simple
thing
s like moving controls on the page were difficult (CVI doesn't have [or
need] a 'pick' tool)! "

This is a just a ridiculus statement since the .uir does require and have a "pick" tool to move controls as well as a text tool and a paint tool.

I have also never seen the extreme speed difference between a well written LabWindows program and a well written LabVIEW program. The only speed difference of note is that it is typically faster to create a test and measurement application in LabVIEW. And that's the main money issue involved. NONE of the people that use my programs care what language they were written in. The only thing that matters is that I can get them written faster.

p.s.

I'm aware of numerous C usenet groups and there is also the LabWindows mail server and the LabWindows Developer Exchange at zone.ni.com.

[steve.root1]

Right - gloves off then!


"Dennis Knutson" wrote:

> First of all as LabVIEW user for 10 years and a LabWindows user since
> version 1 (the bad old DOS days), I consider myself competent in both.
> Both environments have strengths and weaknesses and while developing
> in one I've often wished for a feature that the other one had
> (remember how difficult it used to be have a simple table in
> LabWindows?).
>

The table features still crap. I use Excel if poss. or a list control if
not.

> I daresay most of your comments are due to the fact that you are new
> to LabVIEW and are still at the bottom of the learning curve. While
> steep, it is far less steep than faced by a brand new C programmer.
> That 30 minute LabVIEW demo can be done by myself or any other
> experienced LabVIEW programmer in a time equal or less than the 90
> seconds you mention taking in LabWindows.

When you started you got books. On-line help is no substitute.

> "Really simple
> things like moving controls on the page were difficult (CVI doesn't
> have [or
> need] a 'pick' tool)! "
>
> This is a just a ridiculus statement since the .uir does require and
> have a "pick" tool to move controls as well as a text tool and a paint
> tool.

Don't give me that. click and drag to move, double click to set properties.
It doesn't get simpler than that. No toolbox selection required.

>
> I have also never seen the extreme speed difference between a well
> written LabWindows program and a well written LabVIEW program. The

Write a program with a timer and count loops. Compare and contrast. I
would have attached mine, but it came to 100k. Speed counts with a lot of
I/O.

> only speed difference of note is that it is typically faster to create
> a test and measurement application in LabVIEW.

Sorry - I just think that statement is a fallacy. It's a perceived view
that
can't be tested in the real world.

> And that's the main
> money issue involved. NONE of the people that use my programs care
> what language they were written in. The only thing that matters is
> that I can get them written faster.

The money issue i was talking about was that of EARNING the stuff! Labview
is in demand. CVI not so. The people that use programs don't care. The
people that maintain them do.

> p.s.
>
> I'm aware of numerous C usenet groups and there is also the LabWindows
> mail server and the LabWindows Developer Exchange at zone.ni.com.

Have a wander round it sometime. If you whistle you can hear the echo in
the empty space!

[Dennis_Knutson]

>Write a program with a timer and count loops. >Compare and contrast. I
>would have attached mine, but it came to 100k. Speed >counts with a lot of
>I/O.

It certainly does and but for instrument control and data acquisition (the meat and potatoes of our business), there is no difference. For things like memory and array manipulation, CVI works best.

>Have a wander round it sometime. If you whistle you >can hear the echo in
>the empty space!"

More and more people are seeing the light everyday.


>Sorry - I just think that statement is a fallacy. >It's a perceived view
>that
>can't be tested in the real world.

It has been tested. By me and everyone who's had to write a CVI instrument driver and a La
bVIEW one. It's also been tesed by some trade magazines.

[CraigGraham]

steve.root1 wrote in message
news:%DGz7.2946$uh1.745136@news6-win.server.ntlworld.com...

> The money issue i was talking about was that of EARNING the stuff!
Labview
> is in demand. CVI not so. The people that use programs don't care. The
> people that maintain them do.

Heh- doesn't seem to be at the moment. Over a year ago I was headhunted for
a very lucrative Labview contract. Couldn't take it for personal reasons so
I passed it to a colleague who did take it. I was also approached by other
agencies but the example I quote is the one I'm most familiar with. Now I'm
bored with my present job and ready to move on, and so far I've looked for
about 6 weeks without finding anything suitable.

Okay,
6 weeks may be a short timescale and I have another year to pick and
choose before my job here finishes, but from the UK there doesn't seem to be
a great deal around right now. Not unless I move to a job just north of
London where the salary is at most 1.5X my present one and the house prices
are more than 3X.

What are other people finding at the moment?

[JeanPierre]

When you want to change cursor or use the right click, you have to make a
WinAPI call, whether you use LabVIEW or LabWindows. LabVIEW Users simply ask
how to make these calls and often other users have conveniently wrapped
these system call in G toolkits.

LabVIEW is mostly platform independant. VIs developped on Windows can be
opened and run on Macs, Solaris and Linux machine. Such system calls break
this platform dependance and are usually avoided. After all, Macs do not
have a right mouse button...

Jean-Pierre Drolet