Доотвечу про поверку. Легко с вами общаться.
Вот вы (как компания) пишете, что у вас тоже на производстве датчик сравнивается с эталонами и индивидуально калибруется. В коробке с датчиком бумаги нет. В спеках датчика есть указания на погрешности (это отлично).
И при этом у меня есть датчик от ОВЕНа, который стоит 7 тыр, и эти два датчика, откалиброванные по эталонам, показывают разное. Шо делать? Кому верить? Как быть?
светодиод активности модема, не самый важный. Это эволюция такая: до WB 6 ревизии 6.5 его вообще не было, в 6.5 получилось сделать только снизу, в 6.7 уже смогли вынести на верхнюю крышку. Так что стараемся выносить. когда получается.
В модулях для контроллера (которые справа стыкуются к WB6) светодиодов нет, чтобы дёшево. В отдельных устройствах, типа WB-MR6C v.2 есть светодиоды статусов.
В статье в рекомендованных, кстати, гибкий и экранированный: F/UTP Patch.
А почему нельзя? Я допускаю, что я что-то не знаю, но чем экранированная витая пара F/UTP отличается от специального освящённого кабеля для RS-485? Ну экран там немножко хуже, ну волновое сопротивление чуть не совпало и три процента сигнала откуда-нибудь отразятся обратно. Но вот что бы прямо очень ужасно?
это спасибо, допишем
я бы отметил по длине, снял датчик, вынул ответную часть клеммника и собирал уже без датчика. Планировалось так.
Ну или плату отщёлкнуть, да.
Взять ещё пару датчиков. Например копеечные DS18B20 (только наcтоящие) и какой-нибудь бытовой.
С температурой так можно, с влажностью уже осторожнее: у всех цифровых погрешность 2-3% RH, на краях диапазона больше. Плюс температура (самонагрев) очень сильно влияет на влажность. Плюс на рынке полно хреновых датчиков. По влажности нам стоит просто поверить (после калибровки температуры, если понадобится), потому что проверить без камеры или солевого эталона - очень сложно.
Давно этого жду. А ещё регистры движения 281 и 283 лучше было бы к ним перенести, после 11.
1 лайк
(ответ писался тогда, когда был сделан первый скриншот - в 8утра; если после него кто-то что-то ответил, то тут инфа может быть не актуальной)
Так. Проснулся. Злой. Отвечаю по всем пунктам. Я дьявольски злобен, поэтому за мягкость ответов не ручаюсь, сразу предупреждаю.
Пункт 1. Херня с датчиком продолжалась ВСЮ НОЧЬ. Вон новый скриншот. Валится именно температура:
Где комментарии и обсуждение про это? Это - основной вопрос, который меня интересует. А он за разговорами про регистры и кабели был упущен и ответа на него я не получил.
Выше я приводил регистры, которые я использую на скриншоте из конфигурации устройства (датчика) в ПЛК. Что дальше?
Я знаю, что. Вчера в обсуждении мелькнула фраза про какие-то там стандартные регистры. Мол:
А что это никто не заметил на скриншоте, который я выложил - про регистры, что я использую второй набор регистров, где температура выдаётся х100? Мне самому себе техподдержку оказывать? Окей, щас сам себе отвечу:
- CSыч, попробуй-ка стащить температуру с 0 и 1 регистра и сравни, что будет с ней твориться.
- Ага, понял, ща добавлю ещё одной линией на график и вечером покажу, что будет.
Пункт 2. Про кабели RS-485. Тут у нас получился диалог на тему “Это кто тут ещё хипстеры? У нас крупные организации берут наши девайсы и делают на них большие щиты”.
Ну так вот стоит, чёрт подери, спросить у этих крупных организаций, как и чем они RS-485 ведут по объектам. Наверняка специальным кабелем, который имеет правильное сечение и правильное волновое сопротивление.
Хипстерами я называю тех, кто хочет “прям щас” и не хочет никуда вникать. У меня на блоге такие гады как раз обожают применять витую пару UTP или под интерфейсы связи, или, что ещё хуже, под цепи кнопок. Особенно на 230V. Поэтому слова “витая пара” давно стали для меня красной тряпкой и признаком невежества.
Подпункт А. Многожильный? О чём идёт речь?
- Правильное применение термина: в кабеле несколько ШТУК жил - и поэтому он многожильный? Ну так, если кабель имеет одну витую пару - то там две жилы, и он - да - многожильный.
- Неправильное применение термина: кабель имеет гибкие жилы, составленные из многих тонких проволочек. Если это так - немедленно всё исправлять, потому что такое применение слова “многожильный” - это позорище! Правильное слово для жил: многопроволочная или, если писать простым языком - гибкая.
Подпункт Б. Спецкабели. Тут всё жёстко. Любая хрень - даже бельевая верёвка, если её графитом от карандашей обмазать - протащит через себя RS-485. Но работать это будет только при определённых условиях. Тепличных, скорее всего.
У меня есть вон от другого ПЛК линия ModBus на 9600, котороая вообще телефонной лапшой проложена и звездой на три куска разветвляется. Работает, фигли.
Но если мы хотим, чтобы оно работало правильно и надёжно - то следует обратиться к стандарту или ресурсам, где есть из него выкопировки, в которых сказано про требования к кабелям.
Требования звучат так:
- Одна витая пара (не UTP, а свитые между собой жилы);
- Экранированная оболочка, которая заземляется;
- Сечение от 0,5 кв.мм;
- Разводка строго шлейфом (НЕ звездой);
- Не более 32 устройств на одном канале связи. Если их больше - нужны повторители.
Как найду точный ГОСТ - напишу. Вот технический пруф: http://www.gaw.ru/html.cgi/txt/interface/rs485/app.htm, вот ещё чей-то пруф: https://www.softelectro.ru/rs485.html. А вот рекламный обзор производителей кабелей для RS-485. Только у одного из них есть сечение ниже 0,5 кв.мм: https://www.ruscable.ru/article/ob_interfeysnykh_kabelyakh_standarta_RS-/
Подпункт В. Большие объекты. Вот хотелось бы увидеть примеры монтажа оборудования на больших объектах. Это где не хипстеры делали.
Я к чему. Если мы читаем по утру за чаем обзорчик с хабра, где очередной рукожоп в панельной трёшке на 70 квадратных метров вдолбил в стенку распаечную коробку и напихал туда Wiren или другой умный дом (а точнее дом-дурачок) и там развёл Modbus витой парой UTP, потому что он уже как много лет и прочее такое - то это не показатель.
Когда начинаются большие квартиры от 100 квадратов или дома по 700 квадратов, то к силовому щиту начинает подходить по 150-200 кабелей. В штуках.
И вот тогда нужно думать про то, как все эти кабели влияют на работу RS-485.
Даю примеры, связанные с RS-485^
- Большая лубянка, 12. Дом культуры ФСБ РФ. В 2008 там была мощная реконструкция сценического света, который работает по протоколу DMX-512, который физически построен на том же RS-485 и имеет те же требования (спецкабели, длина линий, повторители, терминаторы, не более 32 устройств).
Так вот там все основные магистрали были проложены правильным кабелем для DMX, а перемычки между диммерами в стойке ради экономии были сделаны кабелем типа МКЭШ “две жилы в экране”. Типа, ну а чё - тоже же две жилы, немного свитые, экран есть.
Вот это вот дерьмо глючило так жёстко, что из-за переотражений сигнала эти диммеры сами себя включали и видели управляющие последовательности, которых не было.
После того, как всё было с матами заменено на правильный кабель - глюки ушли. - Дом 700 квадратов. На три этажа + подвал. На каждом этаже по паре коллекторных шкафов (отопление, тёплые полы). Всё это над зацепить по ModBus и отдать в ПЛК в щит, чтобы управлять термоклапанами и мониторить температуру.
Кабель интерфейса будет идти в стяжке пола, в лотках подвала и кое-где по потолку рядом с силовыми кабелями. Длина линии около 100-150 метров, скорость будет 9600.
Какой кабель я возьму? СПЕЦИАЛЬНЫЙ (и тут мы возвращаемся к тому же самому - как этот кабель заводить и разделывать в датчике). - Просто квартира. Для заказчика, который это ща тоже читает, между прочим. Квартира небольшая, а устройств Modbus наберётся: 8 будущих датчиков MSW + 11 термостатов тёплого пола + 1 датчик уличный = 20 штук.
Кабель идёт и в лотках по потолку, и спускается и поднимается шлейфом в общей штробе вместе с кабелями на розетки и свет. Это квартира, там около блока “три розетки + четыре кнопки + тёплый пол” не получится выполнить требования по разносу линий силы и слаботочки на 50 см.
Какой кабель заложен? Тот же, специализированный.
Почему? Потому что цена ошибки ВЫСОКА. Что будет, если я на дом или квартиру заложу “витую пару”, которая у вас в инструкции написана, а потом эээ… обосрусь с ней. Тогда, когда будет сделана отделка, залита стяжка? За чей счёт будут переделки? За мой, конечно же.
Я этого хочу? Нет. Поэтому я использую специализированные кабели для RS-485 и соблюдаю правила их монтажа и подключения. И поэтому я придираюсь к разъёмам, местам для разделки кабелей и прочему. И буду придираться жёстко.
Подпункт Г. Про НШВИ. А так махом там написано про обжимку через НШВИ на 0,5 кв.мм.
Мы знаем, что кабели RS-485 рахзводятся шлейфом. Мне пойти, взять другой кабель, более злой, с двойным экраном, попробовать обжать его - внимание - в НШВИ(2) на 0,5 и запихать его в клеммы? А влезет ли?
Пункт 3. Про тестирование. Ну и где бумага о том, что датчик был протестирован тогда-то и там-то?
Что мне считать эталоном? На что ориентироваться? Вот ща у меня уже ТРИ датчика разных производителей - и все три показывают разное. Все три датчика электронные.
А, да… есть ещё один аналоговый - термосопротвление марки 50М, имеющее тоже паспорт, клеймо поверки и аналоговый измерительный модуль с классом точности 0,25 и клеймом поверки.
Как это понимать, чёрт меня раздери? У всех есть эталоны, но у всех они эталонистее другого?
У меня нет выбора, я буду верить ОВЕНскому ПВТ-10, потому что на него есть документ.
А вместе с WB-MSW документов не было. Просто коробка с датчиком. Который меряет невесть что.
Пункт 4. Самый дьявольский. Про корпуса и светодиоды. Агрррхххх!!!
Светодиодов нет, чтобы дёшево. А что? Светодиод стоит как в 80ые прошлого века - только АЛ307АМ/БМ и за адские деньги, аж дороже КТ315ого?
Я ща поясню, откуда растут ноги у этого требования. Не моего, и не ГОСТовского, а жизненного.
Контроль, пусконаладка и обратная связь. Привожу примеры, которые банальны:
- Вижу на модуле IO включенный выход, вижу что контактор в щите работает прерывисто, дёргается. Внимательно смотрю на светодиод - светодиод горит ровно и нормально. Значит привет контактору.
- Нажимаю кнопку, нет реакции. Смотрю на модуль IO - светодиод входа не горит. Значит что-то у меня не то с цепями кнопки. Нажимаю соседнюю - светодиод отзывается. Значит питание на кнопки поступает, а разбираться надо только с первой нерабочей кнопкой.
- Надо посмотреть, видит ли модуль IO сигнал типа “Открытый коллектор на GND”. Опять светодиоды помогут, да?
- Как у человека в соседних постах - реле залипло/варистор пробило и он штору чуть не сжёг. Опять годятся светодиоды: светодиод не горит, питание есть. Значит это аппаратная проблема (бабах кулаком или барабанной палкой по модулю - если не отлипло, значит варистор, если отлипло - значит реле).
А если ещё и светодиод горит - то значит завис модуль или управляющая программа/скрипт реально держит включенным выход.
И ещё придирка касательно диодов и индикации - это внешний вид. Это личное. И снова хипстерское. Меня БЕСИТ, когда вместо полезных органов управления или обратной связи производители делают на передней морде устройства, которая стоит НАД пластроном и видна пользователю щита, просто чёртову наклеечку (как у вас и у других), мол “Ура, это Wiren Board”.
Как это не назвать хипстостой, если на этой наклеечке куча значочков, рисунков, даже описание контактов подключения есть - а полезные светодиоды, кнопки или прочие штуки сныканы под пластрон щита или их вообще нету.
Я ДИКО ругался на эту дрянь ещё в лохматых годах, когда мне подобное GSM-реле подкинули. Вот пруф на пост: https://cs-cs.net/shitki-pribludy-uzm-fs453e-gsm#3__gsm
Вот скажите, почему все используют эту чёртову Ganitу или аналоги и все как один лепят на переднюю морду корпуса наклеечку, и все ленятся делать нормальные панели? Это реально ВСЕ. Прям тренд - все, кто берёт подобные корпуса… RazumDom, вы, Rainbow EcoDim и прочие и и прочие…
Кто-то может вообще мне сказать (хоть из вас), ЗАЧЕМ пользователю готового щита надо видеть описание клемм для подключения над пластроном щита? Вот ЗАЧЕМ?
Этот пункт и зуб у меня на вас давно, ещё когда мне мои читатели начали много лет назад псать про Wiren. Я как корпус с наклейкой увидел - сразу вычеркнул вас из головы. Вот по датчику пришлось обратиться.
Пункт 5. Про карту регистров. Тут уже поговорили, да. НАДО делать. И СРАЗУ делать. Пример от RazumDom я приводил.
Просьба пояснить, почему так не было сделано сразу?
Совместимости хотели? Блин, а кто мешал сделать двойные регистры? Вот даже ЩАС, в новой прошивке. Пускай все текущие регистры останутся как есть.
Добавьте те же самые регистры, но подряд, без пропусков (и с заделом на будущее), но пускай они читаются подряд, например с адреса 1000.
То есть, я могу прочитать что-то по-старому, с адреса 0,1, 3, 4, 8, 9, 10, 11.
А могу и прочитать по новому, с адреса 1000 подряд всё.
Пункт 6. Про Coils. ТОРМОЗЯТ. И опять у меня вопрос. ЗАЧЕМ было брать этот архаизм, которым ща пользуются только архаичные монстры климата типа Carel/Domekt, потому что так уже привыкли, а раньше все память экономили.
Все нормальные люди сейчас, в XXI веке, всегда юзают регистры. Потому что их завались, и пишутся и читаются они одинаковыми командами.
Как мне проверить, что всё тормозит? Гм… если меня разозлит про кабель и я буду тестить на более злом спецкабеле с НШВИ(2) на 0,5, то заодно возьму Modbus Tools и тестану Coils.
Уточнение: в принципе, зло их побери, на тесты мне наплевать, потому что эти датчики у меня ДОЛЖНЫ работать именно с этим ПЛК и ядром CodeSys v3. Потому что так надо.
И если окажется, что это уникальный случай и Coils тут будут тормозить - что ж, значит все команды на них я буду выдавать длительностью в 20 секунд.
ИТОГО:
а) Какого фига у меня температура прыгает?
б) Какого фига у меня тормозят Coils?
в) Какому из 4х датчиков температуры мне верить?
А, я ж ещё забыл. Пункт 7. Инструкции по монтажу.
Оказывается, там надо как-то хитро вешать и монтировать датчик? Продевать кабель, отмерять, потом разделывать, потом ставить разъём и потом вешать датчик?
А вот осмелюсь требовательно спросить: А ГДЕ ЭТО НАПИСАНО?
Где инструкции о том, как правильно со всем этим обращаться? Что же получается? Что покупает человек датчик за 10 тыр (если брать полную комплектацию) и будет с ним как обезъяна с гранатой - примеривать так и сяк и портить?
Да, я развращён. До безобразия. ОВЕНом. Потому что я в 2016 году увидел его первым, офигел от того, какие у них удобные и понятные инструкции и паспорта - и хочу такого же.
И чтобы про разделку и подключение кабеля было написано. И чтобы про монтаж было написано. Особенно для датчиков. А то ну как я его суну под натяжной потолок / над газовой плитой поставлю (куда влажность и горячий воздух при готовке идут), а потом в суд подам на то, что я не знал что так нельзя, потому что не было инструкции.
Вы, блин, что выпускаете? ПРОДУКТ или красотульку? На расивую наклейку сил хватило, а сверстать понятный PDF (который можно скачать и распечатать, а не листать чёртовы запутанные Wiki онлайн c вёрсткой таблиц, которые только на А3 печатаются) - нет?
РРР!!!
И это не нападки, это не троллиг. Это я впервые в жизни начал знакомиться с вашей продукцией, про которую мне все уши прожужжали уже как года три. И вот и фигею о того, что элементарных вещей - нет.
Чёрт, прошу простить. Меня понесло. Выливается всё, накопленное за годы.
Пункт 8. Конфигурация. А это… а ГДЕ программа-конфигуратор-то? Простая, писанная на VC++ x32/x64, а не 120-мегабайтная хрень на .NET?
Которая позволит не какие-то там регистры устанавливать руками и не понимать, записались ли они или нет, а позволит подключать датчики или другие модули IO через преобразователь RS-485<>USB и галочками или раскрывающимися списками настраивать все нужные параметры?!
А также тестировать модули IO (которые с ModBus) сразу, без Wiren?
И искать модули с кривыми настройками связи (то, что предлагается делать на Linux WB через скриптик)? А если у меня нет WB, мне подарили юзанный модуль и я не знаю, что там и как?
Где перемычка вида “сброс на дефолтные настройки”?
Чёрт побери, это простой и лёгкий сервис. Вы же делаете свои WB и так-то для продвинутых задротов, где надо писать скрипты, что-то кодить и мучиться (когда везде есть FBD/ST/CFC-языки). Что? Задроты не смогут перемычку поставить для аппаратного сброса железа? Им надо обязательно писать скрипт перебора всех адресов всех устройств?
1 лайк
time modbus_client --debug -mrtu -pnone -s2 $DEV_PORT -a$DEV_ADDR -t0x03 -r5402
Opening /dev/ttyRS485-2 at 9600 bauds (N, 8, 2)
[37][03][15][1A][00][01][A4][57]
Waiting for a confirmation...
<37><03><02><00><E3><31><C9>
SUCCESS: read 1 of elements:
Data: 0x00e3
real 0m0.042s
user 0m0.000s
sys 0m0.000s
Чиатю один регистр.
Читаю coil:
time modbus_client --debug -mrtu -pnone -s2 $DEV_PORT -a$DEV_ADDR -t0x01 -r5001
Opening /dev/ttyRS485-2 at 9600 bauds (N, 8, 2)
[37][01][13][89][00][01][2D][32]
Waiting for a confirmation...
<37><01><01><00><5E><00>
SUCCESS: read 1 of elements:
Data: 0x00
real 0m0.072s
user 0m0.000s
sys 0m0.010s
У вас чтение-запись слишком частые, времени реально на них не хватает. в используемом ПО есть возможность посмотреть на очередь? (на ее длину)
Для теста - сделайте включение и через секунду отключение той же пищалки.
Увеличьте таймер (запросы реже).
Ну и те же coil:
Мы не гоняем по шине то, что не меняется. Как раз для того чтобы ее не занимать. То есть пишем исключительно изменившееся данные. Нет изменений? Не передаем.
Но вот баг с задержкой - воспроизвести сегодня попробую. Напишу скриптик, который будет как у вас с теми же принтервалами получать-отправлять.
Для целей теста - отключите ограничение по диапазону, посмотрим что реально от датчика приходит. Если зарезервированные под “ошибку” значения (скорее всего) - то их реально надо фильтровать.
Блин! АААА!!! А ааа… а… эээ ЧТО? А КАК же тогда ваши датчики будут работать в суровых ПЛК-то?
Там всё совсем по другому: чаще всего пишется не по изменению, а постоянно.
И это ЧТО за бредятина? Как это не хватает времени на запись на 100 мсек? Это ж время-то детское. Не 10 мсек, как я в модули IO пишу обычно.
Так. Значит на сегодня намечаю тесты:
- Снизить скорость опроса каналов температуры до 2000 мсек;
- Снизить скорость записи каналов Coils до 1000 мсек;
- Заценить температуру из обоих регистров: 0,1 и других
А вот за это - наша благодарность. Да, такой момент тоже нужно описать, возможно нам кажется это очевидным и “глаз замыливается”.
Так модуль первые две секунды после включения ждет в загрузчике.
Ну и процедура описана https://wirenboard.com/wiki/
Такс. Запустил первый тест: беру температуру из регистра 0 и отдаю её на график синей линией без обработки (делю на 10, и всё). Ждём пару часов, чтобы график заполнился - и отпишусь тут.
Пойду жечь вонилки, чтобы измучить VOC.
Про загрузчик и про обновление прошивки прочитал. ЭТО СТРАШНО! И МУТНО. Везде какие-то ужасные командные строки, прошивка тулзой из командной строки… ужасть!
Про инструкции. Да, пишите. Правда, ну посмотрите на то, какие инструкции у ОВЕНа. Они тоже российская фирма, тоже сами всё разрабатывают. И вот их можно взять за образец. Вот например от модуля IO (https://owen.ru/product/moduli_diskretnogo_vvoda_s_interfejsom_rs_485/documentation_and_software) инструкция: https://owen.ru/uploads/215/re_mv110-x.16d_dn__m01__1-ru-34143-1.16_a4.pdf - там показано и как крепить, и как провода подключать, и как клеммную колодку снимать, и вся инфа про ModBus собрана разом. Скачал - распечатал - пользуешься. Удобно же. Или даже в ERP-CRM систему этот файл с инструкцией прицепил, и он там всегда лежит (у меня так).
А вот картинка с их сайта, где показан монтаж их датчика. Нарисована даже неказисто, но понятно:
Обратите внимание, что на картинке даже показаны ВИТЫЕ пары. Скрученные. Вот так надо делать!
3 лайка
Итак, беглые результаты первого теста, потому что по ним кое-что видно.
Смотрим на график температур. На нём показано вот что:
- Зелёная линия = температура с регистра #4, которая проваливается, зато более точная (х100)
- Тёмно-синяя линия = температура с регистра #0, который якобы стандартный для всех датчиков. К ней прибавлено +15, чтобы она НЕ накладывалась на зелёную линию и было видно, какое из значений пропадает. Значение БЕЗ фильтрации. Если будет 0 или 0xFFFF, то график так и улетит в ноль или в небеса.
- Тонкая фиолетовая линия внизу = просто число, которое записано так: если не было отвала связи с модулем или ошибок ModBus - то выставить в 10. Если была хоть одна ошибка - выставить в 45. То есть, если линия будет прыгать (как в начале графика - это я значения перепутал, пока тестил), то будем видеть что были отвалы связи с датчиком.
- Тёмно-красная линия = Всё те же показания с ОВЕНского датчика, который висит на том же канале связи.
ИТОГО, что видно:
- Глючат только зелёные показания;
- Отвала или ошибок ModBus НЕТ (фиолетовая линия как была ровная внизу, так и не подскакивала);
- Эта хрень непонятно как зависит от VOC. А может и не зависит. Пики VOC/CO2/Влажности - это я надышал на датчики специально. Но это было в районе 1ч45мин по времени графика, а глюкалово было раньше - от 1ч30мин до 1ч45мин.
Ну и - ДА, датчик, блин, ТОРМОЗНОЙ в плане активности, если вы (Wiren) действительно можете это подтвердить официально, а не строчкой про
То есть, я о чём? Опять должна быть ИНСТРУКЦИЯ, в которой будет сказано не только про монтаж, а про ограничения вида “минимальная частота запросов на чтение = хх мсек, на запись = yyy мсек”. А вот откуда я знаю, тормозит датчик или нет? Почему я про это узнаю на практике?
С временем запросов я ещё повеселюсь. Что мне тесты одного датчика, если их у меня будет 8? А если 32 (максимум интерфейса)?
Спрашиваю зло, да, прям в открытую. Вот датчик позиционируется как крутой, и с возможностью и диодами мигать, и ИК-команды посылать. Вот ща на объекте, про который я говорю (и заказчик читает эту тему), у нас будет 8 датчиков, пять из которых будут рулить пятью кондеями.
И как быть, если следовать тому, что можно прочитать на Wiki (я про витую пару, чёрт её побери, а не специальный кабель ModBus) и тому, что я тут услышал про скорость опроса?
Типа, заказчик ткнул кнопку в WEB-интерфейсе “Врубить кондей”, и через MM времени (ща рассчитаем) эта команда дошла до датчика?
Я могу ошибаться, но подсчитаю, беря синтетический пример (не считая других устройств на том же канале ModBus).
8 штук датчиков
Из-за кривой карты регистров уложиться в один запрос на чтение всего и на один запрос на запись всего мы не можем. Значит подсчитаем запросы, если всё-таки опрашивать по парочке соседних регистров, открывая карту:
-
- Чтение регистров 0-1 (худший случай, так как регистр 3 глючит);
-
- Чтение регистров 3-4-5 (шум, температура, влажность точные);
-
- Чтение регистров 8-9-10-11 (CO2, освещённость, VOC);
-
- Запись Coils 0 (пищалка);
-
- Запись Coils 10-11 (зелёный и красный диод, которые в карте перепутаны нахер);
-
- Запись Coils 5100-5180 (воспроизведение ИК-команд);
- (иногда) 7. Запись Coils 5300-5380 (обучние ИК-команд).
Итого 6 штук запросов. Так как инфы о том, через сколько датчик надо опрашивать, нету, а оказывается что 100 мсек - это типа много, берём 500 мсек и 1 сек.
Далее мы знаем, что все устройства разом опросить нельзя, потому что в силу работы протокола ModBus Master может посылать запрос и получать ответ только от одного Slave в один момент времени.
Также мы знаем, что внутри ядра ПЛК обмен с одним устройством ModBus производится один раз за цикл программы, который я могу накрутить на 10-30 мсек. Берём 10 мсек, чтобы сделать идеальные условия.
Итак, получаем следующие данные для нашего мутного прикидочного расчёта:
Один датчик требует 6 штук запросов, интервал каждого из которых будет составлять 500 мсек или 1 секунду. То есть 6 х 0,5 сек = 3 сек, 6 х 1 сек = 6 сек на опрос ОДНОГО датчика.
Далее. Датчиков у нас 8 штук. Значит 3 сек х 8 = 24 сек или 6 сек х 8 = 40 сек.
Далее вспоминаем, что ядро ПЛК делает промежутки между опросами в 10 мсек на каждый датчик. То есть 10 х 8 = 80 мсек. Ну, это в ключе СЕКУНД не страшно.
И вот вопрос. Он не провокационный, а зло ироничный. Что же это за такой продукт, который не получится использовать так, как он задуман? Вот реально, подумайте, если следовать устным рекомендациям типа “что-то 100 мсек дофига, датчик тормозит”, то получается что из-за кучи запросов моя команда включения кондея дойдёт до датчика через 24 или 40 секунд, что ли?
А теперь вспомним, что на этой линии у меня ещё и 11 термостатов тёплых полов. Которые, правда, не тормозят и которые я гонял аж на 10 мсек ради прикола (отдельно, в тепличных условиях - и он не отваливался).
Представим, что термостаты я опрашиваю раз в 100 мсек. Значит 11 х 0,1 сек = 1,1 секунда. Карллл!! Все мои термостаты опросятся за 1,1 секунду.
Блин. Это что? РЕАЛЬНО ваши датчики НЕЛЬЗЯ на 100 мсек гонять? а как же ИК-командами-то пользоваться? Что за фигня?
На практике: С момента нажатия кнопки
в меню, ну или отправки в mqtt команды проходит много меньше секунды до начала воспроизведения записанной ИК-команды.
Просто потому что все coil мы не пишем. Потребовалось записать - записали.
Реально каждый раз гонять все команды? То есть писать туда нули, поверх нулей? Но зачем? Это просто пустой трафик! То есть 80*(8+6) байт, плюс стоп-биты Это просто нагрев воздуха и занятие шины. Ну нелогично же. Не надо так.
Есть хорошая статья на хабре. Именно про скорость. Нельзя пытаться передать по шине больше чем она способна пропустить. Какое бы устройство не было. 9600 - это меньше 1200 байт/сек.
Если уж с одним устройством при холостой записи удалось занять всю ширину канала.
Но чтение температуры-влажности раз (и даже 5 раз) в секунду успешно работает. Проверил. Потому что запрос регистра (одного) занимает разумное время. Мне нужен один (два, три, пять) регистр - я их запрашиваю.
Опять же с точки зрения практики: ну нету потребности знать температуру даже раз в секунду.
Реально у нас работает на 10 мсек
В том-то и дело что если НЕ надо передавать команду, то и записывать “0” не нужно.
Это как (аналогия)
- Петров!
- Я!
- Не нужен, свободен.
- Сидоров!
- Я!
- Не нужен, свободен.
- Васечкин, включи команду!
- Есть!
- Баранкин!
- Я!
- Не нужен, свободен.
…мать-перемать!
Первое. Я писал ВЫШЕ, что у меня сейчас ОДИН КАНАЛ RS-485. Одна. Штука. Канала. На канале всего два устройства. И сейчас пишется только три штуки Coiloв раз в 100 мсек.
Это что? Много? Прям вот офигеть как много?
Второе. Я считал худший случай. Когда мне надо использовать все 80 ИК-команд. На полную. Датчик же это может? Может. Почему я не могу?
Третье. Все эти рисуночки мне ни о чём не сказали. Мне нужны тесты на живой магистрали из, скажем, 20 штук штук таких датчиков. Вот на такой магистрали и надо замерять время реакции на разные команды по Coils.
Четвёртое. Зачем цеплять за температуру-то? Про температуру речь не идёт. Речь идёт, ещё раз, о следующем
- Из-за идиотской карты регистров, про которую не подумали, применить один групповой запрос на запись и один групповой запрос на чтение не получается
- Тормозит реакция датчика на работу по Coils. На другие вещи НЕ тормозит. Какого чёрта я нажимаю на кнопку, и мой бризер-кондей реагирует через 10 секунд-то?
- В инструкции (а точнее, в неких Wiki) на датчик НЕ указана максимальная частота опроса.
Пятое. Что касается “статьи на хабре”. Она короткая. Я напишу потом позже свою и длиннее. И про все эти нюансы.
Шестое. Что касается других ядер. Опять же, в инструкции и Wiki НЕТ надписи “датчик корректно работает только с WirenBoard версии не ниже хх”. Значит я могу его пихать в любой ПЛК. Даже в такой, ядро которого по умолчанию пишет всё подряд.
Конечно же я могу сделать запись в Coils по запросу. Ща пойду и сделаю. И… грожу пальцем если и это будет тормозить - вот тогда мы и посмотрим, у кого какой ModBus.
Какое?
Почему бы не написать в документации следующие характеристики:
- максимальное время ответа на команду чтения (для каждой функции 1-4, если отличается)
- максимальное время ответа на команду записи (для каждой функции 5, 6, 15, 16, если отличается)
- минимальный интервал между запросами к одному устройтсву (если есть)
и не только для датчиков MSW, а для всех modbus-устройств вашего производства?
Я согласен, что отправлять команды на запись нужно только при изменении состояния. Но знать эти характеристики было бы очень полезно, например, для выставления таймаутов, или при работе через собственное ПО без драйвера wb-mqtt-serial или вообще без контроллера WB.
1 лайк
Хорошая идея, измерим и напишем. Ни у одного производителя я такого, правда, не видел, но будем первыми. Там есть известные места, где можно отвечать быстрее, и у нас как раз на ближайшее будущее запланирована задача про оптимизацию.
Пока измерений и формального куска в документации нет, могу дать оценку:
- максимальное время ответа на команду чтения или записи - ~10мс
- к coil-ам, управляющим ИК, это не относится, там может быть и больше
- минимального интервала между запросами нет
- надо помнить, что по стандарту Modbus между любыми фреймами должно быть 3.5 байта тишины, а мы стандарт соблюдаем. Так что отправка ответа раньше 3.5 байт после запроса, или повторный запрос раньше, чем через 3.5 байта после ответа - это нарушение стандарта и наши датчики такое будут считать шумом и обрабатывать не будут.
2 лайка
Мы сейчас постараемся воспроизвести то, что вы написали, но это займёт какое-то время.
У меня есть смутное подозрение, что проблемы могут быть как раз из-за постоянной записи coil-ов связанных с ИК: они привязаны к аппаратно затратной операции чтения огромных кусков из флеша, они реализованы внутри отдельным образом, и в них никто никогда раньше не писал нули в цикле просто так.
Блин! Позвоните мне уже кто-то из WB. Мне хочется обмареить вас (справедливо) за ублюдочные программные косяки, а тут я не могу этого сделать. А мне ОЧЕНЬ хочется.
И я попробую, даже если меня забанят. Похер. Буду действовать жёстко, но без переходов на личность. Буду критиковать только стиль программирования.
Итак, эта вот херня подтверждается:
А теперь у меня вопрос. Все мы начинали с AtMega8 или PIC. И все мы писали в их EEPROM всякие штучки. И все мы помним, что операция чтения или записи из EEPROM ОЧЕНЬ затратная по времени. Настолько, мать её, затратная, что её обычно выносят в обработку по прерыванию, чтобы не рушить скорость основного цикла программы.
Нет понимания, куда я клоню? Я хотел завернуть что-то зло-ядовитое, но не вышло.
Поясняю на пальцах. Что будет, если мы будем постоянно нашу AtMega заставлять читать-писать EEPROM? Да она просто не будет успевать этого делать, пытаясь отдавать какие-то там байты из него. Но полностью операция никогда не завершится, потому что мы будем пихать всё новые запросы записи-чтения, которые будут заставлять всё начинаться с начала.
Так вот тут вы мне (как производители) описали ту же херовину. И я не могу не материться, правда. Я на чужом ресурсе, я ОЧЕНЬ стараюсь этого не делать. Но вот я же говорил? Говорил, что прежде чем что-то делать - ПОСОВЕТУЙТЕСЬ СО СПЕЦАМИ, вашу мать!!!
Я - не совсем спец в новых STM32, я не адский спец по МК. есть и другие люди. Но любой из них (если не говорить о поверхностных ардуинщиках), скажет вам, что такие жирные операции надо делать по принципу КОНЕЧНОГО АВТОМАТА!!! (мать его прародителя всех МК и жену его печатную плату)!!!
А все эти посылки “ой, а мы никогда не пробовали так писать и не думали про это” - это признак недоработанности алгоритмов.
Надо сделать конечный автомат флагов на выполнение команд. В сложном варианте - с очередью, в простом - без очереди. Который активирует команду по ФРОНТУ, мать его, а не по уровню!
Хотя, о чём мы говорим? Какого хера флеш вообще читается, если мы засылаем в Colis 0, по которому никакой IF не не должен даже доходить до операции чтения команды её посыла?
Короче, что надо:
- Битовый (или как удобно) флаг (глобальная переменная) с названием (условным) “IRBusy”, по которому смотрится: передаётся ли на ИК-излучатель какая-то команда или нет?
- Массив битовых флагов с названием “IRCommandsState” - текущие состояния работы команд (1 = надо выполнить, 0 = не надо);
Алгоритм должен по Colis ставить флаги, отслеживая как у нормальных людей - фронты. ФРОНТЫ, а не уровни!!! То есть, пробую расписать на словах:
- Функция, которая смотрит полученные значения от Coils и сравнивает их с текущими в IRCommandsRequest. Если полученное значение по Coils отличается от сохранённого - то ОДИН РАЗ меняется значение флага в IRCommandsRequest.
Этот момент можно доработать так как удобно. Можно даже настройку в регистре по ModBus сделать. Если мы хотим, чтобы команда бесконечно повторялась, пока по Colis не придёт 0 - то оставляем как есть. Если же хотим, чтобы команда выполнялась всегда один раз (даже если по Colis всегда торчит 1) - то добавляем ещё один массив флагов, где смотрим на выполненные команды. Если надо - могу расписать. Ща идею не сформировал, дописал по ходу. - Отдельная функция, которая сканит флаги IRCommandsRequest и спокойно, с её доступной скоростью определяет те команды, которые надо выполнить. В полрядке очереди.
- Функция, которая выполняет одну команду, защищая сама себя от повторных вызовов флагом IRBusy. В начале она ставит этот флаг, в конце - скидывает. Она получает в качестве параметра банк (да хоть указатель на адрес) того, что надо передать.
Пока флаг IRBusy установлен, никакие другие ИК-команды не должны работать.
То есть, нам надо сделать следующее: флаги команд на исполнение и флаги “команда уже исполняется” и “ИК занят”. И на них, на простых битовых фагах, построить логику, которая будет блочить бесконечную передачу команд по записи Colis по сто раз. То есть, чтобы вся фигня работала строго по фронтам и спадам: если Colis ОДИН раз перешли из 0 в 1 - передаём. Если Colis ОДИН раз перешли из 1 в 0 - перестали передавать. Для этого мы сравниваем их текущие и предыдущие значения через массивы флагов. А чтобы одновременно не выполнялось несколько команд - мы не даём работать нескольким вызовам передачи команды (и чтения флешки) одновременно.
Тут должна быть защита от дурака. Щас-то как себя датчик поведёт, если я возьму все 80 Colis и бахну в них 1? А? Ща проверю!!!
UPDATE: БУГАГАГА!! АХАХАХАХААААА!!! ДАТЧИК ЛЁГ В ДАУН СРАЗУ ЖЕ НАПРОЧЬ!!! Ура!! Мы нашли не баг, а кривые руки и кривые мозги в прошивке!!!
Обожаю это наивное программистское “Ну, тут никогда не может быть нулевой указатель”, “Да эта функция всегда будет получать параметр, не надо ничего сверять”. 0xDEADC0DE вам в глотку! =)) Вместе с 0xDEADBEEF!!
Видос ща будет. Кривой, с рук, но мы ж тестим! Да, если Colis писать по фронту - то становится веселее. Ура. Признали один грёбаный глюк. Офигеть.
Теперь, кстати, я жду признавания глюка провалов температуры в регистре
Вот вы кода не видели, причину проблем (если они есть) не знаете. А уже наделали выводов на три экрана. Естественно, мы знаем и про время операций работы с флешем (которая кстати не EEPROM в наших МК), и про конечные аквтоматы, и про флажочки. Странно думать, что можно сделать продукт такой сложности как WB-MSW v.3 и не столкнуться с такими базовыми вещами.
Внутри там автомат состояний, вызов операций только по фронтам, асинхронный разбор очереди, блокировка при выполнении других операций. И флеш там не читается, если ноль в coil писать, сейчас проверил. Проблема явно имеет гораздо более интересные причины, чем вы предположили.
Хм, но ведь то же самое можно сказать и про алгоритм на ПЛК? Писать флаги по ФРОНТАМ, а не уровням, как у нормальных людей, чтобы экономить ценные ресурсы МК и пропускную способность шины.
Должна быть, если есть проблема - то исправим. Но, как вы наверное понимаете, не существует реальной задачи, где нужно слать 80 coil-ов с единичками, так что “защита от дурака” в этом случаке непонятно что и от кого должна защищать.
Напишите пожалуйста подробнее, что всё-таки произошло и что значит эта фраза. Может датчик терпеливо отправляет 80 ИК команд подряд по вашей команде?
Вот НЕ соглашусь. ЖЁСТКО не соглашусь. Разрабы, которые говорят “да никто никогда не будет писать сразу 80 команд” - это плохие разрабы. Просто ЖЕСТЬ какие плохие. Так делать НЕЛЬЗЯ, и это очень, это ужасно плохо. Прям настолько плохо, что если диалог будет и дальше идти в стиле “этого не должно случаться”, то его можно не продолжать. Либо просьба меня вывести на контакты главного разработчика, и я буду разговаривать уже с ним, а не с форумом.
Защита должна не давать работать командам передачи одновременно разом. Вот что будет, если я запишу 80 Coilов? Вот проглючило у меня цикл, например. Дурак я, плохо программу составил, просмотрел. Что? Датчик сбесится?
Выводы про код и программирование я сделал на основании той цитаты, которую получил - о том, что дескать даже при записи нулей в Coil выполняется чтение из флеша и это отжирает много времени. И от этого я офигел и начал ругаться, как сделал бы любой мало-мальский спец. На такие-то решения.
Если это не так - то просьба сначала нормально разбираться в происходядем, а потом уже отвечать здесь. Чтобы не получалось таких неприятностей, как с этим случаем.
Касательно “писать надо по фронтам” я могу ответить в таком же наивном стиле: “Да я как-то с 2016 года так писал, и ни разу не думал, что кому-то придёт в голову от этого тормозить”.
Если ответить серьёзно, то есть два способа записи, которые я применяю:
а) Запись для модулей IO внутри щита, где требуется максимум быстродействия. Я использую модули дискретного IO от ОВЕНа на 16 или 32 канала (целиком или все входы или все выходы), в которых модуль умеет отдавать ВСЕ свои каналы в одном (для 16ти) или двух (для 32х) регистрах. Поэтому у меня запрос на вечное чтение из модуля - это один или два регистра читать на 115 200.
Вечные чтения и записи мне в этом случае требуются для максимального быстродействия системы: значения с одного и того же модуля (тот самый регистр-битовая маска) разбираются на части и могут использоваться в нескольких задачах ПЛК одновременно. Писать по изменению тут нет смысла.
б) А вот все внешние интерфейсы у меня были те, которые не используют Coils. Я НИ РАЗУ В ЖИЗНИ до вашего датчика не писал Coils (потому что все, даже AliExpress, юзают регистры).
И в 99,9% случаев из внешних интерфейсов у меня было только чтение, а не запись. А уж читать постоянно (раз в 1-2 секунды) температуры - это-то и так должно быть циклично.
Я ясно пояснил свой опыт? Моё объяснение снимает вопросы на тему “писать надо по изменению”?
Значится, по фактам:
- Я не получил инфы, почему у меня температура из 3го регистра валится в нули, при этом связь и другая температура с регистра 0 не отваливаются. А меж тем это как было, так и продолжается.
- ЛЮБАЯ постоянная запись ЛЮБОГО значения в ЛЮБОЙ (не ИК) Coil работает с тормозами.
- Запись в Coilы ИК-команд нулей (какие нафиг попытки передать ИК-команды-то) отваливает датчик по ModBus напрочь. Он что-то успевает изредка ответить, а большее время не отвечает.
- Запись по фронту в Coil работает с задержкой около 1-2 секунды, которая обусловлена уже тем, что на шине ещё два несуществующих устройства, до которых ПЛК (с таймаутом 1-2 секунды) пытается достучаться.
Выложил видео. Вот прямая ссылка на мой хостинг как на файл: https://cs-cs.net/ExxChange/WBVideo.avi
Просьба кому надо видео скачать, так как через пару-тройку недель я его оттуда удалю. Сейчас на хостинге есть проблемы, поэтому если сразу ссыль не сработает, просьба попытаться несколько раз.
Это сайт техподдержки, он у нас принципиально публичный. Руковожу разработчиками прошивок лично я, так что уже никого позвать не получится 
Придётся продолжать со мной и здесь.
Как я написал выше, как только мы сможем понять, что именно вы делаете, воспроизвести и изолировать проблему - мы её поставим в очередь на исправление. Понятно, что в идеальном случае оборудование и ПО должно обрабатывать идеально даже самые безумные способы их использвания, но в реальном мире чем безумнее сценарий, тем с меньшей вероятностью про него подумает разработчик или тестировщик. И тем дольше проблема в нём окажется незамеченной.
Насколько я вижу по коду и истории в репозитории и трекере, осознанного решения про “никто не будет писать 80 coil-ов” мы не принимали. Если бы приняли, то сделали бы так, как вы написали: ограничили бы на уровне Modbus, внесли бы пометку в документацию.
Так что хорошие у нас разработчики, зря вы так.
В этом случае моя мотивация была следующая: воспроизвести у нас займёт не меньше дня, код посмотреть - ну тоже не сразу. Но из общих представлений об архитектуре наших прошивок, я могу сделать предположение о том, что можно проверить вам. Я об этом ровно так и написал - как о предположении. Мне кажется, что это достаточно полезно: вдруг у вас прямо сейчас есть 10 минут времени, чтобы этот рецепт проверить? Так вы получите работающую систему гораздо раньше, чем если будете ждать, пока мы всё воспроизведём, разберёмся и напишем идеально проверенный рецепт.
С чтениями - да, тут всё логично: цикл опроса. Но как связано быстродействие и запись coil-ов в каждом цикле опроса, даже если они не менялись?
У нас исторически немного другое отношение: модулей быстрого параллельного вывода у нас нет (мы ограничены временем срабатывания реле например), тем более такого нет в датчиках. Задачи с быстрым параллельным выводом, по нашему опыту, тоже бывают исключительно редко. И мы сами, и большинство заказчиков делают запись coil-ов именно по событиям, т.е. вклиниваются в цикл чтения параметров с командой записи какого-то одного coil-а, когда нужно. Логика в ПЛК там ровно такая, как вы выше описали для ИК: флажки, автоматы и т.д.
И это печально, как мне кажется. Есть прекрасный инструмент в стандарте, все возможные ПЛК и софт его поддерживают, но вместо этого разработчики оборудования не могут дочитать стандарт дальше третьей страницы и пытаются эмулировать coil-ы и discrete-ы поверх регистров хранения.
Сейчас пытаемся воспроизвести у себя, пока не получается. Я правильно понимаю, что это чтение именно нуля (0x0000) из регистра температуры?
Это пока даже начать воспроизвести не можем. Тормоза - это что? Устройство не отвечает на очередную команду записи? Или устройство отвечает с задержкой?
Т.к. у нас нет под рукой ПЛК конкурентов, да и вашей программы тоже нет, то нам это сложно угадать. Очень поможет, если вы сделайте какой-то минимальный пример, воспроизводящий проблему.
Это уже более понятно. Датчик не отвечает на сами команды записи coil-ов?
Ну это, кажется, с нами вообще никак не связано.
Я вот сейчас смотрю видео, у меня есть вопросы:
-
вы можете просто отключить вообще совсем опрос отсутствующих устройств в Codesys и посмотреть, как будет пищалка работать?
-
зачем там везде таймауты по 1000мс? Для наших устройств 20-100мс достаточно, в зависимости от того, как Codesys считает таймаут.
-
время в 100/500мс - это что значит и как соотносится с общей периодичностью задачи в 30мс? Вы уверены, что рантайм Codesys в этом случае вызывает запись действительно каждые 500мс, или это умножается на количество параметров или устройств?
-
есть какая-то в Codesys отладка на уровне Modbus? Т.е. можете ли вы увидеть, что именно и когда отправляет рантайм Codesys-а, какие ответы приходят и какие не приходят?
В видео вы ориентируетесь на “красный треугольничек в кодесисе”, но нам это мало что говорит, к сожалению.
В части про запись по фронтам тоже слышно, что пищалка не выключилась. Но что это было на уровне Modbus мне не понятно: Codesys не отправил команду? Отправил, но в ответ пришла ошибка? Отправил, но ничего не получил в ответ?
Если рантайм делает запись по фронту, но игнорирует ошибку и не пытается повторить запись - то это какое-то странное поведение рантайма. В таком случае лучше действительно в Codesys использовать постоянную запись, потому что мы-то прошивку исправим, если в ней проблема, но что будет, если там помеха по линии прилетит?