LabVIEW to FPGA?

[DougD]

Maybe it isn't but it should be if it wants to grow. Hasn't it gone
as far as it can in the instrumentation niche market? It certainly
could take on Microsoft for development of ordinary applications if
it's pricing structure was competitive with Microsoft. It's certainly
a lot easier to learn how to use and a lot quicker for development of
simple to medium applications.

Doug De Clue
ddeclue@bellsouth.net


Eric Inazaki wrote in message news:...
> On 5 Aug 2002 09:52:12 -0700, ddeclue@bellsouth.net (Douglas De Clue)
> wrote:
>
> >
> >LabVIEW is tremendously easy to use but if it is to ever catch on for
> >more general computing tasks outside of ins
trumentation, National
> >Instruments will need to address these 3 issues.
> >
>
> Granted I don't really keep up with this sort of thing, but I didn't
> know that NI was pushing for LabVIEW to be a general purpose
> language/environment.

[Eric Inazaki]

In article <6f0395b7.0208051854.3dedba40@posting.google.com>, ddeclue@bellsouth.net (Douglas De Clue) wrote:

> Maybe it isn't but it should be if it wants to grow. Hasn't it gone
> as far as it can in the instrumentation niche market? It certainly
> could take on Microsoft for development of ordinary applications if
> it's pricing structure was competitive with Microsoft. It's certainly
> a lot easier to learn how to use and a lot quicker for development of
> simple to medium applications.
>

Bear in mind that NI is a niche company (test and measurement). It
probably wouldn't make good sense for them to grow out of that niche
with only one product. Like Clint Eastwood said "A man's got to know
his limit
ations".

[tom]

Eric Inazaki wrote:

> On 5 Aug 2002 09:52:12 -0700, ddeclue@bellsouth.net (Douglas De Clue)
> wrote:
>
> >
> >LabVIEW is tremendously easy to use but if it is to ever catch on for
> >more general computing tasks outside of instrumentation, National
> >Instruments will need to address these 3 issues.
> >
>
> Granted I don't really keep up with this sort of thing, but I didn't
> know that NI was pushing for LabVIEW to be a general purpose
> language/environment.

I have only been using it for two and a half years but have seen it as
nothing but.

Tom

[Scott Seidman]

ddeclue@bellsouth.net (Douglas De Clue) wrote in
news:6f0395b7.0208051854.3dedba40@posting.google.com:

> Maybe it isn't but it should be if it wants to grow. Hasn't it gone
> as far as it can in the instrumentation niche market? It certainly
> could take on Microsoft for development of ordinary applications if
> it's pricing structure was competitive with Microsoft. It's certainly
> a lot easier to learn how to use and a lot quicker for development of
> simple to medium applications.
>
> Doug De Clue
> ddeclue@bellsouth.net
>
>
> Eric Inazaki wrote in message
> news:...
>> On 5 Aug 2002 09:52:12 -0700, ddeclue@bellsouth.net (Douglas De Clue)
>> wrote:
>>
>> >
>> >LabVIEW is tremendously easy to use but if it is to ever catch on
>> >for more general computing tasks outside of instrumentation,
>> >National Instruments will need to address these 3 issues.
>> >
>>
>> Granted I don't really keep up with this sort of thing, but I didn't
>> know that NI was pushing for LabVIEW to be a general purpose
>> language/environment.
>

You grow super-big by leaving out details like good customer service. I
think that NI fills their niche nicely, though you can hardly call
instrumentation a niche market.

If NI expands too much into other markets, they need to make sure that
their original customer base is kept happy. They also have a ton of
other problems to address to satisfy a "general audience". For example,
there is a huge base of highly developed and debugged libraries and
algorithms that they would need to find someway to support, or write
their own.

Also, for prototyping code that doesn't involve great GUIs or some other
type of outside-world interface, give me Matlab any day. The advantage
of "living in" your workspace to do code development and debugging is too
big an advantage to give up.

I think there is no better option than Labview for many types of
projects, but I'm not sure that it will ever be my "go to" environment
for general purpose programming.

--
Scott
Reverse first field of address to reply

[wiebe@CARYA]

"Douglas De Clue" wrote in message
news:6f0395b7.0208051854.3dedba40@posting.google.com...
> Maybe it isn't but it should be if it wants to grow. Hasn't it gone
> as far as it can in the instrumentation niche market? It certainly

No it hasn't. In the Netherlands, universities are still getting started
with teaching LabVIEW to students. In five years, these studens will know
LV, and tell their bosses about it.

Also, speaking to other R&D developers, T&M developers; not a lot of them
are even familiar with LabVIEW. There still is room to grow.

Btw. I don't think LV is that slow in execution. Making exactly the same
think in C, will not make that much difference in speed. E.g. building a
large array with auto-indexing takes a lot of time. Memory is relocated
every time the data outgrows the placeholder. In C++ you'll reserve the
memory before the routine starts. The routine will run faster. Doing this in
LabVIEW (initializing a large array before the routine starts) and then
replace the array elements will run faster, like C++! Ergo, in C++ it is
easier to make a fast routine, because the programming language forces this.
In LV it is easy to program, it's a bit harder to do this efficientlly.
Using pointers makes it even easier to build fast routines, like link lists,
trees etc.

The price of LV is a problem. Individuals will not consider buying LV if
VC++ costs < $100. For companies development time will be more expensive. To
grow I think a personal, not limited, edition would be nice. (If people use
it at home, it will grow, like winzip, acrobat reader, etc.) Don't know if
this legally possible...

The size of the executables is large, but the size of the runtime dll is
simply too large. But I don't think LV ever compiles this dll. It is simply
copied.

Regards,

Wiebe.



> could take on Microsoft for development of ordinary applications if
> it's pricing structure was competitive with Microsoft. It's certainly
> a lot easier to learn how to use and a lot quicker for development of
> simple to medium applications.
>
> Doug De Clue
> ddeclue@bellsouth.net
>
>
> Eric Inazaki wrote in message
news:...
> > On 5 Aug 2002 09:52:12 -0700, ddeclue@bellsouth.net (Douglas De Clue)
> > wrote:
> >
> > >
> > >LabVIEW is tremendously easy to use but if it is to ever catch on for
> > >more general computing tasks outside of instrumentation, National
> > >Instruments will need to address these 3 issues.
> > >
> >
> > Granted I don't really keep up with this sort of thing, but I didn't
> > know that NI was pushing for LabVIEW to be a general purpose
> > language/environment.

[DougD]

There may be some truth in what you're saying. It may be better to
remain in a niche market underneath Microsoft's radar than to draw
fire, i.e. be another Borland, or Watcom, or Java that Bill goes out
of his way to kill.

On the other hand, I think LabVIEW is such a simple way to learn to
program that Bill would find it almost impossible to stop if NI
started handing it out to schools for free or cheap and selling at
CompUSA for cheap in shrink wrap. I think NI could rule the world
instead of MS if they tried this.

In fact, someone is already trying to do this. There's a product
called Softwire that costs about 400 dollars that sits on top of VB
that works more or less like LabVIEW (wired da
taflow). I keep
wondering when I'll hear about a lawsuit against Softwire from NI or
about NI acquiring Softwire. NI better not let Bill acquire Softwire.

Doug De Clue
ddeclue@bellsouth.net




Eric Inazaki wrote in message news:<050820022359337031%penfold@deadbeat.edu>...
> In article <6f0395b7.0208051854.3dedba40@posting.google.com>, ddeclue@bellsouth.net (Douglas De Clue) wrote:
>
> > Maybe it isn't but it should be if it wants to grow. Hasn't it gone
> > as far as it can in the instrumentation niche market? It certainly
> > could take on Microsoft for development of ordinary applications if
> > it's pricing structure was competitive with Microsoft. It's certainly
> > a lot easier to learn how to use and a lot quicker for development of
> > simple to medium applications.
> >
>
> Bear in mind that NI is a niche company (test and measurement). It
> probably wouldn't make good sense for them to grow out of that niche
> with only one product. Like Clint
Eastwood said "A man's got to know
> his limitations".

[Sergey Yakovlev]

