[Smirnov_TR]

А вот полный текст ответа:

По результатам анализа присланных Вами материалов можно сделать следующие выводы.
1. Контроллеры с номерами 9, 12, 13, 14, 15, 16, 17, 22, 42, 51 не отвечают на попытки коннекта и в обмене не участвуют.

2. Контроллеры 5, 23 и 24 на один из запросов (типа Rin_byte) возвращают сообщение с кодом ошибки. Код ошибки 0xa0 – в стандарте Modbus не описан. Что он означает, Вам необходимо узнать из описания контроллера. В соответствии с этой информацией надо будет ввести коррективы в проект.

3. Подключающиеся контроллеры 2, 21, 25, 32, 37, включенные Вами в один поток TH15, регулярно разрывают связь, которая затем восстанавливается.
Причина такой ситуации состоит в том, что контроллер 32 запросы получает (это фиксируется в присланном Вами протоколе сетевого перехвата), но не отвечает на них.
В протоколе профайлера этому соответствуют строки вида
ERR_TCP:ModBus recieve zero bytes from 192.168.0.32:502 Alarm1-ШСВ23.

На ожидание ответа поток останавливается на время таймаута, соизмеримое с временем таймаутом на ожидание запроса, заданным в контроллерах.
Результатом является последовательный разрыв соединений контроллерами, входящими в этот поток.
По стандарту Modbus TCP устройство может не отвечать на полученный запрос только в двух случаях:
- запрос не соответствует заданному формату;
- в запросе указывается номер устройства, не равный номеру, указанному в настройках этого устройства.
Вам необходимо выяснить причину отсутствия ответа и соответственно скорректировать проект.

Если Вы удалите контроллер 32 (или отключите его Modbus-каналы), уже в текущем проекте Вы получите стабильный обмен.

При правильно построенных запросах в проекте указанных ошибок быть не должно.
Однако, нельзя исключать возможные сетевые коллизии, которые могут приводить к однократной потере запроса и/или ответа. В таком случае описанная выше ситуация может повториться.
Чтобы этого избежать, желательно изыскать в контроллерах возможность увеличения времени таймаута на разрыв соединения.

В любом случае необходимо заложить в проект контроль качества обмена по соответствующим диагностическим переменным и возможность автоматического управления обменом путем отключения каналов тех устройств, по которым диагностируются регулярные ошибки.