RE: Streamdevice - record only completes processing every other activation

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

Hi Dirk,

Thank you for your help.

The 'var streamDebug' reveals stream isn't doing anything during the off-cycles when nothing happens, and when everything works correctly, processing completes (RPRO and PACT 0):
2024/03/21 10:35:48.879729 SRAM_TEST StreamCore.cc:564: StreamCore::evalCommand(_SRAM_TEST:SWEEP_CMD_EXSC): activeCommand = end
2024/03/21 10:35:48.879742 SRAM_TEST StreamCore.cc:465: StreamCore::finishProtocol(_SRAM_TEST:SWEEP_CMD_EXSC, Success) bus owner
2024/03/21 10:35:48.879752 SRAM_TEST AsynDriverInterface.cc:610: AsynDriverInterface::unlock(_SRAM_TEST:SWEEP_CMD_EXSC)
2024/03/21 10:35:48.879763 SRAM_TEST AsynDriverInterface.cc:1468: AsynDriverInterface::finish(_SRAM_TEST:SWEEP_CMD_EXSC) start
2024/03/21 10:35:48.879772 SRAM_TEST AsynDriverInterface.cc:1478: AsynDriverInterface::finish(_SRAM_TEST:SWEEP_CMD_EXSC) done
2024/03/21 10:35:48.879784 SRAM_TEST StreamEpics.cc:1025: Stream::protocolFinishHook(_SRAM_TEST:SWEEP_CMD_EXSC, Success)
2024/03/21 10:35:48.879812 cbLow StreamEpics.cc:1103: recordProcessCallback(_SRAM_TEST:SWEEP_CMD_EXSC) processing record
2024/03/21 10:35:48.879824 cbLow StreamEpics.cc:899: Stream::process(_SRAM_TEST:SWEEP_CMD_EXSC)
2024/03/21 10:35:48.879834 cbLow StreamEpics.cc:913: Stream::process(_SRAM_TEST:SWEEP_CMD_EXSC) ready. don't convert
2024/03/21 10:35:48.879851 cbLow StreamEpics.cc:1107: recordProcessCallback(_SRAM_TEST:SWEEP_CMD_EXSC) processing record done

 so not a streamDevice Issue. But, what I did discover, is that the bo 'activation' record, which is momentary via the HIGH field, somehow isn't conveying the reset to the actual stream record.

After a successful processing:
epics> dbgf _SRAM_TEST:SWEEP_CMD_EXSC.A
DBF_DOUBLE:         1         
epics> dbgf _SRAM_TEST:SWEEP_CMD_EXSC.VAL
DBF_DOUBLE:         1   

These should be 0. The RPRO message, I think, is coming when the momentary activation bo goes to zero. Streamdevice isn't done, and it's getting poked by the bo going back to zero while processing is still in-progress. I solved it by bumping up the HIGH field of the bo record, but perhaps I should create a loop-back link that resets the bo record.

-Evan

-----Original Message-----
From: Zimoch Dirk <dirk.zimoch at psi.ch> 
Sent: Thursday, March 21, 2024 10:13 AM
To: tech-talk at aps.anl.gov; Daykin, Evan <daykin at frib.msu.edu>
Subject: Re: Streamdevice - record only completes processing every other activation

[EXTERNAL] This email originated from outside of FRIB
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

>  

>  

>