Modbus write single command: help!

Digi One IA/IAP
1

I’m having problems with the Modbus write single register command when it goes through a Digi One IAP. Write multiple works, but every time I attempt a write single command the Digi replies with an exception 11.

Setup is a win2k PC running a Modbus master utility (the one at http://members.tripod.com/~mbserver/), talking Modbus/TCP to a Digi One IAP over Ethernet. The serial port of the Digi is configured as RS-232 running Modbus/RTU (9600-8E1) to a piece of embedded hardware acting as a Modbus slave. I’ve written the Modbus slave code on the embedded side.

If I take the Digi out of the loop and go Modbus/RTU over '232 to the embedded device, everything is fine. From the embedded side, I can’t see any difference in the Modbus/RTU datastream. For the write single 0=0 command, the embedded side receives 8 bytes:
01 06 00 00 00 00 89 CA
and replies with 8 bytes:
01 06 00 00 00 00 89 CA

I’ve turned on the trace (set trace state=on mask=ia:+info+debug), but it’s a little hard for me to read. (Is this stuff documented anywhere?) In particular, I’m not sure which lines show data on the TCP side and which show the serial side. Oh, the “CH01 seeing ECHO - check wiring” message seems important, too.

Any thoughts?

Here’s a trace with a write multiple command (0=0):

00:02:45 IA INFO: mbtcp:m02 Client Connecting!
00:02:45 IA INFO: mbtcp:m02 Rcv Req(5) Seq:0x0000 Len:11
00:02:45 IA INFO: mbtcp:m02 Slv:1 WrNReg:4x00001 Cnt=2
00:02:45 IA DEBG: 1 10 0 0 0 2 4 0 0 0 0
00:02:45 IA INFO: mbrtu:CH01 Snd Req:5
00:02:45 IA INFO: mbrtu:CH01 Slv:1 WrNReg:4x00001 Cnt=2
00:02:45 IA DEBG: 1 10 0 0 0 2 4 0 0 0 0
00:02:45 IA DEBG: f3 af
00:02:45 IA DEBG: MBRTU: Estimated Rsp length is 8
00:02:45 IA DEBG: mbrtu:CH01 wait more data
00:02:45 IA DEBG: mbrtu:CH01 wait more data
00:02:45 IA INFO: mbrtu:CH01 recv resp:5; completed in 80 msec
00:02:45 IA INFO: mbrtu:CH01 start of rsp min:48 avg:53 max:58 msec
00:02:45 IA INFO: mbrtu:CH01 complete rsp min:70 avg:81 max:91 msec
00:02:45 IA INFO: mbrtu:CH01 Slv:1 Write Complete
00:02:45 IA DEBG: 1 10 0 0 0 2
00:02:45 IA INFO: mbtcp:m02 Snd Rsp(5) Seq:0x0000 Len:6
00:02:45 IA INFO: mbtcp:m02 Slv:1 Write Complete
00:02:45 IA DEBG: 1 10 0 0 0 2
00:02:47 IA INFO: mbtcp:m02 idle timeout, closing connection

And a trace of a write single command that returns an exception 11 (0=0):

00:02:54 IA INFO: mbtcp:m02 Client Connecting!
00:02:54 IA INFO: mbtcp:m02 Rcv Req(6) Seq:0x0000 Len:6
00:02:54 IA INFO: mbtcp:m02 Slv:1 Wr1Reg:4x00001 = 0
00:02:54 IA DEBG: 1 6 0 0 0 0
00:02:54 IA INFO: mbrtu:CH01 Snd Req:6
00:02:54 IA INFO: mbrtu:CH01 Slv:1 Wr1Reg:4x00001 = 0
00:02:54 IA DEBG: 1 6 0 0 0 0
00:02:54 IA DEBG: 89 ca
00:02:54 IA DEBG: mbrtu:CH01 wait more data
00:02:54 IA DEBG: MBRTU: Estimated Rsp length is 8
00:02:54 IA DEBG: mbrtu:CH01 wait more data
00:02:54 IA INFO: mbrtu:CH01 seeing ECHO - check wiring
00:02:54 IA INFO: mbtcp:m02 Snd (6) is Exception Seq:0x0000 Len:6
00:02:54 IA INFO: mbtcp:m02 Slv:1 Err/Exception = No Response or Timeout
00:02:56 IA INFO: mbtcp:m02 idle timeout, closing connection

The firmware version is: Version 82000770_F 12/06/2005
Here’s the Digi One IAP config file:
[i]

Digi One IAP Version 82000770_F 12/06/2005

set config dhcp=off
set config myname=“” domain=“”
set config ip=192.168.0.68 submask=255.255.255.0
set config realport=771 securerealport=1027 sockets=2000 redirect=ignore tbreak=std
set config optimize=latency
set keys prevcmd=^P nextcmd=^N forwchar=^F backchar=^B
set config boothost=0.0.0.0 bootfile=“” tftpboot=no
set ethernet speed=auto duplex=half
set config rarp=on
set config ping-arp=on
set web timeout=300
set profile range=1 profile=ia
set profile range=2 profile=realport
set line range=1 parity=E csize=8 error=ignore
set line range=1 baud=9600 stopb=1 break=ignore inpck=off istrip=off onlcr=off otab=off
set flow range=1 ixon=off aixon=off ixoff=off ixany=off itoss=off altpin=off forcedcd=off
set flow range=1 dtr=off cts=off dcd=off dsr=off ri=off
set flow range=1 rts=off pre-delay=0 post-delay=0

set keys range=1 xon=^Q xoff=^S xona=^Q xoffa=^S lnext=^V

set line range=2 parity=N csize=8 error=ignore
set line range=2 baud=9600 stopb=1 break=ignore inpck=off istrip=off onlcr=off otab=off
set flow range=2 ixon=off aixon=off ixoff=off ixany=off itoss=off altpin=off forcedcd=off
set flow range=2 dtr=off cts=off dcd=off dsr=off ri=off
set flow range=2 rts=off pre-delay=0 post-delay=0

set keys range=2 xon=^Q xoff=^S xona=^Q xoffa=^S lnext=^V

set keys range=1 eof=^D erase=^H intr=^C kill=^U
set keys range=2 eof=^D erase=^H intr=^C kill=^U
set snmp run=on auth_trap=off login_trap=off
set snmp cold_start_trap=off link_up_trap=off

set snmp location=“” name=“” contact=“”

set device name=“gendialer” baud=no dialer=genmdm chat=no
set buffers range=1 size=32 state=off
set buffers range=2 size=32 state=off
set port range=1 dev=ia sess=4 termtype=“vt100” edelay=1 auto=off bin=off
set port range=1 uid=none group=none dport=none
set port range=1 dest=none
set port range=1 scriptname=none
set port range=1 keepalive=off flushstchar=default autoservice=default
set port range=1 idletime=0

set port range=2 dev=rp sess=4 termtype=“vt100” edelay=1 auto=off bin=off
set port range=2 uid=none group=none dport=none
set port range=2 dest=none
set port range=2 scriptname=none
set port range=2 keepalive=off flushstchar=default autoservice=default
set port range=2 idletime=0

set socketid range=1 state=off string=“SOCKETID”
set socketid range=2 state=off string=“SOCKETID”

set ia table=1 name=table1
set ia table=1 addroute=1 active=on protocol=modbusrtu
set ia table=1 route=1 protaddr=0-255 type=serial port=1

set ia master=1 active=on protocol=modbustcp transport=tcp ipport=502 table=1
set ia master=1 chartimeout=50ms messagetimeout=2500ms idletimeout=2sec
set ia master=1 permit=all priority=medium
set ia master=1 errorresponse=on broadcast=on fixedaddress=auto
set ia master=1 exttimeout=disabled

set ia serial=1 protocol=modbusrtu type=slave table=1
set ia serial=1 messagetimeout=2500ms slavetimeout=200ms chartimeout=20ms
set ia serial=1 lineturndelay=0ms
set ia serial=1 errorresponse=off broadcast=on fixedaddress=auto
set ia serial=1 rbx=off
set ia serial=1 exttimeout=disabled

set udpserial range=1 rmax=1024 rtime=100 closetime=0 overflow=forward strip=off
set udpserial range=1 delimiters=“”
set udpserial range=2 rmax=1024 rtime=100 closetime=0 overflow=forward strip=off
set udpserial range=2 delimiters=“”
set secureaccess ssh=on
set secureaccess ssh-keyauth=on
set secureaccess ssh-pwdauth=on
set secureaccess telnet=on
set secureaccess http=on
set secureaccess rlogin=on
set secureaccess rsh=on
set secureaccess realport=on
set secureaccess reversetcp=on
set secureaccess reversetelnet=on
set secureaccess snmp=on
set secureaccess securerealport=on
set secureaccess securesockets=on
set secureaccess https=on
set secureaccess lpd=on

set logport ra=1 state=off
set logport ra=1 mode=syslog
set logport ra=1 udpport=514
set logport ra=1 rmax=1024
set logport ra=1 rtime=100
set logport ra=1 pri=134
set logport ra=1 strip=off
set logport ra=1 delim=“”
set logport ra=2 state=off
set logport ra=2 mode=syslog
set logport ra=2 udpport=514
set logport ra=2 rmax=1024
set logport ra=2 rtime=100
set logport ra=2 pri=134
set logport ra=2 strip=off
set logport ra=2 delim=“”
[/i]

2

Sorry, this is a known issue in the “F” firmware - we had a large user seeing host software problems when they had broken RS-485 lines and the DOIAP in effect returned an echo … the host software wasn’t smart enough to handle this as “no reply” and won’t failover to a second serial line. So “F” firmware watches for an echo & treats it as timeout. But I goofed and didn’t realize that the Func 5 & 6 response ALWAYS look like echos.

I uploaded a fixed beta firmware at my own site:
http://iatips.com/docs/82x770_F1_SA3_RelNotes.txt
http://iatips.com/docs/DOIAP_F1_SA3.zip

This F1_SA3 solves this problem. Note: there won’t be an F1 firmware, as we are actually making a “G” for the new hardware.

3

You will need a new firmware version to correct this.
It is not yet released.

4

You will need a new firmware version to correct this.
It is not yet released. It is too large to post here so I will send it to your email address.

5

> You will need a new firmware version to correct
> this.
> It is not yet released. It is too large to post here
> so I will send it to your email address.

Got it. It’ll be later today before I can test it out.

Is there any potential workaround for the released firmware? I can easily update the firmware in my embedded hardware, but a Digi firmware update is out of my hands and may not be possible at this time.

6

The beta firmware update was not helpful.

Here’s a trace from the write single command:

set trace state=on mask=ia:+info+debug

00:01:26 IA INFO: mbtcp:m02 Client Connecting!
00:01:26 IA INFO: mbtcp:m02 Rcv Req(4) Seq:0x0000 Len:6
00:01:26 IA INFO: mbtcp:m02 Slv:1 Wr1Reg:4x00047 = 0
00:01:26 IA DEBG: 1 6 0 2e 0 0
00:01:26 IA INFO: mbrtu:CH01 Snd Req:4
00:01:26 IA INFO: mbrtu:CH01 Slv:1 Wr1Reg:4x00047 = 0
00:01:26 IA DEBG: 1 6 0 2e 0 0
00:01:26 IA DEBG: e9 c3
00:01:26 IA DEBG: MBRTU: Estimated Rsp length is 8
00:01:26 IA DEBG: mbrtu:CH01 wait more data
00:01:26 IA DEBG: mbrtu:CH01 wait more data
00:01:26 IA INFO: mbrtu:CH01 seeing ECHO - check wiring
00:01:26 IA INFO: mbtcp:m02 Snd (4) is Exception Seq:0x0000 Len:6
00:01:26 IA INFO: mbtcp:m02 Slv:1 Err/Exception = No Response or Timeout
00:01:28 IA INFO: mbtcp:m02 idle timeout, closing connection

And one from the write multiple command:

00:01:36 IA INFO: mbtcp:m02 Client Connecting!
00:01:36 IA INFO: mbtcp:m02 Rcv Req(5) Seq:0x0000 Len:11
00:01:36 IA INFO: mbtcp:m02 Slv:1 WrNReg:4x00047 Cnt=2
00:01:36 IA DEBG: 1 10 0 2e 0 2 4 0 0 0 0
00:01:36 IA INFO: mbrtu:CH01 Snd Req:5
00:01:36 IA INFO: mbrtu:CH01 Slv:1 WrNReg:4x00047 Cnt=2
00:01:36 IA DEBG: 1 10 0 2e 0 2 4 0 0 0 0
00:01:36 IA DEBG: 70 3b
00:01:36 IA DEBG: mbrtu:CH01 wait more data
00:01:36 IA DEBG: MBRTU: Estimated Rsp length is 8
00:01:36 IA DEBG: mbrtu:CH01 wait more data
00:01:36 IA INFO: mbrtu:CH01 recv resp:5; completed in 78 msec
00:01:36 IA INFO: mbrtu:CH01 start of rsp min:45 avg:51 max:56 msec
00:01:36 IA INFO: mbrtu:CH01 complete rsp min:72 avg:76 max:78 msec
00:01:36 IA INFO: mbrtu:CH01 Slv:1 Write Complete
00:01:36 IA DEBG: 1 10 0 2e 0 2
00:01:36 IA INFO: mbtcp:m02 Snd Rsp(5) Seq:0x0000 Len:6
00:01:36 IA INFO: mbtcp:m02 Slv:1 Write Complete
00:01:36 IA DEBG: 1 10 0 2e 0 2
00:01:38 IA INFO: mbtcp:m02 idle timeout, closing connection

Did I install the correct firmware?

show version
[i]
Digi One IAP(55001038-01):

Component Part-Number Release-Tag

BOOT 82000827 release_82000827_B
POST 82000779 release_82000779_D
Factory EOS 82000770 release_82000770_F_SA3
Running EOS 82000770 release_82000770_F_SA3
[/i]

7

>
> This F1_SA3 solves this problem. Note: there won’t be
> an F1 firmware, as we are actually making a “G” for
> the new hardware.

Yeah, that version seems to have fixed it.

Any idea on when an offical firmware release with this fix will be available?

8

See my last post in the “PoE?” topic which talks about the new DOIAP hardware.

The “G” firmware will come out with the new Digi One IAP hardware in Jan or Feb 2007. It may be available sooner than the hardware.

We need to call it “G” because the new hardware WON’T run older firmware (not even “F”), because the new hardware in effect is always 2-ports, but it mimics the old hardware when “passthrough” is off and it behaves as if it has only 1-port. The way the old hardware magically worked as 1 or 2 ports was not a good, robust solution.

Technically, the new hardware/firmware in 1-port mode echoes data out both ports and kind of “OR’s” any responses at a software level to act as 1 port. This means (as side effect) you’ll be able to connect a serial primary/backup slave device pair when set to 1-port mode as long as the slaves properly ONLY talk when active. Each has its own set of hardware driver chips. We won’t be claiming this as a feature (unless MarCom finds out about this :slight_smile: … but I know some people in the oil industry who will like this.

9

> See my last post in the “PoE?” topic which talks
> about the new DOIAP hardware.

Hey now, I wasn’t going to bring up PoE at all, especially after my last go around with sales & support on the Digi One IA vs. IAP… :wink:

> The “G” firmware will come out with the new Digi One
> IAP hardware in Jan or Feb 2007. It may be available
> sooner than the hardware.

Understood. I’ll summarize the situation and pass the info on to our customer. I suspect they’ll wait for release firmware since they’re not using write single commands at present. If they modifiy their SCADA setup and need write single support, then I’ll worry about convincing them to run the beta firmware off your site.

> Technically, the new hardware/firmware in 1-port mode
> echoes data out both ports and kind of “OR’s” any
> responses at a software level to act as 1 port. This

Will the 1/2 port selection switch move to a firmware setting, or will it still be that tiny slide switch on the side?

thanks!
newell

10

The switch remains - we have many customers using the Digi One IAP as a single-port device and using DB9 as “first port”. We felt forcing all customers to understand that the DB9 is now always second port was too big of a change.

Technically, the 1 or 2 port and even 232/485 are “firmware settings” … the firmware checks the switches on boot and uses I/O pins to make the setting effective. So in theory we could offer software over-ride. Some people (like me if I were customer) would prefer no switches so one can completely backup/restore a config without remembering about “switches”. That may happen some day, but no plan to do yet.

11

> software over-ride. Some people (like me if I were
> customer) would prefer no switches so one can
> completely backup/restore a config without
> remembering about “switches”. That may happen some

I’d argue that you can take that too far–just try and configure a Digi Wi-SP fresh out of the box when multiple wireless access points are in range. Better hope it decides to link with your access point, and not the neighbor’s!

12

100% agreed - I’ve had bad luck trying to setup the WiSP … but then to make matters worse I need to have it authenticate to Digi’s corporate IT system (ie: Windows domains etc).

By the way, the latest WiSP H2 firmware (and most Digi Connect SP, EM, ME H2 firmware) includes a simple Modbus Bridge so you can now bridge Modbus/TCP into serial RTU/ASCII. Function is much like the Digi One IA.

This is a cut from the Release Notes:

USING MODBUS BRIDGE

This image includes a Modbus protocol bridge. Modbus is one of the most common “third party” interfaces for industrial equipment. The full protocol specification can be found at www.modbus.org

The Modbus Bridge functionality enables Masters and Slave to communicate using any combination of the 3 official dialects:
  • Modbus/TCP transported by TCP/IP or UDP/IP
  • Modbus/RTU transported by serial, TCP/IP, or UDP/IP
  • Modbus/ASCII transported by serial, TCP/IP, or UDP/IP

One-serial port bridges are defined by the role of the attached serial device. Selecting the “Industrial Automation” serial port profile enable you to define either:

  1. Serial Modbus master accessing remote IP-based Modbus slaves
  2. Remote Modbus masters sharing a serial Modbus slave(s).
13

> 100% agreed - I’ve had bad luck trying to setup the
> WiSP … but then to make matters worse I need to
> have it authenticate to Digi’s corporate IT system
> (ie: Windows domains etc).
>
> By the way, the latest WiSP H2 firmware (and most
> Digi Connect SP, EM, ME H2 firmware) includes a
> simple Modbus Bridge so you can now bridge Modbus/TCP
> into serial RTU/ASCII. Function is much like the
> Digi One IA.
>
> This is a cut from the Release Notes:
>
> USING MODBUS BRIDGE
>
> This image includes a Modbus protocol bridge. Modbus
> is one of the most common “third party” interfaces
> for industrial equipment. The full protocol
> specification can be found at www.modbus.org
>
> The Modbus Bridge functionality enables Masters
> ters and Slave to communicate using any combination
> of the 3 official dialects:
> - Modbus/TCP transported by TCP/IP or UDP/IP
> - Modbus/RTU transported by serial, TCP/IP, or
> UDP/IP
> - Modbus/ASCII transported by serial, TCP/IP, or
> UDP/IP
>
> One-serial port bridges are defined by the role of
> the attached serial device. Selecting the “Industrial
> Automation” serial port profile enable you to define
> either:
> 1) Serial Modbus master accessing remote IP-based
> Modbus slaves
> 2) Remote Modbus masters sharing a serial Modbus
> slave(s).

14

> 100% agreed - I’ve had bad luck trying to setup the
> WiSP … but then to make matters worse I need to
> have it authenticate to Digi’s corporate IT system
> (ie: Windows domains etc).

[Let’s try this again and see if the Forum software will play nice…]

Is there any hope for fixing this WiSP configuration drawback? I’d complain, but if someone such as yourself on the inside has already identified it as a weakness, what more could I add? (We’re about to pull the trigger on a 25 pack, and I’d sure feel more comfortable knowing that I can configure the suckers without pulling hair.)

BTW, which forum is appropriate for WiSP discussion? I’ve got a few questions/ideas I’d like to bounce around.

thanks!
newell

15

I moved it here.

http://www.digi.com/support/forum/viewthread_thread,3913#12218

Which is under “external Device Servers” - Software

Will replay there