Arduino.ru

Да и еще, ты в основном файле задаешь 

а потом еще раз

Предлагаю убрать второй блок и переменные SendAddrStatus_master и SendAddrStatus_slave.

Докладываюсь ;-)

1. Код интегрировал, залил в МК смотрю за сетью. Заливку прошивок делал по радио. Круто под потолком сидеть не нужно. ESP-LINK вещь.

2. Команды over CAN работают. Пока тестирую.

3. Непонятным образом включение твоего нового кода (причем замена предудущего) привела к тому что скетч не лезет в UNO 130% памяти и глобальных переменных. Отключение debug дало 55%

Если не сложно глянь, ты дока в оптимизации. 

node_18_Loggia_recuoerator

Старый лежит https://yadi.sk/d/ozOcbX7B3V5hYy а новый со всем кодом сети https://yadi.sk/d/qCKaB5ic3V3QAx

4. Дальше сделаю обмен прошивки MK через Wi-Fi ESP8266 по SLIP/REST/MQTT с MajorDomo + Cacti + Zabbix

5. Еще доделаю Web сервер для DUE и возможно мег (буду кусками код тянуть у AMS)

6. Следующим этапом MQTT over CAN тут смотрю 2 варианта либо шлюзом будет DUE/MEGA CAN->MQTT->MOSQUITTO->MAJORDOMO

либо шлюзом будет Linux машина DDUE/MEGA CAN->IP CAN->Мой софт->MOSQUITTO->MAJORDOMO

И еще вопросы есть

1. Не сталкивался с задачей с arduino управлять устройством вместо пульта 2,4 RF. Интересует какое железо (nRF 2.4G?) какой софт (либы) и как отсканировать команды. 

2. Тот же вопрос по кондиционерам (Управление эмуляцией IRDA это не выход https://github.com/ToniA/arduino-heatpumpir) надо что то с обратной связью 485, Eth или Wi-Fi.

Сообщения об аварии добавлю.

 Короче не смог я залить твои Node 4 и18. Не компилируется у меня нифига. Time.h какого то не хватает и т.д. Код у тебя много больше моего. И когда возникают неполадки в работе -  не факт, что в моей части кода. Ты сначала заливай только мой код на все узлы и проверяй стабильность по связи кан. (ты писал что 2 и 3 узел чтоли отваливаются). Нужно узнать в какой части кода косяк, твоей или моей.

Действительно нету защиты, причём защита то БЫЛА! Смотри ещё далекий #592. Причём защиту я ставил прямо в функциях распечатки в debug.h. Я просто когда переделывал чёто там из твоего debug.h  - её не перенёс, невнимателен был, исправлю.

С этим да, нужно аккуратнее. Заметь, в моём последнем коде выбор аппаратной части происходит до объявления can_struct.h. Это важно, переделай, а то там кое-чё работать не будет. 

Кстати я всё таки победил компилятор, ну на счёт того, чтобы вынести всё с первой страницы. Короче переменные нужно выносить во вкладку обязательно чтобы это был файл.h . В таком случае их можно объявить в ОПРЕДЕЛЕННОМ МЕСТЕ, объявляя файл.h    А вот при выносе функций , наоборот, должна быть просто вкладка .ino , которую объявлять не нужно.

На счёт того, что размер флеша при компиляции у тебя подрос до 130%, ну не знаю.

Старая версия у меня 66% Флеш. 54% на глоб. Переменные

Новая версия 75% флеш. 50% глоб. Переменные.

Смотри, всё таки видимо твоя часть кода значительно добавляет флеш.

На счёт управления по 2.4 ггц и кондиционера не подскажу, не имел такого опыта.

https://yadi.sk/d/uJmEBPO_3UCBjj здесь библиотека.

На самом деле Time1.h это Time.h которую я переименовал. У меня кофликт либ вылез и проще было так.

я все же не пойму, ты же вроде говорил что статусза статус это гениально. А в итоге всё равно используешь свой long массив статусов. 

Ты же хотел от него отказаться. По коду твоему посмотрел, вроде как активен он. 

Конечно у твоих узлов  будут глюки, особенно если это нано или уно. Т.к. добавив ТОЛЬКО этот  массив, заполнение  ОЗУ возрасло с 50% до 77%. Компилятор уже ругается что недостаточно. А у тебя там ещё столько всего понапихано. 

1. Массив я уберу.

2. Статус на статус оставляю.

Просто раньше не глючило.

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

а зачем? я ж тебе толкую - чем проще , тем надежнее.  Код и так уже ппц  -  хрен чё разберёшь. Вот ты там гибрид из кодов сделал -  у тебя, каким то образом, в отсылке параметров, в теле сообщения в байте С это причина отправки параметра стоит 01 и 02. Так не должно быть. Вот сейчас не понятно кто накосячил ты или я ))

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

вот тебе простой пример. Тестируя команды PWM_TURN_OFF, PWM_TURN_ON я выяснил что , например, если добавляешь яркость лампе командой PWM_TURN_ON, потом ещё добавляешь, и если она горит уже в полный накал, если ещё раз добавить, накал на ноль сбрасывается и уже начинается с нуля добавлять. Некруто это, исправил. И таких мелочей будет миллион обнаруживаться в процессе. Понятно, что всё в при тестировании откатать невозможно, но основные моменты желательно. 

- защиту от некорректных данных к распечатке в debug.h вернул. 

- из первой страницы переменные перенёс в  файл System_variables.h

- из первой страницы функции перенёс во вкладку System_functions

- сделал отправку аварии, если узел пропал из сети. Логика такая. Через 30 секунд после старта мастера он начинает "ждать" отправки аварии. Если статус узла "мертв" и флаг позволяет - отправляем аварию на узел мониторинга один раз. Подтверждений от мониторинга делать не стал, муторно это всё, да и нафиг не нужно. 

Флаг разрешения отправки аварии сбрасывается только если статус узла становится "жив".

Самое главное. Адрес битого узла в аварийном сообщении находится в последнем разряде ID (на месте dev_type). Я специально не стал заносить адрес битого узла в тело сообщения, чтобы легче было мониторить в канхакере битые узлы. (При моём подходе сообщения об аварии разных узлов будут с разными ID). Поэтому оставляем канхакер на сутки или более и смотрим какие аварийные ID будут присутствовать в списке, а также мы видим количество повторений фреймов с этими ID, т.е. узнаём сколько раз узел возобновлял и вновь терял связь. 

RIV_full_typemsg5

Получение подтверждения аварии нужно для принятия решения мастером, пытаться справится с аварией своими силами (работать автономно) или ее обработает верхний узел.

значит нужно очередь опять городить 

Я готов твой код взять за основу, но мне нужно иметь возможность встраивать свой код и нужен API. Т.е так не любиме тобой функции. 

Я начал сейчас прикручивать MQTT и для передачи и получения  мне нужны вызовы функций.

Вот например

Это я публикую на Mosquitto для Majordimo температуру. Но я ее как то должен получить.

Дай мне функцию вида 

float temp(имя узла, № датчика) а лучше float parametr(имя узла, № датчика, тип датчика, ххх .....) 

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

dev_make_command(имя узла, № у-ва, тип у-ва, ххх....)

для того чтобы вытащить датчики и устройства выше.

Так же мне нужна возможность встройки кодя для Web сервера, Ethernet и пр.

P.S.

Сделай наконец ф-ю RX() как набор вызвваемых обработчиков (См. мое деление RX_TX и RX_Rroccesing)

Я тогда сосредоточусь на тестировании, выносе наверх и прикручивании датчиков и ИУ, а то накупил датчиков и 4 дня вместо их пайки собирал и отлаживал гибрид твоего и моего кода.

Нужно наконец вместо кодерства продумать структуру и функциональность кода. А то мы как графоманы, кодим ради кодинга.

Нужно наконец структуру и функциональность кода определить. Что, как, кому отправлять и получать и взаимодействовать.

Отрисую функциональную схему на согласование.

.

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

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

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

Насчет массива тут вопрос к обсуждению.

Вот например могут 2 МК мимо мастера общаться и принимать решения? У меня например Есть контроллер коридора с датчиками и есть контроллер управления светом (реле замыкатели и датчики наличия напряжения по 20 шт)  тоже стоящий в коридоре, но он берет инфу от контроллера в коридоре и др. помещениях и управляет светом. Как быть ? через мастер гонять или представить этот контроллер исполнительным устройством? Думать надо.

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

Мне казалось что у тебя это есть. Даже через консоль все работает ф-я test.

Чет сумбурно все.

Давай по шагам.

1. Я сегодня соберу прошивки на твоем коде под все контроллеры и залью в контроллеры отключив дебаг.

