Slashdot Mirror

Yeah, and if it were the North Koreans or Cubans or some other third world Stalinist hellhole's spooks doing it, they may well have done it in an incompetent way that caused health problems due to them effectively microwaving the embassy people on too high a power.

If it was a competent country they'd have figured out how to do it in an undetectable way - e.g. spread spectrum signals near the noise floor

http://www.ni.com/white-paper/...

The rapid phase transition (chip rate Tc) signal has a larger bandwidth given that the rate is greater Rc (without changing the power of the original signal) and behaves similar to noise in such a way that their spectrums are similar for bandwidth in scope. In fact, the power density amplitude of the spread spectrum output signal is similar to the noise floor. The signal is âoehiddenâ under the noise

You mean HP...err Agilent...err Keysight VEE (Visual Engineering Environment)? I used HP VEE and National Instruments LabVIEW 25 years ago and I agree. They are very flowchart oriented. I'm not sure what the actual question is. While both of these are geared toward instrumentation control they are very versatile.

It appears to be a case of dithering used to reduce quantization errors

Another application I've seen in National Instruments analog IO boards and presumably many others places is to effectively turn a lower resolution ADC into a higher resolution one by adding noise prior to the measurement and sampling faster. You have to do some math to effectively get a higher precision waveform at a lower rate. At any rate, here is a link for the curious. dithering

Of course programmers are going to say LabView is a horrible language because it's a GRAPHICAL programming environment. Its entire purpose for being is to allow scientists and engineers to quickly piece together a control environment for scientific/SCADA type equipment without knowing how to code. All scientists/engineers should be able to do logic and flow charts and as the OP pointed out that's where these "languages" shine. If you need more robust code LabView works with C libraries just fine. I wouldn't want to do a purely software related project with LabView but if I need to trigger an oscilloscope when a certain anomaly occurs and send that data to a function generator it's a lot easier than writing a C program.

LabVIEW has been around since 1986. http://www.ni.com/labview/

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

Here's the programming manual for FIRST robotics competitions. This is not dumbed down.

There was never a chance of giving away the meters to an NPO, trade school, or public school. The hardware would inevitably be as suspect as the look-alike case. I am not convinced that there is a place for the $15 multimeter even in the makerbot movement.

Any shorthand description of Fluke and its product lines will read like corporate PR. but that can't be helped.

Fluke, a subsidiary of Danaher (maker of Craftsman tools), makes handheld electronic test tools used by electricians, HVAC technicians, and engineers to install, maintain, and service electrical and electronic equipment. Its multimeters, oscilloscopes, and other devices measure current, voltage resistance, frequency, pressure, temperature, and air quality. It also makes calibrators and calibration software, waveform generators, and power harmonics meters. Its Fluke Biomedical unit makes patient simulators, diagnostic imaging, and radiation safety products, among others.

Fluke Corporation Company Profile

The cheapest Fluke multimeter I could find online sells for about $150 and is CAT III rated for 600 volts.

This category refers to measurements on hard-wired equipment in fixed installations, distribution boards, and circuit breakers. Other examples are wiring, including cables, bus bars, junction boxes, switches, socket outlets in the fixed installation, and stationary motors with permanent connections to fixed installations.

What are Measurement Categories (CAT I, CAT II, etc...)?

I know several smart people who can code in text based languages but, for some weird reason, decide they have to use LabVIEW for data acquisition.

Part of that may be because they are using National Instruments' data acquisition hardware, and naturally LabView plays nicely with it. NI offers other options, such as LabWindows/CVI (which is C-based) and Measurement Studio which are essentially a bunch of libraries for Visual Studio that support NI's hardware and add some UI widgets (like plotting). Certainly worth looking into if you want to use NI's hardware but would prefer to not use LabView.

I know several smart people who can code in text based languages but, for some weird reason, decide they have to use LabVIEW for data acquisition.

Part of that may be because they are using National Instruments' data acquisition hardware, and naturally LabView plays nicely with it. NI offers other options, such as LabWindows/CVI (which is C-based) and Measurement Studio which are essentially a bunch of libraries for Visual Studio that support NI's hardware and add some UI widgets (like plotting). Certainly worth looking into if you want to use NI's hardware but would prefer to not use LabView.

