Slashdot Mirror

The geniuses are working for NI. The deadlocks and race conditions can be controlled using dataflow programming. The language is called LabVIEW. http://www.ni.com/multicore

Hello, You might want to check out the NI "ELVIS". It's not cheap, but would provide an awesome platform to experiment with and learn about electronics. It is complete with built-in instrumentation and even integrates nicely with circuit simulation (Multisim) software. NI ELVIS II: http://sine.ni.com/nips/cds/view/p/lang/en/nid/205425

http://www.ni.com/multicore/ They have been doing it for a while.

Interesting if the XP upgrade was causal or coincidental... We use XP SP2, firewall off (no external net access), all updates applied. Ensure you have no interrupt conflicts - that may have happened inadvertently with the 2k to XP upgrade.

NI, as you prolly know, claims to support PCMCIA w/ 2.5 - http://zone.ni.com/devzone/cda/tut/p/id/5326 - we didn't see any problems with GPIB+, PCI or USB going from 2.2 to 2.5 - but the PCMCIA doesn't support DMA, so maybe they missed something as you suspect.

Also, make sure you're NOT config'd to go at the max possible rate (HS488) - I don't recall but that config param default may be changed with the newer driver - a no-no if you're DMA incapable (ok, I'm swag'ing here - but it makes sense to me). Check timing params also - sorry, not in front of an NI machine, so this is all by memory....

Also - don't underestimate the flakey GPIB cable bit. I had a similar experience and sadly the days of bullet-proof HP GPIB cables are gone. Open the shell on one today and you'll find nice, vibration-sensitive, press-in wiring connectors. If it's a bad ATN or NDAC wire, then you're just seeing the first problem in the OPC query.

Best luck!

OK, so just to clarify a bit. My company (National Instruments) is a FAST Enterprise Search customer (ESP5) so I can provide a little insight into the product.

FAST is a full featured search engine software product. It's not an Internet search engine, though it used to power alltheweb.com. It is suitable for use powering traditional Web search - we have two FAST installations, and one of them is used purely for search on our external Web site. It is very powerful and customizable; you can create custom dictionaties, taxonomies, et cetera. We have built faceted navigation on top of it and are using it to return little portlets of related links, etc - things we used to use cumbersome database queries to do. Check out http://www.ni.com/dataacquisition/ - the drilldown facets there are driven by FAST working off product metadata. Click through to a specific product page, like http://sine.ni.com/nips/cds/view/p/lang/en/nid/203718, and the "resources" tab is a result of a FAST search for manuals, white papers, data sheets, et cetera.

It is also a "much more than just Web page" enterprise search. We have an internal FAST installation that searches Intranet pages, file shares and document repositories of all sorts, Lotus Notes databases, and database tables from our ERP system. It serves as an information gateway to many different sources of information. Documents insert themselves into the engine as they are published out of our CMS. The content indexing pipeline is a completely customizable (in Python) setup, so if you have docs in some proprietary format you need indexed, you can do it. You can tweak the result ranking in many different ways.

There's other companies using FAST for different things - like there's a company in town that's in the email space; they use Fast InStream to index mail immediately as it flows in to make a completely searchable mail repository.

FAST and Autonomy are the leaders in this market. Forrester and Gartner analyst reports agree. We did an extensive evaluation when we moved to FAST several years ago - we had been on Inktomi and then on AltaVista for a time for our enterprise search. FAST was the clear winner.

Though Google is tops in Web search, its search appliance is not competitive - it's very "black box." If you have simple enough search needs that you can just plop down an appliance and have it spider and then use its canned search algorithms, it's fine, but enterprise search needs are usually more complicated than Internet search needs (and the algorithms that make Google good for Internet search tend to not hold up well in an Intranet environment). As a result, serious search developers can't use the Google enterprise product.

OK, so just to clarify a bit. My company (National Instruments) is a FAST Enterprise Search customer (ESP5) so I can provide a little insight into the product.

