EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20232024  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  <20232024 
<== Date ==> <== Thread ==>

Subject: Re: Streamdevice reads weird 1 byte null data
From: Hyung Jin Kim via Tech-talk <tech-talk at aps.anl.gov>
To: Zimoch Dirk <dirk.zimoch at psi.ch>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 19 Sep 2023 08:43:28 +0900
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", "")
...




Replies:
Re: Streamdevice reads weird 1 byte null data Maren Purves via Tech-talk
Re: Streamdevice reads weird 1 byte null data Zimoch Dirk via Tech-talk
References:
Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
Re: Streamdevice reads weird 1 byte null data Zimoch Dirk via Tech-talk

Navigate by Date:
Prev: Re: Problem with CA nameserver and CA_V413 protocol Andrew Johnson via Tech-talk
Next: Re: Streamdevice reads weird 1 byte null data Maren Purves 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  <20232024 
Navigate by Thread:
Prev: Re: Streamdevice reads weird 1 byte null data Zimoch Dirk via Tech-talk
Next: Re: Streamdevice reads weird 1 byte null data Maren Purves 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  <20232024 
ANJ, 19 Sep 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·