We are Zhanjiang Weida Machinery Industrial Co., Ltd., making primary natural rubber processing equipment. A rubber factory line mainly covers coagulum collection, washing and breaking, crepeing and granulating, hot-air drying, and weighing and baling. The wet zone is water and acid all year round, the crepeing/granulating area has many motors and heavy steam, and the drying line runs hot air. In places like these we commonly use RS-485 sensors — not for fashion, but because they are noise-resistant and durable: differential signalling is more stable in interference-heavy environments, a lower baud rate is even steadier, and cable runs can be long. When one fails, you usually just replace the sensor.
Replacing the sensor is easy; changing the address is the hard part
Sensors fail. Heat, condensation, water ingress, wrong wiring or lightning can kill a meter that has run for years. Swapping a sensor is routine for an electrician — the screws are easy; the trouble is the slave address.
A new sensor comes out of the box as address 1, almost always. If address 1 is already on the bus, two slaves fight to answer — light cases make numbers jump around, serious cases take the whole bus down. So you have to change the address first, then put it back on the line. The protocol is not complex: write a register over Modbus RTU. The hard part is who changes it, and with what software.
The software on the market is not built for the electrician on site
There is plenty of address-changing software. Open it and you see COM ports, baud rates, parity, function codes, registers and a hex window all lined up. Someone who has written HMI/SCADA code finds this normal — but the people who actually wire up a rubber factory are mechanical engineers and electricians, not software engineers. They can connect the A/B lines, read an ammeter, and swap the desiccant in a junction box. Asking them to pick a COM port, install a CH340 driver and hunt for registers in a vendor manual is not a matter of capability — the software simply was not built for them.
Then there is language. Our lines are installed in factories in Ghana, Côte d'Ivoire, Thailand, Laos, Cambodia, Vietnam, Malaysia and Brazil. The manual may be in Chinese, the software in English, and the site staff speak French, Portuguese, Thai or Vietnamese. Most address tools support only one language. Staring at a screen full of English abbreviations, an electrician often hands the computer to "the person who knows computers" — who may not even be at the plant.
So we did not want to build yet another fuller Modbus debugger. We wanted to turn "change the slave address" into something an electrician can understand and finish on their own.
Just say one sentence to the computer
We built this SlaveAddr Agent. Connect the A and B lines of the new sensor to the 485-to-USB converter that ships with the unit, open a no-install exe, plug the USB into any port, and say it in the language you are used to:
Please change this new sensor to 7. Troca o endereço desse sensor para 12. Mets l'adresse de ce capteur à 5.
Take a photo of the address-changing page in the manual and send it — just like talking to AI on a web page. The program first reads the text in the image, then lets the model figure out: which register holds the slave address, and what the common baud rates are. No need to flip through the manual or fill in hex yourself.
The program finds which port the converter is on, checks whether the driver is installed, and walks you through the install if not; then it polls the sensor at common baud rates, lists the steps to change, writes the new address, and reads it back to confirm. What you still do: connect wires, plug in the USB, send the manual page, and check whether it succeeded.
This is not a chat wrapper — it is an engineered Agent
Behind one sentence is an entire professional chain wrapped up:
- The protocol is self-written. The Modbus RTU CRC check, read-holding-register and write-single-register frames are implemented from scratch, with no dependency on any vendor debug software, and the protocol-stack code is open and verifiable.
- The manual is handled with OCR plus rule validation. The manual photo is first recognized, then key parameters such as "slave-address register, baud rate, broadcast write or not" are extracted by rules, and the recognized text serves as evidence constraining later writes — registers not present in the manual are never used.
- A device profile mechanism. Which register holds the slave address and whether a power cycle is needed vary by vendor. They are maintained as profiles, so peers can add their own commonly used sensors — the more profiles, the better it gets.
- The model only orchestrates; the write always stays in the program's hands. The LLM understands the request and plans the steps, but actually writing a register must go through the program's built-in whitelisted tools, with confirm-first and read-back-after. If the model says something wrong, it cannot write.
- It works offline too. When the plant has no network, the program switches to a built-in offline wizard that understands the same multi-language rules — "change to 7" — with the same flow, just without chatting.
It cannot run wild
Site computers hold production data and are sometimes on the plant intranet. This program can invoke some commands; if its scope were not limited, it would be worse than useless.
So it has a set of hard constraints:
- It can only do these things: list serial ports, check USB drivers, poll Modbus slaves, read manual photos you send, read/write the slave address, and verify the result. It cannot launch other programs, modify unrelated files, access unrelated sites, or be used to recognize unrelated images.
- Before actually writing to the sensor, it shows you the steps and waits for your approval. After writing, it must read back with the new address; if it cannot read, it stops — no blind continuation.
- Commands are not executed arbitrarily. Only pre-defined actions like checking devices or installing drivers can run, and installing a driver still passes through the computer's own permission confirmation.
- Without a network, it runs the multi-language offline wizard with the same steps, just no chat. Even if the model is down, the sensor still gets changed.
It is simply a helper for changing slave addresses. Not general AI, not a remote-maintenance tool.
Why open source
Primary rubber plants are scattered across producing regions. The people living on site are mostly line workers; when a sensor dies it has to be replaced immediately, but the slave-address step often waits for someone who knows computers, or for remote after-sales from back home. The line sits still, waiting on that one step.
If this kind of tool were locked inside one vendor's dongle, the factory next door would still not get past it. Factories use similar sensors and similar ways to change addresses; there is no reason for every plant to buy another piece of software it cannot understand. Once open-sourced, plants can use it directly; equipment peers can use it on their own lines; and site electricians can add the register notes for the sensors they use into the profiles, so the next person skips one more manual search. The farther the producing region, the more valuable something like this that can be left behind.
We are not making money from this software, nor turning it into a platform. Weida builds lines and does after-sales; we keep seeing the same thing repeat at every plant. Turning this into an open tool means shorter downtime when swapping a sensor and one fewer after-sales trip — good for the plants, for our peers, and for us.
License and technical details
This program is developed by Zhanjiang Weida Machinery Industrial Co., Ltd. and is open-sourced under the MIT license: free to use, modify and redistribute with attribution. Communication uses the public Modbus RTU protocol with a self-written frame implementation; the UI, serial and OCR use open-source components that permit commercial use and redistribution, with licenses listed in the repository's NOTICE. No chip-vendor drivers or third-party manuals are bundled, and no code is taken from commercial debug software. Model keys and official endpoints live in the release configuration, not in the source; if you prefer to bring your own model, just change an environment variable.
A to A, B to B, plug in the USB, open the program, and tell it the new number in your own words. Let the program do the rest.
If you need the code, please contact us for details.