Avkoda meddelandedata på denna CAN-buss

Förutom det första meddelandet är detta typiskt SDO trafik ( CANopen ), med begäran / svarspar:

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

För det första paret är en död giveaway 0x4B i den första byten av svaret. Detta indikerar att de returnerade data är av storlek två byte (för en byte och fyra byte är den 0x4F respektive 0x43). 0x40 i den första byten i begäran indikerar att det är en läs begäran (standarden använder en annan term, " Ladda upp ", med motsatt betydelse som på Internet (nedladdning) – det är ur den adresserade enhetens perspektiv).

Förfrågan CAN-ID är 0x600 + nod-ID. Svaret CAN-ID är 0x580 + nod-ID. Således:

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

För SDO: er är CANopen-index och subindex i andra, tredje och fjärde byte (minst signifikant byte först för CANopen-index). Så för det första paret, 40 78 60 00, säger begäraren: " Enhet vid nod-ID 0x65 (101), ge mig ditt lagrade värde på 6078sub0 " .

I det här fallet flödar informationen från den adresserade enheten till den som gjorde begäran (begäran kan inte ses från CAN-bussloggen, men det är vanligtvis en central styrenhet i systemet eller ett serviceverktyg som körs på en dator (vanligtvis en USB-till-CAN-adapter).

För den visade trafiken görs sålunda läsförfrågningar för ( svar för den sista ingår inte i den upplagda CAN-bussloggen):

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

Konstigt nog upprepas begäran om 6041sub0.

Även om SDO: er vanligtvis bara är för konfigurationsinformation, används CANopen-indexområdet 0x6000 till 0x6FFF vanligtvis för icke-konfigurationsinformation, som uppmätta kvantiteter eller status.

Dykning i handboken

SDO-index / underindex kan letas upp i manualen (I h ave inkluderade de faktiska värdena från exempel-CAN-bussloggen):

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. 

Det första meddelandet

Förutsatt att det första meddelandet också är CANopen, 4E5 F0 16 00 00: För alla CANopen CAN-meddelanden är ID: t en fyrbitsfunktionskod (0-15) följt av ett sju-bitars nod-ID. I detta fall 0x4E5 = 1001 1100101b. Således är funktionskoden 1001b = 9, vilket betyder " PDO4, sänder ". Informationsflödets riktning för PDO: er (trots att " sänder ") är en definitionsfråga (beror på applikationen ). Nod-ID är 1100101b = 0x65.

Nod-ID för PDO är detsamma som för SDO.

Informationen i denna PDO, " Överför PDO 4 ", ingår i SDO 0x1A03, " Överför PDO-mappningsparameter 4 ". Om det inte har ändrats från standard är data i PDO samma som SDO 0x60FAsub0, ett signerat 32-bitars heltal:

kontrollen ansträngning som utgång från positionskontrollslingan. I lägesstyrningsfunktionen är noteringen av kontrollansträngningen lägesberoende och specificeras därför inte.

Slutsats

Motoranordningen med nod-ID 0x65 skickar ut styransträngningen (troligtvis med regelbundna tidsintervall) med en PDO .

En styrenhet eller ett realtidsövervakningsfönster i ett serviceverktyg läser och visar andra uppmätta kvantiteter / status från samma motoranordning med SDO .

Kommentarer

• Jag arbetar med denna typ av CAN bussdata dagligen, så det är lätt att känna igen. Den exakta tolkningen / betydelsen beror dock på information om det specifika systemet. Jag tyckte att denna fråga förtjänade ett omfattande svar.

Du har inte förklarat vad exakt din lista visar, men det kanske vara meddelande-ID, följt av antalet databytes inom parentes, följt av faktiska databytes. Ingenting verkar uttryckligen ange om ID: n är 11 eller 29 bitar. Kanske bara genom att använda 3 HEX-siffror för ID detta listan indikerar 11-bitars-ID: n. Om så är fallet skulle det visa 8 HEX-siffror för 29-bitars-ID: er.

Vad varje rad är (det verkar) som visar dig är ett CAN-meddelande. förstå CAN-meddelandet. Det visas uttryckligen för dig.

Till exempel, den sista raden säger att ett meddelande sågs med ID 665h (1637 decimal), att detta meddelande hade 8 databytes och att databytes var (i HEX) 40, 6C, 60, 0, 0, 0, 0 och 0. De första tre skulle vara 64, 108 och 96 i decimal.

Vad gäller mening av det meddelandet är till vilken enhet som helst eller som är avsedd att agera på det, det är något du måste slå upp i dokumentationen för de specifika enheterna. Det ”ett skiktet ovanför CAN.

Min enhet har ett nod-id på 101

Det finns ingen nod ID i CAN, endast meddelande-ID. Om dina enheter använder konceptet med ett nod-ID är detta något särskilt för ett protokolllager ovanför CAN. CAN-standarden kan inte hjälpa dig med det. Du måste läsa den specifika enhetsdokumentationen, som kan hänvisa till det högre nivåprotokollet som används ovan CAN, eventuellt i ett separat dokument.

Kommentarer

• Det ' är inte grundläggande CAN, det är CANopen, som det ses i manualen.
• Jag har utarbetat det i mitt svar .

Enheten använder en CANopen-protokoll . CANopen är ett CAN-baserat kommunikationssystem. Den innehåller protokoll med högre lager och profilspecifikationer.

Den används i Automation. Det finns flera protokollanalysatorer för att räkna ut hela kommunikationen. Automationssystemet som använder CANopen är en master / slavarkitektur. Du hittar lite information på wikipedia om CANopen, men det är inte så trivialt som meddelandets orienterade CAN.

Kommentarer

• Ja, Det är korrekt. Det är CANopen.

För att avkoda kommunikationen måste du känna till motorns CANopen Object Dictionary. Det ser ut som TPDO: er och deras innehåll beror på kommunikations- och mappningsobjekt.

Du bör studera följande termer från CANopen för att förstå protokollet. – Object Dictionary – Process Data Objects (PDO) – Kommunikationsparametrar – Kartläggningsparametrar