Hello, All!
It was very interesting discussion in this topic about nature of LV code!
But let me remember that the initial question was connected to possibility
to embed LV code into the FPGA devices.
I believe, that it is a quite difficult task for the present time - to
compile LV code into the FPGA's, but more interesting for me is the
question: is it possible to embed LV code into some kind of DSP's or
controllers?
Is it possible to build a LV stand-alone application for real-time operating
system like Linux and use it in embedded system without any graphic card. I
know, that it is possible for Linux version of LV, but I don't know how to
build such application in compact form.

[Scott Seidman]

"Sergey Yakovlev" wrote in
news:aio3et$qs0$1@mamenchi.zrz.TU-Berlin.DE:

> Hello, All!
> It was very interesting discussion in this topic about nature of LV
> code! But let me remember that the initial question was connected to
> possibility to embed LV code into the FPGA devices.
> I believe, that it is a quite difficult task for the present time - to
> compile LV code into the FPGA's, but more interesting for me is the
> question: is it possible to embed LV code into some kind of DSP's or
> controllers?
> Is it possible to build a LV stand-alone application for real-time
> operating system like Linux and use it in embedded system without any
> graphic card. I know
, that it is possible for Linux version of LV, but
> I don't know how to build such application in compact form.
>
>
>
>

This last paragraph is pretty much what labview RT, in conjunction with the
PXI platform, does. Except its not really standalone-- some sort of
labview engine still runs on the PXI platform (I think!!)



--
Scott
Reverse first field of address to reply

[Labviewguru]

Sergey,

This isn't just possible, it's been done.

Pick up Gary Johsons's last book: Power Programming 3e. Starting in chapter 22, he and his coauthor discuss embedding a LabVIEW program into Linux on a PC104. This can also be done using Realtime Linux, though I believe you will be stuck with a 1ms resolution there, unless you use LabVIEW RT for linux or something to that effect.

The only problem with this is that there is more overhead than necessary because LabVIEW has to run on top of a common operating system.


With regards to the balance of the discussion, I have been doing a bit of research myself on writing a compiler for embedded and other systems, in order to create my own compact executables. Of course the problem is that this doesn't allow you to compile LabVIEW code, but rather compiles whatever instructions you would input into an executable or hex/machine code. This is a rather daunting task, and it would basically be the creation of a new programming language (or recreation of an old one.) I think this would be a great task for LabVIEW, but it would be a very niche product, with a very limited scope. Compilers are a dime-a-dozen these days, and most use a very common language: C.

Like most of us, I too long to see the day when LabVIEW can compile compact executables containing all the necessary elements to run.

By the way, I have seen Softwire. There is a reason NI isn't after them. First of all, it is beyond the scope of the Patents for LabVIEW. Second, that company will be out of business inside of a year or two. I received a sample of this software, and was completely unimpressed. The idea is nice, the implementation is pretty good, but it lacks some very important elements that LabVIEW has that many many people so often overlook, elements that also make C/C++ so damn difficult to learn. LabVIEW ships with a slew of example programs that show the user just how to solve some common classes of problems, and offers a base program for the user to expand upon. In the first few months of programming in LabVIEW, as I had no instruction, I relied heavily on these examples. If Microsoft Visual C++ or even VB contained the quality, variety, and number of examples that LabVIEW contains, I would have already learned VB and C++ by now.

LabVIEW is more than just an easy programming language to learn, but it is also something that can be so much more. I have approached National Instruments on several occasions about making a version or adding the capability to create compact stand alone executables. Since I first approached them in 1999, I don't think they are that interested, as I haven't seen anything to date that indicates they are interested. LabVIEW is, and probably will remain, a niche language that is strictly an enabling vehicle for National Instruments' sole profit center: Hardware. Remember, people don't buy DAQ hardware to go along with LabVIEW, they buy LabVIEW to go along with their DAQ hardware...or at least that is what market research tells National Instruments...

National Instruments doesn't want to be in competition with Microsoft. Microsoft makes software, and National Instruments (note the word "instruments" in the name...) makes hardware. LabVIEW is only there to make using the hardware easier.

