Выпуск J1939 RTR

У меня есть проблема с кадрами rtr с использованием candump и cansend.

Сброс транслируемых данных не проблема.

Архитектура - Raspberry pi с защитным экраном Pican, считывающим данные из симулятора J1939.

Я запускаю Candump, чтобы получать все сообщения на шине. Затем получите кадр подтверждения от симулятора, когда я выполняю cansend для pgn Fec. Я запрашиваю предварительно запрограммированный VIN, но ничего не получаю. Вот что я вижу от Candump:

can0  18FEF500   [8]  7D FF FF 40 25 4B FF FF   '}..@%K..'
can0  18FEE900   [8]  D1 4B 03 00 D1 4B 03 00   '.K...K..'
can0  18FEF700   [8]  FF FF FF FF E0 01 FF FF   '........'
can0  18FECA00   [8]  03 FF 00 00 00 00 00 00   '........'
can0  00FEEC00   [0]  remote request
can0  18E80000   [8]  01 FF FF FF FF EC FE 00   '........'
can0  0CF00300   [8]  FF 7D 7D FF FF FF FF FF   '.}}.....'
can0  18FE6C00   [8]  FF FF FF FF FF FF 80 7D   '.......}'
can0  0CF00400   [8]  FF FF 7D 80 7D FF FF FF   '..}.}...''

E800 PGN - это стандартное сообщение подтверждения.

И сообщение, которое я отправляю во время работы Candump:

cansend can0 00feec00#r

По сути, я не возвращаю PGN для VIN. Любые идеи?


person Emerson    schedule 23.09.2016    source источник


Ответы (1)


Оказывается, здесь есть пара проблем.

1- #r не поддерживается в J1939

2- вы не запрашиваете pgns, запрашивая этот pgn напрямую. метод заключается в отправке данных на конкретный pgn, который обрабатывает запросы. пример ниже:

EA 00 - это PGN для отправки данных. Внутри сообщения данных живет запрашиваемый pgn (LSB), поэтому PGN FEE5 теперь E5FE. Требуется три байта, поэтому в сообщении ниже указано 00.

Вот рабочий запрос на количество моточасов:

cansend 18EA00FF#E5FE00

и ответ:

21 00 00 00 8F 01 00 00
person Emerson    schedule 26.09.2016