I’m facing an issue I haven’t been able to solve, and I’d greatly appreciate your guidance.
I have four devices that communicate over Modbus RTU (8N1 configuration). I can successfully read data from them, but I cannot change their Modbus addresses or any other parameters—they appear to be factory-fixed at address 1.
Since they all share the same address, I can’t connect them directly to a single RS-485 bus, as this would cause address collisions.
My proposed solution is as follows:
Assign one T3-Nano per device.
Connect each device (address 1) to the “sub” port of its respective T3-Nano.
Then, daisy-chain all T3-Nano units on a common RS-485 network via their “main” ports, assigning each T3-Nano a unique Modbus address (e.g., 2, 3, 4, 5).
The master system (PLC, SCADA, etc.) would then communicate with each T3-Nano using its unique address on the “main” bus, and each T3-Nano would forward the requests to its local slave device (always address 1) via the “sub” port.
I’ve attached a diagram illustrating this setup for clarity.
My questions are:
Is this technically feasible using the T3-Nano?
What configuration (firmware or settings) is required to make the T3-Nano act as an RTU-to-RTU Modbus gateway/bridge in this way?
Right now this setup isn’t possible on the T3-Nano.
The T3-Nano is mainly used as a Modbus/BACnet to Ethernet gateway, and it doesn’t support serial-to-serial Modbus routing between the Sub and Main ports.
If you need this function, let us know, we can look into adding it in a future firmware update.
There would certainly be a work around for this setup. The master controller can read & write to variables on each of the nanos, 2, 3, 4 and 5. You could do that using the ‘intrinsic’ method on the master, ie:
VAR1 = 2VAR1
…and so on for the vars on panel2
VAR10 = 3VAR1
…and so on for the vars on panel3
VAR20 = 4VAR1
…and so on for the vars on panel4
VAR30 = 5VAR1
…and so on for the vars on panel5
Programs running on panel2 through 5 will read the subnet modbus registers from your subnet devices 1 through 4
So now you have a series of vars on panel1 which mirrors the vars on nanos 2 through 5 (and devices 1 through 4). You can relay those vars on panel1 to the IP network over modbus or bacnet protocol.
Its a bit of work on the programming but it will work.
Following up on my previous post regarding connecting multiple Modbus RTU devices (all fixed at address 1) to a single RS-485 master, I’d like to refine my proposed solution and ask for your technical insights.
My core idea is to use one T3-Nano per device. Each T3-Nano would act as an intermediary, performing the following steps:
Read from Slave: Each T3-Nano would be configured to read data from its dedicated Modbus RTU slave device (which is hard-coded to address 1) connected to its “SUB” port.
Map to Internal Variables: The data read from the slave device would then be mapped to internal variables or Modbus registers within the T3-Nano itself. For example, if the slave device has a register at address X, the T3-Nano would read this and store it in its own internal Modbus register, say 8094.
Expose on Main Bus: The T3-Nanos would then be daisy-chained on the main RS-485 network via their “MAIN” ports, each assigned a unique Modbus ID (e.g., 2, 3, 4, 5).
The Modbus master (PLC, SCADA, etc.) would then communicate with each T3-Nano by its unique ID. Crucially, the master would not directly poll the original slave devices. Instead, it would poll the T3-Nanos, reading the internal Modbus registers (like 8094, 8096, etc.) where the slave data has been mapped. The only change required on the master side would be to switch the Modbus ID to address the specific T3-Nano, while the register addresses (e.g., 8094, 8096) would remain consistent across all T3-Nanos.
What a detailed explanation and indeed that will work as you decribed.
And my earlier suggestion, you can poll two devices with a single nano using the two separate RS485 ports. The PLC if it can read & write to the IP network you can poll the nano over IP. If it doesnt have an IP port then your setup there would be the way.
