Replacing MicroLogix 1500 Radio Links with 1761-NET-ENIW

Somebody on site has told you the peer-to-peer protocol has to change, and the SCADA database with it, because "it's in ASCII." Before you cost that out, open both programs and look at one field. Most radio-to-Ethernet changeovers on a MicroLogix 1500 pair are a media swap and nothing more: the same DF1 packets that were riding a transparent radio link start riding an Ethernet cable instead.

Here is the layout you are working with: slave PLC talking out its RS-232 DB-9 into a radio, master PLC receiving on its own DB-9, and a hanging off the master's 8-pin mini-DIN channel feeding RSView32 over Ethernet.

Do Not Start With These

• Rewriting the peer-to-peer protocol. That is weeks of code plus full retest, and it is only justified if the ladder actually contains ASCII instructions. Do the 30-second channel check first.
• Rebuilding the RSView32 tag database. RSView32 tags resolve through an RSLinx topic to a node and a data table address. Swapping the transport under the topic does not touch N7:, B3: or F8: addressing. If the master's ENI keeps its existing IP, nothing in the HMI project changes at all.
• Specifying a new processor family. Moving to a native-Ethernet controller is a migration project with its own schedule. It does not belong in the middle of a media changeover.
• Wiring the two ENI units point to point. A patch cable between them proves the pair works on a bench, and nothing else. Both sites already have a LAN — land each ENI on a switch port. Point to point leaves RSLinx, RSLogix 500 and RSView32 with no path to either device.
• Forcing switch port speed and duplex. Leave the ports on auto-negotiate. Hard-setting a port that serves a legacy device is the standard source of late collisions and intermittent MSG timeouts.
• Changing DF1 node addresses "to be safe." Leave them. The only new routing number is the index into the ENI's destination IP table.

Understand What the ENI Actually Does

The family is a one-port gateway: DF1 full-duplex on the RS-232 side, PCCC encapsulated in EtherNet/IP on the Ethernet side. It is not a general-purpose Ethernet card for the processor and it does not tunnel a raw serial stream.

Data table addresses never appear on the wire in a form the media cares about. They sit inside the PCCC read/write command that the MSG instruction builds. Change the pipe and the command is identical — same target file, same element, same length. That is why the answer to "do we have to change the database" is no, provided the link is DF1.

Routing is the one thing that changes. On the radio link the MSG instruction addressed a DF1 node number. Through the ENI, the node number you enter in the MSG becomes an index into the ENI's destination IP address table, and the ENI substitutes the far end's IP. Read the table size and the exact field names from the ENI user manual before you plan node assignments.

The ASCII rumor usually comes from one of two places: data radios configured for "transparent serial" mode, which people describe as ASCII even though the payload is binary DF1; or a program that genuinely builds formatted strings with AWT/ARD. Only one of those is real work.

Read the Channel Driver First

In RSLogix 500, open each program offline and go to Channel Configuration, then the tab for the channel that fed the radio. The Driver field decides the whole job. While you are in there, search both ladder programs for ASCII instructions: AWA, AWT, ARD, ARL, ABL, ACB, ACL, AHL, AEX.

If the master already talks to RSView32 through an ENI, you have proof the DF1 full-duplex path works on that processor. Copy those channel settings to the slave and you have removed most of the unknowns.

Convert the Link

1. Upload and archive both programs under dated filenames. Print the channel configuration screens for Channel 0 and Channel 1 on each PLC — driver, baud, parity, error detection, control line, node address.
2. Get static IP addresses, subnet mask and default gateway from IT for both ENI units, with the addresses reserved so nothing else claims them.
3. Configure each ENI with the ENI utility over its serial port: IP, mask, gateway, and the destination IP table entry that maps the node number you will use in the MSG to the far ENI's address.
4. Set the PLC channel that feeds each ENI:

   Channel Configuration - channel wired to the ENI
     Driver ............. DF1 Full Duplex
     Baud ............... match the ENI serial setting
     Parity ............. NONE
     Error Detection .... CRC
     Control Line ....... NO HANDSHAKING

5. Edit the master's MSG instructions. Change the channel, change the target node, leave everything below it alone:

   MSG (master -> slave, after conversion)
     Channel .............. channel wired to the ENI
     Communication Cmd .... 500CPU Read (or Write)
     Target Device ........ 500CPU
     Target Node .......... index in the ENI destination IP table
     Data Table Address ... unchanged
     Size in Elements ..... unchanged

6. Wire the ENI serial port to the PLC channel with the correct 1761-series cable for that connector, and land the ENI Ethernet port on a switch port left at auto-negotiate.
7. Leave the radio powered and connected until the Ethernet path is proven, if the freed channel allows it. On a single-channel processor it cannot, so schedule the cutover with the radio bench-ready as the fallback.

Verify Before the Radio Comes Out

1. Ping both ENI addresses from a laptop on the plant subnet. Watch for dropped packets and latency spikes, not just a reply.
2. In RSLinx, add the Ethernet driver, enter both ENI IPs, and browse. You should see each ENI and the MicroLogix behind it.
3. Go online with RSLogix 500 to each PLC through its ENI. That single test proves the serial DF1 settings, the cable, the IP configuration and the switch path in one shot.
4. Watch the MSG status bits — EN, ST, DN, ER. If ER sets, open the MSG setup screen, read the error code, and decode it in RSLogix 500 help. Timeouts point at the IP table or the gateway; no-response points at driver or baud mismatch on the serial side.
5. Force a known value in the slave and confirm it lands in the master's destination file. Then trend it to confirm it keeps updating.
6. Check the RSView32 topic status and trend an existing analog tag for staleness. Run the Ethernet path for a full shift before anyone unbolts a radio.

Pitfalls on This Retrofit

• Shared serial bandwidth. SCADA polls and peer MSG traffic now squeeze through one RS-232 channel into one ENI. If update rate degrades, fit a second ENI on the DB-9 channel the radio just vacated and split HMI traffic from peer traffic.
• Concurrent connection limits. The ENI accepts a limited number of Ethernet clients. Check the number in the manual before you add a historian or a second HMI station.
• Explicit messaging only. No scheduled or implicit I/O through an ENI. Do not build fast interlocks or anything safety-related on this path.
• Losing your way in. If the ENI occupies Channel 0, you program through the ENI. A bad ENI configuration locks you out. The communications toggle push button on the processor forces Channel 0 back to default DF1 full-duplex settings — which also drops the ENI link until the baud rates agree again.
• Different subnets at the two sites. Each ENI needs a correct default gateway entry, not just an IP and mask. Local pings will pass while cross-site MSGs time out.
• Comms-loss logic. The alarms built on MSG error bits during the radio era still do useful work. Retune the timeout values downward if you like, but do not delete the rungs.

Stop and escalate when the channel really is running ASCII and the far-end code depends on formatted strings, or when MSG errors persist after you have verified the driver, baud, IP table and gateway. Open a case with Rockwell Automation Technical Support and send both program archives, the ENI configuration file, and the exact MSG error code. That is a faster path than experimenting on a live link between two sites.

FAQ