Уважаемые коллеги!
Убедительно прошу Вас высказываться по существу в этой теме. Для всего остального есть раздел "трёп" и личные сообщения.
Спасибо за понимание.
Вид для печати
Уважаемые коллеги!
Убедительно прошу Вас высказываться по существу в этой теме. Для всего остального есть раздел "трёп" и личные сообщения.
Спасибо за понимание.
По делу сейчас распаковал МКОН подключил к ПЧВ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 не посылает.
ПЧВ- Slave, МКОН-Master. Можно подумать тут есть варианты
Настройте slave Ethernet, master RS
Добрый день.
1) Убедитесь, что OPC отправляет посылки на IP МКОН, на SlaveID: 16 dec (0x10 hex)
Именно такой адрес указан у вас в маршруте: 7:0:10:40:0:10:R
По умолчанию OPC используют в качестве SlaveID:1
Пакеты с таким адресом перенаправляются к собственным регистрам МКОН.
2) Убедитесь, что "режим порта RS-485" установлен в положение master
Вложение 48854
Мы специально не хотели грузить пользователей этой "азбукой" и поэтому сделали плагин, который должен помочь настроить МКОН автоматически.
Вложение 48855
Инструкция по работе с плагином доступна здесь -> https://owen.ru/product/mkon/documentation
В конце руководства по эксплуатации есть описание ручного способа настройки, через маршруты.
В помощь к освоению, могу дать вам такую памятку:
Вложение 48856
Вы правы, в плагине "Настроить шлюз" д.б. режим "Мастер в сети Ethernet - Slave RS485"
В "настройки режимов - режим порта RS485 - мастер"
Я бы рекомендовал еще "Настройки порта RS485 - Физ.режим порта RS485 - Физ.мастер" Некоторые устройства без подтягивающих резисторов категорически не работают. Ну и аккуратно перепроверить все параметры сетей. В маршрутизацию я не лазил, после настроек сетей и режима работы все работало. Правда недолго, если Вы читали предисторию.
Дело было именно в маршруте. С маршрутом 7:0G:40:0:S:R работает. Правда почему первая 7 так и не понял.
Прочел еще раз, а вот вы похоже конфигуратор не открывали никогда. Там режим именно так и называется как у меня выше написано https://cdn1.savepice.ru/uploads/202...f31f5-full.png
первая 7 - это маска физ. входов, с которых принимаются пакеты для этого маршрута, смотрите памятку
Так по этой памятке и не понятно "7 - резерв (UART)"
Вот теперь дошло. Спасибо!
Всю тему прочитать не осилил, прошу проконсультировать.
Можно ли с помощью МКОН сделать такую конфигурацию:
СП3хх расширенной версии подключен к МКОН по Modbus TCP (СП мастер), а МКОН подключен к одному ПР200 по Modbus RTU (МКОН мастер).
Для чего это нужно: во первых, возможно понадобится возможность подключения Скада по TCP, а во вторых хочу избавить СП от RS485.
Доброго дня. Подскажите, подойдёт ли МКОН, чтобы считывать и устанавливать параметры дискретных выходов ПР по ethernet через софт с Modbus TCP? Например node-red, или какой ещё.
Должно подойти
Хотел уточнить как дела с устранением проблем с зависанием, поднимавшихся в марте-апреле? Ни здесь ни на мою личную почту, по которой более предметно обсуждали этот вопрос, чтобы не будоражить форум, до сих пор никакой информации.
Да похоже никак не решана. МКОН получил 07.11.2020. Похожая ситуация, потеря связи на 5-6 секунд. Более подробно описал здесь https://owen.ru/forum/showthread.php?t=33963
Каково у Вас время ожидания ответа от прибора на мастере модбус TCP? Оно должно быть не менее 300 мс.
У шлюза тоже есть таймаут ожидания ответа по 485. И если таймаут мастера больше чем таймаут шлюза - то мастер будет рвать соединение и конектится снова.
У МКОН 2 сокета для соединения. И мастер, быстро перебирая эти соединения добьётся их "забития" пакетами.
Учитывая что 80% известных мне мастеров закрывают соединение криво, т.е. "честь" реально оборвать коннект достаётся шлюзу (таймаут при отсутствии обмена 5 секунд)
Вот и получается. У мастера слишком маленький таймаут. Модуль вроде успевает, но если вдруг он призадумается, то мастер не дожидается ответа, и сразу реконектит.
Шлюз ждёт ответ 300 мс.
Мастер реконектит и снова шлёт запрос. Шлюз ставит запрос (по 2-му сокету) в очередь, т.к. порт 485 занят ещё первым запросом.
Мастер и тут не дожидается ответа и снова реконектит.
А сокеты всё... Ждем 5 секунд на принудительный сброс соединения шлюзом.
Что делать:
1. Таймаут мастера не менее 300 мс
2. Мастер должен закрывать коннект полностью, а лучше не закрывать его сразу, а ждать нескольких запросов без ответа.
3. Мы запланировали работы по добавлению настраиваемого таймаута в МКОН.
Мы очень интенсивно и многосуточно тестировали МКОН с 2-мя мастерами по ТСП одновременно на стенде из 31 приборов на 485. В нагруженной офисной сети. И проблем с пропаданием связи не было зафиксировано.
НО! таймауты у мастеров были выставлены реалистичные, а не 10мс, как я видел на некоторых проектах.
В данном случае банальный вопрос, почему шлюз переключает сокеты от одного и того же мастера? где тут логика ?
Видя очередной запрос от того же самого устройства шлюз должен его просто игнорировать а не создавать новый сокет...
например мастер с IP 192.168.10.15 порт х, если второй запрос от него же, зачем создавать под него новый сокет ?
В качестве мастеров были ОВЕН и ИНСАТ ОРС-серверы. "Время ожидания ответа" (этот параметр?) были 300, 500 и 1000 мс с одинаковым отрицательным результатом. Честно сказать, сейчас спросил просто из любопытства, участвовать в тестировании и изучении оборудования, за которое, на секундочку, надо еще и платить деньги, никакого удовольствия.
Для себя я нашел решение, которое безотказно работает при тех же конфигурациях остального железа и софта, на которых МКОН виснет. Причем не приходится упражняться с выбором всевозможных параметров, а потом бояться, что на объекте через несколько минут-часов-дней это все зависнет. И даже если выставлял заведомо малые значения, оборудование не зависало, да, в этом случае были пропуски данных при некоторых запросах, но при следующем/следующих запросах обмен возобновлялся.
На этом по МКОН у меня всё.
Не путайте претензию с "поболтать" , пожалуйста . Вам же ответили про время ожидания ,про эксперименты с другим конвертером....
Филоненко Владислав разные порты, разные сокеты, не спорю, но когда запросы с одного порта, неужели МКОН у вас получился таким чахлым и тупым, что не может проверить запрос тот же, что и предыдущий и отдать уже готовый ответ, если он получил его от устройства, даже если мастер разрывал соединение ?
Вот опишите алгоритм идентификации пакета, пришедшего от разных соединений? Как прибор должен понять что это на самом деле попытка мастером опросить снова пакет, не полученный ранее? А не просто ещё один запрос, пусть по тому же адресу?
А если надо каждые 5 мс опрашивать - это повторы или уникальные запросы?
Вот именно, заплатил деньги. И не просто за корпус с микросхемами. А за отсутствие проблем.
Логи.... Понимаете ли. Люди часто имеют дело с прибором не в лаборатории. И регулярно даже не на СВОЕМ (в смысле работы) производстве. А на стороннем. Или своем, но где эксперименты производить скажем так, не желательно, по техническим причинам. И получив некоторые проблемы - проще сменить прибор. Иногда и производителя.
А что там описывать? вы знаете с какого IP и на какой порт пришел запрос, если у вас сквозной преобразователь протокола из TCP сети в RTU так сложно запомнить на какой адрес устройства и какие регистры запрашиваются и в каком количестве ?
Честно не сталкивался с преобразователями протоколов на лету, обычно железка сама настраивается на чтение регистров slave RTU устройств и предоставляет регистры для TCP, а там хоть пять подключений, это не мешает забирать данные, потому что сама железка читает slave со своим периодом, а ее опрашивают со своим и эти периоды никак не пересекаются.
Вы же сделали что-то уникальное и тестировали только на OPC, а с двух ПЛК тестировали?, а с двух ПЛК стороннего производителя тестировали ? Или подобные тесты отдали на откуп клиентам ?
Только вот само RTU устройство не умеет работать с двумя мастерами, если нет разграничения во времени. А так то да, Ethernet-RS485 с TCP сервером так же на лету работают, если на ПК либо виртуальный COM порт, либо ПО может работать с портом сразу поверх TCP. Проблемы конечного устройства это не отменяет. Но тут то заявлено, что мы обращаемся именно по Modbus TCP, шлюз преобразует в RTU и отдает обратно в Modbus TCP...
У меня есть одна железка подобного рода, но руки не доходят потестить именно таким образом, чтобы ее двое опрашивали, посмотреть что из этого получится.
Или устройство преобразователь (и тогда он НЕ ДОЛЖЕН трактовать/оптимизировать пакеты по модбас, это дело мастера), а тем более рассматривать 2 соединения с одного IP как одно!
Либо это коуплер, сам опрашивающий устройства и видимый во внешней сети как slave сразу по множеству адресов.
Во втором случаем можно играться с анализом и т.п. оптимизациями, т.к. уж в своём собственном ответе устройство уверено.
Простите, а кто в здравом уме будет настраивать опрос двумя мастерами с одного ПК ? этот режим как раз для разных мастеров с разными адресами.
И на прошлой странице вы кажется неправильно выразились, ранее писали, что у мастера таймаут должен быть заведомо больше двух опросов, так как МКОН ставит в очередь запрос, если в этот момент идет опрос другим мастером.
О, бывает и так. основной процесс управления и визуализация.
Таймаут должен быль более времени ожидания ответа шлюзом. Если же 2 мастера посылают пакеты так часто, что их переварить 485 не может - тут никакие таймауты не помогут...
Речь то идет не о обычном времени ответа модуля, а о максимальном.