Arduino Mega. Контроллер теплицы. Хроники - 2

РЕКЛАМА НА ФОРУМХАУС

DIYMan, подскажите как обнулить накопительные показания датчика расхода воды?

 

@evgeny1241 - попробуйте приложенный скетч. На RS-485 не обращайте внимания, я его выключил из компиляции. Сделал настройки уровня реле для срабатывания - теперь должно при включённом канале досветки или полива выставлять нужный уровень.

С окнами тоже не мешает проверить

З. Ы. Для пинов только пока будет инверсная логика - я поправлю в следующих релизах.

 

Пока никак А что - сильно нннна-да?

 

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

 

- нашла коса на камень... питашку к клапанАМ полива я могу от ближайшИХ сараЕВ подтянуть. Мегу тоже туда (куда?) ставить?

 

В общем, с исполнительными модулями на RS-485 вроде всё решается просто: мега будет раз в секунду пхать в шину полное состояние контроллера (состояние окон, досветки, полива, пинов), а модуль - сам будет разбираться уже, что к чему и куда выставить. Чуть сложнее код получился у модуля, по сравнению с 1-Wire, зато сняли головняки с большим количеством пакетов, гоняемых по сети

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

 

Всё, всё, будет nRF, будет

 

Так, RS-485 для исполнительных модулей заработал, сегодня, надеюсь, выложу обновы

 

Обновил на гитхабе прошивки меги и исполнительного модуля - добавил RS-485. Завёл его на скорости 57600, ибо - нефик ползать как черепаха

Принцип работы с исполнительным модулем остался прежним: регистрация в контроллере - по 1-Wire, работать может - по 1-Wire и по RS-485.

Если надо RS-485 для исполнительного модуля - не забываем, что он юзает аппаратный UART, и перед прошивкой МК через USB надо выдернуть проводочки RS-485 из пинов RX0 и TX0.

Модули RS-485 - самые обычные с Али. Остальная информация есть в комментариях к прошивке модуля, и в файле Globals. h, как обычно

Теперь буду думать, как допилить RS-485 для модулей с датчиками.

 

нет, не очень. У меня когда мега глючила накрутила счетчик расхода до средненького пруда. Сейчас тестирую датчик расхода, цифра просто висит некрасивая.
Говорит что израсходовал 628040 литров

 

Как-нибудь приделаю. Но в принципе, вы можете сами в прошивке это сменить: просто залейте скетч, который, начиная с WATERFLOW_EEPROM_ADDR пишет в следующие 8 байт значение 0xFF, и всё. По умолчанию стартовый адрес хранения настроек накопительного расхода воды - 500.

 

Предварительные размышления: сколько модулей с датчиками на RS-485 у нас будет? Давайте подумаем, что пусть их будет десяток, в каждом - до трёх датчиков разных типов, итого - 30 датчиков, примем эту усреднённую цифру как максимальную, ибо - не ёлочную гирлянду делаем

Итак, у нас 30 пакетов, которые надо отослать с меги по RS-485, и получить ответ с показаниями датчиков. Причём существуют ситуации, когда модуля с датчиками нет на линии по разным причинам - сломался, не подключён etc. Примем кол-во таких датчиков как 1/3 от общего числа, т. е. - 10 штук.

Исходная скорость общения: 57600 бод. Интервал между пакетами примем равным 500 мс, т. е. полсекунды. Вычитка одного байта на скорости 57600 составляет примерно 170 микросекунд. С учётом гарантированного получения байта с той стороны утроим эту задержку на вычитку одного байта от ведомого. Т. е. получаем задержку в пол-миллисекунды после отсыла пакета, которая гарантирует нам, что если на той стороне есть модуль - он к этому времени просрётся.

Прибавим сюда время отсылки полного пакета в 21 байт от меги в шину - это 21*170мкс = 3,5 миллисекунды, примем как 4.