searching for the appropriate operations in a palette
which is why you use quick drop rather than looking through the pallets.

It's also hard to see where wires are connected to because they can be arbitrarily nudged around the terminals.
If you don't keep your code clean it doesn't matter if you're using a graphical or text based programming language. It's going to be hard to read either way.

x = 3*(sin(y)+4-length(q))
It's cases like those that you use a formula node.

• Hard to comment
• Very easy to write bad code (particularly for beginners)
• Version control is awkward
• Clunky to debug because programs are hard to follow.
• Hard to modify existing code
• Coding becomes an exercise in placing the mouse in just the right places and finding the right little block.
• As a beginner you waste lots of time trivialities instead of actually learning to code.
• Hard to learn from a book or even from reading somebody else's code.
• Documentation is crappy.

Graphical languages are still programming. Syntax errors don't go away, they just manifest themselves differently. I don't think graphical languages really solve any problems, they just create new ones. That's why they haven't caught on.

"Serial runs aren't that long.."

The link you gave is for RS-232. RS485/422, CAN and Profibus(a protocol running on variant of RS485) can run for hundreds or thousands of meters (using repeaters and/or optical links). They are also the most common form of fieldbus. Allen Bradley uses DeviceNet over CAN, Siemens uses Profibus and various other controller manufactures use RS422/485 and most likely run Modbus or a proprietary protocol over it.

http://en.wikipedia.org/wiki/RS-485": It offers data transmission speeds of 35 Mbit/s up to 10 m and 100 kbit/s at 1200 m."

http://en.wikipedia.org/wiki/Rs422: "The maximum cable length is 1500 m. Maximum data rates are 10 Mbit/s at 12 m or 100 kbit/s at 1200 m."

http://digital.ni.com/public.nsf/allkb/D5DD09186EBBFA128625795A000FC025: CAN Bus - 50 kbits/Sec @ 1000 meters.

http://en.wikipedia.org/wiki/Profibus: "The cable length between two repeaters is limited from 100 to 1200 m, depending on the bit rate used."

So, LabView with DLLs dressed up as SubVIs would be FBP?

National Instruments LabVIEW as graphical control-flow (e.g., looping, branching) constructs http://www.ni.com/white-paper/14556/en
+
ROOM+ObjecTime (now IBM Rational Rose Realtime) as graphical object-oriented & nested state-machines http://www.amazon.com/Real-Time-Object-Oriented-Modeling-Bran-Selic/dp/0471599174/ref=sr_1_fkmr1_1?s=books&ie=UTF8&qid=1379088665&sr=1-1-fkmr1&keywords=realtime+object+oriented+modeling+objectime

I wonder if the Large Hadron Collider took more than a week.

Tsk tsk, those lazy, unwilling-to-learn-anything CERN engineers.

For the more complex bits you should be coding it anyway.

I do a fair amount of home and work microprocessor/hardware dev. and every time I research I keep coming to the conclusion that the Arduino and it's expansion shields from the usual vendors are WAY OVERPRICED.

An Arduino and Ethernet shield costs more than a 2nd hand dual core PC box with windows licence.

The RasberyPI by comparison seems very well priced, though I haven't had need for one. The OP is correct, if he needs a screen , user input and portable nature a (2nd hand) cell phone (android) is a good basis. Since the USB OTG IO expansion costs as much as a budget (2nd hand) android cell phone again it is not a great deal.

I would suggest a TI Stelaris launchpad kit that has USB host / slave functionality for $13 (!)
http://www.ti.com/ww/en/launchpad/stellaris_head.html?DCMP=stellaris-launchpad&HQS=stellaris-launchpad
this little guy has "80MHz, 32-bit ARM Cortex-M4 CPU with floating point, 256Kbytes of 100,000 write-erase cycle FLASH and many peripherals such as 1MSPS ADCs, eight UARTs, four SPIs, four I2Cs, USB & up to 27 timers, some configurable up to 64-bits. "

Another item of interest for projects that I have developed is this Bluetooth to serial TTL for $9:
http://www.mdfly.com/index.php?main_page=product_info&products_id=63

For all most of my (PC based) projects to date I have gone with:
A) the (cheaper) MSP430 launchpad:
http://www.ti.com/tool/msp-exp430g2
B) Or for "medium" speed / quality analog I/O use a national instruments usb I/O card ($170): http://sine.ni.com/nips/cds/view/p/lang/en/nid/201986
C) And for something a bit faster use a Rigol Osc. starting at $300 with usb and Ethernet interfacing.

LabView for the Macintosh shipped in 1986, and not only still exists but has a very solid niche in some circles. LabView is such a pure visual IDE that there are not visible lines of code as such; it is all wiring diagrams.

My day job is writing LabVIEW for measurement and automation tasks... I'd chime in that LabVIEW does have text code now in the form of formula nodes and MathScript nodes (which uses Matlab). These are really useful for more complicated math expressions... the wiring gets pretty nasty as your math gets more complex.

Is this article about GIDE or IDE? VB was definitely not the first IDE. Hell it wasn't even the first GIDE. We were using National Instruments LabVIEW a couple of years before VB. Of course it was instrument control specific but ran on a MAC or a PC.

Have you ever used National Instruments Labview?

It's exactly what you're describing, and it works great.

Similarly, NI LabVIEW has the ability to embed program code in PNG screenshots. http://www.ni.com/white-paper/9330/en

I'm a software developer. My employer has ~5000 employees, and we easily do the majority of our hiring straight out of college.

Including right now, if anyone is looking: http://www.ni.com/careers/

http://www.ni.com/fpga/

d'you ever asked carpenter if he had experience with hammers? LabView is a hammer for all that do not need/want programming but need to orchestrate repeating measurements.

Tell that to Bruce Schneier.

G (why do people keep calling it "LabView"?) is more like a whole DAS/Process-Control multi-drawer rolling toolbox than a simple hammer.

Because G is no longer the name that National Instruments calls it?

While I agree that NI has recently de-emphasized the distinction between "G" and the entire LabView environment (my theory is because it was getting really hard to build search terms for a single letter (oh, how I have wished many times that K&R had called C something more distinctive when doing searches!), and because they got tired of answering stupid questions like "You mean "C", not "G", right?"), but the NI "community support" forums are still full of comments with "G-this" and "G-that" in them, even with new LabView programmers, and even in postings dated this year.

G is a name that NI has been using since 1986, and I may be wrong; but a quick look around on NI's site, doesn't seem to show any place where the term "G" is formally deprecated. It seems more like they are just quietly not talking specifically about "G" anymore as separate from "LabView" itself. Considering the fact that G is proprietary and I believe specific to the LabView platform, it was probably a wise marketing decision overall.

There are also, IIRC, trademark problems with single-letter and numerical names (remember how the 586 became the "Pentium" for that very reason?). So, that may also be an important reason (at least to NI), to stop using the term in marketing literature and documentation.

Twenty years from now, there probably won't be many LabView developers that have more than a passing knowledge of the term "G". But as of now, that most certainly doesn't seem to be the case, at least outside of NI's marketing and documentation departments.

