А что за модули такие?
Овеновские МВ110 можно читать намного быстрее
А что за модули такие?
Овеновские МВ110 можно читать намного быстрее
Эти ---------->Сообщение от kondor3000
Понятно, видел но не пользовал, цена и исполнение (в плане опроса как оказалось) не адекватные.
Последний раз редактировалось kondor3000; 02.08.2026 в 19:32.
На самом деле - исполнение очень адекватное - в узком модуле 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 модулей
Последний раз редактировалось Валенок; 02.08.2026 в 20:58.
Тема создавалась для получения совета по выбору программ анализа обмена 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 секунд.
Но!
Я не оспариваю ваших решений там - это ваша тема и ваши деньги.
Последний раз редактировалось Валенок; 03.08.2026 в 00:10.
А не пробовали выполнять опрос с пачкой ненужных регистров? Иногда приборы это позволяют.
ну так пока целый круг опроса пройдет по всем модулям, почему удивляют эти 12 секунд ?Исходная наблюдаемая проблема заключалась в том, что при ошибке обмена с модулем это состояние ошибки длилось по ~12 секунд.
Последний раз редактировалось melky; 03.08.2026 в 08:59.
Решения не мои - есть опытный руководитель работ, который аргументированно потребовал обязательный опрос состояний. Поэтому от заманчивого критерия отсутствия обрыва "изменение значения измерения температуры" пришлось отказаться.
В общем, моя работа закончилась на выяснении причин наблюдаемых эффектов, дальше решения принимали руководители работ, технологи и проектировщики - они рассмотрели различные варианты и пришли к решению о замене модулей.
Раньше, когда работал в маленькой конторе, на меня давило руководство - умри, но плохой проект автоматизации компенсируй изворотами в программе, даже нарушая требования ТЗ. Сейчас при невозможности что-либо "компенсировать" докладываю руководству и оно принимает решения по изменению аппаратной части. Мне не нужно придумывать, как компенсировать недостаток скорости обмена с модулем - он просто будет заменён.
Уже для себя пробовал сделать опрос всех значений и 1-2 обрывов на один цикл, но это не получилось из-за того, что опрос настраивается в конфигураторе, в котором нет возможности что-то исключить из списка (или я не до конца разобрался или поторопился) и опрос возможен по двум условиям - по таймеру или по изменению, и оба варианта мне не подходили.
Да не то чтобы отказатся. Имелось ввиду что при косвенных признаках проблемы (наглухо не шевелится или резко изменилось) переспросить статус.Поэтому от заманчивого критерия отсутствия обрыва "изменение значения измерения температуры" пришлось отказаться.
Здесь вопрос решён - и ок. Я всё. Снифер не предлагаю)
Ваши права
Ответить с цитированием