А что за модули такие?
Овеновские МВ110 можно читать намного быстрее
Вид для печати
А что за модули такие?
Овеновские МВ110 можно читать намного быстрее
Эти ---------->Цитата:
Сообщение от kondor3000
Цитата:
Сообщение от FPavel
Понятно, видел но не пользовал, цена и исполнение (в плане опроса как оказалось) не адекватные.Цитата:
Сообщение от FPavel
На самом деле - исполнение очень адекватное - в узком модуле 8 каналов AI - очень плотно. Ко всему - исполнение Ex - искробезопасное.
Как объяснял проектировщик, альтернативы ему нет - по проекту нужно обязательно исполнение Ex и 18 модулей разместить во взрывобезопасном шкафу - это толстостенная конструкция с тяжёлым круглым люком на резьбе (диаметр люка около 500 мм) - в нём едва уместились эти модули.
Вернее, альтернатива, конечно, существует, но несоизмеримо дороже и габаритнее - эту альтернативу и вынуждены были применить.
Но эти решения уже за пределами моей компетенции, не всё понимаю и доверяю проектировщику на слово.
Все решения приняты и ок
Просто не совсем понял это
Цитата:
Сама проблема оказалась в модулях ввода - для одного модуля опрос значений измерений показаний 8 термопар занимал 15 мс (одним запросом), а опрос достоверности измерений (обрывов) 8 термопар занимал 8х200мс=1600мс (8 запросов - одним запросом невозможно согласно РЭ на модуль и по результатам эксперимента).
Таким образом, для 8 модулей ввода оказалось, что период обновления показаний составляет 8х1600мс=12800мс=12,8с и это не удовлетворяет требованиям ТЗ.
8 x (1 + 8) это 72. 12800/72 это 178мс на 1 запрос. А почему так много? Или я что-то не понял?Цитата:
8 модулей ввода-вывода, для опроса каждого требуется сделать по 9 запросов (1 для восьми измеренных значений и ещё 8 для восьми регистров качества измерений)
Почему нужно опрашивать по схеме "1 + 8"? Это строго конфигурация? Другие варианты невозможны?
Здесь "8х1600мс=12800мс=12,8с" - подразумевается что обновления на самих модулях как взаимосвязано. А как если они независимые?
Пока понял что есть некие 8 измерений которые можно получить 1 запросом. И у них обновления в модуле - 15мс.
И есть некие 8 статусов к измерениям которые нельзя получить 1 запросом. И их обновление в модуле 200мс и последовательное по 8 каналам.
И таких 8 модулей
Тема создавалась для получения совета по выбору программ анализа обмена Modbus.
В ходе работ такие программы нашёл и поделился их названиями и ссылками, способами использования - может быть кому-то пригодятся.
Исходная наблюдаемая проблема заключалась в том, что при ошибке обмена с модулем это состояние ошибки длилось по ~12 секунд. Причины были непонятны, т.к. время полного опроса одного модуля оценивалось в 0,100-0,150 секунд, а всех модулей ~1,5 секунд.Цитата:
Сообщение от Валенок
На протяжении этих 12 секунд измерения 8 температур от модуля признавались недостоверными, что приводило к останову установки.
Выяснилось, что эта длительность связана с длительностью периода опроса всех модулей ввода - если возникала ошибка обмена, то до следующего успешного обмена статус устанавливался в "ошибку", т.е. получалось 12 секунд недостоверности измерений 8 датчиков.
Уменьшить период опроса не удалось, т.к. каждый модуль ввода аналоговых сигналов от термопар не позволял выполнить опрос 8 каналов и 8 состояний обрыва термопар менее, чем за 1600 мс - при любой скорости обмена. Пришлось менять модули ввода.
Опрос одного модуля состоит из опроса значений 8 температур и 8 состояний обрывов термопар. Значения температур опрашивались почти мгновенно одним запросом - за 15 мс. А статусы обрыва приходилось опрашивать по одному (так модуль устроен) и после запроса ответ приходил через 200 мс, наверное, состояние обрыва мониторилось не постоянно, а по запросу и требовало от модуля проведения дополнительных действий (это я такое предполагаю). Таким образом, опрос статусов обрыва занимал 1600 мс и на его фоне можно пренебречь временем опроса температур.
Да, и таких модулей 8 шт на одной линии Modbus. Присутствуют ещё модули других типов, опрос которых сопоставим с 5-15 мс и временем на их опрос тоже можно пренебречь.
Была мысль выделить по линии Modbus на каждый модуль ввода, тогда период опроса сократился бы с 12 с до 1,6 с, но даже это время почти в 10 раз превышает требование технологов из ТЗ.
Т.е. технологи возмутились столь редкому опросу по сравнению с требованиями получать новые измерения не реже, чем через 0,100 секунд.
При помощи HTerm были получены логи обмена с отметками времени, по которым и стали видны длительности различных запросов. При помощи HEX-редактора выполнял навигацию (поиск) каждого последующего опроса канала измерения для получения временных интервалов.
По правде, есть инструмент лучше, но он платный (хотя и недорого), но сейчас недоступный из России. Пользовался им когда-то давно, пока он был бесплатным, а позже - триальной версией (хватало 20 минут для поиска ошибок).
Где это состояние было - в коде/конфигураторе/ответе модуля/... ?Цитата:
что при ошибке обмена с модулем это состояние ошибки длилось по ~12 секун
Тупой вопрос:
Если после очередного запроса 8 значений (сразу) и НЕобнаружении нигде изменений более чем на сколько-то там - так ли нужен запрос статуса? Т.е. можно ли каждый конкретный статус опрашивать только если отклонение соотв. значения больше чего-то там (ну может + не реже чем какой-то вменяемый период)
Можно ли программно шедулировать запросы статусов отдельно от значений если они (статусы) такие тупые (200мс)?
--
Я собсно просто хочу понять тамошние возможности. Если выше - возможно, то не вижу проблем с 12сек, хотя
Опросить вообще всё? Ну так это полюбасу не реально в данных условиях (хотелка иметь прям завсегда статусы).Цитата:
Т.е. технологи возмутились столь редкому опросу по сравнению с требованиями получать новые измерения не реже, чем через 0,100 секунд.
А вот если как-то можно не завсегда, допустить иногда 200мс тишины [+ учесть что есть, насколько понял, еще интерфейсы] - то можно и поговорить про "почти всегда 0.100...0.150мс - всё"
и вообще
А возможности самих термопар - какие?Цитата:
... не реже, чем через 0,100 секунд.
Но!
Я не оспариваю ваших решений там - это ваша тема и ваши деньги.
А не пробовали выполнять опрос с пачкой ненужных регистров? Иногда приборы это позволяют.
ну так пока целый круг опроса пройдет по всем модулям, почему удивляют эти 12 секунд ?Цитата:
Исходная наблюдаемая проблема заключалась в том, что при ошибке обмена с модулем это состояние ошибки длилось по ~12 секунд.
Решения не мои - есть опытный руководитель работ, который аргументированно потребовал обязательный опрос состояний. Поэтому от заманчивого критерия отсутствия обрыва "изменение значения измерения температуры" пришлось отказаться.
В общем, моя работа закончилась на выяснении причин наблюдаемых эффектов, дальше решения принимали руководители работ, технологи и проектировщики - они рассмотрели различные варианты и пришли к решению о замене модулей.
Раньше, когда работал в маленькой конторе, на меня давило руководство - умри, но плохой проект автоматизации компенсируй изворотами в программе, даже нарушая требования ТЗ. Сейчас при невозможности что-либо "компенсировать" докладываю руководству и оно принимает решения по изменению аппаратной части. Мне не нужно придумывать, как компенсировать недостаток скорости обмена с модулем - он просто будет заменён.
Уже для себя пробовал сделать опрос всех значений и 1-2 обрывов на один цикл, но это не получилось из-за того, что опрос настраивается в конфигураторе, в котором нет возможности что-то исключить из списка (или я не до конца разобрался или поторопился) и опрос возможен по двум условиям - по таймеру или по изменению, и оба варианта мне не подходили.
Да не то чтобы отказатся. Имелось ввиду что при косвенных признаках проблемы (наглухо не шевелится или резко изменилось) переспросить статус.Цитата:
Поэтому от заманчивого критерия отсутствия обрыва "изменение значения измерения температуры" пришлось отказаться.
Здесь вопрос решён - и ок. Я всё. Снифер не предлагаю)