Я придумал как правильно работать с dev_type. Убираем ENUM. Создаём 2мерн массив device [kind] [dev_type] .
где номером элемента массива [dev_type] и будет тип устройства. Сам элемент массива будет нести информацию разную в зависимости от [kind] 3 вида:
device [0] [dev_type] - состояние устройства (вкл или выкл, %, PWM или если это датчик - то значение параметра датчика)
device [1] [dev_type] - пин ардуино к которому подключено устройство
device [2] [dev_type] - Показывает укомлектованность данного узла этим устройством (если значение байта больше "0" значит укомплектовано) и вид устройства - булевое или PWM, % и т.д. это само значение байта. Т.е. комлектация узла устройствами выбирается как раз здесь.
Таким макаром всё НАМНОГО упрощается с организацией команд, управления пинами, на которых висят устройства, обратной связи по выполению команд, передаче параметров от датчиков, т.к. всё теперь можно запихивать в циклы фор.
А на DUE ты добавляешь ещё одно измерение массиву и получаешь таблицу всех параметров от всех узлов сети:
device [kind] [dev_type][node_addr]
надеюсь памяти на такой массив у due должно хватить
У меня блин только CanHacker и один модуль MCP2515 (ещё заказаны, никак дойти не могут). Вот и не получается нормально потестить пинг понг.
У меня честно говоря посылку из китая признали комерческой партией на таможне и вернули кучу барахла назад на али. Пришлось здесь по 190 рублей покупать 10 штук. Абыдна да.
Руки все не доходят до полной сборки. Еще и сервер на Linux поднимаю.
ты не представляешь как круто у меня всё получается. Короче теперь уже не надо устройства, которые требуют долгое выполнение команды, перемещать в первую двадцатку. Так всё получилось, аж прям самому нравится)) Короче теперь мы конгфигурируем узел, т.е. выбираем укомплектованность узла теми или иными устройствами, а также задаём вид устройства (т.е. как оно будет управляться digitalWrite, AnalogWrite или ещё как - подумай какие ещё варианты или это вообще датчик. Также в виде устройства зашифрована инфа - долгое будет выполнение команды или быстрое). В отдельном массиве хранятся таймауты на виды устройств, которые трубуют долгое выполнение команды. Если при конфигурировании мы установили вид устройства - что долго выполняет команду и не забили при этом таймаут в соотвествующий массив - в отладке будет ругаться при старте скетча.
Если тип устройства не сконфигурирован на данном узле - будет ошибка команды, если пытаться им управлять. Узел пошлет соответсвтующий отчет инициатору команды. Поругается в отладку.
Короче вот предварительный скетч. смотри внимательно изменения в вкладке canstruct.h
2. Прошивать всеже дистанционно решил c помощью ESP8266 самым дешевым ESP-01 через esp-link (тут про него http://samopal.pro/arduino-esp8266/), там же будет резервное управление по MQTT
3. Надо делать на центральных МК (у меня это мастрер слейв на DUE) брокер МQTT который превратит команды от MajorDomo (пока кручу его на Atom330+4Gb) в команды протокола OverCan и в обратную сторону соответственно так же.
есть такая идея, разделить использование последнего разряда в ID - type_dev. Т.е. когда у нас в данный момент тип сообщения COMMAND_SEND и ANSWER разрядом type_dev будут адресоваться исполнительные механизмы (массив device).
А когда запросы и ответы параметров (REQUEST_SEND, REQUEST_ANSWER) в разряде type_dev адресуются уже датчики (массив sensor)
Когда разделим эти два типа устройств, будет два массива. Так будет значительно экономиться память, т.к. когда они лежат в одном массиве, много неиспользуемых элементов массива получается. Датчикам то не нужен вид устройства (т.е. вид управления, долгое или быстрое выполнение), а датчиков большинство в массиве.
Я к чему беспокоюсь о памяти. Если все данные будут стекаться на мастере и мы будем белать трехмерный массив device [kind] [dev_type][node_addr] то такой скетч занимает при 93 типах устройств 80% оперативки на МЕГЕ - компилятор уже ругается.
На Due проверить не смог - этот же скетч у меня не компилируется под DUE, - чето ему в библиотеке CAN не нравится.
и почему в одном списке типов устройств у тебя некоторые устройства и в датчиках находятся и в исп. механизмах?
есть такая идея, разделить использование последнего разряда в ID - type_dev. Т.е. когда у нас в данный момент тип сообщения COMMAND_SEND и ANSWER разрядом type_dev будут адресоваться исполнительные механизмы (массив device).
А когда запросы и ответы параметров (REQUEST_SEND, REQUEST_ANSWER) в разряде type_dev адресуются уже датчики (массив sensor)
Так и нужно делать. Где то раньше я об этом говорил.
MaksVV пишет:
Я к чему беспокоюсь о памяти. Если все данные будут стекаться на мастере и мы будем белать трехмерный массив device [kind] [dev_type][node_addr] то такой скетч занимает при 93 типах устройств 80% оперативки на МЕГЕ - компилятор уже ругается.
Все данные с due нужно транслировать дальше на сервер по MQTT , ну и может быть простейшие обработки, сценарии она не потянет.
MaksVV пишет:
На Due проверить не смог - этот же скетч у меня не компилируется под DUE, - чето ему в библиотеке CAN не нравится.
я выше писал, на due переименуй CAN0 в CAN3 или больше. CAN0 и CAN1 заняты в библиотеке hardware от DUE.
MaksVV пишет:
и почему в одном списке типов устройств у тебя некоторые устройства и в датчиках находятся и в исп. механизмах?
это связанно с моей архитектурой на бистабильных реле. Я могу дать короткий импульс и реле сработает, но его состояние мне неизвестно т.к я могу этот импульс послать (замкнуть) и с выключателя. Поэтому у меня есть устройство с неопределяемым статусом, я могу тлько послать короткий импульс и еще есть оптрон АОТ166 который является датчиком наличия напряжения на выходе реле, т.е по сути датчиком состяния. Поэтому у меня есть лампа и есть лампа ;-)
По хорошему должно быть в ИУ вместо лампы реле бистабильное, а в датчиках - вмест лампы - датчик наличия напряжения 220 вольт. и опять же по хорошему наверх из МК можно вытянуть прост абстракцию лампа включить выключить, а можно реле бистабильное и датчик наличия напряжения. Можно сделать оба уровня абстракции, и так и так.
есть такая идея, разделить использование последнего разряда в ID - type_dev. Т.е. когда у нас в данный момент тип сообщения COMMAND_SEND и ANSWER разрядом type_dev будут адресоваться исполнительные механизмы (массив device).
А когда запросы и ответы параметров (REQUEST_SEND, REQUEST_ANSWER) в разряде type_dev адресуются уже датчики (массив sensor)
Так и нужно делать. Где то раньше я об этом говорил.
Ок
riv пишет:
MaksVV пишет:
Я к чему беспокоюсь о памяти. Если все данные будут стекаться на мастере и мы будем белать трехмерный массив device [kind] [dev_type][node_addr] то такой скетч занимает при 93 типах устройств 80% оперативки на МЕГЕ - компилятор уже ругается.
Все данные с due нужно транслировать дальше на сервер по MQTT , ну и может быть простейшие обработки, сценарии она не потянет.
Кстати я подумал - это только на узлах нужен двумерный массив, передавать на due будем только одно измерение в массиве, так что на due получается тоже двумерный массив. Хотел , чтобы на DUE было так сначала
device [kind] [dev_type][node_addr]
но вовремя опомнился - нафига измерение kind? оно не нужно серверу, там хранятся настройки типа девайса (вид девайса) - они не нужны серверу, и остаются только на узле. Поэтому остается так:
device [dev_type][node_addr]. А в таком варианте даже на меге памяти хватит. Не более 50 процентов оперативы будет использоваться.
Продвинулся немного по скетчу. Добавил виды подключения/управления устройств. Добавил список команд для управления устройствами. Добавил список различных отчетов по результатам выполнения команд. Пополнил функцию исполнения команд.
Новичку тут будет тяжело. Я все же останусь при своем, на простые задачи где ответные реакции не критичны прекрасно работает модбус там где реально нужно скорость и время реакции минимально то TCP/IP LAN/WiFi) ну и поверх этого любой протокол обмена (MQTT. Modbus IP, и пр) Сетка на основе витой пары конечно проста в реализации и надежна, может обеспечить питание. Поэтому на мой взгляд следует отдвать предпочтение не одному виду а комплектовать разными. По пробуйте посмотреть в сторону тему MySensors (Это не реклама и зазывало это ВАм вариант решения той самой задачи которая у Вас рождается. В данной теме есть и радио канал и RS485 и проработан сам протокол обмена.
Суть проста. Устройчтва делятся на виды (сенсоры) актуаторы датчики движения реле и пр. и каждый сенсор может иметь множество внутренних своих сенсоров т.е датчик движения может содержать реле и датчик освещеность и пр. Единственое пожалуй это нужен сервер. НО простые команды внутри сети идут прекрсно. Так что можно посмотреть как пример реализации. Я не стал долго упиратся и просто взял готовуе прототипы довел под свой задачи и все. Поэтому и предлагаю Вам в качестве примера.
Для новичка в результате появится библиотека arduino и описание как соединить все в сеть, назначить имена узлов и начать работать.
rw4cju.ru пишет:
Я все же останусь при своем, на простые задачи где ответные реакции не критичны прекрасно работает модбус там где реально нужно скорость и время реакции минимально то TCP/IP LAN/WiFi) ну и поверх этого любой протокол обмена (MQTT. Modbus IP, и пр)
Все зависит от требований и задач. Мы с уважаемым MaksVV ставим требование к системе по задержкам 0,01 а то и 0,001 сек. Это конечно не "реальное время" но что то рядом.
Основные применения таких скоростей это управление светом (согласитесь ждать 1-2 сек когда мастер опросит датчики движения а потом передаст УК команду включить реле света, немного не комфортно), управление медиа (звук, видео - переключение радио, оповещения о событиях) и др. приложениях где задержка вызывает дискомфорт или просто опасна. Мы же делаем не ДУ ДОМ а умный дом. А если "нейронная сеть" меденно передает сигналы в мозг тог это не умный дом а дом инвалид ;-)
Как ни странно, но overCAN протокола уровня overRS485 (ModbusRTU) нет. Вернее так есть OpenCAN (CANFestival) который весьма ресурсоемок и сложен для запуска.
Повторюсь на выходе Вы получите протокол уровня Modbus для проброса MQTT и MQTT-SN.
rw4cju.ru пишет:
Сетка на основе витой пары конечно проста в реализации и надежна, может обеспечить питание. Поэтому на мой взгляд следует отдвать предпочтение не одному виду а комплектовать разными. По пробуйте посмотреть в сторону тему MySensors (Это не реклама и зазывало это ВАм вариант решения той самой задачи которая у Вас рождается. В данной теме есть и радио канал и RS485 и проработан сам протокол обмена.
Рассматривается и ESP-LINK для прошивки, и MySensors и MyDevices и пр проекты с github.
Мы делаем протокол над CAN но под MQTT анологичный ModbusRTU. Если бы был Modbus не только overTCP но и overCAN, даже заморачиваться не стали бы.
rw4cju.ru пишет:
Суть проста. Устройcтва делятся на виды (сенсоры) актуаторы датчики движения реле и пр. и каждый сенсор может иметь множество внутренних своих сенсоров т.е датчик движения может содержать реле и датчик освещеность и пр. Единственое пожалуй это нужен сервер. НО простые команды внутри сети идут прекрсно. Так что можно посмотреть как пример реализации. Я не стал долго упиратся и просто взял готовуе прототипы довел под свой задачи и все. Поэтому и предлагаю Вам в качестве примера.
Мы с уважаемым MaksVV обсуждали уровни абстракции от железа, в темах выше.
В общем думаю будет возможность как получить данные со всех однотипных датчиков из которых получаем например температуру, так и абстрагированный датчик температура в помещени в котором уже обработанные усредненные данные со средней температурой по больнице ;-)
Та же история например с защитой от протечек. Есть N датчиков протечки и N исполнительных кранов c датчиками положения кранов, можно как снимать с каждого датчика и крутить каждый кран так и сделать абстракцию протечка->>перекрыть краны.
Вот кстати еще пример, меня не устраивает только датчик движения для включения выключения света (махать руками чтобы свет зажегся несколько глупо). Соответственно будет сложная система оценки наличия человека в помещении, его поведения (движения) с привязкой к шуму и времени дня. В дверном проеме стоит датчик открытия двери, 2 лазерных датчика как в метро для подсчета вошедших и вышедших в помешение, датчик звука и микроволноыой с тепловым датчиками движения. С реализацией сценариев вечер, с плавным выключением света даже если человек в помещении (вдруг я заснул), гости, ребенок и пр.... Тут поле для фантазии.
Сервер естественно будет, будет MQTT брокер на сервере, MQTT или MQTT-SN брокер на ардуино и MQTT или MQTT-SN клиент на MK. Естественно велосипед изобредать не будем, все с Github.
По поводу уровней абстракции и группировки датчиков и ИУ.
Этот вопрос нужно сначала серьезно обдумать.
Один и тот же датчик будет использоваться в разных системах для решения различных задач.
Вот например, герконовый датчик в окнах решает задачи охраны, температуры и влажности а так же блокирует кондиционер. И таких совмещений множество.
По исполнительным устройствам та же петрушка.
Вот например у меня 3 шаровых электрокрана, 2 перекрывают холодную и горячую воду а 1 подает холодную воду на проточный водонагреватель.
У меня 2 сценария
1. Протечка закрыть кран ГВС и ХВС
2. Нет горячей воды (пока кнопкой, потом автоматизирую) закрыть кран ГВС открыть кран на водонагреватель (на выходе водонагревателя стоит обратный клапан поэтому кран один)
И у каждого крана 2 концевика которые сообщают о статусе крана.
Отладка показала что мы слишком расслабились. И как я ранее и говорил UDP работать не будет. Ни твоя StatusControl() ни моя all_node_status_request() эффективно не работают.
Причина простая. Мы пытаемся отправить сообщение, если сеть занята, то Error Sending Message..., но мы это не обрабатываем, и в итоге твоя рассылка своевременно не отправляются и мои ответы на запрос не отправляются.
Вижу несколько направлений.
1. Рандомизировать отправку по времени. (Синхронизация всех по времени и в дальнейшем запрет отправлять одновременно)
Криво но будет работать. Нужно продумать.
2. Повтор попыток отправки n раз (Тут проблема получить 2 раза одну команду, но номером сообщения можно отфильтровать)
Но тут же проблема, ты раньше меня подкалывал, а вот всплыло, Нужно подтвержение доставки подтверждения ;-)
Т.е мастер отправил запрос статуса всем. Узел начинает отправлять, сеть занята, повторная отправка, доставляем на мастер, мастер по получению отправляет квитанцию что получил.
3. Нужно делать рандомизатор времени повторной отправки, колизия возникает сразу у несколькоих узлов и повтор нужно рандомизировать +- 50 милисекунд.
Тут видимо твоя очередь команд должна работать. Удаляем из очереди только то что гарантированно ушло.
Нужно делать даже не очередь команд а очередь отправки всего. Нужно твоИ ф-ю SendCommand_queue() и SendCommandAnswer_queue() модифицировать в ТХ_queue(), которая как раз и обрабатывает очередь отправки!!!!
Мы с уважаемым MaksVV обсуждали уровни абстракции от железа, в темах выше.
Меня "третьим" возмете?.
Еще прочитал Ваши результаты. Да тут есть логика.
Немного из своих изысканий.
Есть сервер.Raspberry3 на нем MajorDomo/ (далее MD) Почему? да потому что, простая и понятная, да и Hарод на нее столько полезного наработал. так что реально. Сам сервер это только "мозг" он конечно достаточно мощный для всех задач видео по крайней мре с него идет легко на 1 смарт 32 и 2 планшетеа одновременно по сети так что его быстродействия хватает. Теперь про основные задачи.
Логику поведения конечно MD может освоить любую причем с выводом все это в любой форме красивой, крутой любой. Только вот есть несколько проблем.
К самой МD что либо цеплять напрямую не получится, нежная да и капризная сразу будет, поэтому обязатено должен быть "Прокладка" Таким может например ESP32 (8266) Ардуино с IP либо пром контроллер c IP/
А вот уже на него и вешать все остальное. Такой вариант не от хорошей жизни. Распбери имеет питание 3.3. в и потребляеи довольно большой ток по 5 в. (около 500 ма и 200-300 HDD). 2 акумулятора от бесперебойника с питанием 12 в и преобразователем 12/5 в обеспечивают ей режим почти 28 часов до потери ее в сети. Хотя сама распбери еще работает но уже ....
Так вот с сервером вопрос решен а вот то чем он управляет и от чего получает информацию все время в развитии.
Тема "распределенного интлекта" меня всегда привлекает по нескольким причинам. Надежность. Простота да и сама структура гибкая.
теперь про то что имеем.
Сервер МВ например не может опрашивать Modbus чаще 1 с . (особенность самого MD), Поэтому на данной сети у меня то что не критично по скорости это например медленные датчики (температура, влажность и пр) которые по данной сетке идут от внешних контроллеров.
Есть шдюз ESP8266-NRF24L01+ANT (c внешней антеной) это датчики MySensors/ Они довольно универсальны и практичны малогабаритные имеют малое потребление (Aрдуино без всех элементов либо просто Atmeg328) габариты тоже привлекают мжно хоть куда встроить. Даи провода не тянуть.
Из опыта рабаоты ... нормально. Когда все настроиш и выставиш логику то просто рабаотает.
Скорость ... ну на 3+ для моих задач с лихвой .
теперь свет.
У меня несколько контроллеров (по этажам) Логика из проста есть Атмега 8 (МК) с портом 485 у которой 8 входов с опторазвязкой и 8 выходов на реле (на ULN2803). сами контроллеры сидят в боксах получают питание 24 в по линии UTP (6 жил) а две это Data. На контроллерах стоят DC/DC преобразователи поэтому все нормально. Реле на 24 в. Выключатель взимодействует с входом МК который конечно быстр и он тут же переводит сигнал на выход т.е транслимрует его на реле. Скорость конечно мгновенная (время реле а паоскольку освещение светодиодные лампы то все работает быстро. Тиристоры и пр. я не использую потому как данный вариант прешеол еще с 2011 г когда были еще и лампы накаливания. Так что работает а это главное.
Теперь что получает МВ? Он просто получает информацию что в такой то комнате включили свет либо выключили. Тут просто модбас. Также можно отключить все лампы либо все их включчить (это команды внутри МК) но поскольку это внешние команды от логики управления то тут ее мгновенность не важна... Ну скажите какая мне разница откроется штора приводом на 1 сек раньше или позже, или выключч\ится свет по какой либо команде с интрвалом 1 сек? Я тут даже не загоняюсь.
А вот команды датчиков кнопка колитки . датчик протечки и пр. где мгновенная реакция важна тут уже логика на основе МК и она либо вживлена в сам управляющий контроллер который обслуживает датчик либо на их старций брате (Мегу256р3) и на ней по сути построено.
Есть еще отдельные ESP8266. на котором крутися AMS и который при своем скудном обеспечении портами обладает хорошим процессором и простым в реализации стеком IP через WiFi. На нем стоит например индикатор LSD20*4 и который висит просто на стене, оформлен он в корпусе эл. счетчика 6803 и довольно прилично выглядит. Ну по крайней мере прошел контроль и допуск WIFE.. Также он имеет свою веб мордочку и на ней довольно много информации. Ну и он конечно имеет MQTT.
Блок управления ворот .. ну тут монстр. Условно.
Его описать просто не получимтся поскольку его алгоритм отрабатавыляс на протяжени 4 лет и постоянно появлялись новые идеии. Там ESP и Нано с возможностью прошивки через Wifi. так что новые идеии просто залить и испытать.
На данном модуле много функций и скорость реакции тоже важна (контакные датчики положения створы и мощный привод) ..так что да. Но и тут IP протокол который все это решает на ура.
Ну также он в перерывах между основной рабаотай управляет калиткой (ключи 1-Buttom) 3 датчика темепературы 1 DHT22/ датчик освещенности и вывод этого всего на сайт Narodmon.ru... так для общего куража.
Ну и 8 реле Двигатель. Прожектора замок и пр.
Есть ешще несколько контроллеров они просты в рабаоте и по сути являются "розетками" это просто комнатные датчики с DHT 11 b NRF (MySensor) .
Есть еще задумки но порой не хватает времени.
Вот как то так. По Вашему проекту, пока до конца не въехал в задумку, очень большой по обему и элементам, такой проект нужно посматривать не наскоком, но идея и сама концепция построения структуры мне нравится. Успеха в реализации.
1. Насчет включения в работу, думаю MaksVV против не будет. Основной вопрос что мы не используем совсем системы групповой работы и системы контроля изменений и версий, поэтому то MaksVV что то выкладывает новое, то я. Max что то мое берет, я что то его беру. Мне проще всего, у Вас у обоих уже живая рабочая сеть и проложенная инфраструктура, которую не заменишь. У меня пока только заложены все силовые и слаботочные кабели. (Как я выше писал у меня свет на бистабильных реле, т.е до каждой лампы от щита свой кабель, от каждой группы выключателей из помещений свой кабель. Реле имеет 3 упр. цепи. (Проще смотри РИО-1М) Я таким образом от проходных и перекрестных выключателей ушел и сделал задел для автоматизации. В итоге на выходе реле у меня датчик наличия напряжения а в паралель с кнопкой реле от ардуино.
2. Консультации по MD будут бесценным подспорьем. (Я пока развернул на сервере MD, ioBroker, Domotics, OpenHAB, NodeRED, mosquitto.
Пока впечатления от MD не особо. Возможно я не умею его готовить, но максимум визуализатор и загрузчик сценарием в сеть ниже. Быстродействие и дружественность к пользователю никакая.
3. По поводу топологии сети - Лучше провода может быть только провод. Затем nRF24 или nRF5, Затем Wi-Fi.
Оч. не хочется потерять контроль над домом из-за умершего Wi-Fi роутера. Поэтому Wi-Fi только некритичные приложения типа метеостанции.
nRF24 или nRF5 это для мест куда забыл и уже не смогу проложить кабель.
Я не совсем вижу целесообразность такой навароченой структуры в целом. Не в качестве стеба а так совет. Начинайте с простого но если готовите по крупному (а это видно) то советую разбить на сегменты и отработав его как кролика подвать уже как готовое меню.
тут вот в чем дело. При столь развитой структуре будет множество комбинаций которые будут взаимно вложены и при случайном сбое например потеря питания возможно одновременное хоровое пение всех контроллеров в сеть и элементарный перегруз ну и тд.
Кстати биполярные реле могут грешить такими сбоями. Проходные выключатели вещь полезная но саму схему при налаичии разделения по уровню управления и силовая часть можно легко собрать и при допустим отказе контроллра схема перейдет на элементарную электромеханическую. Поэтому рекомендую в скетчи сложных контроллеров при инциалтизации (setup) закладывать раздельные задаржки. например один 1 сек другой 2 и пр. У меня так ESP в сеть входят . Сперво временной разбег потом если не взяли сеть то долбят до подключения. ну и если уж не получилось то есть биперы. Один раз было пищат... оказалось роутер из розетки вместо телефона выключили.
По МВ могу только успешно в части его посадки на Raspberry +HDD тут он прекрасно живет ну и в части простого бесперебойного питания. По его програмироваия все делал на основе примеров и по сути добившись того что нужно не трогаю. Проверено уже более года. Уже и забыл где сервер....
На счет его скорости согласен. Но у него и задачи не особо. OpenHAB юзал но не мое... уж больно какоето оно другое не наше. Менталитет там другой. Хотя как показометор он неплох. А вот логику на него насадить для меня было из серии похода к зубному..
Провода тяните не жалея. Чем больше тем проще. Я тянул в каждую точку и силовой и UTP. Сводил все либо в боксы либо если это IP на центральный HUB/ UTP советую отечественый не китай хотьи дороже. В нашем вроде медь есть да и изоляция лучше Китайский он магнитом провод реагирует по сути стальной и он кородирует это сильно отражается на передече сигнала. Из опыта раоты в организации пришлость перетягивать несколько этажей. Сетка прото вставала.. Вплоть до того что просто из комнаты в команату 5-10 м сигнал не проходлил. Заменили все красота.
Роутер да ..хотя мой уже 10 лет, 24 часа и круглый год... лежит новый но пока не открывал..
Получилось прикольно, сначала придумали что за дачтики, потом перевели на английский их названия, потом в больбе за память сократили названия, потом перевели назад на русский. В итоге что за датчик уже не понять.
Я не совсем вижу целесообразность такой навароченой структуры в целом. Не в качестве стеба а так совет. Начинайте с простого но если готовите по крупному (а это видно) то советую разбить на сегменты и отработав его как кролика подвать уже как готовое меню.
Здесь Вы с MaxVV скорее сойдетесь, я же проектируюсь уровнями, слоями. Один слой отработать, второй слой, третий. Вот сейчас как раз оттрабатываем взаимодействие контроллеров в сети в разных режимах.
По сути не важно что передавать между контроллерами. Важно обеспечить гарантированну, своевременную доставку и подтверждение доставки. На следующем этапе передача команд и информации между МК-ми, мастером и сервером. Потом верхние протоколы.
rw4cju.ru пишет:
тут вот в чем дело. При столь развитой структуре будет множество комбинаций которые будут взаимно вложены и при случайном сбое например потеря питания возможно одновременное хоровое пение всех контроллеров в сеть и элементарный перегруз ну и тд.
CAN как раз и является протоколом с разрешением колизий, главное его правильно использовать (см. обнаруженные выше косяки с сообщениями) А для резервирования CAN я думаю поставить ESP-01 (Wi-Fi) на каждый нод для удаленной прошивки (esp-link) и резерва по MQTT
rw4cju.ru пишет:
Кстати биполярные реле могут грешить такими сбоями. Проходные выключатели вещь полезная но саму схему при налаичии разделения по уровню управления и силовая часть можно легко собрать и при допустим отказе контроллра схема перейдет на элементарную электромеханическую. Поэтому рекомендую в скетчи сложных контроллеров при инциалтизации (setup) закладывать раздельные задаржки. например один 1 сек другой 2 и пр. У меня так ESP в сеть входят . Сперво временной разбег потом если не взяли сеть то долбят до подключения. ну и если уж не получилось то есть биперы. Один раз было пищат... оказалось роутер из розетки вместо телефона выключили.
Оч. интересные идеи и с задержкой на запуск, прямо delay в сетап запихнуть, и watchdog тоже в разнобой настроить, и бипер по аварии.
rw4cju.ru пишет:
По МВ могу только успешно в части его посадки на Raspberry +HDD тут он прекрасно живет ну и в части простого бесперебойного питания. По его програмироваия все делал на основе примеров и по сути добившись того что нужно не трогаю. Проверено уже более года. Уже и забыл где сервер....
На счет его скорости согласен. Но у него и задачи не особо. OpenHAB юзал но не мое... уж больно какоето оно другое не наше. Менталитет там другой. Хотя как показометор он неплох. А вот логику на него насадить для меня было из серии похода к зубному..
Провода тяните не жалея. Чем больше тем проще. Я тянул в каждую точку и силовой и UTP. Сводил все либо в боксы либо если это IP на центральный HUB/ UTP советую отечественый не китай хотьи дороже. В нашем вроде медь есть да и изоляция лучше Китайский он магнитом провод реагирует по сути стальной и он кородирует это сильно отражается на передече сигнала. Из опыта раоты в организации пришлость перетягивать несколько этажей. Сетка прото вставала.. Вплоть до того что просто из комнаты в команату 5-10 м сигнал не проходлил. Заменили все красота.
Роутер да ..хотя мой уже 10 лет, 24 часа и круглый год... лежит новый но пока не открывал..
По кабелям согласен. У себя положил UTP 6E для Ethernet и сигнальный 4-6 жил в оплетке для датчиков и контроллеров.
Отладка показала что мы слишком расслабились. И как я ранее и говорил UDP работать не будет. Ни твоя StatusControl() ни моя all_node_status_request() эффективно не работают.
Причина простая. Мы пытаемся отправить сообщение, если сеть занята, то Error Sending Message......
..........Нужно делать даже не очередь команд а очередь отправки всего.
Вот это оооочень странно. Мы для этого и выбирали CAN а не 485. По идее это должно аппаратно разруливаться, так как для отправки всего уже есть буфер, аппаратный в мсп2515. Там их даже два. Попробуй отключать по одному.узлу. посмотри на скольких оставшихся начнет стабильно отправлять кан сообщения
Но раз уж такая фигня пошла. Мастер тоже шлет статус, широковещательно. В поле данных этого статуса будет время. Узлы читают это время. Каждой группе узлов назначаются "свои" секунды отправки статуса, конкретный МК в группе прибавляет "свои" милисекунды. Всё это делается чтобы разнести отправку статусов по времени, но также всё это будет засинхронизировано, т.к. происходит относительно времени мастера. Получается на одну секунду можно вешать 10 МК, если разницу между соседними отправками сделать в 100мс.
Также можно , наряду с очередью отправки команд , сделать очередь (читай буфер) вообще отправки CAN сообщений, раз уж аппаратная часть не справляется.
соединять очереди эти в одну нельзя. Т.к. критерии удаления из очереди разные и тело буфера разное.
У отправки команд критерий: удаляется из очереди, когда узел ответил.
а критерий у очереди вообще отпраки кан-сообщений: удаляется из очереди, когда сообщение удачно отправлено.
Вот это оооочень странно. Мы для этого и выбирали CAN а не 485. По идее это должно аппаратно разруливаться, так как для отправки всего уже есть буфер, аппаратный в мсп2515. Там их даже два. Попробуй отключать по одному.узлу. посмотри на скольких оставшихся начнет стабильно отправлять кан сообщения
На самом деле все корректно, и это недоработка нашего протокола.
Механизм разрешения коллизий (в отличие от механизма обнаружения коллизий в Ethernet)
Его суть заключается в том, что каждый узел слушает сеть и, если она свободна, может начать передачу. При этом, он продолжает слушать сеть. Если при посылке рецессивного бита принимается доминантный, значит одновременно с этим узлом начал передачу другой узел с более высоким приоритетом. В этом случае передача прекращается.
Т.е если сеть занята то контроллер не начинает передачу и это нормально! Железо обнаружило предпосылку к колизии и прекратило передачу.
Сделал вывод значения sndStat = CAN0.sendMsgBuf(txId_can, DLC, data);
Выдает постоянно 7
Ниже возможные значения
#define CAN_OK (0)
#define CAN_FAILINIT (1)
#define CAN_FAILTX (2)
#define CAN_MSGAVAIL (3)
#define CAN_NOMSG (4)
#define CAN_CTRLERROR (5)
#define CAN_GETTXBFTIMEOUT (6)
#define CAN_SENDMSGTIMEOUT (7)
#define CAN_FAIL (0xff)
Сейчас попробую всем контроллерам снизидь периоды и посомтреть что будет при макксимальной нагрузке на сеть. (И мой опрос раз в 5 сек, и товои сообщения с командами раз в 3-5 секунд от всех)
Раз в секунду шлют статус, для кан это вообще вечность. Не верю что шина занята, тут что-то не так
Проблема не что раз в секунду а что эта раз в секунду у всех одновременно, т.е начинает передачу сразу 5 контроллеров из 15. Проблема плавающая, фронты немного сдвинуты, скорость загрузки смещена, вот и конфликтуют иногода, но за ночь статистика не веселая.
Я запускаю все контроллеры махом (ставлю ноут на докстанцию и питание пошло) так же будет и в сети, общее питание контроллеров по сети.
Но раз уж такая фигня пошла. Мастер тоже шлет статус, широковещательно. В поле данных этого статуса будет время. Узлы читают это время. Каждой группе узлов назначаются "свои" секунды отправки статуса, конкретный МК в группе прибавляет "свои" милисекунды. Всё это делается чтобы разнести отправку статусов по времени, но также всё это будет засинхронизировано, т.к. происходит относительно времени мастера. Получается на одну секунду можно вешать 10 МК, если разницу между соседними отправками сделать в 100мс.
Также можно , наряду с очередью отправки команд , сделать очередь (читай буфер) вообще отправки CAN сообщений, раз уж аппаратная часть не справляется.
соединять очереди эти в одну нельзя. Т.к. критерии удаления из очереди разные и тело буфера разное.
У отправки команд критерий: удаляется из очереди, когда узел ответил.
а критерий у очереди вообще отпраки кан-сообщений: удаляется из очереди, когда сообщение удачно отправлено.
Тут все проще и сложнее, нужно сделать очередь в ТХ их которой удалять сообщения если if(sndStat == CAN_OK), а вот делать очередь FIFO-LIFO или в других комбинациях нужно думать. Т.е. не смог я отправить сообщение а за мной в очереди еще 5, мне это же отправлять или следующее.
Если считать наш протокол канальным или сетевым уровнем то долбить до упора 1 сообщение. Т.к. отказ контроллера или сеть занята идли нет транпорта.
Теоретически MCP2515 от нас должен скрыть канальный уровень, но это не совсем так, мы видим что сеть занята и прекращаем передачу. Так что у нас концы из канального уровня и полный доступ к сетевому.
А вот если делать еще очередь с подтверждением, типа ТСР т.е транспортный уровень до тут нужно думать, я бы ставил сообщение в конец.
Вообще придется все 3 уровня отлаживать
1. контроль передачи - ушло не ушло - if(sndStat == CAN_OK)
2. контроль пути передачи и адресация - здесь просто ответ что получил
3. контроль доставки данных и команд - здесь ответ что данные корректны команда выполнена.
Не совсем понятно что с буфером у MCP2515 и как с ним работать. Я увеличил задержку в либе сначала до 100 потом до 1000 (#define TIMEOUTVALUE 1000 в mcp_can_dfs.h) ошибки пропали на 1000
Дак аппаратный буфер в mcp2515 на прием или на отправку? Или на то и на другое? По идее не должен буфер на отправку заполняться, из-за того что входящие сообщения аппаратно не фильтруем.
В прерывании нельзя весь RX выполнять. Слишком большой он. Максимум флаг ставить что сообщение принято. Хотя чем это будет отличаться от настоящего варианта, непонятно.
Т.е. ты сделал задержку вместо 100мс одну секунду? Это время, в течение которого mcp2515 делает попытки отправить сообщение в кан из своего буфера? В принципе это выход, костыль конечно, но все же.
В общем я разберусь все таки с этими масками/фильтрами.
Дак аппаратный буфер в mcp2515 на прием или на отправку? Или на то и на другое? По идее не должен буфер на отправку заполняться, из-за того что входящие сообщения аппаратно не фильтруем.
Тут как раз ты дока, я про этот буфер и не знал. Пробую либу расковырять, но там регистры и пр. я в этом утону.
Т.е. ты сделал задержку вместо 100мс одну секунду? Это время, в течение которого mcp2515 делает попытки отправить сообщение в кан из своего буфера? В принципе это выход, костыль конечно, но все же. В общем я разберусь все таки с этими масками/фильтрами.
Нужно подбирать параметр. Но на 15 узлах 50 мс и даже 100 мс мало, 1000 поставил на попробывать. Сейчас твой код доковыряю, и потестирую сеть.
а ты точно физически всё нормально соединил? замеряй сопротивление между проводами CAN. должно быть около 120 Ом. Может терминаторы где забыл, или наоборот лишние. И провод должен быть витой. Ну и соединения ардуины и кан модулей. Я вот щас тестировал, тоже даже на проверенных скетчах были сбои отправки, оказался плохой контакт на проводочках SPI шины.
короче вот скетч. тема такая. Мастер шлёт статус раз в 2 секунды (можно выбрать) широковещательно. ( Этот статус в частности получает и слейв, чтобы контролировать исправность мастера.) Как только любой подчинённый узел получает этот статус от мастера, запускается таймер равный адрес МК умножить на 50мс. Таким макаром даже 25 МК в сети отправят свои статусы за 1,25 секунды, что меньше периодичности отправки статуса мастером. При этом отправки статусов от всех узлов разнесены по времени. Проверил работает. Теперь ты проверяй на своих 15 узлах.
проверь на 15 узлах скетч #592. там исправляешь только адрес узла и дефайн мастер или подчинённый. Причинами твоих глюков отправки, возможно являются множество ошибок в твоём скетче. Поэтому я пока не собираю всё в кучу. Толком конкретный элемент работы скетча ещё не проверили, а ты уже другое добавляешь.
riv пишет:
Нужно как то договориться о структуре уже отработанных функций да еще в отдельных файлах и их не менять.
вроде отладка хорошо работала , поэтому далее ты сам себе противоречишь:
riv пишет:
Посмотри как я вынес из RX твой код RX_processing и debug
дело в том, что мы и так часто прыгаем из функции в функцию и всё время передаём аргументы, причем по значению. Это нехорошо.
riv пишет:
Предлагаю в дальнейшем базовые отлаженные функции зафиксировать и структуру не менять, чтобы не глядя брать например RX_TX, WEB, Command_Executin.....
Максимум должны изменяться количество и тип аргументов в вызываемых функциях
вкладка RX TX ещё не дописана, Command_Execution тоже .
//previousMillis перезапросы если нет ответа //message_number //flag_mk_reepeat //flag_mk_answer //previousMillis опрос//разрешение на опрос
мало того, что он знакового типа long (т.е. будут отрицательные значения при переполнении, что для таймера имхо не допустимо), дак ещё в массиве только два элемента из 6 используют тип long, остальное почти всё - флаги (по сути это бит записывается в 4 байтовую ячейку, не жирновато ли для одной единички или нолика?).
т.е. 4 ячейки не рациональных умножаем на количество узлов 30. получаем 120. Т.к. нерациональность в три байта (могли только один применить, а применили 4 - тип long столько занимает). 120*3 = 360 байт ты просто за зря сжёг из ОЗУ. Это расточительство для МК уровня ардуино.
проверь на 15 узлах скетч #592. там исправляешь только адрес узла и дефайн мастер или подчинённый. Причинами твоих глюков отправки, возможно являются множество ошибок в твоём скетче. Поэтому я пока не собираю всё в кучу. Толком конкретный элемент работы скетча ещё не проверили, а ты уже другое добавляешь.
Так я за тобой уже не успеваю ;-), уже трачу больше времени на разбор твоего кода нежели на написание своего.
Предлагаю собрать базовую структуру программы и основной алгоритм, утвердить и в нем крутится.
А функции я делаю если код более 10 строк с одном CASE
Ладно это лирика. Работаем как кому удобнее, дальше как нибудь светем все воедино.
Просто на выходе нужно делать библиотеку и если глянешь на их структуры, то там все разбито на функции и процедуры, внутри классов и структур.
Может у меня привычка дурная С++ но я наследовать код пытаюсь, чтобы не повторяться.
Эту шляпу longarray_request_status[NODS_NUMBER][6]; я переделаю. Помнишь вначале вообще Float испоьзовался. Главное чтобы заработало, потом отладка и оптимизация.
В любом случае мне кажется у нас на выходе не плохо получается, взаимная критика дает плоды и код живет.
посмотри, там полюбому все по указателям или ссылкам передается между функциями. А классами и структурами я не умею пока оперировать. Учиться надо.
Нужно проще всё делать, по возможности. Вот ты запрашиваешь статус каждого узла. потом они отвечают. А посмотри как я сделал. Один статус мастера и все отвечают. Так сказать статус за статус. И кода мимимум. причем периодическую отправку статуса мастером запихал в таймер периодической проверки "а на связили узлы" (StatusControl()).
Я придумал как правильно работать с dev_type. Убираем ENUM. Создаём 2мерн массив device [kind] [dev_type] .
где номером элемента массива [dev_type] и будет тип устройства. Сам элемент массива будет нести информацию разную в зависимости от [kind] 3 вида:
device [0] [dev_type] - состояние устройства (вкл или выкл, %, PWM или если это датчик - то значение параметра датчика)
device [1] [dev_type] - пин ардуино к которому подключено устройство
device [2] [dev_type] - Показывает укомлектованность данного узла этим устройством (если значение байта больше "0" значит укомплектовано) и вид устройства - булевое или PWM, % и т.д. это само значение байта. Т.е. комлектация узла устройствами выбирается как раз здесь.
Таким макаром всё НАМНОГО упрощается с организацией команд, управления пинами, на которых висят устройства, обратной связи по выполению команд, передаче параметров от датчиков, т.к. всё теперь можно запихивать в циклы фор.
А на DUE ты добавляешь ещё одно измерение массиву и получаешь таблицу всех параметров от всех узлов сети:
device [kind] [dev_type] [node_addr]
надеюсь памяти на такой массив у due должно хватить
ты же вроде вывел провода rs485 в одно место от каждого МК, и научился по 485 скетч лить. Тогда этот вариант видимо нужно качать.
ПС. #544 скетч поправил немного.
Проблема в том что для 2560 я так и не научился, сейчас разбираюсь.
+ Все же OverCan прошивка симпотичнее, ты же не зря мультифрейм делал.
У меня блин только CanHacker и один модуль MCP2515 (ещё заказаны, никак дойти не могут). Вот и не получается нормально потестить пинг понг.
У меня честно говоря посылку из китая признали комерческой партией на таможне и вернули кучу барахла назад на али. Пришлось здесь по 190 рублей покупать 10 штук. Абыдна да.
Руки все не доходят до полной сборки. Еще и сервер на Linux поднимаю.
+ Все же OverCan прошивка симпотичнее, ты же не зря мультифрейм делал.
имхо, тут без второй ардуино на каждом узле не обойтись, которая будет прошивать первую.
ты не представляешь как круто у меня всё получается. Короче теперь уже не надо устройства, которые требуют долгое выполнение команды, перемещать в первую двадцатку. Так всё получилось, аж прям самому нравится)) Короче теперь мы конгфигурируем узел, т.е. выбираем укомплектованность узла теми или иными устройствами, а также задаём вид устройства (т.е. как оно будет управляться digitalWrite, AnalogWrite или ещё как - подумай какие ещё варианты или это вообще датчик. Также в виде устройства зашифрована инфа - долгое будет выполнение команды или быстрое). В отдельном массиве хранятся таймауты на виды устройств, которые трубуют долгое выполнение команды. Если при конфигурировании мы установили вид устройства - что долго выполняет команду и не забили при этом таймаут в соотвествующий массив - в отладке будет ругаться при старте скетча.
Если тип устройства не сконфигурирован на данном узле - будет ошибка команды, если пытаться им управлять. Узел пошлет соответсвтующий отчет инициатору команды. Поругается в отладку.
Короче вот предварительный скетч. смотри внимательно изменения в вкладке canstruct.h
1. Скетч супер.
2. Прошивать всеже дистанционно решил c помощью ESP8266 самым дешевым ESP-01 через esp-link (тут про него http://samopal.pro/arduino-esp8266/), там же будет резервное управление по MQTT
3. Надо делать на центральных МК (у меня это мастрер слейв на DUE) брокер МQTT который превратит команды от MajorDomo (пока кручу его на Atom330+4Gb) в команды протокола OverCan и в обратную сторону соответственно так же.
есть такая идея, разделить использование последнего разряда в ID - type_dev. Т.е. когда у нас в данный момент тип сообщения COMMAND_SEND и ANSWER разрядом type_dev будут адресоваться исполнительные механизмы (массив device).
А когда запросы и ответы параметров (REQUEST_SEND, REQUEST_ANSWER) в разряде type_dev адресуются уже датчики (массив sensor)
Когда разделим эти два типа устройств, будет два массива. Так будет значительно экономиться память, т.к. когда они лежат в одном массиве, много неиспользуемых элементов массива получается. Датчикам то не нужен вид устройства (т.е. вид управления, долгое или быстрое выполнение), а датчиков большинство в массиве.
Я к чему беспокоюсь о памяти. Если все данные будут стекаться на мастере и мы будем белать трехмерный массив device [kind] [dev_type] [node_addr] то такой скетч занимает при 93 типах устройств 80% оперативки на МЕГЕ - компилятор уже ругается.
На Due проверить не смог - этот же скетч у меня не компилируется под DUE, - чето ему в библиотеке CAN не нравится.
и почему в одном списке типов устройств у тебя некоторые устройства и в датчиках находятся и в исп. механизмах?
01//sensor02.....03constcharstringDEV_41[] PROGMEM ="ЛАМПА НА ПОТОЛКЕ";// 41; //Лампа на потолке04constcharstringDEV_42[] PROGMEM ="ЛАМПА НАСТЕННАЯ";// 42; //Ланпа настенная05constcharstringDEV_43[] PROGMEM ="ЛАМПА ПОДСВЕТКИ";// 43; //Лампа подсветки06constcharstringDEV_44[] PROGMEM ="ЛАМПА АВАРИЙНАЯ";//44; //Лампа аварийная07......0809//Device Digital //Device analog10constcharstringDEV_64[] PROGMEM ="ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ";//64; //Лампа на потолке вкл/выкл11constcharstringDEV_65[] PROGMEM ="ЛАМПА НАСТЕННАЯ БУЛЕВАЯ";//65; //Ланпа настенная вкл/выкл12constcharstringDEV_66[] PROGMEM ="ЛАМПА ПОДСВЕТКИ БУЛЕВАЯ";// 66; //Лампа подсветки вкл/выкл13constcharstringDEV_67[] PROGMEM ="ЛАМПА АВАРИЙНАЯ БУЛЕВАЯ";//67; //Лампа аварийная вкл/выкл14constcharstringDEV_68[] PROGMEM ="ЛАМПА НА ПОТОЛКЕ ДИММЕР";// 68; //Лампа на потолке диммируемая15constcharstringDEV_69[] PROGMEM ="ЛАМПА НА СТЕНЕ ДИММЕР";// 69; //Ланпа настенная диммируемая16constcharstringDEV_70[] PROGMEM ="ЛАМПА ПОДСВЕТКИ ДИММЕР";// 70; //Лампа подсветки диммируемая17constcharstringDEV_71[] PROGMEM ="ЛАМПА АВАРИЙНАЯ ДИММЕР";//71; //Лампа аварийная диммируемаяесть такая идея, разделить использование последнего разряда в ID - type_dev. Т.е. когда у нас в данный момент тип сообщения COMMAND_SEND и ANSWER разрядом type_dev будут адресоваться исполнительные механизмы (массив device).
А когда запросы и ответы параметров (REQUEST_SEND, REQUEST_ANSWER) в разряде type_dev адресуются уже датчики (массив sensor)
Так и нужно делать. Где то раньше я об этом говорил.
Я к чему беспокоюсь о памяти. Если все данные будут стекаться на мастере и мы будем белать трехмерный массив device [kind] [dev_type] [node_addr] то такой скетч занимает при 93 типах устройств 80% оперативки на МЕГЕ - компилятор уже ругается.
Все данные с due нужно транслировать дальше на сервер по MQTT , ну и может быть простейшие обработки, сценарии она не потянет.
На Due проверить не смог - этот же скетч у меня не компилируется под DUE, - чето ему в библиотеке CAN не нравится.
я выше писал, на due переименуй CAN0 в CAN3 или больше. CAN0 и CAN1 заняты в библиотеке hardware от DUE.
и почему в одном списке типов устройств у тебя некоторые устройства и в датчиках находятся и в исп. механизмах?
01//sensor02.....03constcharstringDEV_41[] PROGMEM ="ЛАМПА НА ПОТОЛКЕ";// 41; //Лампа на потолке04constcharstringDEV_42[] PROGMEM ="ЛАМПА НАСТЕННАЯ";// 42; //Ланпа настенная05constcharstringDEV_43[] PROGMEM ="ЛАМПА ПОДСВЕТКИ";// 43; //Лампа подсветки06constcharstringDEV_44[] PROGMEM ="ЛАМПА АВАРИЙНАЯ";//44; //Лампа аварийная07......0809//Device Digital //Device analog10constcharstringDEV_64[] PROGMEM ="ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ";//64; //Лампа на потолке вкл/выкл11constcharstringDEV_65[] PROGMEM ="ЛАМПА НАСТЕННАЯ БУЛЕВАЯ";//65; //Ланпа настенная вкл/выкл12constcharstringDEV_66[] PROGMEM ="ЛАМПА ПОДСВЕТКИ БУЛЕВАЯ";// 66; //Лампа подсветки вкл/выкл13constcharstringDEV_67[] PROGMEM ="ЛАМПА АВАРИЙНАЯ БУЛЕВАЯ";//67; //Лампа аварийная вкл/выкл14constcharstringDEV_68[] PROGMEM ="ЛАМПА НА ПОТОЛКЕ ДИММЕР";// 68; //Лампа на потолке диммируемая15constcharstringDEV_69[] PROGMEM ="ЛАМПА НА СТЕНЕ ДИММЕР";// 69; //Ланпа настенная диммируемая16constcharstringDEV_70[] PROGMEM ="ЛАМПА ПОДСВЕТКИ ДИММЕР";// 70; //Лампа подсветки диммируемая17constcharstringDEV_71[] PROGMEM ="ЛАМПА АВАРИЙНАЯ ДИММЕР";//71; //Лампа аварийная диммируемаяэто связанно с моей архитектурой на бистабильных реле. Я могу дать короткий импульс и реле сработает, но его состояние мне неизвестно т.к я могу этот импульс послать (замкнуть) и с выключателя. Поэтому у меня есть устройство с неопределяемым статусом, я могу тлько послать короткий импульс и еще есть оптрон АОТ166 который является датчиком наличия напряжения на выходе реле, т.е по сути датчиком состяния. Поэтому у меня есть лампа и есть лампа ;-)
По хорошему должно быть в ИУ вместо лампы реле бистабильное, а в датчиках - вмест лампы - датчик наличия напряжения 220 вольт. и опять же по хорошему наверх из МК можно вытянуть прост абстракцию лампа включить выключить, а можно реле бистабильное и датчик наличия напряжения. Можно сделать оба уровня абстракции, и так и так.
А когда запросы и ответы параметров (REQUEST_SEND, REQUEST_ANSWER) в разряде type_dev адресуются уже датчики (массив sensor)
Так и нужно делать. Где то раньше я об этом говорил.
Ок
Я к чему беспокоюсь о памяти. Если все данные будут стекаться на мастере и мы будем белать трехмерный массив device [kind] [dev_type] [node_addr] то такой скетч занимает при 93 типах устройств 80% оперативки на МЕГЕ - компилятор уже ругается.
Кстати я подумал - это только на узлах нужен двумерный массив, передавать на due будем только одно измерение в массиве, так что на due получается тоже двумерный массив. Хотел , чтобы на DUE было так сначала
device [kind] [dev_type] [node_addr]
но вовремя опомнился - нафига измерение kind? оно не нужно серверу, там хранятся настройки типа девайса (вид девайса) - они не нужны серверу, и остаются только на узле. Поэтому остается так:
device [dev_type] [node_addr]. А в таком варианте даже на меге памяти хватит. Не более 50 процентов оперативы будет использоваться.
Продвинулся немного по скетчу. Добавил виды подключения/управления устройств. Добавил список команд для управления устройствами. Добавил список различных отчетов по результатам выполнения команд. Пополнил функцию исполнения команд.
Доброе время суток.
Прочитал всю тему. Трудно в понимании.
Новичку тут будет тяжело. Я все же останусь при своем, на простые задачи где ответные реакции не критичны прекрасно работает модбус там где реально нужно скорость и время реакции минимально то TCP/IP LAN/WiFi) ну и поверх этого любой протокол обмена (MQTT. Modbus IP, и пр) Сетка на основе витой пары конечно проста в реализации и надежна, может обеспечить питание. Поэтому на мой взгляд следует отдвать предпочтение не одному виду а комплектовать разными. По пробуйте посмотреть в сторону тему MySensors (Это не реклама и зазывало это ВАм вариант решения той самой задачи которая у Вас рождается. В данной теме есть и радио канал и RS485 и проработан сам протокол обмена.
Суть проста. Устройчтва делятся на виды (сенсоры) актуаторы датчики движения реле и пр. и каждый сенсор может иметь множество внутренних своих сенсоров т.е датчик движения может содержать реле и датчик освещеность и пр. Единственое пожалуй это нужен сервер. НО простые команды внутри сети идут прекрсно. Так что можно посмотреть как пример реализации. Я не стал долго упиратся и просто взял готовуе прототипы довел под свой задачи и все. Поэтому и предлагаю Вам в качестве примера.
С Уваженеим.
Новичку тут будет тяжело.
Для новичка в результате появится библиотека arduino и описание как соединить все в сеть, назначить имена узлов и начать работать.
Я все же останусь при своем, на простые задачи где ответные реакции не критичны прекрасно работает модбус там где реально нужно скорость и время реакции минимально то TCP/IP LAN/WiFi) ну и поверх этого любой протокол обмена (MQTT. Modbus IP, и пр)
Все зависит от требований и задач. Мы с уважаемым MaksVV ставим требование к системе по задержкам 0,01 а то и 0,001 сек. Это конечно не "реальное время" но что то рядом.
Основные применения таких скоростей это управление светом (согласитесь ждать 1-2 сек когда мастер опросит датчики движения а потом передаст УК команду включить реле света, немного не комфортно), управление медиа (звук, видео - переключение радио, оповещения о событиях) и др. приложениях где задержка вызывает дискомфорт или просто опасна. Мы же делаем не ДУ ДОМ а умный дом. А если "нейронная сеть" меденно передает сигналы в мозг тог это не умный дом а дом инвалид ;-)
Как ни странно, но overCAN протокола уровня overRS485 (ModbusRTU) нет. Вернее так есть OpenCAN (CANFestival) который весьма ресурсоемок и сложен для запуска.
Повторюсь на выходе Вы получите протокол уровня Modbus для проброса MQTT и MQTT-SN.
Сетка на основе витой пары конечно проста в реализации и надежна, может обеспечить питание. Поэтому на мой взгляд следует отдвать предпочтение не одному виду а комплектовать разными. По пробуйте посмотреть в сторону тему MySensors (Это не реклама и зазывало это ВАм вариант решения той самой задачи которая у Вас рождается. В данной теме есть и радио канал и RS485 и проработан сам протокол обмена.
Рассматривается и ESP-LINK для прошивки, и MySensors и MyDevices и пр проекты с github.
Мы делаем протокол над CAN но под MQTT анологичный ModbusRTU. Если бы был Modbus не только overTCP но и overCAN, даже заморачиваться не стали бы.
Суть проста. Устройcтва делятся на виды (сенсоры) актуаторы датчики движения реле и пр. и каждый сенсор может иметь множество внутренних своих сенсоров т.е датчик движения может содержать реле и датчик освещеность и пр. Единственое пожалуй это нужен сервер. НО простые команды внутри сети идут прекрсно. Так что можно посмотреть как пример реализации. Я не стал долго упиратся и просто взял готовуе прототипы довел под свой задачи и все. Поэтому и предлагаю Вам в качестве примера.
Мы с уважаемым MaksVV обсуждали уровни абстракции от железа, в темах выше.
В общем думаю будет возможность как получить данные со всех однотипных датчиков из которых получаем например температуру, так и абстрагированный датчик температура в помещени в котором уже обработанные усредненные данные со средней температурой по больнице ;-)
Та же история например с защитой от протечек. Есть N датчиков протечки и N исполнительных кранов c датчиками положения кранов, можно как снимать с каждого датчика и крутить каждый кран так и сделать абстракцию протечка->>перекрыть краны.
Вот кстати еще пример, меня не устраивает только датчик движения для включения выключения света (махать руками чтобы свет зажегся несколько глупо). Соответственно будет сложная система оценки наличия человека в помещении, его поведения (движения) с привязкой к шуму и времени дня. В дверном проеме стоит датчик открытия двери, 2 лазерных датчика как в метро для подсчета вошедших и вышедших в помешение, датчик звука и микроволноыой с тепловым датчиками движения. С реализацией сценариев вечер, с плавным выключением света даже если человек в помещении (вдруг я заснул), гости, ребенок и пр.... Тут поле для фантазии.
Сервер естественно будет, будет MQTT брокер на сервере, MQTT или MQTT-SN брокер на ардуино и MQTT или MQTT-SN клиент на MK. Естественно велосипед изобредать не будем, все с Github.
Посмотрите файл структура сети https://yadi.sk/d/uJmEBPO_3UCBjj
Ну и сам прототип
По поводу уровней абстракции и группировки датчиков и ИУ.
Этот вопрос нужно сначала серьезно обдумать.
Один и тот же датчик будет использоваться в разных системах для решения различных задач.
Вот например, герконовый датчик в окнах решает задачи охраны, температуры и влажности а так же блокирует кондиционер. И таких совмещений множество.
По исполнительным устройствам та же петрушка.
Вот например у меня 3 шаровых электрокрана, 2 перекрывают холодную и горячую воду а 1 подает холодную воду на проточный водонагреватель.
У меня 2 сценария
1. Протечка закрыть кран ГВС и ХВС
2. Нет горячей воды (пока кнопкой, потом автоматизирую) закрыть кран ГВС открыть кран на водонагреватель (на выходе водонагревателя стоит обратный клапан поэтому кран один)
И у каждого крана 2 концевика которые сообщают о статусе крана.
Для MaksVV.
Собрал стенд на 15 узлов +CANHacker
Отладка показала что мы слишком расслабились. И как я ранее и говорил UDP работать не будет. Ни твоя StatusControl() ни моя all_node_status_request() эффективно не работают.
Причина простая. Мы пытаемся отправить сообщение, если сеть занята, то Error Sending Message..., но мы это не обрабатываем, и в итоге твоя рассылка своевременно не отправляются и мои ответы на запрос не отправляются.
Вижу несколько направлений.
1. Рандомизировать отправку по времени. (Синхронизация всех по времени и в дальнейшем запрет отправлять одновременно)
Криво но будет работать. Нужно продумать.
2. Повтор попыток отправки n раз (Тут проблема получить 2 раза одну команду, но номером сообщения можно отфильтровать)
Но тут же проблема, ты раньше меня подкалывал, а вот всплыло, Нужно подтвержение доставки подтверждения ;-)
Т.е мастер отправил запрос статуса всем. Узел начинает отправлять, сеть занята, повторная отправка, доставляем на мастер, мастер по получению отправляет квитанцию что получил.
3. Нужно делать рандомизатор времени повторной отправки, колизия возникает сразу у несколькоих узлов и повтор нужно рандомизировать +- 50 милисекунд.
Мы с уважаемым MaksVV обсуждали уровни абстракции от железа, в темах выше.
Меня "третьим" возмете?.
Еще прочитал Ваши результаты. Да тут есть логика.
Немного из своих изысканий.
Есть сервер.Raspberry3 на нем MajorDomo/ (далее MD) Почему? да потому что, простая и понятная, да и Hарод на нее столько полезного наработал. так что реально. Сам сервер это только "мозг" он конечно достаточно мощный для всех задач видео по крайней мре с него идет легко на 1 смарт 32 и 2 планшетеа одновременно по сети так что его быстродействия хватает. Теперь про основные задачи.
Логику поведения конечно MD может освоить любую причем с выводом все это в любой форме красивой, крутой любой. Только вот есть несколько проблем.
К самой МD что либо цеплять напрямую не получится, нежная да и капризная сразу будет, поэтому обязатено должен быть "Прокладка" Таким может например ESP32 (8266) Ардуино с IP либо пром контроллер c IP/
А вот уже на него и вешать все остальное. Такой вариант не от хорошей жизни. Распбери имеет питание 3.3. в и потребляеи довольно большой ток по 5 в. (около 500 ма и 200-300 HDD). 2 акумулятора от бесперебойника с питанием 12 в и преобразователем 12/5 в обеспечивают ей режим почти 28 часов до потери ее в сети. Хотя сама распбери еще работает но уже ....
Так вот с сервером вопрос решен а вот то чем он управляет и от чего получает информацию все время в развитии.
Тема "распределенного интлекта" меня всегда привлекает по нескольким причинам. Надежность. Простота да и сама структура гибкая.
теперь про то что имеем.
Сервер МВ например не может опрашивать Modbus чаще 1 с . (особенность самого MD), Поэтому на данной сети у меня то что не критично по скорости это например медленные датчики (температура, влажность и пр) которые по данной сетке идут от внешних контроллеров.
Есть шдюз ESP8266-NRF24L01+ANT (c внешней антеной) это датчики MySensors/ Они довольно универсальны и практичны малогабаритные имеют малое потребление (Aрдуино без всех элементов либо просто Atmeg328) габариты тоже привлекают мжно хоть куда встроить. Даи провода не тянуть.
Из опыта рабаоты ... нормально. Когда все настроиш и выставиш логику то просто рабаотает.
Скорость ... ну на 3+ для моих задач с лихвой .
теперь свет.
У меня несколько контроллеров (по этажам) Логика из проста есть Атмега 8 (МК) с портом 485 у которой 8 входов с опторазвязкой и 8 выходов на реле (на ULN2803). сами контроллеры сидят в боксах получают питание 24 в по линии UTP (6 жил) а две это Data. На контроллерах стоят DC/DC преобразователи поэтому все нормально. Реле на 24 в. Выключатель взимодействует с входом МК который конечно быстр и он тут же переводит сигнал на выход т.е транслимрует его на реле. Скорость конечно мгновенная (время реле а паоскольку освещение светодиодные лампы то все работает быстро. Тиристоры и пр. я не использую потому как данный вариант прешеол еще с 2011 г когда были еще и лампы накаливания. Так что работает а это главное.
Теперь что получает МВ? Он просто получает информацию что в такой то комнате включили свет либо выключили. Тут просто модбас. Также можно отключить все лампы либо все их включчить (это команды внутри МК) но поскольку это внешние команды от логики управления то тут ее мгновенность не важна... Ну скажите какая мне разница откроется штора приводом на 1 сек раньше или позже, или выключч\ится свет по какой либо команде с интрвалом 1 сек? Я тут даже не загоняюсь.
А вот команды датчиков кнопка колитки . датчик протечки и пр. где мгновенная реакция важна тут уже логика на основе МК и она либо вживлена в сам управляющий контроллер который обслуживает датчик либо на их старций брате (Мегу256р3) и на ней по сути построено.
Есть еще отдельные ESP8266. на котором крутися AMS и который при своем скудном обеспечении портами обладает хорошим процессором и простым в реализации стеком IP через WiFi. На нем стоит например индикатор LSD20*4 и который висит просто на стене, оформлен он в корпусе эл. счетчика 6803 и довольно прилично выглядит. Ну по крайней мере прошел контроль и допуск WIFE.. Также он имеет свою веб мордочку и на ней довольно много информации. Ну и он конечно имеет MQTT.
Блок управления ворот .. ну тут монстр. Условно.
Его описать просто не получимтся поскольку его алгоритм отрабатавыляс на протяжени 4 лет и постоянно появлялись новые идеии. Там ESP и Нано с возможностью прошивки через Wifi. так что новые идеии просто залить и испытать.
На данном модуле много функций и скорость реакции тоже важна (контакные датчики положения створы и мощный привод) ..так что да. Но и тут IP протокол который все это решает на ура.
Ну также он в перерывах между основной рабаотай управляет калиткой (ключи 1-Buttom) 3 датчика темепературы 1 DHT22/ датчик освещенности и вывод этого всего на сайт Narodmon.ru... так для общего куража.
Ну и 8 реле Двигатель. Прожектора замок и пр.
Есть ешще несколько контроллеров они просты в рабаоте и по сути являются "розетками" это просто комнатные датчики с DHT 11 b NRF (MySensor) .
Есть еще задумки но порой не хватает времени.
Вот как то так. По Вашему проекту, пока до конца не въехал в задумку, очень большой по обему и элементам, такой проект нужно посматривать не наскоком, но идея и сама концепция построения структуры мне нравится. Успеха в реализации.
С Уважением.
Посмотрел наработанный материал .
Не мужики... я шляпу снимаю. Молодцы. Реально серьезный подход. Себе кое что на развитие можно утащу... ?
Для rw4cju.ru
1. Насчет включения в работу, думаю MaksVV против не будет. Основной вопрос что мы не используем совсем системы групповой работы и системы контроля изменений и версий, поэтому то MaksVV что то выкладывает новое, то я. Max что то мое берет, я что то его беру. Мне проще всего, у Вас у обоих уже живая рабочая сеть и проложенная инфраструктура, которую не заменишь. У меня пока только заложены все силовые и слаботочные кабели. (Как я выше писал у меня свет на бистабильных реле, т.е до каждой лампы от щита свой кабель, от каждой группы выключателей из помещений свой кабель. Реле имеет 3 упр. цепи. (Проще смотри РИО-1М) Я таким образом от проходных и перекрестных выключателей ушел и сделал задел для автоматизации. В итоге на выходе реле у меня датчик наличия напряжения а в паралель с кнопкой реле от ардуино.
2. Консультации по MD будут бесценным подспорьем. (Я пока развернул на сервере MD, ioBroker, Domotics, OpenHAB, NodeRED, mosquitto.
Пока впечатления от MD не особо. Возможно я не умею его готовить, но максимум визуализатор и загрузчик сценарием в сеть ниже. Быстродействие и дружественность к пользователю никакая.
3. По поводу топологии сети - Лучше провода может быть только провод. Затем nRF24 или nRF5, Затем Wi-Fi.
Оч. не хочется потерять контроль над домом из-за умершего Wi-Fi роутера. Поэтому Wi-Fi только некритичные приложения типа метеостанции.
nRF24 или nRF5 это для мест куда забыл и уже не смогу проложить кабель.
В общем добро пожаловать на борт.
Согласен. Провод это лучший вариант.
Я не совсем вижу целесообразность такой навароченой структуры в целом. Не в качестве стеба а так совет. Начинайте с простого но если готовите по крупному (а это видно) то советую разбить на сегменты и отработав его как кролика подвать уже как готовое меню.
тут вот в чем дело. При столь развитой структуре будет множество комбинаций которые будут взаимно вложены и при случайном сбое например потеря питания возможно одновременное хоровое пение всех контроллеров в сеть и элементарный перегруз ну и тд.
Кстати биполярные реле могут грешить такими сбоями. Проходные выключатели вещь полезная но саму схему при налаичии разделения по уровню управления и силовая часть можно легко собрать и при допустим отказе контроллра схема перейдет на элементарную электромеханическую. Поэтому рекомендую в скетчи сложных контроллеров при инциалтизации (setup) закладывать раздельные задаржки. например один 1 сек другой 2 и пр. У меня так ESP в сеть входят . Сперво временной разбег потом если не взяли сеть то долбят до подключения. ну и если уж не получилось то есть биперы. Один раз было пищат... оказалось роутер из розетки вместо телефона выключили.
По МВ могу только успешно в части его посадки на Raspberry +HDD тут он прекрасно живет ну и в части простого бесперебойного питания. По его програмироваия все делал на основе примеров и по сути добившись того что нужно не трогаю. Проверено уже более года. Уже и забыл где сервер....
На счет его скорости согласен. Но у него и задачи не особо. OpenHAB юзал но не мое... уж больно какоето оно другое не наше. Менталитет там другой. Хотя как показометор он неплох. А вот логику на него насадить для меня было из серии похода к зубному..
Провода тяните не жалея. Чем больше тем проще. Я тянул в каждую точку и силовой и UTP. Сводил все либо в боксы либо если это IP на центральный HUB/ UTP советую отечественый не китай хотьи дороже. В нашем вроде медь есть да и изоляция лучше Китайский он магнитом провод реагирует по сути стальной и он кородирует это сильно отражается на передече сигнала. Из опыта раоты в организации пришлость перетягивать несколько этажей. Сетка прото вставала.. Вплоть до того что просто из комнаты в команату 5-10 м сигнал не проходлил. Заменили все красота.
Роутер да ..хотя мой уже 10 лет, 24 часа и круглый год... лежит новый но пока не открывал..
Для MaksVV
Поправил немного твой debug.h https://yadi.sk/d/uJmEBPO_3UCBjj/Project_can/work_can/node_4_Net_center_Due1_Eth
Получилось прикольно, сначала придумали что за дачтики, потом перевели на английский их названия, потом в больбе за память сократили названия, потом перевели назад на русский. В итоге что за датчик уже не понять.
Согласен. Провод это лучший вариант.
Я не совсем вижу целесообразность такой навароченой структуры в целом. Не в качестве стеба а так совет. Начинайте с простого но если готовите по крупному (а это видно) то советую разбить на сегменты и отработав его как кролика подвать уже как готовое меню.
Здесь Вы с MaxVV скорее сойдетесь, я же проектируюсь уровнями, слоями. Один слой отработать, второй слой, третий. Вот сейчас как раз оттрабатываем взаимодействие контроллеров в сети в разных режимах.
По сути не важно что передавать между контроллерами. Важно обеспечить гарантированну, своевременную доставку и подтверждение доставки. На следующем этапе передача команд и информации между МК-ми, мастером и сервером. Потом верхние протоколы.
тут вот в чем дело. При столь развитой структуре будет множество комбинаций которые будут взаимно вложены и при случайном сбое например потеря питания возможно одновременное хоровое пение всех контроллеров в сеть и элементарный перегруз ну и тд.
CAN как раз и является протоколом с разрешением колизий, главное его правильно использовать (см. обнаруженные выше косяки с сообщениями) А для резервирования CAN я думаю поставить ESP-01 (Wi-Fi) на каждый нод для удаленной прошивки (esp-link) и резерва по MQTT
Кстати биполярные реле могут грешить такими сбоями. Проходные выключатели вещь полезная но саму схему при налаичии разделения по уровню управления и силовая часть можно легко собрать и при допустим отказе контроллра схема перейдет на элементарную электромеханическую. Поэтому рекомендую в скетчи сложных контроллеров при инциалтизации (setup) закладывать раздельные задаржки. например один 1 сек другой 2 и пр. У меня так ESP в сеть входят . Сперво временной разбег потом если не взяли сеть то долбят до подключения. ну и если уж не получилось то есть биперы. Один раз было пищат... оказалось роутер из розетки вместо телефона выключили.
Оч. интересные идеи и с задержкой на запуск, прямо delay в сетап запихнуть, и watchdog тоже в разнобой настроить, и бипер по аварии.
По МВ могу только успешно в части его посадки на Raspberry +HDD тут он прекрасно живет ну и в части простого бесперебойного питания. По его програмироваия все делал на основе примеров и по сути добившись того что нужно не трогаю. Проверено уже более года. Уже и забыл где сервер....
На счет его скорости согласен. Но у него и задачи не особо. OpenHAB юзал но не мое... уж больно какоето оно другое не наше. Менталитет там другой. Хотя как показометор он неплох. А вот логику на него насадить для меня было из серии похода к зубному..
Провода тяните не жалея. Чем больше тем проще. Я тянул в каждую точку и силовой и UTP. Сводил все либо в боксы либо если это IP на центральный HUB/ UTP советую отечественый не китай хотьи дороже. В нашем вроде медь есть да и изоляция лучше Китайский он магнитом провод реагирует по сути стальной и он кородирует это сильно отражается на передече сигнала. Из опыта раоты в организации пришлость перетягивать несколько этажей. Сетка прото вставала.. Вплоть до того что просто из комнаты в команату 5-10 м сигнал не проходлил. Заменили все красота.
Роутер да ..хотя мой уже 10 лет, 24 часа и круглый год... лежит новый но пока не открывал..
По кабелям согласен. У себя положил UTP 6E для Ethernet и сигнальный 4-6 жил в оплетке для датчиков и контроллеров.
Вот еще нашел такой контроллер CAN Serial-CAN-BUS-Module
https://www.seeedstudio.com/Serial-CAN-BUS-Module-based-on-MCP2551-and-M...
Для MaksVV.
Собрал стенд на 15 узлов +CANHacker
Отладка показала что мы слишком расслабились. И как я ранее и говорил UDP работать не будет. Ни твоя StatusControl() ни моя all_node_status_request() эффективно не работают.
Причина простая. Мы пытаемся отправить сообщение, если сеть занята, то Error Sending Message......
..........Нужно делать даже не очередь команд а очередь отправки всего.
Вот это оооочень странно. Мы для этого и выбирали CAN а не 485. По идее это должно аппаратно разруливаться, так как для отправки всего уже есть буфер, аппаратный в мсп2515. Там их даже два. Попробуй отключать по одному.узлу. посмотри на скольких оставшихся начнет стабильно отправлять кан сообщения
Раз в секунду шлют статус, для кан это вообще вечность. Не верю что шина занята, тут что-то не так
Но раз уж такая фигня пошла. Мастер тоже шлет статус, широковещательно. В поле данных этого статуса будет время. Узлы читают это время. Каждой группе узлов назначаются "свои" секунды отправки статуса, конкретный МК в группе прибавляет "свои" милисекунды. Всё это делается чтобы разнести отправку статусов по времени, но также всё это будет засинхронизировано, т.к. происходит относительно времени мастера. Получается на одну секунду можно вешать 10 МК, если разницу между соседними отправками сделать в 100мс.
Также можно , наряду с очередью отправки команд , сделать очередь (читай буфер) вообще отправки CAN сообщений, раз уж аппаратная часть не справляется.
соединять очереди эти в одну нельзя. Т.к. критерии удаления из очереди разные и тело буфера разное.
У отправки команд критерий: удаляется из очереди, когда узел ответил.
а критерий у очереди вообще отпраки кан-сообщений: удаляется из очереди, когда сообщение удачно отправлено.
Вот это оооочень странно. Мы для этого и выбирали CAN а не 485. По идее это должно аппаратно разруливаться, так как для отправки всего уже есть буфер, аппаратный в мсп2515. Там их даже два. Попробуй отключать по одному.узлу. посмотри на скольких оставшихся начнет стабильно отправлять кан сообщения
На самом деле все корректно, и это недоработка нашего протокола.
Механизм разрешения коллизий (в отличие от механизма обнаружения коллизий в Ethernet)
Его суть заключается в том, что каждый узел слушает сеть и, если она свободна, может начать передачу. При этом, он продолжает слушать сеть. Если при посылке рецессивного бита принимается доминантный, значит одновременно с этим узлом начал передачу другой узел с более высоким приоритетом. В этом случае передача прекращается.
Т.е если сеть занята то контроллер не начинает передачу и это нормально! Железо обнаружило предпосылку к колизии и прекратило передачу.
Вот мы попытались отправить
1sndStat = CAN0.sendMsgBuf(txId_can, DLC, data)Вот оценили факт отправки
1if(sndStat == CAN_OK)2{3Serial.print("Send OK");//Коллизии нет4}5else6{7Serial.print("Send Error");//Коллизия есть, требуется повтор передачи8}И вот в секции Serial.print("Send Error"); нужно что то делать
P.S.
Так в либе есть лучше решение, пока смотрю.
INT8U MCP_CAN::sendMsg() отдает
return CAN_OK; return CAN_SENDMSGTIMEOUT; return CAN_GETTXBFTIMEOUT;
01INT8U MCP_CAN::sendMsg()02{03INT8U res, res1, txbuf_n;04uint16_t uiTimeOut = 0;0506do{07res = mcp2515_getNextFreeTXBuf(&txbuf_n);/* info = addr. */08uiTimeOut++;09}while(res == MCP_ALLTXBUSY && (uiTimeOut < TIMEOUTVALUE));1011if(uiTimeOut == TIMEOUTVALUE)12{13returnCAN_GETTXBFTIMEOUT;/* get tx buff time out */14}15uiTimeOut = 0;16mcp2515_write_canMsg( txbuf_n);17mcp2515_modifyRegister( txbuf_n-1 , MCP_TXB_TXREQ_M, MCP_TXB_TXREQ_M );1819do20{21uiTimeOut++;22res1 = mcp2515_readRegister(txbuf_n-1);/* read send buff ctrl reg */23res1 = res1 & 0x08;24}while(res1 && (uiTimeOut < TIMEOUTVALUE));2526if(uiTimeOut == TIMEOUTVALUE)/* send msg timeout */27returnCAN_SENDMSGTIMEOUT;2829returnCAN_OK;30}а вот и сама
1INT8U MCP_CAN::sendMsgBuf(INT32U id, INT8U ext, INT8U len, INT8U *buf)2{3INT8U res;45setMsg(id, 0, ext, len, buf);6res = sendMsg();78returnres;9}Сделал вывод значения sndStat = CAN0.sendMsgBuf(txId_can, DLC, data);
Выдает постоянно 7
Ниже возможные значения
Проблема не что раз в секунду а что эта раз в секунду у всех одновременно, т.е начинает передачу сразу 5 контроллеров из 15. Проблема плавающая, фронты немного сдвинуты, скорость загрузки смещена, вот и конфликтуют иногода, но за ночь статистика не веселая.
Я запускаю все контроллеры махом (ставлю ноут на докстанцию и питание пошло) так же будет и в сети, общее питание контроллеров по сети.
Но раз уж такая фигня пошла. Мастер тоже шлет статус, широковещательно. В поле данных этого статуса будет время. Узлы читают это время. Каждой группе узлов назначаются "свои" секунды отправки статуса, конкретный МК в группе прибавляет "свои" милисекунды. Всё это делается чтобы разнести отправку статусов по времени, но также всё это будет засинхронизировано, т.к. происходит относительно времени мастера. Получается на одну секунду можно вешать 10 МК, если разницу между соседними отправками сделать в 100мс.
Также можно , наряду с очередью отправки команд , сделать очередь (читай буфер) вообще отправки CAN сообщений, раз уж аппаратная часть не справляется.
соединять очереди эти в одну нельзя. Т.к. критерии удаления из очереди разные и тело буфера разное.
У отправки команд критерий: удаляется из очереди, когда узел ответил.
а критерий у очереди вообще отпраки кан-сообщений: удаляется из очереди, когда сообщение удачно отправлено.
Тут все проще и сложнее, нужно сделать очередь в ТХ их которой удалять сообщения если if(sndStat == CAN_OK), а вот делать очередь FIFO-LIFO или в других комбинациях нужно думать. Т.е. не смог я отправить сообщение а за мной в очереди еще 5, мне это же отправлять или следующее.
Если считать наш протокол канальным или сетевым уровнем то долбить до упора 1 сообщение. Т.к. отказ контроллера или сеть занята идли нет транпорта.
Теоретически MCP2515 от нас должен скрыть канальный уровень, но это не совсем так, мы видим что сеть занята и прекращаем передачу. Так что у нас концы из канального уровня и полный доступ к сетевому.
А вот если делать еще очередь с подтверждением, типа ТСР т.е транспортный уровень до тут нужно думать, я бы ставил сообщение в конец.
Вообще придется все 3 уровня отлаживать
1. контроль передачи - ушло не ушло - if(sndStat == CAN_OK)
2. контроль пути передачи и адресация - здесь просто ответ что получил
3. контроль доставки данных и команд - здесь ответ что данные корректны команда выполнена.
Не совсем понятно что с буфером у MCP2515 и как с ним работать. Я увеличил задержку в либе сначала до 100 потом до 1000 (#define TIMEOUTVALUE 1000 в mcp_can_dfs.h) ошибки пропали на 1000
Нашел в чем проблема с буфером, http://forum.arduino.cc/index.php?topic=410276.0
Надо фильтровать, без фильтров буфер забиваем!
И нужно наконец RX прерыванием в любом месте цикла вызывать, хотя думать надо.
Дак аппаратный буфер в mcp2515 на прием или на отправку? Или на то и на другое? По идее не должен буфер на отправку заполняться, из-за того что входящие сообщения аппаратно не фильтруем.
В прерывании нельзя весь RX выполнять. Слишком большой он. Максимум флаг ставить что сообщение принято. Хотя чем это будет отличаться от настоящего варианта, непонятно.
Т.е. ты сделал задержку вместо 100мс одну секунду? Это время, в течение которого mcp2515 делает попытки отправить сообщение в кан из своего буфера? В принципе это выход, костыль конечно, но все же.
В общем я разберусь все таки с этими масками/фильтрами.
Тут как раз ты дока, я про этот буфер и не знал. Пробую либу расковырять, но там регистры и пр. я в этом утону.
Нужно подбирать параметр. Но на 15 узлах 50 мс и даже 100 мс мало, 1000 поставил на попробывать. Сейчас твой код доковыряю, и потестирую сеть.
я вот тут читал про mcp2515. На русском и более менее понятно. Пишут что там два буфера приёма и три передачи
я вот тут читал про mcp2515. На русском и более менее понятно. Пишут что там два буфера приёма и три передачи
Просто глубочайший поклон за статью. А то как слепой тыкался по логике работы контроллера.
почитал немного, ну не должно переполнение буферов приёма влиять на передачу. Пропуски принятия сообщений может быть, но вот передача причём.
Вылетаем здесь sndStat == CAN_OK с 7 вместо 0, еще 6 если частый опрос от меня
Попробую вернуть 50мс и начать дебаг по библиотеке в глубину.
а что если 1000 мс оставить?
а что если 1000 мс оставить?
Буду рассматривать все варианты. Главное добиться работы канального уровня.
Сетевой и транспортный это позже. Тем более ты его почти доделал.
а ты точно физически всё нормально соединил? замеряй сопротивление между проводами CAN. должно быть около 120 Ом. Может терминаторы где забыл, или наоборот лишние. И провод должен быть витой. Ну и соединения ардуины и кан модулей. Я вот щас тестировал, тоже даже на проверенных скетчах были сбои отправки, оказался плохой контакт на проводочках SPI шины.
короче вот скетч. тема такая. Мастер шлёт статус раз в 2 секунды (можно выбрать) широковещательно. ( Этот статус в частности получает и слейв, чтобы контролировать исправность мастера.) Как только любой подчинённый узел получает этот статус от мастера, запускается таймер равный адрес МК умножить на 50мс. Таким макаром даже 25 МК в сети отправят свои статусы за 1,25 секунды, что меньше периодичности отправки статуса мастером. При этом отправки статусов от всех узлов разнесены по времени. Проверил работает. Теперь ты проверяй на своих 15 узлах.
Пока мнение недоформировалось, но что то подсказывает, что связь наука о контактах
Вот лог за ночь, в моем цикле мастер опрашивал каждые 20 сек. ведомые контроллеры. Заполняя и твой StatusNode_OK и мой array_request_status
https://yadi.sk/d/uJmEBPO_3UCBjj/Project_can/work_can_log_09.04.18
Инициативно работал только мастер, остальные только отвечали. Передачу принудительно ограничил 60 мс.
Все работало без сбоев, пока я с утра не подошел, не знаю что сделал, но пошли ошибки, причем перезагруз не помог.
Да и посмотри на последнюю версию, там и твой код встроен https://yadi.sk/d/uJmEBPO_3UCBjj/Project_can/work_can
Нужно как то договориться о структуре уже отработанных функций да еще в отдельных файлах и их не менять.
Посмотри как я вынес из RX твой код RX_processing и debug
Предлагаю в дальнейшем базовые отлаженные функции зафиксировать и структуру не менять, чтобы не глядя брать например RX_TX, WEB, Command_Executin.....
Максимум должны изменяться количество и тип аргументов в вызываемых функциях
проверь на 15 узлах скетч #592. там исправляешь только адрес узла и дефайн мастер или подчинённый. Причинами твоих глюков отправки, возможно являются множество ошибок в твоём скетче. Поэтому я пока не собираю всё в кучу. Толком конкретный элемент работы скетча ещё не проверили, а ты уже другое добавляешь.
Нужно как то договориться о структуре уже отработанных функций да еще в отдельных файлах и их не менять.
вроде отладка хорошо работала , поэтому далее ты сам себе противоречишь:
дело в том, что мы и так часто прыгаем из функции в функцию и всё время передаём аргументы, причем по значению. Это нехорошо.
Максимум должны изменяться количество и тип аргументов в вызываемых функциях
вкладка RX TX ещё не дописана, Command_Execution тоже .
мой то скетч эм, как бы сказать, моветон. А у тебя дак это вообще жесть. Ну например взять это
было так
01voidStatusTX (byterem_addr) {0203if(curMillis - array_request_status[rem_addr][1] > interval_repeat_send_status)04{05#ifdef debug06Serial.println();Serial.print (F(" Отправлено сообщение СТАТУСА для узла - ")) ;07PrintADDR(rem_addr);Serial.println();08#endif09counter_send_frame ();10make_data_frame(0,0,0,0,0,0,0,message_number);// ВОТ ЭТО НАФИГА ФУНКЦИЯ???!!!!11TX (0,6,rem_addr,00,EXTENDED, DATA_CANFRAME, 8, data);12array_request_status[rem_addr][1] = curMillis;13}14}15161718voidmake_data_frame(bytea,byteb,bytec,byted,bytee,bytef,byteg,byteh)19{20// ЭТО ЧЁ ЗА ТАКОЕ БЕСПОЛЕЗНОЕ ПЕРЕКАЧИВАНИЕ БАЙТИКОВ???!!!21data[0]=a;22data[1]=b;23data[2]=c;24data[3]=d;25data[4]=e;26data[5]=f;27data[6]=g;28data[7]=h;29}проще так сделать
01voidStatusTX (byterem_addr) {0203if(curMillis - array_request_status[rem_addr][1] > interval_repeat_send_status)04{05#ifdef debug06Serial.println();Serial.print (F(" Отправлено сообщение СТАТУСА для узла - ")) ;07PrintADDR(rem_addr);Serial.println();08#endif09counter_send_frame ();1011for(inti = 0; i<7; i++) data[i]=0;// ВОТ ТАК ПРОЩЕ ПО-МОЕМУ12data[7] = message_number;// И НЕ НАДО НИКАКИХ ФУНКЦИЙ1314TX (0,6,rem_addr,00,EXTENDED, DATA_CANFRAME, 8, data);15array_request_status[rem_addr][1] = curMillis;16}17}а про этот массив я вообще молчу
1longarray_request_status[NODS_NUMBER][6];2//previousMillis перезапросы если нет ответа //message_number //flag_mk_reepeat //flag_mk_answer //previousMillis опрос//разрешение на опросмало того, что он знакового типа long (т.е. будут отрицательные значения при переполнении, что для таймера имхо не допустимо), дак ещё в массиве только два элемента из 6 используют тип long, остальное почти всё - флаги (по сути это бит записывается в 4 байтовую ячейку, не жирновато ли для одной единички или нолика?).
т.е. 4 ячейки не рациональных умножаем на количество узлов 30. получаем 120. Т.к. нерациональность в три байта (могли только один применить, а применили 4 - тип long столько занимает). 120*3 = 360 байт ты просто за зря сжёг из ОЗУ. Это расточительство для МК уровня ардуино.
проверь на 15 узлах скетч #592. там исправляешь только адрес узла и дефайн мастер или подчинённый. Причинами твоих глюков отправки, возможно являются множество ошибок в твоём скетче. Поэтому я пока не собираю всё в кучу. Толком конкретный элемент работы скетча ещё не проверили, а ты уже другое добавляешь.
Так я за тобой уже не успеваю ;-), уже трачу больше времени на разбор твоего кода нежели на написание своего.
Предлагаю собрать базовую структуру программы и основной алгоритм, утвердить и в нем крутится.
А функции я делаю если код более 10 строк с одном CASE
Ладно это лирика. Работаем как кому удобнее, дальше как нибудь светем все воедино.
Просто на выходе нужно делать библиотеку и если глянешь на их структуры, то там все разбито на функции и процедуры, внутри классов и структур.
#592 Вечером проверю.
мой то скетч эм, как бы сказать, моветон. А у тебя дак это вообще жесть.
voidmake_data_frame(bytea,byteb,bytec,byted,bytee,bytef,byteg,byteh)Я ее на будущее сделал, ты каждый раз работая с фреймом на отправку повторяешь один и тот же код
data[0] = x; data[1] = y; .....
Я же просто думал при формировании фрейма на отправку сказать
make_data_frame (x,y, ....), а лучше ее в функцию передалать с выдачей сразу byte data[8], чтобыTX(direction, msg_type, rem_addr, dev_type, can_ID_type, can_frame_type, DLC, make_data_frame (x,y, ....))
Может у меня привычка дурная С++ но я наследовать код пытаюсь, чтобы не повторяться.
Эту шляпу
longarray_request_status[NODS_NUMBER][6]; я переделаю. Помнишь вначале вообще Float испоьзовался. Главное чтобы заработало, потом отладка и оптимизация.В любом случае мне кажется у нас на выходе не плохо получается, взаимная критика дает плоды и код живет.
посмотри, там полюбому все по указателям или ссылкам передается между функциями. А классами и структурами я не умею пока оперировать. Учиться надо.
Нужно проще всё делать, по возможности. Вот ты запрашиваешь статус каждого узла. потом они отвечают. А посмотри как я сделал. Один статус мастера и все отвечают. Так сказать статус за статус. И кода мимимум. причем периодическую отправку статуса мастером запихал в таймер периодической проверки "а на связили узлы" (StatusControl()).