J1939 RTR Édition

Question

J'ai et le problème avec les trames rtr en utilisant candump et cansend.

Le vidage des données diffusées n'est pas un problème.

Architecture - Raspberry pi avec un bouclier pican lisant les données d'un simulateur J1939. Je cours candump pour recevoir tous les messages sur le bus. Ensuite, récupérez un cadre d'accusé de réception du simulateur lorsque j'exécute un cansend pour pgn feec. Im demandant un VIN préprogrammé mais je ne reçois rien en retour. Voici ce que Im voir de 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 '..}.}...'' 

Le E800 est PGN un message standard ack.

Et message que je vous envoie en candump est en cours d'exécution:

cansend can0 00feec00#r 

Fondamentalement, je ne reçois pas le PGN pour VIN retour. Des idées?

Answer 1

Il s'avère qu'il y a quelques problèmes ici.

1- #R n'est pas pris en charge avec J1939

2- vous ne demandez pas PGNS en demandant que PGN directement. la méthode consiste à envoyer des données à un pgn spécifique qui gère les requêtes. exemple ci-dessous:

EA 00 est le PGN auquel envoyer des données. À l'intérieur du message de données vit le pgn que nous voulons demander (LSB) si PGN FEE5 est maintenant E5FE. Trois octets sont requis, ce qui explique pourquoi 00 est dans le message ci-dessous.

est ici la demande de travail pour Heures de moteur:

cansend 18EA00FF#E5FE00 

et Reponse:

21 00 00 00 8F 01 00 00