FAST is a full featured search engine software product. It's not an Internet search engine, though it used to power alltheweb.com. It is suitable for use powering traditional Web search - we have two FAST installations, and one of them is used purely for search on our external Web site. It is very powerful and customizable; you can create custom dictionaties, taxonomies, et cetera. We have built faceted navigation on top of it and are using it to return little portlets of related links, etc - things we used to use cumbersome database queries to do. Check out http://www.ni.com/dataacquisition/ - the drilldown facets there are driven by FAST working off product metadata. Click through to a specific product page, like http://sine.ni.com/nips/cds/view/p/lang/en/nid/203718, and the "resources" tab is a result of a FAST search for manuals, white papers, data sheets, et cetera.

It is also a "much more than just Web page" enterprise search. We have an internal FAST installation that searches Intranet pages, file shares and document repositories of all sorts, Lotus Notes databases, and database tables from our ERP system. It serves as an information gateway to many different sources of information. Documents insert themselves into the engine as they are published out of our CMS. The content indexing pipeline is a completely customizable (in Python) setup, so if you have docs in some proprietary format you need indexed, you can do it. You can tweak the result ranking in many different ways.

There's other companies using FAST for different things - like there's a company in town that's in the email space; they use Fast InStream to index mail immediately as it flows in to make a completely searchable mail repository.

FAST and Autonomy are the leaders in this market. Forrester and Gartner analyst reports agree. We did an extensive evaluation when we moved to FAST several years ago - we had been on Inktomi and then on AltaVista for a time for our enterprise search. FAST was the clear winner.

Though Google is tops in Web search, its search appliance is not competitive - it's very "black box." If you have simple enough search needs that you can just plop down an appliance and have it spider and then use its canned search algorithms, it's fine, but enterprise search needs are usually more complicated than Internet search needs (and the algorithms that make Google good for Internet search tend to not hold up well in an Intranet environment). As a result, serious search developers can't use the Google enterprise product.

http://www.ni.com/multicore/

Even an embedded Linux platform (e.g. Gumstix) would be a bad idea for this project, as cross-compiling is a PITA. For rapid development (something I have much experience in), go with a standard PC with your development system of choice: C/C++, LabVIEW (really, not flamebait :) , MATLAB, etc.. Basically whatever you already know. Whatever can get data in and out of an ethernet port.

As for hardware, there are so many ways to go. If you have some cash laying around, go with National Instruments as their hardware line is well supported, has a very nice C/C++ API library, and will stand up to the elements pretty well. Even if you're on a budget, they sell some multifunction USB DAQs for less than $200. Buy your motor controllers and control wiring from Automation Direct they'll have almost everything you need.

Having worked on development on robotic telescopes, both hardware and software, let me tell you that using Linux was not an easy choice. We had to narrow our search to vendors who explicitly support Linux, and even there, their support was flaky at best and we spent hours in troubleshooting the drivers before we got them to work. However, this exercise resulted in better support for Linux from the vendor, so it's a win-win situation. We opted for National Instruments for their excellent DAQ boards & LabView which are all supported under Linux.

For the control system, we used INDI, it's a powerful server/client control protocol that you can use to jump start your project within minutes. While it is geared toward astronomy, it can be used for any purpose.

Ah, dataflow. It's too bad LabVIEW's (http://zone.ni.com/devzone/cda/tut/p/id/6422) not a "real" language. Built in multi-core, multi-threaded compiler support, multi-platform portable... and most folks can even manage to draw two squares to make their processes parallel.

Have fun with all that text, though.

Ten Years ? I think you should take a look at this: http://www.ni.com/niweek/keynotevideos.htm [ni.com] link posted on /. by SparahawkA a couple of days ago. You need to choose Tuesday of the menu box top right and scroll down to the last item 'Algorithm Engineering" Time for the Tinfoil Fedora I think ! J7

For another cool demo of the Audeo and how it was developed, you can watch a 5-minute video here:
http://www.ni.com/niweek/keynote_videos.htm

It's under "Tuesday" -- the last topic titled "Algorithm Engineering, Michael Callahan, Thomas Coleman"

Enjoy!

You could always use a graphical language like LabVIEW. Datatypes have different wire colors, and comments can be in any font, any size, with any color. Images can be comments. You can use screenshots of LabVIEW code as comments.

(Although, adding picture comments is generally discouraged. I think I spend more time with LabVIEW making sure my block diagram is readable and followable for the other engineers I work with, then I would with a text based language).

Perhaps Dell's reluctance to sell Ubuntu Dell's to Business has something to do with the level of support Ubuntu requires vs Windows. There's a lot of tinkering being enjoyed by all us linux users, I get a big kick myself out of creating applications for my Knoppix remaster, Rapidweather Remaster of Knoppix Linux. (See screenshots, below)
Windows, on the other hand, is pretty much tinker-proof, nobody knows the source code, let alone fix anything by rewriting the scripts that make it up. If I have something that does not work like I want it to in my Remaster, then I get to it, and fix it like I want.

The Dell-Ubuntu-Windows situation might be compared to a Automobile dealership, that has a sports car on the showroom floor to "attract sales traffic", but does not really want to wind up fixing these cars constantly, since they are being bought by "boy racers", and others that are running the tar out of them.
The dealers will go to any lengths to get traffic in the showrooms, they will have a NASCAR racer displayed out front, even have a driver signing autographs.
The dealership is only making money if they sell cars to a bunch of old ladies that just drive the cars like they were supposed to be, and not racing them around.

Are we "racing linux around", trying to get it to break, overheat, and spin out in the curve? Sure we are. We all laugh at the "blue screen of Death". Same thing happens in Linux, but it does not go to a "blue screen". We can back out, and "kill" the offending process, and bring the system back up to normal, without a reboot. You just have to know how to do it, just like a race car owner has to know how to get the most out of his car.
Is Dell doing the race car out front thing by offering "Ubuntu"? Are they just keeping the linux zelots "happy", but not really wanting to have thousands of business support calls on Ubuntu systems, which could be a nightmare. For Vista, Dell offers that neat restoration Image that is made just as the machine leaves the factory floor, with all of your software, so you can "restore" your Vista Dell machine to "factory fresh" condition if it gets fouled up. Usually by adding software, such as LabVIEW 7.1 that is not really Vista compatible, but designed for XP. That can bring a Vista box to a real "no boot" condition fast!
As far as the linux tinkering goes, just look at my Getting Started Guide, it really tends to show that I have tinkered Knoppix into something that no longer remotely resembles the original Knoppix 3.4 in many ways. (One can actually do some work with it now)
My latest fun thing is having it run off Sandisk USB drives, both 2 and 4 GB.
Check my blog for information on that. (I'm running it now from a 4 GB USB drive, persistent home, swap, everything needed to ditch the HD )
Dell wouldn't want to have to do "support" for my Remaster any more than they do for Ubuntu.

I think that what's most likely to happen is we'll see the emergence of a new programming model, which allows us to specify an algorithm in a form resembling a Hasse diagram [wikipedia.org], where each point represent a step and each edge represents a dependency, so that a compiler can recognize what can and cannot be done in parallel and set up multiple threads of execution (or some similar construct) according to that.

You just described LabVIEW. It is a dataflow graphical programming language, meaning that each component executes when all of its inputs are ready. Multiple components that are ready simultaneously can be processed simultaneously. Programs can even consist of completely separate functional dataflows, and both will execute in parallel.

Yes, I believe it already supports multiple processors.

I believe first version of Mindstorms software was not based on LabVIEW. The NXT version is written by National Instruments http://www.ni.com/academic/mindstorms/.

Going from C to LabVIEW was very easy, and I feel knowing LabVIEW made learning MFC / C++ easier too. But I have only written MFC/C++ programs that spawn 1 thread and its quite tricky. In LabVIEW I wrote quite a complex program for measuring motor performance that has 6 main threads, that my coworkers use almost daily.

LabVIEW is geared towards engineers due to the data acquisition (And its like wiring up an electronic schematic), but it can be used as a generic programming language. One drawback is that it does require a runtime engine - so even the smallest apps have a 10MB install package. The best thing I like is that because each VI ("function") has a GUI, you can test the code as you write.

The tricky thing with any multi-threaded app is race conditions.

I think that what's most likely to happen is we'll see the emergence of a new programming model, which allows us to specify an algorithm in a form resembling a Hasse diagram, where each point represent a step and each edge represents a dependency, so that a compiler can recognize what can and cannot be done in parallel and set up multiple threads of execution (or some similar construct) according to that.

Over 10 years ago, I was using a "visual programming language" created by National Instruments called LabView. HP had a similar visual programming language, but was less flashy than LabView. Both used diagrams to describe objects and data flows. These created multi-threaded, parallel processing applications. http://www.ni.com/labview/.

The problem was, spaghetti code ended up actually looking like spaghetti

Actually, National Instruments does make hardware for the very purpose of industrial control and monitoring. There are PC based versions, but some are ruggedized and can run in real-time autonomously and headless (with ethernet connectivity). They work well, can make direct sensor measurements, and are super easy to program. Check out: http://www.ni.com/compactfieldpoint/whatis.htm

1977, Rome:
G. Forsen, M. Nelson, and R. Staron, "Personal Attributes Authentication Techniques," Rome Air Development Center Report RADC-TR-77-1033, Air Force Base Griffis (New York, 1977).

1980, Rand:
R. Gaines, W. Lisowski, S. Press, and N. Shapiro, "Authentication by Keystroke Timing: Some Preliminary Results," Technical Report Rand report R-256-NSF, Rand Corporation (1980).

1990, Gupta:
R. Joyce and G. Gupta, "Identity Authentication Based on Keystroke Latencies," Communications of the ACM 33:2 (1990), 168-176.

1995, IBM:
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/i el3/3531/10615/00491588.pdf?tp=&arnumber=491588&is number=10615

1999, ATT:
http://avirubin.com/fgcs.pdf

2005, MIMOS:
http://digital.ni.com/worldwide/singapore.nsf/web/ all/ACCD272C9FEF487D8625703D005562A0

LabVIEW. http://www.ni.com/labview.

Take a look at LabVIEW, a compiled graphical programming language from National Instruments. It natively supports SMP / multicore / multithreading. Essentially, dissociated pieces of code you write (computations, hardware I/O, etc.) are automatically scheduled in separate threads of execution in order to maximize efficiency. It's an interesting idea: here's a technical article from their website that does a better job of describing it (some marketing included as well): http://zone.ni.com/devzone/cda/tut/p/id/4233

http://www.ni.com/

National Instruments LabVIEW has been de facto standard in automation programming. If you want to play with robotics seriously, you should try out LabVIEW rather than this MS prototype. I tried this MS Visual Programming Language that ships with MS Robotic Studio. It was slow, unintuitive, hard and slow to develop and only had very restricted set of ready-made functionality available. LabVIEW on the other hand is an integrated cross-platform development environment with 20-year history. You can program both desktop computers and various real-time hardware environments with the same language and same development environment. Of course not all functionality is available for real-time targets and dedicated FPGA chips as these only have limited functionality. The downside of LabVIEW is that it's not free but rather expensive. The language is also strictly closed source and National Instruments has been very strict not to release any source code for the runtime environment. Academica can get LabVIEW for reasonable price, for industry prices are rather high.

For more information on LabVIEW see official website and LabVIEW forum LAVA. LabVIEW Toolkit for LEGO® MINDSTORMS® NXT is available for free download (but you need LabVIEW to run it).

National Instruments LabVIEW has been de facto standard in automation programming. If you want to play with robotics seriously, you should try out LabVIEW rather than this MS prototype. I tried this MS Visual Programming Language that ships with MS Robotic Studio. It was slow, unintuitive, hard and slow to develop and only had very restricted set of ready-made functionality available. LabVIEW on the other hand is an integrated cross-platform development environment with 20-year history. You can program both desktop computers and various real-time hardware environments with the same language and same development environment. Of course not all functionality is available for real-time targets and dedicated FPGA chips as these only have limited functionality. The downside of LabVIEW is that it's not free but rather expensive. The language is also strictly closed source and National Instruments has been very strict not to release any source code for the runtime environment. Academica can get LabVIEW for reasonable price, for industry prices are rather high.

For more information on LabVIEW see official website and LabVIEW forum LAVA. LabVIEW Toolkit for LEGO® MINDSTORMS® NXT is available for free download (but you need LabVIEW to run it).

I have trouble believing that if this information is correct, it will stand.

Microsoft is making a big push into manufacturing systems, and enterprise-to-plant-floor integration with partners like SAP, ABB, Invensys, Emerson and others...and if they make it difficult for end users to replace a PC that is running a control system which, in turn, is running a factory that will lose $250,000 a minute if it shuts down...I can see lots of Linux PCs and Macintoshes running Labview 8.20.

It has only been in the last 10 years that Microsoft has been allowed on the plant floor-- especially in distributed control systems. There are plenty Unix control systems continuing to run that could quite easily be ported to Linux or OS X implementations, bypassing Microsoft.

I think Microsoft is either floating a trial balloon, or the original poster got his wires crossed.

Walt Boyes
Editor in chief
Control magazine
www.controlglobal.com

Tried Labview Realtime instead of standard Labview?

http://www.ni.com/realtime/software/

http://www.ni.com/academic/

So this is a fairly sophisticated package, but play around with some of the basic functions. Everything looks like a circuit diagram... just put your basic operators ( + - * / etc.) and pump in different inputs (start with constant numbers, then replace them with dials and stuff), and watch what happens to the output display (start with numbers, move up to gauges and graphs).

Eventually with enough money for extra hardware you'll have them building Lego robots.

They made us use this in college engineering projects and labs, and there were bits of it that were frustrating. But introduce the components a piece at a time, and the kids will be tinkering with all of the other functionality and figuring out the loopholes in no time.

Just so you know, LabVIEW is in fact offered for Linux. I'm forced to use it on Windows myself, but I'm seriously thinking about switching our lab's measurement comps to Linux for ease of scripting, stability, etc.

http://www.ni.com/linux/labview.htm

>>> name 1 company with a 10 year plan

National Instruments has a 100-year plan. But there is a breakdown at the 10-year level, too, if that makes you happier.

Perhaps this is one reason for the company's perpetual 40-ish+ PE ratio; people buy the stock for the long term.

Whoa there, cowboys. Before anyone starts trashing LabVIEW or defending it too harshly, I'd highly recommend doing things the right way.

First off, you can demo LabVIEW online at this link or download an evaluation version at this link (pretty big download).

Next, check out the LabVIEW Introduction Course - 3 Hours Long or preferably the LabVIEW Introduction course - 6 Hours Long. I believe these were written for LabVIEW 7 (latest version is 8.0.1), but you can still get the idea.

Graphical and dataflow-based programming is much different, and it's not going to be a seamless transition. However, after working with it heavily for as little as 4 months, I am HOOKED. If you sent me your C code, I'd be lost and frustrated. Now, if someone sends me their LabVIEW code, I can "just see it" -- like Neo at the end of the Matrix. It's hard to explain, but it just makes sense at a glance now.

Another cool thing that Slashdotters would like is that there is a LabVIEW forum that is supported by both National Instruments employees and LabVIEW enthusiasts. Some guys in there just love helping you out, just as you've seen in the Linux community. forums.ni.com. Very friendly community (although if you are a flamer, NI employees won't say anything, but other customers sure will!)

So try to understand it before bashing it, or just ignore it. But LabVIEW *IS* a programming language -- just something much different than anything you're used to.

PS: No, LabVIEW is not open source. But it's "open enough" for most people.

Oh, and if you check the job listings, you'll see that knowing LabVIEW can get you a very nice salary in some industries. It's the defacto standard for anything in test and measurement, and is branching out to other things now.

Whoa there, cowboys. Before anyone starts trashing LabVIEW or defending it too harshly, I'd highly recommend doing things the right way.

First off, you can demo LabVIEW online at this link or download an evaluation version at this link (pretty big download).

Next, check out the LabVIEW Introduction Course - 3 Hours Long or preferably the LabVIEW Introduction course - 6 Hours Long. I believe these were written for LabVIEW 7 (latest version is 8.0.1), but you can still get the idea.

Graphical and dataflow-based programming is much different, and it's not going to be a seamless transition. However, after working with it heavily for as little as 4 months, I am HOOKED. If you sent me your C code, I'd be lost and frustrated. Now, if someone sends me their LabVIEW code, I can "just see it" -- like Neo at the end of the Matrix. It's hard to explain, but it just makes sense at a glance now.

Another cool thing that Slashdotters would like is that there is a LabVIEW forum that is supported by both National Instruments employees and LabVIEW enthusiasts. Some guys in there just love helping you out, just as you've seen in the Linux community. forums.ni.com. Very friendly community (although if you are a flamer, NI employees won't say anything, but other customers sure will!)

