Hello Hyung Jin,
I will try to reproduce this behavior.
BTW: For binary protocols (using formats like %r or %R) using
Terminator/InTerminator is problematic because the binary data may contain the
terminator byte. Often, binary protocols have fixed message sizes. I suggest to
use MaxInput in that case.
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", "")
> ...
>
>
- Replies:
- Re: Streamdevice reads weird 1 byte null data Ralph Lange via Tech-talk
- References:
- Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
- Navigate by Date:
- Prev:
Re: PVA connection problem Ralph Lange via Tech-talk
- Next:
Re: PVA connection problem Michael Davidsaver 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 reads weird 1 byte null data Hyung Jin Kim via Tech-talk
- Next:
Re: Streamdevice reads weird 1 byte null data Ralph Lange 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
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·