O abordare detaliată a protocolului CANopen pentru controlul motoarelor industriale cu consum redus de putere

Un protocol de comunicație și o interfață de calitate joacă un rol important în aplicațiile industriale pentru controlul motoarelor. Atunci când este nevoie ca o serie de elemente de procesare să comunice continuu pentru a îndeplini sarcini complexe, CANopen^® a devenit o tehnică populară printre inginerii din aplicațiile de acționare industrială datorită unor caracteristici precum simplitatea integrării. CANopen este o soluție extrem de configurabilă, care permite schimbul eficient și fiabil de date în timp real. Acest articol oferă o înțelegere aprofundată a rețelei CANopen din perspectiva aplicațiilor de control al motoarelor cu consum redus de putere.

CAN – Informații generale

Dezvoltat în 1983 de Robert Bosch Gmbh, Controller Area Network (CAN) este un protocol și o interfață de comunicații extrem de robustă. Acesta a fost creat pentru a rezolva limitările rețelelor de comunicații seriale convenționale, precum RS232, care nu puteau facilita comunicația în timp real între mai multe controlere. Industria auto a fost prima care a adoptat CAN, deoarece necesita transmiterea continuă și simultană de date pentru mai mulți senzori. CAN permite mai multor noduri să comunice între ele folosind mesaje mici, ceea ce reprezintă o soluție ideală pentru aplicațiile auto.

De-a lungul timpului, CAN a câștigat popularitate în diverse industrii datorită robusteții și beneficiilor sale dovedite. Cu toate acestea, integrarea mai multor dispozitive de la furnizori diferiți într-un singur sistem utilizând protocolul CAN s-a dovedit dificilă și uneori imposibilă din cauza unor reguli de codificare proprietare. Pentru a depăși această limitare, utilizatorii CAN in Automation (CiA) și asociațiile internaționale de producători au dezvoltat un protocol de nivel înalt denumit CANopen.

În secțiunea următoare, vom explora arhitectura protocolului CANopen și felul în care aceasta este pusă în practică pentru a controla un driver de motor cu mai multe axe. Articolul va pătrunde în complexitatea acestui protocol de comunicație de nivel înalt și va examina impactul său asupra domeniului de control al motoarelor și al mișcării. Analizând un jurnal de comunicație în timp real al modulului controler/driver de motor multiaxă ADI Trinamic™ TMCM-6212 cu motorul pas cu pas QSH4218-35-10-027, ne propunem să oferim cititorilor o înțelegere a protocolului CANopen. În special, ne vom axa pe mașina de stare NMT (network management) și pe protocolul CANopen de tip client-server. În plus, vor fi prezentate studii de caz pentru a demonstra cum să descifrați jurnalul de comunicații și să determinați starea driverului

Figura 1: Mașina de stare NMT. (Sursa imaginii: ADI)

Arhitectura CANopen

Această secțiune a articolului explică diverse principii de utilizare a protocolului CANopen, inclusiv NMT și SDO (service data object).

Managementul rețelei: NMT este un principiu de comunicație esențial în CANopen la care trebuie să adere fiecare dispozitiv compatibil CANopen. Acesta funcționează ca o mașină de stare și joacă un rol vital în coordonarea aplicațiilor în cadrul CANopen.

Arhitectura mașinii de stare pentru managementul rețelei: Mașina de stare NMT este ilustrată în figura 1 și este compusă din trei stări distincte, detaliate în cele ce urmează:

Starea de inițializare
Starea preoperațională
Starea operațională

Nodul client își asumă rolul esențial de a supraveghea starea de comunicație a nodurilor server asociate de-a lungul diferitelor stări operaționale. Acest lucru se realizează prin punerea în aplicare a mecanismului NMT. Două metodologii distincte, și anume “heartbeat” și “node guarding”, permit nodului client să evalueze integritatea comunicațiilor nodurilor server. În cazul TMCM-6212, tehnica heartbeat este utilizată pentru a valida o comunicație corectă. Fiecare nod emite un semnal heartbeat la un interval de timp ciclic configurabil de utilizator, măsurat în milisecunde, utilizând obiectul 1017_h. Acest lucru asigură că toate nodurile sunt active și pregătite pentru a comunica.

	Inițializare	Pre-operațională	Operațională	Oprită
Boot-Up	•
SDO		•	•
Emergency		•	•
Sync/Time		•	•
Heartbeat/Node-Guard		•	•	•
PDO (Process Data Object)			•

Tabelul 1: Configurarea stării în comunicația NMT

Tabelul 1 prezintă combinația tuturor obiectelor de comunicație utilizate în diferite stări de comunicație. Atunci când dispozitivul intră într-o stare de inițializare după pornire sau resetare, acesta generează un mesaj de boot-up. Dispozitivul trece apoi la o stare preoperațională, în care este pregătit pentru operațiunea dorită. În starea preoperațională, toate nodurile din rețea pot transfera toate obiectele legate de SDO, heartbeat/node guarding, urgență și timp/sincronizare. În starea operațională, obiectele PDO pot fi mapate suplimentar față de toate obiectele disponibile în starea preoperațională. În sfârșit, în starea oprită, dispozitivul dezactivează comunicația tuturor obiectelor SDO și PDO, permițând doar comenzile NMT.

Figura 2: Configurație SDO cu mai multe noduri. (Sursa imaginii: ADI)

Protocolul SDO: Protocolul de comunicație SDO este utilizat în principal în starea preoperațională a mașinii de stare NMT. Acesta operează într-o configurație client-server, în care clientul poate accesa toate obiectele disponibile în dicționarul de obiecte al tuturor serverelor (nodurilor) conectate. În acest protocol, clientul inițiază întotdeauna o tranzacție de citire/scriere cu serverul, iar serverul confirmă finalizarea sarcinii.

Figura 2 prezintă o configurație client-server pentru protocolul SDO într-o rețea cu mai multe noduri. Fiecărui nod îi este atribuit un canal prin care poate comunica cu clientul. În acest caz, driverul/controlerul motorului pas cu pas sextuplu Trinamic TMCM-6212 acționează ca un server, iar PC-ul conectat acționează ca un client, inițiind tranzacția de citire/scriere cu un anumit nod, adică NODUL-1 în acest caz. Deși toate nodurile primesc mesajul clientului SDO, numai nodul vizat va răspunde, în timp ce restul serverelor ignoră solicitarea clientului.

Datagrama SDO (Service Data Object)

Figura 2 ilustrează structura completă a datagramei SDO. Antetul SDO constă în COB-ID (connection object ID), care este un număr unic atribuit pentru sarcini specifice, cum ar fi funcționalitățile de citire și scriere. Prin urmare, sunt necesare două COB-ID-uri în comunicația SDO. Primul COB-ID reprezintă NODE-ID + codul funcției pentru cererea de încărcare/descărcare a clientului, care este 600_h + NODE-ID. Al doilea COB-ID, 580_h + NODE-ID, este utilizat pentru răspunsul serverului.

Primul octet dintr-un mesaj SDO, cunoscut sub numele de specificator, joacă un rol vital în determinarea naturii mesajului. Acesta precizează dacă clientul intenționează să scrie (să descarce) sau să citească (să încarce) datele și, de asemenea, semnalează orice eroare în tranzacție prin mesaje de anulare. Octetul specificator este împărțit în opt biți, ilustrați în figura 3. Cei trei biți (7-5) cunoscuți sub denumirea de CCS (client command specifier) oferă informații esențiale despre natura mesajului. Specificatorul comenzii clientului are configurații diferite în funcție de operațiunea clientului, cum ar fi citire, scriere, transferuri segmentate/expediate sau erori în tranzacții. În răspunsul serverului, cei trei biți ai specificatorului (SCS, sever command specifier) determină succesul tranzacției. Tabelul 2 prezintă diferitele combinații de biți CCS și SCS pentru diferite operațiuni. Bitul 4 din datagrama specificatorului este un bit de comutare utilizat în transferurile de date care depășesc patru octeți. Biții 3-2 nu conțin date și sunt valabili numai dacă biții 0-1 sunt setați. Bitul 1 determină tipul de mesaj transferat prin canalul SDO, indicând dacă este un transfer segmentat sau expediat. În datagrama SDO, așa cum se observă în figura 3, ultimii patru octeți sunt dedicați datelor care trebuie să fie transferate. Dacă datele depășesc patru octeți, acestea vor fi trimise în mod segmentat. Alternativ, dacă datagrama SDO conține datele complete, se consideră că este vorba despre un transfer expediat. Prin urmare, dacă bitul 1 este ridicat, înseamnă un transfer expediat, în timp ce un bit scăzut indică un transfer segmentat. În cazul transferului segmentat, datele sunt transferate în pachete. Serverul răspunde la solicitarea inițială de citire/scriere din partea clientului furnizând dimensiunea datelor în câmpul de date, iar apoi al patrulea bit (bitul de comutare) va începe să comute odată cu transferul fiecărui pachet de date către client. În cele din urmă, dacă bitul 0 din datagrama specificatorului este setat, acesta precizează dimensiunea datelor în biții 3-2, după cum s-a menționat anterior.

Operațiune	Cerere client (CCS)	Răspuns server (SCS)
SDO Download	1	3
SDO Upload	2	2
SDO Download Segmentat	0	1
SDO Upload Segmentat	3	0

Tabelul 2: Configurarea CCS și SCS

Octeții 2-3 și 4 din datagrama SDO corespund octeților index și, respectiv, subindex, după cum se observă în figura 3. Acești octeți sunt utilizați pentru a accesa toate obiectele disponibile în dicționarul de obiecte al dispozitivului. Dicționarul de obiecte conține toți parametrii dispozitivului, permițând utilizatorilor să configureze funcționalitatea dispozitivului pe baza cerințelor aplicațiilor în timp real. Acest concept de profilare a dispozitivului aduce un comportament standardizat dispozitivelor, indiferent dacă acestea sunt dispozitive de control, cum ar fi driverele, sau simple componente I/O. Ultimii patru octeți din datagrama SDO sunt dedicați datelor care trebuie transferate prin stratul SDO, așa cum s-a explicat mai devreme.

Figura 3: Structura unei datagrame SDO. (Sursa imaginii: ADI)

În cazul unei erori, transmisia SDO va fi întreruptă, iar motivul opririi transmisiei poate fi identificat făcând trimitere la explicația codului de eroare furnizată în manualul dispozitivului țintă. În acest caz, valoarea biților CCS este 4, indicele și subindicele specifică parametrii afectați în dispozitiv în timpul transmisiei, iar ultimii patru octeți indică codul de eroare.

Analiza comunicației în timp real

Figura 4: IDE CANopen. (Sursa imaginii: ADI)

Această secțiune explică datagrama SDO utilizând o fereastră de jurnal de comunicare în timp real, în vreme ce mașina este într-o stare preoperațională. Driverul/controlerul de motor pas cu pas sextuplu TMCM-6212 ADI Trinamic este utilizat împreună cu motorul pas cu pas QSH4218-35-10-027. Pentru această configurație, curentul maxim al motorului (Object 2003_h) este setat la 200. Tranzacțiile de încărcare și descărcare între client și server sunt explicate în continuare prin intermediul mesajelor evidențiate în fereastra de jurnal a interfeței software a configurației vizate, după cum se prezintă în figura 4.

Cazul 1: Operațiune de descărcare (Download) între client și server

Figura 5: Cerere de download inițiată de client. (Sursa imaginii: ADI)

Inițiată de client: 0x601: 2f 03 20 c8 00 00 00 (Figura 5).

Răspuns dat de server: 0x581: 60 03 20 00 00 00 00 (Figura 6).

În operațiunea prezentată în figura 6, combinația de biți CCS și SCS arată operațiunea de scriere reușită din partea clientului și răspunsul serverului, observate și în tabelul 2.

Figura 6: Răspunsul serverului privind download-ul. (Sursa imaginii: ADI)

Cazul 2: Operațiune de încărcare (Upload) între client și server

Inițiată de client: 0x601: 40 03 20 00 00 00 00 (Figura 7).

Răspuns dat de server: 0x581: 4f 03 20 00 c8 00 00 00 (Figura 8)

Figura 7: Cerere de upload inițiată de client. (Sursa imaginii: ADI)

Concluzie

Figura 8: Răspunsul serverului privind upload-ul. (Sursa imaginii: ADI

Combinația de biți CCS și SCS indică succesul operațiunii de încărcare între client și server. Exemplele menționate în acest articol pot fi aplicate la alte obiecte din dicționarul de obiecte al dispozitivului, oferind informații despre starea mașinii. Principalul obiectiv al acestei demonstrații este de a permite utilizatorilor să descifreze jurnalul de comunicații și să monitorizeze starea unității. Utilizatorii pot depana erorile în timp real și pot explora mai eficient caracteristicile avansate ale ADI Trinamic CANopen. Integrarea protocolului CANopen în produsele ADI oferă clienților flexibilitatea de a integra propriile PLC-uri cu modulele ADI Trinamic, permițând dezvoltarea de sisteme multi-furnizor. Această interfață este deosebit de valoroasă pentru clienții care lucrează la aplicații complexe, cum ar fi automatizarea laboratoarelor, robotica, procesarea lichidelor, prelucrarea semiconductorilor și multe altele.

Referințe

Olaf Pfeiffer, Andrew Ayre și Christian Keydel. “Embedded Networking with CAN and CANopen.” Copperhill Technologies Corporation, 2008.

“TMCM-6212 CANopen Firmware Manual.” Trinamic Motion Control, 2018.

Autor: Atul Kumar, Inginer de aplicații, ADI

Despre autor
Atul Kumar este inginer de aplicații în cadrul Centrului de Aplicații Dublin. Expertiza sa principală este în domeniul controlului motoarelor, al arhitecturii de control în buclă închisă pentru motoare pas cu pas cu consum redus de putere și motoare BLDC/PMSM. Și-a făcut studiile postuniversitare la Dublin City University și s-a alăturat companiei Maxim Integrated (acum parte a Analog Devices), ca inginer de aplicații în februarie 2022.