How I got a statute – my experience with MODBUS RTU and heat calculators

lip 04, 2019




Let me tell you a story about bits, bytes and how data reading from heat calculators bit me 8616 times.

I would like to introduce my story as Michael Buffer introduces wrestling matches. On the left corner, we have Marko from SmartWay and on the right corner, we have heat calculators!!!! Are you ready? Are you ready? Leeeeeeet’s geeeeet reeeeedy tooooo ruuuumbleeeee!!!!

[STARE DOWN] Let’s get started…

The aim was to read measurements from two heat calculators by PLC and then forward that data to energy tracking database. PLC as a master and two heat calculators as slave devices. Connect heat calculators on RS485 network architecture, send requests from PLC, receive data from slaves and push all that to the database by the master. It seems like an easy match, right?

[ENTRANCE] About heat calculators

Heat calculators were already installed on heating pipes (with all flow and temperature sensors). There was no proper communication, so investor ordered an original MODBUS RTU plug-in modules. Sales engineer told them that it is just plug and play module and gave them an instruction manual. Oh well, I also got a piece of inside information about my opponents – great!

[ROUND 1] Beginning of MODBUS tale

Before connection to RS485 network, every calculator needs to have unique Slave ID. You know what? Both modules had factory values for Slave ID set to 1. For example, on some devices, you can change Slave ID super easy, just with two button presses. Since there was no possibility to change Slave ID by buttons on heat calculator, I tried to assign Slave ID parameter with PLC. I connected heat calculators one by one on PLC and sent writing request to Slave ID register. All I was receiving were error responses 8616 (meaning: slave device busy). I tried that couple of times but without any success.

[ROUND 2] Agony begins

All I was thinking was how to solve this problem. I even thought to put two relays before every heat calculator, control them with PLC so I always have one slave on RS485 network. In that scenario, both slaves can have Slave ID values set to 1. Distance between PLC and heat calculators is very long, so I couldn’t lay another cable and on existing one I didn’t have enough wires for that. I was in the corner and both heat calculators were in front of me.

[ROUND 3] Finally solution! Or not!

I got information from the factory that setting up a Slave ID is only possible by PC with special software and RS485/USB converter. Whaaaat?? Why is that not listed in the instruction manual? I need special software to do a simple Slave ID change? Slave IDs were changed to 810 and 2310 and I finally thought that everything is going to be just fine. Readings that I was getting from HC2 were ok, but received data from HC1 didn’t correspond with displayed values on the screen. I thought maybe is a problem with one of the heat calculators on the network. I disconnected HC2 and still got meaningless readings from HC1. How is that possible? What is wrong?



[ROUND 4] Quit or to stick with the problem?

All it went through my mind was am I going to be defeated by HC1? With my mighty PLC, all the wires, my precious gaming notebook, instruction manual, Google in my corner? Is it the end? Do I have to get to my knees and acknowledge the triumph of HEAT CALCULATOR 1? NO WAY!!

I tried to switch modules from HC1 to HC2. Everything worked well on HC2, so the theory that module is broken fell apart. I was so obsessed with that problem that one of my colleagues told me that he is going to make me a statue in front of that location if I successfully end this agony (spoiler alert – still waiting for that statue).


[ROUND 5] In your face HC1!

And, you know what the problem was? Wrong factory settings for communication between MODBUS RTU module and HC1. The required speed is 2400 bauds and it was set to 9600 bauds on HC1. After I changed that – again by a special program and USB converter, HC1 admitted defeat and finally started to transmit meaningful data.



[ROUND 6] Conclusion

Even if that was my first dealing with MODBUS protocol, I think it is really super easy and understandable. All documentation you can find on the internet is more than enough to understand and implement reading/writing. Also, the protocol is really good to start with, simply because you can easily understand logic and upgrade your knowledge and learn about other protocols.

From my perspective, what is lacking is a manufacturer’s care that everything is listed in instruction manuals and that manuals are updated. If you wonder, MODBUS manual for this heat calculator is now updated. J

After this, my interest in protocols increased, and in the next post, I will tell you more about how it went with M-bus protocol.


Marko Kancijan,

Post by admin

Prenijeto na ovu stranicu