Maybe we'll get lucky and National Instruments will prove me wrong (gee, I sure hope so...I can't stand C/C++.)

[tom]

Labviewguru wrote:

> Sergey,
>
> This isn't just possible, it's been done.
>
> Pick up Gary Johsons's last book: Power Programming 3e. Starting in
> chapter 22, he and his coauthor discuss embedding a LabVIEW program
> into Linux on a PC104. This can also be done using Realtime Linux,
> though I believe you will be stuck with a 1ms resolution there, unless
> you use LabVIEW RT for linux or something to that effect.
>
> The only problem with this is that there is more overhead than
> necessary because LabVIEW has to run on top of a common operating
> system.
>
> With regards to the balance of the discussion, I have been doing a bit
> of research myself on writing a compiler for embedded and other
> systems, in order to create my own compact executables. Of course the
> problem is that this doesn't allow you to compile LabVIEW code, but
> rather compiles whatever instructions you would input into an
> executable or hex/machine code. This is a rather daunting task, and
> it would basically be the creation of a new programming language (or
> recreation of an old one.) I think this would be a great task for
> LabVIEW, but it would be a very niche product, with a very limited
> scope. Compilers are a dime-a-dozen these days, and most use a very
> common language: C.
>
> Like most of us, I too long to see the day when LabVIEW can compile
> compact executables containing all the necessary elements to run.
>
> By the way, I have seen Softwire. There is a reason NI isn't after
> them. First of all, it is beyond the scope of the Patents for
> LabVIEW. Second, that company will be out of business inside of a
> year or two. I received a sample of this software, and was completely
> unimpressed. The idea is nice, the implementation is pretty good, but
> it lacks some very important elements that LabVIEW has that many many
> people so often overlook, elements that also make C/C++ so damn
> difficult to learn. LabVIEW ships with a slew of example programs
> that show the user just how to solve some common classes of problems,
> and offers a base program for the user to expand upon. In the first
> few months of programming in LabVIEW, as I had no instruction, I
> relied heavily on these examples. If Microsoft Visual C++ or even VB
> contained the quality, variety, and number of examples that LabVIEW
> contains, I would have already learned VB and C++ by now.
>
> LabVIEW is more than just an easy programming language to learn, but
> it is also something that can be so much more. I have approached
> National Instruments on several occasions about making a version or
> adding the capability to create compact stand alone executables.
> Since I first approached them in 1999, I don't think they are that
> interested, as I haven't seen anything to date that indicates they are
> interested. LabVIEW is, and probably will remain, a niche language
> that is strictly an enabling vehicle for National Instruments' sole
> profit center: Hardware. Remember, people don't buy DAQ hardware to
> go along with LabVIEW, they buy LabVIEW to go along with their DAQ
> hardware...or at least that is what market research tells National
> Instruments...
>
> National Instruments doesn't want to be in competition with Microsoft.
> Microsoft makes software, and National Instruments (note the word
> "instruments" in the name...) makes hardware. LabVIEW is only there
> to make using the hardware easier.
>
> Maybe we'll get lucky and National Instruments will prove me wrong
> (gee, I sure hope so...I can't stand C/C++.)

Quite simply I find writing ordinary sequential code old fashioned.
C is as old as the hills- 1968? C++ may be newish but is a nightmare
to learn. I used to use Matlab a lot and Matrixx (after I dumped Fortran
77) - of these Matrixx
definately had the edge. They had a system called 'rapid prototyping'
where
a block diagram would generate code for a target microprocessor.
LabVIEW I think is a step above both of them and could indeed become
a general language to program in for many scientific and engineering
applications
at least. I remember when I first used C - I said to somebody who was
the 'expert' - 'right how do I get complex numbers'? - 'Oh', the reply
came - 'you will have to write your own functions'! I mean that is not
a high level language in my book!

The thinking is different in LabVIEW and at least they have type COMPLEX .
My experience is that students take to LabVIEW
like a duck to water and complain all the time about C++.
By the way - many maths people are still using Fortran! It would be great
to be able to program embedded systems in LabVIEW, the skies the limit.

Tom