Hi everyone,

I've released ModbusLens v2.4.0, and this update is focused on making the tool more useful for real-world Modbus troubleshooting.

The biggest change is multiple devices in one workspace. You can now work with several PLCs, energy meters, remote I/O modules, or other Modbus devices from the same window.

What's new?

1. Multi-device workspace

• Manage multiple Modbus TCP, RTU-over-TCP, and serial devices in one window.
• Each device has its own Unit ID and configuration.
• Devices sharing a physical communication link, such as meters behind a gateway or multiple devices on an RS-485 bus, can share one connection.
• All tools now operate per device, including Tags, Trend, Address Table, Raw Data, Scripts, Scanner, and Diagnostics.

2. Calculated tags

Tags can now use expressions based on other tags' values. They're recalculated after each polling cycle without generating additional Modbus traffic.

Calculated values can also be used in trends, alarms, scripts, the Overview tab, and CSV exports.

3. Better register inspection and scanning

• Bit View: Inspect individual bits in a register and write individual bits directly.
• Redesigned Scanner: A color-coded results grid replaces the old text log, with pagination for large address ranges.
• Create Tags From Scan: Convert scan results directly into Tags rows.
• CSV export: Export results from Scanner, Find Devices, and Serial Discovery for further analysis in Excel.

4. Improvements for real-world communication links

I've also fixed several issues that matter when working with actual devices:

• Replies on shared RS-485 lines and RTU-over-TCP gateways are matched to their corresponding requests, helping prevent incorrect responses from being reported as successful reads.
• TCP auto-reconnect now detects dropped connections more reliably.
• Scanner timeouts no longer abort the entire scan. Inconclusive addresses are marked separately so the remaining range can still be scanned.
• Script tag reads and writes now target the correct registers.
• Theme changes no longer force an immediate disconnection of live devices.

Other additions include workspace auto-save, persistent per-device write bounds, transparent serial-to-Ethernet gateway support, and a gateway mode that forwards requests to a downstream serial device and returns its actual response.

Get ModbusLens

GitHub Releases: https://github.com/CraftParking/ModbusLens/releases

Source code: https://github.com/CraftParking/ModbusLens

ModbusLens is an ongoing project, and I'm interested in feedback from people who work with PLCs, SCADA systems, energy meters, remote I/O, and industrial communication networks.

Bug reports, suggestions, and practical feedback are welcome.

Pushed v2.3.0 a bit ago. Wasn't sure if I should post here again after last time, but figured an update's still relevant since a bunch of you were using v2.2.0.

Biggest addition this round is Device Profiles - save a device's tags and address range as a named profile you can reuse, and there's now a Community tab to browse/download profiles other people have shared (or share your own back). No account needed either way, it's just pull requests against a repo under the hood.

Also added an integrated Frame Viewer under Raw Data that decodes TX/RX frames side by side instead of just showing raw bytes, a standalone register decoder (Diagnostics > Decode Registers) that doesn't need a live connection, and a unified Find Devices dialog that does TCP scan + serial parameter sweep in one place instead of two separate tools.

First Linux build too - an Applmage, no install needed, alongside the Windows installer and portable exe.

Bunch of bug fixes on top (Tag Monitoring could crash with Tag Groups enabled, a signed-format display bug, a few Ul papercuts). Changelog's on the release page if you want the full list.

Next up is letting one window talk to multiple devices instead of a separate window per connection - that one needs a real backend change so it'll take a while.

https://craftparking.github.io/ModbusLens/

https://github.com/CraftParking/ModbusLens

Biggest thing: a few of you hit the portable exe just refusing to start (weird

usernames, antivirus not liking how it unpacks itself). Turns out that's a real

PyInstaller onefile limitation, not something I could patch around cleanly, so

there's now an actual Windows installer as an option too. If the portable one's

ever given you trouble, grab that instead.

Also added a dialog for the less common Modbus function codes (exception status,

comm event log, file records, device info, that kind of thing) since I kept

needing them myself and didn't want to write a script every time. And you can

now record a Trend session to a file and replay it later, which has already

