Просмотр полной версии : Подскажите программу логгер/сниффер Modbus
Добрый день!
Во время ПНР появилась задача разобраться с периодической ошибкой в обмене по Modbus RTU.
Система содержит 8 модулей ввода-вывода, для опроса каждого требуется сделать по 9 запросов (1 для восьми измеренных значений и ещё 8 для восьми регистров качества измерений) - так уж устроены эти модули и получить все данные одним или двумя групповыми запросами невозможно и это оговорено в документации на модуль.
Опрос модулей выполняется за счёт конфигуратора и применение другого способа (библиотеки обмена) невозможен.
Периодически на разных модулях возникает какая-то ошибка, диагностика ПЛК просто выдаёт невразумительный код ошибки.
Хочу разобраться с причиной ошибки.
Для этого подключился к линии на прослушку, могу сохранить обмен.
Имеющиеся логгеры-снифферы позволяют сохранять или сплошной дамп без отметок времени или просто сообщения вида "(дата-время) Modbus запрос к устройству с адресом XX и регистру YYYY".
Ошибки возникают раз в 10-15 минут, объём сохранённых данных в логах очень велик, найти запрос+ответ с ошибкой трудно.
Т.е. даже не понимаю характер ошибки - пропуск обмена (таймаут), искажения на линии (неправильный пакет).
Поэтому вижу два варианта:
- найти логгер с сообщениями вида "дата-время запрос (или ответ) устройство XX регистр YYYY: XX 03 YY YY LL LL CRC CRC"
- или написать собственный парсер дампа для получения нужных сообщений с диагностикой ошибок в пакетах.
Подскажите бесплатный логгер с такой возможностью или, может быть, готовую библиотеку разбора дампа с диагностикой.
...........
Подскажите бесплатный логгер с такой возможностью или, может быть, готовую библиотеку разбора дампа с диагностикой.
Не поверите, Эксель, вкладка данные.
При создании фильтра сразу увидите аномальные строки, можно удалить дубликаты и увидеть что то лишнее, там дофига всего можно. Да;е на другом листе сделать выборку почти ка SQL запрос
Как понимаю, VBA for Excel, как и макросы и функции Excel - Тьюринг-полные машины и позволяют воспроизвести любой алгоритм.
У меня в наличие просто бинарные дампы на десятки и сотни килобайт. Думаю, что после их открытия в Hex-редакторе смогу скопировать их hex представление и отправить в Excel, а может и сам Excel может работать с бинарными файлами.
Но, наверное, вместо изучения нового языка и его особенностей мне проще сделать парсер на знакомом FreePascal - неделю сэкономлю. У меня с середины декабря было всего 6 выходных дней - сейчас реально не способен и не расположен к обучению.
У вас лог бинарник? жесть. Логи ведь понятными для человека делают.
Как разбирать лог? так как вам удобнее. Но иметь поверхностное знакомство с Экселем нам не помешает. VBA for Excel.... есть фича, запись макроса, т.е. что то делаете в Экселе, потом это воспроизводите, нажав на кнопочку.
kondor3000
26.05.2026, 22:44
А что за модули? И чем читаете?
Почему вот у меня ни одной ошибки нет интересно, приходится изобретать как ошибку сделать.
Сергей0308
26.05.2026, 23:12
А что за модули? И чем читаете?
Почему вот у меня ни одной ошибки нет интересно, приходится изобретать как ошибку сделать.
Вы вероятно сами делаете или под вашим чутким руководством, а у товарища кто-то делает, я так понимаю, кто в тонкостях процесса не разбирается.
Я так понимаю что и у товарища процент ошибок очень-очень маленький, непонятно зачем этим заморачиваться, в смысле, ничего идеального не бывает, даже на Солнце пятна, сейчас особенно на противоположной к Земле стороне, короче, никто же не рвётся, как Ленин в Петроград, эти пятна устранять, надеюсь, смысл понятен?
А что за модули? И чем читаете?
Почему вот у меня ни одной ошибки нет интересно, приходится изобретать как ошибку сделать.
Контроллер Regul R500.
Среда программирования - кастомизованный CODESYS 3.5. Кроме конфигурации Modbus - других средств нет, в официальных документах не рассматривается.
https://reglab.ru/upload/iblock/c63/bxjpd31viamzx3b4i0nj0zthy4xq1sg1/Modbus-User-Guide-DPA_302-1_v1.7_rus.pdf
Модули RealLab NLS-8TI на 8 каналов термодатчиков, в данном случае термопар. https://www.reallab.ru/Support/download/
Диагностика обмена по Modbus в ПЛК не очень внятная, обобщённая.
У меня есть подозрение, что модули иногда пропускают ответ или помеха на линии искажает пакеты.
Интересует - причина диагностирования ошибки и период между опросами при такой диагностики.
Снял логи программой Serial Advansed Monitor (trial) - пишу по памяти. Пробовал ещё HHM Advansed Serial Logger - тоже название по памяти. Пару дней назад на хабре было описание какого-то нового логгера - и им пробовал.
При сохранении получаю бинарик.
Если лог без дампа типа "(дата-время) Modbus запрос к устройству с адресом XX и регистру YYYY" - то в тексте.
Преобразовать бинарный в текстовый дамп - труда не предоставляет - делал такое даже на ассемблере.
Сделать парсер на Free Pascal - думаю по силам, только время потребуется. Но, подозреваю, что не первым вижу такую задачу.
В идеале - сразу из логгера получать лог с диагностикой ошибок и разбором "запрос / ответ / адрес / регистр / время / ошибки". Самодельный парсер - это на крайний случай.
Обосновал?
Спасибо за пример. На работе посмотрю - на домашнем пользуюсь Libre Office, открыть не смогу.
Отчитаюсь о поисках.
Для получения логов обмена Modbus с отметками времени использовал программу HTerm
https://www.der-hammer.info/pages/terminal.html
Это именно терминал, а не инструмент работы с каким-либо протоколом.
Не скажу, что идеал, но с конкретной задачей помог справиться.
Парсинга обмена Modbus в нём нет, но в моём случае оказались важны только отметки времени между запросами и ответами. Можно сохранять просто бинарный лог, а можно лог с вкраплениями отметок времени.
Формат логов несколько неудобный - в бинарный файл с логом обмена периодически вставлены ASCII строки с отметками времени, но это лучше, чем ничего.
Разбор логов выполнял в HEX-редакторе PSPad editor
https://www.pspad.com
У меня просто отсутствовали любые HEX-редакторы и первым нашёл этот.
Сама проблема оказалась в модулях ввода - для одного модуля опрос значений измерений показаний 8 термопар занимал 15 мс (одним запросом), а опрос достоверности измерений (обрывов) 8 термопар занимал 8х200мс=1600мс (8 запросов - одним запросом невозможно согласно РЭ на модуль и по результатам эксперимента).
Таким образом, для 8 модулей ввода оказалось, что период обновления показаний составляет 8х1600мс=12800мс=12,8с и это не удовлетворяет требованиям ТЗ.
Было принято решение о замене модулей ввода.
Таким образом, для анализа проблемы оказалось достаточно отметок времени возле данных запросов и ответов.
kondor3000
02.08.2026, 18:47
А что за модули такие?
Овеновские МВ110 можно читать намного быстрее
А что за модули такие?
Овеновские МВ110 можно читать намного быстрее
Эти ---------->
Модули RealLab NLS-8TI на 8 каналов термодатчиков, в данном случае термопар. https://www.reallab.ru/Support/download/
kondor3000
02.08.2026, 19:18
Эти ---------->
Понятно, видел но не пользовал, цена и исполнение (в плане опроса как оказалось) не адекватные.
На самом деле - исполнение очень адекватное - в узком модуле 8 каналов AI - очень плотно. Ко всему - исполнение Ex - искробезопасное.
Как объяснял проектировщик, альтернативы ему нет - по проекту нужно обязательно исполнение Ex и 18 модулей разместить во взрывобезопасном шкафу - это толстостенная конструкция с тяжёлым круглым люком на резьбе (диаметр люка около 500 мм) - в нём едва уместились эти модули.
Вернее, альтернатива, конечно, существует, но несоизмеримо дороже и габаритнее - эту альтернативу и вынуждены были применить.
Но эти решения уже за пределами моей компетенции, не всё понимаю и доверяю проектировщику на слово.
Все решения приняты и ок
Просто не совсем понял это
Сама проблема оказалась в модулях ввода - для одного модуля опрос значений измерений показаний 8 термопар занимал 15 мс (одним запросом), а опрос достоверности измерений (обрывов) 8 термопар занимал 8х200мс=1600мс (8 запросов - одним запросом невозможно согласно РЭ на модуль и по результатам эксперимента).
Таким образом, для 8 модулей ввода оказалось, что период обновления показаний составляет 8х1600мс=12800мс=12,8с и это не удовлетворяет требованиям ТЗ.
8 модулей ввода-вывода, для опроса каждого требуется сделать по 9 запросов (1 для восьми измеренных значений и ещё 8 для восьми регистров качества измерений)
8 x (1 + 8) это 72. 12800/72 это 178мс на 1 запрос. А почему так много? Или я что-то не понял?
Почему нужно опрашивать по схеме "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 обрывов на один цикл, но это не получилось из-за того, что опрос настраивается в конфигураторе, в котором нет возможности что-то исключить из списка (или я не до конца разобрался или поторопился) и опрос возможен по двум условиям - по таймеру или по изменению, и оба варианта мне не подходили.
Поэтому от заманчивого критерия отсутствия обрыва "изменение значения измерения температуры" пришлось отказаться.
Да не то чтобы отказатся. Имелось ввиду что при косвенных признаках проблемы (наглухо не шевелится или резко изменилось) переспросить статус.
Здесь вопрос решён - и ок. Я всё. Снифер не предлагаю)
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot