Просмотр полной версии : Ооооочень медленный МВ110-8А
День добрый!
Использую ПЛК110-60 + МВ110-8А + МУ110-8И + МЭ110-1Т + МЭ110-1Т, связь под ModBus.
Проблема в получении данных от датчиков через МВ110-8А. Подключены всего 8 датчиков, из них 4 ТСМ-50М и 4 ОВЕНовские преобразователи давления, 4..20 мА выход. К нечетным подключены ТС, по трехпроводной схеме, к четным ПД. Время опроса установлено на 0,5 сек на каждый вход. Скорость по ModBus 115200. В принципе все здорово, показания есть, но... Значения температур и давления обновляются в лучшем случае раз в ~5 сек, а обычно раз в ~15 сек. В худшем случае более 30 сек, сколько точнее не углядел, т.к. ну никак не рассчитывал на такое безобразие и таймер в проге добавленный для подсчета обновления данных установил на 30 сек. При этом данные по току от МЭ110-1Т обновляются со скоростью 1-2 раза в секунду.
Есть идеи от чего такое происходит и как от этого избавиться? Буду признателен, а то сроки по сдаче установки и так уже сорваны.
Александр Приходько
09.08.2013, 08:24
Добрый день. Вероятнее всего у Вас некорректно настроен обмен между модулями. В результате приборы опрашиваются с большой периодичностью.
Есть еще один нюанс. Аналоговые входы опрашиваются последовательно. поэтому все данные обновляются на этом модуле с периодом (время опроса 1 канала) * (кол-во задействованных каналов)
Добрый день. Вероятнее всего у Вас некорректно настроен обмен между модулями. В результате приборы опрашиваются с большой периодичностью.
Есть еще один нюанс. Аналоговые входы опрашиваются последовательно. поэтому все данные обновляются на этом модуле с периодом (время опроса 1 канала) * (кол-во задействованных каналов)
А что именно может быть настроено некорректно? Остальные приборы в той же сети, и с ними ведь все хорошо. Задержка ответа 2 мс. Остальные параметры связи такие же как и на других приборах.
Каждый канал на 0.5 сек настроен, т.е. все данные должны обновиться максимум за 4 сек. Но получается гораздо дольше, и время это постоянно меняется.
Здравствуйте, Туман.
Использую ПЛК110-60 + МВ110-8А + МУ110-8И + МЭ110-1Т + МЭ110-1Т, связь под ModBus.
Проблема в получении данных от датчиков через МВ110-8А. Подключены всего 8 датчиков, из них 4 ТСМ-50М и 4 ОВЕНовские преобразователи давления, 4..20 мА выход. К нечетным подключены ТС, по трехпроводной схеме, к четным ПД. Время опроса установлено на 0,5 сек на каждый вход. Скорость по ModBus 115200. В принципе все здорово, показания есть, но... Значения температур и давления обновляются в лучшем случае раз в ~5 сек, а обычно раз в ~15 сек. В худшем случае более 30 сек, сколько точнее не углядел, т.к. ну никак не рассчитывал на такое безобразие и таймер в проге добавленный для подсчета обновления данных установил на 30 сек. При этом данные по току от МЭ110-1Т обновляются со скоростью 1-2 раза в секунду.
Есть идеи от чего такое происходит и как от этого избавиться? Буду признателен, а то сроки по сдаче установки и так уже сорваны.
Для начала в ПЛК-конфигурации добавьте модуль "statistic" и установите минимальный цикл (по умолчанию 1 мс) таким что бы значение параметра "Free processor resourse mks in 1 cycle" было примерно равно паре миллисекунд.
Так же есть возможность вести опрос с помощью библиотеки modbus.lib - это если время периода опроса очень критично.
P. S. Если время периода опроса не критично (можно увеличить на 20-40%), перейдите на протокол ОВЕН выше указанных проблем не будет.
Проблема судя по всему именно в самих МВ110-8А. Сегодня взял новые 8А и 8АС и тестировал как мог. Результаты идентичные для обоих 8А. При протоколе ModBus данные передаются в контроллер неприемлемо медленно. Минимум ~5 сек, в среднем 15-20 сек, бывали случаи и по >100 сек. Отключение датчиков через конфигуратор ситуацию не меняло, с 2-мя датчиками 4..20 мА было то же самое. При это если смотреть через конфигуратор напрямую, то значения обновляются быстрее. Хотя тоже долго, 2 датчика 4..20 мА, время опроса 0,3 сек, минимальное время изменения значения 2 сек, максимально 6 сек, в среднем 4 сек. Немного ситуацию с передачей данных по ModBus улучшило отключение двух МЭ110-1Т. Хотя не сильно заметно, просто время обновления в 5 сек стало проскакивать не в 10% случаев а в 30% (примерно).
При этом опрос тех же датчиков через 8АС по ModBus показал при 1-ом датчике ~0,6 сек с редкими вылетами на 1,5 сек. 4-ех - 1,5 сек обновления всех переменных с редкими вылетами до 3-4 сек. С МЭ110-1Т тоже все хорошо, 0,5-1 сек время обновления переменных по ModBus.
Переход на протокол ОВЕН ситуацию изменил в корне. Проверил только на двух датчиках 4..20 мА, но в основном переменные обновлялись за 0,7 сек.
В общем, надо написать в инструкции к 8А, что б не опрашивали с помощью ModBus :) Ну или это я умудрился создать уникальные условия где именно этот модуль не работает как надо или еще где-то что-то нагородил.
Рад, что у Вас есть возможность перейти на протокол ОВЕН и результат Вас устроил.
В общем, надо написать в инструкции к 8А, что б не опрашивали с помощью ModBus :) Ну или это я умудрился создать уникальные условия где именно этот модуль не работает как надо или еще где-то что-то нагородил.
К большому сожалению, если опрашивать модули ввода аналоговые с использованием ПЛК-конфигурации, то выше указанные проблемы это норма :-( лично мое мнение :-).
Если опрашивать один единственный модуль аналогового ввода на шине RS485, то проблем нет.
P. S. Аналогичные проблемы у меня были с МВА8, МВ110-2А, МВ110-1Т. С другими модулями сразу опрашивал по протоколу ОВЕН и наверное по этому ни каких проблем не замечал.
Sergey666
10.08.2013, 11:06
В общем, надо написать в инструкции к 8А, что б не опрашивали с помощью ModBus :) Ну или это я умудрился создать уникальные условия где именно этот модуль не работает как надо или еще где-то что-то нагородил.
True !
Хотя что можно нагородить ?
Хорошо , что прибор несколько протоколов поддерживает.
Но я бы не стал говорить , что какой-то из них быстрее , так как физически они идентичны и разницы по скорости особой дать не могут (прям чтобы в 2 раза)
Здравствуйте, Сергей.
Хорошо , что прибор несколько протоколов поддерживает.
Но я бы не стал говорить , что какой-то из них быстрее , так как физически они идентичны и разницы по скорости особой дать не могут (прям чтобы в 2 раза)
Разницу в скорости видно если снифером посмотреть длины пакетов для разных протоколов. Например запрос измеренного значения МВА8 см. вложение:-)
Так что скорость действительно разная и отличается заметно.
True !
Хотя что можно нагородить ?
Хорошо , что прибор несколько протоколов поддерживает.
Но я бы не стал говорить , что какой-то из них быстрее , так как физически они идентичны и разницы по скорости особой дать не могут (прям чтобы в 2 раза)
А я не просто так стал это говорить. А после того как добавил в программу таймер, который показывал сколько прошло времени с момента изменения переменной, которой присваивается значения регистра. При это физически значение менялось быстро. за 5 сек с 6,6 Bar до 13,5 Bar. датчик 0-40 Bar. Но новое значение в переменной я получал именно через те 15 и больше секунд.
Рад, что у Вас есть возможность перейти на протокол ОВЕН и результат Вас устроил.
К большому сожалению, если опрашивать модули ввода аналоговые с использованием ПЛК-конфигурации, то выше указанные проблемы это норма :-( лично мое мнение :-).
Если опрашивать один единственный модуль аналогового ввода на шине RS485, то проблем нет.
P. S. Аналогичные проблемы у меня были с МВА8, МВ110-2А, МВ110-1Т. С другими модулями сразу опрашивал по протоколу ОВЕН и наверное по этому ни каких проблем не замечал.
Да, программа небольшая, так что сейчас все перепишу под ОВЕН, хорошо, что на маленьком проекте вылезло такое :)
Разница в скорости между 8А и 8АС здесь - 80раз. На одинаковое кол-во включенных входов. Курим РЭ. Но! Это относится к времени обновления показаний входов непосредственно на модулях.
У чела на 8А включены все 8 Ai (4-20) - и цикл обновления показаний на Ai около 3.2с. Собсно опрашивать чаще - нет большого смысла.
Шо там с конфигуратором - не знаю, т.к. syslibcom - позволяет следующее:
Из имеющихся протоколов на 8А самый быстрый - мбRTU, и невыходя за период опроса в 3.2с кол-во МВА8 которое можно опрашивать не напрягаясь - штук так 50..60. Получая информацию по ЛЮБОМУ из 400..480 входов. При цикле ПЛК в 1мс.
Плакания про медленные слейвы смешны, если учесть что рулит - мастер. А это вообще-то ПЛК и его конфигуратор.
Разница в скорости между 8А и 8АС здесь - 80раз. (восемьдесят). На одинаковое кол-во включенных входов. Курим РЭ. Но! Это относится к времени обновления показаний входов непосредственно на модулях.
У чела на 8А включены все 8 Ai (4-20) - и цикл обновления показаний на Ai около 3.2с. Собсно опрашивать чаще - нет большого смысла (ниже)). Тоже самое с 8АС - 40мс.
Теперь по модбас.
Шо там с конфигуратором - не знаю, т.к. syslibcom - позволяет следующее:
Из имеющихся протоколов на 8А самый быстрый - мбRTU, и невыходя за период опроса в 3.2с кол-во МВА8 которое можно опрашивать не напрягаясь - штук так 50..60. При этом получая ВСЮ* информацию по ЛЮБОМУ из 400..480 входов (почти пицот). И это - не выходя за пределы цикла ПЛК в 1(одну) мс.
Тоже самое для 8АС - существенно меньше, но всего лишь из-за превышения цикла сетевого опроса над циклом обновления самих входов - чуть меньше 2х штук 8АС (16 входов). С периодом сетевого опроса 40мс.
*ВСЯ информация это : real-значение, int-значение с колвом цифр после точки циклическая метка и статус для МВА8, real-значение, циклическая метка и статус для 8АС.
Плакания про медленные слейвы смешны, если учесть что рулит - мастер. А это вообще-то ПЛК и его конфигуратор.
И как эта информация поможет в решении проблемы?
А насчет времени опроса 8А, я ж указал, что при включенных 2-ух датчиках (через конфигуратор - "Датчик отключен" для 6-ти входов) ситуация не изменилась.
И как эта информация поможет в решении проблемы?.
А никак. Просто информация для снятия ненужных вопросов и заблуждений.
Отключение датчиков (через конфиг МВА8) не приведет ни к чему если в мастере не удалили не нужные модули опроса.
А что касается сути - выложите хотя бы конфигурацию в исходном виде а не скриншот кокого-то кусочка. (сикретный код можно удалить).
А никак. Просто информация для снятия ненужных вопросов и заблуждений.
Отключение датчиков (через конфиг МВА8) не приведет ни к чему если в мастере не удалили не нужные модули опроса.
А что касается сути, наиболее правильное поведение у проктолога - стать раком, а не рассказывать про "тут болит, тут не болит".
Выложите хотя бы конфигурацию в исходном виде а не скриншот кокого-то кусочка. (сикретный код можно удалить).
Опросы так же были удалены из Конфигурации ПЛК. Окей, выложу.
Здравствуйте, многоуважаемый Валенок.
И как эта информация поможет в решении проблемы?
А никак. Просто информация для снятия ненужных вопросов и заблуждений.
Ну как же не как :D?! Ведь было описано применение библиотеки модбас.либ которая тоже позволяет решить проблему связи. Правда с большими (ударение на первый слог) интеллектуальными затратами, чем протокол ОВЕН в ПЛК-конфигурации.
Остановимся на фактах: при переходе опроса МВ110-8А в ПЛК-конфигурации с протокола модбас-рту на протокол ОВЕН все начинает работать заметно лучше.
Проблема не с оцифровкой, а со СЧИТЫВАНИЕМ значений параметров по протоколу модбас-рту при использовании ПЛК-конфигурации.
Тут опрашиваются два модуля МЭ110-1Т и на видео однозначно видно, что модули ведут себя неадекватно.
Видео предоставлял сотрудникам ОВЕН, а воз и ныне там :-( насколько я понимаю такие проблемы у всех модулей ввода аналогового сигнала от ОВЕН.
Здраствуйте, многоуважаемый Gans.
Ведь было описано применение библиотеки модбас.либ.
Уточю - syslibcom :) Но и c modbus - около того. Решит автор проблему на протоколе Овен через конфирурацию - и слава богу.
Правда с большими (ударение на первый слог) интеллектуальными затратами, чем протокол ОВЕН в ПЛК-конфигурации.
Ну это - вопрос. Затраты были когда-то. Сейчас по сути - таже конфигурация. Ну может на пару минут больше написание.
Остановимся на фактах: при переходе опроса МВ110-8А в ПЛК-конфигурации с протокола модбас-рту на протокол ОВЕН все начинает работать заметно лучше
Не буду спорить - ведь конфигурацию-мастер не юзаю. Отмечу лишь - заметно лучше или просто отлично на протоколе Овен это не совсем максимально возможная скорость при одинаковой надежности.
Проблема не с оцифровкой, а со СЧИТЫВАНИЕМ значений параметров по протоколу модбас-рту при использовании ПЛК-конфигурации.
Ну она (конфигурация) конечно работает. Просто тоже требует интелектуальных усилий в некоторых случаях.
насколько я понимаю такие проблемы у всех модулей ввода аналогового сигнала от ОВЕН.
Касаемо МВА8, 8А, 2А, 8АС, 2АС. Проблем не имею. Проверено. Все на RTU. МЭ110 - не держал в руках, видео вроде показывает траблы, но живой модуль все же не отказался бы пощупать. Да и у автора проблемы вроде с МВА8 а не с МЭ.
А что касается сути - выложите хотя бы конфигурацию в исходном виде а не скриншот кокого-то кусочка.
Вот изначальный проект которым я уже тестил, удалив все блоки и оставив только вход/выход.
Здравствуйте, Туман.
Вот изначальный проект которым я уже тестил, удалив все блоки и оставив только вход/выход.
Добавьте в ПЛК-конфигурацию модуль "button" и "Statistic".
Подскажите откуда такие странные адреса слэйвов? Представители ОВЕН рекомендовали использовать адреса кратные 8.
Данный пост верен и для протокола ОВЕН :-)
Здравствуйте, Туман.
Добавьте в ПЛК-конфигурацию модуль "button" и "Statistic".
Подскажите откуда такие странные адреса слэйвов? Представители ОВЕН рекомендовали использовать адреса кратные 8.
Данный пост верен и для протокола ОВЕН :-)
Я так понял, что кратность 8 это для удобства, т.к. многие модули содержат 8 входов или выходов, хотя могу и ошибаться. Все данные все равно содержатся в табличках Excel, так что просто по порядку все адресовал. И вопрос тогда насчет этого момента, для протокола ОВЕН все понятно, каждый вход/выход имеет свой адрес. А при Modbus? Нам ведь нужен только базовый адрес, дальше все через регистры. Тогда получается, что в Modbus можно опрашивать все входы МВА8 (к примеру) с адресом 1 и следующему модулю давать адрес 2?
А насчет медленного МВ110-8А я разобрался. В общем это я балбес. Т.к. раньше не работал с модулями Мх110 и связью по ModBus/ОВЕН, то кое-что изначально неверно понял. Работает он нормально, хоть и все равно для моей задачи неприемлемо медленно, пришлось добавить МВ110-8АС. А 30-40 сек опроса получил, т.к. исходил из ошибочной предпосылки что измеренное значение обновляется за минимально возможное время, т.к. оно в виде float с 5 знаками после запятой. И значит, подумал я, каждый раз оно будет разное, как минимум из-за погрешности измерения. Оказалось что нет, т.к. и на протоколе ОВЕН я получил эти 30-40 сек между обновлением измерения. А вот между изменением значения Circular time я получил стабильно 4-6 сек при 4 ДТС и 4 4..20 мА, правда на протоколе ОВЕН. Когда понял свою ошибку, все было переписано на ОВЕН, экспериментировать желания уже не было.
Если используется ПЛК-конфигурация стабильность/потерю связи можно оценить используя значения "ласт еррор" и "ласт адрес" (ПЛК-конфигурации)
Потерю связи с конкретным модулем идентифицирую обычно так (http://www.owen.ru/forum/showthread.php?t=1958)
P. S. Если есть возможность использовать протокол ОВЕН используйте его - ни разу проблем с ним не было.
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot