Re: Streamdevice reads weird 1 byte null data

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

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", "")
> > > > > ...
> > > > >
> > > > >
> > >
> > > 
>