Jump to content

Modbus RTU doing things that should not be possible [SOLVED]


Recommended Posts


PLC: USP-104-B10

UniLogic 1.23.25


I am relatively now to Unitronics but have experience with PLCs and programming and things. So this is like weird thing happening.

I have 3 Kamstrup heat meters - PLC reads with Aperiodic Trigger block every second, 38400baud, so there should be enough time for communication I think, response timeout is set 500ms.  The communication fail rate is 4% for some reason - but OK, I can live with that. But what I notice is that the Session skips sometimes. Usually it goes device 1->2->3->1->2->3 and sometimes  1->2->3->...->2->3 and that's when weird things start to happen - heat meters DATA switches places between each other!? Then after a 2 or 3 correct round of readings everything goes back to correct places.

How can communication send out read request to node 170 and then when back comes data from node 171 it decides that this is the correct message I was looking for?

Now things get even worse when I add Multimeter and VFD device into communication. After program download everything works fine for a about 20-30 minutes, and after that it just fails. 80% messages fail, skipping sessions, random successful messages, DATA switches places.

I replaced communication modules on heat meters, comm module on PLC.

We have same type of devices working on other sites and no problem, but this project is a headache. Any suggestions?

Link to comment
Share on other sites

  • MVP 2023

This sounds like a buffer/timing/sequencing issue to me, likely related to how much data is being moved around. 

I'd first experiment with what happens when you drop the baud rate, or increase the trigger block time, or do a combination of both together?

And how are you terminating each call if response is a fail?  ie Is there a definite end so that the plc knows for sure the next call response is only for the requested node?

Link to comment
Share on other sites

  • MVP 2023

I'm guessing you're using RS485, which can be notoriously glitchy depending on the network layout.  It seems I always have to get my scope out when the gremlins appear to see what's actually happening with the data waveform.

You may or may not need terminators at each end, regardless of what the manufacturer says.

Describe your physical layout, including home runs and stubs.

Modify your scan to remove one node at a time to determine if one of them is a problem. 

I'd set my response time to 100 ms.  If you're polling at 1 sec intervals the remote device will either answer right away or it won't and I wouldn't be waiting around for 1/2 of my poll time to see if the slave chooses to answer my request.


Joe T.


Link to comment
Share on other sites

Thanks for feedback.

  • There are no terminators used - this is doable
  • Cable is shielded but not twisted pair, grounded on main cabinet no grounding to devices - should be OK
  • Lower baud rate to 19200, this is my next planned move.
  • layout is mainly daisy chain with one stub VFD->PLC + HeatMeter1->EnergyMeter->HeatMeter2->HeatMeter3 - this can be improved

As I use APeriodic Trigger I dont get any status info to diagnose what is going on or at least I don't know how to get it. I activate block every 1s and that's it, I hope it works. The data is 12 registers per HeatMeter so 1 second is long time for communication to get all things sorted out, before I send next request. As I am new to this then Modbus communication, it looks like a black box to me, I have little information what the communication is actually doing. Looks like if I do software download things get better, but why? Can I do this reset by myself with PLC block?




Link to comment
Share on other sites


Please upgrade to the latest official version, the version contains UniLog feature that will allow us to analyze the issue and assist you.

Contact support via email to support@unitronics.com for further assistance, we will guide you on how to set a higher verbosity level for the Modbus master and get the log.

Link to comment
Share on other sites

Update on this issue.

Apparently VFD did not have shielded cable installed for modbus communications. Rewired VFD with 1 pair shielded not twisted cable, installed terminators, corrected one spike and now everything works. So the cabling indeed affects a lot. Still the way DATA manages to be read successfully from wrong device is just wrong.

Thanks to everyone for help.

Link to comment
Share on other sites

  • KarvaneSiil changed the title to Modbus RTU doing things that should not be possible [SOLVED]

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...