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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Using the stream device @mismatch handler as an if conditional |
From: | "Paduan Donadio, Marcio" <[email protected]> |
To: | "[email protected]" <[email protected]> |
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
|