Просмотр полной версии : МКОН 24 не опрашивает больше двух устройств
AlexanderUshakov
19.07.2023, 11:50
Добрый день!
Решили тут импортозаместить Moxa MGate на ОВЕН МКОН 24.
Сразу два МКОНа 24 не могут опросить больше двух устройств.
На первом 3 контроллера вентиляции (slaveID 3,4,5), на втором два контроллера вентиляции и компрессор.(slaveID 10,11,12).
Стоят оконечные резисторы на последнем устройстве и подтянут на МКОН, иначе вообще опроса нет.
На первом МКОНе поочередно вещают slaveID 3 или 4, 5 всегда вещает, на втором всегда вещают 10 и 12, 11 не вещает вообще. Итого не больше двух устройств на МКОН.
В чем может быть проблема?
MOXA или китайский usb\rs485 опрашивают все три устройства без проблем.
Евгений Кислов
19.07.2023, 11:52
Добрый день!
Решили тут импортозаместить Moxa MGate на ОВЕН МКОН 24.
Сразу два МКОНа 24 не могут опросить больше двух устройств.
На первом 3 контроллера вентиляции (slaveID 3,4,5), на втором два контроллера вентиляции и компрессор.(slaveID 10,11,12).
Стоят оконечные резисторы на последнем устройстве и подтянут на МКОН, иначе вообще опроса нет.
На первом МКОНе поочередно вещают slaveID 3 или 4, 5 всегда вещает, на втором всегда вещают 10 и 12, 11 не вещает вообще. Итого не больше двух устройств на МКОН.
В чем может быть проблема?
MOXA или китайский usb\rs485 опрашивают все три устройства без проблем.
Добрый день.
У МКОН есть ограничение - не более 2 одновременных TCP-подключений.
Кто у вас выступает в роли Modbus TCP Master?
AlexanderUshakov
19.07.2023, 11:55
Добрый день.
У МКОН есть ограничение - не более 2 одновременных TCP-подключений.
Кто у вас выступает в роли Modbus TCP Master?
Опрашивает OPC-сервер KepserverEX 5
Евгений Кислов
19.07.2023, 12:10
Опрашивает OPC-сервер KepserverEX 5
Тогда вам нужно изучить документацию на него, чтобы понять, поддерживает ли он работу со шлюзами Modbus TCP/Modbus RTU через одно TCP-соединение.
AlexanderUshakov
19.07.2023, 12:29
Тогда вам нужно изучить документацию на него, чтобы понять, поддерживает ли он работу со шлюзами Modbus TCP/Modbus RTU через одно TCP-соединение.
хорошо, а как объясните то, что я беру к примеру CAS Modbus Scanner и опрашиваю поочередно каждый контроллер, т.е. получается занимаю только одно TCP соединение и при этом результат тот же, первое и последнее устройство опрашивается, а среднее нет?
Или МКОН цепляет к произвольным двум slaveID адресам TCP-соединение и вещает в сеть? Что-то понять не могу.
AlexanderUshakov вроде МКОН должен поддерживать до 32-х устройств без повторителей на линии RS485. Подключившись вместо МКОН вы опрашиваете все 3-и устройства ?
МКОН вроде ничего не вещает, раз мастер со стороны TCP, а на RS485 висят слейвы. Слейвы так вообще ничего сами по себе не вещают
Евгений Кислов
19.07.2023, 12:42
хорошо, а как объясните то, что я беру к примеру CAS Modbus Scanner и опрашиваю поочередно каждый контроллер, т.е. получается занимаю только одно TCP соединение и при этом результат тот же, первое и последнее устройство опрашивается, а среднее нет?
Или МКОН цепляет к произвольным двум slaveID адресам TCP-соединение и вещает в сеть? Что-то понять не могу.
Видимо, CAS Modbus Scanner тоже не поддерживает работу через одно TCP-соединение.
У любого конвертера есть лимит одновременных подключений по TCP.
У МКОН их 2. У MGate MB3180 - 16.
Kepserver и CAS Modbus Scanner, видимо, устанавливают отдельное подключение на каждый "узел" слэйва в своей конфигурации (хотя IP-адреса в узлах одни и те же, и отличаются только Unit ID) - поэтому лимит исчерпывается.
В корректной реализации - устанавливается одно TCP-соединение с конвертером и через него отправляются запросы к разным RTU-слэйвам с разными Unit ID.
Было бы больше слэйвов - вы бы и на MGate столкнулись с такими же проблемами, как здесь:
https://moxa.ru/forum/index.php?/topic/69270-opc-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80-%D0%B8-mgate-mb3180/
Очень стала интересна схема подключения :)
Если мастер ОДИН и выполняет запросы по Modbus TCP, то сколько один мастер сети должен занять сокетов для опроса 30 устройств слейв подключенных к RS485 МКОН ?
аааа, прикольно, оказывается и так было можно создать сеть, что запросы будут идти параллельно.... тут действительно только создавать одну сессию в рамках которой выполнять опрос последовательно подключенных слейвов... век живи....
Евгений Кислов
19.07.2023, 12:46
Очень стала интересна схема подключения :)
Если мастер ОДИН и выполняет запросы по Modbus TCP, то сколько один мастер сети должен занять сокетов для опроса 30 устройств слейв подключенных к RS485 МКОН ?
Мастер, поддерживающий корректную работу с конвертерами TCP/RTU, займет один сокет.
Евгений Кислов ага, я уже понял в чем прикол.... :)
AlexanderUshakov
19.07.2023, 13:15
Видимо, CAS Modbus Scanner тоже не поддерживает работу через одно TCP-соединение.
У любого конвертера есть лимит одновременных подключений по TCP.
У МКОН их 2. У MGate MB3180 - 16.
Kepserver и CAS Modbus Scanner, видимо, устанавливают отдельное подключение на каждый "узел" слэйва в своей конфигурации (хотя IP-адреса в узлах одни и те же, и отличаются только Unit ID) - поэтому лимит исчерпывается.
В корректной реализации - устанавливается одно TCP-соединение с конвертером и через него отправляются запросы к разным RTU-слэйвам с разными Unit ID.
Было бы больше слэйвов - вы бы и на MGate столкнулись с такими же проблемами, как здесь:
https://moxa.ru/forum/index.php?/topic/69270-opc-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80-%D0%B8-mgate-mb3180/
Так в конфигурации CAS Modbus Scanner присутствует только одно соединение. Один IP, один slaveID, один запрос по регистрам. SlaveID 10 я опросил получил значения, нажал дисконект, поменял в конфигурации SlaveID на 11 нажал Poll и получил ошибку. Нажал дисконект поменял slaveID на 12, нажал poll и получил значения. Тут нет одновременного обращения к разным slaveID МКОНа.68988
Евгений Кислов
19.07.2023, 13:54
Так в конфигурации CAS Modbus Scanner присутствует только одно соединение. Один IP, один slaveID, один запрос по регистрам. SlaveID 10 я опросил получил значения, нажал дисконект, поменял в конфигурации SlaveID на 11 нажал Poll и получил ошибку. Нажал дисконект поменял slaveID на 12, нажал poll и получил значения. Тут нет одновременного обращения к разным slaveID МКОНа.68988
Понятно. Тогда напишите, пожалуйста, на support@owen.ru и предоставьте удаленный доступ по AeroAdmin - посмотрим, в чем может быть дело.
AlexanderUshakov
19.07.2023, 13:59
Понятно. Тогда напишите, пожалуйста, на support@owen.ru и предоставьте удаленный доступ по AeroAdmin - посмотрим, в чем может быть дело.
Прошу прощения, инженер поменял 11 на 13 и не сказал. CAS Modbus Scanner опрашивает все три устройства по отдельности нормально. Этот вопрос снят.
А насчет правильного modbus TCP мастера можете подсказать софтину, которая через 1 tcp соединение опрашивает? Чисто проверить.
Евгений Кислов
19.07.2023, 14:02
Прошу прощения, инженер поменял 11 на 13 и не сказал. CAS Modbus Scanner опрашивает все три устройства по отдельности нормально. Этот вопрос снят.
А насчет правильного modbus TCP мастера можете подсказать софтину, которая через 1 tcp соединение опрашивает? Чисто проверить.
Можно, например, использовать виртуальный контроллер CODESYS V3.5, и действовать по аналогии с этим видео:
https://youtu.be/Czcar_HOTxU
https://owen.ru/forum/showthread.php?t=28167&p=338820&viewfull=1#post338820
AlexanderUshakov
19.07.2023, 14:08
Можно, например, использовать виртуальный контроллер CODESYS V3.5, и действовать по аналогии с этим видео:
https://youtu.be/Czcar_HOTxU
https://owen.ru/forum/showthread.php?t=28167&p=338820&viewfull=1#post338820
Я просто почему спросил, в настройках Kepserver есть эта опция использовать один сокет для всех slave устройств и она включена. Но тем не менее одно устройство стабильно не подключается68993
Евгений Кислов
19.07.2023, 14:18
Я просто почему спросил, в настройках Kepserver есть эта опция использовать один сокет для всех slave устройств и она включена. Но тем не менее одно устройство стабильно не подключается68993
Да, судя по названию - это именно та опция, которая вам нужна.
Но судя по остальной приведенной информации - корректно она не работает.
Я просто почему спросил, в настройках Kepserver есть эта опция использовать один сокет для всех slave устройств и она включена. Но тем не менее одно устройство стабильно не подключается
Цитата их справки:
The ability to put the Modbus Ethernet driver into "single socket" mode is very important for users who are trying to use the Modbus Ethernet driver to talk with a Modbus-Ethernet-to-Modbus-RTU bridge product. Most of these products allow the user to connect multiple RS-485 serial based devices to a single Modbus-Ethernet-to-Modbus-RTU bridge. When a gateway is handling a number of serial devices, the Share a single socket across all devices on this channel option must be unchecked.
AlexanderUshakov
19.07.2023, 15:28
Цитата их справки:
Вообщем опрос пошел через Kepserver, для этого я в настройках канала Channel Properties, во вкладке Advanced выбрал Virtual Network = 3, Transactions per cycle = 3 и Scan Rate для устройства, что не опрашивался сделал 800мс, а для тех что опрашивались 3000 мс.
Выглядит как костыли, но опрос идет стабильный. )
AlexCrane
14.06.2024, 14:45
Я так понимаю что через OWEN OPC Server тоже можно опрашивать не более двух устройств?
Pavel5698
14.06.2024, 15:11
Я так понимаю что через OWEN OPC Server тоже можно опрашивать не более двух устройств?
верно
используйте masteropc, если хотите больше
kondor3000
14.06.2024, 20:37
Я так понимаю что через OWEN OPC Server тоже можно опрашивать не более двух устройств?
Ничего подобного, делал опрос 3 и более устройств через OWEN OPC Server
AlexCrane
17.06.2024, 08:54
Ничего подобного, делал опрос 3 и более устройств через OWEN OPC Server
Если через МКОН то подскажите как. Пока не получилось у меня
kondor3000
17.06.2024, 11:26
Если через МКОН то подскажите как. Пока не получилось у меня
Просто опрос модулей сервером OWEN OPC Server, без МКОНа.
AlexCrane
17.06.2024, 13:08
Просто опрос модулей сервером OWEN OPC Server, без МКОНа.
Напрямую никак, только через езернет, поэтому МКОН, а устройств пять нужно опросить.
только через езернет, поэтому МКОН
Ложный вывод. Полно устройств, умеющих в шлюз modbus tcp/rtu. Более того - сейчас даже многие роутеры штатно умею так шлюзовать.
Что касается МКОН, то помимо непонятного ограничения на 2 tcp-подключения, там ничего не мешает несколько устройств в 485-ой сети опрашивать. Может если только что устройства в сети RTU не могут иметь адрес 1, поскольку его МКОН за собой зачем-то застолбил.
Что касается OWEN OPC Server, то он вполне себе способен опрашивать несколько устройств modbus tcp через шлз. Проверено. Правда, через другой шлюз, не МКОН. Но, мне непонятно - что в МКОН такого особенного, чтобы он не был способен выполнять свою штатную функцию?
AlexCrane
17.06.2024, 15:48
Ложный вывод. Полно устройств, умеющих в шлюз modbus tcp/rtu. Более того - сейчас даже многие роутеры штатно умею так шлюзовать.
Что касается МКОН, то помимо непонятного ограничения на 2 tcp-подключения, там ничего не мешает несколько устройств в 485-ой сети опрашивать. Может если только что устройства в сети RTU не могут иметь адрес 1, поскольку его МКОН за собой зачем-то застолбил.
Что касается OWEN OPC Server, то он вполне себе способен опрашивать несколько устройств modbus tcp через шлз. Проверено. Правда, через другой шлюз, не МКОН. Но, мне непонятно - что в МКОН такого особенного, чтобы он не был способен выполнять свою штатную функцию?
Но мы же инструкцию читаем в последнюю очередь... Да и просто МКОН был в наличии. Да и что OWEN OPC Server занимает по одному tcp-подключению на каждый прибор тоже не знал. Ну и наложилось. Попробую другой прозрачный шлюз.
Да и что OWEN OPC Server занимает по одному tcp-подключению на каждый прибор тоже не знал.
Можно поинтересоваться - откуда такие выводы? Желательно со ссылкой на документацию.
И как вы вообще себе такое представляете? Чисто технически. Абстрагируемся от МКОН и ОВЕН OPC.
Шлюз слушает на на порту 502. Приложение с адреса х.х.х.х запрашивает открытие сокета. Шлюз открывает. Работаем. С каким прибором за шлюзом - абсолютно не важно. TCP про это знать ничего не знает и не должен знать. Как приложение может запросить открытие ещё одного соединения с того же самого адреса х.х.х.х на том же самом порту 502? Как? И зачем?
AlexCrane
18.06.2024, 07:51
Я не представляю, я проверил (для МКОН), читает только два прибора одновременно, причем два из пяти в случайном порядке
Может что с конкретным экземпляром МКОН не так? Я не вижу причин, по которым нельзя было бы опрашивать более 2 устройств в сети RTU через МКОН. Сколько там у него заявлено? До 32-х.
В противном случае давно вой до небес стоял бы, он же не первый день продаётся.
Pavel5698
18.06.2024, 15:03
Конечно можно до 32-х, но не с помощью Owen OPC. Owen OPC создает отдельные tcp-соединения для каждого прибора в узле, даже если у всех приборов один IP-адрес. МКОН поддерживает до 2-х tcp-соединенний, поэтому вот так.
Таких проблем нет с другими ПО и приборами. Вот воя и нет.
Может что с конкретным экземпляром МКОН не так? Я не вижу причин, по которым нельзя было бы опрашивать более 2 устройств в сети RTU через МКОН. Сколько там у него заявлено? До 32-х.
В противном случае давно вой до небес стоял бы, он же не первый день продаётся.
А он давно и стоит. У меня штук 7 валяется, тоже вляпался в своё время.
AlexCrane
19.06.2024, 07:41
Вопрос к разработчикам - почему в OWEN OPC Server не добавили данный функционал, другие OPC же умеют (тот же мастер опс к примеру)?
Антон Новайкин
19.06.2024, 10:15
Вопрос к разработчикам - почему в OWEN OPC Server не добавили данный функционал, другие OPC же умеют (тот же мастер опс к примеру)?
Добрый день.
Owen OPC Server это бесплатное ПО, и оно имеет ряд ограничений.
В настоящий момент нет планов по его доработкам.
Если появятся - это будет первое что мы реализуем.
Я не представляю, я проверил (для МКОН), читает только два прибора одновременно, причем два из пяти в случайном порядке
А ведь Вы правы - действительно для каждого устройства отдельное соединение устанавливает. Раз уж в теме сотрудник подтвердил - решил проверить. Зачем так сделано - загадка.
Емельянов Кирилл
24.07.2024, 12:02
Когда мастер в сети Eth, а слейвы в RS485, надо ли после запроса к 1-ому слейву ждать его ответ или можно сразу слать запрос ко 2-ому слейву. Иными словами реализована ли на МКОН очередь сообщений?
Надо ждать ответ, потом слать новый. Вроде так работают все преобразователи интерфейса. МКОН тут не исключение.
Надо ждать ответ, потом слать новый. Вроде так работают все преобразователи интерфейса. МКОН тут не исключение.
Не надо. Гейт сам должен разобраться - выстроить входящие на eth в очередь, если запросы по нему поступают быстрее, чем отвечают утр-ва на RS. Исключение тут МКОН или нет - не знаю, тут есть люди, которые точно знать должны.
МКОН - не просто преобразователь интерфейса, а преобразователь протоколов.
imaex вроде МКОН рулит очередями только двух мастеров к одному устройству. За ним то все равно висят последовательные устройства. И рекомендация от производителя увеличенный timeout при ожидании ответа, чтобы мастер2 дождался запроса/ответа пока в этот момент происходит запрос/ответ от мастера1.
Если слать постоянно запросы на разные устройства RS то мы получим гарантированный выход за timeout.
Не настолько этот преобразователь МКОН умен, к сожалению. Читайте рекомендации от Овен, которые тут неоднократно освещались по этому поводу.
МКОН к сожалению не шлюз, который можно настроить на опрос приборов RS485 а мастерам по TCP выдавать из буфера прочитанное.
Помнится я покупал шлюз (SNMP)Modbus TCP - Modbus RTU америкосовский по тем деньгам так тыщ за 35 в году 13-14-м - вот он сам опрашивал приборы и по SNMP отдавал данные хоть 10-рым.
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
24.07.2024, 14:58
Что тут говорить, надо у муравьёв учиться, Валенок в какой-то теме писал об этом и ссылку давал!
Почему очередями? Очередь одна должна быть, кмк. И почему от двух мастеров? Мастер и один способен несколько запросов к разным устр-ам по ту сторону выдать.
МКОН прозрачный преобразователь протокола, запрос - переадресация в RTU устройство - ожидание ответа - переадресация к ПК (ПЛК) - по другому ОНО не работает.
С какого это перепуга один мастер должен даже предполагать о существовании какого-то другого? Мне соединение открыли, не отфутболили? Вот и будьте добры обслуживать. Ни про кого другого знать не желаю.
там вроде всего два сокета можно открыть, опять же, читайте документацию и форум.
А откуда ещё, как не из буфера он может отдать прочитанное? Еще раз, это прозрачный конвертер протокола на лету, как у Moxa, как у USR-IOT - это НЕ ШЛЮЗ, который опрашивает устройства самостоятельно
шлюз это вот такое, как у https://www.adfweb.com/home/ - они настраиваются на опрос устройства, а scada по другому протоколу забирает у них данные, не обращаясь к устройствам
хотя у ADFWeb там и шлюзы и конвертеры, всякие звери есть. Основное отличие шлюза, что он опрашивает устройство, а у него данные забирает ПК, не обращаясь к устройствам.
А МКОН пропускает запросы сквозь себя, меняя протокол.
МКОН прозрачный преобразователь протокола, запрос - переадресация в RTU устройство - ожидание ответа - переадресация к ПК (ПЛК) - по другому ОНО не работает.
Еще раз, это прозрачный конвертер протокола на лету, как у Moxa, как у USR-IOT - это НЕ ШЛЮЗ, который опрашивает устройства самостоятельно
Вы опять какую-то свою терминологию выдумали? Это именно что шлюз пртоколов. Преобразует из одного протокола в другой и обратно. Шлюз НЕ опрашивает ничего самостоятельно, его дело шлюзовать. По определению.
И не переадресация, а именно что преобразование. Хоть там не сильно много, но, тем не менее. При чём тут Moxa и USR-IOT? И у тех, и у других есть как шлюзы протоколов, так и преобразователи интерфейсов. Вот последние как раз именно что переадресуют фактически.
шлюз это вот такое, как у https://www.adfweb.com/home/ - они настраиваются на опрос устройства,
Вот это как раз не шлюз протоколов. Мне через секунду понадобилось опросить что-то, на что ваше умное устройство не настроено. И?
там вроде всего два сокета можно открыть, опять же, читайте документацию и форум.
Вы читать умеете? А понимать? При чем тут это? Да хоть 10. Если мне открыли сокет, то меня уже не интересует - есть там ещё желающие или нет.
Вот Вам для примера лог работы шлюза в RTU с двумя запросчиками одновременно. Mgate просто потому, что он есть и там легко и просто лог снять.77560
imaex если вам будет легче понять, есть шлюзы тип1 - МКОН и шлюзы тип2 типа некоторые из ADFweb (так как у них большой выбор устройств).
если что. у меня есть USR-IOT по аналогии с МКОН - преобразующий Modbus TCP в Modbus RTU и по работе сталкивался с ADFWeb SNMP - Modbus RTU и еще одним.
Например ADFWeb не надо слать запросы устройству, а просто его опрашивают по SNMP (то есть только читают), предварительно сам ADFWeb настраивается на опрос, где прописывается адрес Modbus устройства, регистры, типы переменных, перестановка и т.д.
Если вы не видите разницу, ну и ладно.
Вот это как раз не шлюз протоколов. Мне через секунду понадобилось опросить что-то, на что ваше умное устройство не настроено. И?
и нихрена вы не получите, так как надо снова конфигурировать устройство - по другому оно тоже не работает.
Если вы не сталкивались с типом 2, не говорит о том, что их нет. Это примерно как Scada, опросили по Modbus, а отдаем ну скажем по OPC UA. Только в маленькой коробочке, с меньшей памятью и меньшими возможностями.
Если вы не сталкивались с типом 2, не говорит о том, что их нет. Это примерно как Scada, опросили по Modbus, а отдаем ну скажем по OPC UA. Только в маленькой коробочке, с меньшей памятью и меньшими возможностями.
Вот ждал, когда Вы про OPC вспомните. Эта хрень принципиально ничем от OPC не отличается. Это не шлюз протоколов.
imaex проверить к какому из описанных мною типов относится МКОН или вашу Моксу очень просто. Отключите опрос со стороны ПК - индикатор RS485 моргать перестал? - тип 1
Моргает - тип2
Для пущей уверенности стать снифером порта и посмотреть наличие пакетов между шлюзом и RS485 устройством
а по английски они собаки все Gate, и приходится долго ковырять документацию, особенно если требуется тип 2, который самостоятельно умеет опрашивать устройства без наличия ПК.
при 35 упомянутых выше тысях, можно из отдельного плк шлюз любого типа залепить. Хоть 1ого, хоть 2ого. По моему до 30..35 соединений.
2x 485, 232, почти 8М для любых очередей - просто праздник
Валенок мне тогда нужно было в SNMP, подрядчик лоханулся, купил ПЛК от Schneider, у которого было упоминание SNMP (у заказчика была система мониторинга с поддержкой SNMP), да только в ПЛК этот протокол оказался служебным и никаким образом не мог передавать переменные по SNMP. Пришлось искать шлюз.
Кстати подобный шлюз есть у Овен (был) на основе ЕКОН134 и программировать его там надо упариться, судя по документации. И стоило это тогда еще все равно дороже.
Кстати шлюзы от ADFWeb стоили дешевле, тоже один раз пришлось использовать, но вот ADFweb мне не понравился, умеет меньше, умеет хуже чем америкосовский babel-buster (кажется так назывался) к нему тоже были нарекания незначительные.
... тип 1
...тип2...
...Gate...тип 2....
Вы с диабетом попутали. Сахарным. Сам придумал - сам теперь обосновывает.
imaex да изучите вы уже документацию на свои в наличии. И посмотрите документацию на вот этот ADFWeb https://consteel-electronics.ru/sistemy-avtomatizacii/preobrazovateli/snmp/snmp-to-modbus-rtu/hd67164-232-a1
Эта железка САМОСТОЯТЕЛЬНО умеет читать Modbus RTU устройства в цикле, не зависимо, включен ПК со Scada или нет.
Это и есть Gate второго типа, к нему за данными можно обратиться в любой момент, любой программой (в данном случае по SNMP) хоть Scada хоть SNMP браузером любым и получить данные, которая эта железка вычитывает из Modbus RTU устройств.
Еще раз, этот шлюз САМ опрашивает Modbus RTU устройства, которые вы сконфигурируете при помощи их ПО.
Америкосовский был покруче, у него был WEB интерфейс и настраивалось все там.
imaex да изучите вы уже документацию на свои в наличии. И посмотрите документацию на вот этот ADFWeb https://consteel-electronics.ru/sistemy-avtomatizacii/preobrazovateli/snmp/snmp-to-modbus-rtu/hd67164-232-a1
А оно мне надо? Я и так вполне себе представляю, что это такое.
Это и есть Gate второго типа
С Вас пруф на определение "шлюза 2-го типа". Общепринятое. А не от melky или ADFWeb.
Еще раз для особо упёртых - это не шлюз. Так я тоже могу нафантазировать и обозвать модуль в/в шлюзом. Или ПЛК какой. Не, ну а чётакова? Назову 3-го типа. Или 10-го.
В конце концов, в теме обсуждается "МКОН преобразователь протокола Modbus". В частности. Ну и прочие шлюзы modbus заодно. А не неведомые зверушки от ADFWeb.
По английски они все Gate
По русски прямой перевод Шлюз
Фактически один это Конвертер протокола прозрачный - МКОН, moxa MGate и многие другие, без запросов со стороны ПК опроса нижних устройств нет и не будет.
Вторые это действительно шлюзы, которые сами опрашивают устройства и держат в своей памяти все данные.
Как вы их сами классифицирует, напишите. Ну чтобы на вашем языке общаться.
По английски они все Gate
По русски прямой перевод Шлюз
Прямой перевод на русский - ворота.
Вторые это действительно шлюзы, которые сами опрашивают устройства и держат в своей памяти все данные.
Говорящие ворота - это сильно.
Шутить можно много.
Тем не менее, как Вы назовете вот такое устройство https://moxa.ru/shop/modbus/mgate_mb3660/mgate-mb3660-16-2ac/ , которое может (это его нормальная конфигурация) держать в памяти перечень адресов подчиненных устройств и их регистров, опрашивая их самостоятельно?
В названии - шлюз (Gate).
imaex ну вот классифицируйте их, и мы будем под вас подстраиваться :)
Тем не менее, как Вы назовете вот такое устройство https://moxa.ru/shop/modbus/mgate_mb3660/mgate-mb3660-16-2ac/ , которое может (это его нормальная конфигурация) держать в памяти перечень адресов подчиненных устройств и их регистров, опрашивая их самостоятельно?
Не нормальная, а дополнительная, скорее. В документации сказано же вполне конкретно - для чего существует Agent mode. К тому же для клиента он остаётся всё тем же modbus tcp устройством, для клиента ничего не меняется.
А в остальном 3660 ничем не отличается от других в линейке MGate. Как же ещё его называть прикажете?
imaex вероятно вы привыкли общаться только с Modbus TCP, а таких гейтов на разные протоколы валом - BacNet, LON, EtherCat, KNX и так далее. В них в принципе невозможно сделать конвертацию протоколов на лету.
И вот подобные гейты либо конфигурируются специальным ПО, либо через Web уже в зависимости от производителя, протокола и т.д.
самый частый пример, это гейты в Modbus RTU (или TCP) для подключения чиллеров и кондиционеров, всяких там Dantex, Midea и прочих. Другие протоколы тоже попадаются, когда делают здание с мониторингом всей инженерки, системы типа BMS.
Часто все это можно объединить просто Scada системой, но увы, у нас со Scada в России печальная ситуация, мало какие из коробки поддерживают кучу протоколов.
TM, но там ценник и с наскока самостоятельно упаришься.
imaex вероятно вы привыкли общаться только с Modbus TCP, а таких гейтов на разные протоколы валом - BacNet, LON, EtherCat, KNX и так далее.
В конце концов, в теме обсуждается "МКОН преобразователь протокола Modbus". В частности. Ну и прочие шлюзы modbus заодно. А не неведомые зверушки от ADFWeb.
А так же не "BacNet, LON, EtherCat, KNX и так дале".
imaex ну так по поводу МКОН изначально написал, это прозрачный шлюз протокола. В общем назовите его как угодно, суть его в том, что самостоятельно он не опрашивает устройства Slave, только при помощи компьютера в качестве мастера.
МКОН даже очередь запросов одного мастера не может выстроить, точнее там наверняка timeout-ы срабатывают у верхней системы, если идут попытки читать не последовательно, дожидаясь ответов.
з.ы. с трудом себе такое представляю, что там натворили в его прошивке. Раз у народа из нескольких устройств RTU не все отдают данные, да еще и то одну часть, то другую.
МКОН даже очередь запросов одного мастера не может выстроить,.
Имхо - это ключевой вопрос вашей бурной беседы c imaex
Все таки очередь строится или нет?
Валенок ну если люди пишут, что из нескольких устройств опрашивается два, но в рандомном порядке, то стоит посмотреть как настроена система верхнего уровня, если там опросы строго последовательны устройство за устройством (даже по TCP), то вероятно проблема в самом МКОН.
Если же там параллельные запросы по TCP, а на хвосте МКОН висят последовательные RTU устройства - то как бы какие претензии к МКОН ? он бы и рад, да устройство на его хвосте не могёт...
я экспериментировал на обычном преобразователе интерфейсом Ethernet-RS485, опрашивая ПР200 (всего одно устройство) двумя scada системами.
1. надо синхронизировать время двух ПК
2. надо настроить периоды опроса таким образом, чтобы одна система опрашивала каждые 10 минут например но в минуты часа :00, :10, :20 и т.д.
а вторая система так же выполняла опрос каждые 10 минут но в минуты часа :01, :11, :21 и т.д.
и прекрасно все работало. Преобразователь держит несколько сокетов. Если будут несколько устройств, просто надо сдвигать минуты, типа одна :00, :10, :20, другая :03, :13, :23 и т.д.
Как тут МКОН работает и главное как верхние системы большой вопрос
Валенок ну если люди пишут, что из нескольких устройств опрашивается два, но в рандомном порядке
Через Owen OPC. Разобрались же, с чем это связано.
Имхо - это ключевой вопрос вашей бурной беседы c imaex
Все таки очередь строится или нет?
Всё же 2 одновременных подключения он поддерживает, т.ч. очередь по-любому должна быть.
Про очередь на два мастера писали представители Овен, и про увеличение настройки timeout так же они писали.
чтобы второй пославший запрос дождался ответа, если в этот момент идет запрос первым.
а причем тут соединение? Можно открыть и молчать. Запросы все равно одновременно не проканают как не старайся хоть скока конектов. Вернутся ли 3 ответа если отправить 3 запроса, пусть и с паузой но меньшей времени ответа на первый?
Судя по вышесказаному - очередь какая никакая есть
Собсно следующие вопросы
1.Не закрывает ли мкон конект после ответа?
2.Какая глубина очереди?
а причем тут соединение? Можно открыть и молчать.
1. Это к кому вопрос?
2. А можно и не молчать. В любом случае один опросчик по tcp не знает и знать ничего не обязан про другой, о чём уже было сказано. Вывод - очередь есть. Обязана быть, иначе вообще ничего работать не будет.
Дык и ненужно знать про других. Тока учитывать придется.
Тута же как - стоишь один в заводской душевой. Под горячим душем. И внезапно со смены 50 челов. Сами же выше писали. Ну попробуйте не учитывать))
Дык и ненужно знать про других. Тока учитывать придется.
Не не нужно, а невозможно. А учитывать всегда надо.
Да невозможно. Но учитывать придется, с этим есть консенсус
А по вопросам выше что-нить есть? Мкон не рвет конекты после ответов?
Мкон не рвет конекты после ответов?
Судя по тому, что люди писали ранее - нет, не рвёт. Да и с чего бы? Если бы у меня был МКОН (чур меня) - сказал бы точно.
Тогда не ясно, по тому же конекту пришел тот же запрос, тока 7 байт другой. Мкон говорит неа, а вот тому я не переправлю?
..
я экспериментировал на обычном преобразователе интерфейсом Ethernet-RS485, опрашивая ПР200 (всего одно устройство) двумя scada системами.
1. надо синхронизировать время двух ПК
2. надо настроить периоды опроса таким образом, чтобы одна система опрашивала каждые 10 минут например но в минуты часа :00, :10, :20 и т.д.
а вторая система так же выполняла опрос каждые 10 минут но в минуты часа :01, :11, :21 и т.д.
..
Если бы про самый низ ethernetа:
1. Не надо
2. Прослушивание и рандомные паузы. Разрешение коллизий. До нас. 1974 год
..Как тут МКОН работает и главное как верхние системы большой вопрос
Т.к. тут очередь (все утверждают, я не против), то видимо так:
Есть почтальон(1) на велике и склад посылок(2) куда возят почту чоткие пацаны(3) из разных раёнов на заниженных ладах .
1. Мастер на rs (Приехал. Посмотрел. Взял одну. Повёз)
2. Очередь
3. Коннекты
Валенок при чем тут паузы и коллизии ethernet если мы рассматриваем преобразователь в рамках подключенных к нему RTU устройств?
я делаю второй запрос, а там прёт ответ от RTU устройства первому запрашивающему, и преобразователь ему такой, НА тебе опять пакет RTU, че ты тут мне шлешь? :) Примерно как на линию RS подключить два мастера сразу с циклическим опросом.
при чем тут паузы и коллизии ethernet если
не раглядел про
а обычном преобразователе интерфейсом Ethernet-RS485,
Показалось что просто 2 мастера в одной сети
Примерно как на линию RS подключить два мастера сразу с циклическим опросом.
Тогда б как с коллизиями
Про почтальона и поцанов - в силе.
Валенок с двумя мастерами аналогично, в моем случае та же синхронизация времени между ПК и разнесение опроса по времени. У двух ПК будут например USB-RS485. Сути не меняет. Эксперимент в этом и заключался, заставить работать двух мастеров при одной линии RS на хвосте.
Если добиться синхронизации времени у 2-х ПЛК можно сделать аналогично. По крайней мере на многих ПЛК есть возможность синхронизации времени.
Или там можно проще, один прочитал, передал на чтение другому и так по кругу.
заставить работать двух мастеров при одной линии RS на хвосте.
Клиентов при "преобразователе интерфейсом* Ethernet-RS485,"?
*и протокола?
Если добиться синхронизации времени у 2-х ПЛК можно сделать аналогично
При нормальной очереди - не требуется.
Валенок да не важно, Ethernet-RS или USB-RS485, я кажется и то и то цеплял для тестов. МКОН у меня нет, хотя и его можно, все равно ПК опрашивает через него.
Где ж тут нормальная очередь, если устройства разные?
Где ж тут нормальная очередь,
Вроде как определили что у МКОН есть очередь?
Если любой преобразователь (мобас-tcp/модбас-RTU) запросы от любого кол-ва модбас-клиентов в одну rs не ставит в очередь, то этот преобразователь - какашка. Не?
Где ж тут нормальная очередь, если устройства разные?
Не уловил сути вопроса.
Нормальность - это к организации самой очереди, сколько устройств (клиентов по tcp/слейвов по rs) не имеет значения.
Если любой преобразователь (мобас-tcp/модбас-RTU) запросы от любого кол-ва модбас-клиентов в одну rs не ставит в очередь
А такие вообще бывают? melky писал про конвертор eth/rs, там с сериализацией вообще проблемы, принципиальные, кмк. Я так думаю, что там проблемы вообще не на 100% разрешимые, когда у вас со стороны rs не modbus, а произвольный протокол. Хотя, то же melky упоминал про моксовский дивайс, где такое как бы гарантируют. Но, я лично с такими дела не имел.
МКОН, если что, тоже в таком режиме умеет работать, т.е. без преобразования протокола.
А такие вообще бывают?.
А в чем проблема сериализации протоколов вида запрос/ответ (пусть про модбас конкретно)? Задача то простейшая. МКон же с очередью? А очередь и есть сериализация
А в чем проблема сериализации протоколов вида запрос/ответ (пусть про модбас конкретно)? Задача то простейшая. МКон же с очередью? А очередь и есть сериализация
Очередь в режиме шлюза tcp/rtu, там протоколы с обеих сторон предопределены. Как тот же МКОН будет работать в т.н. "режиме прозрачного шлюза" (так в документации), т.е. eth/rs - я не знаю. Во всяком случае с другим (не МКОН) преобразователем я на стороне клинта запросто получал данные, запрошенные другим клиентом. Хотя со стороны rs и банальный modbus был. А вот в режиме шлюза tcp/rtu - всё красиво и вообще без вопросов.
Ну какие прозрачные данные если форматы модбас-tcp и модбас-rtu отличаются?
с другим (не МКОН) преобразователем я на стороне клинта запросто получал данные, запрошенные другим клиентом
Давайте определимся. Если все модбас-клиенты
-обращаются к одному слейву,
-одной и той же функцией
-с одним кол-вом регистров в запросе,
-слишком маленький таймаут на рту (для овен-модулей это менее 3-5мс),
-после запроса не выдерживается минимальная рту-пауза
-перед запросом не вычитывается в 0 rs-буфер (в который может прилететь еще что-то пока отправляли по tcp)
это вполне возможно. Но:
-получить идеальный сдвиг ответов нереально, т.е. будут регулярные ошибки с CRC, а при отсуствии любого из вышеперечисленных условий ошибки (по длине и т.п) будут просто сыпатся. Что было у Вас?
Что было у Вас?
На стороне RS 2 110-ых модуля. Клиент на обоих хостах со стороны Eth абсолютно одинаковые (АРМ SCADA). Чётко было видно ложные данные с модуля аналоговых - давление вместо температуры, например. На данные с модуля дискретов я даже смотреть не стал - стало не интересно.
И с чего бы ошибкам CRC быть, если преобразователь упаковал в TCP абсолютно корректный ответ modbus rtu, а на стороне Eth драйвер абсолютно нормально распаковал его?
На стороне RS 2 110-ых модуля. Клиент на обоих хостах со стороны Eth абсолютно одинаковые (АРМ SCADA).
Ну давайте по порядку запросы и ответы. Логи есть?
1.Первый клиент запросил у какого 110-го что?
преобразователь упаковал в TCP абсолютно корректный ответ modbus rtu,
Тот же 110й. (их у Вас 2) как у предыдущего запроса от другого клиента:
-Функция - та же
-Длина запроса - та же
Предыдущий запрос rtu определилcя как таймаут. Что там клиенту сделали? Ведь его данные ему не пришли а пришли при ожидании текущего. А ответ на запрос текущему пришел - кому? И опять все идеально?
с чего бы ошибкам CRC быть
И тот 110й который хотел ответить на текущий запрос ему, галантно пропустил (подождите! подождите! меня забыли!) ответ от другого? Ну чтоб CRC'ы не побились. Это же ведь в модбас заложено, да?
Ну давайте по порядку запросы и ответы. Логи есть?
С ума сошли? Это было как бы не с год назад. Да и тестировал я тот преобразователь в таком режиме чисто любопытства ради.
С ума сошли? Это было как бы не с год назад.
А мне вам на слово верить что все так идеально было. Абсолютно четкий сдвиг и все дела?
Изобразите словами возможную последовательность запросов/ответов. Вы же знаете какие 110-ые, что и как опрашивали. Я точно нет.
Я ж не говорю что не возможно. Я сказал что ошибки - были. И регулярно. Как минимум с частотой смены слейва в опросе. Нет?
А мне вам на слово верить что все так идеально было.
Думаете, меня это волнует? Не интересно.
Думаете, меня это волнует? Не интересно.
Ну а чём тогда говорить?
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot