Re: Making EPICS IOC admin tasks easier for end-users?

[Andrew Gomella <andrewgomella@gmail.com>]

Thank you both for the suggestions. This seems much more easier and straightforward than I anticipated. 

Ulrik, I am definitely interested in your "procServControl" module, particularly how you were able to pipe the IOC output into EDM. If you could publish it online that would be great. 

Thanks!

Andrew

 

On Mon, Mar 16, 2015 at 5:11 AM, <ulrik.pedersen@diamond.ac.uk> wrote:

On beamlines at Diamond we have solved this with a state notation language application (another IOC) which controls and monitors the state of procServ as a client. So each beamline has a "procServ control IOC" that provide control and monitoring of all the soft-iocs on that beamline. The users can then control the soft-IOCs directly through an EDM screen (see attached screenshot) or any other CA client.

We can publish our "procServControl" support module if this is of interest...

Cheers,
Ulrik

________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Ralph Lange [Ralph.Lange@gmx.de]
Sent: 15 March 2015 20:11
To: EPICS Tech-Talk
Subject: Re: Making EPICS IOC admin tasks easier for end-users?

Hi Andrew,

Yup - if you want to allow restarting through Channel Access, that's the
way to do it.
With the appropriate command line option, procServ will restart any
child process that exits. On regular IOCs, devIocStats is a portable way
to have CA execute a reset/exit. On your python IOCs, you will have to
add one PV that calls exit() when it is written to.
The minimum common PV that you can use to show the IOC is alive would be
the PV you use to issue the reset. If you add the functionality to the
python IOCs, that PV can be made common across all your IOCs.

Another option would be to use procServ's kill/restart command to
restart the IOC. That does not need devIocStats or any addition to the
python IOCs, but needs a bit more thought on the client side: The button
will have to connect to the procServ session (using telnet or netcat)
and send the restart control character. You would have to find a
reliable way to to that (start with echoing the control character to
netcat).
Advantage: works with*any* child of procServ, not just IOCs.
Disadvantages: you would still need a common PV to show the IOC is up,
and the mechanism needs to be configured (IP and port for each IOC),
while in the other case the reset PV name can be nice and generic, and
you don't need to know the procServ ports.

Cheers,
~Ralph

On 15/03/2015 20:46, Andrew Gomella wrote:
> Hi everyone,
>
> For some context, we are constantly switching hardware in and out so
> we are constantly stopping/starting soft IOC's. Some of our users only
> use EPICS rarely, and I would like to be able to tell them (over the
> phone for instance) to "restart ______ IOC" without walking through a
> multi-step procedure.
>
> Right now we can make it very easy for end users to start IOC's by
> using the "execute shell script" button on caqtdm (or MEDM). However,
> what I would like is a way for the end user to see which IOC's are
> running, and have a few simple buttons like start/stop to control them.
>
> I was thinking of installing both procserv and devIocStats and using
> these together. (Though deviocstats won't work with several of our
> python channel access servers)
>
> I was thinking a simple, not very elegant way, would be to choose some
> arbitrary PV from each given IOC and monitor that to determine whether
> to indicate to the end user whether the IOC is online.
>
> Look forward to hearing any suggestions!
>
> Thanks,
> Andrew
>
>

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom