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

[<tom.cobb@diamond.ac.uk>]

This is published here:
http://controls.diamond.ac.uk/downloads/support/procServControl/

Thanks,
Tom Cobb

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> bounces@aps.anl.gov] On Behalf Of ulrik.pedersen@diamond.ac.uk
> Sent: 16 March 2015 09:11
> To: Ralph.Lange@gmx.de; andrewgomella@gmail.com; tech-talk@aps.anl.gov
> Subject: RE: Making EPICS IOC admin tasks easier for end-users?
> 
> 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


-- 
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