Slashdot Mirror

>> The down side to this tack is that someone must go through the time consuming task of manually writing the chip in a Hardware Design Language such as VHDL or Verilog.

That's why there are products such as LabVIEW FPGA. Nothing says that something like that couldn't be done for supercomputing, as it is now done for data acquisition.

Interestingly, LabVIEW was first available only on the Mac (in circa 1986 even!) and still is available for various Unixes as well as OS X and Windows. It's an interesting object-oriented programming "alternative reality" compared to C++ and Objective C.

Machine vision systems spring to mind, such as:
http://digital.ni.com/worldwide/bwcontent.nsf/all/ 725E25B100E5BDEF86256F4400013228?opendocument
and with that sort of (image) data rate 16GB RAM is only a small buffer. Just a guess.

Looks like you're looking for something like LabVIEW
. I've done some pretty powerful stuff with it, including interacting with physical hardware (Like LEGO Mindstorms!), but I find it a PITA to do so much work with a mouse. I'd rather just code it. You may think it's a good idea, but when you end up with screens of interconnects and flowcharts that look like something straight out of a consultant's head, you may change your tune.

How about graphical programming languages (GPLs) like LabVIEW which I believe was decended from a language called G.

And then there is the whole class of functional programming languages like FP and ML and their various derivates.

Another language I didn't spot was SAS , a high-level statistical programming language used by auditors and banks a few years back.

Not to mention anything about more hardware related languages like VHDL.

I'll stop now, before my background starts showing too much.

I suppose one could produce a graphical version of a current programming language, but that would be very complicated and slow to use.

Take a look at LabView at some point

While it is primarily aimed at test and measurement applications, anything that can be done in a general purpose programming language can be done in LabView.

but that would be very complicated

It's not overly complicated. In some ways, it is significantly less complicated that text-based languages. For example, if you have a function (VI is labview terminology) that is blocked, it will automatically run other code that does not depend on the output from the blocked function. I don't have to think about threading or setting up a polling loop since it is handled automatically. Also, things like 'Do I need to make a copy of this data?' are handled by the compiler rather than being explicitly specified by the programmer.

and slow to use

With regard to speed, I have a couple of reasonably complex LabView programs that are running on PII's in the 300MHz range with no issues at all. Labview complies to machine code, so there is no issue of interpreting the graphical language at run-time. If you can figure out how to write something like this that creates large applications like Firefox, Word, or Visual Studio, you'd stand to make a fortune.

Well, at a previous employer, we had a LabView application that queried data from a SQL database based on user-specified criteria, pulled statistical data from the results and wrote it into a report, and the created an excel spreadsheet from the queried data. I'm not sure that LabView is the best language for that sort of thing, but it will work.

As far as the fortune bit, at $2000+ for the development environment, I imagine that NI makes a tidy profit off of LabView. Add to that hardware sales for embedded systems and real-time controllers capable of running LabView programs and I have to think that 'fortune' is probably a good description.

I suppose one could produce a graphical version of a current programming language, but that would be very complicated and slow to use.

Take a look at LabView at some point

While it is primarily aimed at test and measurement applications, anything that can be done in a general purpose programming language can be done in LabView.

but that would be very complicated

It's not overly complicated. In some ways, it is significantly less complicated that text-based languages. For example, if you have a function (VI is labview terminology) that is blocked, it will automatically run other code that does not depend on the output from the blocked function. I don't have to think about threading or setting up a polling loop since it is handled automatically. Also, things like 'Do I need to make a copy of this data?' are handled by the compiler rather than being explicitly specified by the programmer.

and slow to use

With regard to speed, I have a couple of reasonably complex LabView programs that are running on PII's in the 300MHz range with no issues at all. Labview complies to machine code, so there is no issue of interpreting the graphical language at run-time. If you can figure out how to write something like this that creates large applications like Firefox, Word, or Visual Studio, you'd stand to make a fortune.

Well, at a previous employer, we had a LabView application that queried data from a SQL database based on user-specified criteria, pulled statistical data from the results and wrote it into a report, and the created an excel spreadsheet from the queried data. I'm not sure that LabView is the best language for that sort of thing, but it will work.

As far as the fortune bit, at $2000+ for the development environment, I imagine that NI makes a tidy profit off of LabView. Add to that hardware sales for embedded systems and real-time controllers capable of running LabView programs and I have to think that 'fortune' is probably a good description.

