Guide to lab automation? GPIB/computer interface/labview stuff - Page 1
Forum section: electronics / general

author: ftransform
author_rank: Frequent Contributor
timestamp: October 27, 2012, 05:49:06 am
content: So I own several instruments which have the capability to connect to computers.My rigol oscilloscope and a keithly 199 DMM + other DMM.I was thinking that I should focus on buying instruments that are computer compatible.. so this may be a factor in my next power supply purchase.Anyway, how does all of this come together? How could I say for instance save the readings from the DMM's every X time, screenshot the rigol every X time and perhaps even vary power supply voltages?I read many adjustable power supplies come with their own software....And the keithly I have does not even come with any software, it looks like I would have to buy a GPIB card, and then create some kind of custom program to interface with it.Would a setup as I described require me to cobble together a solution by running like 4 separate programs that output into separate log files and make a macro-express script to screenshot and save the oscilloscope read out? Like, my agilent would have to hook into a serial port, my keithly into a PCI GPIB card and the rigol to USB...Is getting a automated "testing solution" as difficult a process as I imagine? Having to write custom programs and scripts just to get some data makes using the setup extremely tedious.I have heard of lab view software, but is it worth for a hobbyist to investigate? Would those GPIB->USB solutions work with labview? Like the one being sold by a member here for 60$Could I just say buy a PCI GPIB card for 60$ and then plug in my keithly 199 into it and have labview just... work?Or maybe hook up a motorized trimpot to a microcontroller which can interface with the computer through a serial connection and have a computer controlled resistor with minimum effort to interface it with labview?

author: free_electron
author_rank: Super Contributor
timestamp: October 27, 2012, 10:24:22 am
content: Simply install Visa. Either NI or Agilent.visa is free as in gratis.They give you a dll that you can open from any programming language.It doesnt matter where your machine sits. Usb , lxi ,vxi,pxi,mxi, gpib , serial, printerport.You connect with one call and you have a read and write operation. The rest is peanuts. Almost any machine out there uses SCPI as a commandset. Plain human readable text.Simply send a command like :meas? To a machine a nd it returns a measurement.: volt 10.2 to a power supply will set its voltage to 10.2. These commands are found in the user or programming manuals of the machines.To open a machine on a gpib bus you send ::gpib0:15 to the visa driver. The driver returns a handleMymeter = Visa_open ("::gpib0:15")Result = Read (mymeter,":meas?")Mysupply = visa_open("::usb:vid_0345:pid_732:0")Write(mysupply,":volt 10.2")And so on.I have an entire instrumentation system written in visual basic , including class wrappers for machines. I dont even care if a machine is usb or gpib or if it is a keithley or hp i just tell that i need a machine that sits 'there'. It figures it out all by itself.I run large setups with 20 to 30 instruments including scopes , thermal chambers , meters , supplies , network analysers and custom built stuff . Some of these runs are weeks long ( burn-in of devices. ). No problem.Ne need for crapview or crapwindows.

author: Unknown
author_rank: Unknown
timestamp: October 27, 2012, 11:54:15 am
content: The Keithley 199 comes from the late eighties, and pre-dates IEE 488.2 and SCPI. From what I remember, it is quite picky about interfacing. It took some trial and error to get it working properly. A LabView instrument driver might help with that. HP/Agilent hardware is nicer in that regard (not that surprising since GPIB used to be HPIB). Any software shipped the Keithley 199 with it would require computers that can only be found in museums. The manual may include some BASIC listings as sample code, but you won't be able to run it on any modern computer.LabView is a software development environment. It implements a graphical programming language called G code. It makes some aspects like graphical interfaces and signal processing easier, but is not fundamentally different from any other programming language. If you are familiar with programming, it should be fairly easy to pick up, although it has some fundamentally different concepts than conventional programming languages like C. If you don't have any programming experience, then it's going to be a steep learning curve. It has drivers for most common test instruments, which makes interfacing easier.NI has SignalExpress, which is much simpler and more designed for basic test and measurement tasks. I haven't used it, but I would expect it to be much more picky about instrument drivers.Like free_electron states, there is no particular reason why you have to use LabView for instrument control, especially if you don't care about instrument drivers. The $60 GPIB adapter will most likely not support VISA or be directly supported by LabView. You need hardware from NI/Agilent/some other brand name manufacturer for that. Even Prologix didn't offer a VISA driver last time I checked. There is nothing preventing you from interfacing directly to the serial port or whatever interface it offers, but you won't have access to most of the features from VISA or LabView, like instrument drivers.Some cheap hardware only ships with a crappy application and does not come with programming documentation or an API. This is a pain, and might require reverse engineering to integrate into other solutions. Hardware with a well documented SCPI interface is usually easy to deal with once you get the hang of it.

