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

[KarvaneSiil]

Hello,

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?

[Ausman]

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?

[Joe Tauser]

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.

 

[kratmel]

Please read this info

 

[Gabriel Franco]

Some suggestions:

1. Check the termination resistors.

2.  Change aperiodic for periodic readings. You can either control single slave readings with Active bit.

3. Use minimum response time.

4. Take a look to "Dropped Operations" information in help file. It may help to solve your issue.

 

[KarvaneSiil]

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?

 

 

 

[Ivgeny]

Hi,

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.

[Joe Tauser]

3 hours ago, Ivgeny said:

Please upgrade to the latest official version, the version contains UniLog feature

What is this "UniLog" and how do I get one?  It sounds very handy indeed.

Joe T.

[Ausman]

3 hours ago, Joe Tauser said:

What is this "UniLog"

It's that fallen tree you sat on at your place of higher learning.  

Sorry, couldn't resist.

[Ivgeny]

UniLog is debugging trace for support and R&D purpose.

[KarvaneSiil]

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.