I suppose one could produce a graphical version of a current programming language, but that would be very complicated and slow to use.

Take a look at LabView at some point

While it is primarily aimed at test and measurement applications, anything that can be done in a general purpose programming language can be done in LabView.

but that would be very complicated

It's not overly complicated. In some ways, it is significantly less complicated that text-based languages. For example, if you have a function (VI is labview terminology) that is blocked, it will automatically run other code that does not depend on the output from the blocked function. I don't have to think about threading or setting up a polling loop since it is handled automatically. Also, things like 'Do I need to make a copy of this data?' are handled by the compiler rather than being explicitly specified by the programmer.

and slow to use

With regard to speed, I have a couple of reasonably complex LabView programs that are running on PII's in the 300MHz range with no issues at all. Labview complies to machine code, so there is no issue of interpreting the graphical language at run-time. If you can figure out how to write something like this that creates large applications like Firefox, Word, or Visual Studio, you'd stand to make a fortune.

Well, at a previous employer, we had a LabView application that queried data from a SQL database based on user-specified criteria, pulled statistical data from the results and wrote it into a report, and the created an excel spreadsheet from the queried data. I'm not sure that LabView is the best language for that sort of thing, but it will work.

As far as the fortune bit, at $2000+ for the development environment, I imagine that NI makes a tidy profit off of LabView. Add to that hardware sales for embedded systems and real-time controllers capable of running LabView programs and I have to think that 'fortune' is probably a good description.

It's a little-known fact that LabVIEW has something like a 90+% marketshare in the realm of, well, I'm not sure what you'd call it: Engineering/Scientific-ish data gathering - the kinds of things that Engineers and "Scientists" do in their laboratories and out on the assembly line floor.

Anyway, if you search at monster.com, you'll see that there are often more hits on "LabVIEW" than there are on "MCSD" [Microsoft Certified Solutions Developer]:

http://jobsearch.monster.com/jobsearch.asp?q=mcsd

http://jobsearch.monster.com/jobsearch.asp?q=labvi ew

Also, it's another little-known fact that National Instruments offers certifications in LabVIEW, so that you can earn yourself a little "diploma" which might open a few more doors:

http://sine.ni.com/apps/we/nioc.vp?cid=10638&lang= US

Try lots of shit and see what works :)

Or does anyone have any experience with any other methods of moving large amounts of [strongly-typed] data across the wire so that it comes to rest in a central repository in some sort of a coherent fashion?

Thanks!

Some years ago, I was doing some work on a laser rangefinder, and got to the point where I needed about $20K in test gear to find out why it wasn't working right. Something like this would have been a big help.

Radio hams will find uses for this. It should be great for working on new data transmission schemes for high-noise links, like HF.

LabView support would be nice.

I remember around 1997 some LabVIEW reps from National Instruments came in to our lab. They were showing a new version of their product. I asked when they'd have a Linux version... [blank stare] and one finally said something to the effect: It isn't cost effective to make a Linux version because no one will use it.

Well, look at what we have from National Instruments today: http://www.ni.com/linux/lin_lv.htm/

Never say never

http://www.ni.com/company/robolab.htm/ http://www.lego.com/eng/service/faqs.asp?section=C onsumerService-FAQ-TechSupport&catid=1E65DEDE-9A63 -4C69-9FE2-445BF90ABEC1&faqid=3280&tech=tr ue/ It usues LabVIEW instead though which for children I would think is a lot easier

You do realize that MatLab runs in Linux if you're willing to licence it, which it seems you are under windows...

Anyway, a quick freshmeat search showed me that Nulab, Yorick, Scilab, FrAid and Lush are all possible replacements, depending on the application. Moreover, many of those refer to Octave which might be suitable, depending on your needs.

Likewise National Instruments makes LabVIEW for Linux, and freshmeat says to look at Flow Designer and TACO as potential free replacements.

If the two are used for related purposes, then consider RobotFlow which came as a result under both searches...

Just in case you decide to retry the system at a later date...

Dynamic languages the future? Unlikely. The future of programming is more likely in code that isn't written, but rather "drawn"

Many people haven't heard of LabView, even though it has been around since the late 80s. It runs on Windows, Mac OS, and Linux. The premise behind LabView is there is no such thing as written code. Instead of code, applications are literally drawn by dragging variables (controls, indicators) onto the block diagram and wiring them together. For instance, if I wanted to add 1 and 2, I would create two integer objects with respective values, find the addition function, and wire them together to an output (indicator - think text box). I have written entire graphical application suites/analysis tools in a matter of days and weeks instead of months (had I written them in, say, C or Java or $your_texT_based_language_of_choice).

The only issue many will have with LabView is that it is expensive. It is also closed source, but hey, so is Java. Anyone interested in rapid application prototyping/development or digital/analog instrumentation should check out LabView.

anybody who's used the labview scientific test, measurement&recording and control software package can see how this will work just like LV in hardware; all you'll have to do will be pick your modules, wire them together and voila, a totally custom hardware solution. cool.

As a CS grad, I have to say that I love LabVIEW. It's certainly not perfect, but it allows me to create true parallel looping faster than any text-based language can do.

I have done my share of C/C++ programming and it has it's merits, but I prefer LabVIEW. The last couple of projects I used it for at work didn't even involve hardware. I just used it like VB.

I think it would be a good learning tool for beginning programmers to learn about different data structures. You can run a VI in "highlight execution" mode which uses animation on the wiring diagram side to show the order of execution. Great for troubleshooting.

the debate textual and graphical programming will rage on, but I don't think it will really matter in the future - as long as it all compiles down to machine code.

NI has a great article about how the compiler works.

There is Agilent VEE (now obsolete) and to a lesser extent, LabVIEW from National Instruments.

I had a job where I did work in VEE and there were a few disadvantages to using it than functional or even object-oriented programming. For one thing, code wasn't as tight as it would have been with text-based programming. I always felt I could get code to work the way I wanted it to when it was another programming language. Another issue is that since VEE is an interpreted language, it's very, very slow to execute compared to an equivalent programming language. Third, the timing issues were horrible if you decided to make your code execute multiple "threads" at the same time, which was more like how Windows 3.1 did its multitasking.

However, VEE was easy enough to use that any old engineer could program in it, even those with little or no coding experience. Technicans could also troubleshoot the code if it was documented well enough. Also, nothing could beat it in terms of cranking out a prototype electrical test when you need to get data quickly.

Similar things have already been done. See LabView... Programs are laid out in a manner similar to electronic schematics... It works well for building software used in engineering and scientifc environments

True; I was just playing with the idea. For sampling at DC you would have to use direct-coupled inputs, no capacitors in the signal path. I imagine it wouldn't be all that hard to apply some RF techniques and "beat" the signals together beforehand in order to get something useful. Or just use a v->f converter. Anyway, I posted the National Instruments link for those reasons, if you need pro grade stuff that already works.

Why couldn't I just use my soundcard line inputs? Not trying to be an asshat here, just reminding people that modems and soundcards basically *are* A/D devices. If you have the $$$ to spend, you can find A/D cards here, they supply pro stuff. Yeah, I'd like to try this under Linux, but I need to ask: does anyone know a good way to re-code the VB into C/C++? This is not the kind of project I normally consider, but its just too damn interesting. Thanks.

64 way systems are the definition of vendor lock-in. You're only going to be running qualified hardware on something like that, and paying real $$ for support. And Linux? That is more of a marketing ploy than anything. If you aren't running HP/UX on that machine, you need your head examined. HP/UX is going to have pretty much all of the commercial applications for hardware like that and much better support.

As far as Penguin's offerings for clustering, maybe they are meaningfully better than Apple's offerings, although I'm not sure how.

"Funky" hardware eh? I'm curious as to what generally useful stuff you can't get on the Mac. You mean stuff like GPIB controllers, or maybe Myrinet, or maybe even more obscure? Frankly, if its funky, that pretty well implies specialized. I think it would be foolish to let the availability of some obscure, special purpose widget for limited use influence my choice for a common server or desktop platform.

Current Mac systems combine the power of Unix with the only platform even hinting at rivaling Windows for standard productivity applications, including MS Office.

If you're searching for a company that does customer support RIGHT, look into National Instruments. They realize that encouraging customer success is paramount to a successful business.

Give your kids a National Instruments - Lego RoboLab kit!

Dispite what the people who came to your school may have told you, NI does have some Linux support. For instance: There is a "driver developement kit", where you can get register level programming information, it provides source code for a plattform independent driver layer and a lower "bus-level" layer, which is available for Linux as well: That should be contain enough information for writing a free software driver (e.g., for comedi). They also have a (somewhat dated) web page which summarizes some of their Linux activities: http://www.ni.com/linux. For instance, there is a Labview version for Linux. I very much suspect that the technical people at NI (just like anywhere) appreciate what Linux can do, their road show/sales people have a different agenda, though. They try to keep the lid on customer wishes, so that they don't have more work honoring them.

...as does IGOR, which someone else mentioned:

LabVIEW

IGOR

For those of you familiar with the LabVIEW programming language for National Instruments, you know that the LabVIEW code is called "G". There's a funny song called "Write in G" that is very similar to the aforementioned song. There's an audio version here.

NI added undo to LabVIEW in the 5.0 release (ca. 1997) of the product. It was really funny how the marketing from NI revolved around that feature. "Now with UNDO!" You would think that promoting the introduction of a feature that is so ubiquitous in most other desktop software would be less than effective--that people would groan because they had expected it for so long. However, at one of their trade shows, the presenter mentioned the new UNDO and got a standing ovation.

NI added undo to LabVIEW in the 5.0 release (ca. 1997) of the product. It was really funny how the marketing from NI revolved around that feature. "Now with UNDO!" You would think that promoting the introduction of a feature that is so ubiquitous in most other desktop software would be less than effective--that people would groan because they had expected it for so long. However, at one of their trade shows, the presenter mentioned the new UNDO and got a standing ovation.

drag and drop elements, then connect them up with lines

National Insturments also provides drivers for most of their hardware for Linux as well.

National Insturments also provides drivers for most of their hardware for Linux as well.

Based on this lkml thread it sounds like you are against binary only kernel modules (e.g. the National Instruments GPIB driver). What is your stance on the legality, morality, and practicality of binary only kernel modules? Specifically, is a binary only kernel module a violation of the GPL or DMCA, and if so, why? Isn't a binary kernel module driver better than no driver at all?

Although it's an ANSI C IDE, I highly recommend National Instruments LabWindows/CVI from the people who brought us LabVIEW. LW/CVI is my preferred IDE; drag-and-drop GUI design, excellent debugging tools, a full-featured API to cover everything from event handling to SQL to advanced data analysis, excellent documentation, excellent online and phone support, excellent training seminars around the country, and portable across Windows (even 3.1), Mac, Sun/HPUX, Sun Solaris, HP-UX, and Linux. Don't overlook this product for its automated test applications, it is very capable of applications of any kind.

I used to program in C++ but wound up reverting back to ANSI C years ago, the aggravations were not worth the gains. Especially after digging deep enough into MFC code only to find the old ANSI C Windows API calls underneath all that bloat!!!

I would have to agree with Zero__Kelvin-- no sound card is going to give any kind of decent signal. If you need an oscilliscope, you'd be doing yourself a disfavor by trying to use the horrible, bandwidth limited DSP in your soundcard. At the very least get a dedicated card by National Instruments or a used Tektronix/Wavetek/HP/whatever Oscope off of eBay for cheap. An analog scope will give you better resolution anyhow, and you'll thank yourself in the longrun.

I too have used National Instrument's LabVIEW and I recommend it as well. Compared to the $5k benchtop oscopes this is inexpensive, and you'll get great results. You can get away with somewhere under $1k maybe even around $500 for a good DAQ card and some software. Their software is awesome and easy to use. LabVIEW contains a graphical programming language that makes working with complex stuff as easy as drag and drop. Serial, TCP/IP, almost anthing is simple as pie. Hell, I believe they even include a sample oscope app somewhere (either online or with LabVIEW software). If you can get the educational price you are in for some cost savings as well. Definitely the way to go for precise measurements. They have products you can plug into your PCI slot that run the gamut from low end more affordable systems to the high end. I used their stuff in school alot and I love it.

JOhn

I took an electronics class were we had to build and program a oscilliscope for one of the beginning prohjects. We had a generic DAQ and the api for C(dos) or VB(win). The prof only new VB so we were limited to that. The drivers and API for VB was pretty good, however it was quite slow when propagating sample rate changes and the like. However, it worked. If you are interested in the source code it is here(warning - it is VB and it is a quick hack). We were able to use it to "record" from a microphone and then "playback" the waveform we recorded. It was pretty cool.

really you should be able to use any analog-to-digital acquisition device. A sound card would work great. Program it using the sound cards low level API. Basically write a driver/program that parse hthe wave info and spits it out to the screen rather than the speaker. heh.

For probes, use a mic plug hooked to a male banana clip. that should allow you to use any breadboard/probe.

heh.