So try to understand it before bashing it, or just ignore it. But LabVIEW *IS* a programming language -- just something much different than anything you're used to.

PS: No, LabVIEW is not open source. But it's "open enough" for most people.

Oh, and if you check the job listings, you'll see that knowing LabVIEW can get you a very nice salary in some industries. It's the defacto standard for anything in test and measurement, and is branching out to other things now.

Whoa there, cowboys. Before anyone starts trashing LabVIEW or defending it too harshly, I'd highly recommend doing things the right way.

First off, you can demo LabVIEW online at this link or download an evaluation version at this link (pretty big download).

Next, check out the LabVIEW Introduction Course - 3 Hours Long or preferably the LabVIEW Introduction course - 6 Hours Long. I believe these were written for LabVIEW 7 (latest version is 8.0.1), but you can still get the idea.

Graphical and dataflow-based programming is much different, and it's not going to be a seamless transition. However, after working with it heavily for as little as 4 months, I am HOOKED. If you sent me your C code, I'd be lost and frustrated. Now, if someone sends me their LabVIEW code, I can "just see it" -- like Neo at the end of the Matrix. It's hard to explain, but it just makes sense at a glance now.

Another cool thing that Slashdotters would like is that there is a LabVIEW forum that is supported by both National Instruments employees and LabVIEW enthusiasts. Some guys in there just love helping you out, just as you've seen in the Linux community. forums.ni.com. Very friendly community (although if you are a flamer, NI employees won't say anything, but other customers sure will!)