Also, Wikipedia still lists "G" as the underlying language for LabView right in the second paragraph (and throughout the article), with no discussion of the name being dropped or changed. The name is also an important part of the OpenG project (Note that it is not called "OpenLabView". I'm sure if you post your idiotic comment there you'd be branded as a noob, or worse...

And, most importantly, even NI's online help system lists "G" simply as the "Graphical programming language LabVIEW uses", with no discussion of the name being deprecated or changed or dropped.

So, let's just agree that the term "G" is being slowly worked out of the LabView ecosystem; but especially with experienced G developers, the term will still be used to distinguish the language from the platform for a long time to come.

G (why do people keep calling it "LabView"?) is more like a whole DAS/Process-Control multi-drawer rolling toolbox than a simple hammer.

Because G is no longer the name that National Instruments calls it?

While I agree that NI has recently de-emphasized the distinction between "G" and the entire LabView environment (my theory is because it was getting really hard to build search terms for a single letter (oh, how I have wished many times that K&R had called C something more distinctive when doing searches!), and because they got tired of answering stupid questions like "You mean "C", not "G", right?"), but the NI "community support" forums are still full of comments with "G-this" and "G-that" in them, even with new LabView programmers, and even in postings dated this year.

G is a name that NI has been using since 1986, and I may be wrong; but a quick look around on NI's site, doesn't seem to show any place where the term "G" is formally deprecated. It seems more like they are just quietly not talking specifically about "G" anymore as separate from "LabView" itself. Considering the fact that G is proprietary and I believe specific to the LabView platform, it was probably a wise marketing decision overall.

There are also, IIRC, trademark problems with single-letter and numerical names (remember how the 586 became the "Pentium" for that very reason?). So, that may also be an important reason (at least to NI), to stop using the term in marketing literature and documentation.

Twenty years from now, there probably won't be many LabView developers that have more than a passing knowledge of the term "G". But as of now, that most certainly doesn't seem to be the case, at least outside of NI's marketing and documentation departments.

Also, Wikipedia still lists "G" as the underlying language for LabView right in the second paragraph (and throughout the article), with no discussion of the name being dropped or changed. The name is also an important part of the OpenG project (Note that it is not called "OpenLabView". I'm sure if you post your idiotic comment there you'd be branded as a noob, or worse...

And, most importantly, even NI's online help system lists "G" simply as the "Graphical programming language LabVIEW uses", with no discussion of the name being deprecated or changed or dropped.

So, let's just agree that the term "G" is being slowly worked out of the LabView ecosystem; but especially with experienced G developers, the term will still be used to distinguish the language from the platform for a long time to come.

G (why do people keep calling it "LabView"?) is more like a whole DAS/Process-Control multi-drawer rolling toolbox than a simple hammer.

Because G is no longer the name that National Instruments calls it?

In fact work at a lab, and I say this was a major missed opportunity...

What they should've said is:

" Listen, your whole system is flawed and full of holes like a tennis racket made of swiss cheese.

For a start immediately buy our university department the following:

- One of each on their catalog...

- And their...

- And their...

...that should cost you only 50-100 million (you might get a discount). Budget it as a long term investment into transaction systems."

At least such a scenario is a recurring dream of mine. Oh well, back to the grind ... calibrating old Tektronix oscilloscopes...

Not only that but I was initially excited when I saw the words "Linux Radio" and thought that someone had finally made some interesting ham-radio stuff for Linux...

like for example a software defined radio - preferably could handle raw IQ via multiple channels on open sound cards with AD-DA upto 192 bps ... for a start

or that someone had finally made an open implementation of STANAG 5066 ...

and what about open mobile base stations?

or write some open FPGA code to to get wider bands of actual RF and electrically tuning steering the antenna array...

trouble is nice development hardware is expensive ...

Anyone got an extra 100,000 USD for a fun open radio project?

Listen, you Labview fan boy, I am not smoking crack. (Although I will admit it: Labview makes me wish I was a toothless meth addict, hitting rock bottom, giving blowjobs to married, middle-aged closeted gay men in a movie theater for drug money.)

I spent more than 10 minutes learning that crap. More than a few weeks in fact. I got to know some Labview tech support "engineers" by name. The problem, I later realized, was that I knew exactly what I wanted the hardware to do, except I had to jump through all kinds of Labview hoops to get there. In C or C++, I could have had the majority of the hard parts done in a few days, and then polish up the details. Not so in Labview.

Ever try to force yourself to do something the hard way, when you know there is a much easier way to do it? Ever try to pee sitting down when you're a few pints in, and you really have to go? That's what working with Labview is like -- it will block your peehole until you are calmly sitting on the toilet like a good boy. If you are a girl it will make you pee standing up through one of those cardboard funnels.

Let's look at what you'd have to spend to get a hardware and software package that lets you look at signals at 10MHz.

Here is the "Buy Labview" (a.k.a. get raped in the ass with a cactus branch) web page:

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

I could go with Labview Base or Labview Full, but since I want to deploy stuff to customers' machines without forcing them to buy Labview, I'm going to go with Labview Professional for US$4299, although I should probably go for NI Developer Suite for US$4699 because it's the "best value."

Next, I want to sample at 10MHz or greater. In 5 minutes of searching, these are the only products that I could find, that will let me do that. Note that these both have a maximum rate of 10MHz; there don't seem to be NI products that can go higher.

• PXI-6115 for US$4199, or if we go with the "NI recommended" version, US$5249
• PCI-6115 which is just the PCI bus version of the PXI-6115, for US$3799, or US$4849 for the "NI recommended" version

If you go with the PCI version, you will need a PC with some pretty good horsepower to handle the 10MHz data stream. This may add an extra $1000 or $2000 to your total price.

If you go with the PXI version, then bend over and grab your ankles again, for into your bleeding rectum NI shall happily insert a well-lubricated PXI chassis of your choice, for an additional few thousands of $$$.

Add in all taxes and other costs (shipping, and oh yeah, $600 cables, anybody??) and it's pretty damn near $10k if not well above. Just for the privilege of writing multi-colored spaghetti code in order to make your measurements.

In conclusion, it is better to just get a real 60MHz digital scope for a few grand. Labview treats intelligent humans like dogs.

Listen, you Labview fan boy, I am not smoking crack. (Although I will admit it: Labview makes me wish I was a toothless meth addict, hitting rock bottom, giving blowjobs to married, middle-aged closeted gay men in a movie theater for drug money.)

I spent more than 10 minutes learning that crap. More than a few weeks in fact. I got to know some Labview tech support "engineers" by name. The problem, I later realized, was that I knew exactly what I wanted the hardware to do, except I had to jump through all kinds of Labview hoops to get there. In C or C++, I could have had the majority of the hard parts done in a few days, and then polish up the details. Not so in Labview.

Ever try to force yourself to do something the hard way, when you know there is a much easier way to do it? Ever try to pee sitting down when you're a few pints in, and you really have to go? That's what working with Labview is like -- it will block your peehole until you are calmly sitting on the toilet like a good boy. If you are a girl it will make you pee standing up through one of those cardboard funnels.

Let's look at what you'd have to spend to get a hardware and software package that lets you look at signals at 10MHz.

Here is the "Buy Labview" (a.k.a. get raped in the ass with a cactus branch) web page:

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

I could go with Labview Base or Labview Full, but since I want to deploy stuff to customers' machines without forcing them to buy Labview, I'm going to go with Labview Professional for US$4299, although I should probably go for NI Developer Suite for US$4699 because it's the "best value."

Next, I want to sample at 10MHz or greater. In 5 minutes of searching, these are the only products that I could find, that will let me do that. Note that these both have a maximum rate of 10MHz; there don't seem to be NI products that can go higher.

• PXI-6115 for US$4199, or if we go with the "NI recommended" version, US$5249
• PCI-6115 which is just the PCI bus version of the PXI-6115, for US$3799, or US$4849 for the "NI recommended" version

If you go with the PCI version, you will need a PC with some pretty good horsepower to handle the 10MHz data stream. This may add an extra $1000 or $2000 to your total price.

If you go with the PXI version, then bend over and grab your ankles again, for into your bleeding rectum NI shall happily insert a well-lubricated PXI chassis of your choice, for an additional few thousands of $$$.

Add in all taxes and other costs (shipping, and oh yeah, $600 cables, anybody??) and it's pretty damn near $10k if not well above. Just for the privilege of writing multi-colored spaghetti code in order to make your measurements.

In conclusion, it is better to just get a real 60MHz digital scope for a few grand. Labview treats intelligent humans like dogs.

Listen, you Labview fan boy, I am not smoking crack. (Although I will admit it: Labview makes me wish I was a toothless meth addict, hitting rock bottom, giving blowjobs to married, middle-aged closeted gay men in a movie theater for drug money.)

I spent more than 10 minutes learning that crap. More than a few weeks in fact. I got to know some Labview tech support "engineers" by name. The problem, I later realized, was that I knew exactly what I wanted the hardware to do, except I had to jump through all kinds of Labview hoops to get there. In C or C++, I could have had the majority of the hard parts done in a few days, and then polish up the details. Not so in Labview.

Ever try to force yourself to do something the hard way, when you know there is a much easier way to do it? Ever try to pee sitting down when you're a few pints in, and you really have to go? That's what working with Labview is like -- it will block your peehole until you are calmly sitting on the toilet like a good boy. If you are a girl it will make you pee standing up through one of those cardboard funnels.

Let's look at what you'd have to spend to get a hardware and software package that lets you look at signals at 10MHz.

Here is the "Buy Labview" (a.k.a. get raped in the ass with a cactus branch) web page:

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

I could go with Labview Base or Labview Full, but since I want to deploy stuff to customers' machines without forcing them to buy Labview, I'm going to go with Labview Professional for US$4299, although I should probably go for NI Developer Suite for US$4699 because it's the "best value."

Next, I want to sample at 10MHz or greater. In 5 minutes of searching, these are the only products that I could find, that will let me do that. Note that these both have a maximum rate of 10MHz; there don't seem to be NI products that can go higher.

• PXI-6115 for US$4199, or if we go with the "NI recommended" version, US$5249
• PCI-6115 which is just the PCI bus version of the PXI-6115, for US$3799, or US$4849 for the "NI recommended" version

If you go with the PCI version, you will need a PC with some pretty good horsepower to handle the 10MHz data stream. This may add an extra $1000 or $2000 to your total price.

If you go with the PXI version, then bend over and grab your ankles again, for into your bleeding rectum NI shall happily insert a well-lubricated PXI chassis of your choice, for an additional few thousands of $$$.

Add in all taxes and other costs (shipping, and oh yeah, $600 cables, anybody??) and it's pretty damn near $10k if not well above. Just for the privilege of writing multi-colored spaghetti code in order to make your measurements.

In conclusion, it is better to just get a real 60MHz digital scope for a few grand. Labview treats intelligent humans like dogs.

National Instruments makes a series of nice data acquisition cards in PCI, PCIe and USB form factors. For ~$2k you can get a board with 16-bit resolution, 1.25 MS/s (split between input channels), 2-4 analog outputs (16-bit, 2.86 MS/s), 24-48 1 MHz DIOs. The DAQ drivers are pretty well documented and easy to pull into custom code plus includes basic display and data-logging software in the form of LabVIEW SignalExpress. The main reason to go for one of these over a faster sampling O-scope is the output ports and potential for device control and testing using one piece of hardware if that's something you'd be interested in.

Of course, the INI files are under either ProgramData or Users where they belong - not under Program Files.

You can say they "belong" wherever, and maybe they do, but if an application that was built in the Win98 era that would otherwise have run perfectly on Vista/Win7 fails because of a misguided attempt to turn Windows into a strict multiuser OS, that's more the OS vendor's fault than the app developer's.

The problem happens when one executable, like a hardware configuration program, writes to an .INI file that other apps in the same directory are expected to be able to read. A virtualized copy of the .INI file is written under \Users\username\AppData\Local\VirtualStore\Program Files\[application name]\whatever.ini. The mistake Microsoft made was including [application name] in that path, because it means that an .INI file written by one .exe won't be accessible to another .exe in the same software package. This was an extremely common practice at one time, especially among developers (such as myself) who never drunk the Registry kool-aid.

Since .INI files are not executable and have thus been responsible for precisely zero OS exploits, it can be concluded that this was just a case of Microsoft fixing something that wasn't broken. This particular change sounds obscure and trivial, but it broke a large number of legacy apps for no good reason.

"A National Instruments PCI-6014 data acquisition card triggers radar pulses and digitizes the video data". http://sine.ni.com/nips/cds/view/p/lang/en/nid/11442 With a $700 (not counting accessories) data acquisition card.

That was my first thought as well. I programmed in HP VEE and Labview in the early nineties.

You might try sooner with something that strucks me a bit as "Mindstorm Duplo" ;) (yes, I know those aren't Duplo bricks...)

http://www.ni.com/academic/wedo/
http://www.lego.com/education/news/default.asp?pagename=press_kit&l2id=17_1

http://www.ni.com/pxi/mxiexpress/

This was done a few years ago in a different way: you wear an electronic collar which eavesdrops on the nerves running to your vocal chords. These signals are then decoded into words. Finally, some words, like "forward", are interpreted as intentions to move. The system is called the Audeo.

Official site: http://www.theaudeo.com/
Video: http://www.youtube.com/watch?v=iyQv61899HE
Article: http://zone.ni.com/devzone/cda/tut/p/id/6130

, which is slower than the previous one, and that requires bigger hardware.

Well, Win2k is faster than XP, perhaps we should downgrade to that? Oh, wait, Windows 98 is faster than Win2k. I'm wondering how quick MS-DOS would run on a quad core!

Screw MS-DOS. I'm waiting for someone to port the VIC-20 OS to the PC.

, which is slower than the previous one, and that requires bigger hardware.

Well, Win2k is faster than XP, perhaps we should downgrade to that? Oh, wait, Windows 98 is faster than Win2k. I'm wondering how quick MS-DOS would run on a quad core!

National Instruments is providing information on how to get Government-paid NI training and certification. You have to complete a couple steps (depending on your state) to get assistance, but there is a good amount of information and assistance available here.

They have a flow-chart programming interface that I had great success introducing programming to my 11-13 year old cousins

For the record, it's a version of NI LabVIEW, and it's a good precursor for those students who may end up in the F.I.R.S.T. robotics competition or in a job in research or engineering.

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

I'm a bit biased, but I'm a big fan of these:

http://www.ni.com/digitizers/

modular, (usually) cheaper, and the UI can be a normal scope interface or it be anything you want with LabVIEW.

Depending on the resources in your lab, and its purposes, you might find that a software-defined interface is more flexible for your needs. You can add any sort of interface or processing capabilities you want.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/205615

If it's a research lab, something like the above may be just what you want. If it's a teaching lab, and you want students to have access to real knobs and buttons, then my experience is specifically with Tektronix scopes that I use at work. Again, without knowing your price range, there are a wide range of options out there.

At the low end, the TDS5054B series has an interface likely identical to that of your old scope; they did a reasonable job of replicating the older style of analog interface but added on some processing utilities.
http://www.tek.com/products/oscilloscopes/tds5000b/

I've used a scope the DPO400 series as well. I found it's interface to be rather, well, different at first, with all the options not in the places I'd usually expect them to be with my other Tek scopes. But I eventually grew used to it and found it all perfectly fine - except that the probe connections for some reason don't allow use of our current probes. They work fine on all other scopes, and I see no reason why they molded the plastic on this scope to exclude them.
http://www.tek.com/products/oscilloscopes/dpo4000/

Finally, at the high end, you have something like the DSA8200. This scope runs windows, which you can get to to do some data analysis, but the scope itself is controlled through the Tek application. It looks and behaves like a piece of software; there are buttons on the front for some features, but they are just macro buttons to execute the commands; it's often faster to just use a mouse since the buttons only offer limited functionality.
http://www.tek.com/products/oscilloscopes/dsa8200/

Note how the Tek scopes are all mostly more expensive than the NI scope, with more limited flexiblity in the interface. Again, if I knew what bandwidth you needed or what your budget was or the purpose of your lab, I could give better recommendations.

obviously their userbase already have a strong interest in Linux.

If so, they sure are ignoring us. The last release of their Linux driver package (NIDAQ) was in 2005. Installing it on a recent version of Linux proved practically impossible. Finally after a few days of installing and reinstalling different distros I got it working on a 2-year-old version of SuSE. But basically determined that outside of personal use, this is totally impossible to expect customers to use if we are to integrate an NI board into our product.

Finally discovered that their "register-level driver" is way more efficient and easier to integrate into a software package. Even open source! We're using it and are happy with it, but unfortunately due to the fact that they are using a "BSD license" (although it doesn't actually say that anywhere on the product, they confirmed it in a forum post.. the software just says "copyright national instruments") GPL-incompatibility issues are stopping us from adding new features, like for instance having it play nice with udev.

After contacting them they seemed interested in rectifying the issue but since seem to have dropped it.

I dunno, they just don't seem to be able to keep up with Linux. You'd think compiling against the latest distro and putting out a driver update or two in a 2-year period wouldn't be so hard for a company that's all about hardware.

A good side of course is that their hardware is fully documented. It's possible that a community effort like comedi is just a better solution in the long run. But I'd prefer it even more if there were an effort to get a standard interface for multifunction DAQs into the Linux kernel. Basically, the OSS model of long-term reliability is to play well with others and contribute your drivers to a larger project instead of trying to do everything yourself. That way everyone helps to port things forward when interfaces change. I wish more companies would realize this, but instead they fall back to NIH syndrome over and over again, making more work for themselves than necessary, and complaining that Linux support is too hard.

Meanwhile, is it _really_ necessary for the Windows driver package to be a freaking 1 GB DOWNLOAD!? When all I need is a couple of DLLs and some header files.

obviously their userbase already have a strong interest in Linux.

If so, they sure are ignoring us. The last release of their Linux driver package (NIDAQ) was in 2005. Installing it on a recent version of Linux proved practically impossible. Finally after a few days of installing and reinstalling different distros I got it working on a 2-year-old version of SuSE. But basically determined that outside of personal use, this is totally impossible to expect customers to use if we are to integrate an NI board into our product.

Finally discovered that their "register-level driver" is way more efficient and easier to integrate into a software package. Even open source! We're using it and are happy with it, but unfortunately due to the fact that they are using a "BSD license" (although it doesn't actually say that anywhere on the product, they confirmed it in a forum post.. the software just says "copyright national instruments") GPL-incompatibility issues are stopping us from adding new features, like for instance having it play nice with udev.

