Experimental Physics and
Industrial Control System

Kay, Thank you for taking the time to reply, I really appreciate it.

What you wrote is very encouraging and of course makes a lot of sense.

One requirement I have is that the Scan Server status would have to be available as a PV and I thought I'd have to write a Python IOC to bridge between EPICS and the Scan Server REST API - but having discussed this with Matt Pearson (ORNL) he suggested that it can be accomplished via a customisation setting (status_pv_prefix) so I reckon all bases are covered!

I'll run up a test IOC tomorrow and check that I can get the status PV to work.

Thanks,

Ian

Hi:

We developed the CS-Studio scan tools for use on our neutron beamlines here at ORNL, where they're key to running experiments.

The design is inspired by the "ScanEngine" ideas of the  APS/Argonne Software Services Group, a project which I think was abandoned, and the dawnscience/GDA project, which has an execution engine to which one can basically submit arbitrary scripts.

Beam lines users want the power of something like python to write arbitrarily complex scripts, and that need might be justified.

But IMHO they often lack the expertise to actually write software, and then there's the issue of how to execute and monitor those scripts.

If a user starts a script in some terminal window on a beamline computer, how can other members of the beamline team, sitting in their office, tell what's happening. What script is running, how far along is it, did it complete successfully or fail?

Expert python users start to  argue that most of the beamline automation software can be replaced by a jupyter notebook, python and some EPICS channel access binding, which can run the experiment, feed the data to an AI/ML system to determine ideas for the next run and so on.

Back in reality, that can result in emails "My experiment failed at 2:30 in the morning. Can anybody help me, explain what went wrong, and how I can improve my script?"

.. which is hard to do when you can't easily tell what script was running in the first place, where exactly it failed etc.

The situation might be fundamentally different for XRay vs. Neuton instruments. On an XRay beamline where exposing a sample takes a few seconds, if a script fails, you fix it, try again, and all you lost is a minute. On our neutron beam lines, one experiment easily takes hours or even days. If you run into a silly error and then need to restart, you lost a lot of beam time.

So our approach with the CS-Studio scan tools is that we rely on a comparably simple but well tested and robust set of predefined commands.

If beamline users write their own python script based on pyepics and never need any help: Perfect, let them do it.

But if they need help, we prefer to use this sandboxed scan server environment.

For example, the "Set" command can set some PV, wait for the callback, then check a readback to be within tolerance. It's used to dependably move a motor or adjust a temperature.

When users write python scripts, those scripts don't directly perform a CA put/get/monitor. Those scripts instead assemble the list of scan commands, submit them to the scan server, and the scan server then executes them. This way, we can see what lists-of-commands aka "scans" have been submitted, which one is running, on what command it currently is.  To some extend you can pause and resume an ongoing scan, or re-order the queue of upcoming scans.

It's all logged, so in case of failures we can see exactly what was written and when, how long it waited, if it received the callback or timed out etc.

In some cases, users never see the underlying script. Instead, there's a CS-Studio GUI for entering parameters of the experiment. When they push the "Go" button, a script in the GUI uses the data in the GUI to assemble and submit the scan commands.

This has worked quite well for our neutron experiments, which tend to consist of a maybe long but otherwise simple list of move this, take data, do that, take data. We can perform commands sequentially or in parallel. For example, we can move motors and adjust temperatures in parallel and continue when they're all done, or have a temperature go from cryogenic to room temp while taking data. But it's still a recipe-type list of steps, there's generally no if-then-else that changes what the experiment does while it's running.

The python script uses the https://controlssoftware.sns.ornl.gov/css_pyscanclient/html/ library to assemble the commands and submits them to the scan server. The script might then be done, or it could wait for the scan to complete, fetch some logged data points and maybe submit a follow-up scan. The point of the scan server is the robust and transparent execution of an experiment.

Without the scan server, if you run your experiment directly as a python script, you could get close to that functionality by building a library that can for example reliably set some PV, wait callback, and check readback within tolerance, log all that it's doing, and run that inside for example a VNC session that allows others to monitor what's running, how far along it is, and how it's doing.

Cheers,

Kay

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ian Gillingham via Tech-talk <tech-talk at aps.anl.gov>
Sent: Thursday, July 21, 2022 8:36 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] Phoebus Scan Server

 

The Scan Server that's packaged with Phoebus looks, on the face of it,
as though it could fulfill a major part of a project requirement - i.e.
automated sequences of operations. I've built some small test scripts
(.scn XML files) and submitted them to a locally running scan server -
it all looks quite slick, especially as Phoebus has a scan editor and
monitor built in.

Before incorporating it into a system design, I'm interested to know
whether anyone else uses it as an integral part of their control systems
and what your experiences have been?

Thanks,

Ian

--
Ian Gillingham

-- 
Ian Gillingham

References:

Phoebus Scan Server Ian Gillingham via Tech-talk

Re: [EXTERNAL] Phoebus Scan Server Kasemir, Kay via Tech-talk

Navigate by Date:

Prev: RE: CS-Studio: File Manager configuration when executing external command Zhang, Tong via Tech-talk

Next: PyDevice modbus liuxiaomin via Tech-talk

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022>  2023  2024 

Navigate by Thread:

Prev: Re: [EXTERNAL] Phoebus Scan Server Kasemir, Kay via Tech-talk

Next: CS-Studio: File Manager configuration when executing external command Zhang, Tong via Tech-talk

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022>  2023  2024