WB-MAI6 ускорение измерения сопротивления

Нет ли каких-либо возможностей ускорить процесс измерения сопротивления на WB-MAI6 в режиме двухпроводной схемы измерения? Конечно выставил 115 кБит/с, конечно опрос поставил на 100 мс. Это вообще как мёртвому припарка.

Поэтому я отключил опросы всего остального, что есть, снизил время одного измерения до 1 мс (1000SPS), увеличил количество измерений подряд, время усреднения сигнала тоже дёргал. И ничего, мультиметр сразу показывает изменения, WB-MAI6 сначала отдавал новое сопротивление через 30 сек - 1,5 мин, потом время стало вообще приближаться к десяткам минут (видимо от слишком частых измерений). Счетчик циклов опроса АЦП при этом бодро крутится, время цикла опроса АЦП показывает 0.131с

Местами клеммники менял, та же фигня. Тут правда выяснилось ещё более интересное: окрашивание красным старого порта идёт с задержкой. Более того, если перед сменой клеммника изменил сопротивление, то оно сначала доотдаёт изменённые значения и только потом окрашивается в красное. Как будто он может и измеряет, но у него что-то с буфером обмена, где отдача данных идёт с задержкой по отношению к их получению. Как сбросить буфер не нашёл. Выключение по питанию не помогает.

Версия HW v.1.6D, прошивка 2.1.4

Вроде повлиять не могло, т.к. регистры перезаписываются после изменений на WB, но перед этим я экспериментировал, на один канал поставил время опроса 100мс, а на другой 30000мс (по одному каналу нужны почти реал-тайм измерения, по другому редкие).

Также подключал датчик давления трехпроводной, по ощущениям там тоже есть задержка секунд в 30 в измерениях. И ещё есть ощущение, что до всех манипуляций светодиод быстрее моргал.

Кстати, когда настраиваешь канал P, то там канал называется “P: двухпроводная…”, а на N канале просто “двухпроводная…”, хотя напрашивается “N: двухпроводная…” по аналогии. Да переключение режимов тоже ни на что ровным счётом не повлияло (режимы измерения температуры могут отдавать сопротивление, что я и опробовал).

Добрый день!

Инженер техподдержки взял в работу ваш вопрос, понадобится некоторое время чтобы подготовить ответ. Дадим обратную связь в течение дня.

Будет проще, если напишете сразу, какую задачу решаете. Я не могу представить, зачем нужно измерять сопротивление каждую мс.

Задача - эмулирование термистора. Обсуждение тут Эмулирование термистора

Просто у меня развилка. Многообортный резистор если перекрутить, то он сломается, т.е. нужно контролировать граничные положения. Для этого и необходимо оперативное измерение.

Если это технически невозможно, то второй путь - с калибровкой и задержками. В конце концов в самом вопросе не требуется прям супер скорости.

Но конечно хотелось какой-то стабильности, а не так, что сейчас измерили раз в 30 секунд, а следующее измерение через 10 минут. И немного напрягает, что само устройство делает вид, что измерение происходит постоянно (показания постоянно меняются в пределях десятка Ом), хотя по факту это не так.

Добрый день!
Очень, конечно, странные времена задержек: несколько измерений в секунду – вполне возможная скорость.
Для начала можете описать ваш стенд? Какие устройства подключены на шине к контроллеру? Какой резистор и как подключен к модулю?

Какие каналы на модуле сейчас включены и в какой конфигурации? Можете отдельно показать скриншотом настройки этого “тормозного” канала?

Так же попрошу прислать диагностический архив контроллера. Создание архива описано в документации.

Да, это у вас что-то сильно неправильно настроено, надо разбираться.

Погрешность измерения не отменишь. Но можно загрубить в скрипте.

Для тестов использую RS-485-2, на ней только WB-MAI6 и шаговый двигатель Makerbase MKS SERVO42D (оба и сама шина настроены на 115200).

Настройки канала стандартные, как и wb-mai6


Подключение тоже обычное (на вторые провода не обращайте внимание, они никуда не подключены, их подключение, например, к мультиметру или в порт N, и отключение ни на что не влияет)

Как всё выглядит (отдача данных с задержкой), записал видео: https://cloud.mail.ru/public/drd6/W9k48hv8a

Диагностику прислать не могу

root@wirenboard-APJD5GCC:~# wb-diag-collect diag
Start data collecting
Traceback (most recent call last):
File “/usr/lib/python3.9/asyncio/subprocess.py”, line 135, in wait
return await self._transport._wait()
File “/usr/lib/python3.9/asyncio/base_subprocess.py”, line 235, in _wait
return await waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/lib/python3.9/asyncio/tasks.py”, line 492, in wait_for
fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “/usr/bin/wb-diag-collect”, line 10, in
sys.exit(main())
File “/usr/share/wb-diag-collect/wb/diag/diag_collect.py”, line 71, in main
asyncio.get_event_loop().run_until_complete(
File “/usr/lib/python3.9/asyncio/base_events.py”, line 642, in run_until_complete
return future.result()
File “/usr/share/wb-diag-collect/wb/diag/collector.py”, line 32, in collect
await self.execute_commands(tmpdir, options[“commands”], options[“timeout”])
File “/usr/share/wb-diag-collect/wb/diag/collector.py”, line 121, in execute_commands
await asyncio.wait_for(proc.wait(), timeout=timeout)
File “/usr/lib/python3.9/asyncio/tasks.py”, line 494, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

Кстати при залогинивании контроллер подтупливает, может здесь какая проблема. На сегодня обновления все установлены.

При этом вроде ничего лишнего нет.

У вас контроллер сильно перегружен:
image
проблема в этом.

Я бы первым делом вернул все настройки wb-mqtt-serial и самого устройства в дефолтное состояние, и посмотрел на загрузку контроллера. Думаю, вы увидите нормальные цифры.

Если контроллер останется перегруженным - ищите, чем он так нагружен. Скорее всего дело в правилах. Надо добиться того, чтобы нагрузка на контроллер была в норме.

Потом при помощи mosquitto_sub я бы подписался на топик MAI6, и посмотрел, как часто он меняет значения сопротивления. Используйте вывод со временем:
mosquitto_sub -t 'ваш топик' | ts "%.T"

Только после этого имеет смысл обсуждать дальнейшие шаги.

1 лайк

Дмитрий, можно ли небольшое пояснение. Что значит нормальные цифры для WB6? Судя по тому, что в нём одно ядро, то нормальная цифра - менее 1. Но как её добиться? Я посмотрел несколько контроллеров WB6, минимальное значение, которое нашёл - 3. На данном аппарате я отключил все правила и добился сейчас 4.5 (через час после отключения всего и ребута). И wb-rules с mosquitto и wb-mqtt-serial продолжают съедать 50%, nginx с python добивают ещё процентов 40. Получается надо даунгрейдиться по софту или покупать новый контроллер? Кстати такие тормоза я начал наблюдать примерно с февраля. После какого-то обновления правила перестали нормально сохраняться и подтягивались только рестартом wb-rules или длительным ожиданием.

в среднем считывает раз-два в секунду видимо в зависимости от загрузки контроллера, т.о. надо оптимизировать правила (asSoonAs работает по наблюдениям более стабильно чем whenChanged), WB6 получается не тянет риал-тайм, надо применять расчетные модели

Сделал замер под нагрузкой avg 8. Команда

mosquitto_sub -t ‘ваш топик’ | ts “%.T”

похоже не имеет смысла, она показывает текущий таймстемп для полученных данных. Вот ниже лог, в 19:40:50 данные уже изменились, а сами изменения появились только в 19:41:15. Т.е. сдвиг начался где-то раньше. И там видимо был разрыв во-времени. Но на текущих данных этого разрыва не видно.

Кстати, в модуль Alarm встроили Telegram. Там тот же модуль, что и публично выложен, или его оптимизировали?

Да, это так.

По выводу top видно, что дело не в процессоре, у вас процессор 53% времени простаивает. И памяти хватает. А задачи ждут какого-то ресурса. Надо разбираться - сотрудники техподдержки помогут (у меня тут совещательный голос).
@JackDallas

Не согласен, надо понять, чем конкретно нагружен контроллер, какого ресурса не хватает.

Именно в это время wb-rules получил сообщение, что значение в топике изменилось. Так что вывод команды адекватен.

Я не понял, что вы имеете в виду. Вы видите те данные, которые MQTT-брокер прислал подписчикам, с таймстампом получения подписчиком этих данных. Понятно, что тут есть временной лаг между физическим событием и этим уведомлением, и он тем больше, чем сильнее нагружен контроллер. Но контроллер вполне способен обрабатывать несколько событий в секунду от каждого канала, с временным лагом, которым можно пренебречь. Короче, это все следствия, надо решать проблему с перегрузкой контроллера.

Покажите, пожалуйста, скриншот с историей загрузки процессора вашего контроллера за последние, скажем, сутки: