Просмотр полной версии : В продаже МКОН - преобразователь протокола Modbus!
Евгений Дударев
04.03.2020, 13:38
Коллеги, приветствую!
Стартовали продажи преобразователя протоколов Modbus ASCII/RTU и Modbus TCP по интерфейсам связи RS-485 и Ethernet. Для протоколов поддерживаются режимы Master и Slave.
47733
Краткая информация об устройстве:
Взаимное преобразование протоколов/интерфейсов Modbus RTU/ASCII (RS-485) <-> Modbus TCP (Eth)
Готовые сценарии работы:
- Master в сети RS-485/Slave в сети Ethernet (до 31 Slave)
- Master в сети Ethernet/Slave в сети RS-485 (до 32 Slave без повторителя)
Быстрая настройка через Owen Configurator благодаря плагинам для МКОН
Рабочая температура: -40 ... + 55 °С
Монтаж на DIN-рейку.
Питание ~ 230 В / = 24 В
Цена 12 120 руб. с НДС
Руководство по эксплуатации, а также результаты сетевого тестирования, проведенного командой разработки МКОН можно найти на странице (https://owen.ru/product/mkon) продукта.
Очень дорого для такого простого конвертера ...ну не сравнить с ПР200..
Ну не очень, но несколько завышенная цена.
А с ПР200 нет смысла сравнивать - это совсем разные устройства.
Ну не очень, но несколько завышенная цена.
А с ПР200 нет смысла сравнивать - это совсем разные устройства.
Да я по комплектации сравниваю ,трудозатратам ..а вы наверное по популярности, с МОХА . В 1,5 -2 раза завышена цена .Это как с термометром...Плата UART- RS485 для пр200 стоит 650р (с гальванической развязкой) + порт езернет 1000р ...Есть куча аналогов и цена уже сформирована , мы же не за проволокой колючей..Тем более все уже в России продается дилерами от 2,5тр ...Лучше оборотом брать ,чем наценкой ,имхо .
Я сравниваю с новатеком.
Но только если сравнивать даже с любимым Вами USRIOT - надо сравнивать не с прямой поставкой и не через Али.
Я сравниваю с новатеком.
Но только если сравнивать даже с любимым Вами USRIOT - надо сравнивать не с прямой поставкой и не через Али.
Я же писал -"Тем более все уже в России продается дилерами от 2,5тр ".. наберите *.pro или ru , причем тут али... у меня ума хватает не предлагать али,которые работают с частниками... У меня на канале ютуб есть еще другие произодители аналогичных конвертеров. Лично я желаю компании ОВЕН только успехов ,потому и критикую за цену , от низкой цены выиграет пользователь и производитель ,при хорошем обьеме продаж ,чего и желаю ...
Ну и 5250.
Я и написал - завышена, но не на много.
Ну и 5250.
Я и написал - завышена, но не на много. если бы так, то и разговора бы не было..
Промышленная серия от 3750-16700 (кортекс м4) , экономичная серия от 2350-3100(кортекс м0) ...Об них знают все и давно используют ,а кто раньше встал ,того и тапки... Корпуса металлические
мда. тоже удивился с цены. Тем более что подобные устройства на самом деле не так уж и востребованы. Потому что достаточно обычного Ethernet - RS485 со стороны которого фиолетово на тип протокола....
не удивлюсь, что данное устройство больше костыль для ПЕ210 и подключения TCP устройств в сети к Облаку... печаль....
Вы про MODBUS over TCP?
Есть прозрачные ,а есть модбамTCP -RTU (K3,K7) конвертеры ,я же неделю назад делал видео ,зайдите на мой канал ютуб , там вообще за 1000р , но не о них речь
МОЕ ГЛУБОЕ УБЕЖДЕНИЕ - ЧЕМ КРУПНЕЕ ПРОИЗВОДИТЕЛЬ , ТЕМ МЕНЬШЕ У НЕГО ЦЕНА , ЧЕМ У ИП СОСЕДА.
Демпинг не приветствую, но если б мог(на месте Овен) забрал бы всех потребителей под свое крыло ...
Спациально разобрал один конвертер ,что бы показать ,что там не один чип ,но картинку вставить не смог
просто такие устройства востребованы только когда
1. устройство с RTU хотят подключить к сети, а Sсada умеет только Modbus (иногда только TCP) (и такое встречал. ну либо за деньги OPC сервера, при чем за большие деньги)
2. когда что то промазали, ПЛК с RS485 а куча удаленных модулей с Ethernet, ну либо просто на удаленке ставят Ethrnet - RS485 к модулям.
Вообще сталкивался с необходимостью похожего устройства. Но там был протокол SNMP на верхний уровень. Это вместо того, чтобы правильно выбирать Scada систему верхнего уровня....
Не совсем так.
Часто есть такие устройства с RTU, разбросанные по площадке и территории. И надо про бросить веревку по сети.
Вот только ровки приводит не законченные модули, а встраиваемые. Это некорректно.
Не совсем так.
Вот только ровки приводит не законченные модули, а встраиваемые. Это некорректно.
Вы что то путаете или намеренно передергиваете , где я говорил или делал ссылки на встраиваемые модули (и куда?) , aso???
Я приводил встраиваемые(к3\к7) только что бы вы поняли образование цены ...
ASo еще раз, если RS485 разбросан по территории и надо все связать в сеть не требуются ТАКИЕ шлюзы. Достаточно простых преобразователей Ethernhet - RS485.
Любых, любого производителя. и rovki как раз говорит, что готовые преобразователи с официальной покупкой в России в два раза дешевле и не нужны такие сложности и такая цена.
з.ы. свое мнение я высказал, что скорее всего Овен выпустил очередной костыль, в том числе для возможности завязывать со своими же костылями... разработка ради разработки.... ощущение, что там студенты какие-то работают....
если что, при очень длинных расстояниях есть готовые из оптики в RS485...
Считайте это моим бзиком, но я предпочитаю передавать протокол, а не делать удоинитель COM порта.
По поводу костыля - в принципе соглашусь. Если не брать типа рынок - возьмите все от одного производителя. Ну дофига на рынке таких шлюзов. По схожей, даже чуть дешёвой цене. А настройка через облако - это что-то с чем-то.
Настройку через браузер хорошо делать на веб странице ...
мелкий как всегда придумал проблему где её нет и все начали обсуждать овен по этому поводу, вместо того чтоб открыть документацию и посмотреть раздел 6.2 рисунки 6.2, 6.3, а так же раздел 7.1 про какое облако вообще речь? То что там есть возможность подцепить шлюз к облаку, так это теперь "повинность" всех устройств выпускаемых овен с ethernet на борту
Филоненко Владислав
07.03.2020, 17:45
ASo еще раз, если RS485 разбросан по территории и надо все связать в сеть не требуются ТАКИЕ шлюзы. Достаточно простых преобразователей Ethernhet - RS485.
Любых, любого производителя. и rovki как раз говорит, что готовые преобразователи с официальной покупкой в России в два раза дешевле и не нужны такие сложности и такая цена.
з.ы. свое мнение я высказал, что скорее всего Овен выпустил очередной костыль, в том числе для возможности завязывать со своими же костылями... разработка ради разработки.... ощущение, что там студенты какие-то работают....
если что, при очень длинных расстояниях есть готовые из оптики в RS485...
Как показали тесты, в режиме "удлинённый COM-порт" возникают различные "сторонние эффекты". И сторона-хозяин (мастер) такого порта должна их учитывать.
Если готовы тонко настраивать систему - можно использовать удлинитель. Если хочется простоты и надёжности - нужен специализированный шлюз, который понимает что находится за его стенками.
К тому же это уже не удлинитель и тупой преобразователь Ethernet-RS, а интеллектуальное устройство, может и адрес подменить, и протокол сконвертировать по адресу или источнику.
Добавим сюда еще функцию шлюз USB<->RS и USB<->Ethernet
И поддержку тучки.
Филоненко Владислав
07.03.2020, 17:50
Считайте это моим бзиком, но я предпочитаю передавать протокол, а не делать удоинитель COM порта.
По поводу костыля - в принципе соглашусь. Если не брать типа рынок - возьмите все от одного производителя. Ну дофига на рынке таких шлюзов. По схожей, даже чуть дешёвой цене. А настройка через облако - это что-то с чем-то.
Облако - лишь один из путей, можно использовать все другие интерфейсы (USB,RS,Ethernet локально)
Блинннн, я задал прямой вопрос.
Есть дофига подобных шлюзов. Если не брать неприлично дорогих, типа М. , то более дешёвых от ICP, USRIOT да и российского Н - давно уже есть. Смысл выпуска ещё одного? При заведомо проигрышной цене.
Ну и так, очевидное предложение, может даже я его уже делал. Сделайте закрытый раздел форума, в котором не будут действовать ряд ограничений. И доступ туда - сотрудникам и десятку из местной тусовки. Чтобы не обсуждать здоровым языком.
Филоненко Владислав
07.03.2020, 20:39
Ну к примеру это промрешение? А не настольный преобразователь с сомнительной устойчивостью к ЭМС? Большую часть автоматизации можно сделать на китайских платах с Али. Очень дёшево. Но никто так не делает. Почему?
Филоненко Владислав
07.03.2020, 20:52
Блинннн, я задал прямой вопрос.
Есть дофига подобных шлюзов. Если не брать неприлично дорогих, типа М. , то более дешёвых от ICP, USRIOT да и российского Н - давно уже есть. Смысл выпуска ещё одного? При заведомо проигрышной цене.
Ну и так, очевидное предложение, может даже я его уже делал. Сделайте закрытый раздел форума, в котором не будут действовать ряд ограничений. И доступ туда - сотрудникам и десятку из местной тусовки. Чтобы не обсуждать здоровым языком.
ICP - самое дешевое с изоляцией 110 у.е. -25. Сколько будет стоить на -40? Неизвестно, не производят. Даже промсерия за 200+ у.е. -25
USRIOT - тоже -25, но хоть цена привлекательнее. Металлический корпус - это не значит промрешение
Moxa и Advantech на -40 - цены вызывают охренение.
manjey73
07.03.2020, 21:29
в пластиковом корпусе устойчивость к ЭМС выше ?
Филоненко Владислав
07.03.2020, 21:35
в пластиковом корпусе устойчивость к ЭМС выше ?
Устойчивость к ЭМС типом корпуса не определяется. Это миф.
Мет. корпус при правильной схемотехнике может ослабить радиоволновое излучение, но я пока не видел промустройства, сбоившего бы при гостовских помехах по радиоизлучению.
Основные источники сбоев кондуктивка, пробой статикой в порты и наноимпульсы. А им на корпус плевать
Устойчивость к ЭМС типом корпуса не определяется. Это миф.
Мет. корпус при правильной схемотехнике может ослабить радиоволновое излучение, но я пока не видел промустройства, сбоившего бы при гостовских помехах по радиоизлучению.
Основные источники сбоев кондуктивка, пробой статикой в порты и наноимпульсы. А им на корпус плевать
Тяжело слушать программиста (хорощего) по части электроники ....Тот USR , что в пластике(DR302) ,который у меня в видео работает -40+85 ... и те что в металле работают от-45 ....все имеют Certifications CE , FC, RoHS , экспортруются в десятки стран мира ... дистрибьюторы США Австралия Бразилия Польша Испания Россия Германия Израиль Тайвань Словакия Италия Индия Таиланд Венгрия Новая Зеландия индия.. Так что делите цену на 2 и все потянуться к вам ....а мы поможем . К слову ,модули езернет от usr поддерживаются kascada cloud , элементарно все настраивается на веб странице .
Филоненко Владислав
08.03.2020, 09:52
Маркировка CE ( «европейское соответствие») — специальный знак, наносимый на изделие, который удостоверяет, что изделие соответствует основным требованиям директив ЕС и гармонизированным стандартам Европейского союза, а также то, что продукт прошёл процедуру оценки соответствия директивам. Маркировка CE указывает на то, что изделие не является вредным (опасным) для здоровья его потребителей, а также безвредно для окружающей среды.
FC - это пожарка
RoHS (англ. Restriction of Hazardous Substances) — директива, ограничивающая содержание вредных веществ, была принята Европейским союзом в феврале 2003 года[1]. Директива вступила в силу 1 июля 2006 года. Каждое государство-член Европейского Союза будет применять свои собственные правила обеспечения соблюдения и осуществления, используя эту директиву в качестве руководства.
RoHS часто упоминается как «директива без свинца», но ограничивает использование следующих десяти веществ:
Так что утилизировать, жарить и глотать можно, но к промавтоматике никакого отношения...
То, что некий экземпляр удачно запустился при -40 (при заявленных -25) ну вообще ни о чем.
-40 на улице не значит что внутри прибора было -40. Это же не значит что он запиустится через 2 года при -40.
И, что характерно, обычно приборы на -40 тестируют при -55. Чтоб запас был.
P.S. отдел тестирования у нас находится в 20 метрах от моего раб места. И все приборы там пытают при разработке. Так что волей-неволей понимать что и как с ЭМС, температурными диапазонами и пр. приходится :)
Давайте говорить здраво - скольким % изделий реально требуется холодный пуск при -40 ? По моим оценкам - не более 1%
Маркировка CE ( «европейское соответствие») — специальный знак, наносимый на изделие, который удостоверяет, что изделие соответствует основным требованиям директив ЕС и гармонизированным стандартам Европейского союза, а также то, что продукт прошёл процедуру оценки соответствия директивам. Маркировка CE указывает на то, что изделие не является вредным (опасным) для здоровья его потребителей, а также безвредно для окружающей среды.
FC - это пожарка
RoHS (англ. Restriction of Hazardous Substances) — директива, ограничивающая содержание вредных веществ, была принята Европейским союзом в феврале 2003 года[1]. Директива вступила в силу 1 июля 2006 года. Каждое государство-член Европейского Союза будет применять свои собственные правила обеспечения соблюдения и осуществления, используя эту директиву в качестве руководства.
RoHS часто упоминается как «директива без свинца», но ограничивает использование следующих десяти веществ:
Так что утилизировать, жарить и глотать можно, но к промавтоматике никакого отношения...
То, что некий экземпляр удачно запустился при -40 (при заявленных -25) ну вообще ни о чем.
-40 на улице не значит что внутри прибора было -40. Это же не значит что он запиустится через 2 года при -40.
И, что характерно, обычно приборы на -40 тестируют при -55. Чтоб запас был.
P.S. отдел тестирования у нас находится в 20 метрах от моего раб места. И все приборы там пытают при разработке. Так что волей-неволей понимать что и как с ЭМС, температурными диапазонами и пр. приходится :)
У них всякие есть и -25 и -40 ...пол мира обеспечивают в области пром автоматизации ...И у наших пользователей работают уже не один год ...Немного опоздали ,лет на 5 минимум ...Они содрали свои супер порты с американских и сейчас после судебных исков сделали собственный конструктив К7,К6 на cortex M4(M0).
Давайте говорить здраво - скольким % изделий реально требуется холодный пуск при -40 ? По моим оценкам - не более 1%
И сколько % продукции Овен работают от -40? Они ,что не стали пром оборудованием ,которые не -40 ?
Филоненко Владислав
08.03.2020, 10:25
%регулярно растет. И насколько мне известно, можно заказать даже если нет позиций в общем прайсе.
А вообще у нас очень холодная, зимой, страна. Это не китай и не таиланд...
И по ЭСМ у нас все хорошо, сертифицированно.
Вернемся к нашим баранам - ну так есть на рынке дешёвые промрешения по шлюзам?
Филоненко Владислав
08.03.2020, 10:26
У них всякие есть и -25 и -40 ...пол мира обеспечивают в области пром автоматизации ...И у наших пользователей работают уже не один год ...Немного опоздали ,лет на 5 минимум ...Они содрали свои супер порты с американских и сейчас после судебных исков сделали собственный конструктив К7,К6 на cortex M4(M0).
Ссылки где, где ссылки. -40 я не нашел.
Ссылки где, где ссылки. -40 я не нашел.
Так вроде нельзя ,но пусть модераторы удалят - [ссылки удалены]
Филоненко Владислав
08.03.2020, 11:53
[ссылки удалены]
[удалено] - соответствие EN 55035 - Мультимедиа оборудование, условия гораздо мягче
[удалено] - от минус 35до +55, про ЭМС вообще не слова не нашёл. Да и функционал ограничен.
Приборы на рынке вряд ли совсем уж неустойчивые к ЭМС. Но почему же тогда сертификация либо отсутствует, либо ведется по мягким стандартам?
Потому, что это мало кому надо. Работает оборудование не по сертификату, а по факту. Сертификация стОит денег. Ну и сертификатам в РФ никто не верит - есть причины.
manjey73
08.03.2020, 13:01
МКОНу не хватает поддержки протокола Овен со стороны RS485 ессно. Тогда и ценник адекватный и необходимость есть, судя по многочисленным вопросам на форуме про старые ТРМ и так далее. И возможность все эти приборы загнать в облако или в Modbus TCP...
Филоненко Владислав
08.03.2020, 14:25
Потому, что это мало кому надо. Работает оборудование не по сертификату, а по факту. Сертификация стОит денег. Ну и сертификатам в РФ никто не верит - есть причины.
И зачем у нас центр тестирования на фирме. Он же не нужен :)
Филоненко Владислав
08.03.2020, 14:26
МКОНу не хватает поддержки протокола Овен со стороны RS485 ессно. Тогда и ценник адекватный и необходимость есть, судя по многочисленным вопросам на форуме про старые ТРМ и так далее. И возможность все эти приборы загнать в облако или в Modbus TCP...
Технически нет препятствий. Будет запрос массовый - сделаем.
Вот Вы и ответили на 2 последних своих поста.
manjey73
08.03.2020, 15:41
Технически нет препятствий. Будет запрос массовый - сделаем.
а то вы форум не читаете, вопросы по подключению в облако приборов с Овен протоколом всплывают постоянно. Единственный ответ, который я вижу в ответах представителей фирмы - "Замените прибор"
поправка, не обязательно в облако, а в любую систему, в которой только Modbus есть.
Это задача не для данного шлюза.
Не сделали потому, что экономически не выгодный костыль.
В любую систему с модбас - а зачем?
manjey73
08.03.2020, 15:49
ASo просто так, чтобы именно этим выделялся. :) тогда и вопрос конкурентно способности бы не поднимался.
на самом деле много систем, где теги на Modbus оплачены и есть куча свободных, а чтобы подключить приборы с другим протоколом требуется купить лицензии на использование тегов от OPC и ценники бывает зашкаливают...
Scada системы они такие разные. Иногда диву даешься, хватило же ума купить.....
Посмотрел картинку ПР200 - шлюз МКОН - модули ввода вывода Ethernet. С учетом ограничения памяти ПР есть смысл строить подобную систему изначально ?
Филоненко Владислав
08.03.2020, 18:18
ASo просто так, чтобы именно этим выделялся. :) тогда и вопрос конкурентно способности бы не поднимался.
на самом деле много систем, где теги на Modbus оплачены и есть куча свободных, а чтобы подключить приборы с другим протоколом требуется купить лицензии на использование тегов от OPC и ценники бывает зашкаливают...
Scada системы они такие разные. Иногда диву даешься, хватило же ума купить.....
Посмотрел картинку ПР200 - шлюз МКОН - модули ввода вывода Ethernet. С учетом ограничения памяти ПР есть смысл строить подобную систему изначально ?
На такую схему как раз было много заказов. Как и наоборот. Как не странно на первый взгляд.
А на ОВЕН в облако/сеть ModBus хотят шлюз отдельные суперэкономные энтузиасты. Т.к. все современные приборы фирмы давно могут ModBus.
Ради 50 клиентов городить кучу ПО просто невыгодно.
manjey73
08.03.2020, 20:14
Вам ради 50 клиентов нет, а клиентам менять кучу старых, продолжающих работать приборов это деньги, часто не маленькие.
На самом деле очень странно от фирмы Овен не получить шлюз с возможностью использования протокола собственного изобретения. Именно это для меня странно.
И простите, какая куча ПО ? шлюз же настраиваемый, если я правильно понимаю. Если в нем мало памяти для организации 2-х протоколов со стороны RS485 то дело должно легко решаться прошивкой №1 и №2
На самом деле очень странно от фирмы Овен не получить шлюз с возможностью использования протокола собственного изобретения. Именно это для меня странно.
Это как раз нормально. Общемировая практика.
Филоненко Владислав
08.03.2020, 20:54
Вам ради 50 клиентов нет, а клиентам менять кучу старых, продолжающих работать приборов это деньги, часто не маленькие.
На самом деле очень странно от фирмы Овен не получить шлюз с возможностью использования протокола собственного изобретения. Именно это для меня странно.
И простите, какая куча ПО ? шлюз же настраиваемый, если я правильно понимаю. Если в нем мало памяти для организации 2-х протоколов со стороны RS485 то дело должно легко решаться прошивкой №1 и №2
С где-то 7 года уже все новые приборы шли с модбасом. Так что у клиентов могут еще сохранится рабочие трм ранних выпусков, но говорить о подключении приборов 10-ти и более летней давности к современным OPC? Если будут обновлять никто ради экономии 100р остаточной стоимости ТРМ не будет его оставлять. А без обновления как работала котельная так и работать будет. А в тучку она, если вдруг приспичит, просто попадет через семейство PE/PW210.
Ну а кому очень надо - есть ПЛК с возможностью сделать такой шлюз.
А куча ПО - это шлюз ModBus-Овен в самом приборе, плагины в тучке и конфигураторе для настройки и т.п. Вы же хотите протестированное ПО? Никогда не отобьётся.
Овен остался лишь как интерфейс настройки ряда устаревших приборов, зачастую скрыто от пользователя. И в новых разработках вообще не используется. Не влетел. Таких кастомных протоколов мильон.
У нас еще есть токовая петля. Тоже делать шлюз в Модбас?
manjey73
08.03.2020, 23:15
это называется поддержкой. а так то, шлюз любого протокола можно сделать на ПЛК или промПК, только там ценник не тот...
Ну так ответьте на вопрос - а раньше как с этим протоколом работали?
Филоненко Владислав
09.03.2020, 09:03
Что значит как? Шлюзов в линейке приборов у нас никогда не было. А оконечное устройство это не шлюз.
manjey73
09.03.2020, 09:34
Ну так ответьте на вопрос - а раньше как с этим протоколом работали?
слава богу у меня такого зоопарка приборов нет, но я еще и читаю форум, и вопросы как перешить тот или иной прибор, чтобы появилась поддержка Modbus тут всплывают часто. Значит у людей есть такая необходимость. Почему и удивился, что компания выпускает подобный шлюз без поддержки собственного протокола.
С учетом массы шлюзов подобного плана выпуск железки для кого ? Кому было нужно уже давно приобрели подобные устройства и используют, остается только либо новые системы либо старые, поддержки которых нет. Дальше вступает в расчет цена, возможности и т.д.
а чистокровное использование в новом проекте очень сомнительно, так как если система распределенная, то просто выбирается контроллер с Ethernet например и все. шлюз не нужен...
e.filatov
09.03.2020, 23:49
а чистокровное использование в новом проекте очень сомнительно, так как если система распределенная, то просто выбирается контроллер с Ethernet например и все. шлюз не нужен...
Есть шкаф, котельная, построенная на ТРМ-ках. Заказчик хочет собирать данные с кучи объектов на условном ОРС. Ставите в готовую систему МКОН - задача решена.
Да, вы правы. Заведомо строить гибрид RS-Eth не рационально.
manjey73
10.03.2020, 07:07
e.filatov вот отсюда и был вопрос - почему нет протокола овен ? - Есть шкаф, котельная, построенная на ТРМ-ках :) Каков был ответ представителя Овен ? - "замените ТРМ-ки" и "ради 50-ти клиентов мы этого делать не будем"
По многим причинам. Экономические уже объяснили. Есть технические - не однозначность протоколов.
Надо собрать - организуйте виртуальный порт, оборудования масса.
Вопрос только экономический по МКОН. По фото и общим соображениям ясно, что это ПЕ210 с иной прошивкой. А тогда почему так различаются цены? Ну не могли экономисты и руководство не исследовать рынок и конкурентов. Типа самый дешёвый на -40 и помехи класса А? Охотно поверю, ну пусть обнимаются с этими сертификатами. В 99% достаточно более дешёвых и проверенных конкурентов, оставшийся % можно оставить...
Или руководство ОВЕН знает и рассчитывает на что-то иное, типа гаСпрома, куда и нужны эти сертификаты?
Филоненко Владислав
10.03.2020, 08:56
e.filatov вот отсюда и был вопрос - почему нет протокола овен ? - Есть шкаф, котельная, построенная на ТРМ-ках :) Каков был ответ представителя Овен ? - "замените ТРМ-ки" и "ради 50-ти клиентов мы этого делать не будем"
В том то и дело, что менять не надо, с 2000-чи лохматого года в приборах есть ModBus. А ежели у Вас в котельной прибор без ModBus - он уже такой древний, что ему лучше в музей... Никто никогда не делает апгрейд систем 10-15-20 летней давности с сохранением электроники. Это могут делать отдельные энтузиасты дома и шарлатаны на промобъектах.
manjey73
10.03.2020, 10:17
Филоненко Владислав вы не поверите, я на заводах году в 2012-2013 видел древнейшие Омроны и другое оборудование, которым на то время было 20 а то и более лет. И никто их менять и абгрейдить не собирался. А наоборот стоял вопрос - втяните все данные с оборудования в нашу новую Scada (как вариант)...
Вот для этого и делается совместимость. Потому что масса таких объектов, которые работают (работает - не трогай), но данные люди видеть хотят на сегодняшний день.
ASo ну каким экономическим ? чем так уж принципиально отличается протокол Овен от того же Modbus ASCII ?
и тот и тот символьные, работают на RS485 линии. Другая прошивка или возможность настройки прибора, если память позволяет впихнуть и Modbus и Овен. Железяка то уже есть, только программная часть остается.
1. Вот именно поэтому шлюзы с таких устаревших систем стОят весьма больших денег. а)конечный продукт б)ограниченный рынок в)цена чуть ниже, чем замена оборудования.
2. Ну не понимаете в чем разница - значит не понимаете. Ничего не поделаешь.
manjey73
10.03.2020, 10:49
ASo я дружу со многими протоколами, по этому и не понимаю, когда железо полностью позволяет это реализовать. Это банальный вопрос репутации производителя - поддержка своих приборов, даже древних. такой маленький нюансик, который не только оправдает цену изделия, но и поставит его выше конкурентов.
manjey73
10.03.2020, 11:21
Так зависит как построена архитектура конвертера, если он как мастер читает одни параметры и складывает их в другие, не вижу никаких проблем.
Как раз один из подобных конвертеров Modbus TCP - Modbus RTU упоминался в теме, это [удалено]. Аналогичные шлюзы есть и у [удалено] и других производителей.
У большинства шлюзов подобного рода не прозрачное преобразование запросов. А судя по описанию МКОН, он и является не прозрачным. (могу конечно ошибаться). Как то покупать для проверки нет желания и отсутствует необходимость.
Вот как я должен расценивать данные слова ? "Master в сети RS-485 – Slave в сети Ethernet"
То есть устройство самостоятельно должно уметь опрашивать slave устройства в сети RS485. Иначе тогда это не шлюз, а просто преобразователь интерфейсов.
Так зависит как построена архитектура конвертера, если он как мастер читает одни параметры и складывает их в другие, не вижу никаких проблем.
Как раз один из подобных конвертеров Modbus TCP - Modbus RTU упоминался в теме, это usriot 511. Аналогичные шлюзы есть и у adfweb и других производителей.
У большинства шлюзов подобного рода не прозрачное преобразование запросов. А судя по описанию МКОН, он и является не прозрачным. (могу конечно ошибаться). Как то покупать для проверки нет желания и отсутствует необходимость.
с рту в тср проблем нет, зачем его приводить в пример если и так реализовано, несколько байт добавить/удалить, расчет контрольной суммы можно и аппаратно сделать, а остальное идентично. А эти Ваши общие фразы:"Так зависит как построена архитектура конвертера, если он как мастер читает одни параметры и складывает их в другие, не вижу никаких проблем" ни о чем, невидите вот и расскажите, я же про это и спросил
manjey73
10.03.2020, 11:31
Прочитал документацию. Прости господи, кто ЭТО назвал "Шлюзом" ? лично у меня язык не поворачивается..... некий гибрид. аминь ему....
capzap, шлюз (именно шлюз) самостоятельно работает со slave устройствами, по отношению к которым он является мастером.
В результате в шлюзе две карты регистров (переменных) и связь между двумя картами.
Например шлюз читает данные с RTU устройств (или вообще с RS485 устройств, протоколы которых поддерживаются шлюзом) и складывает в карту регистров Modbus TCP (еси мы рассматриваем вариант этого протокола). Устройство, либо Scada система ни сном ни духом не знает, какой протокол ЗА шлюзом, с которым он работает. Именно так работают все шлюзы. Иной работы я ни разу не видел. Вот только теперь в лице МКОН увидел, судя по документации на него.....
e.filatov
10.03.2020, 11:35
Прости господи, кто ЭТО назвал "Шлюзом" ?
Самому интересно. В шапке темы совсем другое функциональное назначение.
manjey73
10.03.2020, 11:43
e.filatov ну, теперь по крайней мере, все стало на свои места. осталось только его продавать массово... :)
capzap, шлюз (именно шлюз)
а зачем Вы тогда usriot 511 упомянули если он (Protocol Conversion) согласно документации, ах да Вы же читаете в последний момент
Филоненко Владислав
10.03.2020, 12:42
Филоненко Владислав вы не поверите, я на заводах году в 2012-2013 видел древнейшие Омроны и другое оборудование, которым на то время было 20 а то и более лет. И никто их менять и абгрейдить не собирался. А наоборот стоял вопрос - втяните все данные с оборудования в нашу новую Scada (как вариант)...
Вот для этого и делается совместимость. Потому что масса таких объектов, которые работают (работает - не трогай), но данные люди видеть хотят на сегодняшний день.
ASo ну каким экономическим ? чем так уж принципиально отличается протокол Овен от того же Modbus ASCII ?
и тот и тот символьные, работают на RS485 линии. Другая прошивка или возможность настройки прибора, если память позволяет впихнуть и Modbus и Овен. Железяка то уже есть, только программная часть остается.
ПЛК100 и 2 дня работы - вот шлюз к кастомной системе и готов. Рынок милипузенький
Филоненко Владислав
10.03.2020, 12:46
Так зависит как построена архитектура конвертера, если он как мастер читает одни параметры и складывает их в другие, не вижу никаких проблем.
Как раз один из подобных конвертеров Modbus TCP - Modbus RTU упоминался в теме, это usriot 511. Аналогичные шлюзы есть и у adfweb и других производителей.
У большинства шлюзов подобного рода не прозрачное преобразование запросов. А судя по описанию МКОН, он и является не прозрачным. (могу конечно ошибаться). Как то покупать для проверки нет желания и отсутствует необходимость.
Вот как я должен расценивать данные слова ? "Master в сети RS-485 – Slave в сети Ethernet"
То есть устройство самостоятельно должно уметь опрашивать slave устройства в сети RS485. Иначе тогда это не шлюз, а просто преобразователь интерфейсов.
Режим сборщика (Coupler) это не совсем шлюз. С одной стороны это удобно, с другой если число регистров в памяти сборщика не хватает на все - упс. И кодировать тысячи регистров тоже очень неудобно.
Не забываем что порядок опроса !=const. А сборщик тупо опрашивает по очереди.
МКОН работает именно как шлюз - переправляет запросы, а не сам опрашивает. И при этом он может иметь много одновременных запросов по TCP.
manjey73
10.03.2020, 12:49
Филоненко Владислав он работает как преобразователь, а не как шлюз. Хотя возможно разные люди вкладывают в это понятие разные значения. Вам виднее.
Если складывает в очередь запросы, то да, может иметь несколько одновременных запросов. Легко проверяется подключением и запросами из двух мест на разные слейв устройства в один момент времени. Проверяли ?
Филоненко Владислав
10.03.2020, 13:09
Филоненко Владислав он работает как преобразователь, а не как шлюз. Хотя возможно разные люди вкладывают в это понятие разные значения. Вам виднее.
Если складывает в очередь запросы, то да, может иметь несколько одновременных запросов. Легко проверяется подключением и запросами из двух мест на разные слейв устройства в один момент времени. Проверяли ?
Вы таки почитайте документацию. Там и протокол тестирования есть :D А в нем и такой режим
manjey73
10.03.2020, 13:28
Филоненко Владислав уточните в каком именно документе указан протокол тестирования ? читаю re_mkon_1-ru
Трофимов Артем
10.03.2020, 13:31
47818
отчёт о тестировании (https://owen.ru/uploads/205/otchet_o_testirovanii_setevyh_interfejsov.pdf)
manjey73
10.03.2020, 13:44
а, вы про двух мастеров в сети.... Сколько ошибок чтения возникло на каждом ОРС хотя бы за сутки ? Просто интересно. Ни разу не было совпадения времени ?
Филоненко Владислав
10.03.2020, 14:44
0 ошибок. Естественно внутри очередь запросов, совпадения пофиг.
Вот еще аналог [ссылка удалена]
Вот еще аналог [ссылка удалена]
какой же это аналог, если на одной стороне придется самому расчленять пакет ethernet чтоб прочитать что пришло от рту
manjey73
10.03.2020, 21:35
rovki там же написано, что это Modbus RTU over Ethernhet, обычный простой преобразователь интерфейсов. Я даже в сомнении, что там именно Modbus а не просто RS485.
В данном случае устройство из темы это прозрачное преобразование из Modbus TCP в RTU + орагнизация очереди (всего два соединения, но все же с очередью)
На простых преобразователях добиться работы из двух мест с RTU устройством можно только путем разнесения во времени с синхронизацией времени мастеров.
Да это прозрачный шлюз ,по аналогии с usr k2 ... Яж больше для того привел ,что бы показать стоимость , а добавить (программный)конвертер тср- рту это дело второе ...на стоимость не сильно должен влиять ,у usr это разница 500р.
Да это прозрачный шлюз ,по аналогии с usr k2 ... Яж больше для того привел ,что бы показать стоимость , а добавить (программный)конвертер тср- рту это дело второе ...на стоимость не сильно должен влиять ,у usr это разница 500р.
а Вы зацените цены у других производителей, которые пытаются конвертировать реально различные протоколы, там ценник будет в районе 600 не наших рублей, потому что программно, в этом плане совет про плк100 за 13 килорублей будет очень хорош для бюджетников
Хочу отметить пару моментов:
1. На странице продукта нет ссылки на конфигуратор - надо искать по сайту.
2. Хотел полазать по настройкам прибора в конфигураторе - без физического прибора это невозможно.
а Вы зацените цены у других производителей, которые пытаются конвертировать реально различные протоколы, там ценник будет в районе 600 не наших рублей, потому что программно, в этом плане совет про плк100 за 13 килорублей будет очень хорош для бюджетников
Давно уже заценил про конвертеры тср-рту (именно о них речь) , а другие пока не интересны . Если и дорогие ,так это потому что нет конкуренции или малые обьемы продаж ,при значительных затратах. Если использовать МК cortex ,то все прошивки уже есть на сайте производителя ,в том числе конвертеров и они открытые ...меняй свой веб дизайн страницы настроек и вуаля ...Китайцы так и сделали ,но америкосы их засудили за конструктив , после чего китайцы его переделали и продолжили выпуск супер портов ...
Филоненко Владислав
11.03.2020, 21:40
На сложных, тов. Валенок, производитель позаботился о обработке одновременных запросов.
manjey73
11.03.2020, 23:08
Валенок а чего в них верить, я их проверял двумя Scada системами на ПР200. в качестве преобразователя использовал Raspberry и запущенный TCP сервер COM порта. Когда двое пытаются прочитать ПР с ума сходит.
Вы тоже верите в существование одновременных запросов ?
Что Вы называете одновременными запросами? С учётом сильно разных скоростей веревок.
Филоненко Владислав
12.03.2020, 09:04
Что Вы называете одновременными запросами? С учётом сильно разных скоростей веревок.
Возвращаясь от суконных изделий к овчине - МКОН создан и тестировался на опрос по 1 линии 485 при запросах от 2-х мастеров по TCP. При этом устройство на 485 тоже не сходит с ума, т.к. можно выставить таймауты между запросами по 485.
manjey73
12.03.2020, 09:13
Валенок ну ни в remserial ни в socat нет защелок или очередей, это тупые TCP сервера на порт, что пришло, то и ушло. И как не пытайся настраивать без синхронизации времени между двумя мастерами всегда происходят совпадения времени в течении суток.
Другой вопрос, что я могу настроить опрос через каждые 5 секунд между мастерами и ошибок не будет.
Простых преобразователей с очередью я не встречал. Так что Овеновский будет первым.
Одновременный запрос к одному RTU устройству двумя мастерами.
Филоненко Владислав
12.03.2020, 09:36
А кто же предъявляет ? Устройство (по описанию) - прозрачный проталкиватель данных.
Не совсем понятно назначение t-задержки (Рисунок A.1). Это какое дополнительное время ?
В ходе тестов опроса с 2-х мастеров как раз и было выяснено, что некоторые устройства на 485 шине очень не любят когда к ним приходят запросы сразу после ответов.
Более того, некоторые сходят с ума даже от прихода запроса к другому устройству сразу после ответа от 3-го.
Поэтому была введена доп. настройка паузы между 2 запросами в сети 485.
В ОПС такие паузы есть по умолчанию.
Филоненко Владислав
12.03.2020, 10:50
Данный факт предъявлялся несколько лет назад на форуме. Не снизошли. Искать не буду.
И да, не для этой темы. В техподдержке про тоже для МО2 - полтора месяца. И support, и owengtp. А в ответ ....
Но тумблер - хорош ))
Это - позитив. Они - начались. Но не ответили - это дополнительное время ?
Это пауза между приходом ответа и выдачей нового запроса в 485 сеть.
P.S. Что-то тем про проблемы с 485 из-за частого опроса не встречал. Обычно в сети 485 1 мастер и паузы естественным образом возникают, т.к. темп опроса выставляется в разумных пределах.
manjey73
12.03.2020, 10:56
Валенок с чего бы не мастера ? есть два способа заставить двух мастеров и более опрашивать одно устройство с последовательным интерфейсом
1. синхронизация времени. каждая из Scada у меня опрашивала с периодом 10 сек. одна в 0-10-20-30-40-50-0, вторая 5-15-25-35-45-55-5
2. передачей управления после опроса от одного к другому по очереди (маркерные протоколы есть у некоторых производителей приборов)..
ну и промежуточным устройством с организацией очереди.
з.ы. у меня вот OPC сервера не хотят двоим отдавать данные в домене пользователю, кто первый встал, того и тапки. Что Овен OPC что Инсат. надо поднять машину без доменного пользователя и попробовать, все руки не доходят...
Валенок с чего бы не мастера ? есть два способа заставить двух мастеров и более опрашивать одно устройство с последовательным интерфейсом
1. синхронизация времени. каждая из Scada у меня опрашивала с периодом 10 сек. одна в 0-10-20-30-40-50-0, вторая 5-15-25-35-45-55-5
2. передачей управления после опроса от одного к другому по очереди (маркерные протоколы есть у некоторых производителей приборов)..
ну и промежуточным устройством с организацией очереди.
з.ы. у меня вот OPC сервера не хотят двоим отдавать данные в домене пользователю, кто первый встал, того и тапки. Что Овен OPC что Инсат. надо поднять машину без доменного пользователя и попробовать, все руки не доходят...
хватит уже продолжать путать всех в стиле мелкого, так скады на прямую обращаются к устройствам или это делают ОРС сервера
manjey73
12.03.2020, 11:16
Scada напрямую.
Про OPC просто пожаловался :) Овен так ничего и не ответил по данному поводу, почему так происходит. Потом и на Инсатовском на то же нарвался...
На что нарвались?
https://owen.ru/forum/showthread.php?t=21739&p=249595&viewfull=1#post249595
manjey73
12.03.2020, 14:10
ASo угу, capzap правильную ссылку дал. Проблема с доступом к OPC (оказывается не только к единственному) если пользователь на ПК доменный (и в локальных никак не светится от слова вааще)
Валенок ну мастер в один момент времени всегда ОДИН для устройств с последовательным интерфейсом. если вам так будет легче, то правильнее писать "два мастера" с кучкой но и т.д.
A.Simonov
12.03.2020, 14:28
А кто же предъявляет ? Устройство (по описанию) - прозрачный проталкиватель данных.
Мне вот не совсем понятно назначение t-задержки (Рисунок A.1). Это какое дополнительное время ?
Я так понимаю речь о рисунке 2.1
Смысл задержки состоит в том, чтобы в сети RS485 были увеличенные паузы, между пакетами с данными.
Это актуально для тех устройств, которые "офигивают" если их слишком быстро опрашивать.
На ранних этапах тестирования иногда происходили ошибки, когда мы стали разбираться в чем дело, то выяснили, что на slave (в сети rs485) прилетал запрос на чтение сразу после того как он ответил на предыдущий запрос, не выжидая никакого времени. От чего некоторые устройства не отвечали на запрос. Обычно это решается соответствующей настройкой на OPC сервере (задержка запроса после получения ответа), но OPC общается с МКОН по TCP и том, что нужно сделать паузу на стороне RS485 МКОН ничего не знает. Если в МКОНе по каким-то причинам скопилась очередь, например, два мастера пытаются опросить что-то, то МКОН мог засыпать slave устройства запросами, от чего они выпадали в ошибку. Поэтому и была введена эта задержка, чтобы пакеты не слипались. В сущности, с этой же целью эта настройка есть и в OPC серверах.
Филоненко Владислав
12.03.2020, 19:38
А мы про модбас-rtu говорим ?
MO2. Техподдержка в 20 метрах (сами сказали п#28)
1. про него
2. не слышал
Филоненко Владислав
13.03.2020, 08:43
Добавим инфографики по тонким режимам настройки шлюза
(USB->TCP), каскадный шлюз, преобразование адресов slave, проброс групповых запросов и т.д.
47856
Филоненко Владислав
13.03.2020, 18:41
Видимо мастер работал не по модбас-rtu.
А слейвы наивные думали что с ними по модбас-rtu говорят. Логично что не отвечали
Валенок, слышал звон - думаю что он? Типичный таймаут между запросами был от 4 до 6 мс, чтобы не сходили с ума. На 115200. Освежите знания о таймаутах RTU
A.Simonov
16.03.2020, 13:09
Освежил. От 1.75мс для 115200 (Единиц тактирования времени в МКОН не знаю)
Освежаю вопрос - то t это дополнительное время ?
Ну и новый вопрос - "сходили с ума" - этот диагноз поставил приглашенный на тесты сетевого обмена психиатор ? Как-то сурово у вас там тесты проходят
Данная настройка есть и в OPC, причем не только нашей разработки, но там она у вас не вызывает вопросов. Почему?
47916 47917 47918
Филоненко Владислав
16.03.2020, 20:21
Валенок, Вы у нас привилегированный клиент. Ради Вас даже пресс-форму меняли. Выделенная квота на 4 линию техподдержки - непосредственно к разработчикам. Чего Вам то волноваться?!
Хочу уточниться по "железу".
Наличие гальванической изоляции.
Между чем и чем - питанием и интерфейсами, между интерфейсами или 3-х сторонняя между всем? В чем разница изоляции для моделей 24 и 220В (основная, дополнительная?)
Питание РоЕ не планируется?
Руководство п.5.4 рис.5.1 подтягивающие резисторы к 24В номиналом 120 Ом. Это опечатка про 24В и Fs=120 Ом ? М.б. 5В и несколько кОм? Эти все 3 резистора внутренние, или внутренние только Fs, а средний 120 внешний? Резисторы подключаются/отключаются конфигуратором, значит 24/5 В для "подтягивания" внутреннее?
Антон Новайкин
17.03.2020, 10:31
Хочу уточниться по "железу".
Наличие гальванической изоляции.
Между чем и чем - питанием и интерфейсами, между интерфейсами или 3-х сторонняя между всем? В чем разница изоляции для моделей 24 и 220В (основная, дополнительная?)
МКОН-24
Корпус+ДМЧ - 24В Дополнительная
24В - Ethernet Дополнительная
24В-RS485 Дополнительная
МКОН-230
Корпус+ДМЧ - 230В Усиленная
230В-Ethernet Усиленная
Ethernet - RS485 Усиленная
Руководство п.5.4 рис.5.1 подтягивающие резисторы к 24В номиналом 120 Ом. Это опечатка про 24В и Fs=120 Ом ? М.б. 5В и несколько кОм? Эти все 3 резистора внутренние, или внутренние только Fs, а средний 120 внешний? Резисторы подключаются/отключаются конфигуратором, значит 24/5 В для "подтягивания" внутреннее?
24В опечатка, должно быть 5В. Это внутреннее напряжение.
120 Ом - внешний, в комплекте его нет.
МКОН-24
Корпус+ДМЧ - 24В Дополнительная
24В - Ethernet Дополнительная
24В-RS485 Дополнительная
1. Что такое ДМЧ?
2. Ethernet - RS485 ?
3. Что такое "дополнительная" и чем она отличается от "усиленной"?
В руководстве для всех исполнений указано 2300В и для усиленной и для дополнительной. В чем разница, для чего то ведь указано усиленная-дополнительная. Или это тоже очепятка?
4. 2300В постоянного тока или 50Гц?
Извините, что пытаю Вас по, казалось бы, пустякам, но у меня в большей степени применения с силовым электрооборудованием и приводами, где это важно. Да и хотелось бы, чтобы параметры в документации были прописаны четко, определенно, не вызывая подобных вопросов.
e.filatov
17.03.2020, 14:12
ДМЧ - доступные металлические части
Ethernet - RS485 - 1500 Основная
2300В переменного тока 50 Гц
Тип изоляции указан в соотв. с ГОСТ 61131-2 для понимания пользователем требований. Величина реализована с запасом
e.filatov, Спасибо. Ваши сообщения (и не только в этой теме) весьма конструктивны и я очень рад, что Вы включились в диалог.
У меня есть планы на данную продукцию, я срочно хочу попробовать, поэтому мой интерес не праздный и применения именно промышленные, поэтому и хочется, чтобы и по технике и в руководстве было все прописано четко и определенно.
Итак:
1. ДМЧ - доступная (для прикосновения) металлическая часть? В нормативных документах это называется открытая проводящая часть (ОПЧ). В этом приборе есть такие ("Прибор выпускается в пластмассовом корпусе")? Если есть, то как они заземляются/или почему не заземляются? Класс защиты от поражения электрическим током не указан (или прошу прощения, если не увидел).
2. Ethernet - RS485 - 1500 Основная. = или 50Гц? В руководстве этой цифры и слова "основная" нет. Можно будет это ввести?
3. Для промышленной сети Ethernet предполагается использование экранированных кабелей и соединителей. Есть ли экран для RJ-45 в МКОН и с какой цепью он соединен?
4. Сеть RS485. Хорошо бы в руководстве поправить схему подключения, чтобы конкретно было понятно где "подтягивающие" и согласующие резисторы, что подтягивание осуществляется к изолированному от общего питания и Ethernet источника 5В, что надо/необязательно использовать GND, как-куда подключать экран?
Тогда и само изделие будет создавать впечатление "негаражного", и цена, возможно, будет себя оправдывать.
А где в РЭ сказано, что прибор поддерживает питание постоянным током 220В ?
А где в РЭ сказано, что прибор поддерживает питание постоянным током 220В ?
А где я писал про питание постоянным 220?
Что касается диэлектрической прочности изоляции, то проверку ее могут проводить как постоянным, так и переменным напряжением.
И не все то, что выдерживает постоянное напряжение, выдерживает и переменное.
e.filatov
18.03.2020, 11:42
Santi, пойдём по пунктам:
1. ДМЧ (определение 3.3 ГОСТ 61131-2) - корпус Ethernet коннектора. Класс защиты - 2. Прибор без клеммы заземления.
2. 1500В 50Гц. Стоит заметить, что к данной цепи относятся только контакты "витой пары", корпус коннектора относится к ДМЧ.
3. Экран есть, заведён отдельно (от других цепей) через через Y конденсатор на ноль входного питания (для 230В на нейтраль).
И ещё.... GND на клемме RS не предназначен для подключения экрана RS485 (на проводе 1200м из-за наводки можете спалить весь прибор) (можете расценивать данный контакт как "функциональная земля"). Использовать ТОЛЬКО для согласования уровня сигналов между приборами.
По поводу документации не ко мне.
Евгений Дударев
18.03.2020, 12:05
По поводу документации не ко мне.
Доработаем документацию, добавив расширенную информацию :)
Спасибо, e.filatov, Вы как всегда конструктивны и информативны.
1. За терминологию ДМЧ спасибо, был не в курсе. Кроме корпуса Ethernet коннектора, видимо еще и корпус USB ?
2. Понятно, спасибо.
3. "Экран есть..." это видимо корпус Ethernet коннектора. Y конденсатор - это 2 последовательно включенные между клеммами питания конденсаторы, а их средняя точка к экрану (корпусу Ethernet)? Если так, то потенциал относительно земли 110В, 50Гц (заземления ведь нет). Если просто конденсатор к клемме N, то какая из клемм питания N, маркировки ведь нет.
Экран 485 к этому прибору не подключается, потребитель подключает его сам (видимо на проводник РЕ/FE). Так?
Доработаем документацию, добавив расширенную информацию :)
Спасибо!
Может скажете у кого в РБ его можно быстро купить или взять на попробовать, наш ОВЕНовский поставщик в нынешней ситуации дал срок поставки 4 недели.
e.filatov
18.03.2020, 14:29
Спасибо, e.filatov, Вы как всегда конструктивны и информативны.
1. За терминологию ДМЧ спасибо, был не в курсе. Кроме корпуса Ethernet коннектора, видимо еще и корпус USB ?
2. Понятно, спасибо.
3. "Экран есть..." это видимо корпус Ethernet коннектора. Y конденсатор - это 2 последовательно включенные между клеммами питания конденсаторы, а их средняя точка к экрану (корпусу Ethernet)? Если так, то потенциал относительно земли 110В, 50Гц (заземления ведь нет). Если просто конденсатор к клемме N, то какая из клемм питания N, маркировки ведь нет.
Экран 485 к этому прибору не подключается, потребитель подключает его сам (видимо на проводник РЕ/FE). Так?
1. Да, тоже относится, однако изоляция меньше (350В), т.к. порт только для конфигурирования на столе, в работе не применяется.
3. Не совсем так. К сожалению не могу приложить схему (сами понимаете). Подключён через Y1-1000пФ-10% напрямую минусу входного электролита. Через него все потенциальные напряжения и помехи "сливаются" в питание. Стоит заметить, что это конденсатор повышенной надёжность с выдерживаемым напряжением до 2000В.
По поводу какая клема: 1 - N, 3 - L (считать справа налево).
По поводу RS - да, на других приборах экран подключаете в соотв с их РЭ, но только с одной стороны.
По п.3 непонятно, могу предположить по аналогии с блоками питания минус электролита выпрямленного 220В через Y-конденсатор к экрану. Но более пытать Вас не буду, если прибор появится попробую сам разобраться. А вот по поводу маркировки L - N, если это имеет значение, конечно на приборе необходима маркировка.
Ну и в руководстве конечно (к Дудареву )
e.filatov
18.03.2020, 15:21
По п.3 непонятно, могу предположить по аналогии с блоками питания минус электролита выпрямленного 220В через Y-конденсатор к экрану.
Если проще говорить, то да.
Попробовал прибор в режиме EthernetMaster. Собственно только этот режим мне и интересен. Результат пока плохой, прибор периодически виснет. Возможно конечно я что-то не так конфигурировал. В качестве Мастеров использовал 2 компа с ОРС-серверами (ОВЕНовским и ИНСАТ), слейв 1шт. - панель оператора с RS485. Связь работает некоторое время (рекорд 2 часа, обычно 4-6 минут), потом ошибки сплошняком и прибор не откликается по Ethernet даже на свой конфигуратор. Пинг проходит. Лечится откл-вкл питание МКОН, иногда связь восстанавливается сама, но время восстановления также непредсказуемо. Пробовал откл-вкл свой слейв, свич, ОРС-серверы - ничего не помогает, только сброс МКОНа. Я хотел было приложить конфигурации прибора и ОРС-серверов, но у меня нет прав на вложения. Может там какие некорректности, может кто бы поправил. Виснет и с одним мастером и с 2-мя, с 2-мя быстрее. Скорее всего проблема в МКОНе, так как шлюз другого производителя при той же конфигурации оборудования работает и даже при более частом опросе. Ошибки да, бывают, но не виснет как МКОН.
Еще раз - я не хочу хаять этот продукт, он мне интересен, хочу разобраться все ли я так делаю, но без передачи файлов конфигураций словами считаю обсуждать это бесцельно.
2 мастера по RS-485 - это как?
2 мастера по RS-485 - это как?
прибор в режиме EthernetMaster. 2 мастера со стороны Ethernet.
manjey73
30.03.2020, 08:32
Тот режим, про который тут талдычат уже несколько страниц, про задержки опроса на 485 что за сутки с двух мест ни одной ошибки и т.д.....
Антон Новайкин
30.03.2020, 12:42
Попробовал прибор в режиме EthernetMaster. Собственно только этот режим мне и интересен. Результат пока плохой, прибор периодически виснет. Возможно конечно я что-то не так конфигурировал. В качестве Мастеров использовал 2 компа с ОРС-серверами (ОВЕНовским и ИНСАТ), слейв 1шт. - панель оператора с RS485. Связь работает некоторое время (рекорд 2 часа, обычно 4-6 минут), потом ошибки сплошняком и прибор не откликается по Ethernet даже на свой конфигуратор. Пинг проходит. Лечится откл-вкл питание МКОН, иногда связь восстанавливается сама, но время восстановления также непредсказуемо. Пробовал откл-вкл свой слейв, свич, ОРС-серверы - ничего не помогает, только сброс МКОНа. Я хотел было приложить конфигурации прибора и ОРС-серверов, но у меня нет прав на вложения. Может там какие некорректности, может кто бы поправил. Виснет и с одним мастером и с 2-мя, с 2-мя быстрее. Скорее всего проблема в МКОНе, так как шлюз другого производителя при той же конфигурации оборудования работает и даже при более частом опросе. Ошибки да, бывают, но не виснет как МКОН.
Еще раз - я не хочу хаять этот продукт, он мне интересен, хочу разобраться все ли я так делаю, но без передачи файлов конфигураций словами считаю обсуждать это бесцельно.
МКОН с двумя ПК находятся в отдельной сети? или это сеть предприятия?
A.Simonov
30.03.2020, 13:06
Попробовал прибор в режиме EthernetMaster. Собственно только этот режим мне и интересен. Результат пока плохой, прибор периодически виснет. Возможно конечно я что-то не так конфигурировал. В качестве Мастеров использовал 2 компа с ОРС-серверами (ОВЕНовским и ИНСАТ), слейв 1шт. - панель оператора с RS485. Связь работает некоторое время (рекорд 2 часа, обычно 4-6 минут), потом ошибки сплошняком и прибор не откликается по Ethernet даже на свой конфигуратор. Пинг проходит. Лечится откл-вкл питание МКОН, иногда связь восстанавливается сама, но время восстановления также непредсказуемо. Пробовал откл-вкл свой слейв, свич, ОРС-серверы - ничего не помогает, только сброс МКОНа. Я хотел было приложить конфигурации прибора и ОРС-серверов, но у меня нет прав на вложения. Может там какие некорректности, может кто бы поправил. Виснет и с одним мастером и с 2-мя, с 2-мя быстрее. Скорее всего проблема в МКОНе, так как шлюз другого производителя при той же конфигурации оборудования работает и даже при более частом опросе. Ошибки да, бывают, но не виснет как МКОН.
Еще раз - я не хочу хаять этот продукт, он мне интересен, хочу разобраться все ли я так делаю, но без передачи файлов конфигураций словами считаю обсуждать это бесцельно.
Добрый день.
Отправьте вашу конфигурацию оборудования, схемы подключения, файлы настроек мне на почту
a.simonov@owen.ru
В отдельной сети. 2 компа, свич, МКОН. Да, возможно я недостаточно квалифицирован, чтобы понять про все эти задержки...
Непонятно мне и по конфигуратору (применительно к указанному режиму EthernetMaster) что такое:
1. Настройки шлюза/настройки режима /Режим порта RS485/мастер-слейв. Работает (и виснет потом) и при слейве и мастере.
2. Настройки порта RS-485/Идентификатор (1-255).
3. Почему в Настройки порта RS-485 нет параметра тайм-аута.
Вообще хотелось бы получить "живые" конфигурации МКОНа и ОРС-серверов, используемых в тестировании, при которых наблюдалась длительная, непрерывная работа. Попробовал бы, посмотрел где какие задержки...
Добрый день.
Отправьте вашу конфигурацию оборудования, схемы подключения, файлы настроек мне на почту
a.simonov@owen.ru
Спасибо, сегодня сброшу.
A.Simonov
30.03.2020, 14:15
В отдельной сети. 2 компа, свич, МКОН. Да, возможно я недостаточно квалифицирован, чтобы понять про все эти задержки...
Непонятно мне и по конфигуратору (применительно к указанному режиму EthernetMaster) что такое:
1. Настройки шлюза/настройки режима /Режим порта RS485/мастер-слейв. Работает (и виснет потом) и при слейве и мастере.
2. Настройки порта RS-485/Идентификатор (1-255).
3. Почему в Настройки порта RS-485 нет параметра тайм-аута.
Вообще хотелось бы получить "живые" конфигурации МКОНа и ОРС-серверов, используемых в тестировании, при которых наблюдалась длительная, непрерывная работа. Попробовал бы, посмотрел где какие задержки...
1) РЭ стр. 21 Раздел "Параметр «Режим порта RS-485»"
https://owen.ru/uploads/206/re_mkon_1-ru-53040-1.24_a4.pdf
Проще говоря, если Master опрашивает прибор через Ethernet, то и МКОН должен быть мастером в сети RS-485, по отношению к опрашиваемому прибору, и наоборот.
2) Настройки порта RS-485/Идентификатор (1-255)
Это собственный адрес прибора (МКОНа) по интерфейсу RS485, используется для доступа к настройкам по RS485. (если прописан соответствующий маршрут)
3) Почему в Настройки порта RS-485 нет параметра тайм-аута.
Потому что эта настройка есть у мастера, МКОН только передает через себя пакеты, зачем ему TimeOut?
Спасибо.
1. Ответ понятен, все правильно и логично. Вопрос - зачем при этом режиме в этом окне есть вариант "слейв"?
2. В режиме EthernetMaster порт RS-485 МКОНа тоже Мастер, как Вы логично ответили в п.1. Какой у Мастера м.б. идентификатор 1-255?
3. У других аналогов есть, может это как-то помогает не повесить сеть Ethernet и разделять события таймаутов от МКОН-слейв485 и таймаут EthernetMaster-МКОН. Я не великий специалист, но зачем-то другие делают.
4. Ну и по "Физ.слейв/Физ.мастер", не лучше ли бы это обозвать, как у большинства принято "Поляризация включена/отключена". Очень уж уникальное обозначение, хотя конечно в руководстве прописано...
A.Simonov
30.03.2020, 15:13
Спасибо.
1. Ответ понятен, все правильно и логично. Вопрос - зачем при этом режиме в этом окне есть вариант "слейв"?
2. В режиме EthernetMaster порт RS-485 МКОНа тоже Мастер, как Вы логично ответили в п.1. Какой у Мастера м.б. идентификатор 1-255?
3. У других аналогов есть, может это как-то помогает не повесить сеть Ethernet и разделять события таймаутов от МКОН-слейв485 и таймаут EthernetMaster-МКОН. Я не великий специалист, но зачем-то другие делают.
4. Ну и по "Физ.слейв/Физ.мастер", не лучше ли бы это обозвать, как у большинства принято "Поляризация включена/отключена". Очень уж уникальное обозначение, хотя конечно в руководстве прописано...
1. Данный параметр настраивать не нужно. Когда вы проводите настройку через плагин (кнопка настроить шлюз) в конфигураторе, данный параметр сам принимает необходимое значение.
Порядок настройки указан в РЭ.
Однако, если вы настраиваете прибор не через конфигуратор или вручную, то вы можете изменить параметр.
В частности его необходимо выставлять Slave в том случае, если Мастер находится в сети RS-485, это переводит интерфейс в режим ожидания команд от мастера.
2. Идентификатор имеет смысл в том случае когда интерфейс в режиме slave
3 и 4. Спасибо за обратную связь, если мы поймем, что это востребовано клиентами, то обязательно внедрим.
Филоненко Владислав
30.03.2020, 17:09
Попробовал прибор в режиме EthernetMaster. Собственно только этот режим мне и интересен. Результат пока плохой, прибор периодически виснет. Возможно конечно я что-то не так конфигурировал. В качестве Мастеров использовал 2 компа с ОРС-серверами (ОВЕНовским и ИНСАТ), слейв 1шт. - панель оператора с RS485. Связь работает некоторое время (рекорд 2 часа, обычно 4-6 минут), потом ошибки сплошняком и прибор не откликается по Ethernet даже на свой конфигуратор. Пинг проходит. Лечится откл-вкл питание МКОН, иногда связь восстанавливается сама, но время восстановления также непредсказуемо. Пробовал откл-вкл свой слейв, свич, ОРС-серверы - ничего не помогает, только сброс МКОНа. Я хотел было приложить конфигурации прибора и ОРС-серверов, но у меня нет прав на вложения. Может там какие некорректности, может кто бы поправил. Виснет и с одним мастером и с 2-мя, с 2-мя быстрее. Скорее всего проблема в МКОНе, так как шлюз другого производителя при той же конфигурации оборудования работает и даже при более частом опросе. Ошибки да, бывают, но не виснет как МКОН.
Еще раз - я не хочу хаять этот продукт, он мне интересен, хочу разобраться все ли я так делаю, но без передачи файлов конфигураций словами считаю обсуждать это бесцельно.
1. Если Вы используете 2 мастера Ethernet и они не разрывают соединение между посылками - то 3-е соединение по Ethernet с конфигуратором невозможно в принципе (их всего 2 одновременных в приборе). Но есть USB.
2. Лог сниффера помог бы определить причину.
1. А где в руководстве про ограничения в режиме EthernetMastera? Нашел только в п.7 стр.18 для Мастера 485 и то в мягкой форме, что вызывает задержки, но не обрыв связи. И там же, что максимально до 32 EthernetSlave. Пусть задержки, но не "висяк". И опять же это для Мастера485, режима мне совсем неинтересного.
Прошу уточнить, планируется ли выпуск данного преобразователя с двумя портами Ethernet (по аналогии с MOXA MGATE MB3170)?
Было бы ОЧЕНЬ хорошо, так как есть проблемы с совместной работой ОВЕН ПЛК110 и MOXA MGATE MB3170.
Евгений Дударев
31.03.2020, 11:08
Прошу уточнить, планируется ли выпуск данного преобразователя с двумя портами Ethernet (по аналогии с MOXA MGATE MB3170)?
Было бы ОЧЕНЬ хорошо, так как есть проблемы с совместной работой ОВЕН ПЛК110 и MOXA MGATE MB3170.
Добрый день, Данис. Что касается двух портов ethernet - думали и, скорее всего, линейка преобразователей протоколов будет развиваться в этом направлении.
Могли бы описать задачу, которую Вы решаете сейчас при помощи данного mgate?
Евгений Дударев
31.03.2020, 12:06
Коллеги, чтобы прояснить ситуацию хочу обратить ваше внимание, что в МКОН не планировалась поддержка работы 2-ух мастер-устройств в сети Ethernet. Мы её официально нигде не заявляли ( есть два сценария работы, которые описаны в РЭ). Однако ресурсов МКОН хватило на возможность тестирования его работы с двумя Ethernet мастерами, но мы честно написали о результатах данной работы в отчете по сетевому тестированию. Возможно в будущем, мы проведем оптимизацию и официально скажем о поддержке данной функции.
Филоненко Владислав
31.03.2020, 12:31
1. А где в руководстве про ограничения в режиме EthernetMastera? Нашел только в п.7 стр.18 для Мастера 485 и то в мягкой форме, что вызывает задержки, но не обрыв связи. И там же, что максимально до 32 EthernetSlave. Пусть задержки, но не "висяк". И опять же это для Мастера485, режима мне совсем неинтересного.
не путайте slave и master
не путайте slave и master
Не понял. Я просто хотел уточниться по ограничениям режима EthernetMaster, ничего не нашел и написал, что в руководстве прописаны только ограничения для режима 485 Мастер.
По EthernetMaster ограничений не увидел, в тестировании был вариант с 2-мя мастерами, поэтому решил, что это нормальный режим. Но по последним постам вижу, что это не так, буду ожидать указанных уточнений и пробовать сам. Вообще это конечно минус, на то он и ModBusTCP, чтобы иметь возможность работы с несколькими мастерами. Но что есть, то есть, буду учитывать. Рекомендации по своему вопросу я по почте получил, но попробую только завтра.
Попробовал, пока положительного результата нет.
Евгений Дударев
01.04.2020, 12:10
Попробовал, пока положительного результата нет.
Добрый день, написал Вам на почту. Как только получится попасть в офис (у нас карантин) и получить доступ к оборудованию - сразу же дадим результаты проведенного испытания у нас на стенде!
Какая очередь в пинг-понг протоколе?
manjey73
02.04.2020, 13:00
В теме выше было. Сам мкон создает очередь, а чтобы ошибок не было в сторону Ethernet мастеров (2-х, так как сокета всего 2) на каждом из них настройка timeout ответа в 2 раза выше, на случай что мкон в это время отвечает другому... очередь - всего лишь разделение времени на уровне железки по отношению к сети rs.
Кстати если на rs будет десяток устройств, каковы должны быть настройки двух OPC или Scada систем ?...
Филоненко Владислав
02.04.2020, 18:11
Валенок, ну вот не надо. И с запросами через 1 мс мы тоже тестировали. Не стали бы выкладывать не протестировав, продукты очень переживали и тестировали.
Явно дело не в бобине.
Ждем лог снифера
Филоненко Владислав
02.04.2020, 18:14
В теме выше было. Сам мкон создает очередь, а чтобы ошибок не было в сторону Ethernet мастеров (2-х, так как сокета всего 2) на каждом из них настройка timeout ответа в 2 раза выше, на случай что мкон в это время отвечает другому... очередь - всего лишь разделение времени на уровне железки по отношению к сети rs.
Кстати если на rs будет десяток устройств, каковы должны быть настройки двух OPC или Scada систем ?...
Никаких особенных, все равно устройства опрашиваются по 1 за раз.
Лишь таймаут надо ставить по самому тормознутому, если ОПС не позволяет индивидуально выставлять.
Опять же все равно надо считать поток данных, то, что 2 мастера могут по Ethernet напихать пакетов в МКОН не значит что он их сможет по RS все обработать за отведённое время. Толщина RS ограничена.
Конкретизирую вопрос.
Езернет слейв, RS мастер. Время ответа по RS - 5мс. Время тайм-аут, установленное в езернет мастере - 1мс и раз в 2мс он шлёт запросы. Как поведет себя МКОН в этом случае?
Я понимаю, что тот, кто выставил такое - ССЗБ. Но как поведет МКОН?
manjey73
02.04.2020, 19:34
Филоненко Владислав речь не об этом. Два OPC, выставили timeout Х, один опросил 1-но устройство на линии, дождался ответа и соответственно послал запрос 2-му устройству на RS и так далее. Тоже делает и 2-й OPC. очередь справляется в МКОН перемежающиеся данные то одному то другому ?
Сколько устройств на RS линии вы тестировали ? 2, 5, 31 ?
Два OPC, выставили timeout Х, один опросил 1-но устройство на линии, дождался ответа и соответственно послал запрос 2-му устройству на RS и так далее. Тоже делает и 2-й OPC. очередь справляется в МКОН перемежающиеся данные то одному то другому ?
не смущает ответ в вопросе: дождался ответа, значит пока опрос заканчивает сосед, можно отправить только один запрос и останется ждать ответа прежде чем следующий отправлять
ЗЫ это обычная работа, в каждом языке есть такие вещи как notifyAll и wait
manjey73
02.04.2020, 19:47
capzap есть маленький нюансик, по получению ответа timeout сбрасывается и тут же идет следующий запрос.
Хотя если в OPC том или ином мы все равно ждем окончания timeout тогда как бы да, может работать.
по получению ответа timeout сбрасывается и тут же идет следующий запрос..и что, а сосед разве ждет когда первый получит ответ и только тогда отправит свой запрос чтоб пободаться за "тапки". Оба живут своей жизнью и запросы отправляют когда им хочется. Поэтому получив ответ, даже если время опроса не настроено и очередной запрос отправляется сразу же, в мконе возможно уже обрабатывается запрос соседа и так же придется ждать ответа, в чем ньюанс то?
А с чего это только один ? Можно запулить несколько запросов не дожидаясь ответа. Транспорт - tcp. Ответы будут приходить в том же порядке. А где они выстроятся в очередь - это всего лишь вопрос "емкости труб и баков" на линии. Да, далеко не все модбас-серверы это поддерживают, но это не говорит о невозможности. Вопрос буквально нескольких строк.
Вам уже писали, что если так посылать, то через определенное время запросы в очереди "убьются"
Можно как-то конкретней ?стек фифо например
я не разработчик устройства, понятия не имею как реализовано, может вообще на уровне ТСР, пакеты не гоняются по сети бесконечно
Что же касается фифо, если ячейки закончились, то ни чего из приходящего не пишется, пока не вытолкнут первого в очереди
Мне рассказывали что в 0.2 0.7 почему-то не лезет. Но можно вылить на стол и можно сказать "хватит". Вот это и интересует - как там ?
К фифо это ну никак.
вся суть в том, чтобы кто то что то сказал, на борту должен быть говорящий. Чем тогда эта железка будет отличаться от плк100, только ценой и без среды разработки
Интересно на каком процессоре сделан ??? Меня как жестянщика интересует
e.filatov
03.04.2020, 11:21
Интересно на каком процессоре сделан ??? Меня как жестянщика интересует
STM32F107. Секретом не считаю, т.к. любой сейчас может вскрыть прибор и увидеть маркировку
Интересно на каком процессоре сделан ??? Меня как жестянщика интересует
Анатолий, на самом деле нету разницы на каком железе сделан девайс, там все делает софт, просто ST микроконтроллеры уверенно заняли нишу бюджетных решений, так как стоят дешевле аналогов.
Приветствую !!! Не согласен . Софт определяет функционал ,а возможности железо . А так бы до сих пор бы делали ПР на PIC18 ...Хотя все связано ,но тем неменее... Кортекс М0 и М4 все же отличаются ...Хотя и на тех и на других делают супер порты езернет-уарт
Приветствую !!! Не согласен . Софт определяет функционал ,а возможности железо . А так бы до сих пор бы делали ПР на PIC18 ...Хотя все связано ,но тем неменее... Кортекс М0 и М4 все же отличаются ...Хотя и на тех и на других делают супер порты езернет-уарт
Я имел в виду применения микроконтроллера с функционалом и возможностями, достаточными для решения поставленой задачи, но например других брендов.
Я имел в виду применения микроконтроллера с функционалом и возможностями, достаточными для решения поставленой задачи, но например других брендов.
Нам другие бренды пока не нужны
Нам другие бренды пока не нужны
Сам глаз на них положил, сейчас тестирую, но первые результаты не в их пользу, Атмел работает стабильней, сложилось впечатление, что st завышает характеристики, если поставить с запасом, то стабильность вроде- бы возрастает, но тогда не получается выгоды по цене, вот и думаю, продолжаю тестить, нужно подобрать для своего нового девайса оптимальный контроллер. Лет 15 работаю с Атмелом.
Филоненко Владислав
04.04.2020, 20:08
Конкретизирую вопрос.
Езернет слейв, RS мастер. Время ответа по RS - 5мс. Время тайм-аут, установленное в езернет мастере - 1мс и раз в 2мс он шлёт запросы. Как поведет себя МКОН в этом случае?
Я понимаю, что тот, кто выставил такое - ССЗБ. Но как поведет МКОН?
Что будет - в приемный сокет будут приходить пакеты каждые 2мс. А ответы уходить раз в 5 мс. Учитывая таймаут в мастере 1 мс уже первый ответ будет просроченный и мастер его откинет. С каждым новым запросом задержка будет расти и мастер будет принимать всё более и более старые ответы. В какой то момент либо мастер (если он умный), либо slave (по переполнению) пересоздаст соединение, но это не поможет, т.к. см. условия.
Филоненко Владислав
04.04.2020, 20:10
Филоненко Владислав речь не об этом. Два OPC, выставили timeout Х, один опросил 1-но устройство на линии, дождался ответа и соответственно послал запрос 2-му устройству на RS и так далее. Тоже делает и 2-й OPC. очередь справляется в МКОН перемежающиеся данные то одному то другому ?
Сколько устройств на RS линии вы тестировали ? 2, 5, 31 ?
31 устройство на линии 485 (как slave) + 2 ethernet мастера и 32 устройства ethernet (как slave) +1 RS мастер
Филоненко Владислав
04.04.2020, 20:13
В одну трубу вливается 500 запросов/сек (eth, 1000/2мс). Из другой выливается 200запрос/сек (rs, 1000/5мс).
Через секунду в мконе толпится 300 запросов.
Это не к Aso - это к Овену !!
Какая, блин, емкость мкона в усредненных запросах ? Какая память отведена под них ?
Что будет при исчерпании памяти ? Перезагрузка - это полная лажа.
Валенок. Модбас мастер не может отправлять следующий запрос не получив ответ или таймаут от предыдущего. Или это не ModBus Master, а собрание в дурдоме.
И если кто-то, видя что сокет продолжает принимать данные начинает его спамить запросами - сам себе злобный буратино, т.к. не выполняет спецификацию ModBus.
Причем и Modbus TCP, и Modbus в общем.
Филоненко Владислав
04.04.2020, 20:14
А с чего это только один ? Можно запулить несколько запросов не дожидаясь ответа. Транспорт - tcp. Ответы будут приходить в том же порядке. А где они выстроятся в очередь - это всего лишь вопрос "емкости труб и баков" на линии. Да, далеко не все модбас-серверы это поддерживают, но это не говорит о невозможности. Вопрос буквально нескольких строк.
Валенок, Вы альтернативно одарены. Так можно делать только в мире розовых пони!
Филоненко Владислав
05.04.2020, 12:54
Вы хотите сказать, гр. Валенок, что на ответственных объектах отклоняетесь от спецификации ModBus?
И заказчики в курсе этого пердимонокля?
P.S. очередь, это очередь запросов от РАЗНЫХ мастеров, коих в приборе может быть 4 шт., 2 ModbusTCP, USB и тучка.
Филоненко Владислав
05.04.2020, 17:25
Ну-ка ну-ка.
)) Это какая-то специальная очередь 8( ? Теперь если буду стоять в очереди в один на всех туалет, всегда буду уточнять - а вы в той же столовой ели ? Да ? Тады дуйте отседа, г-н Филоненко так сказал. Теперь я знаю что очереди очень важно - откуда в нее встал очередной хотелец.
Вместо троленья, Валенок, возьмите листик и нарисуйте как должен вести себя шлюз при приходе:
а) Большего числа запросов чем он может обработать по 485
б) нескольких подряд запросов от мастера (на которые шлюз не успел ответить)
P.S. таки в очередь в туалет все мастера стоят с 1 (ОДНИМ) запросом к шлюзу :D
e.filatov
06.04.2020, 00:52
Я уже сам запутался о чём речь? Очередь и в африке очередь. Modbus TCP имеет 2 вариации - Modbus TCP, где может существовать очередь запросов (по размеру вопрос к девайсу), средствами TCP, и Modbus RTU over TCP, где очереди не существует как таковой, т.к. подразумевается просто конвертирование Modbus RTU на пакеты TCP с логикой исходного RTU.
Мария Мильчакова
09.04.2020, 11:59
Уважаемые коллеги!
Убедительно прошу Вас высказываться по существу в этой теме. Для всего остального есть раздел "трёп" и личные сообщения.
Спасибо за понимание.
По делу сейчас распаковал МКОН подключил к ПЧВ3 (но это и не важно) настроил через конфигуратор мастер в Ethernet, slave в RS485. Само собой настройки порта. В итоге запускаю из OPC опрос в ответ приходят пакеты с кодом ошибки 83. При этом лампочка RS485 не моргает и попытка прослушать что на шине тоже говорит что МКОН ничего в шину 485 не отправляет. Этим же адаптером который для прослушки шины 485 отключив опрос через TCP в OPC меняю опрос напрямую и опрос идет. Я так понимаю что ковыряние в маршрутах мне не поможет? Хотя 1й маршрут странный (был по умолчанию) R1 7:0:10:40:0:10:R
P.S. Хорошо бы эту китайскую азбуку поподробней описать.
Эээээ.... Того. Этого....
Вам надо мастер в RS, слейв в Ethernet.
А так - правильно ничего в RS не посылает.
Эээээ.... Того. Этого....
Вам надо мастер в RS, слейв в Ethernet.
А так - правильно ничего в RS не посылает.
Э..с чего бы вдруг если Мастер OPC через ModBus TCP и ПЧВ Slave по RS485. Кидаем запрос по Ethernet и ждем когда он из МКОН в сторону ПЧВ вылезет по RS485. Только МКОН у меня вместо этого сразу 83 назад по Ethernet возвращает.
Э..с чего бы вдруг если Мастер OPC через ModBus TCP и ПЧВ Slave по RS485. Кидаем запрос по Ethernet и ждем когда он из МКОН в сторону ПЧВ вылезет по RS485. Только МКОН у меня вместо этого сразу 83 назад по Ethernet возвращает.
на rs-485 МКОН по отношению к ПЧВ мастер или как Вы пишите
slave в RS485?
ПЧВ- Slave, МКОН-Master. Можно подумать тут есть варианты��
ПЧВ- Slave, МКОН-Master. Можно подумать тут есть варианты��
себя прочтите, сами же даете варианты
настроил через конфигуратор мастер в Ethernet, slave в RS485.
Вам на это и указал ASo
Филоненко Владислав
07.05.2020, 10:21
Настройте slave Ethernet, master RS
A.Simonov
07.05.2020, 12:15
По делу сейчас распаковал МКОН подключил к ПЧВ3 (но это и не важно) настроил через конфигуратор мастер в Ethernet, slave в RS485. Само собой настройки порта. В итоге запускаю из OPC опрос в ответ приходят пакеты с кодом ошибки 83. При этом лампочка RS485 не моргает и попытка прослушать что на шине тоже говорит что МКОН ничего в шину 485 не отправляет. Этим же адаптером который для прослушки шины 485 отключив опрос через TCP в OPC меняю опрос напрямую и опрос идет. Я так понимаю что ковыряние в маршрутах мне не поможет? Хотя 1й маршрут странный (был по умолчанию) R1 7:0:10:40:0:10:R
Добрый день.
1) Убедитесь, что OPC отправляет посылки на IP МКОН, на SlaveID: 16 dec (0x10 hex)
Именно такой адрес указан у вас в маршруте: 7:0:10:40:0:10:R
По умолчанию OPC используют в качестве SlaveID:1
Пакеты с таким адресом перенаправляются к собственным регистрам МКОН.
2) Убедитесь, что "режим порта RS-485" установлен в положение master
48854
P.S. Хорошо бы эту китайскую азбуку поподробней описать.
Мы специально не хотели грузить пользователей этой "азбукой" и поэтому сделали плагин, который должен помочь настроить МКОН автоматически.
48855
Инструкция по работе с плагином доступна здесь -> https://owen.ru/product/mkon/documentation
В конце руководства по эксплуатации есть описание ручного способа настройки, через маршруты.
В помощь к освоению, могу дать вам такую памятку:
48856
Э..с чего бы вдруг если Мастер OPC через ModBus TCP и ПЧВ Slave по RS485. Кидаем запрос по Ethernet и ждем когда он из МКОН в сторону ПЧВ вылезет по RS485. Только МКОН у меня вместо этого сразу 83 назад по Ethernet возвращает.
Вы правы, в плагине "Настроить шлюз" д.б. режим "Мастер в сети Ethernet - Slave RS485"
В "настройки режимов - режим порта RS485 - мастер"
Я бы рекомендовал еще "Настройки порта RS485 - Физ.режим порта RS485 - Физ.мастер" Некоторые устройства без подтягивающих резисторов категорически не работают. Ну и аккуратно перепроверить все параметры сетей. В маршрутизацию я не лазил, после настроек сетей и режима работы все работало. Правда недолго, если Вы читали предисторию.
Добрый день.
1) Убедитесь, что OPC отправляет посылки на IP МКОН, на SlaveID: 16 dec (0x10 hex)
Именно такой адрес указан у вас в маршруте: 7:0:10:40:0:10:R
По умолчанию OPC используют в качестве SlaveID:1
Пакеты с таким адресом перенаправляются к собственным регистрам МКОН.
Дело было именно в маршруте. С маршрутом 7:0G:40:0:S:R работает. Правда почему первая 7 так и не понял.
себя прочтите, сами же даете варианты
Вам на это и указал ASo Прочел еще раз, а вот вы похоже конфигуратор не открывали никогда. Там режим именно так и называется как у меня выше написано https://cdn1.savepice.ru/uploads/2020/5/10/fa2b215616c6fb84a787dabcf07f31f5-full.png
Филоненко Владислав
10.05.2020, 19:02
первая 7 - это маска физ. входов, с которых принимаются пакеты для этого маршрута, смотрите памятку
Так по этой памятке и не понятно "7 - резерв (UART)"
Евгений Кислов
11.05.2020, 21:15
Так по этой памятке и не понятно "7 - резерв (UART)"
В памятке приводится соответствие номеров бит и интерфейсов. Бит номер 7 действительно соответствует "резерв (UART)".
А в маршруте 7 - это значение битовой маски (т.е. биты 0, 1, 2 - в TRUE). И тут уже речи о бите 7 вообще не идет.
Вот теперь дошло. Спасибо!
Вячеслав@
31.07.2020, 09:57
Всю тему прочитать не осилил, прошу проконсультировать.
Можно ли с помощью МКОН сделать такую конфигурацию:
СП3хх расширенной версии подключен к МКОН по Modbus TCP (СП мастер), а МКОН подключен к одному ПР200 по Modbus RTU (МКОН мастер).
Для чего это нужно: во первых, возможно понадобится возможность подключения Скада по TCP, а во вторых хочу избавить СП от RS485.
Евгений Кислов
31.07.2020, 10:00
Всю тему прочитать не осилил, прошу проконсультировать.
Может ли с помощью МКОН сделать такую конфигурацию:
СП3хх расширенной версии подключен к МКОН по Modbus TCP (СП мастер), а МКОН подключен к одному ПР200 по Modbus RTU (МКОН мастер).
Для чего это нужно: во первых, возможно понадобится возможность подключения Скада по TCP, а во вторых хочу избавить СП от RS485.
Добрый день.
Да, такая конфигурация возможна.
Вячеслав@
31.07.2020, 10:08
Добрый день.
Да, такая конфигурация возможна.
Евгений, благодарю.
Алексей Сидоров
10.11.2020, 00:46
Доброго дня. Подскажите, подойдёт ли МКОН, чтобы считывать и устанавливать параметры дискретных выходов ПР по ethernet через софт с Modbus TCP? Например node-red, или какой ещё.
Хотел уточнить как дела с устранением проблем с зависанием, поднимавшихся в марте-апреле? Ни здесь ни на мою личную почту, по которой более предметно обсуждали этот вопрос, чтобы не будоражить форум, до сих пор никакой информации.
Kondratev.S
12.11.2020, 21:58
Хотел уточнить как дела с устранением проблем с зависанием, поднимавшихся в марте-апреле? Ни здесь ни на мою личную почту, по которой более предметно обсуждали этот вопрос, чтобы не будоражить форум, до сих пор никакой информации.
Да похоже никак не решана. МКОН получил 07.11.2020. Похожая ситуация, потеря связи на 5-6 секунд. Более подробно описал здесь https://owen.ru/forum/showthread.php?t=33963
Филоненко Владислав
20.11.2020, 20:13
Каково у Вас время ожидания ответа от прибора на мастере модбус TCP? Оно должно быть не менее 300 мс.
Филоненко Владислав
21.11.2020, 09:39
У шлюза тоже есть таймаут ожидания ответа по 485. И если таймаут мастера больше чем таймаут шлюза - то мастер будет рвать соединение и конектится снова.
У МКОН 2 сокета для соединения. И мастер, быстро перебирая эти соединения добьётся их "забития" пакетами.
Учитывая что 80% известных мне мастеров закрывают соединение криво, т.е. "честь" реально оборвать коннект достаётся шлюзу (таймаут при отсутствии обмена 5 секунд)
Вот и получается. У мастера слишком маленький таймаут. Модуль вроде успевает, но если вдруг он призадумается, то мастер не дожидается ответа, и сразу реконектит.
Шлюз ждёт ответ 300 мс.
Мастер реконектит и снова шлёт запрос. Шлюз ставит запрос (по 2-му сокету) в очередь, т.к. порт 485 занят ещё первым запросом.
Мастер и тут не дожидается ответа и снова реконектит.
А сокеты всё... Ждем 5 секунд на принудительный сброс соединения шлюзом.
Что делать:
1. Таймаут мастера не менее 300 мс
2. Мастер должен закрывать коннект полностью, а лучше не закрывать его сразу, а ждать нескольких запросов без ответа.
3. Мы запланировали работы по добавлению настраиваемого таймаута в МКОН.
Мы очень интенсивно и многосуточно тестировали МКОН с 2-мя мастерами по ТСП одновременно на стенде из 31 приборов на 485. В нагруженной офисной сети. И проблем с пропаданием связи не было зафиксировано.
НО! таймауты у мастеров были выставлены реалистичные, а не 10мс, как я видел на некоторых проектах.
В данном случае банальный вопрос, почему шлюз переключает сокеты от одного и того же мастера? где тут логика ?
Видя очередной запрос от того же самого устройства шлюз должен его просто игнорировать а не создавать новый сокет...
например мастер с IP 192.168.10.15 порт х, если второй запрос от него же, зачем создавать под него новый сокет ?
В качестве мастеров были ОВЕН и ИНСАТ ОРС-серверы. "Время ожидания ответа" (этот параметр?) были 300, 500 и 1000 мс с одинаковым отрицательным результатом. Честно сказать, сейчас спросил просто из любопытства, участвовать в тестировании и изучении оборудования, за которое, на секундочку, надо еще и платить деньги, никакого удовольствия.
Для себя я нашел решение, которое безотказно работает при тех же конфигурациях остального железа и софта, на которых МКОН виснет. Причем не приходится упражняться с выбором всевозможных параметров, а потом бояться, что на объекте через несколько минут-часов-дней это все зависнет. И даже если выставлял заведомо малые значения, оборудование не зависало, да, в этом случае были пропуски данных при некоторых запросах, но при следующем/следующих запросах обмен возобновлялся.
На этом по МКОН у меня всё.
Филоненко Владислав
21.11.2020, 12:43
В данном случае банальный вопрос, почему шлюз переключает сокеты от одного и того же мастера? где тут логика ?
Видя очередной запрос от того же самого устройства шлюз должен его просто игнорировать а не создавать новый сокет...
например мастер с IP 192.168.10.15 порт х, если второй запрос от него же, зачем создавать под него новый сокет ?
Он как раз не переключает. это мастер бросает текущее соединение и открывает следующее. Шлюз пасивную роль играет, как и любой сервер ТСП.
А ситуация 2 одновременных потока запросов от одного IP - норма. И порты у запросов будут разные, так устроен ТСП.
Филоненко Владислав
21.11.2020, 12:45
В качестве мастеров были ОВЕН и ИНСАТ ОРС-серверы. "Время ожидания ответа" (этот параметр?) были 300, 500 и 1000 мс с одинаковым отрицательным результатом. Честно сказать, сейчас спросил просто из любопытства, участвовать в тестировании и изучении оборудования, за которое, на секундочку, надо еще и платить деньги, никакого удовольствия.
Для себя я нашел решение, которое безотказно работает при тех же конфигурациях остального железа и софта, на которых МКОН виснет. Причем не приходится упражняться с выбором всевозможных параметров, а потом бояться, что на объекте через несколько минут-часов-дней это все зависнет. И даже если выставлял заведомо малые значения, оборудование не зависало, да, в этом случае были пропуски данных при некоторых запросах, но при следующем/следующих запросах обмен возобновлялся.
На этом по МКОН у меня всё.
Т.е. логов снифера так и не будет, как я понял. просто поболтать. А был ли мальчик вообще?
Не путайте претензию с "поболтать" , пожалуйста . Вам же ответили про время ожидания ,про эксперименты с другим конвертером....
Филоненко Владислав разные порты, разные сокеты, не спорю, но когда запросы с одного порта, неужели МКОН у вас получился таким чахлым и тупым, что не может проверить запрос тот же, что и предыдущий и отдать уже готовый ответ, если он получил его от устройства, даже если мастер разрывал соединение ?
Филоненко Владислав
21.11.2020, 21:10
Филоненко Владислав разные порты, разные сокеты, не спорю, но когда запросы с одного порта, неужели МКОН у вас получился таким чахлым и тупым, что не может проверить запрос тот же, что и предыдущий и отдать уже готовый ответ, если он получил его от устройства, даже если мастер разрывал соединение ?
Вот опишите алгоритм идентификации пакета, пришедшего от разных соединений? Как прибор должен понять что это на самом деле попытка мастером опросить снова пакет, не полученный ранее? А не просто ещё один запрос, пусть по тому же адресу?
А если надо каждые 5 мс опрашивать - это повторы или уникальные запросы?
Филоненко Владислав
21.11.2020, 21:12
Не путайте претензию с "поболтать" , пожалуйста . Вам же ответили про время ожидания ,про эксперименты с другим конвертером....
логи, где логи.
Или человек хочет разобраться (он же деньги на прибор потратил, не правда ли?), или просто поболтать.
Повторю, мы интенсивно тестировали МКОН опросом от 2-х ОПС в загруженной сети и сбоев не было. Так что надо бы разобраться в причинах.
логи, где логи.
Или человек хочет разобраться (он же деньги на прибор потратил, не правда ли?), или просто поболтать.
Вот именно, заплатил деньги. И не просто за корпус с микросхемами. А за отсутствие проблем.
Логи.... Понимаете ли. Люди часто имеют дело с прибором не в лаборатории. И регулярно даже не на СВОЕМ (в смысле работы) производстве. А на стороннем. Или своем, но где эксперименты производить скажем так, не желательно, по техническим причинам. И получив некоторые проблемы - проще сменить прибор. Иногда и производителя.
Филоненко Владислав
22.11.2020, 09:05
Вот именно, заплатил деньги. И не просто за корпус с микросхемами. А за отсутствие проблем.
Логи.... Понимаете ли. Люди часто имеют дело с прибором не в лаборатории. И регулярно даже не на СВОЕМ (в смысле работы) производстве. А на стороннем. Или своем, но где эксперименты производить скажем так, не желательно, по техническим причинам. И получив некоторые проблемы - проще сменить прибор. Иногда и производителя.
Наша фирма всегда славилась своей техподдержкой. Но мы не можем быть более клиентами чем сами клиенты.
А что там описывать? вы знаете с какого IP и на какой порт пришел запрос, если у вас сквозной преобразователь протокола из TCP сети в RTU так сложно запомнить на какой адрес устройства и какие регистры запрашиваются и в каком количестве ?
Честно не сталкивался с преобразователями протоколов на лету, обычно железка сама настраивается на чтение регистров slave RTU устройств и предоставляет регистры для TCP, а там хоть пять подключений, это не мешает забирать данные, потому что сама железка читает slave со своим периодом, а ее опрашивают со своим и эти периоды никак не пересекаются.
Вы же сделали что-то уникальное и тестировали только на OPC, а с двух ПЛК тестировали?, а с двух ПЛК стороннего производителя тестировали ? Или подобные тесты отдали на откуп клиентам ?
Честно не сталкивался с преобразователями протоколов на лету, обычно железка сама настраивается на чтение регистров slave RTU устройств и предоставляет регистры для TCP, а там хоть пять подключений, это не мешает забирать данные, потому что сама железка читает slave со своим периодом, а ее опрашивают со своим и эти периоды никак не пересекаются.
Сколько угодно таких преобразователей на лету. Скажем так, их большинство. И это удобно.
Только вот само RTU устройство не умеет работать с двумя мастерами, если нет разграничения во времени. А так то да, Ethernet-RS485 с TCP сервером так же на лету работают, если на ПК либо виртуальный COM порт, либо ПО может работать с портом сразу поверх TCP. Проблемы конечного устройства это не отменяет. Но тут то заявлено, что мы обращаемся именно по Modbus TCP, шлюз преобразует в RTU и отдает обратно в Modbus TCP...
У меня есть одна железка подобного рода, но руки не доходят потестить именно таким образом, чтобы ее двое опрашивали, посмотреть что из этого получится.
Филоненко Владислав
22.11.2020, 13:38
А что там описывать? вы знаете с какого IP и на какой порт пришел запрос, если у вас сквозной преобразователь протокола из TCP сети в RTU так сложно запомнить на какой адрес устройства и какие регистры запрашиваются и в каком количестве ?
Честно не сталкивался с преобразователями протоколов на лету, обычно железка сама настраивается на чтение регистров slave RTU устройств и предоставляет регистры для TCP, а там хоть пять подключений, это не мешает забирать данные, потому что сама железка читает slave со своим периодом, а ее опрашивают со своим и эти периоды никак не пересекаются.
Вы же сделали что-то уникальное и тестировали только на OPC, а с двух ПЛК тестировали?, а с двух ПЛК стороннего производителя тестировали ? Или подобные тесты отдали на откуп клиентам ?
Или устройство преобразователь (и тогда он НЕ ДОЛЖЕН трактовать/оптимизировать пакеты по модбас, это дело мастера), а тем более рассматривать 2 соединения с одного IP как одно!
Либо это коуплер, сам опрашивающий устройства и видимый во внешней сети как slave сразу по множеству адресов.
Во втором случаем можно играться с анализом и т.п. оптимизациями, т.к. уж в своём собственном ответе устройство уверено.
Простите, а кто в здравом уме будет настраивать опрос двумя мастерами с одного ПК ? этот режим как раз для разных мастеров с разными адресами.
И на прошлой странице вы кажется неправильно выразились, ранее писали, что у мастера таймаут должен быть заведомо больше двух опросов, так как МКОН ставит в очередь запрос, если в этот момент идет опрос другим мастером.
Филоненко Владислав
22.11.2020, 16:39
Простите, а кто в здравом уме будет настраивать опрос двумя мастерами с одного ПК ? этот режим как раз для разных мастеров с разными адресами.
И на прошлой странице вы кажется неправильно выразились, ранее писали, что у мастера таймаут должен быть заведомо больше двух опросов, так как МКОН ставит в очередь запрос, если в этот момент идет опрос другим мастером.
О, бывает и так. основной процесс управления и визуализация.
Таймаут должен быль более времени ожидания ответа шлюзом. Если же 2 мастера посылают пакеты так часто, что их переварить 485 не может - тут никакие таймауты не помогут...
Речь то идет не о обычном времени ответа модуля, а о максимальном.
Т.е. логов снифера так и не будет, как я понял. просто поболтать. А был ли мальчик вообще?
Помимо сообщений в этой теме форума, чтобы не волновать всю общественность, я общался по почте с Александром Симоновым и Евгением Дударевым. Обсуждались и конфигурации и рекомендации... Итог - "разберемся, сообщим". Прошло более полугода, ни ответа, ни по форуму положительного не увидел. Заплаченные за один прибор деньги считаю выброшенными, но заново ввязываться в изучение проблем Вашего оборудования, сокеты там виноваты или таймауты, это еще терять время, которое тоже деньги. Решение для себя я нашел (полгода или сколько еще ждать?), так что МКОН мне более неинтересен. Может, когда-нибудь это изделии действительно отладится (тема то в принципе востребованная), будут положительные отзывы от коллег, но пока так.
Филоненко Владислав тут зависит как у вас работают timeout-ы. Если стоит 1000 мс, ответ пришел через 50 и 950 мс ваше ПО будет тупо ждать, то это простым словом "жопа" а не ПО.
Если ответ пришел раньше, то нафик остальное время ожидания.... пауза и новый запрос согласно периода опроса.
з.ы. вот не знаю, как у вас ОПС работают, стараюсь с ними не связываться вообще без крайней необходимости.
логи, где логи.
Или человек хочет разобраться (он же деньги на прибор потратил, не правда ли?), или просто поболтать.
Повторю, мы интенсивно тестировали МКОН опросом от 2-х ОПС в загруженной сети и сбоев не было. Так что надо бы разобраться в причинах.
Вы издеваетесь - купил значит киповец шлюз ,общие настройки осилил ,а вы ему давай ЛОГИ , а он понятия не имеет где и как их получить(не все же такие программисты как вы). У меня штук 5 подобных конвертеров ,все настройки на веб странице сделал и вперед . Это вы с ОПС проверяете ,там все логи видны , а с реальным железов ???
Помимо сообщений в этой теме форума, чтобы не волновать всю общественность, я общался по почте с Александром Симоновым и Евгением Дударевым. Обсуждались и конфигурации и рекомендации... Итог - "разберемся, сообщим". Прошло более полугода, ни ответа, ни по форуму положительного не увидел. Заплаченные за один прибор деньги считаю выброшенными, но заново ввязываться в изучение проблем Вашего оборудования, сокеты там виноваты или таймауты, это еще терять время, которое тоже деньги. Решение для себя я нашел (полгода или сколько еще ждать?), так что МКОН мне более неинтересен. Может, когда-нибудь это изделии действительно отладится (тема то в принципе востребованная), будут положительные отзывы от коллег, но пока так.
Спасибо Вячеславу от фирмы , у покупателя отбил желание еще покупать... Мало того ,что в 2-3 раза дороже других ,так еще полгода от техподдержки надо ждать .Совсем расслабились ...
Это к чему ?
К внешнему коммутатору.
Филоненко Владислав
23.11.2020, 07:56
Спасибо Вячеславу от фирмы , у покупателя отбил желание еще покупать... Мало того ,что в 2-3 раза дороже других ,так еще полгода от техподдержки надо ждать .Совсем расслабились ...
Ну, во первых не надо передергивать моё имя, Семён Семёныч.
Во вторых я не техподдержка.
Ну и песни по 3 раза дороже тут уже разбирались.
Филоненко Владислав
23.11.2020, 07:57
Кстати, у меня нет МКОНа. При наличии сделал бы простейший тест :
ПЛК какой-нить 110й - 1 штука.
МКОН - 1 штука.
eth МКОНА воткнул в eth ПЛК, rs МКОНА в rs ПЛК ессно.
В ПЛК мастер по TCP (out register) и слейв по rs.
ПЛК меняет как-нить out regter мастера, взводит таймер и ждет когда оное прилетит в слейв.
Бродить данным кроме* как в МКОНЕ негде. Все в тепличных условиях. Многое показала бы статистика работы за ночь типа :
бродили 0mc - X раз
бродили 1мс - Y раз
...
бродили > 200..300мс - Z раз
И тоже, но с чтением из слейва.
Поменяли на слейве, засекли время, ждем когда пришли в мастера (in regiser)
*уж тут то конфигурация не должна подвести ж.
Валенок, у 110 типовое время ответа до 3 мс. Иногда :)
И таки Вы думаете мы не тестировали сутками МКОН? Поэтому то и возникли вопросы про логи
И как это тут будет влиять ?
Пока отвечает слейв по RS, по езернету можно пропустить сотню запросов.
Можно. А сотня запросов возьмется откуда ?
От мастера.
Про что и говорит Филоненко.
Филоненко Владислав
23.11.2020, 14:06
Т.е. он не ожидая ответа на 1й запрос, генерит еще 99 ?
Да, причём еще некоторые мастера бросают текущее соединение и конектятся по новой
Филоненко Владислав
24.11.2020, 09:34
Тогда мы говорим не про модбас.
Это как-то имеет отношение к вопросу ?
и к замечанию ?
- А могли бы Вы работать после трёх стаканов?
- Ну так работаю же!
Можно как-то показать логическую цепь ?
Цепь- после 1 стакана хорошо ,после 2го - мысли так и путаются ,после 3го - работаем, как можем ...:D
Филоненко Владислав
24.11.2020, 14:23
ну так работает. Я же написал. Это и есть ответ
Валенок по первым заявлениям таймаут у мастера должен быть больше в два раза, на случай, если в этот момент порт RS485 опрашивается вторым мастером и МКОН поставит в очередь запрос первого мастера. А потом вдруг все поменялось...
У шлюза тоже есть таймаут ожидания ответа по 485. И если таймаут мастера больше чем таймаут шлюза - то мастер будет рвать соединение и конектится снова. сообщение https://owen.ru/forum/showthread.php?t=32887&p=343618&viewfull=1#post343618
и там же где-то, что таймаут мастера должен быть не менее 300 мс (ТРЕХСОТ так его)
з.ы. да, есть ситуации когда после каждого опроса требуется обрывать соединение между ПК и шлюзом так же как и удерживать соединение. Это не принципиально особенно, а вот если мастер получив ответ ждет оставшееся время таймаута это туши свет, сам так запрограммил один драйвер, не понимая процесса. Потом правда с разработчиком допилили часть кода, где можно было останавливаться раньше и обрывать таймаут. Вообще проблема сидит где-то в работе с портом в Windows, если я правильно понял.
Валенок почему перебор? просто столкнулся с тем, что есть протоколы, где длина ответа НЕИЗВЕСТНА, вот такие пакостные протоколы бывают.
И в коде нет возможности задать четкий размер буфера для принятия байт, только заведомо бОльший по размеру, при этом штатные средства работы с COM в ОС не предполагают динамическое изменение буфера на лету. В некоторых случаях можно посчитать длину, в некоторых нет,и тут вступает в дело timeout, который ждет несчастные несколько байт, которых уже не будет никогда, так как ответ пришел полностью.
з.ы. в Modbus длина ответа известна, так что там проблем нет, timeout работает только при обрыве связи....
Филоненко Владислав
26.11.2020, 09:05
Валенок по первым заявлениям таймаут у мастера должен быть больше в два раза, на случай, если в этот момент порт RS485 опрашивается вторым мастером и МКОН поставит в очередь запрос первого мастера. А потом вдруг все поменялось...
сообщение https://owen.ru/forum/showthread.php?t=32887&p=343618&viewfull=1#post343618
и там же где-то, что таймаут мастера должен быть не менее 300 мс (ТРЕХСОТ так его)
з.ы. да, есть ситуации когда после каждого опроса требуется обрывать соединение между ПК и шлюзом так же как и удерживать соединение. Это не принципиально особенно, а вот если мастер получив ответ ждет оставшееся время таймаута это туши свет, сам так запрограммил один драйвер, не понимая процесса. Потом правда с разработчиком допилили часть кода, где можно было останавливаться раньше и обрывать таймаут. Вообще проблема сидит где-то в работе с портом в Windows, если я правильно понял.
Получив ответ от slave - МКОН, естественно, не ждет еще 300мс. а вот не получив - ждет. И мастер, опрашивающий МКОН, по идее должен иметь таймаут не менее этих 300 мс.
Получив ответ от slave - МКОН, естественно, не ждет еще 300мс. а вот не получив - ждет. И мастер, опрашивающий МКОН, по идее должен иметь таймаут не менее этих 300 мс.
ну вот взяли и разрушили стройную теорию мелкого что вы не умеете делать приборы
Филоненко Владислав каким образом МКОН знает, что ответ полный если он сквозной преобразователь а не сам опрашивает ? вот это и интересно.
capzap а при чем тут МКОН, когда речь о Мастере, который опрашивает прибор через МКОН ?
Если правильно понимаю, МКОН всего лишь преобразует TCP запросы в RTU и придерживает в очереди запрос, если в этот момент опрашивает другой мастер.
capzap а при чем тут МКОН
вот именно причем тут прибор, если Ваша роль городского сумасшедшего (http://cyclowiki.org/wiki/%D0%93%D0%BE%D1%80%D0%BE%D0%B4%D1%81%D0%BA%D0%BE%D 0%B9_%D1%81%D1%83%D0%BC%D0%B0%D1%81%D1%88%D0%B5%D0 %B4%D1%88%D0%B8%D0%B9#.D0.92_.D0.98.D0.BD.D1.82.D0 .B5.D1.80.D0.BD.D0.B5.D1.82.D0.B5) изрядно поднадоела. С чего появился повод высказать такое предположение:
Филоненко Владислав тут зависит как у вас работают timeout-ы. Если стоит 1000 мс, ответ пришел через 50 и 950 мс ваше ПО будет тупо ждать, то это простым словом "жопа" а не ПО. иди сейчас в одном посте у Вас прибор и сковозной и одновременно ставит запросы в очередь. Нет прибора, не тестировали, не высказывайте своего мнения о чем не знаете
capzap вы мне запрещаете узнавать принципы работы шлюза перед выбором его в кандидаты к покупке? Тогда зачем нужен форум вообще?
Не знаю, к счастью или нет, но голый Modbus и чтение его с двух мест меня мало интересует, вот был бы он сквозным для любых протоколов, и выстраивал бы в очередь мастеров, наверное уже приобрел бы...
з.ы. надоело, не читайте, пропускайте мимо глаз и ушей.
capzap вы мне запрещаете узнавать принципы работы шлюза перед выбором его в кандидаты к покупке?
не прикрывайтесь тем что хотите узнать и уж тем более купить. Высказать оценочное суждение об устройствах которые видели только на картинках, придумывать проблемы которых не существует не одно и тоже, что заниматься саморазвитием и задавать вопросы, пускай для многих и глупые
e.filatov
26.11.2020, 12:34
Филоненко Владислав каким образом МКОН знает, что ответ полный если он сквозной преобразователь а не сам опрашивает ? вот это и интересно.
Пробовали спецификацию ModbusRTU читать? Пауза между символами 3,5 символа на текущей скорости обмена означает завершение передачи. И если, простите, slave тупица и порвал пакет - проблемы индейцев
Пробовали спецификацию ModbusRTU читать? Пауза между символами 3,5 символа на текущей скорости обмена означает завершение передачи. И если, простите, slave тупица и порвал пакет - проблемы индейцев
И мастеру МКОН сообщает как-то что ответа не будет? то есть мастер будет выжидать 300+ мс в то время, когда МКОН точно знает, что пакет оборвался и ждать уже ничего никому не надо ?
capzap если двумя Scada системами я могу синхронизироваться по времени и опрашивать ОДНО RTU устройство, то вот сделать синхронизацию между Scada и например ПЛК может оказаться проблематичным или с танцами и бубном. То такое устройство становится очень интересным. Но вот судя по жалобам тратить деньги под объект может оказаться печальным. А тратить свои для тестирования не очень интересно, и так уже столько игрушек за свои купил, что уже как-то и хватит.
capzap если двумя Scada системами я могу синхронизироваться по времени и опрашивать ОДНО RTU устройство, то вот сделать синхронизацию между Scada и например ПЛК может оказаться проблематичным или с танцами и бубном. То такое устройство становится очень интересным. Но вот судя по жалобам тратить деньги под объект может оказаться печальным. А тратить свои для тестирования не очень интересно, и так уже столько игрушек за свои купил, что уже как-то и хватит.
использовать ОРС который единолично опрашивает устройства, а скады обращаются, как клиенты, это более надежно и профессионально.
жалобы, а какие жалобы? Довести до общественности что есть проблемы, не рассказав как воспроизвести, не предоставить лог опроса, заявить что уже полгода не пользуюсь это эмоция а не жалоба. Валенок говорил правильные вещи, был бы прибор попробовал бы "нагнуть" его чтоб он сломался, но у меня его тоже нет, позиция овена тут не совсем верная наверное это не зная суть переписки полугодичной давности. В базовом варианте все работает, мне нет оснований не верить что исследования проводились и тестировалось не на одном приборе, не стоит забывать что на шине время на запрос-ответ для первого и для последнего слейва может существенно отличаться.
а по играться мне приборы приходят бесплатно, а за свои деньги Вы видимо покупаете, то что потом не можете применить на месте, так это не игрушки а Ваши навыки и умения
capzap попробуйте Owen OPC запустить на ПК с доменными политиками, очень сильно удивитесь. Кто первый подключился, тот и получает данные, второй все по нулям. Пульзователь доменный (локального нет). Я данный вопрос задавал Овену, до сих пор тишина...
Так покупаю то, что могу применить у себя дома например, а под объект точно не буду... И не всегда есть возможность брать на время, так как на тестирование тоже надо время убить. Кстати на счет поиграться, производители часто требуют отчетности да еще и указания объекта, под который играются. А некоторые например на месяц с оплатой, в общем вариаций много. Просто надоело уже, сперва ищем инфу без устройства, если подходит, тогда уже думаем.
capzap попробуйте Owen OPC запустить на ПК с доменными политиками, очень сильно удивитесь. Кто первый подключился, тот и получает данные, второй все по нулям. Пульзователь доменный (локального нет). Я данный вопрос задавал Овену, до сих пор тишина...
почему этот вопрос должны решать овеновцы, Active Directory кто настроил тот и должен выяснять что у него не так.
capzap а почему не Овен ? как минимум у него все возможности провести масштабное тестирование своего продукта и выдать какое-то заключение или доработать продукт.
Обычно это заканчивается со стороны Овен "у нас все работает"...
И в других темах суть та же :)
capzap а почему не Овен ? как минимум у него все возможности провести масштабное тестирование своего продукта и выдать какое-то заключение или доработать продукт.
Обычно это заканчивается со стороны Овен "у нас все работает"...
И в других темах суть та же :)
да не несите бред, найдите того безумного сисадмина, который отдаст настройки своей групповой политики, даже пускай в своих корыстных целях, чтоб за него кто то решил проблему и выдал решение, а без полного повторения домена и смысла нет что то тестировать.
И в других темах суть та же, Вам и Вашим колегам лень работать, начальству отчитываетесь что виноват овен и сидите на жопе ровно, ждете пенсию
capzap я вижу что подходы разные у нас... Производитель ПО в первую очередь должен предусматривать использование своего ПО даже в самых извращенных мыслях сисадминов.... Не важно кто производитель, Овен, Пупкин&Ко и так далее. Если есть различные варианты построения доменов (а они различны, сужу по одной из прошлых контор и нынешней) то как-то должно обязывать.
Как минимум давать рекомендации, что и как настраивать и т.д. Подводные камни описывать в документации, чтобы было что предоставить тем же админам и они сделали соответствующие настройки.
Как правило админы ни сном ни духом об АСУТП, что и как там работает. Впрочем как и обратная сторона, как там работает AD или еще что мне тоже не очень интересно. Поэтому подобные вопросы в первую очередь как раз и направляются производителям ПО, чтобы они разобрались что не так, и что надо сделать, чтобы было так.
Понимаете ли в чем дело именно с OPC... Оно опирается на системные библиотеки OPC foundation, и эта проблема - оттуда. Есть инструкции по настройке политик для DCOM для любого OPC, откуда и растут эти проблемы. Правда... это не всегда срабатывает, и есть подозрение, что по причине Microsoft.
Поэтому - перейдите на OPC UA, и будет Вам счастье. Да, это не ОВЕН и он платный, но данных проблем - нет.
Филоненко Владислав
29.11.2020, 19:38
Филоненко Владислав каким образом МКОН знает, что ответ полный если он сквозной преобразователь а не сам опрашивает ? вот это и интересно.
capzap а при чем тут МКОН, когда речь о Мастере, который опрашивает прибор через МКОН ?
Если правильно понимаю, МКОН всего лишь преобразует TCP запросы в RTU и придерживает в очереди запрос, если в этот момент опрашивает другой мастер.
Ну какой сквозной, помилуйте сударь! С одного конца модбас ТСП, с другого RTU. Ясно что надо принять пакет, проверить CRC, преобразовать и переслать. Он сквозной, но с преобразованием
Филоненко Владислав
29.11.2020, 19:39
И мастеру МКОН сообщает как-то что ответа не будет? то есть мастер будет выжидать 300+ мс в то время, когда МКОН точно знает, что пакет оборвался и ждать уже ничего никому не надо ?
capzap если двумя Scada системами я могу синхронизироваться по времени и опрашивать ОДНО RTU устройство, то вот сделать синхронизацию между Scada и например ПЛК может оказаться проблематичным или с танцами и бубном. То такое устройство становится очень интересным. Но вот судя по жалобам тратить деньги под объект может оказаться печальным. А тратить свои для тестирования не очень интересно, и так уже столько игрушек за свои купил, что уже как-то и хватит.
А как он должен сообщить? В протоколе ModBus, насколько я в курсе, это не предусмотрено.
Филоненко Владислав
29.11.2020, 19:42
А кто вообще этот МКОН видел ? Он у кого-нить работает кроме создателей и тех у кого не работает ? Просто любопытно
Валенок, Вы же наш любимый клиент. Но что же на бета-тесты не записались то? Специальный розовый МКОН сделали б для Вас!
Евгений Кислов
29.11.2020, 20:14
И мастеру МКОН сообщает как-то что ответа не будет? то есть мастер будет выжидать 300+ мс в то время, когда МКОН точно знает, что пакет оборвался и ждать уже ничего никому не надо ?
А как он должен сообщить? В протоколе ModBus, насколько я в курсе, это не предусмотрено.
С помощью exception c кодом 0x0B - и это действительно стоит поддержать, конечно.
52243
Филоненко Владислав
29.11.2020, 20:40
И сколько мастеров поймут и правильно обработают это?
Евгений Кислов
29.11.2020, 20:48
И сколько мастеров поймут и правильно обработают это?
Я предполагаю, большинство мастеров работают очевидным образом:
если код функции в ответе = (код функции в запросе + 0x80) => выделить и передать дальше код исключения, и перейти к отправке следующего запроса
Если мастер работает по иному принципу, то его соответствие стандарту, на мой взгляд, вызывает вопросы.
Филоненко Владислав простите, но это уже не ваша забота, сколько мастеров поймут.
В споре кажется родится истина (правилное решение) ...
если уж речь зашла о спецификациях, может в этом устройстве не 11 код нужен а пятый
С помощью exception c кодом 0x0B - и это действительно стоит поддержать, конечно.
52243
Для прозрачного преобразователя работать не будет. Это для коуплеров.
Так вроде шлюз не прозрачный ,а с преобразованием протокола ...TCP>>RTU
Филоненко Владислав
30.11.2020, 11:44
не бывает прозрачных шлюзов, это уже удлинители интерфейсов
не бывает прозрачных шлюзов, это уже удлинители интерфейсов
Это игра слов (шлюз,мост,удлнитель...) , я бы назвал конвертер(преобразователь) интерфейсов в таком случае(когда прозрачный режим работы), ибо это не всегда удлинитель , в общем случае. В универсальном шлюзе(конверторе) все бывает ...А то получается - поставил галочку в веб настройках это шлюз ,а не поставил , то не шлюз , одно и тоже устройство . Да нет ,просто меняются режимы работы!
Это и есть прозрачный шлюз. То есть без запоминания каких то состояний.
В отличии от коуплеров, которые опрашивают сами, строят память опрошенных данных, а мастер относительно этого коуплера обращается только к этой памяти.
Я ставил такие от М. Там есть возможность как ручной настройки опрашиваемых адресов устройств и регистров, так и настройка на лету. Вот там и нужен этот код состояния.
Согласитесь, ведь гораздо же проще сказать мастеру выставить больше 300 мс и не заморачиваться с программной частью... :)
Именно так.
Давайте здраво и по существу.
1. Сеть считается функционирующей нормально, если в ней тераятся/искажается не более 1% пакетов.
2. Считаем, что основное время сеть работает в не аварийном режиме, т.е. не опрашиваются не существующие адреса.
Тогда какие проблемы?
Проблема в том, что при ошибке связи между МКОН и RTU устройством мастер должен выжидать все оставшееся время таймаута.
Проблема в том, что при ошибке связи между МКОН и RTU устройством мастер должен выжидать все оставшееся время таймаута.
Естественно. И что?
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot