CANopen v programu PP2CAN, díl 5

Díl 1 - Čtení dlouhého SDO, vyžadování jednotlivých segmentů

Díl 2 - Mapování objektů do PDO

Díl 3 - Odesílání TPDO

Díl 4 - Nástroj PDO mapping

Díl 5 - CANopen FD USDO

Díl 6 - CANopen Safety: SRDO

Díl 7 - Nodeguarding a Heartbeat

Díl 8 - Objekt 1010h - save

Díl 9 - Blokové čtení SDO

Předchozí díly ukázaly způsob generování SDO zpráv a mapování PDO. Tento díl udělá malou odbočku a předvedeme v něm změny u nového protokolu CANopen FD. Ten je specifikován v CiA 1301. Norma je ovšem dostupná pouze pro členy a na internetu je konkrétních informací a příkladů jako šafránu. Je ovšem třeba říci že vývoj CANopen není ještě úplně uzavřen. Také dostupnost zařízení, která by podporovala CANopen FD je téměř nulová, lze však předpokládat že se rozšíří po uzavření vývoje velmi rychle.

CANopen FD je založen na CAN FD a tak podporuje přenos až 64 datových bajtů ve zprávě. Reálných dat je samozřejmě možné přenést méně, neboť několik bajt; ukousnou řídící příkazy, i tak je to mnohem více než u single  SDO zprávy. V prvním díle tohoto seriálu jsme si ukázali jak přečíst objekt 1008h s názvem Manufacturer device name, v tomto díle přečteme stejnou položku, nicméně tentokrát se stejným zařízením přepnutým do režimu CANopen FD. K tomu je mimo jiné třeba vlastnit náš převodník USB2CAN Triple, který na portu 3 podporuje CAN FD.

USDO nahrazuje SDO u klasického protokolu CANopen. Oproti SDO komunikaci poskytuje protokol USDO cílové informace. Proto protokol USDO podporuje adresování broadcast, multicast a unicast. To znamená, že všechny uzly CANopen FD mohou komunikovat prostřednictvím USDO mezi sebou. Služby USDO jsou určeny pro konfigurační a diagnostické úlohy. Samozřejmě lze přenášet i procesní data. Tady bych za sebe zdůraznil že je ovšem dát pozor na případný konflikt identifikátorů pokud by jsme se rozhodli komunikovat mezi s jedním uzlem pomocí USDO z více míst.

Na předchozím obrázku vidíme strukturu hlavičky dat USDO. Klasický CANopen používal 3 položky, command specifier, index a subindex. U CANopen FD tu jsou další 4 položky: Destination address, Session ID, Data type a Size. Za povšimnutí stojí prohození pořadí položek subindex a index. Pokud by jste chteli znát odpověď na to, proč k tomu došlo, možnou teorií je lepší přístup pro čtení a zápis 16 bitového indexu u 16 bitových procesorů kdy je vhodné aby položka začínala na sudé adrese.

Session ID

• Identifikuje přesně jeden přenos USDO mezi jedním USDO serverem a USDO klientem, tedy stejný pro všechny zprávy například pri blokovém/segmentovém přenosu.
• Ostatní probíhající přenosy z tohoto mezi steným serverem a stejným klientem musejí mit jiné session ID
• Je tak umožněn paralelní přenos dat mezi stejným serverem a klientem.

               
Nyní když známe význam jednotlivých položek požadavku na přečtení objektu ze slovníku, můžeme se pokusit vytvořit dotaz. Protože SW PP2CAN ještě nemá samostatný nástroj na generování USDO, vytvoříme dotaz zcela ručně. K tomu je třeba v roletce CAN FD otevřít nástroj Basic sender.

Index požadovaných dat je 1008h, tedy bajty mají hodnotu 16 a 8 dekadicky.

Subindex požadovaných dat je 0..

Session ID je 3 a může být jakýkoliv který se aktuálně nepoužívá, v našem případě je to jedno, zvolil jsem hodnotu 3.

Command specifier má hodnotu 11h, tedy 17 dekadicky, jedná se o příkaz Upload request.

Node ID (destination address) má hodnotu 1, náš uzel má adresu 1.

Pro zvětšení klikněte na obrázek.

Jak je vidět z obrázku, uzlu je jedno zda délka dat je 6 bajtů (minimum) nebo 8, případně 64. Vždy odpoví. Pokud jako Node ID (destination address) v prvním datovém bajtu zadáme hodnotu například 3, nikdo nám neodpoví. Pokud však zadáme hodnotu 0 - Broadcast, také obdržíme odpověď. Také je jedno zda pro žádost použijeme CAN FD rámec s přepnutím rychlosti v datové fázi nebo klasický rámec.

V tomto našem ukázkovém případě žádosti o čtení objektu je vidět na obrázcích použití identifikátoru 1537d, tedy 601h v žádosti. U klasického CANopen protokolu a SDO by toto byl pro node s adresou 1 jediný možný. U CANopen FD můžeme klidně použít i jiné identifikátory, například 1538d (602h), 1539d a další vyhrazené pro USDO. Je to tím, že cílové ID uzlu zadáváme v prvním datovém bajtu (Node ID). Aby nedocházelo ke kolizím stejných identifikátorů ale různých datových bajtů  je vhodné se řídit výběrem CAN identifikátoru dle ID nodu který data odesílá.

Data s odpovědí, které dostaneme zpět, mají ve všech případech identifikátor 1409d (581h) bez ohledu na to jaký identifikátor byl použit pro žádost. Identifikátor odpovědi se tak řídí také adresou nodu, který data odesílá.

Odpověď má v sedmém datovém bajtu (DB6 - počítáme bajty od 0) hodnotu 09h. Z tabulky typů dat je zřejmé že se jedná o datový typ VISIBLE_STRING.
Ta tímto bajtem je v osmém datovém bajtu (DB7) hodnota 25h,tedy 37 dekadicky. Tato hodnota indikuje délku dat - délku stringu.

Pokud vypíšeme datové bajty, získáme řetězec:
5043414E2D4D6963726F4D6F642046442044522043414E6F70656E204469676974616C2031

Pro jeho konverzi na text stačí použít nějaký online konvertor hexa dat na ASCII, získáme tak vlastní text, a to:
PCAN-MicroMod FD DR CANopen Digital 1

Jedná se tak o stejný řetězec který jsme získali v prvním díle seriálu pomocí přenosu po segmentech.