Re: [science-iwg] Lab automation tooling

["Kasemir, Kay" <kasemirk@xxxxxxxx>]

Hi:

>while you know that I am doing scripting a lot, most scripts in our
>company need to communicate with lab equipment (oscilloscopes, power
>source units, waveform generators, ...). We are doing this using VISA,
>IVI and typically National Instruments drivers. We are accessing all
>this stuff from EASE scripts, using a self written intermediate layer in
>C# to access hardware busses like GPIB. I am wondering how the other
>science group members do this as I guess some of you will have similar
>requirements. Are you all building your own stuff or is there a common
>approach available already?

Not sure about a good/easy/obvious answer for basic lab automation.

On a larger scale, we use EPICS (http://aps.anl.gov/epics) to perform the control, automation, logging, remote display, ...
Slides with details from a local training session: https://ics-web.sns.ornl.gov/kasemir/train2013/

But that's for larger setups with 100000+ network-accessible devices, requiring reliable operation for years, 24/7.

It's a big step from a PC running LabView, talking to a signal generator on the same table, to "PlantView". 

Still, one key idea is that you will likely soon need a distributed system.
Starting with for example LabVIEW, it's easy to combine device access, automation, logging, user interface all in one program.
Perfect as long as it all fits on your table, but doesn't scale.
Plus what if somebody closes the "user interface" -> The "automation" is also gone.
What if two people want to open the "user interface", for example two people each in their office -> Is the automation now running twice, for example each incrementing something, which as a result rises twice as fast as intended?

Pretty soon a distributed setup makes sense:

Front-end computers, often without keyboard/display/hard drive, talk to your hardware and make the information available on the network. Can be Raspberry Pi, Linux server in some rack, maybe RTLinux or some other real-time OS.

Some automation like PID control runs directly on these front-end computers. Or via the network on other computers if you can accept the network latency and instead want more flexibility like update the higher level automation without affecting the faster PID control that's on the front-end.

In EPICS, the above functions are called Input-Output-Controller (IOC) and the network protocol is Channel Access.
Python can also be used as a Channel Access client and/or server to read and transform raw data into more interesting information, or to perform automation.

Then you have tools like CS-Studio for the user interface. Ideally, it's just the user interface: One or more people can open it to see what's going on, push buttons or enter new values which are then sent via the network to the IOCs or python-based servers.
Automation, logging, .. are fully functional even while nobody's looking.

So the basic suggestions would be:
Python is likely a very good choice for automation.
But don't put it into the user interface.
Allow the automation to run independent from the user interface, ideally on a different computer so an end user crashing the display computer doesn't affect the rest of your control system.
Tie the front end, automation, user display together with a network protocol.
EPICS' Channel Access has been in production for decades on almost every continent, but you can also google for internet-of-things related ideas like the MQTT protocol.

Cheers,
Kay