Automating the lab - Page 1
Forum section: electronics / testgear

author: Mr. Scram
author_rank: Super Contributor
timestamp: December 20, 2017, 07:15:26 pm
content: While putting together a collection of tools, I've made sure to mostly pick ones that will talk SCPI and come with LabView drivers. The idea was initially to use LabView to automate things. However, looking at the LabView pricing and being familiar with various scripting and programming languages, I'm not so sure that's the best way to go. An expensive visual programming environment might not be a better option for me than straightforward scripting for less or free.Ideally, I would simply be able to shoot commands to various devices, using basic if [] then or for loops. Set variables, iterate through loops, change variables, repeat loops, set voltage, read voltage, append data to .csv, that kind of stuff. However, I'm not sure how to practically do this. Some Googling tells me that I might be able to use .net for something like this, but I'm looking for tips and experiences to prevent me sinking a lot of time into something that's already been solved.The preferred OS for all this is Windows. I'm most familiar with VB.net, but I guess something like C# or some dialect should be easy enough to pick up. I would typically be automating somewhat tedious tasks, like testing the efficiency of power supplies or stress testing devices. Do you guys and gals have any input on what might be suitable solutions?

author: HalFET
author_rank: Frequent Contributor
timestamp: December 20, 2017, 07:25:29 pm
content: There are code examples for the NI VISA/whatever you wish to call it/... interfaces in multiple languages. I've grown fond of Matlab and python for this task though.

author: Mr. Scram
author_rank: Super Contributor
timestamp: December 21, 2017, 09:59:49 am
content: Quote from: HalFET on December 20, 2017, 07:25:29 pmI don't have much experience with either, so that doesn't seem to be the best solution for me. I can imagine it being a nice way of doing it though. Matlab should provide a few tools to do nice things with the data you've collected.I'm looking into using .NET, but looking at the examples it's not quite as straightforward as I had hoped. Looks like I might need to write some libraries to deal with the fiddly bits.