So try to understand it before bashing it, or just ignore it. But LabVIEW *IS* a programming language -- just something much different than anything you're used to.

PS: No, LabVIEW is not open source. But it's "open enough" for most people.

Oh, and if you check the job listings, you'll see that knowing LabVIEW can get you a very nice salary in some industries. It's the defacto standard for anything in test and measurement, and is branching out to other things now.

Whoa there, cowboys. Before anyone starts trashing LabVIEW or defending it too harshly, I'd highly recommend doing things the right way.

First off, you can demo LabVIEW online at this link or download an evaluation version at this link (pretty big download).

Next, check out the LabVIEW Introduction Course - 3 Hours Long or preferably the LabVIEW Introduction course - 6 Hours Long. I believe these were written for LabVIEW 7 (latest version is 8.0.1), but you can still get the idea.

Graphical and dataflow-based programming is much different, and it's not going to be a seamless transition. However, after working with it heavily for as little as 4 months, I am HOOKED. If you sent me your C code, I'd be lost and frustrated. Now, if someone sends me their LabVIEW code, I can "just see it" -- like Neo at the end of the Matrix. It's hard to explain, but it just makes sense at a glance now.

Another cool thing that Slashdotters would like is that there is a LabVIEW forum that is supported by both National Instruments employees and LabVIEW enthusiasts. Some guys in there just love helping you out, just as you've seen in the Linux community. forums.ni.com. Very friendly community (although if you are a flamer, NI employees won't say anything, but other customers sure will!)

