EPICS Controls 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  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: RE: [EXTERNAL] Representing stateless device commands?
From: "Feister, Scott via Tech-talk" <tech-talk at aps.anl.gov>
To: "Feister, Scott" <scott.feister at csuci.edu>, "Hartman, Steven" <hartmansm at ornl.gov>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Sat, 6 Jan 2024 00:28:26 +0000

Hi all,

 

To provide one possible solution that tries to act on what Mark and Steven suggested, could I have some thoughts on whether the below (untested) configurations look like a valid/reasonable approach to this problem?

 

Note below, I tried “passive” SCAN in hopes that this would let the record always be processed once every single time caput was called. I’m not sure if that’s needed or appropriate.

Also, I put “in 0” at the end of each proto function to have the PV represent whether the command was currently running, along the lines of Steven’s message.

 

Database:

 

record(bi,"MYLED:IncreaseBrightness"){

    field(DESC,"Slightly increase the LED brightness. Set this PV to True to activate a single adjustment; will automatically reset to False upon completion.")

    field(SCAN,"Passive”)

    field(DTYP,"stream")

    field(ONAM,"increasing”)

    field(ZNAM," inactive”)

    field(INP,"@led.proto IncreaseBrightness led_io")

    }

 

record(bi,"MYLED:DecreaseBrightness"){

    field(DESC,"Slightly decrease the LED brightness. Set this PV to True to activate a single adjustment; will automatically reset to False upon completion.")

    field(SCAN,"Passive”)

    field(DTYP,"stream")

    field(ONAM,"decreasing”)

    field(ZNAM,"inactive”)

    field(INP,"@led.proto DecreaseBrightness led_io")

    }

 

Proto:

 

IncreaseBrightness {

        out "IncreaseBrightness";

        in 0;

    }

 

DecreaseBrightness {

        out "DecreaseBrightness";

        in 0;

    }

 

 

Thanks,

 

Scott

 

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Feister, Scott via Tech-talk
Sent: Friday, January 5, 2024 4:11 PM
To: Hartman, Steven <hartmansm at ornl.gov>
Cc: tech-talk at aps.anl.gov
Subject: RE: [EXTERNAL] Representing stateless device commands?

 

CAUTION: This email originated from outside of CSUCI. Do not click links or open attachments unless you validate the sender and know the content is safe. Contact ITS if you have any concerns

 

Thanks Steven and Mark, for your welcoming and helpful responses.

 

I have the streamDevice proto files written, and am at the point where I’m wondering if there’s an easy way to capture what Steven is suggesting – forcing the PV back to zero immediately after the RS232 command “IncreaseBrightness” has been sent, such that the state of the binary PV “MYLED:IncreaseBrightness” represents whether we are “in process” of “Increasing Brightness”?

 

Here’s what I have in mind as far as sequence:

 

  1. “MYLED:IncreaseBrightness” is 0, its regular state.
  2. I invoke “caput MYLED:IncreaseBrightness 1”, changing the PV from 0 to 1.
  3. StreamDevice follows its protocol for processing a change in the PV, and sends an RS232 message of “IncreaseBrightness” to the device. StreamDevice awaits no reply, as the device gives none.
  4. [Somehow?] “MYLED:IncreaseBrightness” is now automatically forced back to 0.

 

I have steps 1-3 under control with StreamDevice, so I’m wondering about best practices to implement Step 4.

 

Thanks!

 

Scott

 

 

From: Hartman, Steven <hartmansm at ornl.gov>
Sent: Friday, January 5, 2024 1:22 PM
To: Feister, Scott <scott.feister at csuci.edu>
Cc: tech-talk at aps.anl.gov
Subject: Re: [EXTERNAL] Representing stateless device commands?

 

CAUTION: This email originated from outside of CSUCI. Do not click links or open attachments unless you validate the sender and know the content is safe. Contact ITS if you have any concerns

 

 

On Jan 5, 2024, at 1:47 PM, Feister, Scott via Tech-talk <tech-talk at aps.anl.gov> wrote:

My approach right now is to call them binary outputs (bo) records

 

 

 

Welcome to the forum.

 

Yes, that sounds about right. 

 

You can use the ONAM and ZNAM fields of the BO record to name the two states which may convey that it is indeed a process variable that is either doing something (i.e., increase the brightness) or not. In EPICS, pretty much everything is a process variable. 

 

-- 

Steven Hartman

 


References:
Representing stateless device commands? Feister, Scott via Tech-talk
Re: [EXTERNAL] Representing stateless device commands? Hartman, Steven via Tech-talk
RE: [EXTERNAL] Representing stateless device commands? Feister, Scott via Tech-talk

Navigate by Date:
Prev: RE: [EXTERNAL] Representing stateless device commands? Feister, Scott via Tech-talk
Next: Re: [EXTERNAL] Representing stateless device commands? Hartman, Steven via Tech-talk
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
Navigate by Thread:
Prev: RE: [EXTERNAL] Representing stateless device commands? Feister, Scott via Tech-talk
Next: Re: [EXTERNAL] Representing stateless device commands? Hartman, Steven via Tech-talk
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
ANJ, 05 Jan 2024 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·