Kan öppna
CANopen är ett öppet nätverksprotokoll på toppnivå för att ansluta inbäddade enheter i ombord transport- och industrinätverk . Den använder CAN -realtidsprotokollet som ett nätverk och transportlager . Används för att koppla sensorer, ställdon och programmerbara logiska styrenheter till varandra. Öppen standard.
Typiska applikationer
Främst inom rörelsestyrningssystem, i monterings-, svets- och transportenheter. Används för enkelkabelanslutning av sensorboxar med flera ingångar, smarta sensorer, pneumatiska ventiler, streckkodsläsare, ställdon och operatörskonsoler.
Fördelar
Jämfört med andra CAN-baserade nätverk är CANopen-nätverket mer lämpligt för höghastighets rörelsekontrollsystem och återkopplingskontrollslingor. Hög tillförlitlighet, rationell användning av bandbredd, strömförsörjning via nätverkskabel.
Nackdelar
Låg prevalens utanför Europa.
Perspektiv
Förutom att vara ett applikationslagerprotokoll betyder CANopen medlemskap i en "hobby" hårdvarudesignklubb. Mer information finns på CiA:s webbplats (www.can-cia.org). Alla som anser det nödvändigt kan gå med i denna organisation. Organisationen förenar bland annat de ledande biltillverkarna i Europa.
Standardernas struktur
Organisationens struktur återspeglar strukturen för de standarder som styr driften av CANopen-nätverk.
Applikationsskiktsprotokollet är baserat på DS.301-dokumentet, som i sin tur är en praktisk utveckling av idéerna som deklareras i CiA DS-201-207-dokumenten. Den definierar protokollen för konfigurering och drift av nätverket.
CANopen-nätverket är fokuserat på användningen av mikrokontroller, inklusive de billigaste, därför är det uppdelat i ett antal valfria delsystem, vilket tillåter användning av endast de nödvändiga funktionerna.
Nätverkets funktion är utbyte av data. För att förstå hur CANopen-nätverket fungerar delar vi upp all data i funktionella och tekniska.
Funktionsdata - data som beskriver systemets målfunktion (temperatur, storleken på ställdonens styråtgärder), data som skulle överföras mellan enheterna, även om en annan kommunikationslinje än CAN användes som länk , till exempel, LIN eller USB , eller Ethernet , eller I2C .
Tekniska data - de som säkerställer nätverkets funktion som helhet, kontroll av korrekt funktion av alla noder, konfiguration av delar av systemet - de data vars utseende är associerat med användningen av CANopen-nätverket och inte är direkt beroende av de uppgifter som systemet löser.
Dokumentet CiA DS-201 identifierar fyra huvudgrupper av delsystem (Fig. 3 CiA DS-201)
CMS - meddelandehantering. Dessa inkluderar: funktionellt datautbyte, brådskande meddelandeutbyte, begäran om datautbyte,
objekt ordbokshantering
NMT - nätverkshantering, kontroll av nätverksenheter
DBT - Dynamic Identifier Allocation
LMT - enhetskonfigurationshantering
- 1. Realtidsutbyte av funktionella data nyckelord PDO, CMS (huvuddelsystemet är i princip valfritt, men om det inte finns något av de andra delsystemen, kan denna tomma uppsättning endast kallas CANopen potentiellt).
Exempel: Rumstemperaturstyrning huvudenhet, temperaturmätare, värmare/förångare
- Objektordboken är inte ett undersystem till nyckelordet PDO, SDO, entry, Index . Ordboken används av alla delsystem och beskriver måldata som ska utbytas, utbytesreglerna. Du kan dra en parallell med registret i Windows.
Exempel: Enpunktstemperatur och värmare/förångare kontrollparameter
- 2. Synkronisering av nyckelordet för datautbyte SYNC (valfritt, men samma ändamålsenliga delsystem som delsystem 1). När du använder detta delsystem finns det en synkmeddelandegenerator i nätverket som periodiskt sänder ett SYNC-meddelande med hög prioritet. Efter uppkomsten av ett sådant meddelande i nätverket utbyter alla synkroniserade enheter data inom ett angivet tidsintervall (synkront datautbytefönster). Kollisioner (samtidig överföring av data av två eller flera enheter) löses på nivån för det fysiska lagret av CAN-protokollet. Objektordboken innehåller korsreferenser, varifrån vilken data ska hämtas och vilken data som ska placeras var. Applikationer samlar alltså inte in data på egen hand, bara i vissa variabler (ur applikationens synvinkel) dyker det upp nya data med jämna mellanrum, på samma sätt som kontrollåtgärder. I detta läge kan utbytet ske inte bara mellan sensorerna och huvudenheten, utan även mellan sensorerna, förbi huvudenheten.
- Asynkront datautbyte. Inkluderar utbyte av meddelanden om nätverkshantering (nätverksnodhantering) Nätverkshantering, NMT-tjänster , meddelanden om nätverkskontroll undersystem (alternativ för upptäckt av nätverksfel) Felkontroll , brådskande meddelanden - nödobjekt (detektering av noddriftsfel) Emergency Object, EMCY . Meddelanden av denna klass kan visas när som helst, inklusive i det synkrona datautbytesfönstret. Dessa meddelanden har hög prioritet (högre än meddelandena som utgör datapaket), och kollisioner löses på nivån för det fysiska lagret av CAN-protokollet. För att implementera dessa delsystem i nätverket tilldelas en anordning (vid nätverksdesignstadiet) ansvarig för driften av ett visst delsystem. Dessutom finns det mekanismer för dynamisk tilldelning av sådana enheter. Nu i detalj.
- 3. Hantering av nätverksnoder Nätverkshantering, NMT Services (valfritt delsystem). Nätverket kan utformas på ett sådant sätt att varje enhet, efter att ha slutfört initieringen, går in i redo-tillståndet, men kommer inte att delta i utbytet av funktionsdata förrän nätverkshanteringsmastern (NMT-master) tillåter dess drift . I redoläget deltar inte enheten i utbytet av funktionsdata, men kan utbyta processdata. I redoläget kan enheten konfigureras (se Subsystem för hantering av objektordbok nedan). Med detta delsystem kan nätverksmastern återställa och starta om vilken som helst av noderna som kräver en sådan procedur. Mastern tar emot meddelanden från enheten som indikerar enhetens verkliga tillstånd, om det verkliga tillståndet inte stämmer överens med det förväntade, betraktas detta som ett fel. Felsvar diskuteras nedan.
- 4. Nätverkskontroll (detektering av nätverksfel) NMT-felkontrollprotokoll, nodskydd, Heartbeat-protokoll (valfritt undersystem). Vissa system (särskilt de som är relaterade till säkerhet) måste övervaka närvaron och användbarheten av alla standardsensorer.
Exempel: Gränslägesbrytare, när den utlöses ska motorn omedelbart stängas av.
Om själva sensorn plötsligt blir felaktig, när gränslägesbrytaren är stängd, kommer den inte att sända ett meddelande om detta till huvudenheten, som är fylld med en nödsituation, därför, om ett fel i en sådan sensor upptäcks, är nödvändigt för att omedelbart stänga av motorn
Nätverksfelsdetektering ( Nod Monitoring ) görs på två liknande sätt [1]
- I. Upprop för nodbevakningsnoder . Mastern frågar regelbundet noderna som svarar. Så snart noden slutar svara, noteras ett fel för denna sensor, och mastern, i enlighet med arbetslogiken, kan stoppa potentiellt farliga processer. En nod som inte kommer att pollas under en viss tid (linjen är bruten) flaggar också ett fel för sig själv. Nackdelarna med denna metod är att förfrågningar från mastern tar upp en del av nätverkets bandbredd och fel på en enda nod (master) leder till fel i hela nätverket.
- II. Styr klocka. Heartbeat ( lit. engelska "heartbeat" ). Alla nätverksnoder sänder oberoende, utan begäran, regelbundet meddelanden om deras tillstånd - "hjärtslagsmeddelande". Om det inte finns några meddelanden från en nod under kontrollintervallet, flaggar andra noder som prenumererar på dess meddelanden ett fel för sig själva. Denna metod saknar bristerna i den tidigare och rekommenderas för användning i moderna system [2] .
För varje specifikt nätverk är endast en kontrollmetod, antingen Node Guarding eller Heartbeat Protocol, tillåten.
- 5. Ändra objektordlistan. nyckelord PDO, SDO, PDO-mappning Objektlexikonet innehåller data som utbyts enligt PDO-principen, beskriver sammansättningen och strukturen av dessa data. Med hjälp av datautbyte på begäran (SDO) kan du ändra den datauppsättning som kommer att utbytas enligt PDO-principen. SDO-datautbyte är möjligt både i redo-tillståndet och i drifttillståndet. Efter att ha slagit på strömmen, men innan nätverksoperationen startas, är det alltså möjligt att konfigurera alla nätverksenheter för att utbyta nödvändiga data och sedan starta nätverket. När du ändrar ordbokens struktur under drift bör följande punkter beaktas:
- SDO-utbytet har lägre prioritet än SDO-utbytet, så det kan finnas en tidpunkt då en del av ordboken redan har ändrats i enlighet med de nya kraven, en del har ännu inte ändrats, och i det ögonblicket ett SDO-utbyte kommer att inträffa.
- Eftersom enheter som sänder och tar emot PDO:er måste förstå varandra kan en situation uppstå när en enhet kommer att fungera med den nya strukturen och den andra med den gamla.
Dessa två exempel visar möjligheten att ändra ordbokens struktur först när nätverket är stoppat, tyvärr är detta inte alltid möjligt.
- 6. Ändra data på begäran. Förutom att ändra ordlistan kan en app på en enhet ladda ner data till en annan enhet. Skillnaden mellan PDO- och SDO-kommunikation ur tillämpningssynpunkt. Vid utbyte av PDO sker allt automatiskt enligt vissa regler, och applikationen, utan att hänvisa till nätverksprimitiver, tar emot data från variabler, som om data erhölls inuti just denna enhet. För att ta emot data enligt SDO-principen måste en applikation använda nätverkstjänster för att begära data från en annan enhet, och först då, efter att ha fått ett svar, använda data för arbete. Därför bör ryggraden i datautbytet bygga på PDO-utbyte. Tyvärr finns det begränsningar för storleken på data (8 byte för PDO, men du kan använda flera av dessa bitar). Och bara när det är absolut nödvändigt att använda SDO. I SDO-datautbyte kallas enheten som kontaktades med en begäran om att ta emot eller skriva (ladda/ladda upp) data SDO-servern, och enheten som initierade utbytet kallas klienten. Beroende på mängden data som överförs utförs utbytet enligt olika algoritmer och kan inte vara mindre effektivt än PDO-utbytet. SDO-exchange låter dig kontrollera riktigheten av data, vilket till och med låter dig ladda ner bitar av körbar kod.
- 7. Nödobjekt, brådskande meddelanden. Nödobjekt, EMCY . Under drift kan enheten upptäcka fel i driften av sitt program eller i driften av elektroniken. I det här fallet, ju tidigare alla andra delar av systemet meddelas om detta, desto bättre och driften av ett sådant system blir säkrare. Högprioriterade brådskande meddelanden används för detta ändamål. Sådana meddelanden skickas när ett fel upptäcks och när felet försvinner. Standarden beskriver felklasser, sådana parametrar kan vara ström, spänning, temperatur. Om nödmeddelandemekanismen är aktiverad i nätverket måste enheter förstå minst två meddelanden - Allmänt fel (utan specifikation av kategorier), felåterställning. Varje typ av fel kan specificeras med en annan hel byte, som kan koda till exempel numret på den kontrollerade kedjan.
- Fel vid bearbetning. Basstandarden beskriver bara hur man rapporterar fel och definierar kategorier av fel. Ytterligare förtydligande och reaktion på felet bestäms av systemutvecklaren.
Ovanstående artiklar beskrivs i CiA DS-201-207 och CiA DS-301. Utvecklaren av systemet "från grunden" kan självständigt bestämma funktionskraven för nätet, kontrollerade parametrar och beteendescenarier i händelse av fel. Men eftersom CANopen-nätverk används av ett stort antal tillverkare som redan har utvecklat system som täcker många branscher, har rekommendationer dykt upp om vilka parametrar som åtminstone det här eller det systemet ska fungera, och vilka typer av reaktioner på vissa specifika fel som specifika till en viss enhetsklass. Dessa rekommendationer utfärdas i form av standarder för CiA DS-4**-serien. Detta gör det möjligt att producera delar av system snarare än hela system, och dessa nya instrument kommer att integreras perfekt med system utvecklade av kända tillverkare. Vissa av dessa standarder är redan öppna (etablerade), vissa förblir små grupper av tillverkares egendom (nya, kan komma att ändras). Den främsta anledningen till att det finns så många stängda dokument är att detta inte bara är rekommendationer, utan standarder, om de inte följs kommer systemet inte att fungera. När ändringar görs i dokument skickas nya versioner till alla medlemmar i denna intressegrupp. Intressegrupper är inte en sluten kast, alla kan gå med i en eller annan grupp. En förutsättning är kontantinsats. Beloppen som tas ut beror på företagets storlek och är demokratiska i förhållande till småföretag.
FAST BELOPP MEDLEMSAVGIFTER (ÅR) INKLUSIVE TYSKA SKATTER
mer än 100 000 anställda: 8 700,00 Euro 10 353,00 Euro
från 10 000 till 99 999 anställda: 5 200,00 Euro 6 188,00 Euro
från 1 000 till 9 999 anställda: 4 100,00 euro 4 879,00 euro
från 100 till 999 anställda: 2 100,00 Euro 2 499,00 Euro
från 50 till 99 anställda: 1 500,00 Euro 1 785,00 Euro
från 10 till 49 anställda: 900,00 Euro 1 071,00 Euro
från 1 till 9 anställda: 650,00 Euro 773,50 Euro
för skolor och universitet: 520,00 Euro 618,80 Euro
All information om vilka grupper som finns, vilka standarder de har utvecklat och hur man ansluter till dem, finns på webbplatsen can-cia.org, som i det här fallet är det huvudsakliga organiseringsorganet och mekanismen för PR.
Industriella nätverk i CAN-familjen
Se även
CiA (engelska) .
Anteckningar
- ↑ CANopen Basics - Bevakning och hjärtslag (nedlänk) . Hämtad 28 april 2016. Arkiverad från originalet 21 maj 2016. (obestämd)
- ↑ Olaf Pfeiffer, Andrew Ayre, Christian Keydel Embedded Networking with CAN and CANopen - Copperhill Media, 2008
Länkar
| Industriella nätverk |
|---|
| Styrsystem bussar |
|
|---|
| Distribuerad kringutrustning |
|
|---|
| Drivteknik |
|
|---|
| Fältenheter |
|
|---|
| Byggnadsautomation |
|
|---|