saved me once trying to explain an intermittent fault to someone after the fact.

Bunch of smaller stuff and bug fixes too, changelogs on the release page if

you're curious. Next thing I'm working on is letting one window talk to

multiple devices at once instead of needing a separate window per connection -

that one's an actual backend change so it'll take a bit.

https://github.com/CraftParking/ModbusLens/releases/tag/v2.2.0

Biggest thing: a few of you hit the portable exe just refusing to start (weird

usernames, antivirus not liking how it unpacks itself). Turns out that's a real

PyInstaller onefile limitation, not something I could patch around cleanly, so

there's now an actual Windows installer as an option too. If the portable one's

ever given you trouble, grab that instead.

Also added a dialog for the less common Modbus function codes (exception status,

comm event log, file records, device info, that kind of thing) since I kept

needing them myself and didn't want to write a script every time. And you can

now record a Trend session to a file and replay it later, which has already

saved me once trying to explain an intermittent fault to someone after the fact.

Bunch of smaller stuff and bug fixes too, changelogs on the release page if

you're curious. Next thing I'm working on is letting one window talk to

multiple devices at once instead of needing a separate window per connection -

that one's an actual backend change so it'll take a bit.

Release ModbusLens v2.2.0 · CraftParking/ModbusLens

Honestly didn't expect the last post to get the amount of hands-on testing it did. Between the tag-order bug, the address field eating keystrokes, the missing spinbox arrows, and the "have to disconnect and reconnect after adding a tag" issue - all of that came straight from people here actually running it against real drives and ModSim, not just me poking at it alone. That's the whole reason this update exists, so thank you.

Also want to call out u/Automatater specifically - tested this against a real Invertek E3 drive when two other tools failed on it, and on top of that donated to help fund continued development on this. That's the kind of thing that keeps a one-person side project like this alive. Genuinely appreciate it.

Repo: https://github.com/CraftParking/ModbusLens

Release: CraftParking/ModbusLens - v2.1.0

What's new in v2.1.0:

- Light/dark theme, with a "follow system" option

- Scanner tab - auto-discover which register/coil addresses actually respond on a connected device, TCP or serial

- Diagnostics > Serial Discovery - sweep baud rate, parity, stop bits, and Unit ID to find a serial device's settings when they're not documented

- Auto-reconnect with backoff, and Tags monitoring auto-resumes once the connection comes back

- Modbus ASCII framing for serial (was RTU-only before)

- Raw Data is its own tab now - a transaction table of wire bytes and real request/response diagnostics for every read/write, filterable by tag/address/status

- Scripting: REPEAT UNTIL loops, a live variables panel, and scripts can reference a tag by name now (WRITE Boiler_Temp = 100) instead of just type+address - there's an Add Tag button right on the Script tab too

- Drag-and-drop row reordering in the Tags table

- Write bounds for registers (reject a write outside a configured min/max)

- Engineering-unit scaling per tag - raw counts to real units (PSI, °C, whatever), linear min/max, shown live in an Engineering Value column

- Trend pens are picked from your Tags list now instead of typing in type/address/format by hand, and Trend can pop out into its own resizable window that stays on top while you work in another tab

- Tag names are validated as you type now - no spaces, script keywords rejected, since a tag's name is also how it's referenced in a script or picked in Trend

- IP Configuration tool in the Tools menu

- Update checker on the About page

- Modbus exception codes (Illegal Function, Illegal Data Address, etc.) are tracked and shown now, not just a generic error

Also fixed (mostly from what you all found last time):

- Tags table added new rows above the selected row instead of below - order stayed correct now

- The address field's duplicate-check was eating keystrokes while typing a new address

- Missing spinbox up/down arrows on Windows

- Needing to disconnect/reconnect after adding a tag mid-session

- Column resizing was blocked while monitoring was active

- A scan or connection drop racing with the reconnect watchdog could abort the app

- Server tab's Unit ID field didn't actually do anything - it now really only answers as that unit

- Network Discovery's subnet check used the wrong network interface on multi-homed machines

- Monitoring's auto-stop after repeated failures didn't actually stop

- Importing an empty CSV showed a raw Python error instead of a clear message

- One bad tag address could stop polling for every other tag

- A packaged build failing to start showed nothing - now falls back to a log file and a message box

Still just me building this around my own work, so there'll be more rough edges to find - go break it. EXEs in Releases, no install needed. - Let me know what you found interesting and what changes/improvements that would be a great addition to this tool!

Posted here a while back about a small Modbus tool I built because I was tired of opening heavy clients just to read a few registers. Been chipping away at it since, and serial/RTU came up a lot in that thread (thanks u/MostEvilRichGuy and u/Automatater) - that's in now, along with a few other things.

Repo: https://github.com/CraftParking/ModbusLens

What's new in v2.0.0:

• RTU/serial support - Connection Settings has a TCP/Serial switch now (COM port, baud, parity, stop bits)
• Server mode - can run it as a TCP slave, so you can point your own PLC/SCADA program at it and test without real hardware
• A small scripting tab for test sequences (write X, wait, read Y, repeat) - can target either a live connection or the local slave simulator
• Trend graphing, tag-based alarms, CSV logging

Still just me building this around my own work, so a couple menu items are still placeholders. Grabbing the EXE from Releases works, no install needed.

​Hello everyone

​I recently acquired an Enter FL200 Thin Client and I am looking to completely wipe its internal storage to install a lightweight Linux distribution. My ultimate goal is to use this hardware as a dedicated, low-power headless server for a DIY home automation project (monitoring a water tank using an ESP32 micro-controller, MQTT brokers, and Python scripts), essentially mimicking a Termux/Android server environment but on dedicated hardware.

​Right now, the device boots directly into its proprietary, stock embedded firmware screen which functions strictly as a Remote Desktop (RDP) login client. The good news is that the hardware is fully responsive—both my USB mouse and USB keyboard are working and registering inputs correctly after hooking the unit up to my local network via Ethernet.

​However, I am hitting a wall regarding how to actually flash this specific machine.

https://www.enter-world.com/product/fl200-thin-client

Got tired of opening heavy Modbus tools just to read a few registers

Been working with Modbus for a while and kept running into the same thing — needing to open big tools just to quickly check something simple.

So I built a small tool for myself and have been iterating on it a bit. Just pushed a v1.1.0 update.

Repo (in case anyone’s curious what I mean): https://github.com/CraftParking/ModbusLens

Some things I focused on:

- Tag-based monitoring (so I don’t have to remember raw addresses)

- Built-in ARP / ping scan to quickly find devices

- Simple continuous polling without much setup

Also took into account some feedback from u/MostEvilRichGuy and u/Automatater — serial (RTU) support is something I’m working on next.

What do you actually rely on when debugging Modbus in real work?

What feels unnecessarily painful in existing tools?

Any small feature that actually makes a difference in the field?

If you check it out, I’d like to know what feels bad or missing.

Hey all,

I’ve been working with Modbus a bit and got tired of opening heavier tools every time I just wanted to quickly check a few registers, so I ended up building a small tool for myself.

Figured I’d share it here in case anyone finds it useful (or can tell me what I should fix 😄)

GitHub: https://github.com/CraftParking/ModbusLens

It’s written in Python and pretty straightforward — nothing fancy, just focused on quick debugging.

Current stuff it can do:

• Connect to Modbus TCP
• Poll registers continuously
• Tag-based monitoring (so you don’t have to remember raw addresses)
• Basic ARP scan to find devices on the network

This is my first proper project, and I’m still new to UI design (you’ll probably notice 😅 — I leaned a bit on AI for the layout), so I’m more interested in feedback than anything else.

If you’ve used tools like Modscan, QModMaster, etc.:

• What do you usually rely on the most?
• What’s something that always feels missing or annoying?
• Any major features that actually matter in real field work (not just nice-to-have stuff)?
• Anything small that would actually make a tool like this useful day-to-day?

No pressure to be nice — honest feedback is what I’m after.

Thanks 👍