Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 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
<== Date ==> <== Thread ==>

Subject: Using the stream device @mismatch handler as an if conditional
From: "Paduan Donadio, Marcio" <marcio@slac.stanford.edu>
To: "Tech-talk@aps.anl.gov" <Tech-talk@aps.anl.gov>
Date: Fri, 27 Oct 2017 00:14:46 +0000

Hello.


I have a device that takes 3.5 seconds to run a measurement and I don't want that some process send a command that changes a parameter while the measurement is in progress.


I am using stream device and asyn to communicate with it.


My idea was to ever send a command asking for the measurement status when the parameter is changed. If the device is busy, nothing happens. If it is idle, the parameter is changed.


As stream device has no if conditional, I used this idea in the protocol file:


set_freq_stop {
        out ":STAT:OPER:COND?";
        in "Instrument Busy";

        # We change the parameter only after we are sure that the device status
        # is not "Instrument Busy".
        @mismatch {
                out ":SENS:PN:FREQ:STOP:%f%(\$1)s";
                in "Frequency stop set";
        }
}


So, if the equipment sends back "Instrument Busy", the protocol match and that's it. Nothing more happens. But when the equipment sends "Instrument Ready" the @mismatch exception handler is activated and the command to change the parameter is sent.


This is working fine, but I see red warnings in the IOC shell every time the @mismatch handler is used.


So, this brings me 2 questions:

1 - Is there a way to avoid these warnings case a @mismatch is activated? For the other cases, the warnings must be shown.

2 - Is there a better way to do this with stream device? I could read the measurement status in a record, on a periodic SCAN basis, but this don't avoid the case where a parameter is changed between one scan processing and the next, just after the measurement started. In fact I am disabling record processing of the status while the device is idle and re-enabling after the measurement started, just to reduce the number of commands sent to the equipment.


Thank you for your suggestions.


Márcio Paduan Donadio
Control Systems Engineer
SLAC National Accelerator Laboratory
Advanced Instrumentation for Research Division
2575 Sand Hill Rd
Menlo Park CA 94025
Office (650) 926-5007​



Navigate by Date:
Prev: Controls Engineer Job at Brookhaven NSLS-II New York, USA Farnsworth, Richard
Next: Re: medm sigsev on related display Shuei YAMADA
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
Navigate by Thread:
Prev: Controls Engineer Job at Brookhaven NSLS-II New York, USA Farnsworth, Richard
Next: RTEMS+zoneset seems to be broken Ricardo Cardenes
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
ANJ, 27 Oct 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·