УРА!! Докладываю результаты тестов. Ночь оно простояло с выключенным опросом всех несуществующих устройств и записью в Coils по фронтам (без постоянной записи в них).
Пока полёт нормальный по температуре (на уровне шума 1 = дождь пошёл, 2 = проснулся):
Про код ошибки ModBus. Сейчас перепишу программу так:
а) Нехай выводит код ошибки на экран, если он не ноль. То есть в переменной на экране будет торчать последний код ошибки.
б) Воткну переключатель, который врубает или вырубает опрос двух несуществующих датчиков. Будем баловаться и смотреть, влияет ли это на показания температуры.
в) Потестю два варианта с постоянным опросом Coils и без него.
Всё, тесты запустил. Вечером будут результаты.
Полдня погоняю без Colis, вторую половину дня буду над Coils издеваться.
У меня аж вся работа встала из-за этого датчика. Третий день уже как.
Код ошибки Modbus, который иногда возвращает датчик - это 0xA1 - RESPONSE_TIMEOUT.
Прикол в том, что в этот момент проваливается ТОЛЬКО температура из регистра 3. Остальные параметры в норме. У вас там этот регистр 3 обрабатывается без костылей? По идее это ж долно быть то же, что в регистре 0, но с другой точностью.
Ща на ночь врубил опрос несуществующих устройств и запись в Coils постоянно по 100 мсек. Посмотрим, что будет.
ЗЫ. Датчик VOC угарный. Я тут спиртом одну железку протирал - так VOC больше 2000 взлетел. Надо будет попробовать вина напиться и посмотреть, сколько покажет.
ЗЫ2. Я на тесты этого датчика про…протерял три дня. Блин, а кто мне их компенсирует? У меня уже исследование на тему “Ой… а мы никогда этот датчик в другие ПЛК не пихали, а как это там он постоянно значения пишет”?
Это уже интереснее. Датчик, естественно, никакой 0xA1 не возвращает. Это, видимо, внутренне обозначение Codesys-а для отсутствия ответа в течение заданного таймаута. Если рантайм не получил ответ от датчика на команду чтения регистра 3 в очередной цикл опроса, то что у вас будет на графичке температуры? Варианты, которые приходят в голову:
отсутствие точки
значение, которое было 100мс (цикл опроса) назад
ноль
Мы ничего похожего так воспроизвести и не смогли, хотя продолжаем пытаться. Очень осложняет жизнь, что совершенно непонятно что и когда шлёт рантайм в шину, и какие ответы получает. Codesys это точно не умеет? Может быть у вас под рукой есть логический анализатор или просто какой-нибудь USB-RS485 переходник?
Ну из проблем, с которыми вы столкнулись, уже две, предположительно, были вызваны неудачной настройкой ПЛК: тормозная пищалка, которая на самом деле не тормозила; и коилы, которые на самом деле взводили ERROR_BUSY в соответствии с документацией. Так что как минимум за один день из трёх компенсации не будет
time modbus_client --debug -mrtu -pnone -s2 $DEV_PORT -a$DEV_ADDR -t0x05 -r0 0
Data to write: 0x0
Opening /dev/ttyRS485-1 at 9600 bauds (N, 8, 2)
[29][05][00][00][00][00][CB][E2]
Waiting for a confirmation...
<29><05><00><00><00><00><CB><E2>
SUCCESS: written 1 elements!
real 0m0.049s
user 0m0.000s
sys 0m0.010s
49 миллисекунд. Из-за работы ОС и буферов - может и до 60-80 быть.
Сколько времени нужно на чистую передачу данных?
8 байт передали, 8 приняли.
один фрейм - это 8 байт и 3.5 байта тишины. Один байт при наших настройках - это 11 бит (стартовый+8+два стоповых). Итого запрос + ответ занимают примерно (8+3.5)211 бит = 253.
253/9600 = 0,026 - то есть 26 миллисекунд
Реально - 49
Идеально - 26
Сtrl LED green
Реально - 63
Идеально - 26
**Сtrl LED Red
Реально - 55
Идеально - 26
IC_ClearBanks (Полная очистка всех банков памяти команд)
Реально - 62
Идеально - 26
Так, рассмотрим чтение регистров. В принципе отправка - те же 8 байт, прием - уже 7
Значит в идеальном случае - 25 миллисекунд.
У нас период опроса был задан 500 миллисекунд.
Посчитаем, приняв за среднюю длительность обмена 60 миллисекунд:
Реально: 8 (регистров) * 60 (миллисекунд) = 480
Идеально: 25*8=200
То есть при опросе даже в “идеальных” условиях с заявленным периодом какдждые 500 миллисекунд будут набегать “лишние” ((156*5)+200)-500=480 миллисекунд. В реальных условиях по стандарту таймаут ответа - меньше 100 миллисекунд.
Так, как улучшить-ускорить?
температуру, влажность, CO2 читать раз в 2 секунды. Чаще - не надо, она внутри обновляется с такой периодичностью, чтобы избежать самонагрева датчиков. Детектор движения, шум - можно и раз в 500.
При записи coil использовать функцию 0x0f, она работает.
Запрос-ответ получается всего 22 байта на 40 coil
Но лучше их писать по событию все же.
И подскажите что у вас в регистре 245? Посмотрите если достпен больше чем один датчик - то из двух (или больше).
ТАК! Пока СТОП до понедельника.
Потому что есть вероятность, что тот заказчик, который тему читает и у которого будет 8 датчиков, подгонит мне ещё парочку на магистральное тестирование.
Я их все три штуки (ОВЕН + один текущий и два заказчикова) вывешу на одну общую картонку - и вот тогда-то, чёрт раздери, мы и поговорим про всякие чёртовы тесты вида “мы тут отослали пачку команд, соединив датчик проводками на столе”. А заодно я ещё посмотрю на то, как они между собой врать будут, находясь рядом друг с другом и меряя всё в одном и том же месте.
Тьфу. Такие тесты (правда без мутных командных строк) я и сам могу проводить. Взять вон Modbus Poll - и нехай он раз в 10 мсек датчик мучает. Мне нужны не синтетические тесты вида “посмотрите, оно пишет”, а живые.
Вот вы там у себя в офисе возьмите-ка штук 8-10 датчиков, соедините их в магистраль - и тогда и попишите Colis/Registres или поопрашивайте их. Вот тогда и поговорим про всякие задержки и реакцию на кнопки.
А ещё в СБ ко мне грозится приехать другой френд с пишущим осциллографом. Он проводит исследование на тему применения разных приёмопередатчиков в линиях RS-485 и придирчиво изучает то, какие производители что делают в плане работы с шиной и соблюдают ли фронты сигналов.
Вот когда у меня на руках будет вся инфа - тогда разговор наш будет ещё более предметный.
Этим комментарием я хотел показать, что я не пропал, я тут, и что у меня есть возможность набрать ещё больше данных.
И всё-таки, всё-таки я допишу. Про скорость обновления показаний с внутренних датчиков. Тут нужна картинка с матерным мужЫком и фраза “ГДЕ ЭТО НАПИСАНО В ИНСТРУКЦИИ …ТЬ?!!”.
Вообще, вывесите там у себя распечатку этого мужика и подпишите “Составляй инструкцию …ть!” всем своим разрабам. Я вас почему хипстерами зову? Потому что на видео и в статьях у вас всё так няшно и приторно-сладко, что аж тошнит. И у ваших фанатов - тоже. Прям все слюнями так и льют: ой, красотулечки, ой, датчики, ой, скриптовый движок.
А вот пришёл я, развращённый промкой, паспортами на устройства, инструкциями, своим жёстким CodeSys с вытесняющей многозадачностью и полноценным IDE (а не строчками какого-то птичьего языка вида mkmbf -xftg-56 -z30- p20 l-034), и начались вопросы: где инструкция, где паспорт, где времена опроса, где времена реакции на запросы).
И меня умиляет, как на все эти мои вопросы вы отвечаете в стиле “а шо? а мы не знали? а зачем, у нас и так работает”. Кошмар?
Предлагаю сначала определиться, что вы хотите получить от общения с нами.
Вариант 1: вы хотите, чтобы ваша инсталляция нормально заработала.
Как это сделать, мы ответили здесь:
Но непохоже, чтобы вас это заинтересовало.
Вариант 2: вы хотите проверить наши датчики под нагрузкой.
Хорошо, давайте. Но сначала разберитесь хотя бы с тем, как работает протокол Modbus. Мы уже дважды писали в этой теме (1, 2), что бессмысленно опрашивать регистры чаще, чем запрос-ответ успевают выполняться.
Но сейчас вы опять пишете:
Объясню в третий раз, последний:
один запрос на запись одного coil и ответ с результатом записи выглядят так:
Итого: запрос - 8 байт (символов), ответ - 8 байт (символов). Между посылками по стандарту должна быть пауза ещё в 3.5 символа.
Теперь посмотрим, как устроена передача 1 байта данных (символа).
Вот цитата из нашей документации, пересказывающей протокол Modbus (Протокол Modbus — Wiren Board):
В Modbus RTU передается 11-битный символ, состоящий из 1 стартового бита, 8 бит данных (начиная с младшего бита), бит четности (необязателен) и 2 стоповых бита - если бит четности не передается, или 1 стоповый бит - если бит четности передается. Такой символ передает 1 байт данных. В устройствах Wiren Board по умолчанию бит контроля четности не передается и используется 2 стоповых бита.
Итого для ваших настроек 9600-8N1 получается, что запись одного coil + интервал между фреймами + ответ + интервал до следующего фрейма занимают (8+3.5+8+3.5)*10=230 бит. На скорости 9600 бит/с это занимает 230/9600=0,024 с = 24 мс.
Напишу для ясности другими словами:
можно просить нас, CODESYS, ОВЕН, господа Бога записывать coil каждые 10 мс, но это не получится, потому что только посылка + ответ + необходимые по стандарту задержки займут 24 мс.
При этом сам датчик при получении посылки тоже отвечает не сразу. Точное время его ответа немного меняется, порядок - десять мс.
Вариант 3: вы хотите понять, какой датчик показывает температуру неправильно.
Здесь полностью вас поддерживаем, давайте разбираться.
Уже поставили задачу инженеру найти датчик из вашей партии, и поставить на несколько дней на тест. Как только будут результаты, напишем.
Кроме того, можем договориться с вами и приехать к вам с ртутным термометром, и посмотреть, какой датчик что показывает.
Вариант 4: вы придумываете “факты” про наше оборудование, мы их опровергаем.
Первый “факт”.
Мы выкладываем видео теста, которое показывает, что всё работает без задержки. Ваш ответ:
Конечно, проводите. А потом пишите. Не наоборот.
Второй “факт”.
То же самое.
Третий “факт”.
Наши Modbus-устройствами сотнями продаются в проекты, где НЕТ нашего контроллера. И даже у нас на форуме есть пара тем “Я подключил вашу периферию к ОВЕН”. Видимо, наше оборудование и чужие контроллеры работают вместе, а дело в чём-то другом?
Вариант 5: вы даёте нам советы по улучшению нашего оборудования.
Конструктивным замечаниям мы всегда рады. Сразу может и не изменим, но запомним и потом учтём.
Но, пожалуйста, не надо разбавлять это хамством:
Из вашего видео:
дерьмо
Мы так не общаемся и не будем общаться. Мы уважаем себя, труд наших инженеров и программистов.
Я здесь. Докладываю информацию. По пунктам. И начну с последнего.
Я люто ненавижу ваши контроллеры ещё с 2015-2016 годов, когда у них были пружинные клеммы (за которые тогда я готов был пойти на настоящее убийство и сесть в тюрьму - я ненавижу их и вас за это), идиотские корпуса, отсутствие индикации, безопасных режимов на модулях.
Ненавижу ваш Linux и то, то там нет нормальной среды разработки, понятия нормального проекта (который можно загрузить в контроллер, как это делается на ПЛК), ненавижу хипстеров, которые носятся с “вааа, я написал скриптик, у меня на телефон пробрасывается видео с камеры”.
Ненавижу то, что у вас в разработке есть чёртова самобытность вида “а мы ничего не знаем, мы пишем вот свои coils скрпитом из командной строки, а что таим в ваших ПЛК происходит - нам наплевать”. И ненавижу то, что ради работы с вашим контроллером надо учить Linux, мириться с тем, что там нет никакой пошаговой отладки и просмотра состояния переменных в скрипте онлайн и что сами модули неудобны.
Данный датчик меня ЗАСТАВИЛИ посмотреть. По двум причинам:
а) Мне на моём злом и жёстком ресурсе уже как полгода или год каждый хипстер и каждый придурок пишет “Вооо, зацени, Wiren выпустили новый датчик”, на что я каждому должен был отвечать “Мне пофиг, мне не интересно, и датчик скорее всего такой же самобытный, как и их контроллеры”.
б) Пара заказчиков притащила мне эти датчики, потому что они вот ХОТЯТ их поставить у себя. Притащила для того, чтобы я над ними максимально произдевался (вплоть до сжигания или проезда катком или прессом) и составил для них и себя мнение.
Я развращён ПЛК, я развращён ОВЕНом, я развращён средами разработки по типу IDE. Программирую под микроконтроллеры я в IDE, пишу под ПЛК я в IDE, пишу на VC++ я в IDE, составляю схемы под Logo - в IDE.
Я разозлился на подход вида “чтобы найти все устройства с неизвестным адресом, выполните этот скрипт в нашем контроллере”. А если у меня нет контроллера? Вашего? А если я не люблю Linux и командную строку?
Ненавижу я и то, что у этого датчика нет нормального конфигуратора, как у ОВЕНа.
На основании этого у меня и появились к вам недоумённо-злобно-ненавиствные вопросы вида:
А это что ещё за хрень? Как это регистры не по порядку?
А почему у меня это дерьмо кладёт всю сетку, если я ставлю согласующий резистор в линию (терминатор)?
А как это так - я пишу Colils, а эта сволочь срабатывает с задержкой?
А где написано о точности датчиков и кому из трёх верить?
Ну и в таком духе. Все вопросы вполне конструктивные. Щас мы по ним и пробежимся.
Касательно общения и цитаток “дерьмо”, “херня”, “убью” и прочего. Толерантности во мне ни на грамм. И если я увижу дерьмо - то я так его и назову. Собственно, это из серии скандального Артемия Лебедева, и прочих подобных крупных блоггеров. Так вот вышло, я так общаюсь.
Я не хочу специально никого оскорблять. С гоадми это превратилось в что-то типа проверки на адекватность самих компаний, с которыми я так разговариваю: они могут формально обидеться в виде “Вы нас не уважаете, так почему мы должны с вами общаться” (как это сделал Меандр с УЗМками в 2016 году, потеряв в 2020 году долю этого рынка напрочь из-за этой обидки) или могут принять это (или пропустить мимо ушей) и работать с фактами.
Сам я люблю работать с компаниями, которые могут признать свои косяки (а не тыкать мне свои линуксовые скрипты, которые мне негде выполнить и которые оторваны от реальной ПЛКшной жизни) и разговаривать в стиле “Да, мы накосячили, а что ты предлагаешь?”.
Подводим итоги этого раздела:
а) Я человек злой, а сейчас благодаря Ютубчику и прочим идиотам - ещё более злой. Я честно написал про это тут в профиле, чтобы всех предупредить. Кто не читал - я не виноват.
б) По стилю общения: простите. Попробую не материться.
в) На факты давить не стоит. У меня на щите все факты подтвердились: и тормоза Coils, и кривая температура, и провал одного регистра по температуре, и глюки с терминатором в линии. Для меня это - факты. Подтверждённые видео и скриншотами. Я их не подделывал.
г) Я ненавижу ваше бизнес-кредо и ваш наколенно-самобытный подход к разработке вида “а этого не будет, потому что этого не может быть никогда, поэтому сделаем так-то и так-то”. И НИКОГДА бы не регался и не писал бы ничего тут, если бы у меня не появились вопросы к датчику и его монтажу.
Идём далее. Здесь будут и злые вопросы и конкретные рекомендации, как что-то поправить. Поэтому прошу не обижаться и всё прочитать целиком. Раздел 2. Претензии и вопросы.
2.1. Удобство монтажа в случае применения специального кабеля для RS-485.
Факт: кабель в датчик засунуть очень сложно, разделать кабель и спаять экраны - тем более. На момент монтажа есть риск повредить компоненты на плате, так как приходится работать инструментом в непосредственной близости от них. Вопросы: Просьба или показать образец монтажа шлейфом на специализированных кабелях (их наружный диаметр 6-8мм), или признать косяк в дизайне.
Также просьба отразить это в инструкции к датчику
2.2. Всё это время у меня работало уже три датчика WB и три датчика ОВЕН ПВТ на одной линии. Правда для того, чтобы их смонтировать без матов, пришлось брать плоскую телефонную лапшу на 4 жилы. Тогда мне удалось это сделать корректно. Вопрос: Как только я ставлю в конец линии терминатор, один из датчиков мигает светодиодом обмена, но от него валятся ошибки типа CRC_FAIL, INVALID_DATA. Что это значит? Магистраль всё та же - в метре щит с ПЛК и картонка с датчиками.
Сейчас моя линия работает без терминатора, что является нарушением стандарта RS-485. Детали: Не используете ли вы, случаем, в этом датчике, для защиты линии RS-485 самовосстанавливающиеся предохранители? Если используете, то я уже знаю одну из версий ответа на мой вопрос: брак этих предохранителей, из-за которых один датчик садит свои же ответы Мастеру в линии.
2.3. Претензии к разбросу параметров датчиков. Скриншотов у меня около 25 штук, предоставлены они будут архивом по запросу. Тут материться можно? Хм… В общем:
а) ДИКИЙ разброс по датчикам VOC/CO2. Вплоть до того, что один датчик показывает 500 ppm, другой 700, третий 100. Можно ли спросить, как на демотиваторах: “Что это за херня?”. Как данные результаты понимать? Это правда дерьмо и херня, или я требую многого или чего-то не понимаю?
б) Разброс по температурам около 2 градусов. У ОВЕНа - около 0,5 градусов. То есть, WB условно показывает 27,2 - 25,4 - 28,0 а ОВЕН показывает условно 27,9 - 28,2 - 27,9. Да-да, два датчика идут ровно.
Поэтому перезадаю вопрос, на который я не получил точного ответа до этого. Мне его обозвали провокационным, хотя мой вопрос был вопросом тупого дурака, который увидел точные цифирки на ОВЕНе и разные цифирки не WB. Вопрос: Является ли такой разброс показаний датчиков допустимым? Если нет - то является ли это гарантийным случаем (WB может перекалибровать датчики у себя на заводе)?
Про то, что вы их проверяете и вроде как калибруете на производстве я помню. Но чёртов разброс - это КАК? Норма или дело плохо?
2.3. Рекомендация к таблице регистров и грёбаным Colis. Вот тут будет провокация, и мне интересно то, за что вы зацепитесь: за информацию или за внешние признаки.
Даю суть. Вот больше всего я возненавидел вас всех за дьяволом проклятые Coils. Не надо приплетать сюда сейчас скорость, фрейминг и прочие железные вещи. Сейчас речь идёт о логической организации регистров.
Прежде чем орать про “вы все идиоты и сделали неудобно”, я хочу задать вопросы:
а) Почему были выбраны именно Coils, а не регистры? Некоторые ПЛК не поддерживают работу с Colis вообще. Например, CodeSys v2 не поддерживает, а v3 - да. Но сами видите как - с тормозами.
б) Почему было сделано так много Coils - на 80 команд, на 80 записей, на 80 записей в оперативку, на 80 команд из оперативки и так далее?
От ответа на это зависит моё предложение. Нужно ли это было для того, чтобы датчику можно было запихать в очередь одновременно несколько команд, а он их подряд бы засылал? Или это мои бредни, и датчик может воспроизводить только одну команду?
Вообще, что будет с датчиком, если я наберусь наглости и подам ему все 80 Coils на запись ИК-команд в постоянную память одновременно. Он будет пытаться это делать? Или выполнит только одну команду? И какую из 80ти?
Веду я к следующему. Я пытался понять вашу логику, и как-то под вино и сырчик (это и есть провокация) дошёл до такого момента, вспомнив как это делается в других устройствах.
В общем, а почему нельзя сделать так:
ОДИН регистр ModBus (карл, один!), куда кладётся номер банка, с которым надо что-то сделать. Причём по этому же номеру банки сортируются. Например 1-80 - это банки из флеша, 501-580 - банки из оперативки.
ВТОРОЙ регистр с кодом команды. Что-то типа “0” - ничего не делать, “1” - записать, “2” - стереть, “3” - воспроизвести однократно по фронту значения (0->3), “4” - воспроизводить, пока значение регистра команды равно 4 (длительно).
Регистры должны работать по фронту и самоочищаться внутри. Причём они могут быть доступны и на чтение. И работать по такому алгоритму: закинули номер банка и команду одним запросом на запись (как вы любите), и датчик начал её исполнять. Пока он исполняет - он отдаёт (Read Registers) эти регистры с теми же значениями. А как только он выполнил команду - вставляет в них нули, пок которым Мастер может увидеть: “О, команда отработала, значит считаем что кондей/бризер включился, ура”.
В этом случае вместо 80+80+80+80 Coils было бы два WORDда. И совсем коротенькая посылочка.
2.4. Как работать с вашим датчиком (обновление прошивки, документация, конфигурация, поиск устройств с неизвестным адресом) без Wiren и знания Linux? Будет ли написана тулза-программа-конфигуратор-обновлятор прошивок? Или будет ли под винду (не десятую) какой-то эмулятор ваших скриптов и примеров?
Планируется ли создать IDE?
Как вести пошаговую отладку ваших скриптов (ну типа посмотреть состояние переменных или куска массива на 298-ой итерации цикла из 512ти)? Есть ли такая возможность или консоль, текстовые файлики и grep ваше всё?
2.5. Будут ли на датчик бумаги? О проверке и калибровке на производстве? Прям в коробке датчика.
2.6. Требую оптимизировать таблицу регистров датчика в будущем так, чтобы:
а) Или все значимые регистры шли подряд (так сложнее).
б) Или же датчик возвращал на незначимые регистры нули, а не ILLEGAL_DATA_ADDRESS (так проще)
в) Оставить старое и добавить новые регистры с теми же значениями, но подряд (так удобнее и совместимее).
Требую, потому что в промышленных ПЛК ОВЕН, SIEMENS и других по умолчанию выполняется постоянная запись и чтение. Они так устроены. Ваш датчик изначально был рассчитан на работу с вашим контроллером, и это является техническим просчётом.
2.7. Касательно физической реализации RS-485. Я уже спрашивал про преедохранители. Чтобы не рыться на плате, хотелось бы узнать о следующих моментах:
а) На чём сделана защита линии? TVS-диоды? Предохранители?
б) (это не нападение-злиха, а вопрос) Почему не была сделана гальваническая развязка?
в) Что используется в качестве приёмопередатчика в линию?
г) Как работает передатчик в паузах между байтами данных? Вы оставляете его включенным (так правильно) или выключаете? Вообще, CS (или ENABLE) передатчика управляет отдельно, или нет?
д) Морочитесь ли вы с надёжностью связи и делаете ли вы включение передатчика за t3,5 до начала посылки и оставляете ли вы его включенным на t3,5 после конца посылки?
Эта вещь не слишком обязательна, но очень крайне желательна. Про это я напишу позже у себя на блоге в посте и закину ссылку тем, кто со мной свяжется на моё мыло (Info@cs-cs.net).
е) Каким образом устроена приёмопередача данных внутри прошивки? Соблюдаете ли вы точные тайминги протокола (которым мне в нос тыкали ;))? То, что буфер шлётся через DMA или по прерываниям - это понятно. Но вот как работает сам алгоритм:
Заранее заготовили буфер ответа, потом включили передатчик, выждали нужное время и начали посылать. В этом случае тайминги блюдутся и кривоты нет.
Или включили передатчик, потом стали готовить буфер, потом послали? В этом случае тайминги задержки перед посылкой плавают и бывают варианты “включили передатчик, потупили с буфером, начали посылать”, что тормозит линию.
2.8. Все тормоза на линии, про которые я дико ругался, объединяет одно условие: если на линии есть хоть одно выключенное устройство (которое не отвечает), то тогда на WB начинает периодически отдавать значение регистра с номером (тут было много мата, пока я зашёл на страницу датчика, потом в чёртовом всплывающем окне открыл документацию, а потом по ещё одной ссылке наконец-то добрался до карты регистров, возненавидев уже вас всех вместе с вашими Wiki)… регистра с номером 4 в ноль. При этом остальные данные датчик отдаёт верно.
2.9. Аргументы о том, что какие-то значения надо читать реже, а какие-то чаще я не признаю состоятельными из-за того, что датчик должен отдавать по командам чтения из него просто некий буфер из памяти. Заранее подготовленный.
То, что информация в этом буфере может обновляться внутри датчика хоть раз в 5 минут - это не важно. Это никак не связано с тем, как быстро я его читаю. Хоть раз в 10 мсек, хоть ещё как - это должно ограничиваться линией и моим дибилизмом, а не тормозами датчика.
Требую подтвердить и уточнить: у вас же в прошивке сделано отдельно, разными задачами? Отдельно измерение и формирование данных - и отдельно работа по Modbus и отправка буфера данных? Ну не меряете же вы сразу, как у вас температуру попросили узнать?
2.10. Аргументы о “ты не умеешь с ними работать, мы тестировали, у нас ничего не тормозит” я приму только если тесты будут делаться не так, как вы мне их показали - на столе стоит контроллер и датчик к нему подключен проводами в 20 сантиметров длиной - а на полноценном стенде.
Вот возьмите кусок обычной витой пары метров в 20, подключите на её конце датчиков штуки хотя бы три как у меня (или штук 8 как у моего заказчика) - и вот тогда мы будем про это разговаривать. Синтетические тесты датчика через конверторе USB<>RS-485 на столе у меня тоже хорошие получились. А вот на практике - нет.
3. Планы и будущее.
Я хочу написать у себя на блоге пост про сравнение ваших датчиков и датчиков ОВЕН (с бумагами и более точных). Сейчас я набираю ещё фоток и материалов, и к следующей неделе сделаю пост. Не для того, чтобы всё обосрать, а для своих читателей и для тех, кто меня знает и кто меня спрашивал про датчик.
Меня сейчас интересуют ответы на описанные выше вопросы.
4. ИТОГИ. Что понравилось: идея с ИК-командами. Я в неё не верил, а оказалось прикольным. Что не понравилось: уеб… ублюдский монтаж кабелей и клеммы, готичная таблица регистров с провалами, наивные Coils в количестве 320 штук + 5 штук, ответы вида “а у нас всё на столе работает, вам надо просто из командной строки скриптик запускать”, неудобная настройка датчика вручную, общение в стиле “да кто здесь хипстеры, у нас серьёзные проекты делаются, и вообще”.
Мои контакты, которые знают все: +7-926-286-97-35, info@cs-cs.net
У нас где-то потерялся момент про то, что вы открыты к консультациям по своим разработкам и готовы слушать мнение спецов. Просьба обращаться по этим контактам. Звонить, писать туда, а не сюда на форум. К общению я открыт при условии что вы не будете играть в обидки как Меандр. Если я вижу дерьмо или жесть - я буду на них ругаться. Прямо и открыто.
Вы посмотрели, что в действительности происходит в линии? Обещали, что осциллографом посмотрите. Без этого разговор бессмысленен - вы просите от
CODESYS отправлять и получать посылки чаще, чем это физически возможно, оставляете отключенные и другие устройства в линии, СОВЕРШЕННО НЕ ПРЕДСТАВЛЯЕТЕ, какие посылки и когда в итоге идут у вас в линию RS-485, и позволяете себе писать про это как про подтверждённую проблему.
Так как мы нацелены разобраться по всем фактам, ещё раз предлагаю: хватит болтовни, давайте встретимся у нас или у вас, подключим к линии осицллограф/логанализатор, и чётко посмотрим, что и когда туда отправляется. И всё будет понятно.
Всегда есть компромисс между размерами и удобством монтажа. Для настенного датчика габариты весьма критичны, никому не нравится здоровая коробка на стене.
Специализированные кабели для RS-485 - это из рода освященных кабелей для аудиофилов. Хорошая витая пара для Ethernet или систем сигнализации (экранированная, гибкая) ничем не хуже по физическим характеристикам, и, как правило, удобней в монтаже.
При этом даже специальный КИС-В для RS-485 имеет внешний диаметр 8 мм, а жилы прекрасно зажимаются по два в один НШВИ и не занимают много места. По вашей просьбе сделаем фото и выложим чуть позднее.
Ближайший компонент к клемме находится на расстоянии в сантиметр, и это огромный выводной ИК-приёмник. Пришлите, пожалуйста, фото, как вы монтируете датчик, и что боитесь повредить.
Не верю. Инженеры бегло проверили - не воспроизводится и близко. Попробуйте убрать не наши датчики, пришлите фото монтажа - посмотрим возможные причины. Если уверены, что дело в наших датчиках, - давайте встретимся, и с оборудованием посмотрим, что у вас происходит на шине.
Давайте разделять работу CO2 и VOC. Это разные датчики с разным принципом работы.
По CO2:
для CO2 заявлена погрешность ±50 ppm, то есть разброс в 100 ppm это нормально.
Если датчики стоят рядом с вами на столе, и вы на них дышите, то показания будут скакать - в выдыхаемом воздухе 50 000 ppm, в воздухе на улице - 400 ppm.
Стоить обратить внимание на то, что (цитата из документации Универсальный настенный датчик WB-MSW v.3 — Wiren Board):
сразу же после установки датчик может показывать неверные значения: это может быть связано с неосторожным обращением во время транспортировки и монтажа. Через несколько дней показания датчика придут в норму, благодаря функции автокалибровки.
Ну и самая редкая причина (по документации):
Датчик имеет функцию автокалибровки. Измеренное минимальное значение в течении суток принимается за 400 ppm - это значение концентрации CO2 на улице. Концентрация CO2 упадёт до уличной, если в помещении нет людей хотя бы несколько часов в день, или если в помещении работает вытяжная вентиляция, или в помещении иногда открывают окна.
Если это не так и концентрация CO2 в помещении никогда не доходит до уличной, то рекомендуем хотя бы один день хорошо проветривать помещение для калибровки датчика и после этого отключить автокалибровку (прописать 0 в регистр 95). Периодически повторяйте процедуру, чтобы датчик показывал более точные значения. В большинстве случаев отключение автокалибровки или ручная калибровка не требуются - датчик показывает правильные значения без дополнительных манипуляций.
По VOC:
с VOC еще хуже, это датчик измерения летучих органических веществ. То есть реагирует на все подряд, и опасные вещества, и не очень. Если пшикнуть духами рядом - зашкалит. Физика его работы гораздо менее точная, чем у датчика CO2 - это электрохимический датчик, для них нормальна ошибка в 100% (!). У нас стоит датчик известного производителя Sensirion - SGPC3-2.5K. Благодаря автокалибровке у него заявленная повторяемость - 15%. Время автокалибровки не регламентировано, но по нашим наблюдениям на стабильные показания он выходит только через несколько дней непрерывной работы.
И в случае с CO2, и с VOC у нас используются готовые цифровые датчики от хороших производителей, WB-MSW считывает с них данные и передаёт по Modbus без преобразования.
Нет, это ненормально. Что можно проверить:
Из документации:
Для более точного измерения модуль TH необходимо устанавливать в верхний левый разъем. Иначе он греется от СО2 датчика и завышает показания на 1-2 градуса.
Проверьте значения регистров компенсации самонагрева (holding 245). Для датчиков с СО2 там должно быть число около 70 (0.7 градуса). Без него - 0.
Датчики температуры мы не калибруем, они калиброваны изготовителем. Мы проверяем, что они работают, и проверяем что значение попадает в диапазон относительно референсного. И записываем значение в регистр компенсации, если датчик идёт с модулем СО2.
Предложение проверки прямо у вас остаётся в силе:
Потому что удобно именно так. Чтение и запись coil занимает меньше времени на шине, такой тип данных поддерживает гораздо больше контроллеров, SCADA и систем мониторинга, чем битовые маски.
Это специализированный тип данных для дискретных значений - вы лучше ответьте, зачем вместо типа из стандарта использовать что-то другое?
С вероятностью 95% дело в конфигурации, а не в нас, CODESYS или ОВЕН. Выше предложил, как это точно проверить.
Потому что это удобно - отправить один короткий Modbus-пакет, и знать, что сейчас воспроизведётся конкретный ИК-сигнал. Логика в коде получается простейшая - чтобы воспроизвести ИК-сигнал N, запиши один coil c номером N+M.
Это называется “непрямая адресация” и нужно это, если вы живёте в 1970-м году и ОЗУ в вашем микроконтроллере 16 байт. Плюсов нет вообще.
С прямой адресацией, как у нас, одному coil-у соответствует один канал. Нужно включить кондей - запишите единичку в coil “кондей”. Нужно включить “бризер” - пишете в coil “бризер”.
При этом “посылочка” в случае непрямой адресации длиннее на целых два байта по сравнению с тем, как сделано сейчас.
Конфигурация:
вся конфигурация делается через Modbus регистры. Если вы сейчас как-то умеете записывать Modbus-регистры (из ОВЕН или Windows), просто откройте карту регистров и запишите нужный. Если не умеете - зачем вы покупаете устройство с Modbus?
Обновление прошивки и сброс адреса:
В наших контроллерах есть консольная утилита, которая вызывается так: wb-mcu-fw-updater update-all
и сама скачивает и обновляет прошивки всем устройстам, если нужно. Сейчас делаем на её основе интерфейс в веб-интерфейсе контроллера Wiren Board. Она же есть под Windows: Обновление прошивки Modbus-устройств Wiren Board — Wiren Board
Через ту же утилиту можно сбросить параметры на “по умолчанию”, если не знаем ни адреса, ни скорости.
Это же мы уже перепрыгнули с датчика WB-MSW v.3 на контроллер Wiren Board 6? Эмулятора не будет, IDE - в веб-интерфейсе, будем его развивать. Отладка сейчас только через логирование через функцию log() в окошко в том же интерфейсе, “циклов” в наших скриптах нет - там JavaScript и событийная модель. Текстовые файлики и grep - это, конечно, наше всё, только для разработки вам это не потребуется.
В вашем вопросе чувствуется пренебрежение и недоверие к новым для мира автоматизации технологиям. Но это не значит, что придётся заставлять себя страдать: на Wiren Board 6 сейчас официально работают рантаймы MasterSCADA, Каскад, ISaGRAF. Эти среды близки к CODESYS по принципам работы, там те же самые МЭК-овские языки программирования, в т.ч. визуального.
На производстве калибруется только датчик уровня шума, остальные только проверяются. Бумаги не будет, потому что это бессмысленно. Наклейка с серийником и надписью “OK” свидетельствует о прохождении проверки на производстве на автоматизированном стенде. Если мы её на листе A3 напечатаем и подпишем всей компанией, то смысла в ней больше не станет.
Когда включим датчики в госреестр средств измерения, тогда будем вкладывать бумаги о поверке - вот это уже осмысленное действие. Кстати, две недели назад в госреестр СИ включили наши многоканальные счётчики электроэнергии на разъёмных трансформаторах WB-MAP - к ним теперь может прилагаться бумага о поверке.
Очень давно стоит в планах, сейчас уже в разработке, релиз такой прошивки для WB-MSW планируем в течение пары недель.
Возвращать, правда, он будет не нули, а прописанные в документации “запрещённые значения”: 0xfffe для беззнаковых, и 0x7ffe для знаковых - это нужно, чтобы понять, что регистра действительно нет.
А что от чего вы собрались изолировать? Датчик в пластиковом корпусе, внешних проводов не подключается, питание идет по тому же кабелю.
Специальная микросхема-приёмопередатчик RS-485 . В ваших экземплярах стоит ST485EB.
Между байтами данных в посылке передатчик включен естественно, ведь между ними нет никакого промежутка: после стопового бита одного байта начинается стартовый бит другого. Когда передатчик не передаёт, то он, естественно, выключен, иначе бы никакое другое устройство, включая ваш ПЛК не смогло бы ничего передать в линию.
Вообще вопрос весьма странный, кажется вы пытались спросить не то, что спросили. Что именно вызывает у вас беспокойство?
Нет, не делаем. А в чём смысл? Имелось в виду, для борьбы с контроллерами, где разработчики забыли сделать растяжку (failsafe bias)?
Мы входящий пакет детектируем по 3.5 символам тишины после него, как написано в стандарте. Если ещё и ждать после этого 3.5 символа после ответа, то это будет дополнительная задержка в 3.5 символа.
Естественно так. Независимо от внутренней реализации конкретного регистра в конкретном устройстве, тормозов перед отправкой ответа нет никогда, т.е. никаких долгих операций перед ответом не делается.
Строго говоря, к стандарту это отношения не имеет. По стандарту устройства могут “думать” сколько им вздумается, пока это не больше таймаута, и могут при каждом чтении “думать” разное время.
Это неправильное поведение, давайте разбираться. Это же, наверное, опять ошибка таймаута (ответ не пришёл), а не в регистре значение ноль?
Не перевирайте. Это были не аргументы, а совет, как уменьшить частоту опроса без потери реальных данных. Чтобы у вас всё заработало в условиях, когда вы не знаете, что и когда фактически у вас отправляется в линию, и пытаетесь посылать запросы чаще, чем они физически могут идти.
Буфер, разумеется, заранее подготовлен.
Что дальше делать с оборудованием
Как уже неоднократно писал, давайте встретимся и проверим все ваши проблемы. Согласны/не согласны - напишите здесь, потом по телефону согласуем детали.
Что дальше делать с вашим хамством
Как уже писал, мы в таком тоне не общаемся. Суть наших ответов не поменяется, если вы напишете вежливо.
Если хотите привлекать таким способом аудиторию - на здоровье, но только у себя в блоге. Хотя, честно говоря, не понимаю, как вашим читателям может нравиться такое отношение:
– даже если лично вам не нравится датчик.
Последний раз призываю вас к банальной вежливости. Если этого не случится, со следующего вашего сообщения мы каждый эпизод хамства будем менять на остроумное выражение на наш выбор.
Считайте это нашей версией
Так, отлично. Я третий раз говорю: “Если нужно проконсультироваться - звоните” и первый раз говорю прямо: “Да, берите осцилл и логический анализатор и заезжайте буду раз вас видеть”.
“Заезжайте” - потому что у меня сейчас всё это стоит на тестах, и все те вещи, про которые я пишу, можно увидеть там, а не где-то на столе.
Предлагаю провести следующие тесты и отфоткать:
Монтаж датчика спецкабелем. Очень, чёрт подери, прошу: НЕ НАДО ПРО ВИТУЮ ПАРУ. Линии RS-485 необходимо монтировать спецкабелем. И точка, Мне нужна надёжность, а не баловство. И когда линия идёт по огромному дому - я буду её прокладывать спецкабелем и буду жёстко ругаться на те случаи, когда он не лезет.
Сбор всех посылок по всей линии логически анализатором в нескольких режимах:
а) Один датчик на линии
б) Несколько датчиков от Wiren
в) Несколько датчиков от Wiren, но один отключен (а ПЛК пытается до него достучаться)
Дальше из этого и будет понятно, что там было со скоростью работы и временем по Modbus. Мы с камрадом тестировали и собирали данные при помощи осциллографа на 1М семплов и простенького анализатора Saleae. Увидели следующее:
а) Никакие посылки в линии НЕ тормозят. CodeSys их рулит по времени так, что линия не забивается. Требуется это подтвердить вашей техникой. Файлы от Saleae могу заслать (скажите, куда).
б) В момент, когда на линии есть дохлое устройство (отключенный датчик), ответы от остальных датчиков идут нормально и полностью. Но на скриншотах, которые были в начале тутошнего общения были факты того, что в этот момент именно один регистр Wiren проваливается и именно в ноль, а не 0xFFFF. И я писал про это уже раза три. Требуется это подтвердить, но ждать понадобится 1-3 часа. Глюк плавающий.
По поводу хамства. Мне кажется, вы путаете. Это не хабалистое хамство, а злая (злобная) ненависть вида “горите в аду”. Хамства я за собой не набюдаю. Я больше злобный, ченм хамоватый. И я про это ПРЕДУПРЕЖДАЛ. Что не так?
Мелкие детали, чтобы продолжать думать:
а) Про погрешности. Датчики висят в середине комнаты около щита. Дышу я в другом месте, по диагонали. И работают эти датчики с тех пор, как я первый раз написал в этом посте. По VOCам бывают значения (на трёх датчиках): 210 - 0 - 80. Это укладывается в норму?
Вопрос не в том, почему VOC при работе со спиртом (например, флюс смыть с мелкого места пайки) показывает безумные цифры, а то почему на трёх датчиках, стоящих рядом в одном месте, показания разные.
По остальному. Если вы до меня доезжаете (жду мыла или звонка Anytime), то всё остальное - про кабели, монтаж, CodeSys, событийные обработки, можно ли в НШВИ зажимать моножилу (нельзя), погрешности и точности - обсудим на месте.
Про непрямую адресацию задело. Какие нафик 70ые года? Что за намёки? Если переходить на личности как компания к компании, то я могу разозлиться и сказать, что вы крайне не уважаете своих клиентов, если заставляете их в XXI веке вручную крутить регистры на свой страх и риск, лазая по трём ссылкам на Wiki (вместо одного единого PDF со всей картой), переводить DEC/HEX, чтобы эти регистры правильно посчитать - и это вместо удобного конфигуратора, который найдёт устройство автоматически, в котором можно всё нащёлкать галочками, а потом одним кликом записать в устройство. Или сохранить в файл и записать потом в 200 устройств.
Про регистры и Coils. Мои заказчики интересуются вашими датчиками. Если надо будет устроить войну протиы Coils (чтобы для таких как мы и наших ПЛК сделали работу с ИК-командами без Coils) - я буду её устраивать. Мы хотим, чтобы мы писали в датчик два регистра. Аргументирую. Чтобы к хамству (хех) не придрались, поясняю: далее будет не хамство, а тыканье носом в несколько другую жизнь, в которой нет работы по событию и нет тулзы для отправки комапд modbus из командной строки.
а) В некоторых ПЛК есть ограничение на количество регистров, которые можно добавить в устройство, которое он будет опрашивать. Конкретно у CodeSys v3 есть ограничение в 30 штук. То есть, я просто физически не смогу вписать много регистров для ИК-команд. Понимаете?
б) У SIEMENS и ОВЕН по умолчанию все данные гоняются по шине постоянно. Чтобы выдавать их разовыми посылками - нужно мудрить и усложнять программу. Нет событийки, нету её. В промке немного по другому это всё.
Вопрос, на который мне не ответили: что будет если я прям подряд запишу все Coils для всех 80 ИК-команд равными “1” (TRUE)? Что будет делать датчик (выполнит одну какую-то, сдохнет, пытаясь выполнить все, зависнет, проигнорирует это)?
Личное. Перешёл на сам Wiren, когда пытался вам мягко донести то, почему я тут, хм, хамлю и ругаюсь. Спасибо что сделали акцент на том, что у вас всё работает из-за того, что вы применяете событийную модель. Теперь я понял, что именно я дьявольски до горения в аду ненавижу в ваших устройствах и концептах: именно её.
И ещё я понял, за что я вас ненавижу: за то, что вы с этим концептом событий ведёте себя даже сейчас как снобы: “А что? Вот мы протестировали датчик на столе, вот скриптик, у нас всё работает, а остальное уже ваши проблемы”. Как мне быть? Можно я тоже посчитаю это наглым и неприкрытым хамством и унижением моего достоинства? А?
Поэтому, либо вы тоже перестаёте хамить, либо будет драка.
Про отладку. Я не понял, я туплю. Вот например я раз в 1 сек собираю инфу с аналогового выхода с датчика давлениия в массив. И вычисляю там что-нибудь. Положим, некий тренд. И решаю, куда у меня этот тренд идёт: на рост или спад и насколько быстро.
Для этого мне нужен цикл. Вот как без издёвочек про “текстовые файлики это наше всё, но вам это не потребуется” это отладить? Пройти цикл по шагам, посмотреть значения переменных? Вы надо мной издеваетесь, что ли? Не понимаю!
В общем, жду звонка или мыла. Контакты я оставлял. При звонке просьба представиться, чтобы я знал, с кем имею честь, чёрт побери.
Стоп. Событийная модель - она в контроллере Wiren Board 6. Во всех наших исполнительных устройствах, счётчиках и датчиках с Modbus RTU - обычный стандартный Modbus RTU, ничего событийного там нет. Более того,
Несмотря на то, что мы разрабатывали исторически одновременно и контроллер и периферийные устройства, мы осознанно заложили между ними Modbus RTU и RS-485 - чтобы устройства по отдельности были совместимы со сторонними ПЛК, а наши контроллеры - со сторонней периферией.
Мы очень ревностно относимся к стандарту Modbus RTU в периферийных устройствах: там везде правильные задержки, правильные ошибки, правильное поведение по стандарту.
Карты регистров документированы в подробностях, включая все служебные регистры
Большинство регистров следуют “духу” Modbus: регистры это общая память, синхронных операций нет. Поэтому вы, например, можете из датчиков читать температуру хоть 100 раз в секунду и это нормально.
То есть из всей функциональности всех наших устройств хоть какое-то обсуждение может быть у реализации отправки ИК команд в WB-MSW v.3: ну потому что нам нужно вызывать именно одиночные события отправки, а идемпотентный Modbus для этого не приспособлен. Но это чисто дело вкуса: в предложенном вам варианте с непрямой адресаций тоже события неявно есть, и их там не меньше, чем в наших коилах.
…А вот в наших контроллерах Wiren Board 6 действительно уже событийная модель. У нас реализован очень серьёзный и очень сложный сервис опроса устройств по Modbus и похожим протоколам, который сам придумывает, как правильно группировать регистры в запросы, с какой периодичностью и какие команды отправлять, как долго от какого устройства ждать ответы, как потом конвертировать данные. И вот этот сервис уже генерирует события. Очень сильно упрощая и возвращаясь к нашей любимой температуре, обновляющейся раз в две секунды: наш сервиc wb-mqtt-serial будет считывать регистр температуры 100 раз в секунду, и вот только когда значение в нём поменяется - сгенерирует событие
Вовсе не издеваемся. Вот накидал пример: правило считает производную (скорость изменения) значения температуры процессора контроллера и усредняет её по трём последним значениям. В процессе выводит много отладки.
var der_previous_values = [];
var prev_event_time = null;
var prev_event_temperature = null;
defineRule({
whenChanged: "hwmon/CPU Temperature",
then: function(temperature) {
var current_time = new Date();
// отладка
log("В {} пришла новая температура: {}".format(current_time, temperature));
if (prev_event_time != null ) {
// первую точку выкинули
// смотрим, куда идёт тренд - считаем производную
// прошло секунд с прошлого раза
var delta_time = (current_time.getTime() - prev_event_time.getTime()) / 1000;
// температура поменялась на
var delta_temperature = temperature - prev_event_temperature;
// производная:
var temperature_derivative = delta_temperature / delta_time;
// отладка
log("Текущая скорость изменения температуры {} градусов в секунду".format(temperature_derivative));
// Задачка со звёздочкой: будем считать среднюю производную
// добавим текущую производную в список
der_previous_values.unshift(temperature_derivative);
// слишком старое удаляем, оставляем не больше трёх значений
if (der_previous_values.length > 3) {
der_previous_values.pop();
}
// отладка: выведем список значений производной
log("значения в списке:", der_previous_values);
// теперь посчитаем среднее по этим значениям
var sum = 0.0;
for (var i=0; i<der_previous_values.length; i++) {
sum += der_previous_values[i];
}
average_derivative = sum / der_previous_values.length;
log("Cредняя скорость изменения температуры {} градусов в секунду".format(average_derivative));
// тут мы бы в реальной задаче что-нибудь сделали бы с average_derivative -
// вывели бы её в какое-нибудь устройство,например
}
// эти значения нам будут нужны при следующем событии - считать скорость изменения
prev_event_time = current_time;
prev_event_temperature = temperature;
}
});
В логе будет такое:
2020-09-15 22:43:15 В 2020-09-15 19:43:15.065+00:00 пришла новая температура: 60.872
2020-09-15 22:43:25 В 2020-09-15 19:43:25.089+00:00 пришла новая температура: 54.792
2020-09-15 22:43:25 Текущая скорость изменения температуры -0.6065442936951315 градусов в секунду
2020-09-15 22:43:25 значения в списке: -0.6065442936951315
2020-09-15 22:43:25 Cредняя скорость изменения температуры -0.6065442936951315 градусов в секунду
2020-09-15 22:43:35 В 2020-09-15 19:43:35.061+00:00 пришла новая температура: 55.4
2020-09-15 22:43:35 Текущая скорость изменения температуры 0.0609707180104289 градусов в секунду
2020-09-15 22:43:35 значения в списке: 0.0609707180104289,-0.6065442936951315
2020-09-15 22:43:35 Cредняя скорость изменения температуры -0.27278678784235133 градусов в секунду
2020-09-15 22:43:45 В 2020-09-15 19:43:45.046+00:00 пришла новая температура: 52.36
2020-09-15 22:43:45 Текущая скорость изменения температуры -0.30445668502754125 градусов в секунду
2020-09-15 22:43:45 значения в списке: -0.30445668502754125,0.0609707180104289,-0.6065442936951315
2020-09-15 22:43:45 Cредняя скорость изменения температуры -0.2833434202374146 градусов в секунду
2020-09-15 22:43:55 В 2020-09-15 19:43:55.096+00:00 пришла новая температура: 53.576
2020-09-15 22:43:55 Текущая скорость изменения температуры 0.12099502487562198 градусов в секунду
2020-09-15 22:43:55 значения в списке: 0.12099502487562198,-0.30445668502754125,0.0609707180104289
2020-09-15 22:43:55 Cредняя скорость изменения температуры -0.04083031404716346 градусов в секунду
2020-09-15 22:44:05 В 2020-09-15 19:44:05.062+00:00 пришла новая температура: 58.44
2020-09-15 22:44:05 Текущая скорость изменения температуры 0.4880594019666865 градусов в секунду
2020-09-15 22:44:05 значения в списке: 0.4880594019666865,0.12099502487562198,-0.30445668502754125
2020-09-15 22:44:05 Cредняя скорость изменения температуры 0.10153258060492241 градусов в секунду
2020-09-15 22:44:15 В 2020-09-15 19:44:15.079+00:00 пришла новая температура: 59.048
2020-09-15 22:44:15 Текущая скорость изменения температуры 0.060696815413796956 градусов в секунду
2020-09-15 22:44:15 значения в списке: 0.060696815413796956,0.4880594019666865,0.12099502487562198
2020-09-15 22:44:15 Cредняя скорость изменения температуры 0.22325041408536847 градусов в секунду
2020-09-15 22:44:25 В 2020-09-15 19:44:25.067+00:00 пришла новая температура: 59.656
2020-09-15 22:44:25 Текущая скорость изменения температуры 0.060873047657188324 градусов в секунду
2020-09-15 22:44:25 значения в списке: 0.060873047657188324,0.060696815413796956,0.4880594019666865
2020-09-15 22:44:25 Cредняя скорость изменения температуры 0.20320975501255725 градусов в секунду
2020-09-15 22:44:45 В 2020-09-15 19:44:45.059+00:00 пришла новая температура: 60.264
2020-09-15 22:44:45 Текущая скорость изменения температуры 0.03041216486594658 градусов в секунду
2020-09-15 22:44:45 значения в списке: 0.03041216486594658,0.060873047657188324,0.060696815413796956
2020-09-15 22:44:45 Cредняя скорость изменения температуры 0.05066067597897728 градусов в секунду
2020-09-15 22:45:25 В 2020-09-15 19:45:25.077+00:00 пришла новая температура: 60.872
2020-09-15 22:45:25 Текущая скорость изменения температуры 0.015193163076615447 градусов в секунду
2020-09-15 22:45:25 значения в списке: 0.015193163076615447,0.03041216486594658,0.060873047657188324
2020-09-15 22:45:25 Cредняя скорость изменения температуры 0.03549279186658345 градусов в секунду
2020-09-15 22:45:35 В 2020-09-15 19:45:35.119+00:00 пришла новая температура: 60.264
2020-09-15 22:45:35 Текущая скорость изменения температуры -0.06054570802628929 градусов в секунду
2020-09-15 22:45:35 значения в списке: -0.06054570802628929,0.015193163076615447,0.03041216486594658
2020-09-15 22:45:35 Cредняя скорость изменения температуры -0.004980126694575753 градусов в секунду
2020-09-15 22:45:55 В 2020-09-15 19:45:55.063+00:00 пришла новая температура: 60.872
2020-09-15 22:45:55 Текущая скорость изменения температуры 0.03048535900521445 градусов в секунду
2020-09-15 22:45:55 значения в списке: 0.03048535900521445,-0.06054570802628929,0.015193163076615447
2020-09-15 22:45:55 Cредняя скорость изменения температуры -0.00495572864815313 градусов в секунду
2020-09-15 22:46:15 В 2020-09-15 19:46:15.100+00:00 пришла новая температура: 60.264
2020-09-15 22:46:15 Текущая скорость изменения температуры -0.030343863851873883 градусов в секунду
2020-09-15 22:46:15 значения в списке: -0.030343863851873883,0.03048535900521445,-0.06054570802628929
2020-09-15 22:46:15 Cредняя скорость изменения температуры -0.02013473762431624 градусов в секунду
Лог можно посмотреть прямо рядом с редактором скриптов. Как отладите, отключить.
Я ж задал дополнительные вопросы. Выше там по тексту. Без ответа остался вопрос о том, что будет если послать сразу 80 команд на вопроизведение ИК (Write Multiple Coils), без ответа остался вопрос про то, почему при отключенном устройстве на линии (любом) у датчика валится один из регистров в ноль (сейчас отключу один датчик и ещё раз посмотрю, будет ли или нет), почему при подключении терминатора и в линию один из датчиков даёт ошибки CRC.
Касательно адресации команд. Как же ж она непрямая-то? Прямая: есть регистр адреса и регистр команды. Раз речь пошла про 70ые, то тут - да - можно вспомнить всякие извраты на MCS-51 и Z-80 типа таблицы указателей перехода на подпрограммы и прочие такие штучки, которыми чуваки типа DI HALT обожают до сих пор пользоваться.
Но это ж не относится к тому, о чём говорю я.
Вы простебали меня про то, что я якобы предлагаю сделать указатель на указатель, а я имел ввиду прямое указание. Если образно, то регистр с названием “ГДЕ ДЕЛАТЬ” (место) и регистр с названием “ЧТО ДЕЛАТЬ” (действие). Считаю стёбчик не засчитанным.
Вопрос применимости этого решения зависит от того, как у вас устроено выполнение ИК-команд. Спрашиваю ещё раз. ЧТО будет, если я одновременно пришлю Write Coils на исполнение ИК-комад сразу на штук 10-20 их?
Если датчик поставит их в очередь и будет исполнять друг за другом - то моя идея может обломиться, так как она позволяет послать за один раз одну команду. Если же датчик исполнит одну команду (потому что в один момент времени он может передавать только одно) - то моя идея очень применима, потому что позволяет за один раз как раз-таки жёстко ограничить посылку только одной команды. И защитит от разных дундуков.
Вы тут до меня докапывались и уже не знали, к чему придраться. И что я флужу, и что провоцирую. Ну так доезжайте до меня. Я приготовил для вас спецкабели для RS-485, и можем прям на видео заснять: прикрутить датчик к куску ДСП или фанеры, сымитировав что он закреплен на стене жёстко, и попробовать смонтировать этот кабель.
Мои требования такие (как у террориста, блин):
Собрать ВСЕ инструкции, таблицы регистров, инфу про обновление прошивки, изменение сетевых настроек датчика в ОДИН документ и выложить его ссылкой на сайте с описанием товара.
Жёстко прописать в инструкции примеры монтажа датчика с риснуками того, как надо правильно разделывать кабель и подключать его в разъём для многожильных кабелей с моножилой и многожильных кабелей с многопроволочной жилой. И не забудьте прорисовать соединение экрана (drain-проводника) в кабеле, так как это тоже важно и на это нужна ловкость рук.
Доапгрейдить прошивку датчика так, чтобы регистры были доступны или подряд, или же те, которые не задействованы возвращали не ошибку, а что-то пустое типа 0xFFFF (тут это предлагалось, я согласен). Короче, чтобы можно было брать и читать все регистры с 0 по NN (сейчас не хочу искать конечный номер; важен принцип) одним запросом.
Добавить в документацию более точную информацию про управление внешними светодиодами датчика. Там есть некие “длительность и период”, но не сказано о том, что они означают и где и них минимум или максимум.
Добавить в прошивку то, что предлагаю я: управление ИК-командами при помощи двух-трёх регистров (WORD). Для совместимости оставьте Coils как есть, я не против. Но это - добавьте. Пусть даже это будет просто костыль, который внутри прошивки будет дёргать Coils так, как будто команда пришла по ним.
Пожелание. Добавить в прошивку возможность управлять индикаторным светодиодом датчика: включать или выключать его. В полной темноте напротив кровати его всё равно видно.
Прикладывать к датчику бумажку (хоть самописную), которая называется “Паспорт” с серийным номером датчика, с данными о том, что все внутренние датчики проверены и протестированы. И с их допустимыми погрешностями. Хоть липовую - но чтобы была. Потому что по некоторым договорам и судам она ТРЕБУЕТСЯ. Требуется показать, что “Вот документ, предоставленный производителем, вот допустимые погрешности, вот в документе серийный номер именно этого датчика”.
EvgenyBoger, вот с тобой общение идёт как-то легче и техничнее, чем с poglazov. Тут и техничная инфа, и понятные пояснения. Правда, спасибо! Вот тебя я точно буду рад у себя видеть.
Это укладывается в норму, соответствует уровню “Хорошо”. Как можно заметить по таблице Универсальный настенный датчик WB-MSW v.3 — Wiren Board, шкала для концентрации VOC скорее логарифмическая. Для разных помещений нашего офиса, которые мало чем отличаются, разброс составляет 120-180. И ещё раз призываю выдержать рекомендации, которые написаны выше.
Вы про это?
Если да: у КИС-В многопроволочная жила.
Обе темы лишь про то, что в конфигураторе CODESYS нет Modbus-функции 0x05. Во второй вам инженер ОВЕН явно написал, что нужно использовать функцию 0x0F (Write Multiple Coils) для работы с coil, и coil будут работать. Так что либо инженер ОВЕН врёт, либо вы.
Контекст был в том, что весь модбас у нас самый-самый стандартный, никаких событий там нет и никаких вариантов по реализации тоже. За исключением, возможно, коилов управления ИК, которые мы тут и обсуждаем. Т.е. обобщение “мне не нравится управление ИК через коилы” до “во всех ваших устройствах не модбас, а событийное непонятно что” - неправильное.
Непрямая: вместо того, чтобы передать адрес и команду в нужных полях протокола Modbus, вы предлагаете использовать команду “запись регистра хранения”, и через неё уже писать адрес и команду.
Вот есть тут поле “адрес” в Modbus-посылке. Если там адрес - это прямая адресация, если там всегда одно и то же, а адрес вы пишете в поле данных - это непрямая адресация.
Ну и Modbus вообще по истории и логике - это очевидный прозрачный протокол для доступа к последовательной памяти контроллера. Поэтому там есть адреса, смещения и т.д. Так что “указатель” в вашей терминологии соответствует как раз адресу регистра Modbus.
. В ваших экземплярах стоит ST485EB.
