Experimental Physics and
Industrial Control System

Zimoch Dirk via Tech-talk <tech-talk at aps.anl.gov> · Wed, 20 Sep 2023 06:47:25 +0000

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System