author: bd139
author_rank: Super Contributor
timestamp: December 21, 2017, 11:16:22 am
content: I've been using OSX and some python scripts to talk to everything and orchestrate it all. I've built a simple class to talk to each instrument which uses whichever transport is appropriate (usually some form of bastardised SCPI over either serial or RS232). This is not scaling well and I've had a couple of really awkward drivers to deal with so I have started to migrate it all to my desktop PC on windows with C#. Also you benefit from static typing there which is a must for measurement classesNI VISA is apparently a thing but it's not really difficult to talk to the native interfaces of most instruments so I went down that route.An example here. This logs unix timestamp vs frequency from a TF930 counter so I can do drift statistics (using R). This is run over the space of a few hours.I will write one program for each use case usually as I can hammer them out in minutes (15 years of C# programming now)Code:using System;using System.IO;using System.IO.Ports;using System.Threading;class Program{public static void Main(string[] args){using (var writer = new StreamWriter("log.csv")){var epoch = new DateTime(1970, 1, 1);var p = new SerialPort("COM3", 115200, Parity.None);p.Open();p.WriteLine("M2");while (true){var uts = (uint)(DateTime.UtcNow.Subtract(epoch)).TotalSeconds;p.WriteLine("?");var rdg = p.ReadLine().Trim();rdg = rdg.Substring(0, rdg.Length - 2);var fmt = string.Format("{0},{1}", uts, rdg);writer.WriteLine(fmt);Console.WriteLine(fmt);Thread.Sleep(10000);}}}}

author: HKJ
author_rank: Super Contributor
timestamp: December 21, 2017, 01:37:24 pm
content: I do not like to install a bunch of VISA drivers, some of them installs way to much software and they are depend on OS brand and version, i.e. if you update it may not be possible to move all your equipment to the new platform.For this reason I always communicate directly with the equipment, preferable with a socket connection, but also via serial port (usual virtual).I have done my software in Java, it has been very stable, I frequently run logging session that takes more than a week.Replacing defective computers has also been fairly easy.

author: Mr. Scram
author_rank: Super Contributor
timestamp: December 21, 2017, 02:01:54 pm
content: Quote from: HKJ on December 21, 2017, 01:37:24 pmHow does that work? Do you shoot commands at COM ports?

author: HKJ
author_rank: Super Contributor
timestamp: December 21, 2017, 02:10:11 pm
content: Quote from: Mr. Scram on December 21, 2017, 02:01:54 pmCOM ports or sockets, most larger equipment has support for SCPI build in. For some equipment I need to send special packets to control them, but as long as I can find documentation it is easy enough.

author: Mr. Scram
author_rank: Super Contributor
timestamp: December 21, 2017, 02:15:45 pm
content: Quote from: HKJ on December 21, 2017, 02:10:11 pmI've been careful to select equipment speaking SCPI. I have been looking at a Maynuo load, but I don't want to deal with the Modbus style communications. I want to focus on my projects, rather than the tools becoming the projects. Myabe later when the rest is up and running, but I'll stick to SCPI for now. Yours seems to be the easier solution, though I'm probably overlooking a few things.

author: HKJ
author_rank: Super Contributor
timestamp: December 21, 2017, 02:26:00 pm
content: Quote from: Mr. Scram on December 21, 2017, 02:15:45 pmThere is one detail called LXI, for some equipment it is required and I did not find an easy explanation on how to code it.There is also some equipment where the SCPI implementation could be better.I have not coded the Maynuo load, the Itech and BK use another protocol that is fairly easy to get working (At least for me).

author: _Wim_
author_rank: Super Contributor
timestamp: December 21, 2017, 08:26:44 pm
content: Quote from: Mr. Scram on December 20, 2017, 07:15:26 pmAttached is the source code in C# that I once wrote to make trends with my HP8153A optical multimeter. I made a generic class for GPIB instruments that should allow you to easily create your own. I used a Agilent 82357b GPIB-adaptor to communicate, but other adaptors should also work. It includes some basc functionality for making plots and some GPIB error handling... I used the free version of visual studio.

author: alm
author_rank: Super Contributor
timestamp: December 23, 2017, 10:28:19 am
content: Quote from: HKJ on December 21, 2017, 01:37:24 pmThe advantage of the VISA interface is abstraction (change from RS-232 or GPIB to Ethernet only requires a change to the connection string). Clearly this abstraction comes at a cost, and I'll not argue against the VISA implementations being huge and sticking their tentacles everywhere. Not a big deal if you have a computer dedicated to controlling equipment, in my opinion. You might also able to useIVI driversthat run on top of VISA if they are available for your instruments. They abstract your interface so you can change a Keysight power supply for a similar Keithley power supply with barely any changes to the code, unlike with the so-called standard SCPI.I don't use the NI bloatware either, but fair more lightweight libraries likepython-vxi11(VXI-11 implementation),PyVISAwithPyVISA-py(supports serial, USBTMC and on Linux GPIB) andpython-ivi(high-level instrument drivers). Reading from a DMM is as simple as:Code:k2000 = keithley2000('TCPIP::192.168.0.2::gpib,16::INSTR')k2000.measurement_function = 'dc_volts'k2000.range = 10result = k2000.measurement.fetch(1)Quote from: HKJ on December 21, 2017, 02:26:00 pmLXI is a standard for instrument control over Ethernet. It implements automatic discovery of new instruments (which is what the NI/Keysight VISA agents use) and supports either raw TCP/IP or VXI-11 (an RPC based protocol). There is also the more modern HiSLIP, which is a successor to VXI-11. Raw TCP/IP is obviously easy to use, but protocols like VXI-11 have features useful for ATE like group triggers (to trigger multiple instruments at once, say to DMMs to measure voltage and current) and asynchronous SRQ (controller can wait for an interrupt without polling every instrument, give me a signal if any of the over current limits trip).Quote from: HKJ on December 21, 2017, 02:26:00 pmAbsolutely. Some equipment requires trial and error to find command sequences that do not trip up the unit.

author: HKJ
author_rank: Super Contributor
timestamp: December 23, 2017, 11:56:05 am
content: Quote from: alm on December 23, 2017, 10:28:19 amThe big deal may come around when you have to update the computer, can you get all the drivers for the new computer and updated OS?With direct connection to the equipment you do not have that problem. I have replaced a couple of computers over the years, including windows upgrades and the only problem was the fake usb-serial chips.With the software I use I only have to change the instrument type and port when changing between different brands of equipment. This is very handy for both power supplies and DMM's, but then I do not need all the functions in the equipment, this makes it considerable easier to make generic interfaces.

author: bd139
author_rank: Super Contributor
timestamp: December 23, 2017, 12:38:50 pm
content: Generic interfaces is what I'm currently working on.DG1022Z -> DUT -> power meter (AD8307) -> GDM8341Code:// Scalar network analyser:var generator = new RigolDG1022Z("tcp://192.168.1.101");var dmm = new GWInstekGDM8341("ser://com3");var input = generator.Output1;input.Enabled = true;input.dBm = 1;var output = dmm.Channel1;output.Mode = GWInstekGDM8341Mode.DC;for(long i = 0; i +=10.KHz(); i < 20.MHz()) {input.Frequency = i;Thread.Sleep(500);writer.Write("{0},{1}", i, output.Read());}(missing boilerplate and typed from memory but you get the idea)

author: HKJ
author_rank: Super Contributor
timestamp: December 23, 2017, 12:50:02 pm
content: Quote from: bd139 on December 23, 2017, 12:38:50 pmThis do not look very generic to me, if you had used DMMMode.DC it would be much more generic.The idea is that you can instance any generator and DMM you have (As long as they support the required functionality) at the top and the rest of the code will work without changes.

author: bd139
author_rank: Super Contributor
timestamp: December 23, 2017, 01:02:00 pm
content: Yep it needs a lot of refactoring yet. I'm sort of still experimenting as to what a suitable model is for each instrument class. I intend to have the whole thing extrapolated into device classes and channels at some point so you can kick out an IDMM instance from a factory:Code:using Instruments.GWInstek;...IDMM dmm = (IDMM)Instrument.Dial(typeof(GDM8341), "ser://com3");dmm.Channels.Mode = ChannelMode.DC;dmm.Channels.Measure();But it's nowhere near there yet. The above is straight out of my sticky note on the "end game".Edit: I'm also working on a decimal based unit capable type system to go with it so precision is kept on some measurement classes to a predictable number of digits (frequency for example).

author: Mr. Scram
author_rank: Super Contributor
timestamp: February 11, 2018, 12:25:28 am
content: Today I finally decided is was time to get experimenting and much to my surprise, getting things to at least tentatively work wasn't that hard at all. Though there are various layers of abstraction to choose from, talking SCPI directly to a device seemed the least complicated. First I wanted to see if I could communicate with a device in the first place. So after hooking up the GDP-3303S and making sure I got the right COM port selected, I opened up the Serial Monitor of the Arduino IDE. With the manual and some trial and error, I could command and read from the machine.Of course, sending commands manually through a prompt isn't the most useful thing in the world, so I decided to see whether I could do the same through Visual Studio. There are a lot of fairly complicated examples to be found online, so it took some experimenting to find out what the actually needed bare minimum is. Right now I have got it down to eight lines of my own code, other than the usual Visual Studio faff. Four to declare a few things initially and four to actually push a command to the port. There seem to be some alternative ways of maybe doing it more efficiently, but this is already a nice result. Once you figure out how it's done, it's trivial to fire off commands in the exact sequence desired. After some more trial and error, I can now also read data back and process it any way I like.So far I have spent zero effort on trying to catch errors or any other polish. I have to be careful not to fall into the trap of wanting to develop a full product yet again, but it would be nice to abstract things a bit more and get them to a point where I can use single line commands of some sort to quickly whip up automated scripts. Right now I imagine it being something like PSU.SetCurrent(var), but I still need to figure out what's convenient there.

author: G0HZU
author_rank: Super Contributor
timestamp: February 11, 2018, 12:44:34 am
content: I've been using Visual Studio for this stuff for many years and I generally use a little Asus EeePC to run the code as I don't like having a desktop PC (with monitor and keyboard and mouse) on my main RF workbench. It feeds to an Agilent 82357A USB to GPIB cable and then I connect the test gear together via GPIB.The little EeePC can run for up to 10 hours on its internal battery and can be tidied away as easily as putting a small book away on a shelf. I also use a mini wireless mouse with it. I generally write code to control various sig gens, my VNA and spectrum analysers and DMMs. I recently bought a Thurlby programmable dual PSU at an auction and I've had some fun with that by writing a few simple programs.

author: Mr. Scram
author_rank: Super Contributor
timestamp: February 11, 2018, 12:54:00 am
content: Quote from: G0HZU on February 11, 2018, 12:44:34 amThat sounds great. What language do you use and do you abstract anything for yourself? I'd love some good ideas on how to streamline things a bit.

author: G0HZU
author_rank: Super Contributor
timestamp: February 11, 2018, 01:17:14 am
content: QuoteI'm very lazy and I'm still using an ancient copy of VB6 Enterprise. I'm not sure what you mean about streamlining things. I tend to write fairly simple stuff anyway. I'm also happy to live with the dated and clunky look of VB6. One day I'll have to move on from it but it is just so easy to use

author: rx8pilot
author_rank: Super Contributor
timestamp: February 11, 2018, 03:17:22 am
content: I have been using Labview Home edition for $50Much faster than Python IMHO - unless you are a python genius. Both have a learning curve, but Labview is very quick to create things after the initial learning curve. Python is harder, in my view of course, to manage and visualize.

author: Mr. Scram
author_rank: Super Contributor
timestamp: February 12, 2018, 07:49:54 am
content: Quote from: G0HZU on February 11, 2018, 01:17:14 amStreamlining things would be getting to a point where the handful of lines needed are replaced by a single line, probably a function. Right now I'm thinking about having a separate library per device. That should make things fairly modular. As far as I can tell you can only talk to one port at a time, so I need to do a bit of port management too. Going the dumb route and opening ports for every communication is als an option, but I'd have to look at the overhead.I think the first attempt will be making it so that I can just enter "PSU_current_read()", "PSU_voltagesetpoint_write(1.750)" or "AWG_frequency_write(variable)". I could get fancy with all sorts of autodetecting features, but I have to be mindful of feature creep. It doesn't have to be perfect or useful to others, it just has to be convenient enough to be workable and allow me to quickly whip up a scripted sequence. I guess I'll just have to figure it out as I go along.

author: Mr. Scram
author_rank: Super Contributor
timestamp: February 12, 2018, 08:01:35 am
content: Quote from: rx8pilot on February 11, 2018, 03:17:22 amThanks for the different perspective. Initially I thought I'd do it all with LabView, but the more I thought about it the more a visual programming language put me off. I've never used one that wasn't clunky and painful compared to simply writing code. None of them were as developed as LabView should be, though. I also thought LabView would be expensive, but the Home Edition looks affordable enough. I don't think you can use that edition for commercial work, right? Does that pose problems for you in the minifactory? Are there other limitations compared to other editions I need to be aware of? One advantage of using LabView would be that Mynuo loads actually do come with LabView drivers, but are a bit more complicated to drive through my own code. The Maynuo units seem to use the Modbus protocol, with which I have no experience. I'm honestly not too excited to learn about it simply to drive a single device.I don't use Python, as I have near zero experience with the language. Currently I'm working with Visual Studio 2015 and VB.net, simply because that's the modern language I'm most well-versed in. I guess C# would be an option too, but it boils down to the same thing anyway. I think basic scripting is easier in an actual programming language, but LabView might have the edge when it comes to easy visualisation of data.May I ask how much programming experience you have? I can imagine the mileage varying massively depending on the existing skill set.

author: rx8pilot
author_rank: Super Contributor
timestamp: February 12, 2018, 07:03:23 pm
content: Quote from: Mr. Scram on February 12, 2018, 08:01:35 amLabview is remarkably capable, not sure what limitations I have with the home edition. You can communicate with just about anything, calculate it, branch, loop, save, graph, plot, whatever - only a lot faster to produce and change over time. My programming skills are modest - mostly in C/C++, some Python but not much more than utility programs. Labview is not just for lab automation. People use it way beyond just boring automation tool.It is fairly easy to make visual controls on a screen with buttons, indicators, alarms, etc. That is possible in hard code, but it takes more skill and time. If I was a master Python or C++ developer it may make sense - but programming is a peripheral skill for me. My primary goal is getting a product out the door so I lean toward the fastest possible solution.

author: Mr. Scram
author_rank: Super Contributor
timestamp: February 13, 2018, 05:24:17 pm
content: Quote from: rx8pilot on February 12, 2018, 07:03:23 pmCoding up readouts and buttons isn't that complicated when using Windows forms, if I'm honest. After I figured out how I can send and receive signals I could whip together a virtual frontpanel in not that much time. However, it does sound like LabView is worth a look and at 50 bucks it's not a huge risk. It could just be that both are useful, depending on the scenario.

author: rx8pilot
author_rank: Super Contributor
timestamp: February 13, 2018, 05:44:03 pm
content: Quote from: Mr. Scram on February 13, 2018, 05:24:17 pmIn an ideal world - I would be an expert in both. No doubt. I am only a beginner in Labview overall - just scratched the surface. Same with Python - beginner there too in the big scheme of things.If my business has some good months, I may invest in bringing in an expert to do some automation projects that I am not able to do for lack of both time and skills. My guess is that I will also learn a lot in the process of just watching an expert tackle the various challenges.

author: alm
author_rank: Super Contributor
timestamp: February 13, 2018, 10:20:12 pm
content: Quote from: rx8pilot on February 12, 2018, 07:03:23 pmLabVIEW is very capable, but I did not enjoy my time working on some complicated LabVIEW programs. Even some fairly simple math will quickly take up a large amount of screen space and become hard to read. The 2D nature makes it much harder to understand a program you have not seen before, since there is no clear sequence. Searching for all references to a global variable is also harder for the same reason. Unless you are very methodical in naming all wires and define self-contained virtual instruments with clean interfaces, it can be very hard to figure out a program. In a textual program you are at least forced to name all variables and put things in an order. Also, last time I checked, unit testing was problematic.About faster to change over time: sure, after you have moved part of the program to make room for new code, and cleaned up all the wires that were messed up in this process, it is very quick to change.So for me, LabVIEW is nice for quickly creating something that acquires a bunch of data, does simple math, and display the result. Or for creating virtual front panels to test setups. But for anything moderately complicated, I'd rather use a tool like MATLAB, Python or R. That's where the limitations lie in my opinion, not in features.