DL250 Modbus radio polling needs 500 ms RTS and PL squelch

A DL250 master polling DL05 RTUs through analog Motorola radios and Bell 202 dumb modems at 1200 baud, using Modbus on port 2 with RX/WX blocks of up to 16 V-memory locations, returned about 40% good polls. Modbus RTU over a dumb radio modem fails from four causes: RTS timing too short, squelch-tail noise read as data, CPU firmware that drops out after a comm error, and a weak RF path. Fix them in the order below. Each step ends with a check against an error counter so you know which change helped.

Put error and traffic counters on the first two rungs

Build the measurement first. Without it, every later change is a guess. The 40% figure only means something if you can reproduce it on demand.

1. Place two counters on the first rungs of the program. Position matters because of scan order; the counters must see the port bits before other logic touches them.
2. Clock counter 1 from SP116 and counter 2 from SP117. On the DL250 as documented for this setup, SP116 counts port communication activity and SP117 is the port error bit.
3. Confirm in the DL250 manual's special relay table that SP116/SP117 map to the port you use (port 2 here). Do not assume they map to port 1.
4. Optionally add a third counter that counts each firing of the RX/WX instruction. Compare it to the error counter to get a poll success rate: success % = (RX/WX count - error count) / RX/WX count x 100.

Check: the activity counter climbs steadily and the error counter climbs only with real failures. A baseline near 40% good confirms you are measuring the same problem. Keep this baseline; every later section has to move it.

Prove the link on a hardwired cable before touching the radios

Swapping radios or antennas first is the usual wrong fix. If the ladder, the RX/WX addressing, or the port setup is wrong, no RF change repairs it, and you will chase noise that is not there.

1. Remove the modems and radios. Connect the DL250 port 2 to a DL05 port 2 with a direct cable, matching the port parameters at both ends (station number, baud, parity, Modbus protocol).
2. Run the same RX/WX logic and the same counters from the previous section.
3. Fix wiring, station numbers, and address mapping until the error counter stays flat.

Check: the hardwired link runs with zero counted errors. If it does not, stop; the fault is in the PLC program or port setup and the RF work would be wasted. Only then reinstall the modem and radio path.

Set 500 ms RTS on and off delays at both ends

The dumb modem does one job: it keys the radio when the PLC raises RTS. The radio needs time to key and settle before the first data byte leaves. It needs the same time at the end so the last byte is fully transmitted and the remote sees a clean end of frame. Short delays clip the front of the frame or truncate the tail. Reported field experience on a large DL250/DL05 radio installation is that anything under 500 ms on and off was unreliable.

The two CPUs differ in how you set this:

• DL05 port 2: RTS on-delay and off-delay set in the normal port setup. The DL05 here was at 500 ms on and 100 ms off. Raise the off delay to 500 ms.
• DL250: RTS on-delay set in the normal port setup (AUX functions on the handheld programmer or Secondary Port Setup in DirectSoft). The RTS off-delay is a newer feature (DL250, DL350, and DL450 port 1 only) and DirectSoft's port setup does not expose it. Write it from ladder logic into V-memory.

The DL250 off-delay register is V7655. The three least significant bits select the delay:

1. Open a data view on V7655 and record the current value. The upper bits are shown as zero in the register layout you are working from, but read the live value before you write.
2. Confirm in the DL250 manual that V7655 applies to the port you use. The DL450 restricts this feature to port 1, so do not carry addresses between CPU models.
3. Add a first-scan rung that writes the low three bits as 111 and leaves all other bits as read. If the upper bits read zero, the value is 0007.
4. Download, then read V7655 back in the data view.

A temporary restore is to raise the on-delay alone. It helps the front of the frame but leaves the tail unprotected, so it only masks the fault. Treat it as a stopgap for the night, not the repair.

Check: put a breakout box LED or scope on RTS at the DL250 port. RTS must rise about 500 ms before the first data byte and stay high about 500 ms after the last one. Then re-run the 15-minute counter test.

Space the polls so one transaction ends before the next begins

Full-duplex thinking fails on a half-duplex radio channel. Every transaction stacks two key-up delays, two hold delays, and the frame time at 1200 baud. Firing the next RX/WX right after the previous one steps on the tail of the last response. A working site allows 2 seconds between master polls.

Budget the worst case.

Cycle time per full scan is. Plug in your remote count. If the cycle is too slow, cut the block size or the number of transactions per remote before cutting the RTS delays.

Also check the master's response timeout in the port setup. Set the timeout above that with margin, or the master logs an error on a reply that was still on its way.

Check: add a timer between RX/WX firings and confirm the gap. Re-run the counter test; the error count should drop measurably from the baseline.

Kill the squelch tail with Private Line or DPL

