Micrologix 1400 - MSG send too fast in succession

Hello,
I have problem with Modbus MSG. When i use ladder logic like this (which worked for other projects):

I got timeout error on every even rung.
The reason was that MSG were send too fast and when i changed logic so every second i enable new MSG rung everything was ok.

Of course i want to complete more than one message per second and i wonder how do You solve problem like this?
For now my best idea is to change logic so ER or DN will start timer for like 50ms and then enable new MSG rung. However if there are some better methods or maybe even Micrologix setting that allow to increase time between messages please let me know.

Use real time clock RTC or S: files to trigger your MSGs.

Modbus is a pure half-duplex protocol and only one Modbus MSG can be active at a time in the MicroLogix controllers.

This logic probably worked in other applications that used a protocol like DF1 or DH485, for which there are message buffers in the controller, allowing more than one MSG instruction to be active simultaneously.

I can't say for sure what happened in your other applications; you have 60 messages, so there was likely a circumstance where one of them failed.

I agree that adding a delay between MSG instructions is the best approach.

I see two potential issues:

1. I always unlatch the previous MSG instruction before ENabling the next one. So, on your top rung, I would add a branch around the MSG instruction, move the MSG to the branch and insert a OTU to unlatch the FINAL MSG instruction in your cascade.

2. On rung 002 of you ladder, you are performing an XIC for MG10:2, but the MSG above it is MG10:1. Is this an error, or did you put MG10:2 somehwere else? I'm guessing there are 60 separate MSG instructions? It's good practice to keep MSG instructions in order so it's easier to troubleshoot.

Modbus is a standard protocol when you follow the bit patterns in the read/ write words.

I've found it to be pretty much pot luck with each manufacturer. You have to experiment to find out what really works sometimes. Usually being careful is better than being quick.

check if buffer is empty then send next message or when you received a ack message.