Labview shortcomings?

[Remington]

Hello,

I've only been using Labview6.1 for about two weeks now and am very impressed with it's ease of use and capabilities for instrument control. To the more seasoned users of Labview, I would like to know if you've found any programming issues that Labview has not been able to address? Can it be used for writing almost any program that we can think of?

[wiebe@CARYA]

Hi,

Yes, LabVIEW can be used for witing any program. But LV is less suitable for
writing administrative programs (e.g. financial programs), or for programs
that need to be small.

One of the few technical things that is very hard to do in LabVIEW is
working with pointers to functions. This prevents real OOP, because function
overwriting, inheretance, multiple inheretance are hard to do. It also is
hard to interface with some API's because of this (the API's that use
callbacks).

Regards,

Wiebe.

"Remington" wrote in message
news:50650000000800000040790000-1042324653000@exchange.ni.com...
> Hello,
>
> I've only been using Labview6.1 for about two weeks now and am very
> impressed with it's ease of use and capabilities for instrument
> control. To th
e more seasoned users of Labview, I would like to know
> if you've found any programming issues that Labview has not been able
> to address? Can it be used for writing almost any program that we can
> think of?

[mikeporter]

I have yet to run into anything useful that I couldn't do with LV. Of course I've never had the desire to write a word processor for spreadsheet progeam.

In terms of all the OO-stuff. That's only an issue if you assume that OO adds anything useful to the dataflow structure already in LV--which it doesn't.

Mike...

[Dennis_Knutson]

I haven't found any real limitations in what I need to do. Designing an advanced user interface with MDI, child windows, tear off tool strips, etc. is hard to impossible. Low level hardware control is best done with C/C++. Jeff Kodosky (the inventor of LabVIEW) has an article entitled "Is LabVIEW a general purpose programming language?". You can find it here.

[Trager]

You could use LV for almost anything, but there area number of situations in which it's less than ideal. Although the new event structure is great for trapping front panel events, the ability to write truly event driven software (particularly in the real time environment) is still limited.

[Stephen Boulet]

Some of the shortcomings I see after working with LabVIEW for a number of
years are difficulty in maintaining other people's code and complexity issues
when trying to scale programs past a certain point. Also, since it's
graphical, you can't do global search and replace the way you could with a
text language.

But if you keep the scope more limited, you can be very efficient with it.

It would be a poor choice for, say, real-time programming or text/data
processing -- gathering and formatting the data in the first place yes, but I
find other solutions better for data processing/reporting.

-- Stephen

Remington wrote:
> Hello,
>
> I've only been using Labview6.1 for about two weeks now and am very
> impressed with it's ease of use and capabilities for i
nstrument
> control. To the more seasoned users of Labview, I would like to know
> if you've found any programming issues that Labview has not been able
> to address? Can it be used for writing almost any program that we can
> think of?

[wiebe@CARYA]

Mike,

You're absolutelly right! I couldn't find the words for it...

> In terms of all the OO-stuff. That's only an issue if you assume that
> OO adds anything useful to the dataflow structure already in LV--which
> it doesn't.

Regards,

Wiebe.

"mikeporter" wrote in message
news:50650000000500000055D60000-1042324653000@exchange.ni.com...
> I have yet to run into anything useful that I couldn't do with LV. Of
> course I've never had the desire to write a word processor for
> spreadsheet progeam.
>
> In terms of all the OO-stuff. That's only an issue if you assume that
> OO adds anything useful to the dataflow structure already in LV--which
> it doesn't.
>
> Mike...

[Jim_Kring]

I am finding myself limited by:

==> lack of OO inheritance

==> the tools for implementing one's own polymorphic VIs

==> Global VI namespace

==> Scriptability {For simple scripting, a text-based environment is more maintainable. There are fewer steps for adding a loop around a block of code, removing, adding, or commenting-out a line of code, etc. Editing LabVIEW is a little more like transplant surgery. You have to prepare the patient, cut it open, take out the old, put in the new, and stitch it back up. Finally you have to see if it still runs correctly, when your finished. In each of those steps there are small chances for mistakes.}

==> Inability to automate various development and editing tasks.

==> Working with custom palettes is
not straight-forward.

-Jim

[wiebe@CARYA]

Jim,

In LV 6 you can make your own polymorphic VI's.

Regards,

Wiebe.


"Jim Kring" wrote in message
news:506500000005000000CBD60000-1042324653000@exchange.ni.com...
> I am finding myself limited by:
>
> ==> lack of OO inheritance
>
> ==> the tools for implementing one's own polymorphic VIs
>
> ==> Global VI namespace
>
> ==> Scriptability {For simple scripting, a text-based environment is
> more maintainable. There are fewer steps for adding a loop around a
> block of code, removing, adding, or commenting-out a line of code,
> etc. Editing LabVIEW is a little more like transplant surgery. You
> have to prepare the patient, cut it open, take out the old, put in the
> new, and stitch it back up. Finally you have to see if it still runs

> correctly, when your finished. In each of those steps there are small
> chances for mistakes.}
>
> ==> Inability to automate various development and editing tasks.
>
> ==> Working with custom palettes is not straight-forward.
>
> -Jim

[Jim_Kring]

Yes,

I said that:

"I am finding myself limited by the tools for implementing one's own polymorphic VIs".

My statement is simply that the current implimentation of making polymorphic VIs limiting. There are several instances, specifically with compound data types, where it is impossible to define a polymophic member function for every possible permutation of data type. Also I find the management of Polymorphic functions to be a chore. What I would prefer is a "broken", or undefined, data type that would allow a subVI's inputs and outputs to be defined by the context of the caller. This is not impossible, because it can be done with units for numerical data types using the units "$x" syntax (where x is a single digit from 1 to 9) see
the following link for more info:

http://zone.ni.com/devzone/conceptd.nsf/webmain/A6B7E1D590276DA986256A3A006885FB?opendocument

For example, what if I want to define an operation that works for all arrays, regardless of the element type. Why should I necessarliy have to declare the element type, at edit time. Same thing goes for clusters. The only way to do this, right now is with Variants, and this is quite cumbersome as well and often requires implementation of the core functionality for every possible (or needed) data type.

-Jim