RE: [EXTERNAL] Representing stateless device commands?

["Feister, Scott via Tech-talk" <tech-talk at aps.anl.gov>]

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

hartmansm at ornl.gov