сердцебиение лучше синхронизировать от мастера . Так гарантированно по времени разнесутся heartbeat-ы узлов. Просто сделать эти heatbeats широковещательными тогда. и будут все видеть, только не пойму, честно, нафига всем это видеть.
А если уж мастер перестал свой heartbeat с временем слать, тогда уж в аварийном режиме начинают ноды сами пульс гнать в шину.
Я говорю как сделан heartbeat в протоколе CANOpen. Твой вариант называется там NodeGuard.
Heartbeat. При мониторинге сети по принципу heartbeat узел автоматически передает свое коммуникационное состояние с регулярными интервалами как доказательство своей коммуникационной работоспособности.
Node guarding. При работе по принципу node guarding определенный узел сети (это главный узел сети, так называемый NMT-master) опрашивает остальные узлы сети (подчиненные узлы, соответственно называемые NMT-slave) фреймом CAN remote (что такое remote frame, см. [12]). Опрос узлов идет последовательно, друг за другом, с заранее определенным интервалом времени ("guard time", защитный интервал времени). В ответ подчиненные узлы должны передать телеграмму данных, описывающую их текущее коммуникационное состояние (stopped, operational, pre-operational) вместе с так называемым битом toggle. Если узел по какой-то причине не ответил на запрос NMT-master в течение заданного времени ("node life time", время жизни узла), то это регистрируется как ошибка соответствующего узла, и показывается контроллеру хоста NMT-master как "node-guarding event" (событие защиты узла). Другими словами, подчиненные устройства NMT-slave также мониторят сеть на предмет обнаружения запроса от NMT-master в течение своего "времени жизни". Если такой запрос отсутствовал дольше, чем так называемый интервал "времени жизни" узла, то узел NMT-slave также предполагает, что мастер сети NMT-master поломался, и показывает это своему хост-контроллеру через "Life guarding event" (событие защиты жизни сети).
Его целые конторы разрабатывали, так что я пошел на поводу. )
Рекомендую почитать здесь про протокол. Очень много идей можно дернуть.
И кстати обрати внимание что даже в CANOpen идет не один широковещательный запрос, а опрос всех по очереди. Я пробовал твой вариант, сеть ложиться ошибки нарастают. Контроллеры при превышении ошибок блокируются.
Помнишь я долго бился об ошибки в сети. Так вот 99% проблема в алгоритмах. И при 125кбит 20 одновременных запросов положит сеть. Так что ребут я на этот случай предусмотрел. Т.к. программно не нашел решения вывести контроллер из состояния блокировки передатчика по переполнению буфера ошибок.
Помнишь я долго бился об ошибки в сети. Так вот 99% проблема в алгоритмах. И при 125кбит 20 одновременных запросов положит сеть.
какие 20 одновременных запросов? это ты про что именно? запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.
Помнишь я долго бился об ошибки в сети. Так вот 99% проблема в алгоритмах. И при 125кбит 20 одновременных запросов положит сеть.
какие 20 одновременных запросов? это ты про что именно? запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.
Если так то хорошо. Важно чтобы они все одновременно не начали отвечать.
А ребут нужен если узел заблокировался. Причем откуда лезут ошибки не понимаю. То стоит сеть неделю без сбоев то пару дней все в ошибках.
ну не знаю на счёт того что , проблема как ты говоришь в алгоритмах. Ты простейший скетч #965 заливал? там супер простая логика:
MaksVV пишет:
мастер шлёт запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.
Я пошел дальше, заливал примеры прямо из библиотеки, и пакеты по по таймеру. И дальше начал увеличивать кол-во узлов. Если их больше 5-6 начинаются проблемы с ошибками.
Причем это не ошибки физики а слишком сильно нагруженная сеть.
Тем более это не вопрос а утверждение. Сейчас проблем нет. Причем сеть работает при периоде HB 1 секунда.
НО! Иногда высыпаются ошибки в нескольких контроллерах. Думаю просто баги в железе либо как выше говорил Demid это проблемы с SPI и нужно уходить в STM либо ESP32.
не понимаю, как может быть нагружена сеть от 6-ти МК, которые по одному сообщению шлют. И уж тем более, когда по времени эти ответы разнесены. Если от этого виснет, нах такая мультимастерная сеть вообще нужна, которая по факту нихера не мультимастерная, а получается уговаривать её надо, сообщения по времени разносить и т.д. Трафик то вообще ниочём и то уже проблемы. В автомобилях вон песец трафик: с периодичностью 10 мс десяток сообщений, 50 мс десяток и ещё куча, которые помедленнее. Хрень какая-то .
Интересно, чё будет когда ты реальным обменом сеть нагрузишь, а не только heartbeat. Возможно проблема вернётся.
возьми поставь только два узла и нагрузи шину - налепи кучу сообщений. И посмотри будут ли ошибки от как ты говоришь "шина загружена" .Имхо всё будет нормально. А вот если ошибки начинаются при добавлении узлов, то имхуется всё таки аппаратная проблема, а не загруженность шины.
У меня mcp-шки фейлились, когда я наваливал в них все метрики подряд, без паузы. Не то, что они вешались - просто не успевали отправить и библиотека возвращала состояние "фейл", которое так же при обрыве линии возникает. Т.е. "доброкачественная" ошибка выглядела как "злокачественная".
ну с этим да , так низя. Получается таким образом забивается TX буфер mcp шки . Я метрики разнёс через 5 мс. Но у RIV то проблема , даже когда всего одно сообщение от узла исходит. Я думаю тут совсем другое.
Хочу напомнить, что когда я тестировал хаб, гонял температуру каждые 275мс с 50 датчиков, то есть в секунду отправляется и принимается всеми блоками 1000/275*50=181 пакет, что грубо около 11кбит/c реальных данных при выставленной скорости 250кбит/с.
О какой загруженности сети вы говорите ? Потолок у CAN шины чуть больше 19000 пакетов в секунду. Без данных конечно. 181 это ни о чем. Вопрос только в обработке такого потока. Сомневаюсь что в форде стоят 8-битные МК с CAN-контроллером через SPI. А вот передатчики +/- те же самые MCP2551.
1.связка 2560 <-> MCP2515 по SPI где могут быть сбои от помех наводимых ESP8266 (я заметил что контроллеры в дальних комнатах с низким RSSI сбоят чаще)
2.помехи на самой линии CAN
3.низкое быстродействие МК за счет чего данные не успевают обработаться. (по RX поставил прерывание) но его можно в MCP ставить только на 1 событие.
Для уменьшения этого сделал:
1. Просмотрел осциллографом всю сеть, поставил где надо терминаторы, объединил землю
но ведь на малом количестве узлов нет ошибок? значит не есп причина. может формирователи шины перепаять на mcp2551? и производительность ардуины тоже тут не причем - говорю трафик вообще ниочем!!! возьми сделай на малом количестве узлов (когда ошибок нет), столько сообщений , эквивалентное такому, как на бОльшем количестве узлов (при котором возникают ошибки). если будет все хорошо - производительность МК не при чем. Главный симптом - появление ошибок при добавлении в сеть участников. надо тут искать причину
нужно подключить can hacker и затестить, что происходит в момент сбоев на шине. и я так и не помню, RIV ты гонял на столе все свои МК при коротком кабеле? Все было хорошо? Может банально всё дело в твоих отклонениях от требуемой шинной топологии?
У меня сеть бывает стоит неделю без сбоев. А потом внезапно начинает сбоить один контроллер и постепенно убивает сеть, причем у него tx error а у остальных rx. И при добавлении новых узлов возникает затухающий сбой, у всех по 100-150 ошибок приема, затем они спадаю до 0 за пару минут.
нужно подключить can hacker и затестить, что происходит в момент сбоев на шине. и я так и не помню, RIV ты гонял на столе все свои МК при коротком кабеле? Все было хорошо? Может банально всё дело в твоих отклонениях от требуемой шинной топологии?
Canhacker и осциллограф уже рабочим инструментом стали.Но проблема не постоянная. Я и веб морду прикрутил для этого. Чувствую скоро до syslog дойду.не могу выявить из-за чего начинается шторм в сети.
я думаю, что нужно исследовать на примерах с библиотеки , на которых чаще глюк проявляется или на том скетче #965. На них тоже должно всё нормально работать. А если глючит , значит есть косяк. просто на них чаще проявляется. А heartbeat -ом возможно ты не решил проблему, а получился некий костыль, немного маскирующий проблему.
я думаю, что нужно исследовать на примерах с библиотеки , на которых чаще глюк проявляется или на том скетче #965. На них тоже должно всё нормально работать. А если глючит , значит есть косяк. просто на них чаще проявляется. А heartbeat -ом возможно ты не решил проблему, а получился некий костыль, немного маскирующий проблему.
Так я и не спорю. Ищу помаленьку откуда уши торчат. Вот и наделал костылей.
Там в перемешку команды, сервисные сообщения, статусы. Относящиеся к состоянию узлов.
Сюда же лягут команды конфигурации узла.
P.S.
Функции установки времени из твоего протокола брать не буду. У меня в сердцебиении мастер отдает аппаратное время которое устанавливается на узлах, а узлы кидают свой аптайм по которым мастер и слейв в web интерфейсе показывают, + мастер отдает для слейва свой аптайм.
Давай всё по порядку и будем максимально точными в своих изречениях, чтобы не запутаться.
riv пишет:
Мне для управления маршрутизацией и управлением сетью не хватает 16 адресов в msg_type поэтому решил его не трогать для совместимости с тобой.
Хочу свои команды управления загнать наверх dev_type. Можешь зарезервировать адреса с 128 по 255?
вот эти две фразы я не понял в принципе. Маршрутизацией чего? управлением чем? Что значит загнать команды наверх dev_type ? Адреса резервировать не нужно. Сколько ты написал девайсов, столько и будет, но не более 254.
riv пишет:
Судя по enum Parameter_addr_enum на 60, тебе адресов хватает. Не против?
вот тут ты, наверное, немного не понял. 60 это не я выбирал, оно получилось само по себе, т.к. всего записали параметров 59 штук (и ещё нулевой адрес, поэтому получилось 60). Соответственно в енуме последняя идёт строка "SIZE_PARAM_ARRAY". В ней и лежит количество сконфигурированных нами параметров (енум сам и подсчитывает), это используется в скетче, чтобы знать количество в списке адресов параметров. Т.е. если, например, сконфигурируешь в списке только 3 параметра, то SIZE_PARAM_ARRAY будет равно 4 (т.к. плюс нулевой ещё).
Там в перемешку команды, сервисные сообщения, статусы. Относящиеся к состоянию узлов. Сюда же лягут команды конфигурации узла.
Где там, куда сюда? Не путай, команды это команды, статусы это статусы.
riv пишет:
Что нужно настроить на узле генераторе команд (какие массивы и какие функции их вызывают)
На том узле, с которого ты хочешь отправить команду, ничего настраивать не нужно. Нужно просто вызвать функцию:
SendCommand (приоритет, тип команды, значение, значение_2, значение_3, значение _4, адрес получателя, тип девайса, № датчика )
Понятно, что эту функцию стоит вызывать, если речь идёт о типах команд «управление GPIO», либо «удалённое изменение значения параметра». Для последующих придуманных типов команд, например «рестарт узла» и т.д. нужно добавлять в мой протокол куски кода.
riv пишет:
Что нужно настроить на узле исполнителе команды (какие массивы device, timeoutsArray, parametrs_quontity, parametr)
команды могут быть разные. Если речь идёт о прилетании типа команды "управление GPIO". то для правильной работы команды , предварительно настраиваешь на целевом узле только массив device. Там указываешь какой девайс, к какому пину подключен, и вид управления (шим, диджитал и т.д.). Если устройство импульсное (например, как у тебя свет уже сделан), то указывается ещё пин ардуино, которым отслеживается текущее состояние девайса (например свет в данный момент включен или нет. Если он включен и прилетает команда "ВКЛ", то импульса на девайс НЕ последует).
Если прилетела команда "изменение значение параметра", то нужно, чтобы данный параметр который хотим изменить был сконфигурирован на этом узле (ну то бишь, что он тут присутствует) и номер датчика не забываем правильно указывать.
Остальные типы команд, такие как инициирование рестарта и т.д. ещё в моем протоколе не реализованы.
riv пишет:
Структура команды в CAN_ID и DATA (msg_type и dev_type)
В приложении мануала ведь четко расписана структура ID и тела кадра команды, читай внимательно . (dev_type содержится в последнем разряде ID, а msg_type это 3 байт тела кадра.
riv пишет:
Какие массивы нужно заполнить на передатчике какие на приемнике команд.
Передатчик и приёмник команд тут ни при чём, потому что, каждый узел может быть и передатчиком, и приёмником команд. Для каждого конкретного узла заполняется два массива «parameter»r и «device». (эти массивы у каждого будут свои в зависимости от наличия датчиков и исполнительных механизмов). А вот енумы в файле name_addresses.h общие (одинаковые) для всех узлов (там указываются в принципе какие узлы, параметры и девайсы (ну т.е. их адреса) существуют в умном доме). А уж применять или нет их на данном конкретном узле, уже дело десятое. Главное, чтобы у всех участников сети адресация узлов, параметров и девайсов была единая.
riv пишет:
Где настраиваются ответчики на запрос, а где автогенерация периодическая.
Где указывается кому отправлять.
Это настраивается в массиве «parameter». Смотри там в комментах в скетче столбец «таргет адрес 1-го узла», если не нужна автоматическая периодическая отправка данных, ставишь в этом столбце NOT_SENT или (если нужна) ставишь тут какому узлу отправлять. Если нужно нескольким узлам, то добавляешь ещё один столбец (да, при добавлении столбца для одного параметра, для остальных, если им это не надо, будет оверхэд в массиве тогда. ничё страшного).
При этом нужно до массива «parameter» указывать максимальное количество узлов автоматической отправки
riv пишет:
Получаю ответ
"Ошибка выполнения команды. Устройство или параметр, которым пытаемся управлять данной командой, не укомплектованы на узле!"
потому что, не настроил правильно на данном узле массивы "parameter" и/или "device"
вот эти две фразы я не понял в принципе. Маршрутизацией чего? управлением чем? Что значит загнать команды наверх dev_type ? Адреса резервировать не нужно. Сколько ты написал девайсов, столько и будет, но не более 254.
Я уже писал выше мне не хватает msg_type для всех статусов и команд. Поэтому для них буду использовать адреса 128-255 из dev_type. Обработкой разделю
вот тут ты, наверное, немного не понял. 60 это не я выбирал, оно получилось само по себе, т.к. всего записали параметров 59 штук (и ещё нулевой адрес, поэтому получилось 60). Соответственно в енуме последняя идёт строка "SIZE_PARAM_ARRAY". В ней и лежит количество сконфигурированных нами параметров (енум сам и подсчитывает), это используется в скетче, чтобы знать количество в списке адресов параметров. Т.е. если, например, сконфигурируешь в списке только 3 параметра, то SIZE_PARAM_ARRAY будет равно 4 (т.к. плюс нулевой ещё).
Я говорю о принудительном ограничении количества параметров с 0 до 127
MaksVV пишет:
Где там, куда сюда? Не путай, команды это команды, статусы это статусы.
Естественно там и команды и статусы я написал об этом выше.
MaksVV пишет:
На том узле, с которого ты хочешь отправить команду, ничего настраивать не нужно. Нужно просто вызвать функцию:
Send Command (приоритет, тип команды, значение, значение_2, значение_3, значение _4, адрес получателя, тип девайса, № датчика )
Понятно, что эту функцию стоит вызывать, если речь идёт о типах команд «управление GPIO», либо «удалённое изменение значения параметра». Для последующих придуманных типов команд, например «рестарт узла» и т.д. нужно добавлять в мой протокол куски кода.
В приложении мануала ведь четко расписана структура ID и тела кадра команды, читай внимательно . (dev_type содержится в последнем разряде ID, а msg_type это 3 байт тела кадра.
То что ты описал, очевидно. Не очевидно как идет связка msg_type, dev_type, data.
В общем ладно, не разберусь так свой код напишу.
MaksVV пишет:
Передатчик и приёмник команд тут ни при чём, потому что, каждый узел может быть и передатчиком, и приёмником команд. Для каждого конкретного узла заполняется два массива «parameter»r и «device». (эти массивы у каждого будут свои в зависимости от наличия датчиков и исполнительных механизмов). А вот енумы в файле name_addresses.h общие (одинаковые) для всех узлов (там указываются в принципе какие узлы, параметры и девайсы (ну т.е. их адреса) существуют в умном доме). А уж применять или нет их на данном конкретном узле, уже дело десятое. Главное, чтобы у всех участников сети адресация узлов, параметров и девайсов была единая.
Видимо ты не понял вопрос. То что каждый узел и передатчик и приемник как бы ну совсем очевидно. Я спросил последовательность передачи о обработки одной команды с настройкой двух узлов.
MaksVV пишет:
Это настраивается в массиве «parameter». Смотри там в комментах в скетче столбец «таргет адрес 1-го узла», если не нужна автоматическая периодическая отправка данных, ставишь в этом столбце NOT_SENT или (если нужна) ставишь тут какому узлу отправлять. Если нужно нескольким узлам, то добавляешь ещё один столбец (да, при добавлении столбца для одного параметра, для остальных, если им это не надо, будет оверхэд в массиве тогда. ничё страшного).
При этом нужно до массива «parameter» указывать максимальное количество узлов автоматической отправки
Спасибо.
MaksVV пишет:
потому что, не настроил правильно на данном узле массивы "parameter" и/или "device"
Я уже писал выше мне не хватает msg_type для всех статусов и команд. Поэтому для них буду использовать адреса 128-255 из dev_type.
Наконец, я понял про что ты говоришь. В общем ты прав. В ID (заголовке кадра) последний разряд dev_type используется только в типе кадра "параметр" и "команда". Да и то в "команде" он используется только в типах команды "управление GPIO" и удалённое изменение значения параметра". Во всех остальных случаях этот разряд ID не используется, поэтому можешь использовать его на свое усмотрение. Например, в типе кадра "авария", я загнал на место dev_type адрес узла, про который сообщается, что у него авария.
Так что не обязательно начинать со 127. Это ведь совсем другая адресация, никакой это не dev_type, хоть и стоИт на том же месте в ID.
Только вот не могу понять как может не хватить в типе кадра "команда" 254 типа команд? ведь в каждом типе команды у тебя до 4-х байт подтипов можно сделать. Ну правильнее, конечно, сказать до 3-х байт подтипов, т.к. один байт на само значение команды. Это ж ппц какое количество команд.
Что первично устройство и у него параметры а у параметров pin?
"параметры" - это метрики (данные с датчиков, датастрим если хочешь). К устройствам никакого отношения не имеют, т.к. устройства не являются датчиками, а являются исполнительными механизмами. У устройства (девайса) закладывается информация заранее (в массиве device), к какому пину оно подключено.
Я уже писал выше мне не хватает msg_type для всех статусов и команд. Поэтому для них буду использовать адреса 128-255 из dev_type.
Наконец, я понял про что ты говоришь. В общем ты прав. В ID (заголовке кадра) последний разряд dev_type используется только в типе кадра "параметр" и "команда". Да и то в "команде" он используется только в типах команды "управление GPIO" и удалённое изменение значения параметра". Во всех остальных случаях этот разряд ID не используется, поэтому можешь использовать его на свое усмотрение. Например, в типе кадра "авария", я загнал на место dev_type адрес узла, про который сообщается, что у него авария.
Так что не обязательно начинать со 127. Это ведь совсем другая адресация, никакой это не dev_type, хоть и стоИт на том же месте в ID.
Только вот не могу понять как может не хватить в типе кадра "команда" 254 типа команд? ведь в каждом типе команды у тебя до 4-х байт подтипов можно сделать. Ну правильнее, конечно, сказать до 3-х байт подтипов, т.к. один байт на само значение команды. Это ж ппц какое количество команд.
Вот структура ID
//ID structure e.d.cc.bb.aa
// E D CC BB AA
// priority msg type target addres source addres dev type
// 1^2=2 2^4=16 2^8=256 2^8=256 2^8=256
Насколько я понял ты AA используешь не только для dev type но и для аварий (подскажи кстати в каком месте, с ходу не нашел)
Ты делаешь вариативную структуру CAN_ID? В коде этого не нашел.
Судя по структуре см. выше, E D CC BB AA жестко зафиксированы по местоположению, и емкости в части передаваемых сообщений.
Или ты имеешь ввиду что на msg type = command у нас 8 байт данных?
Я это понимаю, просто мне нужны все поля данных, пытаюсь в ID все выбросить.
в heartbeat-e количество ошибок узла, количество ошибок кан контроллера, согласен. Буду это добавлять .
сердцебиение лучше синхронизировать от мастера . Так гарантированно по времени разнесутся heartbeat-ы узлов. Просто сделать эти heatbeats широковещательными тогда. и будут все видеть, только не пойму, честно, нафига всем это видеть.
А если уж мастер перестал свой heartbeat с временем слать, тогда уж в аварийном режиме начинают ноды сами пульс гнать в шину.
Я говорю как сделан heartbeat в протоколе CANOpen. Твой вариант называется там NodeGuard.
Heartbeat. При мониторинге сети по принципу heartbeat узел автоматически передает свое коммуникационное состояние с регулярными интервалами как доказательство своей коммуникационной работоспособности.
Node guarding. При работе по принципу node guarding определенный узел сети (это главный узел сети, так называемый NMT-master) опрашивает остальные узлы сети (подчиненные узлы, соответственно называемые NMT-slave) фреймом CAN remote (что такое remote frame, см. [12]). Опрос узлов идет последовательно, друг за другом, с заранее определенным интервалом времени ("guard time", защитный интервал времени). В ответ подчиненные узлы должны передать телеграмму данных, описывающую их текущее коммуникационное состояние (stopped, operational, pre-operational) вместе с так называемым битом toggle. Если узел по какой-то причине не ответил на запрос NMT-master в течение заданного времени ("node life time", время жизни узла), то это регистрируется как ошибка соответствующего узла, и показывается контроллеру хоста NMT-master как "node-guarding event" (событие защиты узла). Другими словами, подчиненные устройства NMT-slave также мониторят сеть на предмет обнаружения запроса от NMT-master в течение своего "времени жизни". Если такой запрос отсутствовал дольше, чем так называемый интервал "времени жизни" узла, то узел NMT-slave также предполагает, что мастер сети NMT-master поломался, и показывает это своему хост-контроллеру через "Life guarding event" (событие защиты жизни сети).
Его целые конторы разрабатывали, так что я пошел на поводу. )
Рекомендую почитать здесь про протокол. Очень много идей можно дернуть.
http://microsin.net/programming/arm/canopen-overview.html
Кстати MULTIFRAME придется переделывать, там все очень не просто. 3х команд не хватит.
ок, интересно, поизучаю. Я два года назад начинал читать про этот CANopen нифига не понял.
Все просто как табуретка
Есть система мониторинга NMT - Network Management в ней Heartbeat и Node guarding
Есть SDO - это мультифрейм
Есть PDO - это передача в одном фрейме
Все остальное нам думаю не нужно в маленькой сети.
И кстати обрати внимание что даже в CANOpen идет не один широковещательный запрос, а опрос всех по очереди. Я пробовал твой вариант, сеть ложиться ошибки нарастают. Контроллеры при превышении ошибок блокируются.
Помнишь я долго бился об ошибки в сети. Так вот 99% проблема в алгоритмах. И при 125кбит 20 одновременных запросов положит сеть. Так что ребут я на этот случай предусмотрел. Т.к. программно не нашел решения вывести контроллер из состояния блокировки передатчика по переполнению буфера ошибок.
по диагонали пробежался. Так же мыслят люди. Словарь объектов - это наши массивы parameter и device. и т.д. По сложнее всё только там немного.
Node Guarding больше понравился.
по диагонали пробежался. Так же мыслят люди. Словарь объектов - это наши массивы parameter и device. и т.д. По сложнее всё только там немного.
Node Guarding больше понравился.
Не скрою мне тоже, и я его реализовал. См. мой код. Но практика показала что лучше сердцебиение.
Так же я где то вычитал что HB лучше.
Сделай проще реализуй оба варианта. Потом проверишь на живой сети.
какие 20 одновременных запросов? это ты про что именно? запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.
Кстати я помаленьку интегрирую CAN через шлюзы мастер/слейв в Majordomo.
Потом просто возьмешь мой форк https://github.com/graynet-dev/OkBitUDP
И кусок кода https://github.com/graynet-dev/aHomeBus/blob/master/ahb_gw_can_to_okbit.cpp либо здесь https://github.com/graynet-dev/ESP8266WiFiOkBit
какие 20 одновременных запросов? это ты про что именно? запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.
Если так то хорошо. Важно чтобы они все одновременно не начали отвечать.
А ребут нужен если узел заблокировался. Причем откуда лезут ошибки не понимаю. То стоит сеть неделю без сбоев то пару дней все в ошибках.
Кстати если будешь делать web сразу делай AJAX https://github.com/graynet-dev/aHomeBus/blob/master/ahb_WEB.cpp см. только void AHB_WEB::loop_web() (void AHB_WEB::loop_web2() и далее тестовые)
по идее у меня гибрид понятий heartbeat и nodeguard. Грубо говоря взято от обоих лучшее ))
ну не знаю на счёт того что , проблема как ты говоришь в алгоритмах. Ты простейший скетч #965 заливал? там супер простая логика:
ну не знаю на счёт того что , проблема как ты говоришь в алгоритмах. Ты простейший скетч #965 заливал? там супер простая логика:
Я пошел дальше, заливал примеры прямо из библиотеки, и пакеты по по таймеру. И дальше начал увеличивать кол-во узлов. Если их больше 5-6 начинаются проблемы с ошибками.
Причем это не ошибки физики а слишком сильно нагруженная сеть.
Тем более это не вопрос а утверждение. Сейчас проблем нет. Причем сеть работает при периоде HB 1 секунда.
НО! Иногда высыпаются ошибки в нескольких контроллерах. Думаю просто баги в железе либо как выше говорил Demid это проблемы с SPI и нужно уходить в STM либо ESP32.
не понимаю, как может быть нагружена сеть от 6-ти МК, которые по одному сообщению шлют. И уж тем более, когда по времени эти ответы разнесены. Если от этого виснет, нах такая мультимастерная сеть вообще нужна, которая по факту нихера не мультимастерная, а получается уговаривать её надо, сообщения по времени разносить и т.д. Трафик то вообще ниочём и то уже проблемы. В автомобилях вон песец трафик: с периодичностью 10 мс десяток сообщений, 50 мс десяток и ещё куча, которые помедленнее. Хрень какая-то .
Интересно, чё будет когда ты реальным обменом сеть нагрузишь, а не только heartbeat. Возможно проблема вернётся.
вот реальный трафик с моторной шины форд транзит. на ней от 4 до 8 блоков . Time это периодичность, мс
Вот трафик с салонной шины 125кбит/с:
все равно это тебе не раз в секунду запрос и 6 ответов слать. Тут тоже большинство кадров сыплется 30...150мс.
возьми поставь только два узла и нагрузи шину - налепи кучу сообщений. И посмотри будут ли ошибки от как ты говоришь "шина загружена" .Имхо всё будет нормально. А вот если ошибки начинаются при добавлении узлов, то имхуется всё таки аппаратная проблема, а не загруженность шины.
У меня mcp-шки фейлились, когда я наваливал в них все метрики подряд, без паузы. Не то, что они вешались - просто не успевали отправить и библиотека возвращала состояние "фейл", которое так же при обрыве линии возникает. Т.е. "доброкачественная" ошибка выглядела как "злокачественная".
ну с этим да , так низя. Получается таким образом забивается TX буфер mcp шки . Я метрики разнёс через 5 мс. Но у RIV то проблема , даже когда всего одно сообщение от узла исходит. Я думаю тут совсем другое.
Хочу напомнить, что когда я тестировал хаб, гонял температуру каждые 275мс с 50 датчиков, то есть в секунду отправляется и принимается всеми блоками 1000/275*50=181 пакет, что грубо около 11кбит/c реальных данных при выставленной скорости 250кбит/с.
О какой загруженности сети вы говорите ? Потолок у CAN шины чуть больше 19000 пакетов в секунду. Без данных конечно. 181 это ни о чем. Вопрос только в обработке такого потока. Сомневаюсь что в форде стоят 8-битные МК с CAN-контроллером через SPI. А вот передатчики +/- те же самые MCP2551.
Я думаю, что проблемы в следующем:
1.связка 2560 <-> MCP2515 по SPI где могут быть сбои от помех наводимых ESP8266 (я заметил что контроллеры в дальних комнатах с низким RSSI сбоят чаще)
2.помехи на самой линии CAN
3.низкое быстродействие МК за счет чего данные не успевают обработаться. (по RX поставил прерывание) но его можно в MCP ставить только на 1 событие.
Для уменьшения этого сделал:
1. Просмотрел осциллографом всю сеть, поставил где надо терминаторы, объединил землю
2. Снизил скорость до 125
Попробую вынести подальше esp
3.низкое быстродействие МК за счет чего данные не успевают обработаться. (по RX поставил прерывание) но его можно в MCP ставить только на 1 событие.
Вот это может быть. Особенно, если всякие веб-морды тудыть совать. Потому как скорость SPI явно выше 250Kbps.
3.низкое быстродействие МК за счет чего данные не успевают обработаться. (по RX поставил прерывание) но его можно в MCP ставить только на 1 событие.
Вот это может быть. Особенно, если всякие веб-морды тудыть совать. Потому как скорость SPI явно выше 250Kbps.
Хотел маски использовать, но тогда маршрутизацию потеряю
В обработчике прерывания прямо с MCP читается?
Регистрами выставляю тип прерывания в MCP и читаю прерывание GPIO МК.
И кстати esp8266 реально вносит ошибки в сеть. Пока не понял на SPI или на CAN влияет.
На SPI скорее всего какая нибудь гармоника от ESP вылетает.
Реализовал дистанционный Reboot, надпись на кнопке это количество ребутов.
но ведь на малом количестве узлов нет ошибок? значит не есп причина. может формирователи шины перепаять на mcp2551? и производительность ардуины тоже тут не причем - говорю трафик вообще ниочем!!! возьми сделай на малом количестве узлов (когда ошибок нет), столько сообщений , эквивалентное такому, как на бОльшем количестве узлов (при котором возникают ошибки). если будет все хорошо - производительность МК не при чем. Главный симптом - появление ошибок при добавлении в сеть участников. надо тут искать причину
нужно подключить can hacker и затестить, что происходит в момент сбоев на шине. и я так и не помню, RIV ты гонял на столе все свои МК при коротком кабеле? Все было хорошо? Может банально всё дело в твоих отклонениях от требуемой шинной топологии?
У меня сеть бывает стоит неделю без сбоев. А потом внезапно начинает сбоить один контроллер и постепенно убивает сеть, причем у него tx error а у остальных rx. И при добавлении новых узлов возникает затухающий сбой, у всех по 100-150 ошибок приема, затем они спадаю до 0 за пару минут.
нужно подключить can hacker и затестить, что происходит в момент сбоев на шине. и я так и не помню, RIV ты гонял на столе все свои МК при коротком кабеле? Все было хорошо? Может банально всё дело в твоих отклонениях от требуемой шинной топологии?
Canhacker и осциллограф уже рабочим инструментом стали.Но проблема не постоянная. Я и веб морду прикрутил для этого. Чувствую скоро до syslog дойду.не могу выявить из-за чего начинается шторм в сети.
я думаю, что нужно исследовать на примерах с библиотеки , на которых чаще глюк проявляется или на том скетче #965. На них тоже должно всё нормально работать. А если глючит , значит есть косяк. просто на них чаще проявляется. А heartbeat -ом возможно ты не решил проблему, а получился некий костыль, немного маскирующий проблему.
я думаю, что нужно исследовать на примерах с библиотеки , на которых чаще глюк проявляется или на том скетче #965. На них тоже должно всё нормально работать. А если глючит , значит есть косяк. просто на них чаще проявляется. А heartbeat -ом возможно ты не решил проблему, а получился некий костыль, немного маскирующий проблему.
Интегрировал шину с Majordomo
есть ссылка где толково описано про настройку мажордомо? Я чето с ходу не могу понять, как что-нибудь туда на ардуине подключить.
есть ссылка где толково описано про настройку мажордомо? Я чето с ходу не могу понять, как что-нибудь туда на ардуине подключить.
У MD есть Маркет дополнений, оттуда ставишь модули сопряжения,
Из интересных есть Modbus TCP, MQTT и OKBIT UDP.
К сожалению вся информация обрывочная. Есть инфа на yotube и форуме
https://mjdm.ru/forum/viewtopic.php?f=5&t=1675&hilit=ModBusTCP
https://mjdm.ru/forum/viewtopic.php?f=5&t=3350
https://mjdm.ru/forum/viewtopic.php?f=5&t=5851#p91062
https://mjdm.ru/forum/viewtopic.php?f=4&t=595
Сам пока разбираюсь.
Макс приветствую. Начал реализовывать совместимость библиотеки с твоим скетчем по протоколу.
Мне для управления маршрутизацией и управлением сетью не хватает 16 адресов в msg_type поэтому решил его не трогать для совместимости с тобой.
Хочу свои команды управления загнать наверх dev_type. Можешь зарезервировать адреса с 128 по 255?
Судя по enum Parameter_addr_enum на 60, тебе адресов хватает. Не против?
Ну и тебе поначалу сначала фильтрация моих dev_type, а потом возможно мои функции внесешь к себе.
Здоров. у меня реально гораздо меньшее количество адресов. Поэтому не вопрос.
а какие например команды управления?
а какие например команды управления?
При запуске устройства оно отдает onboot
Reboot устройства
Сердцебиение
Nodeguard
Sdo пока не реализовал и пр. Из canopen
Вот здесь описание.
https://github.com/graynet-dev/aHomeBus/blob/master/ahb_proto.h
Дак это вроде не команды а статус, не?
Там в перемешку команды, сервисные сообщения, статусы. Относящиеся к состоянию узлов.
Сюда же лягут команды конфигурации узла.
P.S.
Функции установки времени из твоего протокола брать не буду. У меня в сердцебиении мастер отдает аппаратное время которое устанавливается на узлах, а узлы кидают свой аптайм по которым мастер и слейв в web интерфейсе показывают, + мастер отдает для слейва свой аптайм.
Макс, приветствую.
Совсем запутался в твоих функциях и мануал не помогает. Распиши пожалуйста логику настройки.
Что нужно настроить на узле генераторе команд (какие массивы и какие функции их вызывают)
Что нужно настроить на узле исполнителе команды (какие массивы device, timeoutsArray, parametrs_quontity, parametr)
Структура команды в CAN_ID и DATA (msg_type и dev_type)
Какие массивы нужно заполнить на передатчике какие на приемнике команд.
Где настраиваются ответчики на запрос, а где автогенерация периодическая.
Где указывается кому отправлять.
Получаю ответ
"Ошибка выполнения команды. Устройство или параметр, которым пытаемся управлять данной командой, не укомплектованы на узле!"
Вечером позже видео запишу
Давай всё по порядку и будем максимально точными в своих изречениях, чтобы не запутаться.
Хочу свои команды управления загнать наверх dev_type. Можешь зарезервировать адреса с 128 по 255?
вот эти две фразы я не понял в принципе. Маршрутизацией чего? управлением чем? Что значит загнать команды наверх dev_type ? Адреса резервировать не нужно. Сколько ты написал девайсов, столько и будет, но не более 254.
вот тут ты, наверное, немного не понял. 60 это не я выбирал, оно получилось само по себе, т.к. всего записали параметров 59 штук (и ещё нулевой адрес, поэтому получилось 60). Соответственно в енуме последняя идёт строка "SIZE_PARAM_ARRAY". В ней и лежит количество сконфигурированных нами параметров (енум сам и подсчитывает), это используется в скетче, чтобы знать количество в списке адресов параметров. Т.е. если, например, сконфигурируешь в списке только 3 параметра, то SIZE_PARAM_ARRAY будет равно 4 (т.к. плюс нулевой ещё).
а какие например команды управления?
Где там, куда сюда? Не путай, команды это команды, статусы это статусы.
На том узле, с которого ты хочешь отправить команду, ничего настраивать не нужно. Нужно просто вызвать функцию:
SendCommand (приоритет, тип команды, значение, значение_2, значение_3, значение _4, адрес получателя, тип девайса, № датчика )
Понятно, что эту функцию стоит вызывать, если речь идёт о типах команд «управление GPIO», либо «удалённое изменение значения параметра». Для последующих придуманных типов команд, например «рестарт узла» и т.д. нужно добавлять в мой протокол куски кода.
команды могут быть разные. Если речь идёт о прилетании типа команды "управление GPIO". то для правильной работы команды , предварительно настраиваешь на целевом узле только массив device. Там указываешь какой девайс, к какому пину подключен, и вид управления (шим, диджитал и т.д.). Если устройство импульсное (например, как у тебя свет уже сделан), то указывается ещё пин ардуино, которым отслеживается текущее состояние девайса (например свет в данный момент включен или нет. Если он включен и прилетает команда "ВКЛ", то импульса на девайс НЕ последует).
Если прилетела команда "изменение значение параметра", то нужно, чтобы данный параметр который хотим изменить был сконфигурирован на этом узле (ну то бишь, что он тут присутствует) и номер датчика не забываем правильно указывать.
Остальные типы команд, такие как инициирование рестарта и т.д. ещё в моем протоколе не реализованы.
В приложении мануала ведь четко расписана структура ID и тела кадра команды, читай внимательно . (dev_type содержится в последнем разряде ID, а msg_type это 3 байт тела кадра.
Передатчик и приёмник команд тут ни при чём, потому что, каждый узел может быть и передатчиком, и приёмником команд. Для каждого конкретного узла заполняется два массива «parameter»r и «device». (эти массивы у каждого будут свои в зависимости от наличия датчиков и исполнительных механизмов). А вот енумы в файле name_addresses.h общие (одинаковые) для всех узлов (там указываются в принципе какие узлы, параметры и девайсы (ну т.е. их адреса) существуют в умном доме). А уж применять или нет их на данном конкретном узле, уже дело десятое. Главное, чтобы у всех участников сети адресация узлов, параметров и девайсов была единая.
Где указывается кому отправлять.
Это настраивается в массиве «parameter». Смотри там в комментах в скетче столбец «таргет адрес 1-го узла», если не нужна автоматическая периодическая отправка данных, ставишь в этом столбце NOT_SENT или (если нужна) ставишь тут какому узлу отправлять. Если нужно нескольким узлам, то добавляешь ещё один столбец (да, при добавлении столбца для одного параметра, для остальных, если им это не надо, будет оверхэд в массиве тогда. ничё страшного).
При этом нужно до массива «parameter» указывать максимальное количество узлов автоматической отправки
"Ошибка выполнения команды. Устройство или параметр, которым пытаемся управлять данной командой, не укомплектованы на узле!"
потому что, не настроил правильно на данном узле массивы "parameter" и/или "device"
вот эти две фразы я не понял в принципе. Маршрутизацией чего? управлением чем? Что значит загнать команды наверх dev_type ? Адреса резервировать не нужно. Сколько ты написал девайсов, столько и будет, но не более 254.
Я уже писал выше мне не хватает msg_type для всех статусов и команд. Поэтому для них буду использовать адреса 128-255 из dev_type. Обработкой разделю
1if(temp.dev_type > 127) {2temp.cmd = temp.dev_type;3}вот тут ты, наверное, немного не понял. 60 это не я выбирал, оно получилось само по себе, т.к. всего записали параметров 59 штук (и ещё нулевой адрес, поэтому получилось 60). Соответственно в енуме последняя идёт строка "SIZE_PARAM_ARRAY". В ней и лежит количество сконфигурированных нами параметров (енум сам и подсчитывает), это используется в скетче, чтобы знать количество в списке адресов параметров. Т.е. если, например, сконфигурируешь в списке только 3 параметра, то SIZE_PARAM_ARRAY будет равно 4 (т.к. плюс нулевой ещё).
Я говорю о принудительном ограничении количества параметров с 0 до 127
Где там, куда сюда? Не путай, команды это команды, статусы это статусы.
Естественно там и команды и статусы я написал об этом выше.
На том узле, с которого ты хочешь отправить команду, ничего настраивать не нужно. Нужно просто вызвать функцию:
Send Command (приоритет, тип команды, значение, значение_2, значение_3, значение _4, адрес получателя, тип девайса, № датчика )
Понятно, что эту функцию стоит вызывать, если речь идёт о типах команд «управление GPIO», либо «удалённое изменение значения параметра». Для последующих придуманных типов команд, например «рестарт узла» и т.д. нужно добавлять в мой протокол куски кода.
Ты говоришь о
1voidSendCommand(boolPriority,byteCommand_Type,byteCommand_Value,byteCommand_Value_2,byteCommand_Value_3,byteCommand_Value_4,byteTarget_Address,byteDevice_Type,byteSensor_numb)В приложении мануала ведь четко расписана структура ID и тела кадра команды, читай внимательно . (dev_type содержится в последнем разряде ID, а msg_type это 3 байт тела кадра.
То что ты описал, очевидно. Не очевидно как идет связка msg_type, dev_type, data.
В общем ладно, не разберусь так свой код напишу.
Передатчик и приёмник команд тут ни при чём, потому что, каждый узел может быть и передатчиком, и приёмником команд. Для каждого конкретного узла заполняется два массива «parameter»r и «device». (эти массивы у каждого будут свои в зависимости от наличия датчиков и исполнительных механизмов). А вот енумы в файле name_addresses.h общие (одинаковые) для всех узлов (там указываются в принципе какие узлы, параметры и девайсы (ну т.е. их адреса) существуют в умном доме). А уж применять или нет их на данном конкретном узле, уже дело десятое. Главное, чтобы у всех участников сети адресация узлов, параметров и девайсов была единая.
Видимо ты не понял вопрос. То что каждый узел и передатчик и приемник как бы ну совсем очевидно. Я спросил последовательность передачи о обработки одной команды с настройкой двух узлов.
Это настраивается в массиве «parameter». Смотри там в комментах в скетче столбец «таргет адрес 1-го узла», если не нужна автоматическая периодическая отправка данных, ставишь в этом столбце NOT_SENT или (если нужна) ставишь тут какому узлу отправлять. Если нужно нескольким узлам, то добавляешь ещё один столбец (да, при добавлении столбца для одного параметра, для остальных, если им это не надо, будет оверхэд в массиве тогда. ничё страшного).
При этом нужно до массива «parameter» указывать максимальное количество узлов автоматической отправки
Спасибо.
потому что, не настроил правильно на данном узле массивы "parameter" и/или "device"
В общем я и спрашивал как правильно.
Вообще не очевидна иерархия, вложенность свойств и методов.
Что первично устройство и у него параметры а у параметров pin?
Наконец, я понял про что ты говоришь. В общем ты прав. В ID (заголовке кадра) последний разряд dev_type используется только в типе кадра "параметр" и "команда". Да и то в "команде" он используется только в типах команды "управление GPIO" и удалённое изменение значения параметра". Во всех остальных случаях этот разряд ID не используется, поэтому можешь использовать его на свое усмотрение. Например, в типе кадра "авария", я загнал на место dev_type адрес узла, про который сообщается, что у него авария.
Так что не обязательно начинать со 127. Это ведь совсем другая адресация, никакой это не dev_type, хоть и стоИт на том же месте в ID.
Только вот не могу понять как может не хватить в типе кадра "команда" 254 типа команд? ведь в каждом типе команды у тебя до 4-х байт подтипов можно сделать. Ну правильнее, конечно, сказать до 3-х байт подтипов, т.к. один байт на само значение команды. Это ж ппц какое количество команд.
"параметры" - это метрики (данные с датчиков, датастрим если хочешь). К устройствам никакого отношения не имеют, т.к. устройства не являются датчиками, а являются исполнительными механизмами. У устройства (девайса) закладывается информация заранее (в массиве device), к какому пину оно подключено.
1voidSendCommand(boolPriority,byteCommand_Type,byteCommand_Value,byteCommand_Value_2,byteCommand_Value_3,byteCommand_Value_4,byteTarget_Address,byteDevice_Type,byteSensor_numb)да
Наконец, я понял про что ты говоришь. В общем ты прав. В ID (заголовке кадра) последний разряд dev_type используется только в типе кадра "параметр" и "команда". Да и то в "команде" он используется только в типах команды "управление GPIO" и удалённое изменение значения параметра". Во всех остальных случаях этот разряд ID не используется, поэтому можешь использовать его на свое усмотрение. Например, в типе кадра "авария", я загнал на место dev_type адрес узла, про который сообщается, что у него авария.
Так что не обязательно начинать со 127. Это ведь совсем другая адресация, никакой это не dev_type, хоть и стоИт на том же месте в ID.
Только вот не могу понять как может не хватить в типе кадра "команда" 254 типа команд? ведь в каждом типе команды у тебя до 4-х байт подтипов можно сделать. Ну правильнее, конечно, сказать до 3-х байт подтипов, т.к. один байт на само значение команды. Это ж ппц какое количество команд.
Вот структура ID
//ID structure e.d.cc.bb.aa
// E D CC BB AA
// priority msg type target addres source addres dev type
// 1^2=2 2^4=16 2^8=256 2^8=256 2^8=256
Насколько я понял ты AA используешь не только для dev type но и для аварий (подскажи кстати в каком месте, с ходу не нашел)
Ты делаешь вариативную структуру CAN_ID? В коде этого не нашел.
Судя по структуре см. выше, E D CC BB AA жестко зафиксированы по местоположению, и емкости в части передаваемых сообщений.
Или ты имеешь ввиду что на msg type = command у нас 8 байт данных?
Я это понимаю, просто мне нужны все поля данных, пытаюсь в ID все выбросить.