This is the fault that most often survives everything else. When a receiving radio unsquelches, it passes a short burst of static at the end of a transmission. A dumb modem passes that burst straight to the PLC. Modbus treats any incoming signal, noise or real, as data. The result is a corrupted response, or a phantom reply to the master's own request. Adding retries or slowing the baud rate does not remove the burst; it just gives the burst more chances to land inside a frame.

Fix it at the radio:

1. Enable Private Line (CTCSS tone) or DPL (digital) on all radios. Digital is preferred; tone works.
2. Use two codes. Master transmit and slave receive share code A. Master receive and slave transmit share code B. Slaves then do not hear each other and do not process traffic meant for a different site.
3. Do not put a repeater in the loop on a dumb-modem Modbus system. The master hears the repeated copy of its own request and takes it as a response. Use separate frequencies or smart radios and modems if you need a repeater.

Check: with the code decoders active, key the master and listen on a scanner at a remote: the end-of-transmission static burst must be gone. Then run the counter test. Errors from bad or extra bytes should drop sharply.

Load DL250 firmware that fixes the master-to-slave flip and port lockup

Two CPU faults look like radio faults, so rule them out.

The firmware numbers above are the versions cited when this issue was documented (V1.43 fixed the flip, V1.48 was the released version and V1.51 was in test at the time). Read the revision from your CPU, then download the current DL250 firmware from the AutomationDirect support site. Do not rely on the numbers above being current.

A power cycle is the temporary restore for a locked port. Firmware is the permanent repair. If you cannot power cycle a remote site, add port-reset logic per AutomationDirect's published fix, but note that field reports say it does not always work and that it could not be made to work on the DL450 at the time.

Check:The master must resume polling on its own and the activity counter must resume climbing. If the counter stays frozen until you power cycle, the port is still locking up.

Repair the RF path: antenna, coax, line of sight, interference

A failing antenna and a squelch tail both give intermittent errors, so do this after the tone/DPL work, not before. Changing antennas first is a common wrong fix because a good radio setup hides nothing behind it.

• Antennas: use directional, all-welded yagis (a 10 dB gain yagi was the reference), and make coax connections clean and water tight. One documented site had antennas that worked for about two weeks, then failed intermittently. They worked better held in a hand at ground level than on the 30 ft pole mount. Replacing all of them cleared the problem for over a year. Suspect the antenna and its mount if a link degrades after a period of good service.
• Line of sight: trees and vehicle traffic in the path degrade the link, especially at 800 MHz and above. At 450 MHz, passing vehicles were audible at one site with a highway overpass in front of the antenna.
• Interference: adjacent-channel bleed-over and skip kill reliability. Confirm nobody else uses your frequency.
• Scanner: put a scanner at each end and listen. Note the signal strength you hear. If a remote you could hear yesterday is weak or gone today, the master radio, its coax, or its antenna has changed.

Check: the scanner hears every remote and the master at consistent strength across a day. Repeat the counter test in the traffic peak of the day, not at night.

Capture the Modbus RTU traffic in hex

A plain terminal program works for ASCII, but the link here carries Modbus RTU binary, and a terminal cannot show that usefully. Use a serial monitor that displays hex and timestamps, connected on a PC to the modem side of the link (a breakout box or Y-cable on TxD and RxD, listening only).

1. Capture a few dozen transactions on the master side, then the same at a remote.
2. Confirm the request: slave address, function code, start address, quantity, CRC.
3. Confirm the response has the same slave address and a byte count matching your block size, followed by a valid CRC.

Check: failing polls show up as specific bad frames you can point at, not as a vague percentage. If every failure has trailing junk, return to the squelch section. If requests never reach the remote, return to the RF path.

Decide whether the dumb modem has reached its limit

If the steps above still leave errors, the modem is the limit, not the PLC. Options in order of cost:

A D2-DCM does not help here. It is a Modbus slave only and a master only with DirectNet, so a Modbus master would still have to be the CPU port. Do not order one on the assumption it avoids the lockup.

Check: if you change modems or radios, repeat the entire counter procedure from the first section, because the RTS delays and PL codes may no longer be needed.

Run the end-to-end acceptance test

1. Confirm firmware on the DL250 and each DL05 is current. Confirm the V7655 low bits read 111 after a power cycle.
2. Confirm RTS on and off delays are 500 ms at both ends, measured, not just configured.
3. Confirm PL/DPL is on all radios with the two-code plan and a scanner hears no end-of-transmission burst.
4. Confirm 2 s (or more) between polls and a master response timeout above the round trip.
5. Capture a sample of RTU traffic and confirm every response frame has a valid CRC with no trailing bytes.

Pass criteria: the success rate is far above the 40% baseline and the error counter rises only on deliberate faults. A comparable DL250/DL05 site with the same settings reported about 99% success; treat that as a reference for what a healthy dumb-modem link looks like, and investigate any remote well below it.

FAQ