if i have 15 messages is it still fine ?
if i poll each of them each scan it may become a problem ? I sometimes get 0 as return values but isn't timed or i can't find any relationship with the sequence programming for these 0...
There probably be an easy way to make sure the is no collision or overloading ? How do you do that when there is a lot of comminucation message programmed ?
15 messages should be OK, providing they are not all firing off simultaneously and rapidly repeating themselves.
YES : Do not re-initiate MSG instructions immediately they are complete. Instead, use free-running timers to initiate them at a much more relaxed rate, depending on the application. And I would also schedule the messages to fire off at a rate appropriate to the data they are transferring.
Example1 : If I am reading Analog data acquired in another processor, I would not try to read it faster than it is changing - look at the Real-Time Sample and Requested Packet Interval rates of the remote processor to determine their update rates.
Example2 : Production Report data, providing it is time-stamped within the data itself, probably could be read once a minute, or even longer, or be triggered by "Production Complete" instead of timers.
If you do require any "high-speed" data transfers, then set the MSG configuration to enable Connection Caching. This will speed-up the completion of the message, at the expense of a permanently used "connection".
Make the messages "large" - use UDTs to group data into a single tag, and poll the single tag rather than use multiple messages.
If the remote processor is Logix5000, consider using Produced/Consumed tags instead of messaging. Again, pack the data into "large" UDT tags (maximum 500 bytes of data for a produced/consumed tag).
A processor loaded with messages would need a greater "System Overhead Time-Slice. The default is 20%, but you would almost certainly need to increase this %age, at the expense of a slower user-code scan-time.
In Rev. 16 or greater, there is the option to recover unused time-slice and allow the processor to resume scanning the user-code - I would always check that option in any project anyway. I have seen this value at >80% on a project, but the option was enabled.