Modbus server

The station's own Modbus TCP server: its row in the Communication column, turning it on and off, its port and the clients connected, the register map that serves tags, Logic variables and alarm states, what a client reads and writes, a worked example, and what it does not do.

The Modbus server lets a PLC, an HMI or a building system that speaks only Modbus TCP read the station's tags, Logic variables and alarm states, and write the tags and variables you allow. It is the second way data leaves the station, beside the embedded OPC UA server, and it is not a driver: a driver reads equipment, while the Modbus server is read by equipment, waiting for a PLC to connect and never connecting to anything. Its panel says so under the title: "Answers the PLCs, HMIs and building systems that read and write over Modbus TCP. It receives connections and never makes one."

Modbus carries no user name and no password: whoever reaches the port reads every register the map serves. So the server starts turned off, every row of its map starts read only, and writing is allowed row by row, by someone who chose it. View connector reads the page; Configure connector changes it.

The row in the column

The Modbus server row sits under the Servers folder of the Communication tree, below the OPC UA server's row, with a server icon where the drivers show a plug. It is always there: a station has exactly one, and it is never created or deleted. The search box finds it by its name, and the state chips file it by its state: Off while it is turned off, Issues while its port is in use or it could not listen, OK otherwise. Beside the name it says what the server is doing, and a dot sums it up:

The dot is the server's alone: it takes no part in the Drivers folder's roll-up or in the status bar, which are about the equipment the station reads. Selecting the row opens the server's panel; its header repeats the state beside the same dot. The commands are on the command bar; the row carries no menu of its own.

Turning it on and off

Being on is a setting the station keeps, and listening follows the runtime:

The Port and clients card

The first card of the panel is Port and clients.

A port the server cannot move to is refused before anything is stored: the reason is said under the field, the field goes back to the port in force, and the server stays where it was. Six entries are refused: a number outside the range ("Port must be between 1 and 65535."); the port of the web server, set on Remote access ("Port N is already the web server. Pick another port, or move the web server first."); the port agent access is set to on the Agent page, whether agent access is on or off ("Port N is already agent access. Pick another port, or move agent access first."); the port of the OPC UA server on Configuration, running or stopped ("Port N is already the OPC UA server. Pick another port, or move the server first."); the port of the MQTT broker on the Connector page, on or off ("Port N is already the MQTT broker. Pick another port, or move the MQTT broker first."); and a port something else on this machine holds right now ("Port N is in use on this machine. Close what is holding it, or pick another port."). The four other port fields refuse this server's port in turn. The reason stays under the field until the next port the field accepts, or until the row is selected again.

Under the card a note says: "Answers any unit id. Other machines reach this server only if Windows Firewall lets TCP port 502 in: allowing it is your decision, and this station never does it on its own."

The server takes at most 16 clients at once: a seventeenth connection is closed as soon as it opens, and the journal says so. A client that disappears without closing its connection (a PLC switched off, a cable pulled) is found by TCP keep-alive, and its place is freed within about a minute and a half.

Windows Firewall

Under the note, a dot and a sentence state whether the station's own inbound rule lets this port in, as the Client access card states it for the OPC UA port, with one action when it does not.

The state is read when the card opens and again when the port moves, so a new port shows Not configured until you allow it. The station never adds the rule on its own.

The register map

The second card, Register map, is what the server serves: each row puts one tag, one Logic variable or one state of an alarm at a register, or at a coil, that a client addresses. A register no row covers does not exist for a client. The card says: "Each row serves one tag, Logic variable or alarm state at a register. A row stays read only until you allow writing, and a row that serves an alarm always does. A client's write then takes the same path as every other write and is recorded in the journal with the client's address."

The table

The rows are listed by class (holding registers, input registers, coils, discrete inputs), then by register. With none: "No register is served yet. Add one with New row." Clicking a row selects it and opens its fields under the table; which row is selected belongs to the window you are in.

What grows the table and what ends a row stand at the right of the card's title:

A row's fields

A row has exactly the fields and the rules of a Modbus tag: a point accepted at one end of the wire is accepted at the other. Each field is stored the moment it changes (a number when you leave the field or press Enter, a pick when you pick, a box when you tick it), and a client is served the new row from its next request, without being dropped.

Under the fields, three lines read the row back: where it sits ("Takes register 0." or "Takes registers 0 to 1."), what a client may do with it ("A client may read this row and not write it." or "A client may read and write this row: each write is recorded in the journal with its address.", or "A client reads this alarm state and never writes it. As a number, 0 is normal, 1 active and unacknowledged, 2 active and acknowledged, 3 cleared and unacknowledged." for a row that serves an alarm), and what a client reads there now ("Value now: 21.5"). When a client reading the row would get no value, the reason follows:

What a row refuses

A change the server's rules refuse is not stored: the reason is said in red above the row's fields, the change stays on the screen so you can correct it, and the row keeps serving what it served until a change is accepted. The other rows are not affected.

While a run holds the station or the runtime is stopped, a change is refused the way every change of the page is, with the reason in the action feed ("Configuration is locked while a Unit is running.", "Runtime stopped"), and nothing is stored.

What a client reads and writes

The server answers any unit id, and answers with the unit id it was asked with: on TCP a station is addressed by its IP address. Register numbers are 0-based as they travel. A PLC tool that counts from 1, or that writes the classic notation, adds the offset itself:

