Simulating RS-485 Multi-drop with Digi's UDP Socket Port ...



Simulating RS-485 Multi-drop

with Digi’s UDP Socket Port Profile

Keywords: IA, Digi One IAP, multidrop, modem, Modbus

Abstract: Many existing applications use RS-485 or other multi-point analog modem technology to connect one master to many slaves. As companies upgrade their infra-structure to newer IP-based technologies, they are finding retaining this “multi-drop” design to be difficult. IP Broadcast is rarely permitted in distributed IP-based systems. Fortunately the Digi One IAP can simulate a multi-drop using simple UDP/IP unicast.

Introduction

Example Application

An existing serial master is using older multi-point analog or digital modem technology to access four remote sites with a total of nine serial slaves. All nine slaves appear to be on a single multi-drop to the master – as if RS-485 were being used. Now you want to upgrade the system to use newer IP-based technologies such as cellular, ADSL, or satellite. For variety, assume the geography at site #4 (IP subnet 10.34.4.x) makes using 2 IP devices with two distinct multi-drops the preferred solution. To simulate multi-drop, a single request from the master must be echoed to each of the five remote IP devices.

[pic]

Theory of Operations

We start with the basic assumption of multi-drop systems; one master device talks to many slave devices. All remote slave devices inspect a protocol message, identify a destination address and ignore messages not intended for them. If the master device sends a request to all slave devices, only the slave device addressed will respond. Because routed IP is now being used, the challenge is to get the same message repeated to all remote sites. Neither IP broadcast nor IP multicast passes naturally through routed IP-based wide-area-networks. Since each remote site represents a distinct IP subnet, somehow the same data must be sent directly to each remote IP address. This means we need a unicast solution.

The Digi Device Server “UDP Sockets” profile solves this problem. Serial data received serially from the master device is repeated as UDP/IP packets to up to 64 remote Digi device servers. UDP/IP data received from any number of sources is freely sent out the serial port as response to the master device.

So the serial master request is repeated to each of the remote sites. All serial slave devices see each request and protocol knowledge means only the addressed slave will respond. The serial slave device response needs only be returned to the IP of the master device.

Configuration

Configuration is straight forward. The Digi device server for the master will have a unique configuration we’ll call the “master configuration”, while each of the remote Digi device servers will hold a “slave configuration”. The DIN-rail mounted, ground isolated Digi One IAP set for single-port operation is used for this example. However, the same concept can be used with other Digi products including the Digi One SP, Digi One IA, Digi TS4H and most others.

Planning Ahead

You need to collect the following information:

• What is the IP address of the master device server? This example uses 10.34.1.100 for the master.

• What are the IP addresses of each of the Slave device servers? This example uses the six IP 10.34.2.101, 10.34.3.101, 10.34.4.101, 10.34.4.102 and 10.34.5.101. (In this example site 4 has 2 IP devices)

• Which UDP port does the Master device server send to? This is the same UDP port the Slave device servers receive on. This example uses the Digi default of UDP port 2101.

• Which UDP port do the Slave device servers send to? This is the same UDP port the Master device servers receive on. This example uses the Digi default of UDP port 2101 – note that there is no problem with using the same UDP port for source and destination.

Serial Master Configuration

Click the Configuration | Serial Port | Select Port Profile and select the UDP Sockets profile. Press the [pic] button at the bottom.

[pic]

The settings for the UDP Sockets are split into two independent unidirectional channels – together they can mimic a full-duplex channel. The UDP Server is the UDP-to-Serial channel. The UDP Client is the Serial-to-UDP channel.

The UDP Server waits on a UDP/IP port for any data packets and sends them out the serial port as received. No timing or access control is required since the multi-drop nature of this protocol implies that at any one time either the Master is sending a request to all Slaves, or one Slave is responding to the Master.

The only setting for the UDP server is the UDP port number. Most users can use the default of 2101.

[pic]

This value can be changed on the Configuration | Network | Advanced Settings page. The formula used is (desired_port – 100 – serial_port_number). So if you desire to use UDP port value 3005 to receive data for port #1, you’d need to set the Network Services Settings: Base Socket to 2904. Note that this value also affects the TCP Sockets profile.

The UDP Client waits for serial data until some condition is true, and then sends a copy of the serial data to all UDP servers on its list. For the serial master device to send a request to all five remote device servers, we need to add the 5 IP addresses to the configuration. Remember to press the [pic] button after adding all the entries or your work will be lost.

[pic]

By default the UDP data is sent 4 or 5 bytes at a time. While this lowers end-to-end latency, it does increase traffic on the network. It also risks short serial pauses appearing at the remote site between these blocks of 4 to 5 bytes. If you want the Digi device server to gather or coalesce more data into larger packets, select one of the 2 options circled above.

Checking the Send data after the following number of bytes option and entering a value such as 25 or 100 milliseconds causes the Digi to collect serial bytes until no more serial bytes are seen after the selected delay in milliseconds.

Alternatively, checking Send data when the following string is found option allows simple ASCII protocols to be packed based on data seen.

Do not change the Always send data … parameter unless your infrastructure cannot handle large IP packets. The default of 1024 bytes works for most users. This does NOT mean all packets sent will be 1024, only that no packets larger than 1024 bytes of data will be sent.

Serial Slave Configuration

The serial slave configuration is really identical to the master, except that only the IP address of the master device server is in the UDP client table. You don’t want the IP addresses of the other slaves in this table, or this slave will also echo its responses to each of the other slaves.

Example walk-through

The serial slave configuration is really identical to the master, except that only the IP address of the master device server is in the UDP client table. You don’t want the IP addresses of the other slaves in this table, or this slave will also echo its responses to each of the other slaves.

Frequently Asked Questions

Q: UDP isn’t reliable, what happens if a message is lost?

A: RS-485 multi-drop is also not reliable and commonly has error rates in the 0.5 to 1.5% range. It is only suitable for protocols like Modbus that include error detection and loss recovery. If a request is lost, then the slave will not respond and the master must retry. If the slave response is lost, then the master must retry. So while UDP/IP is not reliable, you’ll find the error rate to very much lower than RS-485 – perhaps in the 0.01 to 0.1% range. So any protocol and SCADA system which can function over RS-485, will function well over UDP/IP.

Q: Can I have 2 Masters sharing the slaves?

A: If your 2 masters cannot share RS-485 multi-drop slaves, then they cannot share these remote UDP/IP slaves. You would have no problem using two serial master device servers – each would be configured with all of the slave addresses. Each of the slave device servers will happily receive incoming master requests from dozens of masters. Your first problem is that the slave device servers have no concept of half-duplex protocol or transaction. So if 2 requests show up nearly simultaneously, slave device server would merely concatenate the 2 requests together on the serial port. Likely your slave would be confused by seeing 2 requests and being given no chance to answer the first before the second arrives. Your second problem is that each slave device server would need to be configured with the IP address of both (or all) master device servers, and all serial responses would be duplicated and echoed to all masters. So a response to a poll from master “A” would be returned to both master “A” and master “B”. Likely master “B” would be confused by an unsolicited response to a poll it never sent.

Q: Does this only work with Modbus?

A: No, this works with any protocol suitable for use with RS-485 multi-drop. Since you are just sending raw data encapsulated over UDP/IP, the protocol must not expect special handling of RS-232 control signals or send long breaks. So this design works well with AB DF1 (full-duplex, half-duplex, or radio modem), Omron HostLink, Mitsubishi FX and FX2, and others.

Q: Does this only work with PPI, ProfiBus, DH485?

A: This won’t work with RS-485 protocols functioning as “token buses” with fast token rotation assumptions. For example, Siemens PPI masters assume the addresses slave will “ACK” the packet within 2 to 4 msec. When a PPI master passes the token to another Master, it expects to “hear” that master talk within 10msec. It is not feasible for a wide-area-network of routed IP to satisfy these timing constraints repeatably over the long-term.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download