So try to understand it before bashing it, or just ignore it. But LabVIEW *IS* a programming language -- just something much different than anything you're used to.

PS: No, LabVIEW is not open source. But it's "open enough" for most people.

Oh, and if you check the job listings, you'll see that knowing LabVIEW can get you a very nice salary in some industries. It's the defacto standard for anything in test and measurement, and is branching out to other things now.

Whoa there, cowboys. Before anyone starts trashing LabVIEW or defending it too harshly, I'd highly recommend doing things the right way.

First off, you can demo LabVIEW online at this link or download an evaluation version at this link (pretty big download).

Next, check out the LabVIEW Introduction Course - 3 Hours Long or preferably the LabVIEW Introduction course - 6 Hours Long. I believe these were written for LabVIEW 7 (latest version is 8.0.1), but you can still get the idea.

Graphical and dataflow-based programming is much different, and it's not going to be a seamless transition. However, after working with it heavily for as little as 4 months, I am HOOKED. If you sent me your C code, I'd be lost and frustrated. Now, if someone sends me their LabVIEW code, I can "just see it" -- like Neo at the end of the Matrix. It's hard to explain, but it just makes sense at a glance now.

Another cool thing that Slashdotters would like is that there is a LabVIEW forum that is supported by both National Instruments employees and LabVIEW enthusiasts. Some guys in there just love helping you out, just as you've seen in the Linux community. forums.ni.com. Very friendly community (although if you are a flamer, NI employees won't say anything, but other customers sure will!)