Any other function code is answered with exception 01. One request reads at most 125 registers or 2000 coils or inputs, and writes at most 123 registers or 1968 coils.

A read is answered whole or not at all. Each value is read from the station's current state, never evaluated for the client: a tag serves its engineering value, the one the station shows after the value pipeline, a variable serves its value, and an alarm the state its row names. The value is converted to the row's type by the station's one conversion: a real is rounded to the nearest whole number for an integer row (halves away from zero) and held at the type's limits, so an Int16 row serves 32767 for 40000. A read may ask for part of a two-register row: it gets the registers it asked for, as the encoded value holds them. A row whose source has no good value is never served a last value the server kept: a register carries no quality, and a PLC that read an old number would act on a value the station knows is not current. The client is answered with exception 04 instead, and its own communication-fault handling decides; the price is that one row without a value fails a block read that spans it, which the map's Value now column points at. A tag that presents a stand-in of its own (the last good value held, or a declared number, set on its Invalid reading stage) keeps a good value, and the stand-in is served like any value.

A client's write crosses the same single write funnel as every other write (see Logic): a tag through its device's delivery queue, its engineering value reversed through the tag's conversion, and a memory variable on the Logic queue. The source locks apply: a source that a running Process recipe or interlock holds is refused. The funnel journals each value as old to new under the source Modbus client 192.168.0.20:51234, and the answer waits for each value's receipt, which for a tag is the equipment's own answer.

• A write covers whole rows: writing one register of a Float row is refused, so a Float is written with function 16 and a count of 2.
• Every row the write reaches is checked against the map before any value leaves: a register in no row, or a row that is read only, refuses the whole request, and nothing is written.
• The values then go to their sources in register order. A refusal the funnel gives one of them is what the client is answered with, although the other rows of the same request were handed over too.

A worked example

A PLC reads an oven's temperature and its door switch from the station, and writes the oven's setpoint, a memory variable Variables.Oven.Setpoint. On the panel:

1. Select the Modbus server row and press New row. Set Register class to Input register (3xxxx) (the register stays 0) and Source to "Tag · Simulated · Oven · Temperature". The row reads "Takes registers 0 to 1.", Address in the manual reads 30001 to 30002, and the Value now column shows the temperature.
2. Press New row again, set Register class to Discrete input (1xxxx) (the type becomes Boolean and the register stays 0), and pick the door switch, "Tag · Simulated · Oven · DoorOpen".
3. Press New row a third time. It lands at holding register 0, Float. Pick "Variable · Oven / Setpoint" first, then set Access to Read and write: the row reads "A client may read and write this row: each write is recorded in the journal with its address."
4. Press Enable on the command bar: the row reads "Listening on port 502". For a PLC on another machine, press Allow local network on the Port and clients card.

What the PLC asks for, with both order boxes on (a Float travels big-endian, most significant word first, ABCD):

The same with an agent, through the four tools of the Connector areas:

modbus_map_upsert(source: "Connector.Simulated.Oven.Temperature", registerClass: "InputRegister", register: 0, type: "Float")
modbus_map_upsert(source: "Connector.Simulated.Oven.DoorOpen", registerClass: "DiscreteInput", register: 0)
modbus_map_upsert(source: "Variables.Oven.Setpoint", registerClass: "HoldingRegister", register: 0, type: "Float", access: "ReadAndWrite")
modbus_server_configure(enabled: true)

A row created by an agent is read only unless access says otherwise, and a coil or a discrete input is Boolean when no type is given. modbus_server_status reads the whole server back: its state, its clients, and every row with what a client reads there now. The tools are described on The tools, area by area.

Permissions and locks

While a run holds the station or the runtime is stopped, the verbs stay drawn and greyed with the reason, and every change is refused, as everywhere on the Connector page. Reading the panel, and the clients reading the server, go on. An agent changes the server only through the Connector configure area of agent access, and every change it makes is journaled as the agent's.

The journal

The server writes on the Events console under the Server area, component Modbus server: when it starts and stops listening, a port it could not open, a connection it closed because 16 clients were already served, and every request it refused with its exception code. A refusal that repeats, as a PLC polling a register that is not in the map repeats it every cycle, is written the first time, summarized every few minutes while it lasts, and closed with one line when the client is answered again. Connections and disconnections are detail, kept for the detailed capture. Each change of the server's settings or of its map is journaled too, whether it came from the page or from an agent. What a client's write did is the write funnel's own line, under its source Modbus client <address>:<port>.

What the server does not do

• It serves Modbus TCP only, with the MBAP header. There is no Modbus RTU or ASCII server on a serial line, and no RTU framing over TCP.
• It never opens Windows Firewall on its own (only Allow local network does, when you press it), and it cannot listen on one network card alone: it listens on every address of the computer, on one port.
• It answers any unit id with the same one map: it cannot host several units with different maps.
• It has no user, no password and no encryption, because Modbus has none: anyone who reaches the port reads every row and writes every row that allows writing. Keep rows read only unless a client must write them, and keep the port closed to networks that have no business with it.
• It never connects to anything. To read a Modbus device, add it under the Modbus TCP or Modbus RTU driver.
• It keeps no registers of its own: a register no row covers does not exist, and everything a client writes lands in a tag or a variable.
• It never keeps a value of its own to serve in place of a missing one, and it carries none of the other function codes (Read/Write Multiple Registers, Mask Write Register, device identification): they are answered with exception 01.
• The map has no import or export of its own: it travels with the station's configuration in the backups.