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> 2025 | 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> 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: CryoTel GT Cooler: different startup and shutdown StreamDevice protocols |
From: | boj via Tech-talk <tech-talk at aps.anl.gov> |
To: | Ralph Lange <ralph.lange at gmx.de>, EPICS Tech Talk <tech-talk at aps.anl.gov> |
Date: | Mon, 27 May 2024 07:34:20 +0200 |
Dear Ralph
Thanks for the input.
I do indeed not need the response (I can just check later if all
went well).
However, how do I write an IN protocol statement that will just
accept any input from the device (or stated alternatively, empty
the serial buffer), my device sends multiple lines (different
number of likes for the different responses).
With such a strategy, I can just do something like :
out "command to turn on"
wait
in "empty buffer"
Best
Bo
On Fri, 24 May 2024 at 07:38, boj <lister at f77.dk> wrote:
Thanks for the suggestion.
I read up om the BO record (I am running 3.15) using the HIGH field for the "Push bottom" behavior.
As I understand that documentation, the record is processed again when going low after the specified time.I guess that will mean that the protocol is executed twice? Any way to avoid that?
Yes, correct. No decent way to avoid that.Then, just don't set the HIGH field. Whatever value is being written to the record, the protocol will be executed.
This brings back the problem that the response from the device depends on its current state
(it is different when going from On -> Off, and from Off -> Off).
As Dirk was asking: Do you need the response? Can't you just ignore it?
A Simple push button that executes an protocol entry once will be very useful for me.
Switch or buttons is a design choice.
Buttons always need a status, else you never know the current device state.A switch position needs to be readable from the device or persisted (autoSaveRestore), else it might end up in the wrong position after an IOC reboot.
Discussing with colleagues, I found some very strong, almost religious, opinions in the underlying "trigger by state or by pulse" question.
The EPICS database allows to implement one using the other. Flexibility is nice!
Cheers,~Ralph
ps. Having a record named after you is pretty cool.