So try to understand it before bashing it, or just ignore it. But LabVIEW *IS* a programming language -- just something much different than anything you're used to.

PS: No, LabVIEW is not open source. But it's "open enough" for most people.

Oh, and if you check the job listings, you'll see that knowing LabVIEW can get you a very nice salary in some industries. It's the defacto standard for anything in test and measurement, and is branching out to other things now.

Put all your money in non-algorithmic, signal-based, synchronous software. It will revolutionize both the hardware and the software industry and usher in the most dramatic change in computing since the days of Charles Babbage and Lady Lovelace.

Do you mean like Labview?

That's not quite true.

> What would be nice would be if someone could resurrect Prograf with it's warts polished off.

  Prograf sounds similar to LabVIEW (http://www.ni.com/labview/demos.htm), which I used when I was doing my physics degree. http://www.icon-tech.com.au/faq_introduction.html. According to that FAQ, there is now an open-source openG project which implements LabVIEW's underlying G programming language (for which LabVIEW itself is an IDE). G can't be represented textually, so it suffers the same problem as Prograf.

  And from experience, making a proper program with error handling, instead of just blindly talking to the physics lab hardware (serial port, GPIB, etc.) adds complexity to the program that makes it harder to deal with any part of the program. Unlike in C, where the error handling code lives near the code that might generate the error, you have to have whole chunks of your program inside case/switch "boxes", with extra "wires" running all over the place.

  However, you could write modules in LabVIEW, and wire them together without seeing their internal complexity, just their inputs and outputs.

  I never really liked LabVIEW as something I wanted to use myself. It is interesting in that it's the only graphical language I know of (well, now I've heard of Prograf). Other people in my class liked it: one guy who really liked it also had some CS background (so he knew what programming in an imperative language like C is like, giving him some basis for comparison). He was also left-handed, which is correlated with being a visual thinker (very much unlike myself). I found LabVIEW to be a real pain sometimes, with the limitations of the built-in library stuff, but that was more than 6 years ago now, so maybe the quality of the thing has improved and it can be a good language for visually oriented people.

http://zone.ni.com/devzone/conceptd.nsf/webmain/37 0DFC6FD19B318C86256A33006BFB78?opendocument

