When the serial and Ethernet protocols read the same data tables, as Modbus RTU and Modbus TCP do, change the protocol on the device itself and every tag address stays valid. The article gives the steps, a 60-tag worked example with the arithmetic, and the verification set to run before the panel goes back on the line.
Your HMI project is full of tags pointed at a serial device, the PLC is moving onto the plant network, and the export-import round trip looks like an evening of spreadsheet editing. In the common case you can skip the spreadsheet entirely. When the Ethernet protocol reads the same data tables as the serial one, as Modbus RTU and Modbus TCP do, one protocol change on the device keeps every tag address valid. This article shows when that shortcut applies, the steps to make the change on a device called DEV001, a 60-tag worked example with the arithmetic shown, and the verification set to run before the panel goes back on the line.
Can I just edit the device name in the exported tag file?
No: the export is a snapshot of project data in which the address, data type and protocol fields depend on the device each tag points to, so swapping the device name in the sheet leaves the addresses untouched and the panel still pointed at serial.
An exported workbook is a printout of project data, and its columns are linked. Each row names the device a tag reads from, and the address text is written in that device's notation. Modbus register numbers, a PLC file address and an offset all look like plain text in a cell; the meaning behind the text follows the row's protocol. The tempting patch edits the device name and the protocol ID in the last columns, but a name swap carries no conversion with it: the import maps each address through whatever protocol the row's device carries after the edit.
So for a serial-to-Ethernet move, leave the export closed. The supported path runs through the device configuration, four edits in the device list, and the tag list stays untouched.
When do tag addresses survive the move from serial to Ethernet?
Addresses survive when the serial and Ethernet protocols read the same data tables: Modbus TCP carries the same register model and function codes as Modbus RTU, wrapped in an Ethernet frame, so a holding-register address such as 40001 stays 40001.
Modbus keeps one data model across both transports. Coils are single bits, registers are 16 bits, two bytes each, and the four ranges keep their meaning: coils, discrete inputs, input registers and holding registers. The common five-digit notation numbers the first holding register 40001 and the last 49999, and a request on the wire carries an offset one less, so 40001 travels as offset 0 and 40060 as offset 59. The function codes match on both sides too, so the panel's reads and writes need no re-mapping.
Only the connection details change. Over a serial line the device sits at one slave address between 1 and 247 on an RS-485 segment. Over Ethernet the destination is an IP address at TCP port 502, the Modbus TCP standard's own port, and the old slave number rides along as the unit ID field.
Other PLC families follow the same pattern where the vendor pairs a serial driver with an Ethernet protocol over the same data tables. The panel's documentation lists which pairs it treats as shared-addressing, and that list is what qualifies a pair.
What do you need before you start?
You need four things: a saved copy of the project, the device name and its current protocol from the device list, the PLC's IP address, its Modbus TCP port, 502 unless the PLC changed it, its unit ID, and live values for five tags read straight from the PLC.
- A project backup. Save a copy under a new name so the serial version stays openable if you want to step back.
- The device entry. The example device is DEV001 on Modbus RTU, slave address 1, serial port at 19.2 kbps, 8 data bits, even parity, 1 stop bit. The Modbus serial defaults are 9600 baud with that same framing; the PLC's printout lists what yours runs.
- The network side. The PLC's IP address and subnet mask, the TCP port, and the unit ID, usually 1 on a direct connection.
- A verification set. Five tag numbers written down with the PLC register behind each one, spread across the range, including at least one write tag.
How do you change the device from serial to Ethernet?
Change the protocol on the device itself: select DEV001 in the device list, pick the Ethernet entry of the same protocol, confirm when the software asks, then fill in the new address fields, the PLC's IP address, the TCP port and the unit ID.
- Save a copy of the project under a new name. The serial version stays runnable while you work.
- Open the device list and select the serial device, DEV001 in this example. Note its current protocol and slave address.
- Open the protocol selection on that device and pick the Ethernet entry of the same family: Modbus TCP where the serial side was Modbus RTU.
- Accept the confirmation prompt when the software asks. It is the software telling you the protocol under the tags is changing, which is exactly the change you want.
- Fill in the Ethernet settings: the PLC's IP address, the TCP port and the unit ID from your notes.
- Save and open the tag list. Every tag still points at DEV001 and every address reads exactly as before, because the tags were never touched.
If serial and Ethernet both have to run at once, the cleaner route is a second Ethernet device rather than a protocol swap, and the article on running one HMI panel on serial and Modbus TCP together walks that per-device setup.
Worked example: what changes when 60 tags move from Modbus RTU to Modbus TCP?
A packaging line panel reads 60 tags from one PLC over RS-485 at 19.2 kbps, all holding registers 40001 to 40060; after the protocol change every tag keeps its address, and the only new numbers on the device are an IP address, TCP port 502 and unit ID 1.
Before. DEV001 talks Modbus RTU to the PLC's serial port: slave 1, 19.2 kbps, 8E1. The 60 tags sit in holding registers 40001 to 40060, and the wire offsets are the address minus 40001, so 40001 maps to 0 and 40060 maps to 59. One screen block reads the whole bank in a single request.
The change. Select DEV001, switch the protocol to Modbus TCP, accept the prompt, and fill in the PLC's address, 192.168.10.20 in this example, with TCP port 502 and unit ID 1. No tag is opened. The list still reads 40001 to 40060, and each value is still one 16-bit register, two bytes.
The arithmetic. The values are transport-blind: one holding register holds 16 bits, two bytes, on either transport. The request still fits in one read: 60 registers × 2 bytes = 120 bytes, inside the 125-register, 250-byte single-read cap the Modbus specification sets (125 × 2 = 250). The timing moves: the reply body alone is 120 bytes × 11 bits per byte at 8E1, 1,320 bits, about 70 ms at 19.2 kbps, and the plant LAN carries the same payload in under a millisecond, so a 500 ms screen scan now spends its time on the scan interval instead of the wire.
The check. Watch the verification set, 40001, 40030 and 40060 plus two write tags, against live PLC values. Sixty tags moved with no address edit and no import pass.
How do you verify the panel before you release it to the line?
Watch real values, not the connection status: read the five-tag verification set from the worked example, first, middle and last of the bank plus two write tags, compare each against the value the PLC itself reports, and count timeouts in the panel diagnostics over a 30-minute run.
- Read one tag before you trust the link. A ping is a cable check; the first successful register read is the protocol check.
- Compare the watched tags with the values the PLC reports for the same registers. First, middle and last of the bank catch an offset slip: 40001 against 40002 is the classic one-off, where every value looks plausible and belongs to its neighbor.
- Run the first write against a scratch register the machine ignores. A write aimed one register off moves a real output, so this check comes before any write tag goes live on screen.
- Let the panel run with the diagnostics open. A flat timeout counter means a clean link; a climbing one points at network load, a wrong port or a duplicated IP address.
- When reads come back empty or an address errors out, work through the no-reply and address-error fixes for a Modbus RTU master; when values update slowly after the move, trace the 10 to 15 second delay between an HMI panel and its devices in the order that article gives.
Release when the five watched tags have matched the PLC for the full run and the timeout counter has stayed flat.
When does the one-selection shortcut not apply?
Two cases need real conversion work: the Ethernet protocol uses a different data model from the serial one, or the tags must move to a second device such as DEV002 because serial and Ethernet have to run at the same time.
A different data model. Some Ethernet protocols do not mirror their serial siblings: the ranges, widths or notations differ, and each address needs checking against the new protocol reference. Why HMI tag address formats change between PLC protocols covers how the notations drift. Treat that move as a conversion, one tag family at a time.
A second device. When serial and Ethernet both stay in service, DEV002 is configured as its own Ethernet device, verified on its own, and the tags move in small batches, a screen at a time, each batch watched before the next moves. The export can still carry the text, color and scaling fields, but the device assignment on each tag decides which PLC the panel talks to, so that column is checked in the editor, batch by batch.
The panel documentation's list of shared-addressing protocol pairs decides which case you are in, so read it before the first edit.
Recommendation: When the Ethernet protocol reads the same data tables as the serial one, as Modbus RTU and Modbus TCP do, change the protocol on the existing device, keep every tag address, and verify five tags against live PLC values before the panel goes back on the line. Configure a second device and move tags in checked batches only when serial and Ethernet must run at the same time.
Questions
Do Modbus RTU and Modbus TCP use the same function codes?
Yes. Both transports run the same function codes: 3 reads holding registers, 4 reads input registers, 15 writes coils and 16 writes multiple registers. The RTU frame's slave address byte reappears as the unit ID field in the TCP header, and the TCP side adds the destination port, 502 by default. Register numbers, data widths and message size limits carry over unchanged, which is why a tag address can survive the move without an edit.
How many registers can one Modbus request carry?
The Modbus specification caps a message's data area at 253 bytes. A read holding registers request therefore returns at most 125 registers, 250 bytes of register data, and a write multiple registers request carries at most 123. A screen block larger than the limit gets split into two requests, which costs one extra transaction each scan.
What should the unit ID be on a Modbus TCP connection?
On a gateway, the unit ID routes each request to one serial slave behind it, so it carries the target slave's number, 1 to 247. On a direct connection to a PLC with nothing behind it, most devices ignore the field; set 1 unless the device documentation asks for a specific value.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.