Hi Evan,
This is a hard to debug without your device.
I am a bit surprised about the "\r\0\n" line terminators in your code but if
that is what the device sends, so may it be.
BTW: I usually break such long lines for readability:
in "\r\0\n\r\0\n"
"Chip: 0\r\0\n"
"# of Events: %(\$1:EVT_RD_CHIP0)d\r\0\n"
"Chip: 1\r\0\n"
"# of Events: %(\$1:EVT_RD_CHIP1)d\r\0\n"
"Chip: 2\r\0\n"
"# of Events: %(\$1:EVT_RD_CHIP2)d\r\0\n"
"Chip: 3\r\0\n"
"# of Events: %(\$1:EVT_RD_CHIP3)d";
As far as I know, RPRO goes to 1 when something writes to a record while it is
still processing (and thus locked). I thought that should make the record
process again once the current processing has finished.
To me this looks like the record is waiting for something and thus has not
finished processing. Probably for 2 seconds (ReadTimeout=2000).
Have you tried with 'var streamDebug 1'?
Dirk
On Wed, 2024-03-20 at 18:11 +0000, Daykin, Evan via Tech-talk wrote:
> Hi,
>
> I have an unusual issue I haven’t seen before. I have a mode selector, activation bo, directed through a fanout (single output with SELL), which finally sends out a read command, like this:
>
>
> record(mbbo, "$(D):MODE_CMD_SWEEP"){
> field(ZRST, "Fullsweep")
> field(ZRVL, "0")
> field(ONST, "Fullsweep4") <- SELECTED
> field(ONVL, "1")
> field(TWST, "Simulsweep4")
> field(TWVL, "2")
> }
>
> #User presses this to execute a scan, stays high for 0.5s
> record(bo, "$(D):SWEEP_CMD_EXSC"){
> field(ZNAM, "Idle")
> field(ONAM, "Sweep")
> field(HIGH, "0.5")
> field(VAL, "0")
> field(FLNK, "_$(D):SWEEP_EXSC")
> }
>
> record(fanout, "_$(D):SWEEP_EXSC"){
> field(SELM, "Specified")
> field(SELL, "$(D):MODE_CMD_SWEEP")
> field(LNK0, "_$(D):SWEEP_CMD_DBG")
> field(LNK1, "_$(D):SWEEP_CMD_EXSC") <- SELECTED
> field(LNK2, "_$(D):SWEEP_CMD_SIM")
> }
>
> record(calcout, "_$(D):SWEEP_CMD_EXSC"){
> field(DTYP, "stream")
> field(INPA, "$(D):SWEEP_CMD_EXSC")
> field(INPB, "$(D):PAT_CSET_SWEEP")
> field(CALC, "A")
> field(OOPT, "Transition To Non-zero")
> field(OUT, "@sram.proto fullsweep4($(D)) $(HOST)")
> }
>
> The protocol file entry looks like this:
>
> fullsweep4{
> ReadTimeout=2000;
> InTerminator="\r\0\n\r\0\n>";
> out "fullsweep4 c %(_\$1:SWEEP_CMD_EXSC.B)#x";
> in "\r\0\n\r\0\nChip: 0\r\0\n# of Events: %(\$1:EVT_RD_CHIP0)d\r\0\nChip: 1\r\0\n# of Events: %(\$1:EVT_RD_CHIP1)d\r\0\nChip: 2\r\0\n# of Events: %(\$1:EVT_RD_CHIP2)d\r\0\nChip: 3\r\0\n# of Events: %(\$1:EVT_RD_CHIP3)d";
> }
> it wants a message of the form:
>
> Chip: 0
> # of Events: 131072
> Chip: 1
> # of Events: 131072
> Chip: 2
> # of Events: 131072
> Chip: 3
> # of Events: 131072
>
> >
>
> But, the last record (calcout) _SWEEP_CMD_EXSC only fires every other time I activate the bo SWEEP_CMD_EXSC, and wireshark confirms it’s only sending out the inquiry every other click as well. Setting TPRO shows:
>
> epics> ca:daykin@diag-cam: dbProcess of '_SRAM_TEST:SWEEP_CMD_EXSC'
> cbLow: dbProcess of '_SRAM_TEST:SWEEP_CMD_EXSC' <- Nothing actually happened, nothing in wireshark, readback records don’t update
>
> ca:daykin@diag-cam: dbProcess of '_SRAM_TEST:SWEEP_CMD_EXSC'
> cbLow: dbProcess of Active '_SRAM_TEST:SWEEP_CMD_EXSC' with RPRO=0 <- Record fired correctly, readback records update
>
> What does this indicate? What is RPRO doing?
>
> Thank you,
> Evan
>
>
>
- Replies:
- RE: Streamdevice - record only completes processing every other activation Daykin, Evan via Tech-talk
- Re: Streamdevice - record only completes processing every other activation Zimoch Dirk via Tech-talk
- References:
- Streamdevice - record only completes processing every other activation Daykin, Evan via Tech-talk
- Navigate by Date:
- Prev:
Re: PVXS IOC Philosophy Timo Korhonen via Tech-talk
- Next:
Re: PVXS IOC Philosophy Kasemir, Kay 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:
Streamdevice - record only completes processing every other activation Daykin, Evan via Tech-talk
- Next:
RE: Streamdevice - record only completes processing every other activation Daykin, Evan 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>
|