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>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Thu, 21 Sep 2023 15:21:41 +0900
Hello,

When I asked a MOXA engineer about unexpected \x00 signals in RS485 communication, he suggested adjusting the DIP switch. If you check the manual, you may see “Adjustable Pull High/Low Resistors for the RS-485 Port”. After changing the resistance setting value from 150kOhm to 1kOhm, it was confirmed that the data was read normally without the \x00 signal. Thank you for your advice and comments.

Best regards
Hyung Jin Kim

On Wed, Sep 20, 2023 at 3:47 PM Zimoch Dirk <dirk.zimoch at psi.ch> wrote:
When not done correctly, 2-wire RS485 is prone to "echos" of the command you
send. A correctly made transceiver should disable its input while sending, but I
have had problems with newer MOXA DA-662 (but not older ones) re-enabling the
receiver too early. If MOXA uses the same chip in your nport 6650, it may be
unsuitable for 2-wire mode. You may want to try with a serial server from
another vendor.

Dirk

On Wed, 2023-09-20 at 08:15 +0900, Hyung Jin Kim wrote:
> Dear Dirk,
>
> We tested it by directly connecting the computer and the device using a USB-RS485 converter. We confirmed that the \x00 byte signal did not appear at all and everything worked perfectly.
>
> The method we are currently using connects our device to the MOXA nport 6650 serial device server, and RS485 communication is done in     a 2-wire method. It seems that the \x00 character occurs randomly when connected and used like this. However, we do not yet understand why this happens.
>
> Best regards,
> Hyung Jin Kim
>
> On 9/19/23 16:22, Zimoch Dirk wrote:
> > Hello Hyung Jin Kim,
> >
> > You wrote that is a serial device but you configure an IP port. Thus, I guess
> > you have some sort of RS232 (or maybe RS485) to ethernet converter in between.
> > Maybe that converter generates the 0x00 bytes?
> >
> > If you have an analyzer for serial, try to find out if the 0x00 bytes appear on
> > the serial bus, too. Otherwise try to connect your IOC directly to the serial
> > port, e.g. running it on a laptop with a RS232-USB converter.
> >
> > Dirk
> >
> > On Tue, 2023-09-19 at 08:43 +0900, Hyung Jin Kim wrote:
> > > 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", "")
> > > > > ...
> > > > >
> > > > >
> > >
> > > 


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
Re: 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
Re: 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: 回覆: 回覆: EPICS support for PI E-500 piezo controller Chiang, Liang-Chih [江良志] via Tech-talk
Next: No rule to make target '../../../lib/linux-x86_64/libstream.a' error. Peter Pitfield 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 Ralph Lange via Tech-talk
Next: RE: IC101 support? Guerrero, Chris 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, 21 Sep 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·