author: NiHaoMike
author_rank: Super Contributor
timestamp: October 27, 2012, 01:19:18 pm
content: I would recommend using Python instead. LabVIEW is great if you want to quickly throw together a simple test program, but you're locked into using their expensive software and complex test programs are a real mess.

author: ftransform
author_rank: Frequent Contributor
timestamp: October 27, 2012, 04:52:47 pm
content: Hmm I'm actually thinking that it might be cheaper to get a old machine with ISA ports on it and use ISA GPIB cards for 20$ instead of 60$ pci gpib cards.....This is fascinating, I am glad to hear that making such complicated setups is fairly straightforward free_electron.

author: free_electron
author_rank: Super Contributor
timestamp: October 27, 2012, 07:52:20 pm
content: python is crap for this ind of work. python is gread a a web beack-end tool.The reason is the very poor implementation of VISA in python ( i have been using it. it is junk. tremendously slow and whoever wrote that wrapper has no clue how VISA nor instrumentation works. They pull an instance of visa, create a device , open device , sed command, close device release visa. That is absurd. if you have 3 machines you have 3 instances of visa running. You only need 1 instance of visa. visa itself is multhtreaded and manages device handles itself. and there is no need for this repetitive open and close.start of program : hook into visa ( load dll , done automatically in any programming language the moment you call a function )create device handles , perform operations against handles. terminate visa on exit of program.Now, as for labview and labwindows : they have their place. If you buy all NI hardware , including thier custom computers then this is a nice system to work with. Bring anything in that is NOT NI branded and it is a pile of wormfood. These so called 'drivers' that they provide are a collection of half finieshed , bug riddled libraries written by users and shared amongst them. invariably only a few functions are implemeted ( typically those that the instrument user needed ). Or, the functions are implemented wrongly because the instrument is not understood.I have been member of a panel on instrumentation control ( a research panel requested by a 'big company' and set up by nichols Research') looking after common problems encountered with instrumentation programming. This was the single thing that kept on returning over and over again : incomplete libraries that are written by people that don't understand the machine.I give you an example : take 256 readings and return me the min, max, avg and st.dev. And everyone goes off making a friggin for next loop and doing a bunch of calculations. The machine can do it all by itself, this saves a whole bunch of bus operations , and is way faster and more accurate than doing it in software. the machine can sync to the power line crossings and reduce the noise. if you order it to sample now it disregards the powerline crossing. But in order to know this you need to read the machine manual. and you need to code the function in such a way that, no matter what is requested, the most accurate method is used. And that is where it goes to snot.I have a practical example encountered a few months ago. We happen to have a few people using python and that visa library . they started this because one of em was doing a post-grad and one of the things they did was python programming so he touhgth it would be cool to combine what he was learning in uni with what he was doin in our lab. the end result is a massive bunch of spaghetti python code that is unmanaable and just doesn't work right. There is a piece of code that performs DNL/INL measurements of an A/D ;we program a precision source , sample the source using an 81/2 digit meter and record the a/d digital code and find the toggle points. For a 16 bit a/d this 'code' runs almost 48 hours to complete... ( 256 averages on on the meter , seek step up , seek step down a few times . the output is glitchy and you have to throw away the false readings ( someone turned on the light overnight and this upset the reading ) by hand.A collegue of mine started looking at this in an attempt to speed it up and shaved off a few hours. He got nowhere and came for advice. I told him to read the users manual of the meter to begin with. Look how to use the built in averging, read up on the NPLC settings of the meter, and double check that the display is off. These meters triple their speed if they don't have to update their display .... I have written such software in the past and knew about those machines.That knocked it down to an 8 hour runtime... from slightly over 2 days... just by understanding your machinery. My collegue then came back and said it still didn;t 'feel right'.We tried rectifying the visa library but gave up. neither of us was proficient enough in Python and having to fight against a language where an added space to a line makes a big difference ... we gave up and pulled the plug. Downloaded Vb express , opened the Visa Example from NI , and rewrote the thing ( it's amere 30 lines of code that loops for every step, rewriting it from scratch was done in an hour. faster than hairpulling against a nitwit language syntax where whitespace control program flow... and problems with library versions. Python : broken by design.)That knocked it to 5 hour runtime... tweaked the algorithms to do binary seeks instead of linear seeks and used the OPC? query on the supply to determine when the step was settled as opposed to a 'hard delay'. End result ? DNL/INL in under an hour. And i'm certain if that GPIB controller we used was a real PCI card and not a usb<>gpib i can shave off another 20% ...Long story short:1) no need for expensive stuff.2) labview and Labwindows do work , provided you use all NI hardware. Provided libs are 'user supplied' 'user supported' , incomplete or plain wrong.3) UNDERSTAND your machine. The users manual gives plenty of examples. Read the damn thing. there is a reason the users manual of a 34401 meter is 200 pages thick.4) Stay away from pyVISA. it is wrongly and poorly implemented by people that don't understand it. Simply taking a DLL , sending it through the tool to make a python wrapper for it does NOT produce a quality library ..5) Stay away from those cheapo gpib doohickeys. none of them implemnt GPIb right and none are VISA compatible. Go on the ebay and buy a used GPIB PCI card. they go as low as 50$. Doesn't matter if it is NI or Keithler or CEC or Agilent.plug it in , download driver , plunk visa on system and off you go. There is a chinese dude selling 100% clones for the USB versions. They do work and they do work right.

