CANNY forum — Потеря сообщений при приеме

Re: Потеря сообщений при приеме

2020-10-21T08:39:31Z

В сообщениях с ID=0x18EBFF00 кроме "ЕС1PACK" еще какие-нибудь данные могут быть получены?

Да, кроме EC1 мультипакетами отправляются и диагностические сообщения DM1, у них так же идет BAM, а затем n-ное количество пакетов. Например, если движок шлет и ЕС1, и DM1 и они оба мультипакетные, IDшники у ВАМов и PACKов будут идентичные. Принимающие узлы определяют какая "пачка" пакетов к какому сообщению относится только по PGN, который передается в последних трех байтах BAM-сообщения, следом за которым прошел этот мультипакет.

Re: Потеря сообщений при приеме

2020-10-21T08:28:50Z

Посмотрел лог. Стало понятнее.
В сообщениях с ID=0x18EBFF00 кроме "ЕС1PACK" еще какие-нибудь данные могут быть получены?

Re: Потеря сообщений при приеме

2020-10-21T06:04:39Z

Не вполне понятно как у вас организована обработка "ЕС1PACK"
Пожалуйста, приведите пример хотя бы двух последовательных сообщений мультипакета. На картинке EC1_pack.PNG присутствует идентификатор 0x18FEE300x. Хочется понять, все же с каким ID передаётся мультипакет.

Да, я сразу не сообразил заскринить более наглядно, поэтому кажется, как будто PACK отправляется с IDшником самого ЕС1, но это не так. По J1939 у нас для ВАМ первый байт - приоритет, второй и третий - ID ВАМ-сообщения, который всегда ECFF, последний байт - адресант, в данном случае 00 - блок двигателя. Для PACK аналогично: первый байт - приоритет, второй и третий - ID PACK-сообщения, который всегда EBFF, последний байт - адресант.
В первом пакете 1С20 - это как раз-таки наши обороты хх, которые выставлены на 900. Остальные данные не заполнены за ненадобностью.
На всякий случай еще добавил лог. Если у вас есть возможность читать .blf, то могу отправить в таком формате.
Состав ЕС1 более наглядно виден в CAN Interactive generator, с помощью которого я генерю сообщения в CAN, скрин во вложении.

Re: Потеря сообщений при приеме

2020-10-20T17:07:23Z

Sergey пишет:

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

Именно так, на аппаратном уровне. И более того - гарантировать приём если не каждого, то по крайней мере первого сообщения с заданным в фильтре ID с момента попадания в диаграмму предыдущего сообщения с таким ID.

Sergey пишет:

...как быть, если нужно принимать более 16 сообщений? Ведь "Регистров установки фильтра приёма" всего 16...

Фильтры можно перенастраивать динамически, можно подключить параллельно второй CAN интерфейс у которого тоже 16 фильтров, второй контроллер и т д. Кроме того, дополнительные возможности фильтрации даёт драйвер Шлюза CAN. Но, разумеется, предел возможностей существует.

Не вполне понятно как у вас организована обработка "ЕС1PACK"
Пожалуйста, приведите пример хотя бы двух последовательных сообщений мультипакета. На картинке EC1_pack.PNG присутствует идентификатор 0x18FEE300. Хочется понять, все же с каким ID передаётся мультипакет.

Re: Потеря сообщений при приеме

2020-10-20T07:45:30Z

Благодарю за помощь! Теперь работает, хотя если долго наблюдать за симуляцией процесса, изредка все-таки проскакивает значение с педали, когда нижний предел в ЕС1 выставлен более 600. Но я так думаю, нужно поиграться с задержками, чтобы свести к нулю вероятность возникновения таких моментов.
По поводу ЕС1, скрины во вложении. TPCM - это ЕС1BAM - в данном случае из всего, что в нем передается, нас интересует PGNunber, потому что кроме ЕС1 есть еще другие мультипакетные сообщения и нам нужно знать какое из них будет передаваться в данный момент. ЕС1 - это ЕС1PACK, для удобства отображения "Vector" склеивает 6 восьмибайтных сообщений в одно и отображает как одно 40-байтное сообщение. Фактически после ЕС1BAM передается подряд 6 сообщений по 8 байт, в которых первый байт - номер пакета, а остальные семь содержат данные. В конкретном примере нас интересует только EngineSpeedAtIdlePoint1. Описание параметра пo J1939 во вложении (SPN_188.PNG). Остальные параметры нас не интересуют, поэтому я не задавал для них каких-либо значений и они стоят по нулям и остальные 5 пакетов принимать в CANNY нет необходимости.

