Dekódování dat zprávy na této sběrnici CAN

Až na první zprávu je to typické provoz SDO ( CANopen ) s páry požadavek / odpověď:

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

U prvního páru je mrtvý prozradí 0x4B v prvním bajtu odpovědi. To znamená, že vrácená data mají velikost dva bajty (pro jeden bajt a čtyři bajty je to 0x4F a 0x43). Hodnota 0x40 v prvním bajtu požadavku označuje, že se jedná o čtení požadavek (standard používá jiný výraz, " Nahrát ", s opačným významem jako na internetu (ke stažení) – je to z pohledu adresovaného zařízení).

ID CAN požadavku je 0x600 + ID uzlu. ID CAN odezvy je 0x580 + ID uzlu. Tedy:

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

U SDO je index CANopen a subindex ve druhém, třetím a čtvrtém bajtu (nejméně významný bajt první pro index CANopen). Takže u prvního páru, 40 78 60 00, žadatel říká: " Zařízení v uzlu ID 0x65 (101), dejte mi uloženou hodnotu na 6078sub0 " .

V tomto případě informace proudí z adresovaného zařízení každému, kdo zadal požadavek (žadatele nelze vidět z protokolu sběrnice CAN, ale obvykle se jedná o centrální ovladač v systému nebo servisní nástroj běžící na PC (obvykle adaptér USB-CAN).

Proto se pro zobrazený provoz vytvářejí požadavky na čtení ( odpověď na poslední není zahrnuta v zaslaném protokolu sběrnice CAN):

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

Kupodivu se požadavek na 6041sub0 opakuje.

Navíc, i když SDO obvykle slouží pouze pro konfigurační informace, rozsah indexu CANopen 0x6000 až 0x6FFF se obvykle používá pro nekonfigurační informace, jako jsou naměřené veličiny nebo stav.

Ponoření do manuálu

Indexy / subindexy SDO lze vyhledat v příručce (viz ave zahrnuty skutečné hodnoty z ukázkového protokolu sběrnice CAN):

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. 

První zpráva

Za předpokladu, že první zpráva je také CANopen, 4E5 F0 16 00 00: Pro všechny zprávy CANopen CAN je ID čtyřbitový funkční kód (0-15) následovaný ID sedmibitového uzlu. V tomto případě 0x4E5 = 1001 1100101b. Kód funkce je tedy 1001b = 9, což znamená " PDO4, vysílat ". Směr toku informací pro CHOP (navzdory v tomto případě " vysílat ") je věcí definice (závisí na aplikaci ). ID uzlu je 1100101b = 0x65.

ID uzlu pro PDO je stejné jako pro SDO.

Informace v tomto PDO, " Vysílejte PDO 4 ", je obsažen v SDO 0x1A03, " Vysílejte parametr mapování PDO 4 ". Pokud nebyl změněn z výchozího nastavení, jsou data v PDO stejná jako SDO 0x60FAsub0, podepsané 32bitové celé číslo:

ovládací prvek úsilí jako výstup smyčky řízení polohy. Ve funkci řízení polohy je notace síly řízení závislá na režimu, a proto není specifikována.

Závěr

Motorové zařízení s ID uzlu 0x65 odesílá kontrolní úsilí (pravděpodobně v pravidelných časových intervalech) pomocí PDO .

Řídicí jednotka nebo okno monitoru v reálném čase v servisním nástroji čte a zobrazuje další měřené veličiny / stav ze stejného motorového zařízení pomocí SDO .

Komentáře

• Pracuji s tímto druhem CAN data sběrnice na denní bázi, takže je to snadno rozpoznatelné. Přesná interpretace / význam však závisí na informacích o konkrétním systému. Myslel jsem, že tato otázka si zaslouží komplexní odpověď.

Nevysvětlili jste, co přesně váš zápis ukazuje, ale možná být ID zprávy, následovaný počtem datových bajtů v závorkách, následovaných skutečnými datovými bajty. Zdá se, že nic výslovně neuvádí, zda jsou ID 11 nebo 29 bitů. Snad jen pomocí 3 HEX číslic pro ID toto výpis označuje 11 bitová ID. Pokud ano, zobrazil by 8 HEX číslic pro 29 bitová ID.

Co vám tedy každý řádek (jak se zdá) ukazuje, je jedna zpráva CAN. K dekódování už není nic víc rozumíte zprávě CAN. Zobrazí se vám to výslovně.

Například poslední řádek říká, že byla viděna zpráva s ID 665h (1637 desetinně), že tato zpráva měla 8 datových bytů a že datové bajty byly (v HEXU) 40, 6C, 60, 0, 0, 0, 0 a 0. První tři by byly 64, 108 a 96 v desítkové soustavě.

Co se týče toho, co význam této zprávy je pro jakékoli zařízení, z něhož pochází, nebo má na něm působit, to je něco musíte vyhledat v dokumentaci konkrétních zařízení. Ta vrstva je nad CAN.

Moje zařízení má ID uzlu 101

Neexistuje žádný uzel ID v CAN, pouze ID zpráv. Pokud vaše zařízení používají koncept ID uzlu, pak je to něco zvláštního pro vrstvu protokolu nad CAN. Standard CAN vám s tím nemůže pomoci. Musíte nahlédnout do dokumentace konkrétního zařízení, která může odkazovat na protokol vyšší úrovně, který používá nad CAN, případně v samostatném dokumentu.

Komentáře

• ' není to základní CAN, je to CANopen, jak je vidět v manuálu.
• Podrobně jsem to rozpracoval v moje odpověď .

Zařízení používá protokol CANopen . CANopen je komunikační systém založený na CAN. Zahrnuje protokoly vyšší vrstvy a specifikace profilů.

Používá se v automatizaci. Existuje několik analyzátorů protokolů, které mají zjistit celou komunikaci. Automatizační systém využívající CANopen je architektura typu master / slave. Na wikipedii najdete nějaké informace o CANopen, ale není to tak triviální jako samotné CAN orientované na zprávy.

Komentáře

• Ano, to je správně. Je to CANopen.

Chcete-li dekódovat komunikaci, musíte znát motorový CANopen Object Dictionary. Vypadá to, že TPDO a jejich obsah závisí na komunikaci a mapování objektů.

Abyste porozuměli protokolu, měli byste si prostudovat následující termíny z CANopen. – Object Dictionary – Process Data Objects (PDO) – komunikační parametry – mapovací parametry