Arduino.ru

Пока думаю о протоколе, MODBUS немного избыточно. И хочу сделать автоопределение SLAVE устройств мастером.

так же думаю о модульной системе, протокол общения пока не решил какой буду использовать

2 all: определитесь будут ли в системе использоваться сторонние устройства, если "да" - тогда без вариантов повторять протокол устройства, если "нет" - можно смело изобретать свой протокол обмена.

Сам MODBUS не подрузомевает смену мастера, сделать на его основе своей реализации будет проблематично... у меня есть библиотека ICSC вроде она подрузомевает то, что нужно, но пока не разбирался...  Жду модули RS485...

я вижу основные проблеммы при реализации цикличного мастера:

1. Первичные выборы мастера, по идеи нужно делать с самым малиньким ID, но если все будут кричать свой ID в сеть будет фигня, по этому нужны или рандомные паузы или использовать циклы с номером ID, но тогда выборы будут идти не быстро

2. Коллизии с ID (несколько устройств с одним ID), для обычной шины с одним мастером и несколькими слейвами это не всегда будет проблеммой, а при цикличной передачи мастера это точно будет проблеммой

3. Ошибки вызваные включением нового устройства в уже работающей системе

Кроме всего есть и физические проблеммы шины на RS485, не смотря на терминаторы при определенных условиях не идеального подключения шина будет ловить штормы...

собственно я вижу 2 решения

1. сделать на основании HUB RS485, и он всегда будет мастером. Его можно сделать и самим и они есть готовые. Но тут нужно разбиратся и стоят они не слабо... Можно его сделать самим и заточить прошивку под свою шину, этим решится куча проблемм начиная от включения "на горячую" и заканчивая физикой. Вот тут вполне можно задействовать MODBUS и не извращатся самому. В любом случае решение будет дорогим но идеологически грамотным во всех смыслах.

2. Мудрить с протоколами (искать готовое или писать свой), решение бюджетное но довольно "велосипедное", собственно написать свой протокол не составит особого труда, но это будет велосипед не имеющий глобальных преспектив развития...

кстати при использовании единого HUB можно по витухе разводить 12 вольт для питания... вот пример промышленого устройства http://www.studioer.ru/products/komponenty-resheniy/aktivnyy-kontsentrator-rs485/

 

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

с питанием пока не знаю как поступить, на каждый слейв не хочется ставить свой блок питания, а расстояние будет до 20 метров между мастером и слейвами.

и кстати кто какие модули RS485 себе покупал и как работают?

я себе заказал такие http://www.ebay.com/itm/381374599127?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT но пока еще не пришли...

еще плюс в пользу отдельного устройства "шина": в него можно будет в него воткнуть часы реального времени и раздовать время "широковещательными" пакетами. Что удобно, единое время у всех модулей....

про питание надо почитать https://ru.wikipedia.org/wiki/Power_over_Ethernet

Модули RS485 не использую, просто купил драйверы ADM485 и ST3485. У меня свои платы на базе Pro Mini. Первая версия у меня работает давно, в качестве Master там Mega2560 с RTC, шина приблизительно метров 20-25, 5 Slave. Попытка питать через витую пару не удалась, пришлось бросить питание отдельно. Каждую секунду, по прерыванию от RTC, мастер посылает всем текущее время а затем опрашивает по очереди.

"Кто ищет, тот иногда находит". Вспомнил про одну книгу, называется "Проектирование цифровых устройств на однокристальных микроконтроллерах", 1990г. В своё время мне сильно помогла, так вот там на 190 стр. есть описание микросети с разделяемым моноканалом. Можно попробовать.

для себя пришел к выводу в целесообразности создания отдельного устройства "шина" выполняющего 4 функции

1. функционирование шины RS-485

2. обеспечение всех устройст единым временем (с энерго независимых часов внутри модуля)

3. обеспечение доступа и хранения общих данных на SD карте (внутри модуля), например лог работы устройств, ошибки устройств, общие настройки и т.д.

4. диагностику работоспособности подключенных устройств

За базовый протокол беру "Modbus" поверх него делаю свой, (или расширяю этот своими командами). 

вот библиотека https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino

Сори за офф-топ:Присоеденюсь к обсуждению позже, пока подписался.

Посмотрел библиотеку, нужно править. Не очень хочется использовать Ардуиновские функции, особенно millis() и digitalWrite(). Таймер 0 если и буду использовать, то по другому.

от части согласен...

По идеи нужно строить на прерывании от таймера. Короче пока самому не на чем ковырять (из ардуинок только мега лежит одиноко... жду посылку...). Хотя с другой стороны возможно и пойдет, тут надо смотреть зависимость стабильности передачи и приема от прочей загрузки контроллера.... вот завел тему http://arduino.ru/forum/programmirovanie/apparatnyi-posledovatelnyi-port-ili-emulyator для выбора подхода хард&код...

Я всю начальную настройку, насколько возможно, делаю в Proteus. И отлаживаю всё не сразу, а по модулям. Работу RS485 можно посмотреть и настроить в нём.

Сделал раздел на Яндекс-диск https://yadi.sk/d/eKF4ZGLJpfT4g здесь буду выкладывать наработки.

И ещё, SoftwareSerial тоже вне закона, на слейвах будут 2 Serial порта через внешний коммутатор.

чего за комутатор?

Можно использовать мультиплексор 4053, но когда буду делать плату, поставлю TS5A23157DGSR.

А смысл?

RS485 - связь + Nextion. Управление через тач дисплея.

Дисплей на слейвах! Зачем? И как коммутировать serial порт и не потерять данные на приеме?

В моем понимании дисплей нужен только на центральном контроллере.

я планирую такую схему:

мастер содержит SD карту, тач дисплей и исполнительная переферийка через RS485 подключаются к мастеру как слейвы.

мастер опрашивает все слейвы по кругу, когда доходит очередь до тач дисплея (со своим небольшим контроллером) то он фигачит все новые паракметы установок мастеру и мастер пишет на SD, потом когда дело доходит до переферийки (релюхи с контроллером) они получают новые установки с SD карты. При этом установки могут быть произведены не только с тачскрина но и например от SMS или через WEB или с ИК пульта...

То есть исполнительный модуль на прямую с тачем не работает, и если тач заглючит или обесточится - исполнительное устройство будет нормально работать дальше.

Если мне на кухне, например, нужно включить таймер или посмотреть время и т.д. я должен бежать к центральному МК? Или если центральный МК сдох, всё, сижу и радуюсь? В каждом помещении свой МК со своими функциями, центральный осуществляет синхронизацию, связь с внешним миром, настройки и рулит всем хозяйством. Его отсутствие не приведёт к краху системы. В каждом помещении, кроме основного, будут ещё и вспомогательные контроллеры(например в некоторых светильниках). Так что вылет основного МК в одной из комнат тоже не сильно повлияет на систему.

А сейчас как ты включаешь таймер? И для чего центральному контроллеру знать о включении таймера на кухне? Неужели есть необходимость включать/выключать кухонные таймеры дистанционно по SMS или через WEB? Или по кухонному таймеру должно еще что-то происходить в системе? Пусть будет автономное устройство - "кухонный таймер" с дисплеем. Можно еще понять индикатор температуры в помещении, но если тебе захочется узнать температуру в другом помещении - пойдешь смотреть в другое помещение? Или воспользуешься компом/смартфоном/центральным контроллером?

На самом деле нет никаких проблем, нужен дисплей ставь, просто соответствующий контроллер выбирай - с двумя портами, коммутировать один порт это не правильно.

Более того, хотел бы обозначить необходимость гальванической развязки между устройствами и общей шиной RS485. Попадание 220В или другого напряжения в любой контроллер или шину RS485 не должно выводить из строя всю систему.

