Hello Greg,
I notice that all your set protocols don't expect any reply. Is that so that the
device does not send replies? Unfortunately, I cannot find the manual online.
The point is that if the device sends a reply and StreamDevice does not consume
it in the set protocol, then it may accidentally receive it processing the next
get protocol. This would be a race condition between the device sending the
reply and StreamDevice discarding old input when starting the next protocol.
Dirk
On Mon, 2023-06-26 at 19:34 +0000, Leblanc, Gregory via Tech-talk wrote:
> Hi folks,
>
> I'm still working on getting these Heinzinger PCU 50-300 supplies doing everything I want using EPICS. Today I thought I'd try reading the status word from the supply, so I added an mbbiDirect record. The custom sections of my .db file now read:
>
> record(ai, "$(P)$(R)GetCurrent") {
> field(DESC, "Read output current")
> field(DTYP, "stream")
> field(INP, "@devPCU50_300.proto getCurrent $(PORT) $(A)")
> # field(SCAN, "1 second")
> field(SCAN, "Passive")
> # field(PINI, "YES")
> field(EGU, "Amps")
> field(ESLO, "0.001")
> field(LINR, "SLOPE")
> }
>
> record(ao, "$(P)$(R)SetCurrent") {
> field(DESC, "Write output current")
> field(DTYP, "stream")
> # field(SCAN, "1 second")
> field(SCAN, "Passive")
> field(OUT, "@devPCU50_300.proto setCurrent(%d) $(PORT) $(A)")
> field(PINI, "YES")
> field(VAL, "0")
> # field(FLNK, "$(P)$(R)GetCurrent")
> field(EGU, "Amps")
> field(ESLO, "0.001")
> field(LINR, "SLOPE")
> }
>
> record(mbbiDirect, "$(P)$(R)StatusRegister") {
> field(DESC, "Status Register")
> field(NOBT, "24")
> field(DTYP, "stream")
> field(INP, "@devPCU50_300.proto getStatus $(PORT) $(A)")
> field(PINI, "YES")
> field(SCAN, "Passive")
> }
>
> But I'm seeing some unexpected behavior, somehow related to my other records. Above, the PINI field for the GetCurrent record is commented out. When I start the IOC in this state, the StatusRegister record is properly populated. If I set PINI to YES and start the IOC, the StatusRegister record is not properly populated. Running the command 'dbtr PCU50_300testStatusRegister' on the "broken" startup will update it so that it has the correct status. I've watched the console output when launching st.cmd, and browsed the logfiles that I generated, but I can't spot what I'm doing wrong. I've attached a logfile where I have the problem, and another where I don't. My .db, .proto, and st.cmd are at: https://github.com/leblancOUAL/PCU_50-300/
>
> I feel like the root cause is that somehow the replies to the different serial commands are getting mixed up, but I can't see how that's possible. It is more likely that I've done something silly along the way. Any hints for troubleshooting are greatly appreciated!
> Greg
>
> --
> Gregory Leblanc
> Accelerator Engineer
> Edwards Accelerator Lab - Ohio University
> 123 University Terrace
> Athens, OH 45701 USA
> leblanc at ohio.edu
> M: (401) 52-OUAL1 or (401) 526-8251
>
- Replies:
- RE: [External] Re: Strangeness in ai/mbbiDirect with StreamDevice on PINI Leblanc, Gregory via Tech-talk
- References:
- Strangeness in ai/mbbiDirect with StreamDevice on PINI Leblanc, Gregory via Tech-talk
- Navigate by Date:
- Prev:
Re: Display custom TCP data in CS-Studio Ralph Lange via Tech-talk
- Next:
RE: [External] Re: Strangeness in ai/mbbiDirect with StreamDevice on PINI Leblanc, Gregory 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: Strangeness in ai/mbbiDirect with StreamDevice on PINI Ralph Lange via Tech-talk
- Next:
RE: [External] Re: Strangeness in ai/mbbiDirect with StreamDevice on PINI Leblanc, Gregory 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
|