Re: Streamdevice reads weird 1 byte null data

[Hyung Jin Kim via Tech-talk <tech-talk at aps.anl.gov>]

    Dear Dirk,
    
    I didn't expect that the device itself would randomly send a value
    of \x00 along with the expected data. 
    I checked it using a simple Python code, and it seems to be a signal
    sent from the device. 
    Thus this issue seems to have nothing to do with Streamdevice.
    I think I need to take a look at my device.
    Thank you for the comment.
    
    Best regards,
    Hyung Jin Kim

On 9/18/23 18:44, Zimoch Dirk wrote:

> Hello Hyung Jin Kim,
>
> Unfortunately, I cannot reproduce your problem.
>
> I have set up a simulation server that always sends the sequence
> "\x16\x16\x80\x00\x08\x00\x80\x22\x43\x00\x00\xc0\x40\x6d\x1a"
>
> I have no problem at all to read this. It always shows as expected:
>
> 2023/09/18 11:18:38.028 localhost:40000 read 15
>
> 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a 
>
> This is read as the value 162.5.
>
> I never got unexpected 00 bytes. The only way to get it is to modify the server
> to actually send "\x00" in between the expected data.
> Thus I guess, your devices actually does this.
>
> However, the protocol fails when 0x1a is part of value or checksum. Therefore, I
> changed the protocol to:
>
> MaxInput=16;
> query_head    = "\x16\x16\x80";
> query_tail    = "\x00%2<sum8>";
> get_dev_info
> {
>     out  $query_head "\x00" $query_tail;
>     in  $query_head "\x00\x08"
>         "%#4R"
>         "%2<sum8>\x1a";
> }
>
> Note that now "\x1a" at the end needs to be read explicitly.
>
> Of course, this does not solve the problem with the unexpected 00 bytes.
>
> We need to find out what is happening on your network.
> Can you capture the network traffic between your device and your IOC with
> wireshark (or tcpdump or similar)?
> What happens if you set SCAN=Passive? Does the device still send 00?
> Are there any other records in your IOC that may make your device sending 00?
>
>
> BTW: I strongly recommend to never use 'ExtraInput = Ignore;' except you really,
> really know you really, really, really need it.
>
> Dirk
>
>
>
>
> On Fri, 2023-09-15 at 15:27 +0900, Hyung Jin Kim via Tech-talk wrote:
> > Dear All,
> >
> > We have some device controlled via raw serial communication. Streamdevice reads a weird 1 byte null data (as far as we are understanding). 
> > We expect that 15 byte data are read back normally when 7 byte command is sent.
> > send cmd: 0x16 0x16 0x80 0x00 0x00 0x80 0x1A
> > read-back: 0x16 0x16 0x80 0x00 0x08 (two 4 byte float) checksum 0x1A
> >
> > However, unexpected 1 byte  null(\x00) character is read. Sometimes, this null character is read together with our read-back data, which causes an input error as shown in iocshell console message.
> > Do you have any idea about this?
> >
> > Thanks,
> > Hyung JIn Kim
> >
> > =================================================================
> > iocshell console message:
> >
> > 2023/09/15 10:57:29.891 192.168.85.191:4001 write 7
> >
> > 16 16 80 00 00 80 1a
> > 2023/09/15 10:57:29.903 192.168.85.191:4001 read 15
> >
> > 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
> > 2023/09/15 10:57:29.912 192.168.85.191:4001 read 1
> >
> > 00
> > 2023/09/15 10:57:31.891 192.168.85.191:4001 write 7
> >
> > 16 16 80 00 00 80 1a
> > 2023/09/15 10:57:31.895 192.168.85.191:4001 read 1
> >
> > 00
> > 2023/09/15 10:57:31.903 192.168.85.191:4001 read 15
> >
> > 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
> > 2023/09/15 10:57:31.912 192.168.85.191:4001 read 1
> >
> > 00
> > 2023/09/15 10:57:32.913154 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: Input "<00><16><16><80><00><08><00><80>"C<00><00><c0>@m<1a><00>"
> > 2023/09/15 10:57:32.913470 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: mismatch after 0 bytes ""
> > 2023/09/15 10:57:32.913730 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: got "<00><16><16><80><00><08><00><80>"C..." where "<16>" was expected
> > 2023/09/15 10:57:33.891 192.168.85.191:4001 write 7
> >
> > 16 16 80 00 00 80 1a
> > 2023/09/15 10:57:33.903 192.168.85.191:4001 read 15
> >
> > 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
> > 2023/09/15 10:57:33.912 192.168.85.191:4001 read 1
> >
> > 00
> > 2023/09/15 10:57:35.891 192.168.85.191:4001 write 7
> >
> > 16 16 80 00 00 80 1a
> > 2023/09/15 10:57:35.903 192.168.85.191:4001 read 15
> >
> > 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
> > 2023/09/15 10:57:35.912 192.168.85.191:4001 read 1
> >
> > 00
> > 2023/09/15 10:57:37.891 192.168.85.191:4001 write 7
> >
> > 16 16 80 00 00 80 1a
> > 2023/09/15 10:57:37.903 192.168.85.191:4001 read 15
> >
> > 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
> > 2023/09/15 10:57:37.911 192.168.85.191:4001 read 1
> >
> > 00
> > 2023/09/15 10:57:39.891 192.168.85.191:4001 write 7
> >
> > 16 16 80 00 00 80 1a
> > 2023/09/15 10:57:39.895 192.168.85.191:4001 read 1
> >
> > 00
> > 2023/09/15 10:57:39.903 192.168.85.191:4001 read 15
> >
> > 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
> > 2023/09/15 10:57:40.904437 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: Input "<00><16><16><80><00><08><00><80>"C<00><00><c0>@m<1a>"
> > 2023/09/15 10:57:40.904748 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: mismatch after 0 bytes ""
> > 2023/09/15 10:57:40.905012 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: got "<00><16><16><80><00><08><00><80>"C..." where "<16>" was expected
> > 2023/09/15 10:57:41.891 192.168.85.191:4001 write 7
> >
> > 16 16 80 00 00 80 1a
> > 2023/09/15 10:57:41.903 192.168.85.191:4001 read 15
> >
> > 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
> > 2023/09/15 10:57:41.911 192.168.85.191:4001 read 1
> >
> > 00
> > ...
> >
> > ===========================================================================
> > For reference, here is a part of our protocol:
> > Terminator  = "\x1A";
> > ExtraInput    = Ignore;
> > query_head    = "\x16\x16\x80";
> > query_tail    = "\x00%2<sum8>";
> > get_dev_info
> > {
> >     Separator = "";
> >     out  $query_head "\x00" $query_tail;
> >     in  $query_head "\x00\x08"
> >         "%#4R"
> >         "%2<sum8>";
> > }
> >
> > Our database is as follows:
> > record(aai, "${SYS}${SUBSYS}${DEV}${SUBDEV}#getInfo") {
> >   field (DESC, "Get Freq and Firmware")
> >   field (SCAN, "2 second")
> >   field (DTYP, "stream")
> >   field (INP,  "@sspaRFPT.proto get_dev_info(${SYS}${SUBSYS}${DEV}${SUBDEV}) $(PORT)")
> >   field (NELM, "2")
> >   field (FTVL, "FLOAT")
> > }
> >
> > ===========================================================================
> > Our st.cmd looks like :
> > ...
> > drvAsynIPPortConfigure("PHWRB41", "192.168.85.191:4001", 0,0,0)
> > asynSetOption("PQWR001", 0, "baud", "115200")
> > #asynSetOption("PQWR001", 0, "bits", "8")
> > #asynSetOption("PQWR001", 0, "stop", "1")
> > #asynSetOption("PQWR001", 0, "parity", "none")
> > ...
> > asynSetTraceMask  ("PHWRB41", 0, 9)
> > asynSetTraceIOMask("PHWRB41", 0, 4)
> > dbLoadTemplate("${TOP}/db/sspaRFPT.substitutions", "")
> > ...
> >
> >
> >       
>