Центральный будет собирать информацию о температуре в комнатах, счётчиков электроэнергии, воды, с датчиков протечки, дыма, газа, с уличного контроллера и т.д. анализировать и производить определённые действия. Через него я смогу удалённо узнать что происходит в доме. У каждого слейва будут свои функции, в зависимости от места установки. Дублировать все функции слейва на центральном МК нет необходимости, но некоторые,  особенно важные, имеет смысл. Например, прихожу домой и хочу включить свет во всей квартире. Вместо того, чтобы бегать по всей квартире, я включаю на центральном МК режим "Гости" и всё.

Верно. Справедливо и обратное, уходя из дома выключаем свет во всем доме с центрального контроллера. Контроллер просто шлет широковещательное сообщение всем контроллерам "выключить свет". О дублировании функций речь не идет - это другая функция, более высокого уровня.

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

Тревожная сигнализация строится не на реальных датчиках подключенных к центральному контроллеру, а на подключенных к локальным контроллерам, т.е. по сути на виртуальных. Центральный контроллер и понятия не имеет что за датчики там подключены и как с ними работать, для него все датчики одинаковы: 0=в норме, 1=тревога, 2=КЗ, 3=обрыв и т.п.

и т.д.

Всё верно. Я планирую сделать так, чтобы слейв при первом подключении передавал мастеру информацию о том,  какие функции он поддерживает и какие из них нужно дублировать. И на основании этой информации будет выстраиваться общение мастера с данным слейвом. Например, контроллер светодиодной ленты сообщает  сколько у него каналов PWM и можно им управлять удалённо или просто отражать своё состояние. Ведь основные фукции это что то включить или выключить, установить яркость(или просто аналоговое значение), получить информацию с датчика, передать информацию на слейв.

И ещё про библиотеку, которую упоминал vde69, хрень полная всё завязано на millis() вместо таймера.

Для гурманов - распознавание голосовых команд на дуине:

http://www.rlocman.ru/review/article.html?di=150550

давно смотрю на такие платы, но к сожалению их больше не производят.... проект закрыт :( 

да и говорят что плохо работает http://arduino.ru/forum/obshchii/interesnoe-na-aliexpress-i-ebay?page=22#comment-182155

есть другие http://ru.aliexpress.com/item/for-arduino-speech-recognition-module-containing-microphone-serial-control-voice-module-recording-transmission-LED-lights/32490559216.html?spm=2114.30010708.3.31.baqkK3&ws_ab_test=searchweb201556_2,searchweb201602_1_301_10034_10033_507_10032_10020_10017_10005_10006_10021_10022_401_10007_10018_10019,searchweb201603_9&btsid=fb455351-547e-4b2f-a82a-0f13b610fdcd

и такие http://ru.aliexpress.com/item/ISD4004-Voice-Recording-Module-Development-Kit-NewWay-Third-Version/32363308657.html?spm=2114.14010208.99999999.335.GU4q2a про него вообще ничего не могу сказать, и описание продавец не дает

а так идея очень заманчивая и сам хожу облизываюсь

Может в этом направлении взглянуть на проблему?

https://habrahabr.ru/post/237589/

С удовольствием присоединюсь к обсуждению когда начнете обсуждать практические вещи.... С учетом того, что уже впринципе работаю над похожей схемой.... 

Сейчас собираю свой "умный дом" .... который базируеться на 5 платах Arduino Mega.... вместо основного контроллера у меня выступает PC... но это не суть важно в этом вопросе... этот PC может быть заменен на 6 плату и все....  Передача данных между ними тоже по RS485...

Так вот советую начать разработку всей этой системы с простого примера.... который должен быть обработан / проверен... а дальше написать программу - это лишь вопрос времени.... 

На данный момент столкнулся с такой проблемой, что передача по RS485 завязана на пин ардуины, который отвечает за состояния "прием сигнала" или "отправка сигнала".... В моей схеме по умолчанию RS485 находиться в режиме приема сигнала и включаеться на отправку сигнала лишь на время "отправки сигнала". Програмно это выглядит так:

Соответственно когда принимаеться сигнал аналогичный алгоритм :

Вот если все внимательно посмотреть то в каждом процессе есть "delay" - это время на то, чтоб отправился сигнал, или принялся.... или выступает как разделитель между сигналами, вообщем без него нормально не работает.... 

Так вот эта задержка ВСЕ И ПОРТИТ, так как если у вас несколько контроллеров... и они одновременно начинают передавать сигналы - получить их нормально не получаеться.... и не получаеться одновременно получать и отправлять - так как есть этот Delay.... тоесть если у вас модуль 1-й отправляет информацию "температура 22 градуса"... а в этот миг 2-й модуль отправляет сигнал "отопление 1 включилось".  То модуль 1-й не примет сигнал от 2-го модуля - так как его активный режим "отправить сигнал".... и как с этим быть - до сих пор не понимаю.... нашел только один вариант - так как у меня основной контроллер РС - просто буду подключать каждую ардуино по своей ветке...  по принципу "звезды" с подтверждением, что сигнал принят... если нет подтверждения - повторная отправка.... Как в Вашем варианте быть - не знаю... Возможно я чтото не так делаю и можно избавиться от delay ... но как я не знаю.... 

Вообщем начните с этого вопроса, так как "как написать код" и все структуризировать - это придумать можно - но обидно если все придумаете, а на практике не получиться изза такой мелочи ... и потом многое нужно будет переделывать... 

у меня к вам вопрос, почему ваши слейвы отправляют одновременно?

почему не сделать опрос из мастера, тоесть отправили 1 , все слейвы приняли это а ответил только слейв под №1 а осталные ждут своей очереди и так по очереди мастер опрашивает все слейвы и ни какой звезды не нужно

Тогда это получаеться проект не "умный дом", а "умное отопление"... тоесть смысл этого всего : 

опросить все датчики по запросам, на основании полученных данных запустить какойто алгоритм исполнения... Включить вытяжку \ отопление \ кондиционер.... 

Тоесть Вас не интересуют секундные задержки... если так - то вопросов нет - все должно работать.... если идти по схеме "Запрос - ответ" ...

как только Вы перейдете в режим онлайн... тогда будут вопросы... 

В стандарте RS-485 в один момент активным может быть только один передатчик, а уже протокол обмена должен решить как рулить устройствами чтобы это правило соблюдалось и не было коллизий. Поэтому принцип "каждый по себе и делаю  что хочу" здесь не пройдёт. С протокола и надо начинать, либо свой писать, либо взять готовое. Но пока поиски успехами не увенчались.

Я наверное чего-то не понимаю в вашей системе, для чего вам режим онлайн? И неужели играет роль какие показания вы увидите...за секунду или за 2 минуты назад которые были. Это же не управление реактивным самолетом а показания датчиков в доме которые меняются очень медленно.
Или же есть какое-то недопонимание просмотра в режиме онлайн? Все показания должны хранится в пампамяти мастера или сервера и каждый период времени обновляется после запроса со слейва

Я наверное чего-то не понимаю в вашей системе, для чего вам режим онлайн? И неужели играет роль какие показания вы увидите...за секунду или за 2 минуты назад которые были. Это же не управление реактивным самолетом а показания датчиков в доме которые меняются очень медленно.
Или же есть какое-то недопонимание просмотра в режиме онлайн? Все показания должны хранится в пампамяти мастера или сервера и каждый период времени обновляется после запроса со слейва

внимательно почитайте САБЖ....

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

пример:

есть блок "шина" - он содержит SD память и часы реального времени

блок "контроль света" есть датчики движения и освещенности, они подсоедены к своему блоку, этот блок сам включает и выключает свет...

есть блок "Клавиатура" - он содержит интерфейс для задания режима работы света сон/подьем/день/все на работе/все в отпуске

----------------------------------------------------------------------------------------------------------

блок "шина" раз в 1 минуту шлет блоку "клавиатура" запрос "есть изменения?", в ответ получает новый режим работы света (если он изменился) 

блок "контроль света" работает по дефолтной схеме включая и выключая свет, раз в 1 минуту блок "шина" шлет ему сообщение "перейди в режим сон/отпуск и т.д.". Дальше он он работает по новой схеме... Если "контроль света" не получает данных с шины в течении 10 минут - он переходит в дефолтный режим

----------------------------------------------------------------------------------------------------------

даже если шина пропадет совсем (кабель рубанули) свет 10 минут будет работать по последней установленой схеме, а потом перейдет в дефолтный режим...

Я пока не вижу проблемм ни с быстродействием шины, ни с синхронизацией...

пока я вижу такой обмен:

1. 1 раз в секунду мастер шлет широковещательный пакет содержащий текущую дату и время, этот пакет служит для диагностики на слейвах наличии шины и синхронизации времени

2. Сразу после этого мастер начинает сеанс обмена с единичным слейвом (в промежутке между широковещалкой обрабатываются пакеты только с одним слейвом). Такой обмен должен идти менее 1 секунды!!! Сколько будет слейвов такой будет и цикл всей системы... То есть при 60 слейвах полный цикл будет 1 минута.

Правильно ли я понимаю, что при таком подходе можно реализовать хотелки в теме http://arduino.ru/forum/programmirovanie/biblioteka-setevye-peremennye-i-upravleniechtenie-portov-razlichnykh-mk-v-set

Т.е. информация не только поступает в мастер МК от слейвов, но и, например, в один слейв от другого слейва? Иначе могу ли я рулить выходами и читать входы с одного МК на удаленном другом МК?

 

кроме времени имхо должно быть ещё много ОБЩИХ переменных, которыми должны пользоваться разные МК. 

Вот нашёл в сети программу FLProg. Альтернативная графическая среда для программирования ардуино. Там вот есть сетевые переменные в modbus  и довольно легко настраиваются, но в остальном как программировать ничего мне непонятно.

PS после компилирования прога пишет скетч на ардуино IDE и его можно заливать, но скетч трудно читаемый

скетч для мастера

 

приведите примеры таких переменных, мне на ум не приходят...

состояния датчиков движения, протечки воды, температуры (они например в разных комнатах на разных МК)  да много ли чего ещё . Дисплей например стоит в прихожей на своем МК, а показывает температуру на улице с другого МК. Там же система ставиться на охрану (переменная состояние охраны) и данные передаются на контроллер на котором "висит" система охраны. Да дофига примеров. 

эти данные не нужны всем.... читайте мой пост чуть повыше...

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

читайте пост #37

а это что не переменные чтоли?

если взять не режим света, а например состояние охраны, то состояние этого режима нужно многим МК а не одному. 

она то-же не всем нужна... например для пожарной сигнализации должно быть пофиг на текущий режим... и какому нибудь авто поливу растений - то же :) да мало-ли чего еще...

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

ну и будут они передоваться в сеансе для конкретного устройства, я в этом проблемм не вижу. сейчас попробую посчитать пропускную способность...

значит эти переменные не должны быть общими или сетевыми если хотите. Я же не говорю, что надо все переменные делать общими и закидывать их в сеть.

PS зато движение около дома нужно знать "МК охрана" и "МК свет", тогда эта переменная всё таки должна быть сетевая, а вдруг она потом ещё кому понадобиться, прощё будет потом из сети её взять. 

рассмотрим Modbus

предположим обмен 3 пакетами,

1. команда мастера

2. данные слейва

3. подтверждение мастера

к каждому пакету идет заголовок, предположим (10 байт + 4 паузы по 1 байту) * 3 пакета * 8 = 336 бит

скорость допустим 9600 бит в сек, итого за 1 сек мы сможем передать примерно 1 кбайт, это 512 чисел типа INT, разделим на 2 (надо туда и обратно слать) и еще на 2 на всякий случай...

выходит:

на скорости 9600, мы можем с каждого слейва слать 128 чисел INT и столько-же получать за 1 сек,

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

 

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

Если делить разные МК по функциям то может ещё и пойдет такой медленный поллинг - так его называют? А если МК по комнатам, то нужно быстрее