Het decoderen van berichtgegevens op deze CAN-bus

Behalve het eerste bericht is dit typisch SDO -verkeer ( CANopen ), met aanvraag / antwoord-paren:

0x665 SDO request (range 0x600 - 0x67F, depending on the node ID) 0x5E5 SDO response (range 0x580 - 0x5FF, depending on the node ID) 

Voor het eerste paar is een dode weggeefactie de 0x4B in de eerste byte van het antwoord. Dit geeft aan dat de geretourneerde gegevens een grootte hebben van twee bytes (voor één byte en vier bytes is dit respectievelijk 0x4F en 0x43). De 0x40 in de eerste byte van het verzoek geeft aan dat het een lees -verzoek is (de standaard gebruikt een andere term, ” Upload “, met de tegenovergestelde betekenis als op internet (download) – het is vanuit het perspectief van het geadresseerde apparaat).

De CAN-ID van het verzoek is 0x600 + node-ID. Het antwoord CAN-ID is 0x580 + knooppunt-ID. Dus:

665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65 

Voor SDOs bevinden de CANopen-index en subindex zich in de tweede, derde en vierde byte (de minst significante byte eerst voor de CANopen-index). Dus voor het eerste paar, 40 78 60 00, zegt de aanvrager: ” Device at node ID 0x65 (101), geef me je opgeslagen waarde op 6078sub0 ” .

In dit geval stroomt de informatie van het geadresseerde apparaat naar degene die het verzoek heeft gedaan (de aanvrager kan niet worden gezien in het CAN-buslogboek, maar het is meestal een centrale controller in het systeem of een servicetool die op een pc draait (meestal een USB-naar-CAN-adapter)).

Voor het getoonde verkeer worden dus leesverzoeken gedaan voor (de antwoord voor de laatste is niet opgenomen in het geplaatste CAN-buslogboek):

6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes) 

Vreemd genoeg wordt het verzoek om 6041sub0 herhaald.

Bovendien, hoewel SDOs meestal alleen voor configuratie-informatie zijn, wordt het CANopen-indexbereik 0x6000 tot 0x6FFF meestal gebruikt voor niet-configuratie-informatie, zoals gemeten hoeveelheden of status.

Duik in de handleiding

De SDO-indexen / subindexen kunnen worden opgezocht in de handleiding (I h hebben de werkelijke waarden uit het voorbeeld van het CAN-buslogboek opgenomen):

6078sub0 Motor current, 219 mA 6064sub0 "Position Actual Internal Value" is 6,192,612 6041sub0 Statusword, 0x0227 = 0000 0010 0010 0111, meaning: "ready to switch on", "switched on", "operation enabled", "quick stop" "remote" 606Csub0 "Velocity Actual Value". The value is not included, but it is a 32-bit signed integer. 

Het eerste bericht

Ervan uitgaande dat het eerste bericht ook CANopen is, 4E5 F0 16 00 00: Voor alle CANopen CAN-berichten is de ID een vier-bits functiecode (0-15) gevolgd door een zeven-bits node-ID. In dit geval 0x4E5 = 1001 1100101b. De functiecode is dus 1001b = 9, wat betekent ” PDO4, verzend “. De richting van de informatiestroom voor PDOs (ondanks in dit geval ” verzenden “) is een kwestie van definitie (afhankelijk van de toepassing ). Het knooppunt-ID is 1100101b = 0x65.

Het knooppunt-ID voor de PDO is hetzelfde als voor de SDOs.

De informatie in deze PDO, ” Verzend PDO 4 “, is opgenomen in SDO 0x1A03, ” Verzend PDO-mappingparameter 4 “. Als de standaardwaarde niet is gewijzigd, zijn de gegevens in de PDO hetzelfde als SDO 0x60FAsub0, een 32-bits geheel getal met teken:

de controle inspanning als de output van de positieregellus. In de positiecontrolefunctie is de notatie van de controle-inspanning modusafhankelijk en daarom niet gespecificeerd.

Conclusie

Het motorapparaat met knooppunt-ID 0x65 verzendt de controle-inspanning (waarschijnlijk met regelmatige tussenpozen) met behulp van een PDO .

Een controller of een real-time monitorvenster in een servicetool leest en toont andere gemeten hoeveelheden / status van hetzelfde motorapparaat met behulp van SDOs .

Opmerkingen

• Ik werk met dit soort CAN busgegevens op dagelijkse basis, dus dit is gemakkelijk herkenbaar. De precieze interpretatie / betekenis hangt echter af van informatie over het specifieke systeem. Ik dacht dat deze vraag een uitgebreid antwoord verdiende.

Je hebt niet uitgelegd wat precies je vermelding laat zien, maar het zou de bericht-ID zijn, gevolgd door het aantal databytes tussen haakjes, gevolgd door de feitelijke databytes. Niets lijkt expliciet te vermelden of de IDs 11 of 29 bit zijn. Misschien gewoon door 3 HEX-cijfers te gebruiken voor de ID. lijst geeft 11-bits IDs aan. Als dat zo is, worden 8 HEX-cijfers weergegeven voor 29-bits-IDs.

Wat elke regel (zo lijkt het) u laat zien, is één CAN-bericht. Er is niets meer om naar te decoderen het CAN-bericht begrijpen. Het wordt u expliciet getoond.

De laatste regel zegt bijvoorbeeld dat een bericht is gezien met ID 665h (1637 decimaal), dat dit bericht 8 databytes had en dat de databytes waren (in HEX) 40, 6C, 60, 0, 0, 0, 0 en 0. De eerste drie zouden 64, 108 en 96 in decimalen zijn.

Wat betreft wat de betekenis van dat bericht is naar welk apparaat dan ook waarvan het afkomstig is of bedoeld is om ernaar te handelen, dat is iets je moet opzoeken in de documentatie van de specifieke apparaten. Dat “een laag boven CAN.

Mijn apparaat heeft een node-ID van 101

Er zijn geen node IDs in CAN, alleen bericht-IDs. Als je apparaten het concept van een knooppunt-ID gebruiken, dan is dit iets specifieks voor een protocollaag boven CAN. De CAN-standaard kan je daar niet bij helpen. U moet de specifieke apparaatdocumentatie raadplegen, die mogelijk verwijst naar het protocol van een hoger niveau dat het boven CAN gebruikt, mogelijk in een afzonderlijk document.

Opmerkingen

• Het ‘ is geen basis-CAN, het is CANopen, zoals te zien is in de handleiding.
• Ik heb het uitgewerkt in mijn antwoord .

Het apparaat gebruikt een CANopen-protocol . CANopen is een op CAN gebaseerd communicatiesysteem. Het bevat protocollen van hogere lagen en profielspecificaties.

Het wordt gebruikt in automatisering. Er zijn verschillende protocolanalysatoren om de hele communicatie te achterhalen. Het automatiseringssysteem met CANopen is een master / slave-architectuur. Op wikipedia vindt u wat informatie over CANopen, maar het is niet zo triviaal als de berichtgerichte CAN zelf.

Opmerkingen

• Ja, dat is juist. Het is CANopen.

Om de communicatie te decoderen, moet u de motor CANopen Object Dictionary kennen. Het lijkt op TPDOs en hun inhoud is afhankelijk van communicatie- en mappingobjecten.

U moet de volgende termen uit CANopen bestuderen om het protocol te begrijpen. – Object Dictionary – Process Data Objects (PDO) – Communicatieparameters – Toewijzingsparameters