Compare e.g.

Floating-Point Computing A Comedy of Errors?

LabWindows/CVI, was hated by me while i was taking a real time systems class. However, that doesn't mean it wasn't easy to use, or even easier to make all sorts of guages, switches, displays of all sorts. It should fit right in!

For 20 years, NI LabVIEW graphical development has revolutionized the way engineers and scientists create flexible and scalable test, measurement, and control applications rapidly and at minimal cost. With LabVIEW, developers interface with real-world signals, analyze data for meaningful information, and share results and applications. Regardless of experience, LabVIEW makes development fast and easy for all.

it's newest proprietary programming language (Photoshop like , so they say)

I was introduced to Mindstorms via National Instruments, who made the programming software--LabView. A colleague (who has bright teenage boys) reports that this is a great set for bright 11 to 15 year olds, but then they gravitate to other "toys". Now they are into gaming on the Web big time. It's a great tool for introducing kids to engineering, but there doesn't seem to be a lot of staying power. Maybe if they went into development with bigger and bigger sets that would help. That's probably beyond Lego's R&D investment. I think that once the novelty wears off, then it's off to other endeavors. At that rate, the market will never grow.

Check out LabVIEW 8.0, just released three days ago.

National Instruments, of Austin, TX, sells a graphical programming language, called LabVIEW, which has about a 90% market share in the research sector [both for-profit and "not-for-profit"], and which is moving aggressively into the automation sector [i.e. the factory floor].

PS: Ironically, LabVIEW 8.0 was just announced yesterday.

PPS: Unlike many of their competitors [e.g. Agilent], National Instruments weathered the dot-com/dot-bomb tech debacle pretty well:

http://finance.yahoo.com/q/bc?s=NATI&t=my&l=off

National Instruments, of Austin, TX, sells a graphical programming language, called LabVIEW, which has about a 90% market share in the research sector [both for-profit and "not-for-profit"], and which is moving aggressively into the automation sector [i.e. the factory floor].

PS: Ironically, LabVIEW 8.0 was just announced yesterday.

PPS: Unlike many of their competitors [e.g. Agilent], National Instruments weathered the dot-com/dot-bomb tech debacle pretty well:

http://finance.yahoo.com/q/bc?s=NATI&t=my&l=off

National Instruments, of Austin, TX, sells a graphical programming language, called LabVIEW, which has about a 90% market share in the research sector [both for-profit and "not-for-profit"], and which is moving aggressively into the automation sector [i.e. the factory floor].

PS: Ironically, LabVIEW 8.0 was just announced yesterday.

PPS: Unlike many of their competitors [e.g. Agilent], National Instruments weathered the dot-com/dot-bomb tech debacle pretty well:

http://finance.yahoo.com/q/bc?s=NATI&t=my&l=off

We boot into 3.11 because the operational code was developed using Borland C++, but need to exit 3.11 into DOS for the "RT" interrupt capability of the driver for a A/D data acquisition board. You can imagine the hassles that this has given us. It has become a problem just to upload data to our servers.

Our main problem in upgrading the system is that the board hasn't been supported for years, a driver for anything past DOS was never developed, which was proprietary. AFAIK, the company doesn't even exist, and so its unlikey that we could even find someone who might have the code for us to inspect.

Is there a real reason you have to stay with this data acquisition board you're using already? Is it even a PCI card, or is it ISA (wouldn't be surprising at all in a Pentium 90 machine)? Can it even plug into a modern computer? What if the old board you have now breaks -- can it even be replaced? If you're going to make a major change, you might as well get fully up to date in the process.

To that end, have you thought about just calling up National Instruments and seeing what they have to offer? They specialize in exactly this type of product. They have a wide variety of data acquisition hardware and software, and they support a wide variety of operating systems and programming languages. It's possible they may even make a turnkey solution that already does what you need to do or can be programmed to do it easily.

... is National Instruments' LabVIEW. Amazing stuff.