# Wu.CommTool is a Windows desktop workbench for Modbus, MQTT and serial debugging

> Wu.CommTool is a C# and WPF communication debugging tool that parses Modbus RTU frames automatically, searches for devices on a bus, monitors registers, hosts an MQTT broker and connects as an MQTT client, all in one window. It suits an engineer wiring sensors and PLCs on a Windows bench, and it is a desktop application rather than a library.

**Monika1313/Wu.CommTool** — 基于C#、WPF、Prism、MaterialDesign、HandyControl开发的通讯调试工具。支持Modbus Rtu调试、Mqtt调试、TCP调试、串口调试、UDP调试

- Repository: https://github.com/Monika1313/Wu.CommTool
- Website: https://salight.cn/
- Stars: 683 · Forks: 160
- Language: C#
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/monika1313-wu-commtool

## The repository is a WPF solution, not a reusable library

The project is described as a communication debugging tool built with C#, WPF, Prism, MaterialDesign and HandyControl, and the repository layout confirms that it is a desktop application rather than something you reference from a project. The top level holds Wu.CommTool.sln, the main Wu.CommTool/ project directory, a Wu.CommTool.Core/ library, a separate Wu.CommTool.DynamicTheme.Core/ and Wu.CommTool.DynamicTheme.Resources/ pair for the theming, a Modules/ directory, a Test/ directory, a directory of reference notes, a PROJECT_STRUCTURE.md, a GiteeREADME.md alongside the main README, and a LICENSE.txt. The presence of a DynamicTheme project with its own resource assembly is a design decision worth noting, because it implies the interface can be re-skinned at runtime rather than being fixed at build time. The repository description also carries a Chinese summary, and the author reaches users through a QQ contact and a QQ group rather than a mailing list, which tells you something about where the project is centred.

## Modbus RTU is the feature the tool is really built around

Looking at the feature list, the Modbus RTU support is deeper than the rest, and the other protocols read as companions to it. The RTU side claims automatic formatting, parsing and validation of data frames, custom frames with automatic checksum support, a device search that can be set with multiple combinations and runs automatically, data monitoring where you can set byte order and data types and supports both reading and writing, and automatic responses. The framing detail that matters in practice is the one about handling, since a serial line can deliver several frames in one read or split one frame across reads, and a tool that mis-syncs on that boundary produces garbage. The data monitor also lets you set data type and scaling multiplier, and the documentation notes that if a value looks wrong you should consider the byte order, which is the single most common source of confusion when reading Modbus registers. The monitor configuration can be exported and imported, so a register map can be reused between sessions.

## Device search turns a bus of unknown addresses into a list

The device search feature deserves a mention on its own, because it solves a specific and common problem. You can select multiple baud rates and parity combinations, and the tool will sweep them automatically, and the discovered devices appear in a list on the right of the window. In practice, commissioning a Modbus RTU bus often means you know a device is answering but not which address it lives at or which serial settings it uses, because the vendor documentation and the actual shipped configuration drift apart. A brute force sweep over a handful of baud rate and parity combinations, with the responses collected, turns that into a list you can work from. The screenshots in the repository show both the settings dialog and the results panel, and the same feature is a good illustration of the general approach here, the tool is aimed at the fiddly parts of talking to industrial hardware rather than at a clean data model.

## MQTT is covered on both sides, broker and client

The MQTT support runs in both directions, which is what makes it useful for a test bench rather than only for a consumer. The MQTT Server mode starts a local broker so that clients can connect to it for testing, and the MQTT Client mode opens a client connection to a server. On the client side there is subscription management, so you can subscribe and unsubscribe, and in both modes a right click on a message opens a formatted JSON view of the payload, which is the difference between seeing a wall of escaped bytes and seeing the object your application will actually deserialise. The feature list also lists a JSON formatting viewer and a conversion tool as separate features. The broker side is the piece that distinguishes this from an ordinary MQTT desktop client, because it lets you run the server half of a system locally and point a client at it, which is a normal way to develop a device integration without a second physical device. The repository topics list both mqtt-client and mqtt-server, along with serialport, tcp, udp, modbus-rtu and modbus-tcp.

## Modbus TCP is present but still marked as work in progress

Here the documentation is honest in a way that helps you decide. The Modbus TCP section is shorter than the RTU section, and one of its bullets is explicitly marked as under development. The TCP side does have custom frame support and frame parsing, and the repository has separate screenshots for the TCP custom frame and the TCP frame parsing views, so the parsing is real. What is not finished is the rest of the feature set, and since the RTU feature set includes search, monitoring and automatic response, the reasonable assumption is that TCP does not have all three. If your device speaks Modbus TCP rather than RTU, the tool is still useful for building and inspecting frames by hand, but you should not plan on it replacing your RTU workflow. The repository description lists both Modbus Rtu debugging and TCP debugging as supported, and the topics include modbus-tcp, so it is a real target rather than a placeholder, just an incomplete one.

## Automatic response turns the tool into a device simulator

The automatic response feature on the Modbus RTU side is the one that changes what kind of tool this is. You set a match template and a response template, and when received data matches the template, the tool sends the response template automatically. That means the application can be written and tested without the physical device present, or before the device is wired in, or against a fault condition you would rather not produce on real hardware. It is a small amount of code and it changes the workflow, because a protocol test that previously required a device on the bench now requires only a serial port. The same feature also means the tool can act as a target during development of the master side. For anyone integrating Modbus RTU hardware, this is the feature that turns a debugging utility into a development environment, and it is worth checking early whether the templates cover the frames your application actually sends.

## It is a Windows application, and the download is a zip

The download section is short and has one hard requirement. Only Windows is supported and .NET 6 must be installed, and the instruction is to go to the Release page and download WuCommTool.zip. The homepage for the project is salight.cn, and the releases themselves are tagged with a four part version number, with V1.5.5.15 dated 2026-01-14, V1.5.5.9 from 2025-11-01 and V1.5.5.6 from 2025-10-29, so the patch component is being incremented frequently. The repository is not archived and the last push was on 2026-09-24, so the code moves more often than the packaged releases do, which is a gap to be aware of if you are comparing what you read in the source with what you download. The licence is Apache-2.0, held in LICENSE.txt at the top of the tree. The project also maintains a GiteeREADME.md, which is a mirror for readers in China where GitHub access is unreliable, and the Gitee repository is the same organisation's hosting.

## Where Wu.CommTool is the wrong tool

Three situations argue against it. The first is any environment that is not Windows. The application is a WPF desktop program, WPF being a Windows presentation framework, so there is no Linux or macOS build and no cross platform story. A developer working on a containerised bench or a remote Linux host has to reach for a different set of tools. The second is an automated pipeline. Every feature in this tool is a person looking at a window, framing a request and watching the reply, which is exactly what you want during commissioning and exactly what you do not want in a regression suite that has to run unattended on every build. The third is a project that needs a protocol this tool does not cover. The scope is Modbus RTU, Modbus TCP, MQTT, serial, TCP and UDP, and while the serial and TCP sides are broad enough for a lot of work, anything with a bespoke binary protocol means writing your own client rather than configuring this one. The alternative worth naming is the standard tooling. A scripting client for the same protocol is a better fit for automation and for version control, while this tool wins on interactivity, on the automatic frame parsing, and on the device search, which is the part you would otherwise write by hand.

## Conclusion

Adopt Wu.CommTool when you are commissioning Modbus RTU or MQTT hardware on a Windows workstation and want frame parsing, device discovery and register monitoring in one window without writing a script. Skip it if you need a Linux or cross platform setup, or if you need the logic to run unattended in CI, since this is an interactive desktop application. Verify first that your target machine has .NET 6 installed, because the project states that requirement, and check the release page for the current WuCommTool.zip rather than building from the solution.

## FAQ

### What is Wu.CommTool?

It is a communication debugging tool developed with C#, WPF, Prism, MaterialDesign and HandyControl. It supports Modbus RTU debugging, MQTT server and client, TCP, serial and UDP debugging, with automatic Modbus frame parsing, device search, register monitoring and automatic responses.

### How do I get Wu.CommTool?

Only Windows is supported and .NET 6 has to be installed. Go to the Release page of the repository and download WuCommTool.zip, and the project homepage is salight.cn.

### Can Wu.CommTool find Modbus devices on an unknown address?

Yes. The device search lets you select multiple baud rates and parity combinations, runs the search automatically, and lists the discovered devices in a panel on the right of the window.

### Is the Modbus TCP support in Wu.CommTool complete?

Not fully. The Modbus TCP section documents custom frames and frame parsing with screenshots for both, but one of its feature bullets is marked as still under development, and the TCP side does not have the same set of RTU features.

### Is Wu.CommTool still maintained?

The repository is not archived and the last push was on 2026-09-24. The recent release tags are V1.5.5.15 from 2026-01-14, V1.5.5.9 from 2025-11-01 and V1.5.5.6 from 2025-10-29, and the licence is Apache-2.0 in LICENSE.txt.

## Sources

- [License: Apache-2.0](https://github.com/Monika1313/Wu.CommTool/blob/master/LICENSE)
- [Monika1313/Wu.CommTool on GitHub](https://github.com/Monika1313/Wu.CommTool)
- [Project website](https://salight.cn/)
- [README](https://github.com/Monika1313/Wu.CommTool/blob/master/README.md)
- [Releases](https://github.com/Monika1313/Wu.CommTool/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/monika1313-wu-commtool