Могут два узла общаться и без мастера. Отправка параметра по запросу от любого узла уже реализована. Мастер тут не нужен. Контроллер в коридоре по запросу от контроллера света посылает ему инфу с датчиков и всё. 

Да, залей пока мой код во все МК. Подключи канхакер, если оживил его. Там видно будет кто сколько раз по кану проштрафился.  

Для работы слейва (пока функциональность не написана) добвь плиз везде

И в void StatusControl ()

if (i!= node_address && i!=1 && i!=2 && i!=3 &&  i!=16 && i!=17 && i !=0)

Для отключения 1,2,3, 16,17 их у меня по CAN нет.

Ну в общем да есть но не всё. Функция отправки команды присутсвтует уже. Можешь дергать её сверху. 

SendCommand (тип команды,   2 разряд команды,   таргет адрес узла,   таргет адрес девайса/параметра). 

типы команд: 

во втором разряде команды будет содержаться некая величина, например, если имеем тип команды PWM_SETTING то во втором разряде команды будет целевая величина ШИМ. 

если PWM_TURN_ON то во втором разряде команды будет цифра насколько нужно увеличить ШИМ, относительно действующей величины ШИМ 

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

ну и т.д.

Конструкция 

#ifdef type_node_mk or type_node_slave

не работает!

Пришлось дублировать.

а так ? 

вот, переделал по конструкции как в предыдущем посте,  вроде работает. Также убрал из мониторинга отсутсвующие в CAN у тебя узлы

А потом когда у слейва свуой код появиться опять все переделывать. Лучше свои секции для слейва с кодом аналогичным МК.

Так категорически ненужно!!!

Первичный вывод

1. С дебагом прошивка перестает нормально разбирать из CAN пишет NULL_C NULL_A пр.

2. Без дебага вроде живет, посмотрим что к утру будет.

3. UNO вылетает в обоих вариантах. (Правда у меня MD-328 и у нее свои либы)

Вобщем прошивка не выдержала суточный прогон. Даже с отключеным дебаго узлы начинают сыпать FAIL

Непонятно почему, но где то видимо в каком то цикле переполнение. Узел начинает слать ХЛАМ и переполняются все. В итоге сеть ложиться.

Моя прошивка https://yadi.sk/d/CVQWXRdr3VGje2 (гибрид с твоей RIV_full_typemsg 1 и 2 версий) жил неделю без сбоев.

Тут уже нужен системный подход. Сделал кусок. Отладил. Зафиксировал.

Вот смотри я ведь сделал в своей прошивке в setup()  delay (random(500,2000)); это позволило запустить контроллеры асинхронно.

Поставил рассинхронизацию. Вроде час стоит.

Я думаю основная причина разноразмерные DATA (DLC разных размеров) 

Не понял смысл резать фреймы.

Причина может быть например высокая скорость. Попробуй 125 кБит.

А смысл? У нас сейчас логика такая, что нам не нужна асинхронность относительно старта МК. Сейчас сделано ещё лучше. Асинхронность создаётся относительно факта получения от мастера его статуса. (А статус этот широковещательный, поэтому все получают его одновременно). После этого запускается таймер - у каждого узла он разный (адрес * 50мс). По окончанию таймера узел отвечает мастеру своим статусом. Поэтому отправка статусов от всех узлов разнесена по времени - между ближайшими отправками 50мс. 

А вот периодическая отправка параметров, да - ассинхронизирована относительно старта МК. Которая со временем будет убегать и в итоге отправки параметров могут наложиться друг на друга. Но по крайней мере ассинхронизация не рандомная, а закономерная и без delay.

Но всё равно лучше потом сделать по-другому. И тоже сделать относительно широховещательного статуса мастра. 

Причём в теле статуса мастера передавать время. Вот это общее время и будет точкой отсчёта для всех узлов для любых ассинхронизаций.  А также в логах время можно писать. Будем знать в какое время косяк возник. 

а ты точно как есть мою прошивку залил? скинь все прошивы которые ты залил, я гляну. Может с массивом  параметры что то . и ХЛАМ какого характера узел начинает слать? Хотя бы тип сообщения какой?

у меня уже три часа RIV_full_typemsg6 работает без единого Fail. Один мастер и один узел (Уно и нано). Получается дело может всё таки не в скетче? Что там может переполнится после 3 часов, не знаю. 

добавлено: уже 8 часов, полёт нормальный. 

https://yadi.sk/d/uJmEBPO_3UCBjj

длальше /Project_can/work_can_maksVV

Я отключил везде дебаг кроме 4 и 5 нода. К стати в папке debug_canhacker_log с прошивками смотри лог Canhacker

Два узла и у меня стоят как вкопаные.

Две проблемы вылезает

1. Узел перестает понимать что принял - пишет NULL_C NULL_A и так пока все узлы не откажут, перезагрузка узла снимает проблему. CANHACKER видит что узлу что то отправлено но от него нет ответа.

2. На мастере через час начинает сыпаться без остановки ШИРОКОВЕЩАТЕЛЬНЫЙ, CANHACKER сразу показывает что сеть легла и пакеты не ходят.

Нашёл как надо. Вот так:

откуда берётся NULL_A ? У меня вообще такого в скетче нет. Узлы одни и теже начинают глючить? Если два узла работают стабильно, скетч вроде как не при чём получается.  Скорость CAN пробовал понижать? Когда узел перестаёт понимать что принял, он чтонибудь отправляет в этот момент? 

Обычно такая вата бывает если два устройства соединить по кан без терминаторов

ещё попробуй мастером сделать не DUE а МЕГУ

Было NULL_C и ШИРОКОВЕЩАТЕЛЬНО  (это то что раньше было NULL_A).

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

Уже сам хотел предложить.

Скорость не забудь меньше попробовать

Я конечно все попробую, но вот что меня смущает, ренше то все работало на других прошивках. Ты дебаг смотрел, ничего проливающего свет на проблему не нашел?

Неа, единственное что насторожило от одного узла, он один раз отправил параметры на адрес 82

Ну залей для прикола предыдущие версии. Посмотрим, действительно ли они стабильны.

В CAN есть много чего хорошего, но есть и минусы:

- очень короткие сообщения

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

- жесткие требования к разводке кабелей: это должна быть одна шина с терминаторами с обоих концов и короткими отводами к узлам

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

На этом принципе работает европейская шина для домашней автоматизации KNX (раньше называвшаяся EIB  - European Installation Bus),  а также ее менее известный, но очень близкий родственник - австралийский C-Bus. Непосредственно CAN как таковой для домашней автоматики использует бельгийская фирма Velbus.  KNX и С-bus используют "открытый коллекторный выход" скомбинированный со схемой фантомного питания, т.е.  передают сигнал и питание по одной витой паре.

Эти 3 интерфейса для домашней автоматизации имеют нечто общее между собой:

- работа по принципу "производитель-потребитель", за счет этого включение/выключение света происходит быстро, менее чем за 200 мс, даже если в сети много устройств, скажем несколько тысяч (Модбас нервно курит в сторонке)

- прокладка кабелей - произвольная ("свободная топология"), с любыми ответвлениями, суммарная длина до 1 км (здесь CAN нервно курит в сторонке)

"Свободная топология" достигается это за счет снижения бодовой скорости. C-Bus работает на скорости 5 кбит/сек, KNX - на скорости 9.6 кбит/сек, а Velbus - (вроде бы) на скорости 19.2 кбит/сек.  При этом терминатор ставится один, где-то в середине сети, причем согласование не полное.

Что там колдует Velbus, чтобы CAN работал на низкой скорости при неполном терминаторе - не знаю. Подозреваю, что у них все сделано "на живую нитку", т.е за пределами спецификаций, просто по факту: "как-то работает - ну и слава богу".

Совершенно верно. Ничто не мешает к обычному UART приделать приемопередатчик CAN. При этом во время передачи можно слушать шину и, если принятое не совпало с передаваемым, прекращать передачу, поскольку обнаружено столкновение (коллизия). После этого надо подождать некоторое время (псевдо-случайный интервал) и, если шина пуста, повторить передачу.

Такой протокол называется CSMA/CD, "с обнаружением столкновений". Правда у CAN, KNX и C-Bus сделано лучше, у них CSMA/CA, "с избеганием столкновений", но реализация намного сложнее. А выигрыш от CSMA/CA будет ощутим только в сильно нагруженных шинах, с сотнями устройств и напряженным трафиком. Скажем, в большом оффисном здании или на стадионе.

Сложнее для кого? для инженеров, проектирующих CAN контроллеры? Это да, но спасибо им за проделанную работу. Это всё сделано АППАРАТНО!

А вот это :

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