author: ftransform
author_rank: Frequent Contributor
timestamp: October 28, 2012, 06:25:45 am
content: That is quite the story haha. Visual basic wins eh?how does the light effect the measurement? Because of powerline effects or because of metal excitation ?8.5 digit multimeter sounds crazyi figure something that advanced would just run off a battery..

author: free_electron
author_rank: Super Contributor
timestamp: October 28, 2012, 04:17:56 pm
content: it's not so much visual basic that wins. i'm sure you can do the same in c# or c or c++ or maybe even in python , provided 1) you know your machines, 2) know what you are doing witht hem, 3) have correctly implemented machine libraries and 4) have a correct API towards the machines.pyVISa is a turd. Period. And python is bass-ackwards. Come on, whitespace controls program flow ? and then there is the problem of 2.x and 3.x this lib is not ported, that doesn't work there. pffffrt. broken by design.its not the light that affects the measurement. we have TL lights (vacuum fluorescent, standard office lghts) . when you turn them on the ballasts kick in to ignite the tubes. this causes enough crap in the spectrum to be visible in the readings. a 16 bit A/d running from a 1.65 volt vref ... you do the math how small the step is. and we sweep that step with 6 bit precision (we have a 22 bit 'dac' ) to have an idea if it is center , high or low ... Even if the setup is stuck in the temp chamber ( we use the temp chamber as faraday cage as it is all metal ) the room lights still disturb it so it is visible. bad grounding i suspect.Idelly it would run off a battery but the problem is that there is so much instrumentation that it woudl require a big honking battery.

author: Unknown
author_rank: Unknown
timestamp: October 28, 2012, 06:42:33 pm
content: I don't see the point in turning this thread in another 'which programming language sucks the least' argument. Idiots are perfectly capable of producing poorly performing garbage using any tool. Poor understanding of the equipment or platform will kill any programming project. Almost any general purpose programming language ftransform happens to be familiar with should probably do fine in this case.

author: bingo600
author_rank: Super Contributor
timestamp: October 28, 2012, 06:49:35 pm
content: PYLT "PYthon LabTools" by Poul Henning Kamp is quite nice.https://github.com/bsdphk/pyltCurrently two hardware connections are supported:1: Prologix USB-GPIB adapter2: Direct USBTMC/USB488 connection.It's a tool that talks to the "iron" , so you'd better know the SCPI or whatever Instrument Commands to use.I use it for my Pre-SCPI HP 5384A/Bingo

author: ftransform
author_rank: Frequent Contributor
timestamp: October 28, 2012, 09:32:24 pm
content: Maybe you can get old airplane batteries inside of your lab!test equipment does not draw that much does it?