Как видно из приведённых рассуждений, статусом "модуля нет на линии" можно пренебречь, поскольку время получение ответа от модуля (те же 21 байт) - существенно больше времени таймаута до приёма первых двух байт. Следовательно, имеем следующий полный цикл общения с модулем для вычитывания показания с одного датчика:

1. Пишем 21 байт в шину - 4 мс;
2. Читаем 21 байт из шины или вываливаемся по таймауту - 4 мс;

Получаем 8 мс на цикл -запись/чтение. Прибавим сюда парочку миллисекунд для надёжи (переключение на приём/передачу, накладные расходы на обновление показаний с датчика в меге и т. п.) - получим 10 мс на датчик.

Что, конечно, даже на скорости 57600 - отнюдь не быстро, за это время модуль ESP успеет прожевать около 120 байт, т. к. работает на вдвое бОльшей скорости. Ходим, что называется, по самому краю потери данных

Ок, с потерями данных разберёмся потом, сейчас - мы выяснили, сколько максимум нам надо времени для опроса одного датчика на шине RS-485. Итого - полный цикл опроса одного датчика будет составлять 500 + 10 = 510 мс, где 500 - интервал между опросами двух датчиков. На массив из 30 датчиков уйдёт 510*30 = 15300 мс, или около 15 секунд.

Т. е. показания с каждого датчика будут обновляться раз в 15 секунд в самом вырожденном варианте. И это при условии, что всё будет стабильно работать на скорости в 57600. А теперь представьте, что придётся снижать скорость работы с портом до 9600, т. е. в 6 раз медленнее. Чо тогда? Раз в полторы минуты, зашибись интервал

Плюс - не забываем про критическое время работы по обработке одного пакета - нельзя допустить, чтобы буфер у ESP протух, да и вообще - любой буфер протух и пришёл в негодность.

Конечно, приведённый пример справедлив при наличии ажно тридцати зарегистрированных в системе датчиков, или, что то же самое - десяти нафаршированных по самое не могу модулей с датчиками, или - 15 модулей с двумя датчиками, или - ну вы поняли

Вот чего будем делать? Устроит такое "быстродействие"?

 

Это же огород, можно опрашивать через пару и более минут.

 

Использовал метеостанцию "Орбита" с радиодатчиком, в ней показания датчика менялись через 3 минуты. Для наблюдения за вялотекущим изменением температурных режимов вполне достаточно. Большая скорость опроса по моему нужна только например для остановки двигателей форточек при аварийном заклинивании или каких то похожих процессах.

 

Понятно, значит, с интервалом не паримся, делаем раз в полсекунды один пакет на один датчик - и улыбаемся и машем

Почти прикрутил показания с датчиков по RS-485, осталось только забороться с показаниями "нет данных", объясню чому: если в случае с работой через 1-Wire модуль сломался, не дай боже, то показания с него сбросятся корректно в "нет данных", поскольку класс опроса 1-Wire хранит в себе ссылку на последний опрошенный скратчпад, и знает - какие датчики сбрасывать в "нет данных" перед очередным опросом, то в случае с RS-485 - всё не так.

Там мы не можем делать предположений, откуда приходят показания с датчика, т. к. мы просто последовательно делаем в шину запрос для всех датчиков универсальных модулей. И если из шины ответа нет - это не значит, что модуль поломался. Это может значить, что он либо не подключён к шине, либо - работает по 1-Wire, либо - по радиоканалу. Следовательно, принудительно выставлять такому датчику в системе "нет данных" в виде показаний мы - не могём, т. к. не знаем и не строим предположений, через какие окольные дорожки он пробирается в наш окоп

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

Озвученную проблему надо решать. Думаю, наиболее приемлемым будет вариант, когда каждый модуль с датчиками (кому нужен такой функционал) принудительно сбрасывает показания с них в "нет данных" через какой-то интервал, например, пару минут, что даст нам уверенность, что через обозримый промежуток времени состояние контроллера в части показаний станет таки актуальным.

Ы?