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:
-
“MYLED:IncreaseBrightness” is 0, its regular state.
-
I invoke “caput MYLED:IncreaseBrightness 1”, changing the PV from 0 to 1.
-
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.
-
[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
My approach right now is to call them binary outputs (bo) records
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.