author: free_electron
author_rank: Super Contributor
timestamp: October 28, 2012, 10:05:17 pm
content: Quote from: bingo600 on October 28, 2012, 06:49:35 pmDoes not support real gpib cards or LXI or other machines. So: useless , at least for me.The beauty of VISA is that you do not care what the physical connection medium is.You can have machines plugged in on USB, some on a network (LXI standard) , some can be on a real gpib card , and others may go over a GPIB port to a VME bus backplane ( VXI ) ir a compact PCI backplane (PXI/MXI). you can even open serial ports and stuff attached to printerports if you want.You define a 'machine' and tell it where it sits. After that you read and write to that 'machine'. done.i have a mix of machines on GPIb , USB ( the newer 34410's ) and lan ( Scopes ). All works flawlessly through visa. no need to muck with usb drivers, network config or anything.Visa handles transport and all the low level stuff. all i need to do is send the ascii commands back and forth , whether these are SCPI or old Style doesn't matter.VISA is the industries solution to the problem. it is not 'owned' by anyone but was co-designed by HP , NI , Keithley and Fluke when they did VME. All the instrument makers support it. it is gratis , download, install and go. And it is actively maintained and developed by both Agilent and NI.For me, VISA is the way to go. anything else is re-inventing the wheel and making it hard on yourself to get any real work done.

author: Unknown
author_rank: Unknown
timestamp: October 28, 2012, 10:21:01 pm
content: VISA is great as long as you have real GPIB hardware and supported instruments. Less so if you have hobbyist level hardware (eg. the cheap DIY or Prologix GPIB interfaces), custom hardware (eg. random micro driving a DDS chip) or hardware from certain Chinese manufacturers that don't offer VISA drivers, only their proprietary API. Sure, you can use VISA to interface with a serial port, but you don't get the advantages of abstracting away the low level interface.So, the costs/benefits analysis for VISA is going to look very different if you're driving a bunch of Tektronix/Lecroy scopes and Philips multimeters via GPIB and USB-TMC versus a bunch of Arduino/ST discovery boards driving your custom test setup.

author: ejeffrey
author_rank: Super Contributor
timestamp: October 29, 2012, 03:45:00 am
content: Quote from: alm on October 28, 2012, 10:21:01 pmYou still get reasonably cross platform serial port access as good as you are going to get with such non-standard devices, and you still get network transparency. In my experience the network transparency part isn't that reliable (using NI VISA), but that could have been a problem with our network configuration due to certain sysadmins who think that the more rules in your firewall the more secure you are. Same story with USB devices that just have an FTDI USB<->RS232 chip rather than a proper USB T&M class device.

author: free_electron
author_rank: Super Contributor
timestamp: October 29, 2012, 04:24:48 am
content: Quote from: alm on October 28, 2012, 10:21:01 pmI have plenty of custom hardware on serial ports (through ftdi chips, and on real serial ports). Works flawless.As for 'driver'.. I don't know what you mean. The thing about visa is that there is no need for a driver. You open the coonection and exchange data. It is a simple pipe. Done. The instruments manual will tell you what to throw in and what comes out.Visa is an API that exposes a multitude of communication channels ( gpib , lan, serial, etc ) as a simple pipe.Any test equipment worth its salt is gpib or lxi compliant.As for those prologix thingies... I've already given my opinion on those in several other topics... Although i'm sure it is possible to write a wrapper that talks to those through visa as well. Those things show up as a serial port so open it as such and make a wrapper that puts those box xpeciifc headers around the instrument command and it will work fine.

author: ejeffrey
author_rank: Super Contributor
timestamp: October 29, 2012, 05:37:05 pm
content: Quote from: free_electron on October 29, 2012, 04:24:48 amThe only think I can think of is devices that use FTDI adapters and require direct mode rather than virtual com port. That would require a low-level driver to work in VISA, and I honestly haven't ever bothered to look to see if such a thing exists. The only devices I know of that legitimately require direct mode are partially or fully binary devices like cameras which need the speed or other features of the chip not exposed in VCP mode. These wouldn't work will with VISA in any case, so the point is mostly moot. I have run across a few instruments that use these chips and while they work fine in virtual COM mode, the included demo software puts the device in direct mode. The good news is that these devices typically have C libraries available that provide access which you can call from from any language you like. Not as good as having a well documented text based API, but it gets the job done, provided the DLLs work, are compatible with your OS, have the right bit depth, and don't violate the security protections of the latest MS OS... And provided you don't want to use it on Mac or Linux. Like I said, a properly documented serial API is the best, but sometimes you have to live with it.

author: Unknown
author_rank: Unknown
timestamp: October 29, 2012, 09:19:30 pm
content: Quote from: free_electron on October 29, 2012, 04:24:48 amBut many cheap devices don't use any of the 'pipes' offered by VISA. GPIB is on its way out, LAN is relatively expensive, serial is mostly dead. USB is by far the most popular. Some equipment uses an USB-UART interface or USB-TMC, but many of the cheap ones use a proprietary protocol only understood by their software. I believe that the somewhat popular (on this forum) Hantek DDS-3x25 is one example of this. So are many of the cheap DSOs. Even if they do use a standard USB class, they still won't tell you the protocol. Don't expect your $100 arbitrary function generator to support SCPI.Quote from: free_electron on October 29, 2012, 04:24:48 amExactly my point. Not all test equipment is 'worth its salt'.Quote from: free_electron on October 29, 2012, 04:24:48 amBut will it offer transparent access similar to other GPIB interfaces? Will it handle details like addressing and SRQ? You can open a serial connection and send some bytes in almost any programming language, you don't need the VISA framework for that.

author: free_electron
author_rank: Super Contributor
timestamp: October 29, 2012, 09:47:23 pm
content: Quote from: alm on October 29, 2012, 09:19:30 pmthat won;t work since those toys don't know how to do any of that stuff anyway. most of those converters aren't even level compliant...like i said : get a real gpib card and get real test equipment.