МКОН 24 не опрашивает больше двух устройств

[melky]

imaex вроде МКОН рулит очередями только двух мастеров к одному устройству. За ним то все равно висят последовательные устройства. И рекомендация от производителя увеличенный timeout при ожидании ответа, чтобы мастер2 дождался запроса/ответа пока в этот момент происходит запрос/ответ от мастера1.

Если слать постоянно запросы на разные устройства RS то мы получим гарантированный выход за timeout.

Не настолько этот преобразователь МКОН умен, к сожалению. Читайте рекомендации от Овен, которые тут неоднократно освещались по этому поводу.

МКОН к сожалению не шлюз, который можно настроить на опрос приборов RS485 а мастерам по TCP выдавать из буфера прочитанное.
Помнится я покупал шлюз (SNMP)Modbus TCP - Modbus RTU америкосовский по тем деньгам так тыщ за 35 в году 13-14-м - вот он сам опрашивал приборы и по SNMP отдавал данные хоть 10-рым.

[imaex]

imaex вроде МКОН рулит очередями только двух мастеров к одному устройству.

Почему очередями? Очередь одна должна быть, кмк. И почему от двух мастеров? Мастер и один способен несколько запросов к разным устр-ам по ту сторону выдать.

И рекомендация от производителя увеличенный timeout при ожидании ответа

Увеличенный относительно чего? Какие рекомендации конкретно?

чтобы мастер2 дождался запроса/ответа пока в этот момент происходит запрос/ответ от мастера1.

С какого это перепуга один мастер должен даже предполагать о существовании какого-то другого? Мне соединение открыли, не отфутболили? Вот и будьте добры обслуживать. Ни про кого другого знать не желаю.

Если слать постоянно запросы на разные устройства RS то мы получим гарантированный выход за timeout.

Зачем постоянно? Не дожидаясь ответов? Ну, знаете... timeout регулируется на стороне клиента и это верхняя граница задержки ответа. Не укладываемся? Увеличиваем timeout. А частоту опроса сам драйвер протокола должен подстраивать и уменьшать при необходимости.

МКОН к сожалению не шлюз, который можно настроить на опрос приборов RS485 а мастерам по TCP выдавать из буфера прочитанное.

А откуда ещё, как не из буфера он может отдать прочитанное?

Помнится я покупал шлюз (SNMP)Modbus TCP - Modbus RTU америкосовский по тем деньгам так тыщ за 35 в году 13-14-м - вот он сам опрашивал приборы и по SNMP отдавал данные хоть 10-рым.

Что-то у Вас всё в кучу - шлюз TCP/RTU да ещё и SNMP. Если он сам опрашивает RTU, а отдаёт по SNMP - на фига ему modbus tcp шлюзовать? Что-то Вы придумываете и лишние сущности привносите.

На сегодняшний день вполне работоспособный шлюз TCP/RTU штатно можно найти в составе промышленного (условно) роутера. Ценой намного меньше 35 тыс. Сегодняшних, а не начала 10-х. И в режиме именно шлюза способный обслуживать более полусотни одновременных подключений - тут, конечно, всё сильно будет зависеть от скорости на RS и интенсивности запросов со стороны eth.