After contacting them they seemed interested in rectifying the issue but since seem to have dropped it.

I dunno, they just don't seem to be able to keep up with Linux. You'd think compiling against the latest distro and putting out a driver update or two in a 2-year period wouldn't be so hard for a company that's all about hardware.

A good side of course is that their hardware is fully documented. It's possible that a community effort like comedi is just a better solution in the long run. But I'd prefer it even more if there were an effort to get a standard interface for multifunction DAQs into the Linux kernel. Basically, the OSS model of long-term reliability is to play well with others and contribute your drivers to a larger project instead of trying to do everything yourself. That way everyone helps to port things forward when interfaces change. I wish more companies would realize this, but instead they fall back to NIH syndrome over and over again, making more work for themselves than necessary, and complaining that Linux support is too hard.

Meanwhile, is it _really_ necessary for the Windows driver package to be a freaking 1 GB DOWNLOAD!? When all I need is a couple of DLLs and some header files.

obviously their userbase already have a strong interest in Linux.

If so, they sure are ignoring us. The last release of their Linux driver package (NIDAQ) was in 2005. Installing it on a recent version of Linux proved practically impossible. Finally after a few days of installing and reinstalling different distros I got it working on a 2-year-old version of SuSE. But basically determined that outside of personal use, this is totally impossible to expect customers to use if we are to integrate an NI board into our product.