По поводу фильтров. Я так понимаю, что фильтры, которые Вы добавили в начале диаграммы, необходимы для того, чтобы принимать узлом только те сообщения, которые нам нужны, а не все, что есть в шине. А затем уже мы сравниваем значение регистров "Рег.чтен.СAN0 IDL", "Рег.чтен.СAN0 IDH", "Рег.чтен.СAN0 ERL" c идентификаторами конкретных сообщений и, если совпадает, то извлекаем из поля данных конкретного сообщения необходимую нам информацию. То есть получается как бы "двухуровневая фильтрация" идентификаторов: вначале на прием из CAN, а затем, на поиск среди принятых того ID, который нужен для конкретной цепочки?
И еще: как быть, если нужно принимать более 16 сообщений? Ведь "Регистров установки фильтра приема" всего 16. Значит, остальные сообщения будут приниматься без фильтров, просто по совпадению идентификаторов с заданными константами?

Re: Потеря сообщений при приеме

2020-10-19T15:39:53Z

Для уверенного приема идентификаторов рекомендуется использовать фильтры CAN: https://wiki.canny.ru/index.php/CANNY_7 … %D1%80_CAN
Для лучшего понимания алгоритма, приведите, пожалуйста, пример мультипакета конфигурации двигателя ЕС1 (с расшифровкой что где в нем расположено).
В исходную диаграмму добавлены фильтры, а также несколько примеров оптимизации.

Потеря сообщений при приеме

2020-10-19T07:31:17Z

Добрый день всем! На днях столкнулся с очередной проблемой. Суть такова: требуется отправлять в CAN значение запроса оборотов двигателя, принятое с резистивной педали акселератора, при условии, что оно превышает предустановленное значение оборотов холостого хода, которое можно извлечь из сообщения конфигурации двигателя. (Минимальное значение оборотов хх – 600 об/мин). Схема преобразования значения АЦП и схема приема конфигурации двигателя работают корректно и описанный алгоритм работает, но по какой-то причине конфигурация двигателя (EC1), отправляемая раз в 5 секунд, принимается CANNY раз в десять реже, если не более. Т.е., если, допустим в ЕС1 обороты хх выставлены не 600 об/мин, а 900 об/мин, а с педали выдается, например, 800 об/мин, то в CAN все равно отправляется значение с педали. Отправляемое значение обнуляется лишь изредка, после того, как CANNY все-таки «выловил» EC1 (обнаружение CANNY EC1 детектировал визуально с помощью зеленого светодиода, присоединенного к старшей части идентификатора сообщения).
Как показали наблюдения, с уменьшением периода отправки EC1, частота его приема в CANNY все-таки увеличивается. Но так же рандомно. Перебор значений задержек в схеме не привел к успеху, потому что EC1 может прийти как раз в секунду, так и раз в минуту.
Загрузка шины только сообщениями, которые видны в диаграмме на прием и на отправку.
Ни приоритет, ни периодичность ЕС1 поменять мы не можем.
Я так предполагаю, проблема в том, что буфер CANNY заполняется сообщениями, отправляемыми с большей частотой, а EC1 CANNY просто не успевает обработать. Но почему тогда при установке задержек для удержания принятого значения оборотов вплоть до минуты, отправляемое значение все равно сбрасывается через несколько секунд?
Надеюсь, проблему описал понятно. Диаграмма во вложении. Сабж в самом низу диаграммы и выделен красными рамочками.