Assuming that the motors in question (or probably their associated VFD's) are considered 'reliable' in executing properly received poll commands via Modbus, then if you send start requests to multiple motors and some motors do not start, then it is likely that the poll/query from the master is being corrupted by electrical noise as other motors start up.  

I'd check the Modbus error logs to see if master polls to the non-starting motors also indicate a failure of the non-starting motor to reply to the Modbus poll.  It is proper operation for a motor/VFD which receives a corrupted Modbus message to ignore that message.

Correcting electrical noise problems is a challenge.

The assumption for using the Modbus protocol is that the bus network is reliable and that slaves will respond to a master's poll and execute its task.   Repeated polling of a slave because of failed execution due to communications corruption is a work-around to fixing the core problem of a poor communications bus.

 

Assuming that the motors in question (or probably their associated VFD's) are considered 'reliable' in executing properly received poll commands via Modbus, then if you send start requests to multiple motors and some motors do not start, then it is likely that the poll/query from the master is being corrupted by electrical noise as other motors start up.   I'd check the Modbus error logs to see if master polls to the non-starting motors also indicate a failure of the non-starting motor to reply to the Modbus poll.  It is proper for a motor/VFD which receives a corrupted Modbus message to ignore that message.

Correcting electrical noise problems is a challenge.

However, the assumption for using the Modbus protocol is that the bus network is reliable and that slaves will respond to a master's poll and execute its task.   Repeated polling of a slave because of failed execution due to communications corruption is a work-around to fixing the core problem of a poor communications bus.

If your master algorithm is not waiting for the completion of the previous poll/query in the sequence, and if the master can be forced to poll the next slave, then you could be creating your own packet collisions between master poll and slave response.

A couple of Siemens 'sequencing slaves' notes are shown below:

1.  Example Modbus RTU program at shows sequence of Modbus Master operation for two slaves.  Note the use of the Tag n and Done Bits.

https://support.industry.siemens.com/cs/mdm/109741593?c=81280701451&lc=en-WW

2.  pg 25 and 26 show the program sequence to read or write to three Modbus slaves in sequence

https://cache.industry.siemens.com/dl/files/801/109476801/att_991274/v2/109476801_S7-1200_ebmpapst_DOC_V30_en.pdf

Hello,

to my knowledge and experience, use of these comm blocks is simply managed internally, all what you need to do is only set correct values inside input parameters (as you require) and monitor output parameters DONE, ERROR as mandatory. All input parameters values changes need to be executed only after no other job is pending with specific block, here you need do your intervention with your code to be ok here, no other way. I see no problem with add more conditions due different requirements but all what can I recommend to you is use input parameters to set expected data for return, check if no error is there and set next changes. In case of use more same blocks with different parameters (also solution) you need to be very careful with good state machine in your code to not have bad behaviour like timeouts, wrong data and similar problems.