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

[stesel]

Может что с конкретным экземпляром МКОН не так? Я не вижу причин, по которым нельзя было бы опрашивать более 2 устройств в сети RTU через МКОН. Сколько там у него заявлено? До 32-х.

В противном случае давно вой до небес стоял бы, он же не первый день продаётся.

А он давно и стоит. У меня штук 7 валяется, тоже вляпался в своё время.

[AlexCrane]

Вопрос к разработчикам - почему в OWEN OPC Server не добавили данный функционал, другие OPC же умеют (тот же мастер опс к примеру)?

[Антон Новайкин]

Вопрос к разработчикам - почему в OWEN OPC Server не добавили данный функционал, другие OPC же умеют (тот же мастер опс к примеру)?

Добрый день.
Owen OPC Server это бесплатное ПО, и оно имеет ряд ограничений.
В настоящий момент нет планов по его доработкам.
Если появятся - это будет первое что мы реализуем.

[imaex]

Я не представляю, я проверил (для МКОН), читает только два прибора одновременно, причем два из пяти в случайном порядке

А ведь Вы правы - действительно для каждого устройства отдельное соединение устанавливает. Раз уж в теме сотрудник подтвердил - решил проверить. Зачем так сделано - загадка.

[Емельянов Кирилл]

Когда мастер в сети Eth, а слейвы в RS485, надо ли после запроса к 1-ому слейву ждать его ответ или можно сразу слать запрос ко 2-ому слейву. Иными словами реализована ли на МКОН очередь сообщений?

[melky]

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

[imaex]

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

Не надо. Гейт сам должен разобраться - выстроить входящие на eth в очередь, если запросы по нему поступают быстрее, чем отвечают утр-ва на RS. Исключение тут МКОН или нет - не знаю, тут есть люди, которые точно знать должны.

МКОН - не просто преобразователь интерфейса, а преобразователь протоколов.

[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.

[Сергей0308]

Что тут говорить, надо у муравьёв учиться, Валенок в какой-то теме писал об этом и ссылку давал!