This is very interesting. I go out of my way to avoid VISA.
I’ve done a LOT of instrument control over plain old ethernet + SCPI, so I’m quite curious as to why people would want to use VISA ?
I say this because when I have had to use VISA, I have had problems more than occasionally.
Not too long ago I was attempting to use an instrument driver that depended on VISA but VISA wouldn’t recognize the instrument. I wrote a quick check program using ethernet + the SCPI port and the instrument worked fine. I ended up having to write the driver myself (luckily i only needed a few commands).
Julia + instrument control + data analysis is a terrific combination.
I thought about adding a timeout feature but didn’t implement it as this was a quick experiment. As is, if the expected Char never arrives it will wait forever. I haven’t looked into behaviour of other readuntil methods to see if there is some precedence for that.
I guess it kind of stuck:)). Long story short we were using Matlab with instrument control toolbox, wanted to get rid of the license and started using ni-visa. Most of our instruments are gpib and usb, so we went on with visa because we managed to write our own high level drivers quite easily. Things ran well so we didn’t think of alternatives. Now I’m trying to convince my colleagues to switch to Julia but it’s tough work when there are multi site teams using Matlab.
Mostly because it (is supposed to) handle the connectivity for you. So you can run the same higher-level code through USB, GPIB, etc. Not saying it always works, but it is a convenient abstraction in many cases. I agree I’ve had to bypass at the driver level as well.
I’m curious about this - Julia’s forte is fast-running code. But the bottleneck in instrument control is not the CPU. So I have not converted the team from python at this point. Has anyone run across a situation where Julia’s speed helped the instrument control specifically? (Data analysis, no question )
I think most applications there would be very young and possibly nonpublic if they exist. But, I can say I was able to prototype a calibration routine /w a front end into a rinky dink DIY syringe pump in ~4-5 afternoons after work. Consider I am not an engineer nor have I taken any engineering classes, cheated a bit with an arduino shield and a motor driver library, but I did this by putting as much on Julia as possible because it’s so easy to prototype in (JuliaMakerProjects/Projects/SyringePumpJl at master · JuliaMakers/JuliaMakerProjects · GitHub).
I’m not sure where the real power of julia lies for these efforts if Julia is not directly embedded. I think it’s mostly in quick ‘hacking’, and yes turning data into digestible information/instructions quickly. But also in control! I mean one could offload data so Julia can do diagnostics from complicated sensor readings(the analysis would have to outweigh the transfer for it to be worthwhile), and zap back an action.
The way I’m seeing it is, in a few years there will be operations only Julia can do ‘well’ and the more people on board with the tinkering side of things the more motivation there will be to really let those come to life. At that point other things will be more or less obvious.
This is a good point. I have not run into a situation where the app was CPU bound. I have had measurement systems that definitely were interactive in the sense that calculations would direct the subsequent measurements. However, the computations were not very intensive.
And it gets a little worse. I’ve had to write control programs in python strictly so that i could access .net libraries…
edit: the point being that I have not had a situation where there was a real need to use Julia instead of python.
Make no mistake - I love Julia and there is no reason not to use it in these situations. I just can’t justify switching the uninitiated over to it for this … yet. But when that day comes, I’m the first to jump in.
I think one would switch to Julia because of the two language problem, when one needs to develop a complete framework and can’t afford to lose precious time switching between controlling instruments in one language and processing in another. One cool task I had once was to loop through thousands of operating conditions for a device, acquire oversampled oscilloscope waveforms, perform some automatic glitch checking and localization, compress data and dump it do disk every loop. The glitch checking and compression methods were custom and we really needed them as the resulting disk data was 100x smaller. Coded everything in Matlab2017 and Julia(no multithreading at that time) and Julia ended being 4x faster. This meant cutting down run time from almost a week to one day.
Totally agreed that the single-language thing is legit. And for multi-day instrumentation runs, that does offer an example where the speed mattered. Sounds like you were indeed CPU-limited in some way. Very cool.
We are working on a project where someone else is collecting data using a Gantner system and writing their .dat files. We are writing our code in Julia, and wanted to be able to access this data. There seemed to be two solutions. One was to use their .dat binary file format to csv file converter. Not only was this slow, but only gave about 4 significant digits precision. They also have a MATLAB read_exact.mex file solution. This was interesting because it called their shared library. Using the source code of that file we were able to create Julia ccalls to read the file by calling the shared library. We are just learning about how to create packages so we can make that public if anyone is interested.
More of interest to hackers is the MCC HATS for the Raspberry PI. We have now made the commands for the MCC 172 available in Julia again using ccalls. With this as a base it should be straightforward to make the commands in the other cards in this series available. Again if anyone is interested, we will attempt to put this on Github. These seem to be in the interesting land of low end commercial quality at quite reasonable prices.
Hi, just today I published in Forem (Experiments automation with Julia) how to do a basic automation with Julia, it is not a pure Julia solution because it uses PyCall. I show that it is not difficult to use Julia for such tasks. I also manage to implement live monitoring of the data as it is captured using @async and GLMakie (I show this in a link for my repository).
I really hope that there will eventually be fully native solutions in Julia. But for now, this has served me quite well, with the exception of a few instruments that I can’t connect to anything other than the manufacturer’s software.
Thankyou so much for doing that. I know that Avik Sengupta published a package some time ago regarding accessing Raspberry Pi sensors. Would you maybe comment on R Pi ?
