Scan Modbus.
Read it in every decoding.

ModEye26 is a Modbus tool for Windows for commissioning and troubleshooting. It finds Modbus devices on the IP network and on the serial bus, reads their registers and shows every raw value in all data types and byte orders at once — so you see immediately which interpretation is correct instead of guessing. On top of that: a live monitor, a master for reading and writing, a slave for simulation and a telegram trace.

No. ModEye26 is a standalone tool and works with any Modbus device, regardless of manufacturer or control system. If you do use EisBaer, you get a bonus: recognised devices can be exported as a .modbus profile and imported directly, and the device library can live right inside the EisBaer directory.

ModEye26 is a single EXE for Windows (64-bit). Download it, run it — no installation, no administrator rights, no separate .NET: everything needed is inside the file. Settings, connection profiles and logs go to Documents\ModEye by default; you can choose that folder freely in the settings. For Modbus RTU you also need a serial port or a USB-to-RS485 converter.

There is a free, time-limited trial license with the full feature set: in the app's license dialog, the “Request trial license” link takes you straight to the form and you enter the code in the same dialog. For professional use ModEye26 is available as an annual license (single workstation) via the busbaer.de shop — see licensing & pricing.

• Modbus TCP and Modbus UDP over Ethernet/IP, freely selectable port (502 by default), TCP optionally TLS-encrypted.
• Modbus RTU and Modbus ASCII over a COM port with adjustable baud rate, parity and stop bits.
• RTU/ASCII over TCP or UDP — for serial servers and RS485-to-Ethernet gateways: same framing, only the transport runs over the network.

Yes. The library saves you work, it is not a prerequisite. ModEye26 talks to any device that speaks Modbus: read a register range in the Decoder, click the matching decoding in the table, name the points and save them as your own device file. That gives you your own template — and you are welcome to send it to us, so it makes it into one of the next releases.

Yes, in the Master tab: choose unit ID, function, address and quantity, enter the values, send (FC05, FC06, FC15, FC16). A note from practice: writing takes effect on the plant immediately — set points, operating modes or enables change real states. Before your first write attempt, practise against a simulation using the Slave tab.

Yes. In the Slave tab ModEye26 itself behaves like a field device and answers requests: set the unit ID and start values, hit “Start”. That lets you test a control station, a PLC or a visualisation before the real hardware is on the bus — and narrow down faults when it is unclear whether the master or the slave is the problem.

You can save as .modbus (EisBaer SCADA XML), as .xml or as .csv. For EisBaer the route is: describe the device fully in Decoder/Monitor → save as .modbus → import in EisBaer. The other way round, ModEye26 reads existing EisBaer profiles, so you can check and extend an existing configuration.

No. Scans, measured values, profiles and logs stay on your machine — no cloud, no telemetry. The only outbound traffic is what you trigger yourself: the license check and the update check against our server. That makes ModEye26 suitable for isolated plant networks, too.

ModEye26 checks for a newer version at startup and updates itself on request — without an installer and without admin rights. The download is signed with an EV code-signing certificate of Alexander Maier GmbH; Windows shows the publisher when it starts. Updates are included in the annual license.

1. Network scan: take the address range from the network adapter, leave port 502, start. Every address is checked by ping and port connection at once; the ARP cache reveals silent devices. The hit list shows response time, name, manufacturer (from the MAC) and MAC address.
2. Connect: take the address you found into the Connection tab.
3. Modbus scan: sweep unit IDs 1 to 247 — this also finds devices behind a gateway. “Continue with” moves the unit ID straight into Decoder, Master or Monitor.

Modbus is an open fieldbus protocol from 1979, today maintained by the Modbus Organization — and despite its age it is the lowest common denominator in building and energy technology. The principle is deliberately simple: a master (today: client) asks, a slave (server) answers; a slave never sends on its own. Only numbers are transferred — 16-bit registers and single bits, with no units, no names, no type information. What a value means is documented only in the device manual. That gap is exactly what a decoder closes.

The content is identical — only the packaging differs.

• RTU runs serially over RS-485 (rarely RS-232): binary, with a CRC checksum and pauses as frame boundaries. One bus, many devices, a single master.
• ASCII is the same serial world in readable hex characters — slower, but easier to debug; rare today.
• TCP runs over Ethernet/IP on port 502: no CRC (TCP handles that), instead an MBAP header with a transaction number. Several clients can access it in parallel.
• Gateways translate between the two worlds — TCP on the network side, RTU on the bus side.

The unit ID distinguishes devices on one bus. Valid values are 1 to 247; 0 is the broadcast (all devices, write commands only, no answer). Each ID may exist only once on the bus — duplicate addresses cause collisions and sporadic timeouts rather than a clear error message.

With Modbus TCP the IP already addresses the device; the unit ID is then often 1 or 255 (some devices accept both, others exactly one). Behind a gateway it regains its original meaning: there it selects the serial device.

Modbus has four separate data areas. Each has its own address count starting at 0 — address 12 in the holding registers has nothing to do with address 12 in the input registers.

• Coils (FC01/05/15): single bits, read and write — relays, enables.
• Discrete inputs (FC02): single bits, read-only — switch and fault signals.
• Holding registers (FC03/06/16): 16-bit registers, read and write — set points, parameters. By far the most common area.
• Input registers (FC04): 16-bit registers, read-only — measured values.

Both. The manual uses the old “4x” notation: 40001 is the first holding register, which travels in the telegram as address 0. Rule of thumb: manual value minus 40001 gives the protocol address. The same offset applies to 30001 (input registers), 10001 (discrete inputs) and 00001 (coils).

It gets annoying because some manufacturers already print the protocol-level count from 0 while others start at 1. Test: if the expected value is exactly one register off, this offset is the reason. ModEye26 shows addresses in decimal or hexadecimal — an input prefixed with 0x always counts as hex.

A Modbus register holds 16 bits. Larger values span several registers, and the order of the four bytes is not standardised in practice:

• ABCD — big-endian, the Modbus standard.
• CDAB — word swap: registers exchanged. The normal case for float values on many PLCs and meters.
• BADC — byte swap within the registers.
• DCBA — little-endian, everything reversed.

A wrong order does not produce an “error” but plausible numbers that are wrong — 3.4·10³⁸ instead of 230.5 V, or a sign that jumps around. That is what the Decoder is for: it shows the same raw value in all variants at once, and the single sensible number tells you which one is right.

Always as a sequence of 16-bit registers: 32 bits (Int32, UInt32, Float32 per IEEE 754) = 2 registers, 64 bits (Int64, Double) = 4 registers. Strings are stored as two ASCII characters per register. Also very common is the scaled integer: the device delivers 2305 and the manual says “×0.1 V” — which makes 230.5 V. Some devices send the factor in a register of its own (SunSpec calls this a scale factor).

Baud rate, data bits, parity and stop bits must be identical on all nodes. Common are 9600 or 19200 baud, 8 data bits, and depending on the device 8E1 (even parity, one stop bit — the specification's default) or 8N1 (no parity, then properly with two stop bits). If the baud rate is fixed on the device, everything else has to follow. If you do not know the setting, work through the common combinations — start with 9600/8N1 and 9600/8E1.

• Nodes: classically 32 unit loads per segment; modern transceivers with ⅛ unit load allow up to 256 — the address range still ends at 247. More is possible with repeaters that split the bus into segments.
• Length: up to about 1200 m at 9600 baud. The higher the baud rate, the shorter: length × baud rate is the rule of thumb.
• Topology: a line, daisy-chained from device to device. Stars and long stubs are the most common cause of erratic faults — keep stubs below 30 cm.
• One master per segment. Two masters on the same bus interfere with each other.

Yes — 120 Ω between A and B at exactly the two ends of the bus, not in the middle and not at every device. Without termination, signal reflections travel along the line; with a short bus at 9600 baud it often works anyway, which is why the mistake gets overlooked — and comes back later as a “sporadic failure” with more devices or a higher baud rate. Too many terminations are just as harmful: the level collapses because the drivers work against too little resistance.

On top of that come bias / fail-safe resistors that hold the bus at a defined level when idle. Many devices and most USB-to-RS485 converters have them built in — exactly once per bus is right.

A device that brings the serial bus onto the network. Two designs that are easily confused:

• True gateway (TCP → RTU): it speaks Modbus TCP on the network side and Modbus RTU on the bus side and converts the telegrams. The unit ID selects the serial device.
• Serial server (RTU over TCP): it tunnels the serial telegrams unchanged. The master then has to speak RTU over TCP/UDP — exactly what that transport mode in ModEye26 is for. Set plain Modbus TCP here by mistake and you get no answer at all, even though the wiring is perfect.

An exception is an answer — the device is reachable and tells you why it rejects the request. That is good news: wiring, address and parameters are already correct.

• 01 Illegal Function — the device does not know this function code (many meters only do FC03 or FC04).
• 02 Illegal Data Address — address or quantity is outside the register range. Most common cause: the 40001 offset, or too many registers at once.
• 03 Illegal Data Value — the value does not fit the register (range, step size, invalid operating mode).
• 04 Server Device Failure — internal device error.
• 05 Acknowledge / 06 Server Device Busy — request accepted, or device busy: ask again later.
• 0A Gateway Path Unavailable / 0B Gateway Target Device Failed To Respond — the answer comes from the gateway, not from the target device: wrong unit ID, silent serial side or wrong baud rate.

ModEye26 shows the code together with plain text in the Trace / Log tab.

A timeout means: the request went out, nothing came back. The list, by frequency:

1. A and B swapped. The labelling is not consistent across manufacturers (A/B, D−/D+, ±). Just swap them — nothing gets damaged.
2. Wrong unit ID. Sweep 1–247 with the Modbus scan instead of guessing.
3. Wrong baud rate or parity. Both sides must match exactly.
4. No common GND reference or missing termination resistors.
5. Two masters on the same bus — for instance the control station still polling while you measure.
6. Firewall or wrong port with TCP; port 502 is the default, but not mandatory.
7. Serial server instead of a true gateway — then choose RTU over TCP, not Modbus TCP.
8. Timeout too tight. Some meters and heat pumps need 500 ms and more.

The Trace / Log tab shows every telegram sent and received — you can see straight away whether nothing, something incomplete or an exception comes back.

More slowly than you would think. On RS-485 all devices share one line: every request costs send and response time plus device processing, and a meter often refreshes its values only once per second anyway. 1 to 5 seconds per device works well; over TCP it can be faster. Two levers help more than a shorter interval: read contiguous registers in one telegram instead of one by one, and poll only what you actually need. Poll too fast and answers get out of sync or the device reports “busy”.

Classic Modbus has neither authentication nor encryption — whoever reaches the network or the bus may read and write. That is why Modbus devices belong in a dedicated plant network or VLAN, behind a firewall, and never unprotected on the internet (port 502 is a popular scanning target).

Since 2018 there is Modbus/TCP Security: Modbus inside a TLS tunnel with certificates, officially on port 802. So far only a few devices support it. ModEye26 can establish TCP connections TLS-encrypted on request.

SunSpec is a vendor-independent register standard on top of Modbus, mainly for PV inverters, battery storage and meters. Instead of a separate register table per device there are numbered “models” (e.g. model 103 for a three-phase inverter, model 203 for a meter) with fixed fields and scale factors. A SunSpec-capable device identifies itself with the marker SunS from register 40000 — find that and you no longer have to hunt for the register layout. ModEye26 ships the 106 common SunSpec profiles.

• Modbus polls, transfers bare numbers and has no self-description — but practically every device speaks it, from a €30 meter to a chiller.
• KNX is event-driven: devices send on group addresses by themselves and data types (DPT) are standardised. Strong in room automation, weak with large amounts of measured data.
• BACnet brings named, self-describing objects with units, alarms and trends — more powerful and more effort, typical in the control systems of large buildings.
• M-Bus is designed specifically for consumption meters and delivers unit and scaling along with the value, but is limited to that purpose.

In practice you meet all four in the same building — which is exactly why EisBaer brings them together in a single interface.