Finally discovered that their "register-level driver" is way more efficient and easier to integrate into a software package. Even open source! We're using it and are happy with it, but unfortunately due to the fact that they are using a "BSD license" (although it doesn't actually say that anywhere on the product, they confirmed it in a forum post.. the software just says "copyright national instruments") GPL-incompatibility issues are stopping us from adding new features, like for instance having it play nice with udev.

After contacting them they seemed interested in rectifying the issue but since seem to have dropped it.

I dunno, they just don't seem to be able to keep up with Linux. You'd think compiling against the latest distro and putting out a driver update or two in a 2-year period wouldn't be so hard for a company that's all about hardware.

A good side of course is that their hardware is fully documented. It's possible that a community effort like comedi is just a better solution in the long run. But I'd prefer it even more if there were an effort to get a standard interface for multifunction DAQs into the Linux kernel. Basically, the OSS model of long-term reliability is to play well with others and contribute your drivers to a larger project instead of trying to do everything yourself. That way everyone helps to port things forward when interfaces change. I wish more companies would realize this, but instead they fall back to NIH syndrome over and over again, making more work for themselves than necessary, and complaining that Linux support is too hard.

Meanwhile, is it _really_ necessary for the Windows driver package to be a freaking 1 GB DOWNLOAD!? When all I need is a couple of DLLs and some header files.