1ms is the way-way-way upper end of what could be considered realtime. You don't need an RTOS to do this - a USER mode application in Windows can respond that about that fast. The only problem is that it's not garuanteed like it is with RTOSes. Don't go surfing the web or defragment the harddrive and you'll be ok. (yes the default sleep time ranges from 10-16 milliseconds or so, you can change that with a call to timeBeginPeriod and set it to 1ms) National Instruments is the company you want to contact to work out the details of what you require. IOmega is another alternative if NI doesn't have a product that meets your needs (if NI has it, but it from them - even if it's more money!) NI They make a product called LabView which could work well for you.

They might as well do it right.. There's an article on the National Instruments page (it's a customer application of they're using to promote their product) about the Redwood City Police, using a network fo microphones to to sense and triangulate the location of gun fire in the city.. the Link is here

If we're going to have cameras installed in the cities, then they should be linked to accoustic, air velocity, air chemistry, and IR sensors. Give each camera enough memory to buffer 15 seconds of video (~450 images), and use the combined sensory infomation to monitor the urban areas for gun shots, chemical agents, and fires.. When any of these sensors are triggered, extra-sensory information can be used to triangulate the area of interest, and the video from those cameras can be then be studied..

Of course this is also has the benefit of providing on-line SMOG, and traffic monitoring..

... In a camera mounted in a lamp post?

I don't think so!! Six degrees of freedom would mean x,y,z translation, and roll, pitch and yaw moments.. If you've got a camera in each lamp post, you don't need any of the translation degrees. You just need to stitch the images (acquired simultaneously) together from each camera, and then pass them to a QuickTime VR viewer so the operator could float around the scene.. Hint: imagine shots such as those in the Matrix..

I'd give bonus points to anyone who links a system like the one described above to a real time set-up like the Redwood, CA police department is using to remotely monitor for gunshots in high crime areas.

Run time licenses are free, and there are thousands of drivers for different types of hardware, some of which would be useful for this wireless data acquisition application. Of course, the FieldPoint system that another NI employee mentioned above is designed to be controlled easily with LabVIEW.

Finally, though LabVIEW is primarily used on the Win32 platform, most of its features are available on other OSes, including Linux.

Run time licenses are free, and there are thousands of drivers for different types of hardware, some of which would be useful for this wireless data acquisition application. Of course, the FieldPoint system that another NI employee mentioned above is designed to be controlled easily with LabVIEW.

Finally, though LabVIEW is primarily used on the Win32 platform, most of its features are available on other OSes, including Linux.

Run time licenses are free, and there are thousands of drivers for different types of hardware, some of which would be useful for this wireless data acquisition application. Of course, the FieldPoint system that another NI employee mentioned above is designed to be controlled easily with LabVIEW.

Finally, though LabVIEW is primarily used on the Win32 platform, most of its features are available on other OSes, including Linux.

In fact, there is a package called LabView which is extensible and many data collectors provide modules to LabView with their sensors. LabView is predominantly a Windows product, but don't let some folk's bias get in the way of work. [Note: I'm not a Windows fan, but will use it when required or if it's the right tool for the job, which it is for things like data collection.]

I cannot attest to cost, but merely to the fact that advertising in TechBriefs has even stuck with someone who has no interest in scientific data collection, like myself. Cheers. ----- Want intelligence? Go to Stratfor.com. If it's in the news, it's too late.

Try National Instruments FieldPoint system. It's a rugged distributed I/O system with wireless, serial, ethernet and Fieldbus options.
Look at the Fieldpoint section on NI's site

Yeap, you guessed it, I work for National Instruments :-)

Seriously though, there are some very interesting options with the NI gear.

BTW, LabVIEW 6.0 was just released this week, and it has been available for Linux since 5.0. See http://www.ni.com/linux.

I program in LabVIEW almost exclusively for my job, though I still prefer text-based languages.

What, you mean like LabView ? It's a graphical programming language - mainly intended for controlling lab equipment, but surprisingly general purpose.

Edric.

Take a look at LabView's G language. Its a completely GUI based language. While the compiler is $3000 there is a student version that is nearly fully functional available for ~$80. The latest version even has several internet protocols builtin. Plus it has an excellent math library and data analysis package that would do very well for any science classes they take.

Take a look at LabView's G language. Its a completely GUI based language. While the compiler is $3000 there is a student version that is nearly fully functional available for ~$80. The latest version even has several internet protocols builtin. Plus it has an excellent math library and data analysis package that would do very well for any science classes they take.