Change each machine's NetVar IP and port where the engine actually reads them: the sender list's network properties and the interface address in device configuration, or documented endpoint variables. Persistent variables only work where the vendor names them as the endpoint source; otherwise keep per-machine values in device configuration so one shared application clones to every machine.
You can set each machine's NetVar IP and port from the application only where the runtime documents specific writable endpoint variables. On the common IEC 61131-3 controllers it does not: the engine opens its connection from the sender list's network properties and from the interface address held in device configuration. Set the endpoint there, once per machine, and one shared application clones to every machine with only its row of a settings map substituted. This page shows where the endpoint lives, why a persistent variable is the wrong lever unless it is documented as the source, and the steps and checks for a four-machine line.
Can the application change its own NetVar IP and port?
Only when the runtime documents specific variables as writable endpoint settings; on the common IEC 61131-3 controllers it does not, and the NetVar engine builds its connection from the downloaded network variable list plus the interface address held in device configuration.
An endpoint value lives in one of three places, and finding that place is the whole job:
- The sender list's network properties: protocol, port and peer list, downloaded as part of the application.
- The controller's own interface address: device configuration, which survives an application download.
- Documented writable endpoint variables: rare, and only yours if the vendor prints them.
Editing a value somewhere else is wasted work. The same layering explains why a control application config setting is ignored after you were sure you had changed it.
Where does the NetVar engine read its endpoint from?
From two places: the network properties of the sender list, which hold the protocol, the UDP port (1200 by default in the list editor) and the peer list, and the controller's own interface address, which lives in device configuration.
The list travels with the application. Change the port or the peers there and the change applies at the next download. The controller's own address is device data: it stays with the machine through application downloads and applies after the interface restarts. One option removes the peer problem completely: with the protocol set to UDP broadcast, the list carries no peer address at all, and every listener on the subnet receives the packets.
Why will a persistent variable not move the endpoint?
Because persistence is storage, and the NetVar engine does not read storage: it opens its sockets from the list it received with the last download, so a stored value changes nothing until a documented mechanism applies it.
The persistence behavior is real, and it is exactly what the multi-machine idea is after. In IEC 61131-3 runtimes, retain variables are cleared by an application download, a cold reset and a reset to origin; persistent variables keep their values through a download and through warm and cold restarts. That is the documented behavior of the mainstream controller platforms.
The gap is the reader. A value held in a persistent variable is stored, but that by itself does not make the engine use it. Unless the vendor prints variable names as endpoint settings together with their activation sequence, a stored address is just data. Do not write guessed variable names into undocumented memory, and do not test the theory by watching a value table: the table shows storage, the connection counters show the connection.
How do you keep one application on machines with different addresses?
Split identity from logic: keep every shared value in the application and move the two or three machine-specific endpoint values into device configuration, so a common download overwrites nothing that differs per machine.
Three patterns, in order of preference:
| Situation | Where the per-machine value goes | What the shared application holds |
|---|---|---|
| All machines on one subnet | Each controller's own address in device configuration | Lists set to UDP broadcast, no peer address |
| Machines on separate subnets | Peer address as a documented device parameter per machine | Unicast lists with the peer field sourced from device data |
| Vendor documents endpoint variables | The documented variables, written once per machine | Logic that applies them at the documented point |
The same split between shared logic and per-machine values comes up in local versus shared timers in control software, and the rule is identical: what differs per machine leaves the shared body.
Write a settings map before anything else, one row per machine with six fields: machine tag, interface address, subnet mask, UDP port, list name, activation method. Four machines means 24 cells, and every later step reads from this map.
What do you need before touching the first machine?
Six things: a settings map with one row per machine, a backup of the application and device configuration, the engineering tool, network access, the address owner's sign-off, and a window where the machine can be stopped.
Take the backup with the platform's normal archive function and name it with the machine tag and the date. Ping the address you intend to assign; silence is what you want, and a reply means the address is taken.
Safety note: an address change restarts the interface and drops that machine's communication for a few seconds, so make it with the machine stopped, one machine at a time on a running line.
Example: how do four machines run one application with four endpoints?
Four filling machines on line network 192.168.10.0 with mask 255.255.255.0, addresses 192.168.10.11 through .14, one sender list broadcasting on UDP port 1200 at a 100 ms interval, and a supervisory station at 192.168.10.50 listening.
The application holds zero machine-specific addresses: broadcast reaches every listener on the subnet, and each controller's own address sits in its device configuration. Per-machine work is one address entry and a read-back, about 15 minutes each, so 4 x 15 = 60 minutes of panel time for the whole line.
Verification arithmetic: the sender transmits 1 / 0.1 s = 10 packets per second at that interval, so a 60-second watch of the receiver counter must show 60 x 10 = 600 new received packets. If the counter climbs by about 600, the endpoint is live. If the ping succeeds while the counter stands still, the port is wrong.
Plant B variant: the same four machines split across subnets 192.168.11.0 and 192.168.12.0. Broadcast stops at the router, so each machine carries its peer address as a documented device parameter and the map row gains a peer entry. The verification arithmetic is unchanged.
How do you apply the change on the first machine?
Take machine one through backup, change, activation and verification to a passing counter check before you touch the second machine: six steps, and every remaining machine then repeats steps three to six with its own map row.
- Archive the application and the device configuration. Keep the archive; it is your rollback.
- Ping the target address and expect no reply. A reply means a conflict to resolve first.
- Set the endpoint at its owner from the map row: the interface address in device configuration, the port and peers in the list's network properties, or the documented endpoint variables if your vendor prints them.
- Activate the documented way: an interface restart for an address change, an application download for a list change. One documented step, once.
- Read the setting back from the same owner and compare it to the map row.
- If the machine loses communication, restore the archive and return to the last known-good endpoint so production can resume.
When machine one passes, repeat for machines two through four, substituting only their map rows, and record each read-back and counter result against the row.
How do you check the connection really uses the new endpoint?
Read the effective endpoint back from the same configuration owner, watch the list's transmit and receive counters move at the interval you set, and repeat both checks once after a power cycle; three checks, in that order.
The counters are the verdict. A successful ping is not proof the engine is listening on the port; the counters are. If values arrive but look wrong after a download, that points to a PLC runtime device mismatch, not to the endpoint. After cloning, the one machine on the line that stops counting points to its map row, never to the shared application.
Which shortcuts break this later?
The five below, and each fails the same way: it puts a machine-specific value somewhere a shared download can overwrite, or it skips the one documented activation step and hides the baseline you need for rollback.
| Shortcut | Why it fails | Do instead |
|---|---|---|
| Write the IP into a persistent variable and wait | Storage and the communication stack are separate; the engine reads the downloaded list | Set the value where the engine reads it |
| Edit the shared application per machine | The next common download overwrites the machine-specific value | Keep per-machine values in device configuration |
| Fill the address field without checking local versus peer | The field may name the far interface, and the map row goes quietly wrong | Use the field descriptions in the tool, then read back |
| Download repeatedly to make the change take | The change needs one documented activation, and repeats hide the baseline | Activate once, then verify with counters |
| Change other network parameters while testing | Every extra change adds a variable to the fault search | One change, one check, in order |
Recommendation: keep one shared application and put every machine-specific endpoint value in device configuration; use a persistent variable for the endpoint only where your vendor's documentation names it as the source the NetVar engine reads. If all machines share one subnet, set the sender lists to UDP broadcast on port 1200 and the application needs no per-machine address at all.
Once the map is verified it is also floor content: export each machine's row as a page and play it from the card on a shop-floor display board, so the crew sees each machine's endpoint without opening the engineering tool.
Questions
What happens if two machines end up with the same address?
An address conflict makes two devices answer one address; the network flips between them and both connections drop within seconds, taking their network variable traffic with them. Ping the target address before you assign it and expect silence. If a conflict is already live, stop one machine, correct the other's device configuration, then restart both. Give one person ownership of address assignment on the line so the settings map stays the single record.
Can the machines sit on different subnets?
Broadcast lists stay inside one subnet; a router does not forward them. If machines sit on different subnets, give each machine its peer address as a documented device parameter and use unicast lists, or consolidate the machines onto one line network. Add a subnet column to the settings map so each row still says everything about one machine.
Is UDP broadcast a load problem on a shared plant network?
A tenth of a second between sends means one machine sends 10 packets per second, so four machines send 40. That is a light load for a switched line network. Keep the lists on the machine network and off the office segments anyway: broadcast packets reach every device on the segment, and there is no reason to send production data where nobody listens.
Can you verify the endpoint without stopping production?
Reading a setting back and watching counters are passive checks; you can run them on a machine in production. Changing the address itself restarts the interface and drops communication for a few seconds, so that part needs a stop window. A port or peer change in the list needs a download, which also belongs in a stop window.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.