Slashdot Mirror
Running a Research Lab on Free Software?
"[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is. Who could blame them? Their Windows DLL is the perfect solution under [most] circumstances.
I'm not the only one around here getting frustrated, but all before me have been defeated. It seems I am to be as well, for today I have started to learn Visual Basic.
Has anyone had any *positive* experiences trying to move a lab from proprietary to free software? Surely the government-funded researchers of the world have a responsibility to ensure that their work is free, as in freedom. However, I have found out the hard way that it's usually just not worth the effort, following such ideals. You just get frustrated by apathetic colleagues, useless product support, and the conventional wisdom that it's OK to ignore your ideals, so long as you get the experiment working. Additionally, my ordeals convince my peers that free software isn't worth the trouble."
I once saw Isaac Chuang's quantum computing lab. He was controlling something to do with the NMR machine with an embedded linux device that looked like it was held together with gaff tape.
:wq
Research companies write their software in VB? No wonder there's still no cure for cancer!
For almost any government project i have seen, Windows is the choice by the government. Getting them to switch over makes no sense to them, because why switch when you have something that works? Cost benefits don't really seem to do anything, but they seem afraid of switching and trying something new because Windows is just the way it has been, and will continue to be for them. Research might be the same way. UNlesss their research IS software like this, they may just want to stick with what has already beenw orking for them.
I've found it somewhat difficult to use since building their modules is really suggested on a generic rather than stock Redhat kernel (and building with what are claimed to be the RH sources and config files didn't work for me).
Funny thing is, the two and a half weeks that the "all BSD" lab lasted, we had no work orders concerning crashes. I learned BSD only because the LAN manager in question made me learn it to move a email server over to it (Novell GroupWise used to be VERY expensive, and this square-headed manager didn't want to pay a bunch of cash to run one secure and isolated mail server on Novell stuff).
Business is business I guess.
You've wasted a *lot* of time and effort trying to implement some simple stuff with free (and better) alternatives? Surely that beats wasting a lot of time and effort trying to implement the same things with commercial (and worse) alternatives?
I'll give you the benefit of the doubt and assume you made a slight 'grammaro'.
As someone who has been a sysadmin for a 20-person femtosecond laser group, may I suggest Labview (www.ni.com)? It runs on Linux & Windows, many hardware cards support it, and it's honestly better than VB.
Your time is your most important resource. Don't waste it recoding.
R.
I work in a Corporate R&D lab and we're pushing open source technologies here, but you have to be patient and strategic.
First off, are you trying to make programmers convert? If so then you're in a losing battle. People will almost always stick with what they're comfortable with. You'll only get them to look at something else if it is 1 or 2 orders of magnitude simpler to use.
Set an example with your work. If you can do your work using OS tools and you can do it quicker, cheaper, and easier then that's how you convince people. Comments like, "But VB is lame. MS is the anti-christ. etc..." do NOT a good case for conversion make.
Finally, if you can't do it in OS then don't. If you're stuck because of specific hardware/OS issues then don't try to fight the beast on those for now. Pick projects and things that you can migrate and move those instead. (Move the intranet site to JSP or PHP or whatnot on Linux/BSD/Apache. Throw out some NT/2000 Domain boxes and use SAMBA instead.) If you can show the advantages of OS tools for certain tasks then you can get people thinking about it. If you can't do it because of the hardware you're using then you're just going to appear as a stubborn zealot to your colleagues.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
Actually, I sometimes feel that this is the number one symptom of the obstacles that OSS/free software face. Multiple times, I have been labeled a nut for wanting to us Linux/OSS. I had a roommate in the dorms once who insisted that I would be "happier" using Windows.
As far as experience moving labs from Windows to OSS, I have never moved an entire "lab" so-to-speak to Linux, but it is my experience that in the past three or so years since I was introduced to Linux, it has made big inroads into becoming easier to install and use. The hardware support is definitely better. I remember when I first tried Linux, support for USB mice was still experimental.
These days, migrations from Windows to Linux have been relatively smoothe. I've had great success moving a fileserver from a Windows NT workstation to a less-used Linux box. Usually, it will eventually go down because of a power outage - so I recently purchased a UPS.
The bottom line is, I think that the problem of colleages who drag their feet on using Linux/OSS will be reduced as major distros become increasingly easy to setup and operate and hardware support improves.
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
Are you sure the fine print in your resident research grant allows you such freedom?
certain hardware manufacturers utterly refuse to support anything other than Windows
Since you mentioned you did some coding, you may want to check out Linux Device Drivers plus some of their other kernel tweaking/modding books.
simply because certain hardware manufacturers utterly refuse to support anything other than Windows."
Just pick your hardware manufacturers more carefully. There is plenty of analog and digital I/O boards for PCs that have Linux support. Even better, Linux is very popular on embedded systems (like PC104), so you don't even need a whole desktop PC but can use a small, embedded PC running Linux, together with hardware that comes with Linux drivers.
It is also my experience that manufacturers that ship Windows-only hardware are generally substandard. They probably don't support Linux because they are very tight on resources. If they don't give you low-level documentation, it's probably because they don't have it. And you end up between a rock and a hard place with that kind of hardware when VB wants you to upgrade your OS and their proprietary Windows driver won't work anymore.
UNIX itself has a very long tradition for experimental applications, so if there is nothing for Linux, consider getting a cheap Sun workstation with hardware that is supported under Solaris. That will still work a lot better than the Windows stuff, and it will interoperate nicely with Linux machines.
If you absolutely must do something on Windows, use Python, Perl, and/or wxWindows rather than VB. CygWin is also great. That way, your developers will acquire open source and Linux expertise and won't be locked into the Windows upgrade treadmill.
So, while occasionally some cheap peace of Windows hardware may seem alluring, if you just look around a bit more, you'll probably find something at least as good or better for Linux.
..you choose whatever platform/software that will do the job the best.
Functionality
Availability
Budget
Useability
Philosophy is far down the list.
Clearly VB is the winner here as it perfectly mimics the unpredictability of quantum mechanics!
Sounds like a Michael Crichton recipe for technology gone bad. I bet the fat guy in your lab gets it first.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
It's a shame, but often to accomplish work in the sciences (which means publishing and getting grants) one often has to use the best tool for the job. Sometimes this means spending lots of money and effort to develop tools which are not available. Other times it means purchasing hardware that is available and can do the job (those $40k SGI Octanes come to mind). Some times you can get lucky and use a tool that is both free and commonly available (a wonderful example is ImageJ developed by Wayne Rasband(sp?) who also wrote the seminal NIHImage.
Unfortunately, one can waste huge amounts of time, effort and money attempting to find solutions that will meet your needs for lower costs/free, but that time and money might be better spent obtaining the tools that will do the job and simply working at the job until it is accomplished. I understand what you are saying though in that I am trying to transition our lab from Wintel to Macintosh for a whole variety of reasons from security to ethics to simply that all around, Macs seem to be better tools, especially with OS X. That said, we still have to run Wintel hardware and Microsoft operating systems until the tools that we require are on our platforms of preference and we still will probably have to have both operating systems co-exist for some time to come. That is OK with me though as I will always go for the better tool. If it is available on Windows, that's what I will get. However, the MacOS is so much better that if the tools are also available for OS X, I will default there.
Visit Jonesblog and say hello.
I have never known a lab that used VB as its programming environment. Usually it is either c/c++, Java, or one of the math programs (matlab, mathematica, maple, etc...). In general, I would recommend using microcontollers for controlling your experiments. However, you mentioned that you are doing stuff at the quantum level, so these may not be fast enough for you (the ones I use are 20MHZ). However, I must say that the PIC series of microcontollers can be programmed in a variety of languages and has a great deal of flexibility. One of the main problems is that a lot of the software for contolling lab equipment is either homebrew for a specific application (as is the case with some dynamic clamping software in the neurosciences) or made for a wide variety of applications (labview), but is not open source. The best option may be to get a company made environment which can have functions written for it in another programming language and customize it. However, coming from a biology side of things I do not know what your specific needs would be for quantum computing, and thus cannot give any ideas as to that specifically. Good Luck.
Don't do it! If you have to learn something, at least go to C#. Visual C++.NET would be OK, too. Both of those are better languages all around. And you can still interface to DLL's with either. To almost any programming question VB is NOT the answer.
That is all.
I've used comedi with a National Instruments NiDAQ 16 channel acquisition card on a P3 laptop running debian - it worked very well.
However, can I offer the following advice, which may save some people from smashing their head into a bloody pulp against a wall...
* Turn off APM!!! *
You can do this by passing apm=off to the Linux kernel with your bootloader (I think - can't actually check that at the moment) if you don't want to actually remove it from the kernel (APM is useful on a laptop normally).
If you don't do this, you might find your acquisition mysteriously stalling after random intervals. It's to do with APM interrupt handling. Not sure if it's restricted to PCMCIA cards.
First, naturally, there is the question of "Who do you sue" when things go wrong (which in itself is a statement of the issues surrounding responsibility in community development.) Commercial software vendors strive to meet a standard of reliability because they've implied with the sale of their software a warranty of fitness.
Also, there is a question of reliability. Commercial software is designed towards a goal; Open Source is designed almost by accident. Integrating commercial products tends to work better than Free Software because of an accumulation of tolerances.
Most importantly, using commercial software makes repeatibility in other labs a more likely possibility. A Windows setup is standard. A Linux (or whatever) setup depends on any number of factors, from the versions of the software to the distributions of the kernels. Irregardless of the general expense involved in setting up commercial software testing, this is perhaps the most important thing: your colleagues won't have a chance at duplicating your results if they don't know what you're running.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Is it really worth your time, your professor's time, or the government grant's time to spend your quantum research dollar in overhead costs as you bang your head away in frustration trying to cludge together some string of 0.2 beta versions of open source data collection programs?
And what about when you leave? Does the next grad student have to spend 3 years learning your absolutely unique software setup instead of learning physics?
In the Big Name(TM) physics lab I work in, grad students cost about $200 a day (to the grant), and postdocs cost about $500 a day. If I need a program that would take me a month to write or costs $2,000 to buy today, it's my job do know to just buy the program.
We used to use LabWindows (call it C++) and VisualBasic, but the last person who know LabWindows left and now looking at the code when things go wrong is a nightmare.
So, anything new is being done in LabView. (Disclaimer - I don't work for National Instruments) Sure, it costs $2K for the good suite, but I guarantee you will make up for it in productivity. Plus, debugging LabView code as a beginner is waaaaay easier than debugging someone's crazy spaghetti C code. With the high turnover rate of a research university, it's very important to retain the chain of knowledge. Otherwise things progress into the realm of Black Boxes.
My opinion is not to waste your valuable research time worrying about software. Especially in quantum computing where you will be left in the dust if you fart around worrying about open source too long.
Best of luck,
Muerte
[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is.
You have to phrase your request nicely:
"Give us the technical specs, or we will crack your company encryption keys with our quantum computer, access all your specs, and post them on usenet."
However you do not have to run VB only. My Windows2k box has opengl, openinventer, vtk, ativePerl, active Python, gVIm, cygwin, gnuc/c++, Devc++, ruby, tk/tlc, apache, php, etc.
Infact the win32 ports for these opensource apps are very well integrated with Windows. FOr example I can use gvim aka VI to replace my editor in VC++, create ole programs in python, and even use Perl to create Excell macro's.
Your Windows based collauges will get use to opensource and be more open later on after they get used to it.
As a scientist I assume you use VB for similiations and or to interface with your devices for experiments.
For similiations try vtk++ and openinventor. Your colleagues probably used them in Irix quite heavily. THe libary comes with a great
If your equipment provider only provides
http://saveie6.com/
LabView will also run on Linux, and they are porting it to OS X. So at least it's half-free?
Muerte
ps. sorry for being such a troll to reply to my own post.
Forget the old stuff, concentrate on new projects, number crunching and data servers. Use the strengths of free software first, then move into areas you can. Old stuff is working, as well as any old M$ junk works, and you will only be frustrated working with equipment no one cares about. "Rebuild" it till it smokes. You are familiar with the superiority of free software available for networking, number crunching and programming. Take old computers no one wants and make them useful. Something as simple as databases, web servers and email servers are helpful. Take the hardware advice you get here and put it into your next proposal. The bottom line will speak for itself and you will have proven the dependability of free software on comodity hardware already.
Friends don't help friends install M$ junk.
Maybe the sci apps developers should investigate how the trunking of manufacturer supplied win32 dll's can be used to give at least x86 machines with free operating systems access to the hardware. It's better than nothing at least.
But yeah, I know it sucks. The hardware vendors shouldn't whine. They shouldn't care what OS is used to drive their hardware, just that intitutions can buy and use it. And institutions are a lot different from normal consumers. The sci-institutions just want to get their work done. And, according to the story poster, with something else than Microsoft's stuff.
It's not just a pride thing,
Well, thank goodness for that!
The coolest voice ever.
I'm doing my Ph.D. at a mobile robotics lab. Most (all?) of the robots we bought, (either from iRobot or ActivMedia) came with Linux pre-installed. I don't think we could even have Windows if we wanted it. I think this is going to be much more frequent in the future. For things that don't have a display anyway (no we don't have 17" monitors on our robots!) what's the point of running Windows?
Opus: the Swiss army knife of audio codec
Depends on the research I guess:
o v/torc/
http://www.csm.ornl.gov/
http://www.csm.ornl.g
we are mostly linux. We do some windows because we choose too (for varying reasons, most of us really like Open Source but are relativly OS agnostic).
Besides our CS work we run things such as the human genome project, nuclear fallout modelling, vis applications, process data from some of the colliders, basically govt researchy type stuff.
So yes, it is VERY possible to run a research lab under linux, unix, or windows, though there will generally be some mix. Here, compute power is usually linux/unix, developer platforms are generally linux/unix, office work is usually windows - though sometimes windows has some software that is really kick ass.
------- Sorry about the spelling, I suffer from two problems. Dyslexia makes it difficult to spell well, lazy makes it
I also do Government research and you'd be hard-pressed to find windows running on any of the machines we work on (except in the PR / HR departments). I do most of my number crunching on an Origin 3000 running IRIX, but I could just as easily move it to Solaris, AIX, HP-UX, Linux, and SunOS.
Who are you?
Labview is okay, but I much prefer IGOR (www.wavemetrics.com). It's a pretty powerful data acquisition and analysis software package that my mesoscopic physics lab predominantly uses. It runs under Windows and Mac OSes and allows you to automate pretty much anything if you write the code for it. You can buy add-in software that allows you to use the GPIB interface, which many instruments carry.
W.
Nope. Since fairly recent desktop machines without PCMCIA slots are perfectly capable of sleeping/hibernating with the apm 1.x spec. And, yes, APM interrupt handling is involved here.
And the last thing I need is having a desktop box fall to sleep when I'm doing benchmarking of (say) C library function calls for an extended period (a.k.a. generating datasets that need to be reliable to make sense).
Although i.e. my desktop machine supports this, I don't see the need of ever turning APM on if the machine I'm using is not something that has/needs a battery and is not always switched on. Also, I doubt that the boards comedi supports will fit inside a laptop, so the point is actually very moot. :-)
But yeah, good advice. I can imagine a VB user missing that one ;-)
My graduate program focus on using spin physics either to image people or animals, or to get info about proteins and free radical interactions on a molecular level.
On the molecular biology side, all of our new spectrometers and their analysis software are linux based.
On the imaging side, our primary acquisition platform was HP/UX, then IRIX (primarily because we could not find PCI A/D cards with good enough performance numbers for our needs,so we had to go with VME-based solutions).
Our latest "toys" however, are a couple of linux PCs with PIC A/D cards that allow us to do the same thing the SGI Power Challenge did, for about 1/4 of the cost, and much faster - not to mention easier to maintain. Our analysis software is also home grown. It's developed primarily under linux, but has been ported to IRIX, and I made a couple of tweaks here and there to get it working under OS X.
Now I will say now that my boss is a hardware genius. He IS the reason I came to this program for my degree. He wrote the drivers for the A/D cards for ALL of our imaging platforms (i.e. drivers for HP/UX, SGI IRIX and Linux). He's a physicist by training, but has a good understanding of the underlying math and physics, and reads the docs and books like crazy !!
So if you want to set up a linux only lab, it IS very possible. You (or the folks responsible for the lab) just have to invest resources (mainly time and for documenatation) to move your setup
over to linux.
You guys are trying to get Windows running on quantum computers? Talk about uncertainty!
This way you can use python, and all of the open source goodess that comes with Python, plus you can link to those god forsaken DLLs.
ActiveState: Python, Perl, Tcl, etc for Windows.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
who run the labs. In our lab we wouldn't make the purchase when the products could't work on more than one open platforms. It's not like we hate Windows and proprietary products.
A researcher with certain year of experience would have thru the nightmare of getting obsoleted hardware to work - it's not that the hardware itself is getting out-dated, it's about its interface i.e. the device driver. E.g. the VPL optical gloves are still usable today as we've the driver source came with them, even when the company behind were out of contact for years; while we have to kiss those 3d controllers goodbye when their Windows device driver no longer functional in modern Windows system.
Really, we had no problem when we had to code in VB, as long as it works effectively, and gives results for our papers. We just don't want our money wasted on endless upgrade-cycle(if upgradable), we are not running a corporation afterall.
It wasn't so much the laptop falling asleep - just having the APM code active in the kernel was doing something screwy to the interrupt handling from the NiDaq card. It would fail acquisition after 15 seconds or so (although fairly randomly).
David Schleef pointed this fix out to me after I asked him very politely about what the $#@$ was going on...
Microsoft software is available for a negligible cost at the academic discount.
Assuming your lab is attached to a university the costs of any MS development tool would be a very small part of your budget
Still too expensive? Get a good connection with Microsoft's education people. Friend of mine ran a website for kid's science education. MS *gave* (read: free) him: NT4 Server (this was a while ago), SQL Server, Visual Studio Enterprise Edition and a bunch of other stuff. He turned his back on Linux and open source tools the day that package arrived from MS.
As soon as that check for $750M clears, there will probably be a whole bunch of cross-platform hackers ready to work on something else... call it Labzilla, especially since there's already something else called that!
We work on a DARPA project that runs a distrubuted multiagent system which is written in Java across a couple hundred dual-Xeon machines running Linux. The control mechanism is a Ruby application framework that uses Jabber for control and stressing of the multiagent application.
Not only is the project using open source as the infrastructure, but contributing to the open source community with projects like Cougaar and PMD.
We use Linux primarily because of the simplification of administration and maintanence.
Comedi is awsome. The very first driver described leads to The 8255 driver. It's author, Daniel Franklin, recomends "Alessandro Rubini's excellent book Linux Device Drivers (another fine O'Reilly publication)" Ahh, knowledge, what could be finer. Free software, free info. Go get it and become the research tech God you want to be.
Friends don't help friends install M$ junk.
I'm just a lowly sysadmin at a biotech (genetics research), and while we're not doing anything on the level of quantum computing research, its REALLY hard even with our stuff (which is more commercial, more prolific, and therefore more likely to be windows) to find anything that is not written for Solaris/Linux/Irix. Everything is written for unix. I could list a couple dozen tools that account for 95% of what is used in the industry for research in fact, and not one of them doesn't at least have unix as its primary devel platform.
So again, I'd REALLY like to know the names of some tools that he's using for quantum computing research that only work on windows. Cause M$ Word does NOT count as such a utility.
Theoretically you could use any operating/language you want. The key question is:
Do you want to learn a new language/os or focus on the science?
In my lab, we use a Labview/MacOS/Gpib combination for our development? It simple to use and it works. It is a little on the expensive side but you get that money back in time saved. It so simple, undergrads can learn it and develop useful applications.
We also have Windows/Basic system that is use to control a commercially develop experiment. Though I need extra features for the experiment, I refused to learn to develop with it because I don't have the time. I am here to focus the science not on learning programming languages.
If you insist on switching over to an open source solution. Then tried Linux/ C or C++. But be warned, aside from serial ports, you may have trouble get other DAQ boards to work.
You don't have to be smart to use a Mac, you just have to be smart enough to buy one
don't fix it. For fuck's sake, did you read your own submission?
I know what I'm missing out on, in the free software world.
Followed immediately by:
I've wasted a *lot* of time and effort trying to implement some very simple stuff with free (and better) alternatives
Yeah you're missing out on the struggle and pain of hacking together ad-hoc solutions to an already-solved problem.
Way to go, buddy.
I work with a research professor at the University of Washington. I'm hard pressed to find a windows machine on my floor (I think there are two, and they suck). Everything is Solaris. The main server room has a huge Sun Enterprise Server and a 19 computer linux cluster. My group just got its own 2TB storage server, it's linux based... The whole dept. seems to moving from Solaris => Linux if anything... but no where near Windows.
Anyone has experienced something like that? and what kind of "measures" you take to get some Free Software followers?
The package said "Windows XP or better. Pentium Class Processor or better"... So I got a Mac with OS X
Consider whether you really believe that ALL software NEEDS to be open source, I mean, as long as the OS and the core tools are, is there really a problem with someone writing a fairly esoteric piece of software that few people will ever use and charging money for it?
I suppose VB isn't really that esoteric, but as others in this thread have pointed out, open source isn't free-as-in-free-beer, because it takes someone time to write it, and if that someone is you, then your time costs money. Bite the bullet, spend the time researching if the system works.
Anyway, then in this weeks sourceforge.net newsletter we were introduced to a program called B.I.E. (http://sf.net/projects/bie). Anyway, this app was designed to do exactly what we needed in getting data out of systems, and putting data back into other systems. We've replaced nearly 30% of our custom scripts in only 3 days!!!
So to get to my point, I'm wondering if you could get a system like that for hardware. Some kind of mechanism that would allow you to abstractly control different types of hardware. My thought is that with all the linux kernel and driver projects there are out there, someone must have created a distro specifically for researchers like yourself.
You buy a $500,000 mass spec or $40,000 HPLC, the manufacturer sells you a machine (usually from DELL/COMPAQ/HP) with propriatary cards, bundled with their proprietary software. Why? That way everyone with the machine is running the same OS, same software, so when you call because your $500,000 machine doesn't work anymore and you wan't to make use of your $5,000 a year service contract they either send you to DELL/COMPAQ/HP or their own database. They don't want to (and feasibly CAN'T)deal with your custom linux set up or that open source software written by who knows who to do who knows what that somebody has tweaked to work with your insturment. There is oodles of great OSS out there. But there are a limited number of very expensive instruments and a company can't sell an instrument without software. So, One: Nobody is going to sell an instrument without the software they spent money developing. Two: There isn't a huge demand for OSS alternatives, since they already paid for the software, and the instrument works. The last thing you want in your research lab it to make your expensive instrument not work. People get fired for that. Quickly.
I also work in a physics lab, and we had some bad experiences with LabView. First, it's another language to learn. Sure it's hooking up wires to modules in the gui, but for any semi-sophisticated programming you have to spend some time figuring out the LabView 'way'. Then, since only a few people learned how to do this, in order for changes to be made you had to convince them to change the program. Finally, when one guy left, he set the application lock so that no changes could ever be made (equivalent to deleting the source code). This was just data acquisition, the data was then imported and analysed in a c based analysis program.
So for the next thing that was built, the national instruments cards were driven by Comedi and all software was written in c++. Everyone basically knows c/c++, so improvements, changes were easy. Also, the code was automatically backed up, and production versions installed by root. And since the analysis was also c, it was integrated into the DA. Nice, and still in production usage!
Microsoft is determined to take over instrumentation. It is a Buisness priority. It would be very bad for them if the cheap comodity hardware, that everyone wants, was running Linux. What is in the lab soon gets to production. That means assemblers, testers, technicians, prduction engineers might get a lot of exposure to Linux. If they see Linux first hand, they will realise that it is not big and bad and only for geeks. At least some of the non-computor geek types in this catagory will give Linux a try at home. And this would be a major crack in the MS desktop Monopoly. All manufacturers of instrumentation are within MSs sights. Some have already been taken over. The long term goal for MS, is to have all instrumentation running Windows ( even though this is assinine). Windows only drivers will be supplied and the interface protocals will be propiatary. On top of that, the instruments will come with a EULA that will prohibit the instrument from being controled from a system that does not have a valid MS lisence. Technical and legel problems have prevented much success. The lates anti-trust coart case also put a major dampaner on things. But with the disruption in the industry caused by the current economic turmoil, MS sees a perfect time to let slip the dogs of war. And no, this is not all hot air and paranoia. I have seen indications of this for at least four years.
I've worked at Princeton Plasma Physics Laboratory (A US DOE Lab) and we were using Linux for our visualization cluster...despite that it was based off of the Princeton University one which was running Windows.
My current work is at Rutgers University's Dataman Lab working on wireless sensors from Berkeley University and we also run Linux to program for TinyOS.
So all I can say is that there are some places where the researchers are using linux
United Electronics, www.ueidaq.com, make data acquisition cards similar to National Instruments and have linux driver support. Check them out.
We have a lightning research group (previously mentioned on Slashdot here and here). We use LabView 6.1, on RedHat (7?), to communicate with PIC microcontroller-based instrument control boxes out in the field, to continously monitor the local electric field (which is a good indicator of the favorability of lightning initiation, either natural or triggered), and to arm, calibrate, and disarm all of the oscilloscopes in the various experiments. We leave the system unattended during the winter months, just in case a frontal storm comes through and we get a strike within a half kilometer or so...
.VI files are available to access the Comedi drivers from LabVIEW, and our fields monitoring program appears to have been running, unattended, without restart, for over 100 days on our dual Athlon MP 1900+ box.
We use the Comedi drivers to interface with our National Instruments DAQ card.
And if you can't program in LabVIEW, you might oughta practice asking if I want fries with that burger.
Ce n'est pas un vrai mouvement de robot!
A lot of times, especially in academics, you just have to work with what you have. The truth is that its a money thing. Whoever it was that was responsible for the purchase of the lab equipment also had to figure out the total cost of the support contracts and all the other cost analysis that has to do with the procurement of laboratory equipment. This holds true even in the corporate world. Even if we, the researchers, students, lab technicians, developers, would prefer a different solution or prefer to work on different platforms with different tools, it really doesn't matter since it's technically not our lab and our equipment. Now if it is your lab, then the game is entirely different.
kha0z
Master of ImportChaos.com
Linux isn't really mature yet for real-time control. Another year or two, and it might be a contender.
As for Visual Basic, my controls people all want to use Matlab.
It's free, supported, works on most platforms without rewriting the code, and has simple wrappers/interfaces for all kinds of programming languages, so you can still use those DLL's.
Voodoo Girl is the bomb!
I must disagree with the VB bashers here.
Our shop builds test equipment with lots of analog and digital I/O - some of it high speed.
We started off 20 years ago using C but switched to whatever-the-current-version of Microsoft's BASIC was at the time. Each system was unique and you can't beat VB for fast coding/debugging.
In the beginning we had to write assembler code to access the hardware regs on the acq boards for speed but when DLL's began to be supplied with the hardware things got much easier. The huge library of controls and DAQ add-ons for VB just cannot be ignored. For a laboratory the advantages would be similar - fast prototyping and debugging for unique applications with lots of off-the-shelf code and low labor costs. VB has it's faults but for this kind of work it is well suited.
There is really no economic advantage to using free software in this instance.
It wasn't true until .NET, but now I have to say, after using about 1/4 of the languages out there (and that's still a lot), VB has truly matured. I'd say that for anything except embedded software, or that which simply must work on *ix, VB is probably the best choice overall. Consider things like ease of use, learning curve, cost per hour per programmer, and it makes some sense.
Labview is better to use to actually acquire the data, but Igor is amazing to display the data.
I work in an IR laser lab actually doing labview development and it is VERY easy to program with.
You might look into the Wine project. Maybe the existing interface DLL's can be made to work for you under Linux. I believe that certain Linux programs (like MPlayer) use such methods to directly access Windows DLL's. This lets you go ahead and write code to these interfaces without needing to reinvent the wheel. I'm not sure how well it'll work with your hardware - I guess it depends how it's put together and interfaces to your computer.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Oh yeah and Comedi supports a wide range of PCMCIA data acquisition cards that DO fit in a laptop.
There's two basic tricks I've discovered over the last couple of years of slowly incresing the use of open source platforms and tools in our research (ok, we do behavioral science stuff, but the politics of IT change are the same).
First, re convincing colleagues that open source / free software has a role in your work: do something they envy. Produce a tool they want to use, or find some existing software that does something useful and cool, or even just do the great unix thing of tying a bunch of small programs that do one or two things well together to do something that no existing monolithic package really offers. Then point out that it either can't be done on the current platform of choice, or, while it can be done, it requires spending $$$ on some proprietary solution. Doing something like this tends to legitimize the use of the toolset you'd like to use, and gives you a good foot in the door for more abitious moves later.
Second, re working with third party suppliers who don't currently produce software or drivers or whatever that work with non-MS platforms. If there's more than one vendor who supplies something that does what you want, pick the smallest one. They're more likely to be interested in finding niche markets, less likely to be bogged down by bureacracy when it comes to doing something new or different. And a three-person company is more likely to have two of the three who've recently been working in your field & remember what it's like trying to do the usual research thing of trying to get an existing tool to do something that no-one's done before - hence more likely to give you access to the kind of more detailed information you might need, even if they can't really expend the effort themselves right now.
Anyway, that's my take on 'what worked' after a couple of years of win-some, lose-some politics around research and IT.
I work for a Navy research lab and we use Linux, Perl, C, Apache, Mozilla, Gnome, Perl/Tk, GnuPlot, etc almost exclusively for our control and monitoring systems. We have had no difficulty controlling Opto22 devices, GPIB, RS422, R485, and one-wire devices. The only windows we use is on the desktop which is unfortunately mandated (see NMCI).
If you need real-time look into QNX.
BTW we operate what is probably the deepest running webserver. We have a vehicle monitoring system that is controlled via a Linux/Apache machine setting at depth reporting topside via fiber connection. This system controls power reports temperatures, pressures, inclination, depth, smoke, leak, etc.
imagine a beowulf cluster of clusterfucks of beowulf clusters of free research labs!
Repeal the DMCA!
I've been working with one of the Physics profs at my school (U of Rochester) for the past year, helping him update the software they use for cosmic particle experiments. We use a data aquisition board and particle detectors designed by FermiLab. The software runs on Linux, and accesses the DAQ board through the serial port. My job has mostly been adding a GUI to the program, so that the students running the experiments can concentrate more on getting results than understanding the weird command line interface for the program. For more info on the project, see the FermiLab page for the QuarkNet project, and the PARTICLE project page at the university.
We set up a small undergraduate research lab at the University of Manitoba's EE Dept. For the summer we are doing research in networking and telecommunications. All of our workstations are running slackware linux and we find most of what we need in this distro. OK, so this is slightly contrived (we're doing networking after all) but we rely big time upon iptables, tcpdump, iptraf, Sun's java, and lotsa unix utilities. I think people underestimate how many useful tools are in linux.
How do you check for a buffer overflow on a quantum computer?
I'm currently working for a small research group which is part of a particle physics experiment and we are running entirely on Redhat systems, using many excellent open source tools made available by CERN. In my experience, a Unix like environment works orders of magnitude better than a windows environment, especially when it comes time to automate events. I can't even imagine trying to do what we do in a windows environment. It would be an absolute nightmare trying to run most of the program we write.
There's no sig like SIGSEG
damn that's funny, debian troll. wish i had some moderator points. shame about these stuffy moderators...
My first choice is Delphi. I don't think I'd ever say Delphi is better at creating quick`n`dirty apps than VB, but I would most certainly say that it is completely on par in that area, with the added benefit of being much more powerful. (My opinions here are based on VB6 and Delphi5, which are the last two I used heavily before being liberated from Windows GUI work.)
The other alternative I can think of is RealBASIC. Their development environment used to only run on Mac OS, even though it could compile apps for either Mac OS or Windows. Nowadays, the environment itself as well as the apps it creates all run on both Mac OS 9/X and Windows, although I've never used the Windows development environment. I've only had limited exposure to RealBASIC, but based just on those few hours, I would highly recommend any fan of VB at least give it a shot--I know if I ever have to go back to Windows GUI work, I certainly will. (It seems it would especially shine for quick`n`dirty apps because it seems to focus more on simplicity and cross-platform rather than feature bloat.)
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
Why not use Gambas for the VB stuff in Linux?
There is only one reason to use managed C++ in .NET, and that is if you already know C++ or you want to bring in existing C++ code. That's it. If you're going to do .net development, and you don't know either language, there's absolutely no reason to learn C++ over C#. The only reason it's there is for compatibility. Also if you have a Java background C# will be much easier to pick up.
And one more thing, drop the elitism. Maybe VB isn't the answer to your programming questions, but when I need a graphical app done in a couple of weeks I can think of no better tool. I'm not going to restrict myself to perl or whatever language is en vogue with the free software community.
Does that mean that just having windows means that the job has been done?
M.
Ah, that's what my knee jerk reaction was all about. Discresion is the better part of valor. Use hardware that's got drivers already for new projects and use the old junk till it blows up. I presume someone will have sucess stories that I was only able to dream of four years ago.
I get ill thinking of VB. Learning C++ and the win95 API was easier for me. One week of happy brainwash VB training tape scarred me for life, "methods" twitch. I saved myself from that hell with a nice little "windows XX API how-to" book with examples and a watcom compiler. It made sense and offered greater control. MFC was required to talk to devices and it was a step in the wrong direction but control, display and communication modules were still seperate Others were lazy or stupid and spageti code VB was used on many other projects with horrid USB interfaces.
Good luck, you suffer a legacy of bad choices and are going to be forced onto VB. So you enter the downward spiral of the M$ maze, chasing mindless changes, befudled by tools that don't work the way they should and mysterious crashes, delays and poor data rates. You shall suffer nights of rebuilding win3.1 machines to take care of those old DA boards that don't have win2k much less XP drivers. If you can even read the poorly commented and ill disciplied spagetti code you have, you will suffer the pain of "porting" VB 4, 5, 6 to whatever is the current version, which might require complete re-writes to save time. Read letters to the editor in VBmagazine if you don't believe me. The more you learn, the worse it looks. Don't gripe too hard, the boss might have written some of that crap.
When it's all said and done, using a seperate machine listen to the device and learn how to talk to it might save you time. Selecting reasonable hardware for future project surely will save you time. Once you get aquisition working once you will be able to replace legacy stuff that breaks. The VB/disposable hardware route can hardly be called a success story.
Friends don't help friends install M$ junk.
In some cases, esp. where federal monies are concerned, law requires that if a commercial solution exists already that they be used over development of similar/same alternatives. So is the environment is primarily windows (or some versions of linux) then development with free software, where similar commercial products are available, can be illegal.
"Visual Basic [seems to be] the preferred solution for controlling the experiments"
all I can say it:
msgbox "EEEEeeeek!",4112,"Error!"
The Kruger Dunning explains most post on
I did a concise writup of the available solutions for using VB in Linux over at the linuxcult (linuxcult.com) site.. While the slashdot dictators didnt see fit to post it, you may find it an interesting read. It's entitled Basically Speaking... You can find it in an index over there....
Words are only yours until someone else uses them...
Really important?
Then get an MBA, study business and become the decsion maker at a large company. We must have people in those positions for Linux to really move.
You need to be playing golf with CEOs.
Most of you seem bright(at this threshhold) so I bet you can do it. Sure, you can't do what you love dureing working hours, but that is the sacrifice.
Besides, how much of your job do you love? If its like any job I have held, its about 10%. Which is all the coding and design I usually get. Most the time I'm in meetings, or over in QA exlaining to them, yet again, that it is there job to catch problems and send it back to the developers. The developers can not reasonble do an accurate test on a development box. that is why we do a 'development' tests.
yeesh.
sheesh
The Kruger Dunning explains most post on
I'm also doing Quantum Computing research, particularly, quantum error correction. I a program that simulated a the process of quantum error correction in terms of the Quantum state. That's rather inefficient, since you need a vector of 2^n elements to simulate an n qubit system. But after using that I was able to figure out when quantum error correcting codes are corrected, and then wrote a specific program to calculate those.
Here's the paper I wrote:
http://arxiv.org/abs/quant-ph/0209058
The /. editors are controlling what you see, and therefore what you think. Blog Slashdot!
ASP.NET is nearly finished, and there's already an alpha (?) ASP.NET server available for Linux here. Code new apps in as web-based services or in C#/Windows .NET Forms and port to GTK# or Qt# when ready.
That's the way we're doing it.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
I remember this same troll from a couple of weeks ago.
Get a life. Loser.
If the issue is convincing colleagues to switch over to non-conventional-Windows solutions, I would at least spread the word about Cygwin, which is a good switch over environment. It gives them a chance to use Linux (and assorted "free" software) on top of Windows.
I used to work for a company that did government contract work distributing radio frequency calculations, and we basically all had dual-booted linux/win2k boxes with Cygwin running on the Win2k side. Cygwin was where I got my walking-feet for eventually pursuing the use of Linux whereever I could manage.
As for Visual Basic...ewwwww! I work in an all Windows shop now, and they are all anti-Unix, for no good reason other than they are intimidated by the command line. However, using Cygwin (setting up your build system, versioning, etc), would be a good way to convert people slowly, and still be able to fall back on Windows-related development apps. The more I look around on the web, it seems like there's so many ports of popular, quality Unix development packages/apps to Win32, that the mythic oppositional relationship of WindowsVsUnix doesn't really exist so much. Everything's so hybrid. Have you seen all those jokes on Slashdot where people post about running Cygwin on top of Wine on top of Unix...etc etc...?!
I'm working in a lab doing "Quantum Chaos" experiments (manipulating cold atoms to investigate the difference between quantum and chaotic physics). We use the free (as in beer) version of RTLinux to run all our experiments, as timing is important and we didn't want to implement a hard real-time system. I coded most of the gui for the experimental interface using Borland Kylix and everything works quite nicely (apart from some evil memory leaks).
The real problem is the hardware - a real guru set that up for us. He wrote the "drivers" for the I/O cards himself (although that's meant to be a little easier in RTLinux than for normal linux) and also got a scientific grade CCD camera working even though the only linux drivers available were outrageously outdated. Sadly, we will definitely face some issues in the future if we want to upgrade to a new kernel!
Personally, I think the only way to move data files around is with a decent shell. Rename is perfect for all those times I put the wrong parameter in the file names of 160 different data sets. Most of the time our lab works quite smoothly with regard to the OS itself, and it's certainly an improvement on the old Win95/Scientific workplace combo of the past!
Seems like the moderators are on prolinux crack again. Not that I have a problem with Linux but a +5 for an offtopic subject? Come on.
I used to work (not too long ago), with systems that run Microsoft/SCO Xenix 286. They are still in service, and I get a consulting job out of them every so often.
The main thing is to control the equipment, and get the data out. Process it somewhere else. Don't waste your time or the vendor's time.
The time to specify things like OS and computers is in the purchase order.
We have developed a data acquisition and device control system in my laboratory (LURE - Orsay, France).
I work from 1997 on this project, it is an extensible system with focus on physical elements of the experiement (not on devices to realize the work) with a 'linear' view of the experiment, and with a (maybe complex) system to ensure parallel processing of tasks when it can be.
It is written with Python (so has no platform dependancy in its kernel).
It is on the way to be LGPLed (I does the legal stuff for that request and wait for the reply). More news in Python announce when (and if) I get a positive reply.
-- Laurent Pointal
I work for one of the larger visual effects companies, and from our direct experiences, and from what I know of our competitors, linux is now basically a given. Over the past 6 months, we have yet to talk to a vendor who doesn't have a package for both windows and linux, or has a concrete "in 3 months" type schedule for their linux product line. We just got a product demo for a new software package written by a startup company, and the 2nd/3rd thing coming out of the rep's mouth was "linux version in 2 weeks". That's an amazing contrast with the laboratory field, I guess - It's been amazing how much the studios have jumped on the bandwagon. To guess, I think a lot of that driving force is the general cost savings - labs that are less "profit"-driven have less incentive to try new ways of doing things, but the visual effect industry is so cutthroat, everyone's always switching to the next "great" thing, and right now, that thing is linux. Will it stay that way? Almost definately, but you never know...
Now, if only someone could beat the SCO guys with a clue stick, we'd be all set. I haven't had any allback yet on that crap (no senior management wandering over asking me for comments), but it's bound to come if there's any serious setbacks in the case. Here's hoping that IBM works 'em over.
Shurely with winelib you could compile a program that used the windows dll in linux... not too sure of the details, but I spose thats what theyre mailing list is for.
Almost the entire math department (i.e., the 4th floor of a massive building called Tech) uses GNU/Linux with Gnome for their research projects and simulations. Down on the ground floor, at least one lab is loaded up with GNU/Linux and IceWM (see Intro to EE lab instructions under the "Hardware" section), because they needed real-time responses while running some simulations and such. It's heartening to see my university using OSS.
-- Kurt
There may be (as always) technical solutions to this problem. But they won't touch the core of the problem: There doesn't seem to be a free market for scientific equipment. If you get a grant, you buy what you need. You don't have to care about the price. And that's why scientists will shell out incredible amounts of money to some company for a bunch of wires they could buy at Radioshack. I think that the same line of reasoning holds for the software scientists are using. As long as they do get their data they don't care about the quality or price of the software. They just use it. If the scientific community would be more aware of the kind of shit they are putting up with right now, they could force the companies that live of their money to do almost anything. Today, however, scientist are the most stupid flock of sheep you are likely to meet. Stupid software for incredible prices, and just think about the stupidity with which they publish their papers, granting publishers the right to hide their work from the public and sell it for (yes, again) incredible prices.
I've been doing instrument control for nearly 20 years. I have always seen better duplication of results from machine to machine with HP-UX, Linux, and SunOS ( even between machines running different Unicies) then I have with any Windows machine with itself.
control = embedded space (eurotherm or others for temperature control) ;-) but I couldn't care less) ;-)
log = whatever (chose labview...errr my boss chose labview
As an engineer, safety is one of the first things that should come to mind.
And in my experience embedded space provides this with much higher accuracy than any OS on any PC.
Ofcourse on Slashdot you read this extreme data logging things like over 6 months-extreme weather: to me those people did the right thing: linux-labview-comedi drivers.
But for logging-in-the-lab: anything goes.
e.g. log temperature and pressure every minute: we use qbasic-talking about cost control
No, we're not a russian lab...
For controlling motors and controlling through extreme high frequency daq: guess I would drop anything of the above and go with labview and the OS with the decent-driver-at-the-moment
This is going OT but is importand none on the less
Windows NT, 2k, and XP have different users as well but the internal access rights are different. Any program can access the registry in Windows no matter what the user priveldge is. Thank Windows95 for making this standard.
There I was typing away on a post marking you as a troll and then it hit me... You have been using regedit.exe on winnt based systems! Have a look at regedt32.exe, Done? You must have noticed the "security" menu on top. Here you can set full acl`s on every value or "directory" you want. All sorts of fine tuning options there. This beats the unix configuration system by like a hundred times on security. Its more complex (very bad in security land) but also offers great posibilities being able to limit acces to each induvidual value with an ACL with options (dis)allowing induvidual users (or programs run in their context) from querying the value, setting the value, creating subkeys,listing subkeys,"reporting","linking",removing, writing DAC data,writing owner and reading security info. (can`t translate them all from my localized version)Compare this to the crude all or nothing mechanism split by owner, one group and everyone else on a whole config file.Then add the fact that NT kernels have had full filesystem ACL`s (and remote filesystem acls) as well as basic mandatory acces controll (user rights policies) while linux has been strugeling to get even minor posix suport for ACL`s and has been doing nfs by default for a while now... And lets not forget the full acounting features posible on all of the objects with ACL`s on them in winnt.
Now dont get me wrong any OS that comes with a webserver that has had a plain dotdot bug in its filehandling (same bug in win95 remote filesystems) enabled by default is to be laughed at first befor being considered for use on the internet, but blame everything microsoft (office apps, "servers", scripting features, shell, manuals, patching policies, backward compatibility policies, monkey-see-monkey-do training, source distribution policies) for that except the security design of the NT kernel
[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is.
What exactly did they say when you asked? Have you made sure that they understand what you want to do? (Create a driver that makes the card work on linux, that anyone can get, potentially increasing the sales for the card). The key is to present the request not as "we need this" but as "you will get this if we can get that". They may still not be willing to help and then you explain that whenever you do the purchasing decisions you will prefer a company that provides specifications (or linux drivers). They still might not listen so you may have to wtick with windows, just make sure you remember who foreced you to it whenever you get a budget to buy new equipment.
- We are the slashdot. Resistance is futile. Prepare to be moderated -
You don't have to worry about Windows crashing. Decoherance amazingly is usually a problem before Windows would crash by itself.
I'm a Physics UG at the University of Oxford, and have done the odd part-time job writing code for some of the groups (I worked for CMP last year and will start in the Teaching Course next month). All of the code that I have written was released as OSS, because other research groups can then modify it and use it in their experiments, without affecting the originality of our work.
The systems I worked on in CMP were almost entirely Red Hat, and some of the code I had to work with was being ported to C/Linux from Delphi/Windows it was stupid to ask people to pay for Delphi licenses just to tweak a few lines of code in a detector controller. Some of the older computers were running Win95 with X11 and SSH clients and were just used as terminals for the beefier Linux boxen.
The computer I'll be using in my next project is a little meatier, a four CPU Sparc box. There are a couple of these in the department, each with a few dozen SunRays attached. The code developed on here will still be OSS, and the box has a fair amount of the GNU userland sitting side-by-side with the Solaris rubbish.
Other than that, my knowledge is a bit sketchy and is inferred through what I hear or see around the department. There are a number of Windows workies around, because software like SPSS or Origin or Minitab only exists on Windows, and there either don't exist Unix or Linux alternatives, or they aren't yet mature enough to want to switch onto. Many of these workstations also have Cygwin or at least DJGPP.
But the main point to be answered is whether or not a research group should be OSS. My opinion is yes as far as in-house code is concerned, because this facilitates collaboration between groups using similar code, hence quickly smoothing bugs. OSS also neatly fits the philosophy of shared information many scientists have.
Should the computers all use Open Source operating systems? I just don't think this should be a requirement in most cases. Yes Linux and the BSDs are stable and mature enough to be used in a research environment, but then so are Slowlaris and Mac OS X, and you can develop and build your code on both of these systems too. The only situation OTTOMH in which having an OSS OS would be directly beneficial is when custom-built embedded devices are required, for instance in HEP detectors or beam controllers. In these circumstances the ability to modify the OS kernel would be useful, but if you're just developing your C code in a Unix environment to be used on bog-standard Unix or Linux machines, then a good set of manpages and a functional cc is really all that's needed.
I wrote a program for a commercial researchers' data collection tool in LabView. Still shipping so I won't mention the name, but MAN did it suck. Anyone who's written anything in LabView can just try imagine writing a major commercial product in it. Try debugging pictures....lots of fun. Just stick with the bloody VB stuff. At least Basic was designed to do stuff. Delphi is pascal which was meant for teaching programming. If you really want to do stuff use Visual C++. At least it's mature and certainly has more people to ask for help than GCC. I hate MS, too, but I'm a realist. Stick with it. Suck it up.
Great for prototyping. Horrible for large projects. Try debugging nested loops. What a friggin mess. Anyone who suggests LabVIEW for anything other than a one-day project should be shot. I spent (wasted) 1 1/2 years doing a commercial project with it. Seems nice at first, but slowly you very quickly get diminishing returns from it. I'd rather do stuff in assembler. At least I can see what the fuck's going on. Optimization sucks because who the hell knows what NI does under the hood. Go with VB or C/C++ or ANYTHING before LabVIEW. Please.
I've had good experiences using Python + wxPython (wxWindows) for control tasks (and this was a few years ago, so the toolkits are more mature now). We were interfacing to a PCI A/D card and another card we made ourselves - the control side was hacked up as a C DLL, then exported with SWIG.
Granted, I did this more because I didn't like VB and it seemed cool rather than a free software thing, but it works well and I'll use the same combination again. This was on a Windows 98 platform, but only the control side would be platform specific.
However, using Python (which most people have never heard of) and wx can be hard to justify if people are looking over your shoulder demanding you use VB, so be careful.
Recently this went so far that I had a very candid talk with one of their sales people. I made it clear I would move to a different manufacturer if they would not provide drivers or some means for me to write them. He would ask within their organisation. Several days later I received an email titled "Solution to your GPIB driver problem". To my astonishment, it gave contact details for several other manufacturers of GPIB cards!
So, isn't this weird? They'd rather lose our custom than provide us with a driver, or sufficient details to write our own! And given the amount of stuff we are buying from them that's a pretty big decision.
So now we are talking with National Instruments, and they are very pleased to have us as customers. Moreover, they have Linux drivers for their GPIB cards. I haven't seen these drivers yet, and I sure hope they will be of acceptable quality.
I'm interested in hearing what experiences other people here have had with GPIB cards under Linux - especially those of NI, which we are about to buy. When you mention lousy Linux support, does that include their GPIB cards?
... and all I've got to show for it is this lousy Linux Journal Article
Although we use LabView on Windows for most of our low-level instrument control, we couldn't get through a single day's testing without Perl, Linux, and Apache.
All I want to know is why the fuck are the hardware makers so damn reluctant to tell you how to use thier products (as in write drivers for them)? Does Microsoft have that much of a stranglehold on them or is there some other consideration (such as possible appropriation of trade secrets or some other such nonsense.)
I was in a similar position...I was using Linux to run a laser tweezer setup in our small research group. Linux was such a pain - inconsistent libraries, poor support, flaky drivers unsupported by vendors, etc.
I switched to Windows 2000 Pro for the vastly superior support for data acquisition hardware, framegrabbers, and so on. Along the way I switched from doing GUI stuff in wxWindows/C++ to Matlab. The GUI stuff in Matlab 6.x is pretty good. It's got a bigger learning curve than LabView but it can also be used to implement much of your data analysis as well, with its vast libraries of mathematical functions and decent performance.
With the new hardware coming out, our lab now has a standing policy to only purchase items with USB or FireWire interfaces whenever possible, so the PCs don't even need to be opened up anymore. These drivers are rarely if ever available for Linux.
Use whatever makes your lab the most productive. Standard lab software like LabView, Matlab, and Mathematica are a safe way to implement software since they're so popular and they're more efficient and productive than C/C++ or VB. If you need high performance computing, then go consider F90, C++, etc., but instrumentation should never be controlled like that. You need real time? Buy a real time board.
People would have you believe that to develop GUI applications in Linux, Qt is the way to go. But what they don't mention is that the Qt library is unstable and has no support (for the non-commercial version). So if you have any problems like I did you have to fix it by hook or crook. Better to switch over to GTK.
...as does IGOR, which someone else mentioned:
LabVIEW
IGOR
I HATE GPIB. I loath it. I am forced to support GPIB when my project has a perfectly good Ethernet port.
/dev/gpib interface that you can select(), poll(), and such on.
National Instruments has a "driver" for their cards under Linux, but their "driver" does not do things in the One True Unix Way - the driver is more of a shared library you link against your program that provided a slew of functions to manipulate the card. What it does NOT provide is a
I would ask this: if your goal is control, why not use TCL/Tk for the control? That way you get an environment that your end user (the scientists) can play around in without edit/compile/link/curse cycles. You also get a degree of portability.
Yes, the problem is that most hardware venders do not provide a lower-level programming model - a) because they are afraid of the competition cloning their board and b) because most folks developing software with them want a LabView|LabWindows|HPVEE|DCOM interface.
However, there is a small ray of hope: the government JTRS (Joint Tactical Radio System) (the new software defined radio standard The Men In Green are wanting) uses CORBA to do all the module communication. Now, if we could just pursuade industry to follow that trend! I'd love to provide a CORBA interface for my network enabled device, rather than the current solutions!
www.eFax.com are spammers
I work with a research lab and we moved a lot of stuff to linux but we had to write a lot of SW on our own.
One magic is the use of ascii for communication and data. We also created a pcb with a MC on it that dumps data (our raw data are mainly counts) in ascii. Attach it directly to a monitor ; it solves a lot of problems.
For display we use plain old X11. Strong learnig curve but VERY powerfull if mastered.
We had also some comercial prodructs but they were generaly a disapointment.
"My lab is researching quantum computing, and I don't like the fact that Windows / Visual Basic [seems to be] the preferred solution for controlling the experiments. It's not just a pride thing, unlike many colleagues I know what I'm missing out on, in the free software world."
Quantum computing with VB? Are you ripping the piss?!! A pride thing? Nice troll. I think you'd better hurry back to CS101.
I am a physicist at Vanderbilt University, in the Free Electron Laser Center, who has been doing various kinds of distributed data acquisition and control for about 25 years. I have run into many of the same problems with closed interfaces the author describes, and am slowly developing a strategy to minimize the impact of this problem.
First, I try to avoid products which depend on a closed library/DLL/whatever to control them. This has resulted in my shifting away from a lot of PCI-card devices to (when possible) external devices which communicate via GPIB/IEEE-488, rs233/422/488 interfaces, USB interfaces, network interfaces and (I hope soon) FireWire/IEEE-1394 interfaces. For such devices, one can often find programming specifications, although not always. Obviously, using the slower interfaces may result in lower performance in high-bandwidth environments, so it won't always be an option. However, the fastest current IEEE-1394 looks very promising, as it can support speeds that only a few years ago would saturate a PCI bus.
I have also discovered another interesting phenomenon: 'hidden' standards. In the past year, I became aware of a little-advertised standard, VXI-11, (www.vxi.org), which is a protocol for communicating with GPIB-like devices over TCP/IP. Although one almost never hears about it, a lot of devices support it. Tektronix and Agilent Infiniium scopes use it, and Ethernet-GPIB converters from Agilent, Tektronix and National Instruments all use this. The protocol is open, sunrpc based, and quite easy to implement. However, each company hides any reference to it deep inside the documentation, and basically provides their own Windows dll for communicating with their devices. The Agilent E5810 Ethernet-GPIB converter (a very elegant box) even calls itself a GPIB-LAN interface for Windows, as its official product name, even though it is almost fully VXI-11 compliant and can be used from any platform. I have no idea why they actively _hide_ its cross-platform compatibility.
<slight advertisement> I am trying to address some of these issues by releasing a lot of the code I am working on to interface various devices. I am a python fan, so I have a sourceforge project PythonLabTools which is a library of open-source code to implement communications with various types of devices which are effectively GPIB devices but run over the net via TCP/IP. I am also adding other classes of interface support to this library. An example is the Verinier Software LabPro, a low-end but quite nice and inexpensive a/d, d/a, and digitial i/o box which communicates via serial and USB. There are also data analysis tools in this package (fitting, et.c), and support for the National Instruments DSTP protocol, which allows LabVIEW to share data over a network, and (in this case) allows a Python program to directly interact with a LabVIEW program. This allows separation of the fancy user interface capabilities of LabVIEW from more intensive data analysis which can be executed in Python. <end advertisement>
I am looking forward to a day when more and more external devices with published interfaces become available. Internal devices (PCI or whatever), of course, take a lot of work to make drivers, but since communications with external devices can be carried out in userland, they are easier to provide cross-platform support for. I am alos watching as bandwidth on external interfaces rises to the point where there may not be any need for internal cards and the hassles they create.
I spent a fair amount of time a couple days ago lobbying our National Instruments representative for opening up the interfaces to more of their devices, especially their FireWire/1394 based products, which are right now only supported on Windows (which _really_ galls me, since Apple and Sony spearheaded this interface!). We are a fairly significant customer of theirs, and I think they actually listen.
Speaking of NI, some labs I've worked with use LabVIEW. Yes, its prohibitively expensive (especially compared to VB) but its spectacular for scientific RAD. Plus, the programming is wholly graphical, which should be refreshing to those scientists that have no experience with text-based programming.
An opensource group would do well to attempt some sort of "workalike" to the language - the ease-of-use is stunning.
That being said, part of the reason it is popular is that instrument companies are pretty good for providing drivers for LabVIEW. An open-source project would lack that unless they also implemented their driver system, which would probably get that project in big trouble.
At least it sounds like you're starting to get some work done, which is a good thing.
"[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is. Who could blame them? Their Windows DLL is the perfect solution under [most] circumstances.
"Very upset"? Really? Did they yell at you? "Who could blame them?" Why do you think the response you received is related to their use of DLLs? Do you think there is some sort of Microsoft-lab equipment conspiracy?
First, I don't believe anyone got "very upset" at you for asking. Second, perhaps you should consider it from another point of view. It is possible that the equipment you are using is more complex than just reading a register to get a value. Perhaps there is software processing required to extract accurate data. These companies live and die by reputation - if their products don't produce research grade data the companies are out of business. Then up walks Joe FreeSoftwareIdealist who thinks it is just a matter of reading a few registers. Let's say they give you what you want and you botch the implementation of the driver (do you have time to test your software rigorously to ensure results are repeatable and you are getting results within the specs for the equipment?). Not only is the research wasted but the company runs the risk of looking like they provide unreliable equipment.
Using the software provided with the equipment removes an unknown from the work, and that's a good thing. Your first allegiance should be to the research and what's best for the work at hand. There is no "conventional wisdom that it's OK to ignore your ideals, so long as you get the experiment working", just conventional wisdom that without good results you are nothing. Pick your battles, and if this is so important to you go elsewhere.
Here's another tip. You wrote, "Has anyone had any *positive* experiences..." Why don't you want to learn about cases where people have failed? Given the vague whiny description of your problem (you don't even list the equipment used in the lab) it is highly unlikely that anyone's postive experience will help. You are far more likely to learn from the failures of others in this case. It rather sounds like you just need some hand holding or a hug. Ok... [[[[neurotensor]]]], you go boy!
I have been working with Kmax for as long as I can remember... It is platform independant, Java based data acquisition software that allows you to build graphical toolsheets to interface with many different bus types. It can talk to GPIB, CAMAC, VME, and any other bus that you can write a JNI driver for. You can get a free version of Kmax at Sparrow Corporation, and I think the only thing that is disabled is the Save feature...
From my experience, Kmax has been the most versatile data acquisition software I have ever used. The way it is designed, if you want something more, just write your own KmaxDevice or KmaxDriver (interfaces are documented) and you're all set! It even has options for remote connections over TCP/IP for client-server connections, useful if you want to take a look at your data from home or if you feel like changing some parameters without walking down the hall and mucking with your racks of equipment.
-EowaennorI work in a research lab at a very large research university ( > 45,000). We use almost exclusively open source software. RH 8/9 is the order of the day for our OSs. We rarely have to control any custom or obscure hardware, however (we do research on networks and security,hardware evaluation, and virtual teaching techniques). This is neither here nor there; the real key to success for any research lab is technically skilled slave labor ( == graduate assistants)!
Don't become a regular here, you will become retarded. -- Yoda the Retard
Not sure what protocols your company uses, but at my company, nearly everything is GPIB controlled. Most stuff in the past was either done using LabVIEW or manually - In my lab it's almost all Perl these days thanks to me.
http://www.mock.com/gpib/ has an excellent library for GPIB in Perl. It only supports older equipment, but at least in the GPIB world, nearly everything has a published command set, and the library makes adding support for other instruments extremely simple. (I have yet to find an instrument that didn't have detailed programming info. It takes me an average of an hour to implement most of the funcionality of a new piece of equipment. Sadly, the work I've done on that lib will most likely stay in-house.)
Now if only Octave had the external interfacing capabilities that Matlab did. (Even with some of the "Matlab compatibility" libraries like octave-forge, Octave is still missing a ton of signal processing toolkit functions like psd() - Octave will also not interface with any of our digital I/O cards). Even Matlab under Linux won't help us here.
In short: We've basically replaced LabVIEW with Perl here (to much rejoicing - People at this facility are more familiar with text-based programming than GUI programming.), but I don't forsee us replacing Matlab any time soon.
retrorocket.o not found, launch anyway?
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...
Yeah, if I worked as an application engineer for that company I definately want a phone call from you ever ten minutes "hey this doesn't work right... how do I do what your software already does?"
See, they *advertise* the cards and hardware as what they are... They work, they have windows libraries. If you don't want to play by the rules, don't buy their hardware. But don't buy the stuff, then give the poor people who work there a hard time because you're a nutsack.
Call them up, "Do you have FreeBSD/AmigaOS libraries for your product?" "No, we don't" "okay, I will find a product that does". If enough people were calling them with that, they'd be making FreeBSD/AmigaOS libraries for their hardware.
I would have thought it much more productive to invest your valuable research time on the task at hand, rather than change your software for what appears to be aethetic reasons.
gnu scientific library
and
gnu plot
Absolutely killer apps !!!
not just a pride thing, unlike many colleagues I know what I'm missing out on, in the free software world
Like what, for example? Under Windows you can run Emacs, Vim, Perl, Python, Ruby, etc. You can get bash or another UNIXy shell if you like, and all the same command line tools. Putting together GUI interfaces for little tools with Visual Basic is a *great* idea. You could use something else, of course, like Tcl/Tk, or a free VB-like system, but VB is very good at what it does.
Reliability isn't an issue, if you're running Windows 2000. I have never had a single crash doing heavy software development under Windows 2000.
To me, it sounds like you just want to avoid Microsoft and Windows at all costs, but you don't have a real reason. In fact, you're even attempting to move away from the OS that most of your peripherals are designed to run under. Very strange.
At PSU Physics , we use a variety of OSS for research. Most notable is our computing cluster which runs particle simulations and such on Linux. I'm unawae of any who have reversed drivers for their instruments to run on OSS in my department, however many researchers use PERL to analyze the results.
- about me
I am maybe in misundertsanding.. but i always diapointed when i see people trying to solve the problem, but not once analyise the real problem.. :) )
:)
(maybe i just say it because i just see the matrix 2..
But when i read this article, i was wondering.. are you talking about the problem? or only a problem.. which is not the real one..
I mean:
You're talking about what kind of software, os, and so on you need, or laud, or can use for your projects.. but wait a bit..
don't you sould fisrt.. before anything else.. plan your system?? I am not talking about os, i am talking about system which is designed for your company, for your projects, for your emloyees and so on.. Or do you think is it harder to make, than a tools for a choosen os? or an extension for a tool??
So i think, first you should think about a system, make it realy clear.. and simple.. and if you can write it down, than you can make it..
And if you reach that point, you can select the perfect os, tools, or people who can write to you what is not have in the market.. or configure one of them..
I first give time to make a good, and easy managed system for my work, and than I started to work inside of that.. and it is realy dosent matter, tools are free or not ( until I have enough money.. ), becasue I WILL NEED EXPERT to the job, project, system, and so on..
Finaly, if you know what you want.. i mean if you know what is your perfect system of your job/projects/company, you can easily find the tools, or EXPERT for that.. and the chippest way always the "first looking expensiest"..
So get as many experts as you need to make a system which is the best and simliest, and of course the "long time chipest" , and make tham.. after all.. you can be very very effective
OR NOT
There is only one good solution: The simpliest!
You are right. The same thing happens with automatic DNA sequence machines. Applied Biosystems (AB) sells the ABI sequences line with a DELL (with flat panel monitor!) with WinNT. The Windows has ServicePack 5, and they (AB) tell you NOT TO UPGRADE it to SP6.
There is also a training course, and basically they explain that if there is any error on the screen, just reset the computer! (that is their troubleshooting procedure).
DNA in your Linux: DNALinux
I think you're really attractive. Would you go out with me?
Sure movies such as Real Genius, have science being used in the wrong way and most people would say that it is wrong. But even Richard Feynman saw the possibilities of the knowledge gained at Los Alamos. He even had patents on nuclear powered aircraft.
The way I look at science is that it should be done for the pursuit of knowledge. Wasting the resources, such as grant money, becasuse you don't like the philosophy behind the tools (which happen to work) is not a productive thing to do. If it were a simple task, sure why not, but it sounds like you are wasting lots of time and money for an altruistic goal, that doesn't really matter.
And on another note, if I had built the hardware, and provided the software tools to access it, there is no way in hell I'd turn over the specific hardware details. Once the product has been EOL'd then I might but not a minute sooner.
I'm an astrophysicist in a non-profit research institute. We have very few 'special' hardware requirements like the poster, and so are not as limited by what OS hardware vendors are willing to support, but I've come across similar situations.
When it comes to proprietary hardware with proprietary drivers on a limited number of (non-free) OSes, you're stuck. Everytime you talk to the vendor, or the support staff, you need to ask them about Linux (or BSD, or whatever) support. Be the bee in their bonnet that gets them thinking about supporting other operating systems. They don't necessarily have to GPL their software and drivers (I know, sacrilege!), but the ability to use your hardware on Linux means your one step closer to moving the lab over to Linux. Also, even if the data-acquisition is on, for example, Windows, that doesn't mean the data-analysis has to be on the same OS.... (Unless the data format is proprietary =8-( )
However, being a researcher, you should be used to the concept of peer-reviewed publications: nothing is published in established journals without having being scrutinized by other researchers in the same field. The same concept applies to OSS: open source software, at sometime in its public life, is viewed by enough people that bugs, cheats, etc., will probably be caught (things slip through, as they do in the scientific peer-review process, but the idea is sound). If you're doing research in the uncharted regions of physical science, you can't expect that someone would have written all of the software you need to get there and understand what you discover. This means that you, the researcher, are obligated to write the software. This software should be open sourced and peer-reviewed, saving your collegues and other researchers the same headache. What is done in scientific research is often governed by the 'publish or perish' doctrine. But keep in mind that what you publish might not have to be scientific papers: if everyone in quantum computing labs around the world knows of or makes use of your software, you will have more exposure than publishing a few obscure papers.
Also, despite the fact that you might be analysing unique data, I would hazard to guess that large amounts of the mathematics and statistics you would be using are not unique. Save yourself time when writing your software and don't re-invent the wheel: use publicly available mathematical and statistical packages. There are enough out there that I'm not going to bother giving URLs...
I look forward to seeing your project (not in VB or C#) on sourceforge =;-)
(Oh, and when your Windows-bound collegues ask about using your software on their OS, you can say "Sorry, it's only supported on Linux." That'll make you feel better, trust me =8-)
#include "cunning_plan.h"
Oh, that I did not know. I stand corrected. :)
I am sure that you know what you are missing out on by not using OSS software personally. However, have you thought about what your lab is missing out on or would be if they moved. Bear in mind as you read this, I am a Linux user and this is not a flame.
In a research lab statistics are important. You probably use JMP, Matlab or some other large stats package. Their is not yet one in existence on OSS. If there were, there would not yet be a talent pool familiar with that software.
By coding in visual basic, they assure themselves that even if you leave they can find a lot of programmers to work on your project. Look at a directory in a major city for vb developers and then find someone (with a talent pool of more than 2 guys in a basement) advertising GCC development.
The fact is that significant development dollars will not be spent on OSS until an OSS OS (like Linux) has much deeper penetration into your work environments. Unfortunately, those uses are what would gain it that penetration.
Try these site for linux gpib drivers http://pcitco25.cern.ch/SI/lvbv/lvbv_drivers3.htm http://linux-gpib.sourceforge.net/
You don't have to be smart to use a Mac, you just have to be smart enough to buy one
Proprietary software has been compared to a cathedral, but in some sense, OSS has become the new cathedral, while proprietary software is the new bazaar. Look at this case. A researcher is wasting time trying to reinvent the wheel using open source to solve a problem that has been solved with proprietary software. I understand the advantages of OSS, but I'd like to point out that he seems not to beinterested in modifying soure code, as was Stallman's motive, but instead wants to use OSS for it's own sake. This is like a cathedral in his "worship" of OSS that leads him to want to use it despite the fact that it's more diffiult. On the other hand, proprietary sw vendors want to write and sell software that works "good enough", a bazaar (free market) style approach, and makes them some money in the process.
Vote for Pedro
Barf, that's all I can stand and I can't stand no more.
I feel your pain and I'm not laughing. It sucks that you are faced with such problems for something as simple as stepper motor control. You can at least avoid VB and learn C. If you can't get $2,000 bucks for labview, you can at least use the manufacturer's C code for control. Almost anything that has a VB thingy will also have DLLs and tell you how to link to them in C. Start with simple command line interfaces that read files to do your work and stick a VB face on it if you have to. On this project you are stuck with dinky hardware. Good luck and get going!
Friends don't help friends install M$ junk.
I work at a biotech where Windows is the platform on every scientists desktop. Additionally, all the software provided with the instruments (plate handlers, HPLC, Mass Spec, NMR, etc) is Windows DLL/ActiveX based.
Python is a great solution for mixing open source development tools with Windows based vendor tools. All of our applications are written in Python using wxWindows as the GUI toolkit. Most applications use 3rd party ActiveX controls. We have had no problems integrating these with the open source tools.
Python also has the advantage of a very powerful scientific environment, SciPy and Numeric, both of which we use for all our data processing.
The one caveat is that occasionally a little C/C++ hacking may be necessary to work around COM issues. In one instance, I did have to implement a COM method call in C and call it via a Python function (eg, callCOMMethod(comObj, args...)). Also, for performance reasons, a little C hacking can be useful when dealing with large data sets.
-Chris
Jones on stepping motors found via google
Seems like stepper motors are not that difficult to control. A simple darlington transistor, resistor, and diode are all that's needed for the driver, for the control circuitry I suggest Atmel AVR microcontrollers, some of them have built in A/D etc, they're cheap, and they are programmable via GNU C compilers available under linux.
Get a Dontronics rAVeR to run the control circuit.
An AVR running at 10 mhz gives you a lot of processing power, and plenty of i/o to step 2 motors forwards and backwards. The main question is how to tell the AVR what to do.
It depends on how complicated your control algorithm is, ie. do you just need to run through a set of rote steps, or are you doing feedback control, or responding to the outside world?
If you're doing feedback control, then get an AVR with A/D channels built in, if you're responding more complicatedly then perhaps use the sound card output of your computer to tell the AVR what to do?
Admittedly all of this is likely more trouble than installing windows and writing your software in VB, but once you've done it, you've got a system that you can have some control over vs. an off the shelf solution from a non-responsive vendor (ie. there's not necessarily a guarantee that the thing works all that well under windows either)
Plus, with this kind of experience you will rapidly find other uses for a general purpose microcontroller platform, you'll be able to bypass buying expensive proprietary PCI cards and build some of the simpler control systems you need yourself.
NOTE: if you're building things yourself you have to deal with debugging the hardware and the software. Keep focused on the cost to benefit ratio of doing it yourself vs. buying off the shelf. Remember you're trying to do research, which means you need the flexibility of do-it-yourself, but you've also got a hard enough time doing the research, so adding hardware design and debugging on top is added hassle.
Getting an undergraduate electronics engineer to work with you for work-study credit is probably a good idea.
((lambda (x) (x x)) (lambda (x) (x x))) http://www.endpointcomputing.com a scientific approach to custom computing.
A computer, it's OS, and the software that runs on it for controlling, recording or analyzing your experiments are just tools. Not socio-political icons, symbols of oppression, freedom or status.
What you run in your dorm room might be. What you encounter in school or at work are not. You will live longer and go further if you learn that using the best tool for the job is the best way to get the job done.
I've got some experience with this. I work on medium-scale (i.e. 100-200 collaborator) particle physics experiments, and I've built and used smaller test-bench apparati as well. I always perfer to use a linux-based system.. if the hardware allows you.
That's the bottom line, of course: if you're going to go the Linux route, you have to buy equipment that you can talk to. Your job, of course, is to get research done. Frequently, the best case is to go ahead and use the windoze solution, export your data file and do your processing on whatever platform you like.
That said, I've had some reasonably good experience. You can use linux to get a CAMAC or VME-based data aquisition systems if you're willing to do the hacking and have the right interface board, if you're doing high-throughput stuff.
On the low end, like running a stepper motor or reading a simple device, the serial port is your best friend. Although it sometimes requires much hacking to get more than two serial ports working, you can do it, and most low-tech equipment can be accessed through a serial interface.
The great thing about using linux is that you can write in whatever script or language you want with whatever front- or back- end you want. You can output your data direcly into the analysis format that you want, rather than having to do things like export and massage and import and such. (This is important if your little test stand is generating gigabytes of data a day!) You can do stuff like imbed a simple version of your analysis for prompt feedback. You can use well-established tools to do your I/O (our system is based upon ROOT ( http://root.cern.ch ) which has some nice features if you're doing lots of ntuple-based data.
The problem comes if you find yourself needing to talk to USB or, even worse, a card in a slot somewhere... here, you're likely to get creamed. Five years ago companies would often ship products will a full technical description, but now they're just too lazy.. even if you're willing to do all the leg work, they can't be bothered to document their codes and data structures for you.
So: if you have the option, it's really nice, but be prepared to do a lot of work to get some badly-documented things working, and give up if you just can't find the supplier.
I don't have enough time to explain the abstraction between an application layer and an OS, so I've just showed the mods reply to my boss at the Imperial College biochem labs. He laughed. And laughed. And laughed.
Then he told me to stop posting to student-run websites (and do some work).
I'm going to take his advice.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
As one of my professors put it once, "I don't know what you would do with Windows at an accelerator." We're running entirely Linux, except for some Windows when we're developing hardware (which leads into the next point...)
The problem is not hardware manufacturers providing drivers for only Windows; the problem is that they provide only drivers. I know an undergraduate in astrophysics whose lab job is to fight companies for their specs and implement them on linux (that lab recently switched entirely to Debian).
So, as an answer, large parts of the physics community -- and the math community as well -- run unix. Often a lot of stuff has been written, especially for things like CAMAC controllers.
You might have a look at ROOT (http://root.cern.ch) as an example of a major project in high energy physics which might be useful. You can use it to write the quick and pretty interfaces, and you can link in libraries and drivers to access hardware. A lot of places use it as their experiment control tool. No FFT, but I hacked FFTW onto it in about an hour and half, including learning how to do it.
Python and glade ? Don't know much about but VB does the work and is easy.
Some microsoft products are good like office(pricey but good) and developer tools.
Hey have you noticied that Sam McGee's message board is all messed up lately? The 'latest' page on the Chile Garden Forum shows messages from 1998. :-/
I forget...are we at war with Eurasia or East Asia?
The Navy Research Lab Sucess Story
Friends don't help friends install M$ junk.
Au Contrere, my silly AC frere. If you got stuck with some fancy device that only works in windblows, the least you can do for youreself is learn to use it's C interface. Almost anything that has a dumb VB interface also comes with one that works with C. While VB works for M$ and only M$, C is everywhere and a much better thing to learn. All VB can add for you is a dinky interface and loads of heartache and rewrites.
Lab view might be useful, but real labs don't hamper themselves with vendor lock in nighmares like VB.
Friends don't help friends install M$ junk.
I've never known a mathematician or physicist
who didn't use Linux or a Unix variant (like
Solaris). The same goes for theoretical
computer scientists.
San Diego Padres, 100 Park Blvd, San Diego CA 92101
It is pitch black. You are likely to be eaten by
I have used linux for many years now, and the only reason I still keep Windoze on any of my computers is so my son can play his games. Even for Windoze-only supported hardware, I use Win4Lin, available from netraverse. As long as a program does not use the DirectX drivers, there are very few programs that fail to run through the Win4Lin environment. I have several oscilloscope cards and various hardware that is not supported outside of Windoze, and they all seem to work just fine. Win4Lin just released version 5. I've been using version 4, and have not yet purchased my upgrade. For the price, this is an excellent product. One great advantage is, any files used in the Win4Lin environment is available in the user's $HOME/data directory (or however the drive is mapped - see Win4Lin documents), so these files are immediately available within both the Win4Lin environment AND the linux environment, even simultaneously!
For any manager to claim that free software is not worth the time or effort, I'd suggest you tell him/her that by the same logic, your time and effort is clearly worth a raise! They obviously have money to burn.
As a reminder, most linux software is coveres under the GNU Public License (GPL) and "Free software" does NOT neccessarily mean "free of cost." Visit the Free Software Foundation website and follow links. There are many excellent links that discuss how to deal with people who only believe that, "you get what you pay for, and free software is worth what you pay!" Such beliefs are foolish and quickly becoming outdated.
But that'sjust my opinion.
seriously ... use it and quit complaining
I'm working in a national research center associated with an ivy league university, and we're using Linux and Python for data acquisition and process control in 'my' spectrometer development project. Python is extremely flexible and interactive, allowing us to create/modify experiments and visualize data immediately. I can also do quite a bit of data reduction and initial analysis right in the lab.
Slower GPIB hardware is accessed via the GPIB driver by Jens Toerring, and some custom hardware is currently controlled via the parallel port. We use 1GS/s PCI-based digital averagers from Acqiris - Acqiris not only provides (alas, non-open source) Linux drivers, but so far has also been quite helpful with respect to getting things running. We are planning to replace some of the current hardware with a VME system (running Linux on m68k) which is linked to the main computer via ethernet.
So far, the system works better than I dared to hope, and I'm pretty sure commercial integration tools like LabView would be much more cumbersome and much less flexible. I'm pretty certain that it was the switchover to this environment (from an earlier CVI based Windows solution) which enabled us to get the spectrometer operational in record time.
I'd also like to point out that the "research grade" commercial spectrometers from one of the major players in our field have been switched from Irix to Linux recently (Windows is used for the low-cost "appliance" models).
While certain big players in the data acquisition field have subscribed to "any operating system as long as it's Windows" in the past, I think they are now realizing their mistake. Multi-platform support is rapidly becoming an important buying argument.
On a side note, our theory group members who are doing simulation work -- all primarily Windows users -- have indicated recently that they'd prefer a Linux based cluster to get their number crunching done. They don't want to use our university's Microsoft-sponsored Windows cluster-based "supercomputing center" any more because of permanent reliability issues...
"My lab is researching quantum computing, and I don't like the fact that Windows / Visual Basic [seems to be] the preferred solution for controlling the experiments."
In related news Iraqui people found to have WMD, and I am running a nuclear plant over my Windows Pocket Edition. Sure.
--
No my sig is not a troll.
In a perfect world it would be a part of your requirements that you can release ASIC register data to customers. If they insist on a NDA, then you find a different supplier. In your world where customers are requesting that data, customer service requires that you provide it.
Of course I understand the world isn't perfect, if there is no second choice for a ASIC, or the second choice sucks in every other way, there is much you can do. Add in general office politics (joe in upper management doesn't like foo, so we won't buy their stuff) and it is hard. Still you should insist that purchesing have a line item "All chip programing (register) data nessicary to interface to this chip can be released to our customers." It is a simple item, and it might be negociated away, but you should get a break from them for getting rid of it if nothing else. (and when salesmen say they are having a harder time getting a deal because of this issue things will change)
I'll answer your question as soon as you answer my question: why are you writting an app that you will throw away?
In most cases the answer will either lead directly to my reason to write the throw away GUI, or I will agree it isn't worth it.
Reasons to write a throw away GUI: a prototype used to demonstrate it to management before the a lot of decisions have been made. A prototype used for human interface testing so that the real GUI is useable. A program that will be used for a couple days by many people and then thrown away. To prove to yourself that you can write a GUI just as easially as a CLI, or you think it is easier. (with the right toolkit GUIs are not hard to make, and input checking may be easier)
wondrous google is.
http://www.google.com/linux?hl=en&lr=&ie=ISO
gives...
seismologists' tools on linus is: http://www.seismo.unr.edu/ftp/pub/ichinose/LINUX/
A cool article about an linux-based instrument for use in U-2 spy planes.
http://www.linuxdevices.com/articles/AT6
A linux journal article about linux in a lab.
http://www.linuxjournal.com/article.php?sid
which, in the resources link, includes a link to
the "Scientific Applications on Linux" page...
http://SAL.KachinaTech.com/index.shtml
I don't really know that much about computers but...
why can't everything just work through usb or some sort of nuetral interface? Then there would be nothing special about any hardware, it would just all use the same input/output.. very easy to write software for.. right?
I would have expected by now to see a LabVIEW open source clone. The problem such a product might have would be similar to our considering IGOR. It looks good, but the investment is big when we already use LabVIEW, and if other groups with whom we want to collaborate use LabVIEW...well, ya know.
A common thread here also seems to be the interface protocols. NI is supposedly getting away from boards in their devices to support connections, and might rely more on plug-in cards separately purchased. These changes are good if you're just starting out, but they do create a legacy for running labs that require stable data acquisition and processing to meet a milestone.
We watch the COTS and RTC journal for open source developments. Some of it is out there, like a Matlab function that requires Mozilla, and the government does seem to be generally interested to investigate this route of open source.
If it's just DLL's use wine!
Hello. Sorry, no time for registration. However, I have used NI LabVIew extensively to control Data Acquisition cards, and GPIB. I had also at one time asked them about Linux, and got a so-so response. HOWEVER, last I heard, NI had finally released a Linux version of LabView. Now, granted, LabVIEW is not cheap, but it includes all the software you apparently would need for your control applications, and if NI supports it on Linux, you shouldn't need any Win based crap software.
Also, I agree with the guy who posted about Win2k - MUCH more stable, you should definitely consider switching to it, if you don't go to Linux.
Regarding your comment that emails to NI don't even get a response, I find this to be Very odd. Typically, I call in, and I've found NI tech support to be one of the most responsive (of course, I'm usually asking them questions about things they support, not how to use a competitor's product with one of theirs, etc.)
I would really really recommend you think about using Labview, you can get a free 30-day eval (fully functional apparently) version by going to the website www.ni.com. I don't know how great their Linux support is, but you should be able to tell quickly enough, since LabView is their flagship product, so it shouldn't take so much investment on your behalf. And if you do, please post on your findings, I would love to know how test and measurement and control apps work with Linux.