DIY PLC для IoT, часть 2
Часть 1
В качестве демонстрации решения, соберем готовое устройство, как пример: набор датчиков в одном корпусе.
Почему в этот ряд статей «приплетена» статья про модем? При тестировании модема были использованы те же решения, про которые пишется сейчас, как то создание устройств из ПП разработанных с целью изготовления модуля с более-менее законченным видом и имеющего в своем составе набор относительно унифицированных плат.
Печатные платы, в отличие от ардуиновских шилдов, делаются под пайку. Т.е. технология слегка отличающиеся от «быстренько воткнул и заработало».
В частности в тестовой версии модема, что собирался для проверки идеи как таковой, были использованы плата процессорная, плата макетная и трех-юнитовый корпус. Как это выглядело можно посмотреть на картинках статьи об испытании модема.
плата макетная для корпуса D3MG
Вернемся к датчикам. Поскребши «по сусекам» на столе оказались:
- DHT-22 — датчик влажности и температуры, интерфейс Single Wire (не путать с 1-Wire)
- GY-65 — датчик давления и температуры, интерфейс I2C
- GY-302 — датчик освещенности, интерфейс I2C
- GAS Sensor (MQ-135) — датчик на кучу газов, но самое интересное — CO2, аналоговый выход
В общем, всё из набора для ардуинки.
набор датчиков, DHT-22 впаян на плату мезонинную
Сюда же добавим плату процессорную, плату крепления датчиков. Текущая версия платы мезонинной под датчики мне не нравится, будет переделана с целью унификации под большее число поддерживаемых, в том числе одновременно, датчиков. В нашем модуле оказались сразу два температурных датчика. Один показывает температуру внутри корпуса, другой — снаружи.
«Слабым звеном» в этом наборе будет GAS Sensor. У него диапазон рабочих температур -10 +45. Остальные компоненты, включая датчики -40 +85. Это температурный пром. диапазон. Применение компонент для данного температурного диапазона делает несколько дороже стоимость изделия. Если у кого то появится желание, то можно подобрать компоненты совместимые с примененными, но попроще, допустим диапазона температур -10 +70. Так же, для снижения стоимости, печатные платы можно укомплектовывать не полностью. Платы спроектированы на применение в пром. условиях. В домашнем хозяйстве нет таких жестких требований к оборудованию, поэтому такие компоненты как монитор старта, защита CAN, внешний кварц для МК, многоуровневые гальванические развязки можно не устанавливать. Цена изделия будет ниже, но и сфера применения ограничена.
модуль датчиков в сборе
Применительно к модулю датчиков, с целью посмотреть/оценить/протестировать ПО работы с каждым датчиком по отдельности и всех вместе, как и было упомянуто в предыдущей статье достаточно любой демо-платы с МК STM32F10x «на борту». На какие порты МК какие датчики цеплять — есть описание в архиве с исходниками.
пример вывода датчиков,
вывод данных на консоль.
DHT_t — температура, датчик DHT-22
DHT_h — влажность, датчик DHT-22
BMP085_p — давление, датчик BMP085
BMP085_t — температура, датчик BMP085
BHT1750 — освещенность, датчик BHT1750
CO2 — концентрация СО2 (вывод напряжения со входа АЦП, ppm более сложный пересчет)
Собранный модуль можно использовать для «автономной» работы, как тестовый или как мини-погодная станция. При тестировании, информацию с датчиков получаем через USB — UART. Питание модуля внешнее, DC 5V или 24V (мезонинные платы, для различного питания будут отличаться числом компонентов). При варианте работы через USB — UART перемычкой на плате МК можно запитаться от 5V USB.
Но, цель создания модулей по данной технологии это не развлечения с отдельной коробочкой, задача строить системы из подобных модулей, где каждый из модулей выполняет определенную функцию. Например уже созданный модуль датчиков. Для объединения модулей в сеть на плате с МК присутствует CAN интерфейс. Помимо CAN, в качестве эксперимента были построены небольшие беспроводные сети на основе ESP8266 и NRF24L01. Решение с использованием ESP8266 в то же время позволяет модулям самым простым способом подключиться к сети TCP/IP.
Но, вернемся к CAN. Наиболее разумное решение это один мастер, остальные подчиненные. Мастер с определенной частотой рассылает запросы, устройства‑модули отвечают. Запрос‑ответ асинхронны. Т.е. мастер не ждет, когда придет ответ от подчиненных. Но в то же время, если в заданный промежуток времени ответ от подчиненного модуля не пришел, то с этим модулем явно есть какие то проблемы. В то же время, в силу особенностей реализации CAN, любой модуль в произвольный момент времени может послать сообщение, напр об аварии или критическом событии, не дожидаясь запроса от мастера. Данное сообщение получат как мастер, так и все модули сети CAN.
CAN Bus дает возможность подключать наборы модулей к ПЛК различных производителей, в этом случае требуется написать библиотечные модули, напр. на языке ST, для поддержки промышленным контроллером протокола передачи данных для наших модулей. В этом случае ПЛК будет мастером.
Повторюсь, что в качестве мастера может выступать любой компьютер или микроконтроллер, такие как PC, Raspberry, Arduino, любой из наших модулей.
Например, для построения сети из модулей, на основе предложенной концепции, сделаем модуль USB‑UART‑CAN. Используем кусок платы, отрезанный от макетной. На этот кусок платы припаиваем плату с микроконтроллером и клеммы.
модуль UART‑CAN.
готовый модуль USB‑UART‑CAN.
Заливаем в этот модуль прошивку CAN‑Gate и можем работать, напр с нашими модулями датчиков по протоколу CAN, получая данные от модулей и управляя модулями. В частности, модуль CAN‑Gate позволяет снифферить сеть CAN, посылать команды любым устройствам поддерживающих физическую реализацию данного протокола, не обязательно только нашим модулям. В то же время, как пример, из этого модуля я могу сделать мастера, поместив в него соответствующую управляющую программу. По сути этот модуль становится свободно программируемым ПЛК.
Пример сети CAN.
Далее, если работать с CAN, то эксперименты с любой демо-платой закончены, ПО будет сильно привязано к разработанному «железу».
Подробнее про CAN, протоколе обмена и с чем их будем «есть» — в следующей части публикаций.
Файл проекта
