Az üzenetadatok dekódolása ezen a CAN-buszon

Az első üzenet kivételével ez a tipikus SDO forgalom ( CANopen ), kérés / válasz párokkal:

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

Az első pár esetében egy elhalt ajándék a 0x4B a válasz első bájtjában. Ez azt jelzi, hogy a visszaküldött adatok két bájt méretűek (egy és négy bájt esetében 0x4F, illetve 0x43). A kérelem első bájtjában szereplő 0x40 azt jelzi, hogy olvas kérés (a szabvány más kifejezést használ, ” Feltöltés “, ellentétes jelentéssel, mint az interneten (letöltés) – a címzett eszköz szempontjából).

A kérés CAN ID értéke 0x600 + csomópont azonosító. A válasz CAN ID 0x580 + csomópont azonosító. Így:

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

SDO-k esetében a CANopen index és az alindex a második, a harmadik és a negyedik bájtban található (a legkevésbé jelentős bájt először a CANopen indexnél). Tehát az első pár, a 40 78 60 00 esetében a kérelmező azt mondja: ” Készülék a 0x65 (101) csomópont azonosítónál, adja meg a tárolt értékét a 6078sub0 ” .

Ebben az esetben az információ a címzett eszközről folyik annak, aki megadta a kérést (a kérő nem látható a CAN busznaplóból, de általában egy központi vezérlő a rendszerben vagy egy PC-n futó szervizeszköz (általában USB-CAN adapter).

Így a bemutatott forgalomhoz olvasási kérelmeket küldünk ( Az utolsó válasza nem szerepel a közzétett CAN busznaplóban):

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

Furcsa módon a 6041sub0 kérését megismételjük.

Továbbá, annak ellenére, hogy az SDO-k általában csak konfigurációs információkra szolgálnak, a 0x6000 és 0x6FFF közötti CANopen indextartományt általában nem konfigurációs információkhoz használják, például a mért mennyiségekhez vagy az állapothoz.

Az SDO indexek / alindexek a kézikönyvben kereshetők meg (I h ave tartalmazza a tényleges értékeket a minta CAN busznaplóból):

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. 

Az első üzenet

Feltételezve, hogy az első üzenet is CANopen, 4E5 F0 16 00 00: Az összes CANopen CAN üzenet esetében az azonosító egy négybites funkciókód (0-15), amelyet egy hétbites csomópont azonosító követ. Ebben az esetben 0x4E5 = 1001 1100101b. Így a függvénykód 1001b = 9, vagyis ” PDO4, továbbítás “. A PDO-k információáramlásának iránya (ebben az esetben annak ellenére, hogy ” továbbít “) definíció kérdése (az alkalmazástól függ) ). A csomópont azonosítója: 1100101b = 0x65.

A PDO csomópont azonosítója megegyezik az SDO-kkal.

Ebben az OEM-ben található információk, ” PDO 4 továbbítása “, a 0x1A03 SDO tartalmazza, ” PDO átviteli 4. paraméter küldése >

Nem magyarázta el, hogy pontosan mit is mutat az adatlapja, de lehet legyen az üzenet azonosítója, amelyet a zárójelben lévő adatbájtok száma követ, majd a tényleges adatbájtok. Úgy tűnik, hogy semmi sem utal kifejezetten arra, hogy az azonosítók 11 vagy 29 bitesek. Talán csak 3 HEX számjegy használatával A lista 11 bites azonosítókat jelöl. Ha igen, akkor 8 HEX számjegy jelenik meg a 29 bites azonosítóknál.

Az egyes sorok tehát (úgy tűnik) egy CAN üzenetet jelentenek. Nincs több dekódolás értse meg a CAN üzenetet. Ezt kifejezetten megmutatja Önnek.

Például az utolsó sor azt mondja, hogy egy üzenetet 665h azonosítóval láttak (1637 tizedesjegy), hogy ennek az üzenetnek 8 adatbájtja volt, és hogy a az adatbájtok (HEX-ben) 40, 6C, 60, 0, 0, 0, 0 és 0. Az első három 64, 108 és 96 lenne tizedesjegyekkel.

Ami a jelentése annak az üzenetnek, amely bármilyen eszköznek származik, vagy annak szándékozik cselekedni, ez valami meg kell nézni az adott eszközök dokumentációjában. Ez a CAN fölötti réteg.

Az eszközöm csomópont-azonosítója 101

Nincs csomópont CAN-ban lévő azonosítók, csak üzenet-azonosítók. Ha eszközei a csomópont-azonosító fogalmát használják, akkor ez a CAN feletti protokollréteg sajátossága. A CAN-szabvány ebben nem tud segíteni. Olvassa el az adott eszköz dokumentációját, amely utalhat az általa CAN felett használt magasabb szintű protokollra, esetleg külön dokumentumban.

Megjegyzések

• ‘ nem alapszintű CAN, hanem CANopen, amint az a Kézikönyvben is látható.
• A válaszom .

Az eszköz CANopen protokoll . A CANopen egy CAN-alapú kommunikációs rendszer. Magasabb szintű protokollokat és profilspecifikációkat tartalmaz.

Az Automation alkalmazásban használják. Számos protokollanalizátor létezik az egész kommunikáció kiszámításához. A CANopen-t használó automatizálási rendszer master / slave architektúra. Talál a wikipédiában néhány információt a CANopenről, de ez nem annyira triviális, mint maga az üzenetközpontú CAN.

Megjegyzések

• Igen, az igaz. Ez a CANopen.

A kommunikáció dekódolásához ismernie kell a motoros CANopen Object Dictionary szót. Úgy tűnik, hogy a TPDO-k és tartalmuk a kommunikációtól és az objektumok leképezésétől függ.

A protokoll megértése érdekében tanulmányoznia kell a CANopen következő feltételeit. – Objektum szótár – Folyamat adatobjektumok (PDO) – Kommunikációs paraméterek – Paraméterek leképezése