Actually, I'm not trying to discredit it. VB is very good for creating the gui interface. It's just not robust enough to build an entire data acquisition system upon (as I'm assuming you know).
My implied discredit comes from my current project , where I've been literally instructed to use VB for the ENTIRE project, for the reason stated: so that the other engineers, who may actually never need to see the code, could understand it if they did look at it (they only code in Basic). I've also been instructed to use VB 6... Right now, with the project only 85% complete, I'm looking at 50k+ lines of VB code as it is...
Maybe I'm just grouchy because I'm tired of looking at Basic code.
Replying to myself... Oh well, I've been accused of talking to myself before.
I havent' used NI for a year or so (havn't needed new hardware). Now that I actually check their site, I have to retract the "All of their software has linux drivers" It appears that they're linux support isn't as strong as it once was (has Microsoft gotten to them too???)
Anyway, they did have the specs published in the earlier manuals. Check into this.
I have had success with their hardware. In some cases, you may (or may not) need to use labview to get the device drivers (it would seem).
good luck
If you're using Windows machines, want quick and dirty GUI code, or code that less computer literate people (older engineers who had little or no programming training) can read; then, you write in VB.
Otherwise it's C; or, even better, C on Unix.
National Instruments, as a company (no, I don't work for them) has been very good about supporting Linux. All of their software is available in Linux versions, All of their hardware has Linux drivers. And they release I/O port maps and hardware specs for those who want to develop their own drivers.
There's a lot of VME/VXI hardware out there that will also work well with linux kernels (I've done it). Compact PCI (cpci) should work as well, although much of it seems to be driven by x86 / Windows embedded computers...
Any hardware which communicates to the workstation via a standard interface (ethernet, usb, gpib, serial, etc) should work just fine.
The real issue is simply checking the vendors of your hardware BEFORE you make the purchases to see if the hardware is supported. This should be true with any hardware purchase. (It is possible to buy hardware that doesn't work with Windows...)
If you're trying to use legacy instruments (which you already own) whose manufacturer does not support Linux and who refuses to release interface information (because of it's proprietary nature); well then, you're out of luck unless you can kludge an interface with a Windows PC talking to the device(s) (acting as an ad-hoc interface) and a Unix system doing the rest of the work. You'll get better performance this way than trying to have the Windows PC do all the work.
I'd urge you to use Unix or Linux variants for data acquisition and controlls. Windows is not deterministic and DOES NOT do real-time (I don't care what Microsoft says or how fast the machine runs).
Almost every government project you've seen? How many is that?
Every government RESEARCH project I've seen was done with Unix or Linux systems (coming from someone who worked for the Department of Energy for 11 years).
Windows was only used in Administrative tasks because we had an early installed base of Office from prior to the release of better quality Linux software like Open Office.
Ok guys (and gals) it's time to get over it. I'm sitting here at my desk, within sight of NASA - Langley thinking about it (I don't work for NASA, just happen to work for a company located next door to the facility). I admit, I've been thinking about it a lot myself; because, the Challenger accident changed MY career plans (I was a senior in high school in '86).
It happened; it was tragic; we now know why.
Let's acknowledge that we have flawed (even if brilliantly engineered) aging system. We have little choice but to limp along for now, using what we've got. Let's fix the problems we can, and continue to fly.
Let's not forget that NASA's not totally to blame. If Congress didn't cut their budgets, there might be better maintenance on the shuttle; and, there'd be a next generation shuttle flying now. And, if the Air Force hadn't insisted the shuttle be built out of Aluminum (they insisted that the available titanium go to the SR-71 program) the shuttle would have been made of more durable stuff. But that's just more woulda, shoulda, coulda stuff, and I digress.
To totally cancel the existing program would devastate any research currently being carried out. I've seen research projects, which had merit, die slow painful deaths because of program cancellations. I'm sure I'm not alone in having been the target of cancellations because of FUD: "We're not going to do... because last time we invested money,... cancelled the program half way through"
Obviously, we need to build a replacement system. It will take time; that's just a fact. What we've learned from the Shuttle, good and bad, will make it's eventual replacement that much better.
I have to argue here...
What good would it do to stuff the hole full of stuff that is simply going to burn up in re-entry like the airframe obviously did. Buying a few seconds, or even a minute or two simply means it breaks up a little later.
The result is still the same: The shuttle breaks up.
Surveyors do the alignment of such facilities as nuclear accelerators. It's important that the components be accurately placed to to such tight accuracies; and, they regularly do work such miracles. It's amazing to see a large system set up, where you have a mile diameter loop, for example, and have everything be right to within a few millimeters.
I saw one mistake made once, where a target was missed by 1 inch. They went back through the system and found it was a mistake on an engineering drawing; but, as a result of the analysis, they found that they were off by exactly 1.00"
It's even more convoluted than you imagine. At one point (100 years ago), a 5" iron pipe was 5" in ID and assigned a "schedule" rating signifying it's proof(burst) pressure. With advances in metallurgy, the wall thickness required has been reduced. Simply changing the thickness and leaving the ID the same causes problems with fitting old pipe to new. So, a 5" schedule 40 pipe is no longer 5" ID, the OD/ID have been averaged to fit the middle of the thickness of the old pipe...
If NASA put up an 'ad' saying: we ned a man rated launcher...
But that's essentially what happens. Just NASA maintains ownership of the shuttle. NASA didn't build the thing. They didn't do all the design work either. A contractor did. The system works something like this: someone says, We need... A list of proposals is created. Contractors make suggestions and place bids. One of the contractors wins the bids on the merits of the proposal and the price they say they can do it at. It's built.
Slashdot Mirror
My implied discredit comes from my current project , where I've been literally instructed to use VB for the ENTIRE project, for the reason stated: so that the other engineers, who may actually never need to see the code, could understand it if they did look at it (they only code in Basic). I've also been instructed to use VB 6... Right now, with the project only 85% complete, I'm looking at 50k+ lines of VB code as it is...
Maybe I'm just grouchy because I'm tired of looking at Basic code.
Replying to myself... Oh well, I've been accused of talking to myself before. I havent' used NI for a year or so (havn't needed new hardware). Now that I actually check their site, I have to retract the "All of their software has linux drivers" It appears that they're linux support isn't as strong as it once was (has Microsoft gotten to them too???) Anyway, they did have the specs published in the earlier manuals. Check into this. I have had success with their hardware. In some cases, you may (or may not) need to use labview to get the device drivers (it would seem). good luck
If you're using Windows machines, want quick and dirty GUI code, or code that less computer literate people (older engineers who had little or no programming training) can read; then, you write in VB. Otherwise it's C; or, even better, C on Unix.
There's a lot of VME/VXI hardware out there that will also work well with linux kernels (I've done it). Compact PCI (cpci) should work as well, although much of it seems to be driven by x86 / Windows embedded computers...
Any hardware which communicates to the workstation via a standard interface (ethernet, usb, gpib, serial, etc) should work just fine.
The real issue is simply checking the vendors of your hardware BEFORE you make the purchases to see if the hardware is supported. This should be true with any hardware purchase. (It is possible to buy hardware that doesn't work with Windows...)
If you're trying to use legacy instruments (which you already own) whose manufacturer does not support Linux and who refuses to release interface information (because of it's proprietary nature); well then, you're out of luck unless you can kludge an interface with a Windows PC talking to the device(s) (acting as an ad-hoc interface) and a Unix system doing the rest of the work. You'll get better performance this way than trying to have the Windows PC do all the work.
I'd urge you to use Unix or Linux variants for data acquisition and controlls. Windows is not deterministic and DOES NOT do real-time (I don't care what Microsoft says or how fast the machine runs).
that's just my 2cents worth...
Almost every government project you've seen? How many is that? Every government RESEARCH project I've seen was done with Unix or Linux systems (coming from someone who worked for the Department of Energy for 11 years). Windows was only used in Administrative tasks because we had an early installed base of Office from prior to the release of better quality Linux software like Open Office.
It happened; it was tragic; we now know why.
Let's acknowledge that we have flawed (even if brilliantly engineered) aging system. We have little choice but to limp along for now, using what we've got. Let's fix the problems we can, and continue to fly.
Let's not forget that NASA's not totally to blame. If Congress didn't cut their budgets, there might be better maintenance on the shuttle; and, there'd be a next generation shuttle flying now. And, if the Air Force hadn't insisted the shuttle be built out of Aluminum (they insisted that the available titanium go to the SR-71 program) the shuttle would have been made of more durable stuff. But that's just more woulda, shoulda, coulda stuff, and I digress.
To totally cancel the existing program would devastate any research currently being carried out. I've seen research projects, which had merit, die slow painful deaths because of program cancellations. I'm sure I'm not alone in having been the target of cancellations because of FUD: "We're not going to do ... because last time we invested money, ... cancelled the program half way through"
Obviously, we need to build a replacement system. It will take time; that's just a fact. What we've learned from the Shuttle, good and bad, will make it's eventual replacement that much better.
I have to argue here... What good would it do to stuff the hole full of stuff that is simply going to burn up in re-entry like the airframe obviously did. Buying a few seconds, or even a minute or two simply means it breaks up a little later. The result is still the same: The shuttle breaks up.
Surveyors do the alignment of such facilities as nuclear accelerators. It's important that the components be accurately placed to to such tight accuracies; and, they regularly do work such miracles. It's amazing to see a large system set up, where you have a mile diameter loop, for example, and have everything be right to within a few millimeters. I saw one mistake made once, where a target was missed by 1 inch. They went back through the system and found it was a mistake on an engineering drawing; but, as a result of the analysis, they found that they were off by exactly 1.00"
It's even more convoluted than you imagine. At one point (100 years ago), a 5" iron pipe was 5" in ID and assigned a "schedule" rating signifying it's proof(burst) pressure. With advances in metallurgy, the wall thickness required has been reduced. Simply changing the thickness and leaving the ID the same causes problems with fitting old pipe to new. So, a 5" schedule 40 pipe is no longer 5" ID, the OD/ID have been averaged to fit the middle of the thickness of the old pipe...
Yeah, unfortunately it sometimes takes millions of years for the universe to make it's effects known. I can't wait that long...
But that's essentially what happens. Just NASA maintains ownership of the shuttle. NASA didn't build the thing. They didn't do all the design work either. A contractor did. The system works something like this: someone says, We need... A list of proposals is created. Contractors make suggestions and place bids. One of the contractors wins the bids on the merits of the proposal and the price they say they can do it at. It's built.
But it is used still in certain applications.
Beyond F77 (FORTRAN 77) theres an f90, f95 and a Fortran 2000 standard...
I've been known to play with them there old vacuum tubes from time to time. It takes one back to one's roots; staring at the warm glow...