Естественно, понимаю.
Уберите у Сименса возможность постоянной перекредитовки==заведомо невозвратных кредитов - он банкрот.
Вид для печати
Естественно, понимаю.
Уберите у Сименса возможность постоянной перекредитовки==заведомо невозвратных кредитов - он банкрот.
Ребята, давайте тему кредитов у Дяди Сёмы обсуждать в курилке.
Кредиты можно и нужно обсуждать в курилке.
Но то,что первые задачи у ОВЕНа при разработке - экономические - это четко видно.
Типа, НИОКР будет стОить примерно столько, себестоимость изделия должна быть не выше того, продадим за... примерно столько...
Отсюда и сроки и качество разработки (тестирование у вас весьма посредственное), порой и изгототовления.
Понимаю и не осуждаю.
Ты читаешь финансовую отчетность Siemens, тебе известны ее мультипликаторы ?Цитата:
Сообщение от ASo
Ещё раз повторяю - все свои обсуждения по поводу тем, не относящихся к теме топика, ведём в курилке, либо в ЛС.Цитата:
Сообщение от IVM
Подскажите, модуль вывода 210-411, в конфигураторе читаеться и управляеться (попробовал порулить выходом D0), все клемы СОМ посадил на минус, все 3 клемы U+ на плюс. В результате индикация выходов с 1по 8 и с 10 по 12 и 22 потухла и готова к работе (как я понимаю), а выход 9 и 13-21 продолжают гореть красным.Что не так?Вложение 54530Вложение 54531Вложение 54532
Подскажите, какой режим работы ключей установлен на выходах с красными светодиодами?Цитата:
Сообщение от дрю
В РЭ на модуль на стр. 39 описаны неисправности при которых светится красный светодиод.
Иван, добрый день. Все проглядел на вкладке ,,Отслеживания параметров но Вложение 54580 строку "режим работы выхода" не увидил,ткните пожалуста. В инструкции написано следоющее ,,для выбора режима и его настройки следует записать нужные значения в соответствующие Modbus
регистры (см. раздел ).,, Вложение 54581 но ни указателя на раздел ни как это сделать ни написано. И как в этом разобраться. На видио по конфигурированию модуля тоже ничего нет по настройке выходов.
Так ребята, разобрался где настройка выходов, показываю если кто то не увидит как я не видил их 2 дня Вложение 54588 нажать этот треугольник, откроется вкладка Вложение 54589 Ну вот вообщем и всё
Нашел просто тыкая мышкой, не нашёл нигде инструкции на этот счет. Проблему с модулем на данном этапе решил.
Здравствуйте! На вебинаре анонсировали модуль ввода тензодатчиков. Подскажите, пожалуйста, когда планируется релиз?
Здравствуйте!Цитата:
Сообщение от _Pavel_
I кв. 2022г.
Добрый день!) Неожиданно столкнулся с проблемой подбора оборудования для замены сгоревшего. Оказалось что серия 210, а точнее МВ210-101 не поддерживает сигнал 0-10В. Вопрос, будет поддерживать, а то как то не вяжется с названием "Универсальные аналоговые входы" ?
Удалось ли кому-нибудь решить проблему с зависаниями модулей? Столкнулся с аналогичными зависаниями, управляю контактором 220 В с первого выхода модуля МУ210-402.
Дежурные команды отправляю на модуль каждые 10 с, реально контактор включаю раз в полчаса на 3 минуты. При диагностике сети WireShark'ом было замечено что при зависании модуль спамит в сеть Pause-пакетами Flow Control с максимальным запрашиваемым таймаутом. Т.е. фактически модуль просит всех "помолчать" и делает это постоянно. Это приводит к фактическому падению всего сегмента сети, где находится модуль. Пока что отключил на роутере функцию Flow Control для того порта, который смотрит в сторону модуля, но это ж жесть!
Интересно!Цитата:
Сообщение от Maxim_12
Я все темы мониторю, по свободному времени будем перехоить на Мх110.
Интересно, зачем модуль так делает.. и можно ли в прошивке это поправить!
Добрый день.Цитата:
Сообщение от Maxim_12
Какая версия ПО у Вас в модуле?
У меня после зависания обмена одни ARP запросы от модуля в сети летают.
Три дня назад (12.05.2021) обновил версию МУ210-402 до актуальной по совету техподдержки. Т.е. сейчас версия 1.0. Причём обновлять пришлось по USB, Ethernet-обновление всё время заканчивалось ошибкой (модуль начинал мигать красным уже через 15-20 секунд после начала прогрузки прошивки). До обновления прошивки конфигуратор OWEN не мог даже считать "Информацию об устройстве" - выдавал ошибку. В моих условиях модуль зависает каждую неделю-две, пока наблюдаю за ним после перепрошивки. На новой прошивке "Информация об устройстве" конфигуратором считывается, но осталось два вопроса по ответам модуля на некоторые Modbus команды. Вы не могли бы прокомментировать?Цитата:
Сообщение от e.filatov
Код:Версия встроенного ПО прибора:
00 01 00 00 00 06 01 03 F0 10 00 01
00 01 00 00 00 05 01 03 02 2E 31 // .1
Название платформы:
00 01 00 00 00 06 01 03 F0 20 00 01
00 01 00 00 00 05 01 03 02 46 47 // FG
Версия платформы:
00 01 00 00 00 06 01 03 F0 30 00 01
00 01 00 00 00 05 01 03 02 2E 34 // .4
Версия аппаратного обеспечения:
00 01 00 00 00 06 01 03 F0 40 00 01
00 01 00 00 00 05 01 03 02 57 48 // WH
Время и дата:
00 01 00 00 00 06 01 03 F0 80 00 01
00 01 00 00 00 03 01 83 02 // Error! А по факту RTC работают, конфигуратор OWEN прекрасно отображает время. Отлавливать запросы конфигуратора WireShark'ом времени пока нет.
Часовой пояс:
00 01 00 00 00 06 01 03 F0 82 00 01
00 01 00 00 00 05 01 03 02 00 00
Заводской номер прибора:
00 01 00 00 00 06 01 03 F0 84 00 01
00 01 00 00 00 05 01 03 02 37 38 // Тут показывают "37 38", а конфигуратор OWEN показывает "87076200232044494". Почему так?
1. Время и дата занимают два регистра, и в запросе надо считывать сразу оба (а не один, как у вас).
2. 0x37 0x38 - это ASCII-коды символов "7" и "8" (т.е. это первые две цифры серийника со свапнутым порядком байт).
Вложение 55095 документация однозначно говорит сколько байт надо принятьЦитата:
Сообщение от Maxim_12
И, если позволите, вопрос по МУ210-101 (прошивка 1.0). Модуль только куплен, работает несколько дней, к нему ничего не подключалось и сейчас не подключено. Однако он не отдаёт float-значение ни одного из 8 входов. При этом integer-значения отдаёт. Пробовал команду чтения 03 и 04 - поведение одинаковое.
Код:Чтение значения (float) на входе 1:
00 01 00 00 00 06 01 03 0F A0 00 01
00 01 00 00 00 03 01 83 02 // Error! Почему?? Модуль уже пару дней как работает, 41 с (см. ниже) много раз прошла.
Циклическое время измерения входа 1:
00 01 00 00 00 06 01 03 0F A2 00 01
00 01 00 00 00 05 01 03 02 A1 11 // "A1 11" == 41 233 мс.
Чтение значения (integer) на входе 1:
00 01 00 00 00 06 01 03 0F E0 00 01
00 01 00 00 00 05 01 03 02 00 00 // Ответ "00 00". Вроде нормально выглядит.
Опять-таки, float занимает два регистра, а вы запрашиваете один.
Спасибо за помощь! С запросом кол-ва регистров разобрался, а со свапом особенно порадовал 0x0, приходящийся не на конец строки если не знать про свап :)
Остаётся неделю-другую понаблюдать за поведением МУ210-402.
Да, и если кому-то вдруг интересно - вот логи Wireshark в момент глюка (где летят Flow Control пакеты) и после перезагрузки модуля (т.е. уже в нормальном режиме).
Добрый день.Цитата:
Сообщение от Maxim_12
Как раз разбираемся с зависанием обмена по Ethernet при комутации нагрузки.
Спасибо за лог.
Прошло 8 дней после обновления МУ210-402 до прошивки v1.0. Это примерно 400 коммутаций напряжения 220 В на порту №1 (к модулю подключен контактор, запускающий оборудование). Модуль опять завис, но на этот раз в сеть он уже ничего не вещал. На всякий случай прикладываю логи WireShark, но там ничего интересного нет.
Сеть через себя модуль не передаёт (по схеме "ПК <-> МУ210-402 <-> другой_модуль"), но в качестве оконечного устройства никому в сети не мешает (по схеме "ПК <-> другой_модуль <-> МУ210-402").
Уже не первый год прошу сделать так что-бы модули можно было конфигурировать удаленно OwenConfigurator. Настройку с таймаутом связи в конфигуратор добавили, но связь от этого не появилась. Wireshark показывает что модуль отправляет пустые пакеты в ответ. Причем пинг идет нормально, ПЛК210 без проблем программируется но вот модули МВ210 в конфигураторе не открыть.
Вложение 55328
https://disk.yandex.ru/d/XSpce7uJYPFcew
1. Обмен идет с мастером, пакеты в ответ ну совсем не пустые.Цитата:
Сообщение от RV9WFJ
2. У Вас одновременно несколько соединений открыто, зачем, не попробовать ли для тестов с одним соединением за раз?
3. Откуда то ретрансмиты, либо ответы не доходят до получателя, либо где-то есть петля? Какова конфигурация сети? При этом наблюдаются склеивания пакетов при ретрансмите - что невозможно при аппаратной проблеме - склеить их может только мастер (стек IP мастера). Сколько ОДНОВРЕМЕННО запросов генерирует мастер к одному slave? Должен быть ТОЛЬКО ОДИН запрос, а видно что их минимум два.
4. Связь рвёт мастер - хотя в логе есть вполне ликвидные ответы.
5. Надо поиграться с настройками VPN - в частности периодом ретрансмита (поставить несколько секунд до первой попытки), временем жизни пакета (поставить не более заданного в мастере таймаута ожидания ответа)
Мастер в данном случае OwenConfigurator. Вот и мне интересно почему мастер так себя ведет.
Петля естественно есть - вы же сами предлагаете Мх210 к ПЛК210 петлей цеплять
ПЛК210 сам определяет по STP наличие петли и 2-й конец "ставит в резерв".Цитата:
Сообщение от RV9WFJ
Посмотрите настройки таймаутов тоннеля.
Что-то я не знаю что такое "настройки таймаутов" в OpenVPN, подскажите что это. По вашей логике вся проблема в тоннеле. Но почему тогда пинг на тот же МВ210 нормально проходит. И более того Lectus по тому же протоколу вполне себе его опрашивает?
Не могу подсказать, совсем не в теме. Единственно наш конфигуратор, почуяв ethernet, очень агрессивен в опросе. И возможно это "забивает" канал?Цитата:
Сообщение от RV9WFJ
Посмотрел настройки openVPN - можно считать их нету :) Другие VPN побовали?
Вот это похоже на правду. Это я и пытаюсь донести, что хорошо бы какие-то настройки добавить чтобы в тормозных сетях можно было с ним работать. А то приходится через ПЛК модули программировать.
Ошибка МУ210-402 проявилась вновь. Теперь в виде обрыва связи с модулем, стоящим за ним дальше в цепочке. Сам же МУ210-402 при этом формально работает, лишь Owen Configurator выдаёт ошибку при попытке получить "Информацию об устройстве". Между тем чтение значений (как конфигуратором, так и через свой софт) происходит нормально. Ошибка снялась лишь перезагрузкой по питанию.
Всё это время модуль единственным первым портом коммутирует катушку контактора IEK КМИ-23210 (по заявлениям IEK мощность потребления катушки в момент срабатывания 90 ВА (cosf=0,75), при удержании 7,5 ВА (cosf=0,3)).
Если забыть про опыты Cs-Cs с коммутацией щадящей низковольтной слаботочной нагрузки, где глюков не происходит, то проблема выглядит как неаккуратная работа с указателями в прошивке.
Maxim_12 Ишь как всё интересно!! А что может указывать на ошибку работы с указателями?
У меня у одного заказчика, пока мы ПЛК прогали, модуль зависал (отваливался и уходил в аварию связи) тогда, когда на модуле были включены выходы, а мы перезапускали ПЛК, ПЛК не опрашивал модули, и его выходы все разом отключались. На них стояли реле на +24V DC.
Добрый день.Цитата:
Сообщение от Maxim_12
Нет, указатели там непричём. Проблему воспроизвели (спасибо Cs-Cs за марку реле на которых повторяемость 99.9%). При коммутации катушки, помеха влияет непосредственно на PHY микросхему. И та, в свою очередь, переходит в Z состояние, при котором линк виден, auto-negotiation отрабатывает корректно, пакеты "от прибора" идут корректно, "к прибору" не доходят. При всём этом, если без перезагрузки прибора (читай прошивки) сделать hardware-reset PHY-ки (прямо пин на ноль подтянуть), то всё "поднимается" корректно.
Сейчас прорабатываем вопрос, как анализировать "непредвиденный сбой" и корректно восстанавливать обмен.
А для начала - советую зашунтировать RC-цепями все индуктивные нагрузки, даже очень небольшого номинала
e.filatov Во! Наконец-то есть инфа! Ура!
Это уже какой-то аналог NetPing получается... были такие устройства, которые пинговали сеть и, если пинги не ходили - релюшкой передёргивали питание роутера.
За реле - не за что! Пользуйтесь на здоровье! =)
А мы все (я и мои заказчики и моя тусовка на блоге) будем ждать результатов.
Cs-Cs Подозрение на работу с указателями возникло вследствие очень разных проявлений глюка. Так обычно бывает когда процессор попадает в рандомное место памяти и начинает исполнять непонятно что. Однако e.filatov уже всё объяснил.
e.filatov Снабберы уже в пути, однако прошу учесть что глюк проявлялся и в отсылке модулем Flow control пакетов. Хотя, в принципе, это укладывается в сценарий с подвисшей PHY-микросхемой, начавшей жить своей жизнью.
Правильно ли я понимаю что HW-reset PHY-микросхемы и/или защита её от наводок будет реализована лишь в следующей аппаратной ревизии?
Если возможно решить вопрос лишь софтверно - очень хотелось бы попробовать новую версию прошивки. Боевое тестирование, так сказать.
Если же всё упрётся в обновление аппаратной части то, боюсь, придётся серьёзно подумать о дальнейшем закупе модулей от ОВЕН. Техподдержка на просьбу решить вопрос (обменом на 1 либо 2 модуля МУ210-401 с доплатой с моей стороны) посоветовала отправить модуль в сервис.
Maxim_12 HW reset уже поддержан на аппаратном уровне. Вопрос только в определении сценария, при котором необходимо восстанавливать связь.
Сейчас тестируем 3 сценария, определяем, какой из них более быстрый и надёжный, т.к. всё упирается в RSTP.
Про защиту PHY от наводок - она и так защищена на требуемый по стандартам уровень. Вопрос только в том, что эти уровни, всего лишь цифры на бумаге, а в реальной жизни пользователям важны совсем другие уровни помехоустойчивости.
Про действия тех.поддержки ничего сказать не могу, т.к. не имею к ней никакого отношения и/или влияния.
P.S. 401-й модуль хоть и лучше выдерживает помехи, но и его мы научились "завешивать". Вопрос только в уровнях воздействия.
Кувалдой можно и наковальню перегрузить. Так что RS цепочки всегда и везде!
Будут ли в обозримом будущем RS цепочки интегрированы в модуль?Цитата:
Сообщение от Филоненко Владислав