Добрый день!
Как всегда, много эмоций и мало сути.
Вы посмотрели, что в действительности происходит в линии? Обещали, что осциллографом посмотрите. Без этого разговор бессмысленен - вы просите от
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 и систем мониторинга, чем битовые маски.
Это специализированный тип данных для дискретных значений - вы лучше ответьте, зачем вместо типа из стандарта использовать что-то другое?
А вы не обманываете? Про поддержку coil в Codesys_v2399 c сайта ОВЕН: https://owen.ru/uploads/139/rp_plk110_m02__16.pdf
С вероятностью 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 для знаковых - это нужно, чтобы понять, что регистра действительно нет.
TVS-диоды + самовосстанавливающиеся предохранители (PTC).
А что от чего вы собрались изолировать? Датчик в пластиковом корпусе, внешних проводов не подключается, питание идет по тому же кабелю.
Специальная микросхема-приёмопередатчик RS-485 
. В ваших экземплярах стоит ST485EB.
Между байтами данных в посылке передатчик включен естественно, ведь между ними нет никакого промежутка: после стопового бита одного байта начинается стартовый бит другого. Когда передатчик не передаёт, то он, естественно, выключен, иначе бы никакое другое устройство, включая ваш ПЛК не смогло бы ничего передать в линию.
Вообще вопрос весьма странный, кажется вы пытались спросить не то, что спросили. Что именно вызывает у вас беспокойство?
Нет, не делаем. А в чём смысл? Имелось в виду, для борьбы с контроллерами, где разработчики забыли сделать растяжку (failsafe bias)?
Мы входящий пакет детектируем по 3.5 символам тишины после него, как написано в стандарте. Если ещё и ждать после этого 3.5 символа после ответа, то это будет дополнительная задержка в 3.5 символа.
Естественно так. Независимо от внутренней реализации конкретного регистра в конкретном устройстве, тормозов перед отправкой ответа нет никогда, т.е. никаких долгих операций перед ответом не делается.
Строго говоря, к стандарту это отношения не имеет. По стандарту устройства могут “думать” сколько им вздумается, пока это не больше таймаута, и могут при каждом чтении “думать” разное время.
Это неправильное поведение, давайте разбираться. Это же, наверное, опять ошибка таймаута (ответ не пришёл), а не в регистре значение ноль?
Не перевирайте. Это были не аргументы, а совет, как уменьшить частоту опроса без потери реальных данных. Чтобы у вас всё заработало в условиях, когда вы не знаете, что и когда фактически у вас отправляется в линию, и пытаетесь посылать запросы чаще, чем они физически могут идти.
Буфер, разумеется, заранее подготовлен.
Что дальше делать с оборудованием
Как уже неоднократно писал, давайте встретимся и проверим все ваши проблемы. Согласны/не согласны - напишите здесь, потом по телефону согласуем детали.
Что дальше делать с вашим хамством
Как уже писал, мы в таком тоне не общаемся. Суть наших ответов не поменяется, если вы напишете вежливо.
Если хотите привлекать таким способом аудиторию - на здоровье, но только у себя в блоге. Хотя, честно говоря, не понимаю, как вашим читателям может нравиться такое отношение:
– даже если лично вам не нравится датчик.
Последний раз призываю вас к банальной вежливости. Если этого не случится, со следующего вашего сообщения мы каждый эпизод хамства будем менять на остроумное выражение на наш выбор.
Считайте это нашей версией
и
Так, отлично. Я третий раз говорю: “Если нужно проконсультироваться - звоните” и первый раз говорю прямо: “Да, берите осцилл и логический анализатор и заезжайте буду раз вас видеть”.
“Заезжайте” - потому что у меня сейчас всё это стоит на тестах, и все те вещи, про которые я пишу, можно увидеть там, а не где-то на столе.
Предлагаю провести следующие тесты и отфоткать:
- Монтаж датчика спецкабелем. Очень, чёрт подери, прошу: НЕ НАДО ПРО ВИТУЮ ПАРУ. Линии RS-485 необходимо монтировать спецкабелем. И точка, Мне нужна надёжность, а не баловство. И когда линия идёт по огромному дому - я буду её прокладывать спецкабелем и буду жёстко ругаться на те случаи, когда он не лезет.
- Сбор всех посылок по всей линии логически анализатором в нескольких режимах:
а) Один датчик на линии
б) Несколько датчиков от Wiren
в) Несколько датчиков от Wiren, но один отключен (а ПЛК пытается до него достучаться)
Дальше из этого и будет понятно, что там было со скоростью работы и временем по Modbus. Мы с камрадом тестировали и собирали данные при помощи осциллографа на 1М семплов и простенького анализатора Saleae. Увидели следующее:
а) Никакие посылки в линии НЕ тормозят. CodeSys их рулит по времени так, что линия не забивается. Требуется это подтвердить вашей техникой. Файлы от Saleae могу заслать (скажите, куда).
б) В момент, когда на линии есть дохлое устройство (отключенный датчик), ответы от остальных датчиков идут нормально и полностью. Но на скриншотах, которые были в начале тутошнего общения были факты того, что в этот момент именно один регистр Wiren проваливается и именно в ноль, а не 0xFFFF. И я писал про это уже раза три. Требуется это подтвердить, но ждать понадобится 1-3 часа. Глюк плавающий.
По поводу хамства. Мне кажется, вы путаете. Это не хабалистое хамство, а злая (злобная) ненависть вида “горите в аду”. Хамства я за собой не набюдаю. Я больше злобный, ченм хамоватый. И я про это ПРЕДУПРЕЖДАЛ. Что не так?
Далее. У CodeSys v2 штатно нет поддержки Coils на уровне конфигурации ПЛК (вот одна из тем, где народ спрашивал: https://owen.ru/forum/showthread.php?t=29780, вот свежая https://owen.ru/forum/showthread.php?t=33662). Нужно брать билиотеку работы с портами и ручками писать свою реализацию Modbus на уровне “отправить байты - принять байты”.
Мелкие детали, чтобы продолжать думать:
а) Про погрешности. Датчики висят в середине комнаты около щита. Дышу я в другом месте, по диагонали. И работают эти датчики с тех пор, как я первый раз написал в этом посте. По 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 раз в секунду, и вот только когда значение в нём поменяется - сгенерирует событие
/devices/wb-msw-v3_25/controls/Temperature 22
Вовсе не издеваемся. Вот накидал пример: правило считает производную (скорость изменения) значения температуры процессора контроллера и усредняет её по трём последним значениям. В процессе выводит много отладки.
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 будут работать. Так что либо инженер ОВЕН врёт, либо вы.
https://owen.ru/forum/showthread.php?t=22220
Кажется, вы опять либо обманываете, либо упёрлись в ограничение, которое инженеры ОВЕН убрали ещё в 2015 году.
Про длительность и период подробнее здесь, с минимумами и максимумами: Управление датчиками Wirenboard по протоколу Modbus — Wiren Board, регистры 97-98.
Выполнится только первая.
То есть я теперь переговорщик получается 
Контекст был в том, что весь модбас у нас самый-самый стандартный, никаких событий там нет и никаких вариантов по реализации тоже. За исключением, возможно, коилов управления ИК, которые мы тут и обсуждаем. Т.е. обобщение “мне не нравится управление ИК через коилы” до “во всех ваших устройствах не модбас, а событийное непонятно что” - неправильное.
Непрямая: вместо того, чтобы передать адрес и команду в нужных полях протокола Modbus, вы предлагаете использовать команду “запись регистра хранения”, и через неё уже писать адрес и команду.
Вот есть тут поле “адрес” в Modbus-посылке. Если там адрес - это прямая адресация, если там всегда одно и то же, а адрес вы пишете в поле данных - это непрямая адресация.
Ну и Modbus вообще по истории и логике - это очевидный прозрачный протокол для доступа к последовательной памяти контроллера. Поэтому там есть адреса, смещения и т.д. Так что “указатель” в вашей терминологии соответствует как раз адресу регистра Modbus.
Господи, я всё прочитал!)))
Это было как триллер, ей-богу!))) Но кто “убийца”, пока не ясно - рекламная пауза!))
Извините, что оффтоп, но удержаться не могу).
Что могу сказать. Во-первых, что заочно(я еще не купил ни одного устройва WB) я могу сказать, что я “влюбился” в WB с момента прочтения первой статьи, как они появились на хабре и компания только создавалась; молодцы: берут, делают, сложно, трудно, переделывают! Улучшают и т.д.!
Ну и ещё конечно, за то, что могут выдержать такой скажем, формат обращения в техподдержку от CS. Я думаю, многие, кто знает “формат” общения довольно токсичного CS-CS - знают, как непросто с ним общаться, во всяком случае, в интернете.
Так как тема в общем обсуждении, я тоже позволю сказать для CS-CS что формат общения с оскорблениями и “эпитетами” не считаю приемлемым, несмотря на “предупреждения” с твоей стороны (это ведь не даёт тебе автоматически право это делать?).
По существу проблемы и т.д. хотелось бы увидеть в конце “развязку” всего здесь описанного, в любом случае, пока читал - форум автоматически меня “подписал” на эту тему)
Насколько я смог понять - WB-MSW практически не вносит задержку в ответе (±10мсек на обработку “пакета”) в синтетических тестах?
Что могу сказать из опыта и подчеркнуть важность тестов именно “в шине”, а еще лучше - “в поле” и всё-таки выяснить реальную причину проблем (если таковые были) - из своей практики сталкивался с наладкой Modbus-линии вент. установок, может быть несколько десятков установок в шлейфе. Шлейф протянут по всему зданию от установки-к-установке. Естесстенно, с нуля ничего не “поднялось” Поиск неисправной линии, полярности, адресов и т.д. и т.п. отнимает много времени.
Но самое главное, что было обнаружено: контроллер вентустановки не был способен отвечать достаточно быстро, плюс было какое-то девиантное поведение именно в шлейфе, там были несколько разных производителей кажется, и вот одно устройство “на столе” отвечало быстро, когда же опрашивали цикл в “шлейфе” всё падало таймаутами и т.д., хотя каждое устройтво по отдельности работало, кажется исправно.
В-общем, танцы с бубном никакие не помогли - цикл опроса составлял действительно, порядка может быть 2х секунд на устройство, при 20 установках - 40 секунд на ЧТЕНИЕ!!! даже если запись была “приоритетом”, то обратная связь - всё равно до 40 секунд! это было ужасно.
В качестве предположения было то, что в вентустановках стояли какие-то дохлые МК, которые “долго” отвечали на запросы. Плюс, как предположение - возможно, МК, адрес которого не равнялся адресу в пакете запроса всё равно как-то “долго” обрабатывал этот запрос и к моменту посылки следующего запроса уже непосредственно ему еще “раздумывал” над предыдущим пакетом… но это неточно.
Я к чему - да, действительно, как по мне - важно, чтобы устройство опрашивалось и записывалось на максимально доступной технически скорости, независимо от скорости считывания данных из поля и т.д.
Ну, и конечно, поддерживаю CS-CS в плане того, что конечно же, нужен некий более удобоваримый конфигуратор всего этого добра. Не помешал бы и Ethernet с веб-мордой на борту и Modbus TCP. 21й век же)
Кстати, кто может сказать, как в Ethernet\TCP устроен модбас, там тоже поллинг? Я имею ввиду, на стороне мастера как это выглядит, я туда не углублялся по этому поводу. Хотя, по идее, модбас-мастер может слать запросы на чтение с такой скоростью каждому слейву, с которой только может, не нужно дожидаться ответа от каждого… или нужно? как там в Ethernet всё устроено?
Меня тоже дико “бесит” поллинг в модбасе, может быть, модбас TCP позволяет опрашивать разные девайсы асинхронно? Ну и вообще TCP позволяет любую топологию строить, звезда, шлейф, дерево… Я - за Ethernet)
И да. Запись\чтение циклически - это тоже имеет место быть и должно быть. Никакого “по событию”.
Кстати, вопрос в зал: а кто-нибудь встречал модбас-программку где каждому опрошенному полю можно давать “имя”, в таком случае можно было бы готовить карты регистров под каждое устройство в виде файлов-шаблонов… Всё легче было бы. Линукс, командная строка для настройки модбаса - это жестоко…
Teemon, Я быстро. Вот прямо сейчас жду ребят из WB. Будем смотреть как раз в поле. С приборами. Дальше отпишусь.
Про поле и было одной из моих претензий. На столе любой может сказать “всё работает”. А вот на линии - это ещё не факт.
Программка ModBus Tools разве не годится (ею все и пользуются)? Вот же, можно так:
Modbus TCP НЕ НАДО. Это:
а) Увеличит размеры устройства
б) Потребует сетку (коммутаторы например)
в) Потребует больших аппаратных ресурсов.
Отписываюсь по результатам встречи. Ох, ребята! Инет - это фигня. Вот вживую мы ощбий язык нашли быстрее, чем на форуме!
Выражаю огромнейшную благодарность за то, что ребята из Wiren до меня доехали. По итогам, хех, триллера, вышло следующее:
- Нашли кое-какие аппаратные недоработки у ОВЕНа в плане реализации Modbus-протокола и таймингов. Со всеми датчиками и устройствами ОВЕНа это работало нормально, а вот один датчик из Wiren начал ловить от этого глюки и, благодаря этим глюкам, нашлась сама недоработка.
- Сделали измерения общего плана для ОВЕНских ПВТшек и Wiren MSW и пришли к общему выводу о том, что:
а) Общие разбросы показаний укладываются в погрешность измерений;
б) Некоторые недобросовестные перекупщики-перепродажники мутят, собирая одно устройство-датчик из разных модулей (например, ставят датчик с CO2 в версии без CO2 без дополнительных настроек), из-за чего появляются погрешности по температуре из-за неправильной корректировки самонагрева датчиков (о чём написано в инструкции). - Со своей стороны я рассказал о том, как работает CodeSys v3 и чем его драйвер опроса Modbus отличается от обычных и как это влияет не тормоза шины и работу опросов (сам я у себя позже напишу пост, но для этого мне надо насобирать информацию).
Wiren это учтёт в плане техподдержки: если кто-то будет писать про то, что в CodeSys v3 всё тормозит, будет понятно, куда смотреть и какие дать рекомендации. Ура! - Про регистры и регистры управления ИК-командами обсуждается. Опять же, вживую это было удобнее показать, и то что в других ПЛК иногда важно иметь меньшее количество регистров, чем 80 штук Coils, было принято как аргумент для доработки прошивки.
- Обменялись образцами кабелей и их марками для того, чтобы разобраться с монтажом датчика. В том числе и разобрались, кто что понимает под “витая пара” и то, что например в офисах кабель (если он будет ошибочно выбран или повреждён) ещё как-то можно перетянуть под потолками и заменить, а в быту из-за финишной отделки - нет. Поэтому для быта - да - оправдано морочиться и брать более дорогой, но более крутой кабель. Ибо потом фиг его перетянешь так просто.
- Поговорили про сайт, фотографии и инструкции. Например, я вживую увидел модуль IO и увидел что на нём есть индикация. Оказывается. Снаружи. Как я хотел. А на фотках на сайте этого нет. Такие вот недоработки будут постепенно правиться.
Я очень доволен! Позже (теперь, когда вся информация будет обработана и окучена) я напишу посты про этот датчик и про Modbus. Также закину ОВЕНу информацию по кое-каким особенностям их железа.
Молодцы, рад, что вы нашли общий язык!))))
Ну теперь-то ты “полюбил” WB? 
В-общем, в спорах рождается истина и конечно, хорошо, что разобрались в таймингах байтах и полупериодах - продукт от этого должен стать только лучше, а от этого станет лучше - нам)
Так а что с п.3?.. Значит, пока запишем как “особенность работы CSv3 c модбас”?))
Мм, ну вот смотри, я сейчас в поисках решения для своего будущего дома по управлению теплым полом, климатом и всем таким, что есть в доме. Одно из решений - завести все датчики температуры пола в один модуль и его уже “прокинуть” до главного ПЛК. Внизу тоже будет модуль. И ещё где-нибудь будет модуль. Звезда - удобнее. Езернет - быстрее. Если бы был POE - ещё лучше. Завтра поменял модбас ТСП на что-то другое - а езернте остался.
Надоелл мне RS485, вот при всей её “железобетонности” все вот эти волновые сопротивления, экраны, помехи, оконечные сопротивления - надоело!
Не знаешь - Modbus TCP будет работать в циклическом режиме поллинга? Мне кажется нет - по идее модбас клиент устанавливает соединение с каждым модбас-сервером(слейвом) и данные струячат независимо друг от друга, не?
а когда планируется прошивка с возможностью чтения регистров подряд?
Да по ходу никогда.
Ребята тогда ко мне приезжали, мы пообщались, и они сказали что через 2 недели, максимум через месяц будет прошивка.
Месяц прошёл, я их пнул - сказали что ещё через месяц.
Потом прошёл ещё месяц, потом наступил 2021, … в общем, я забил на всё. И обозлился. Надоело такое отношение.
Сделаем-сделаем. Через месяц у производителей микроконтроллеров случились некоторые проблемы. Хотя на нашей стороне президент, нам всё равно пришлось всё бросить и переделывать продукты на другие микроконтроллеры, чтобы вообще было, что продавать. А потом ещё на одни, и ещё на одни, прежде чем мы смогли найти подходящие, которые реально можно купить в больших объёмах. Благодаря этому, мы ещё держимся и обеспечили производство оборудования как минимум до конца года, в отличие от всех остальных.
Осторожно предположу, что к нормальной продуктовой разработке для периферии мы вернёмся в конце марта. Конкретно эта задача там в самом начале очереди.
Как дела?