Masterproef Handheld communication device
Studiegebied Industriële wetenschappen en technologie Opleiding Master in de industriële wetenschappen: Elektronica-ICT Afstudeerrichting Elektronica Academiejaar 2008-2009
Hanne Deschildre Howest – departement PIH, Graaf Karel de Goedelaan 5, 8500 Kortrijk
Voorwoord
Voor de realisatie van deze masterproef wil ik graag mijn promotor, Tom Decouttere, bedanken. Tom begeleidde mij doorheen de masterproef en stond altijd klaar wanneer er problemen optraden. In maart nam Filip Deniere deze taak over, ook hij zette zich ten volle in voor mij zodat ik een mooi eindresultaat kon neerzetten. Bedankt Tom en Filip, niet iedereen had zo’n goede externe promotoren. Als interne promotor stond Benjamin Samyn mij bij met raad en daad, ook wanneer er wijzigingen in het eindwerk werden aangebracht. Bedankt voor de goede begeleiding. Binnen PsiControl bedank ik graag Mario Debevere, Bart Desimpelaere, Olivier Helewaut en Tom Robesyn voor de hulp bij problemen. Er was een leuke sfeer binnen het bedrijf en het was aangenaam om er mijn masterproef te maken. In de loop van het academiejaar heb ik heel wat bijgeleerd en dat besef bracht voldoening.
Ook een dankwoordje tegenover mijn papa en mijn broer Arne omdat ze altijd klaar staan om te helpen, ook wat betreft dit werk. De masterproef zorgde voor een druk jaar waarin ze me veel geholpen hebben thuis. Alles wat ik doe is met mijn mama in gedachten, dus ook voor de realisatie van de masterproef was ze heel dichtbij. Ter nagedachtenis van haar probeer ik in mijn studies en alles wat me bezighoudt te volharden, ook wanneer het wat lastiger wordt. We denken veel aan haar maar dat maakt het gemis niet kleiner.
Hanne Deschildre
I
Inhoudsopgave Voorwoord .................................................................................................................................. I Symbolen- en afkortingenlijst .................................................................................................. IV Lijst van figuren en tabellen ...................................................................................................... V Inleiding ..................................................................................................................................... 1 Hoofdstuk 1: Concept................................................................................................................. 2 1.
Masterproef concept ........................................................................................................ 2
2.
Programmeeromgeving en softwarestructuur ................................................................. 4
3.
Opstelling ........................................................................................................................ 6
4.
Opmerkingen ................................................................................................................... 7
Hoofdstuk 2: PEG+ .................................................................................................................... 8 1.
2.
Studie PEG+ .................................................................................................................... 8 1.1
Inleiding ........................................................................................................... 8
1.2
Werking ............................................................................................................ 8
1.3
Tools ............................................................................................................... 16
PEG+ toegepast op de Handheld ................................................................................... 21 2.1
Schermstructuur ............................................................................................. 21
2.2
Praktisch: opbouw van de schermstructuur .................................................... 30
Hoofdstuk 3: Modbus ............................................................................................................... 42 1.
Geschiedenis van de Modbus interface ......................................................................... 42
2.
Modbus protocol principe ............................................................................................. 42
3.
2.1
Protocol omschrijving .................................................................................... 42
2.2
Modbus adressering........................................................................................ 44
2.3
Modbus functie codes..................................................................................... 46
2.4
Modbus error codes ........................................................................................ 48
Modbus toegepast op de Handheld ............................................................................... 49 3.1
Modbus files ................................................................................................... 49
3.2
Werking van de bestaande software ............................................................... 50
3.3
Modbus software voor de schermen............................................................... 51
Hoofdstuk 4: CANopen ............................................................................................................ 56 1.
CANopen studie ............................................................................................................ 56 1.1
Hanne Deschildre
Inleiding ......................................................................................................... 56 II
2.
1.2
De object dictionary ....................................................................................... 57
1.3
Communicatieobjecten ................................................................................... 59
1.4
Communicatiemodellen ................................................................................. 60
1.5
Protocollen ..................................................................................................... 60
CANopen toegepast op de Handheld ............................................................................ 72 2.1
Probleemstelling ............................................................................................. 72
2.2
CANopen uitwerking ..................................................................................... 73
Hoofdstuk 5: XML-structuur en opmerkingen ...................................................................... 78 1.
2.
XML-structuur .............................................................................................................. 78 1.1
XML voor Modbus......................................................................................... 78
1.2
XML voor CANopen ..................................................................................... 84
1.3
XML-parser .................................................................................................... 86
1.3.1
FAT filesysteem ............................................................................................. 86
1.3.2
Parser .............................................................................................................. 86
Tips & Tricks ................................................................................................................ 89
Besluit....................................................................................................................................... 93 Literatuurlijst ............................................................................................................................... I Bijlagen ....................................................................................................................................... I
Hanne Deschildre
III
Symbolen- en afkortingenlijst BSD
Bekaert SR Drive
CAN
Controller area network
DOM
Document object model
Emcy
Emergency object
FAT
File allocation table
GUI
Graphical user interface
HCD
Handheld communication device
MSB
Most significant bit
NMT
Network management
PEG+
Portable embedded GUI
PDO
Process data object
PLC
Programmable logic controller
RTOS
Real time operating system
SD-card
Secure digital card
SDO
Service data object
SYNC
Sychronisation object
XML
eXtensible Markup Language
Hanne Deschildre
IV
Lijst van figuren en tabellen Figuur 1: PsiControl mechatronics logo..................................................................................... 1 Figuur 2: HCD opgesteld met enkele CANopen en Modbus slaves .......................................... 2 Figuur 3: Blokschema van de HCD ........................................................................................... 4 Figuur 4: Visual DSP omgeving ................................................................................................ 4 Figuur 5: Lagenstructuur van een project .................................................................................. 5 Figuur 6: Opstelling van de masterproef .................................................................................... 6 Figuur 7: SWELL software logo ................................................................................................ 8 Figuur 8: Voorbeeldscherm ........................................................................................................ 9 Figuur 9: Blokschema van de 4 PEG+ pijlers en hun onderling verband ................................ 11 Figuur 10: De boomstructuur waarmee PegPresentationManager de orde bijhoudt. .............. 12 Figuur 11: De vorm van een PegMessage ................................................................................ 13 Figuur 12: Bericht dat de programmeur verstuurt voor een Tab.............................................. 13 Figuur 13: Code binnen PEG+ die het Tab bericht opvangt. ................................................... 14 Figuur 14: De bottom up afhandeling van berichten................................................................ 15 Figuur 15: Snapshot van de PEG Window Builder.................................................................. 16 Figuur 16: De files die de Window Builder genereert ............................................................. 17 Figuur 17: Instellingen voor de String Table ........................................................................... 18 Figuur 18: De String Table Editor............................................................................................ 18 Figuur 19: Snapshot van de PEG Image Convert .................................................................... 19 Figuur 20: De code die de PEG Image Convert genereert ....................................................... 19 Figuur 22: De code die de PEG Font Capture genereert voor een nieuwe font ....................... 20 Figuur 21: Snapshot van de PEG Font Capture tool ................................................................ 20 Figuur 23: Begin van de schermstructuur voor de CANopen slaves (Standaard schermen) ... 22 Figuur 24: 2e deel van de schermstructuur (Applicatie specifieke schermen) ........................ 23 Figuur 25: De schermstructuur voor Modbus schermen .......................................................... 24 Figuur 26: Het informatiescherm ............................................................................................. 26 Figuur 27: Boomstructuur van schermen ................................................................................. 26 Figuur 28: Standaardschermen van de HCD ............................................................................ 27 Figuur 29: Applicatie specifieke schermen van de HCD ......................................................... 28 Figuur 30: Toetsen van de HCD .............................................................................................. 29 Figuur 31: HcdStartupScreen ................................................................................................... 32 Figuur 32: De initialisatiefunctie voor het tonen van PEG+ schermen.................................... 33 Figuur 33: Start van de timer als het scherm verschijnt ........................................................... 33 Figuur 34: Oproep van een nieuw protocol scherm ................................................................. 34 Figuur 35: Verwijderen van een scherm .................................................................................. 34 Figuur 36: Vermeldingen in HcdStartupScreen om de figuren op het scherm te plaatsen ...... 34 Figuur 37: HcdProtocol ............................................................................................................ 35 Figuur 38: Prototype voor de key-scan-functie ........................................................................ 35 Figuur 39: Initialisatie van de timer voor key scanning ........................................................... 35 Figuur 40: Key scanning code .................................................................................................. 36 Figuur 41: Berichten die verzonden worden bij de “enter”-functie ......................................... 36 Hanne Deschildre
V
Figuur 42: Berichten die verzonden worden bij een “tab”-functie. ......................................... 36 Figuur 43: HcdModbusOverview............................................................................................. 37 Figuur 44: Nodige declaraties om het protocolScreen opnieuw op te roepen ......................... 37 Figuur 45: De oproep van het vorig scherm: ProtocolScreen .................................................. 37 Figuur 46: HcdCANopenScreen .............................................................................................. 38 Figuur 47: HcdCANopenOverview ......................................................................................... 38 Figuur 48: HcdNmtAllSlavesScreen ........................................................................................ 39 Figuur 49: HcdModbusSpecific ............................................................................................... 39 Figuur 50: HcdSlaveInfo .......................................................................................................... 40 Figuur 51: HcdCANopenSpecific ............................................................................................ 40 Figuur 52: HcdParameterScreen .............................................................................................. 41 Figuur 53: Modbus bericht ....................................................................................................... 42 Figuur 54: Foutvrije Modbus transactie ................................................................................... 43 Figuur 55: Modbus transactie die foutloopt ............................................................................. 43 Figuur 56: De tabellen bij Modbus adressering ....................................................................... 44 Figuur 57: Het Modbus adresseringsmodel ............................................................................. 45 Figuur 58: Modbus functie code categorieën ........................................................................... 46 Figuur 59: Aanvraag met functie code 01: lees coil status ...................................................... 46 Figuur 60: Antwoord op een “lees coil” aanvraag ................................................................... 47 Figuur 61: Foutmelding bij een “lees coil” aanvraag ............................................................... 47 Figuur 62: Modbus transactie state diagram ............................................................................ 48 Figuur 63: Initialisaties voor Modbus ...................................................................................... 49 Figuur 64: Initialisatie van een hook ........................................................................................ 50 Figuur 65: Prototype van de opvangfunctie voor een Modbusbericht ..................................... 50 Figuur 66: Verzenden van een Modbus toestel identificatie aanvraag .................................... 50 Figuur 67: De busscanning start met de verzending van een bericht naar de eerste slave....... 51 Figuur 68: Functie die wordt opgeroepen bij ontvangst van het antwoord op de ID request .. 51 Figuur 69: Aanmaak van een object per slave dat alle informatie omtrent de slave vasthoudt 52 Figuur 70: Functie, opgeroepen bij een time out ..................................................................... 52 Figuur 71: Functie, opgeroepen als busscanning beëindigd wordt .......................................... 52 Figuur 72: Deel van de structuur binnen HcdSlave ................................................................. 54 Figuur 73: Een CANopen frame .............................................................................................. 59 Figuur 74: NMT state machine van een CANopen toestel ...................................................... 61 Figuur 75: Een NMT-bericht dat de slave van state doet veranderen ...................................... 63 Figuur 76: Berichten bij node guarding ................................................................................... 64 Figuur 77: Structuur van een SDO-bericht .............................................................................. 65 Figuur 78: SDO expedited leesactie ......................................................................................... 66 Figuur 79: SDO segmented leesactie ....................................................................................... 66 Figuur 80: SDO expedited schrijfactie ..................................................................................... 67 Figuur 81: SDO segmented schrijfactie ................................................................................... 67 Figuur 82: Abort SDO transfer bericht .................................................................................... 69 Figuur 83: De verzending van een PDO .................................................................................. 70 Figuur 84: Het SYNC object met de synchrone en asynchrone PDO verzending ................... 71 Figuur 85: HcdCANopenOverview ......................................................................................... 73 Hanne Deschildre
VI
Figuur 86: HcdNmtAllSlavesScreen ........................................................................................ 74 Figuur 87: HcdCANopenSpecific ............................................................................................ 75 Figuur 88: HcdParameterScreen .............................................................................................. 76 Figuur 89: HcdSlaveInfo .......................................................................................................... 76 Figuur 90: Standaard schermen voor de oefening .................................................................... 78 Figuur 91: Applicatie specifieke schermen voor de oefening .................................................. 79 Figuur 93: Holding register voor het instellen van de state ..................................................... 80 Figuur 92: State opsomming in het XML-bestand ................................................................... 80 Figuur 94: ModbusSlaveScreen specificaties in het XML-bestand ......................................... 81 Figuur 95: SlaveInfoScreen specificaties in het XML-bestand ............................................... 82 Figuur 96: ParameterScreen specificaties in het XML-bestand ............................................... 83 Figuur 97: CANopenSlaveScreen specificaties in het XML-bestand ...................................... 84 Figuur 98: SlaveInfoScreen specificaties in het XML-bestand ............................................... 84 Figuur 99: ParameterScreen specificaties in het XML-bestand ............................................... 85 Figuur 100: Oplossen van een pointer probleem ..................................................................... 90 Figuur 101: De compilers en processors mogelijk voor PEG+................................................... I Figuur 102: Voorbeelden van mogelijke berichten ................................................................... II Figuur 103: Eerste voorstel voor een schermstructuur............................................................. III Figuur 104: RJ11 connector ..................................................................................................... IV Figuur 105: Modbus exception codes ....................................................................................... V Figuur 106: Voorbeeld van een OD ingang ............................................................................. VI Figuur 107: Overzicht van de functie codes............................................................................VII Figuur 108: Mogelijke CANopen berichten per state .............................................................VII Figuur 109: Heartbeat principe ............................................................................................. VIII Figuur 110: DB9 connector ................................................................................................... VIII
Tabel 1: De object dictionary gebieden.................................................................................... 57 Tabel 2: Alle elementen die kunnen voorkomen in een OD .................................................... 58 Tabel 3: Voorbeeld van een OD ............................................................................................... 59 Tabel 4: COB-ID van een CANopen frame ............................................................................. 60 Tabel 5: Parameter specificaties in het XML-bestand ............................................................. 82
Hanne Deschildre
VII
Inleiding Deze masterproef werd aangeboden door PsiControl Mechatronics. Dit bedrijf is gevestigd in Ieper en is fabrikant van real-time ingebedde systemen, motoren, drives, actuatoren en gebruikersinterfaces voor speciale applicaties. Met 195 mensen (55 in R&D) levert PsiControl Mechatronics innovatieve ontwerpen en productiediensten aan technologische bedrijven. Het bedrijf werkt wijd verspreid bij de hulp naar klanten toe in ontwerp, opbouw, aflevering en onderhoud van mechatronische producten via een faciliteitennetwerk in 15 landen. Naast het bedrijf in Ieper is er een vestiging in Roemenië die hoofdzakelijke productie activiteiten ondersteunt.
Figuur 1: PsiControl mechatronics logo
Het idee voor deze masterproef is gegroeid uit de nood aan een handheld die slaves kan beïnvloeden. De bedoeling is dat de gebruiksvriendelijke handheld wordt geprogrammeerd zodat hiermee aangesloten toestellen kunnen uitgelezen en ingesteld worden. De gebruiker moet, op een overzichtelijke manier en met behulp van de toetsen, tussen enkele schermen kunnen switchen. Voor de handheld zijn 2 grote werkgebieden, enerzijds het grafisch gedeelte dat moet geprogrammeerd worden en anderzijds de software voor de communicatie met de slaves. Voor het grafisch gedeelte is een klassenbibliotheek voor handen: PEG+ en wat betreft de communicatie zijn vooral de protocollen Modbus en CANopen belangrijk. Oorspronkelijk werd geopteerd om CANopen als primair en Modbus als secundair protocol te zien. CANopen moest worden geïmplementeerd binnen de masterproef en bij elke stap zou worden rekening gehouden met de latere implementatie van Modbus. In maart is er echter heel wat veranderd door een ingrijpende ontslagronde. Hierna werd in overleg Modbus als primair protocol genomen en CANopen werd op de achtergrond geplaatst. Zo’n omschakeling brengt heel wat problemen voor de masterproef met zich mee maar veel andere opties waren er niet.
Hanne Deschildre
1
Hoofdstuk 1: Concept 1. Masterproef concept Voor de aansturing van devices wordt vaak gezocht naar de meest geschikte presentatie van toestelparameters naar de gebruiker toe. De toestellen kunnen een interface aanbieden via een geïntegreerde module of ze kunnen andere toestellen bedienen vanop afstand. Bij deze laatste optie kan een handheld communication device de taak vervullen. Via een master die in de hand past, worden de slaves beïnvloed. Deze HCD biedt via een scherm en enkele invoerelementen een mogelijkheid om parameters bij de slaves uit te lezen en aan te passen. De figuur verduidelijkt het principe.
SD-kaart
Figuur 2: HCD opgesteld met enkele CANopen en Modbus slaves
De software wordt tijdens ontwikkeling geprogrammeerd op de computer en ingeladen in de HCD. De handheld wordt hier voorgesteld door een Standard Compact module, eerder gebruikt als user interface bij toepassingen voor Atlas Copco. De module is master op zowel de CANopen- als Modbus bus. De uitwerking van een dergelijke opstelling kan in 3 stukken opgedeeld worden: het grafisch gedeelte (de GUI), de communicatie en de informatiestructuur. 2 Hanne Deschildre
Hoofdstuk 1: Concept
GUI: De software bibliotheek PEG+ biedt de bouwstenen om een goeie GUI te maken. Qua lay-out worden de schermen gerealiseerd met de bouwstenen van PEG+.
Communicatie: Bij aanvang van de masterproef werd beslist om CANopen als primair protocol te implementeren en bij elke stap rekening te houden met een latere implementatie van Modbus. In maart echter werden de rollen omgedraaid. Hoe dan ook, voor het geïmplementeerde protocol moet de HCD alle slaves herkennen en zijn schermen weergeven. Modbus slaves kunnen aangesloten worden en de HCD communiceert er zonder problemen mee. Een implementatie van het protocol houdt in dat alle software aanwezig moet zijn en het geheel kan samenwerken met het besturingsprogramma van de HCD: Quadros. Aangezien de protocollen enige uitleg vereisen wordt voor de uitleg van implementaties en ideeën telkens een (gedetailleerde) samenvatting van de studie gegeven. Beide seriële protocols werken via RS485. Voor Modbus is een RJ11 connectie voorzien (Modbus bijlage 1), CANopen zal over DB9 lopen (CANopen bijlage 5). Informatie structuur Door de protocollen Modbus en CANopen ligt de structuur van de toestellen deels vast. Dat maakt het voor de HCD mogelijk om standaardinformatie op te halen bij elke slave zonder enige voorkennis van diens configuratie. Daarnaast moet de HCD ook in staat zijn specifieke karakteristieken op te halen of in te stellen en hiervoor is wel enige voorkennis van de toestellen nodig. Via een SD-kaart, aanwezig bij de HCD, kan de bediener van de toestellen de nodige informatie voor elke slave ter beschikking stellen zodat de HCD een gedetailleerde interface per slave kan voorzien. Voor de informatie op de SD-kaart wordt een structuur opgesteld zodat de HCD de informatie probleemloos kan ophalen, parsen en gebruiken om de schermen op te bouwen, zowel op gebied van lay-out als inhoud.
Concreet houdt de uitwerking van de 3 pijlers in dat bij de master alle elementen moeten geprogrammeerd worden die de opstelling (figuur 2) mogelijk maken. De elementen zijn weergegeven op het volgend blokschema. We zien de master aangesloten op CANopen- en Modbus slaves.
3 Hanne Deschildre
Hoofdstuk 1: Concept
Figuur 3: Blokschema van de HCD
2. Programmeeromgeving en softwarestructuur Om alles te programmeren en in te laden is een programmeeromgeving nodig. Hier wordt Visual DSP gebruikt. Er wordt geprogrammeerd in C en C++.
Figuur 4: Visual DSP omgeving 4 Hanne Deschildre
Hoofdstuk 1: Concept
Een project wordt gekenmerkt door een nummer. De HCD zal software krijgen met nummer 818, de 8 betekent dat het project gestart werd in 2008, 18 is het volgnummer. Belangrijk om weten is dat de 818 het applicatieproject is en beroep doet op een bibliotheek, namelijk de 817. Die doet op zijn beurt beroep op kernel files (k3data) en de PEG+ bibliotheek. De 818 bevat C++ code en stelt de HCD applicatie voor. De visuele applicatie werd opgebouwd met PEG+ bouwstenen (in C++) , de communicatiesoftware zit voornamelijk in de 817 omdat dit niet applicatie specifiek is. De 817 bevat uitsluitend C-files voor de algemene werking en de communicatie. De communicatiecommando’s die de applicatie nodig heeft worden dan in de 818 opgeroepen. Verder zijn er nog enkele elementen die specifiek zijn aan een dergelijk project: -
-
-
-
Alle functies die in andere files opgeroepen worden hebben een beduidende naam. Het eerste gedeelte van de naam is het bestand waarin de functie gedefinieerd wordt, op die manier kan de programmeur de invulling van zijn functie altijd terugvinden. Het tweede deel van een functienaam zegt iets over de gebeurtenis bij oproep van de functie. Bvb.: HcdProtocolBusscanFinished(): deze functie is te vinden in het bestand: HcdProtocol en voert code uit wanneer de busscanning gedaan is. Elke code en header bestand in C wordt opgebouwd volgens de design rules die algemeen worden toegepast binnen PsiControl. Ook voor deze masterproef werd er rekening mee gehouden. Voor files in C++ is nog geen afgelijnde structuur voorzien maar de opbouw is vrij logisch en overal analoog gehouden. Vanuit C++ worden vaak functies in C opgeroepen. Een prototype van de gebruikte functie met de term “extern” ervoor legt de link voor de compiler. Meer informatie hierover in hoofdstuk 5. Voor elk project wordt de software opgebouwd in lagen. De software van de projecten wordt dan ook in de juiste files per laag geschreven. Applicatie
Quadros Standaard laag Driver laag System laag
Figuur 5: Lagenstructuur van een project
Door die lagenstructuur worden alle files opgeslagen in een gestructureerd bestandssysteem en alles moet tijdig ingecheckt worden op de server, ook voor het HCD-project.
Verdere software verdieping wordt toegelicht per hoofdstuk. Hoofdstuk 5 geeft nog wat “tips en tricks“ waarin zaken aan bod komen die opgemerkt werden in deze masterproef.
5 Hanne Deschildre
Hoofdstuk 1: Concept
3. Opstelling
Voeding voor HCD
HCD testbord
Adaptor voor OXI
OXI slave
Figuur 6:: Opstelling van de masterproef
In de opstelling zien we het testbord voor de HCD samen met zijn voeding en een Analog Devices evices tool om de software via de laptop in te laden. laden. De HCD stuurt een OXI en toont zijn schermen. Hiervoor haalt hij informatie van de SD-kaart. SD De OXI is een platform dat stappenmotoren aanstuurt. Voor de demo op de presentatie kunnen 2 stappenmotoren aan deze OXI geschakeld worden.
6 Hanne Deschildre
Hoofdstuk 1: Concept
4. Opmerkingen Zoals het CANopen hoofdstuk duidelijk maakt zijn er enkele problemen opgetreden in de loop van het academiejaar. De problemen zijn leerrijk maar leiden niet tot software die geïmplementeerd kan worden. Een overzicht van de evolutie: -
-
-
-
-
-
Na een week en half werd veranderd van hardwareplatform. De Standard Compact werd, om talrijke redenen, verkozen boven het eerst voorgestelde. De studie rond het eerste platform was overbodig maar een mooier platform werd aangeboden. Bij de nieuwe verfijning van het eindwerk werd voorgesteld om zowel Modbus als CANopen te implementeren. Bij nader inzien bleek snel dat dit, naast de implementatie van PEG+, een volledige structuuruitwerking en de XML-uitlezing, te veel was voor één masterproef. Aangezien CANopen nieuw was, werd dit het primair protocol. Na een grondige studie van CANopen en PEG+ werd begonnen met een test van het protocol. Om enkele berichten te sturen en een slave te beïnvloeden moest al wat software worden geschreven. De SDO-berichtgeving was geslaagd en er werd gestart met PDO’s. Eind 1e semester werd echter beslist om een stack aan te kopen. Na de beslissing omtrent de CANopen stack was het tijd om de bijhorende CANtools te onderzoeken. Dit alles gebeurde naast de studie en implementatie van het visuele aspect van de masterproef en de xml-uitlezing, 2 zaken die een grondige studie vereisten vooraleer ze geïmplementeerd werden. In maart vielen 2 Roemeense R&D ingenieurs weg. Zij onderzochten de stack en zouden hem werkbaar maken op de Blackfin processor van mijn masterproef. Dit nog als “extraatje” bij de masterproef voegen was ondoenbaar vandaar de beslissing om over te stappen naar Modbus. Aangezien dit protocol oorspronkelijk secundair was, moest rond Modbus nog een studie gebeuren. Ook Modbus schermen binnen PEG+ moesten nog gemaakt worden, voor de ommekeer waren ze immers niet nodig. De implementatie van CANopenschermen was gestart en werd meteen stopgezet. Even later viel mijn promotor, Tom Decouttere, weg. Daarna nam Filip Deniere de taak op zich.
Dergelijke problemen zijn dagdagelijks en oplosbaar. Alleen is de tijd voor een masterproef beperkt. Desondanks is het resultaat van de masterproef naar wens. Een samenvatting van de resultaten wordt meegegeven in het besluit.
7 Hanne Deschildre
Hoofdstuk 1: Concept
Hoofdstuk 2: PEG+ 1. Studie PEG+ 1.1 Inleiding PEG+ is een sterk objectgeoriënteerde bibliotheek gecreëerd door SWELL software (Figuur7). Ze biedt de mogelijkheid de visuele opbouw voor een display te maken. PEG+ staat voor Portable Embedded GUI. Het is porteerbaar naar elk hardware systeem dat een grafische output aankan. In PEG+ bijlage 1 zit een overzicht van enkele systemen waarop PEG+ gebruikt kan worden, hierbij zitten ook systemen van Analog Devices met de Blackfin als processor. De doelsystemen zijn real-time ingebedde systemen en de bibliotheek levert ons de bouwstenen voor een GUI. Deze bouwstenen zijn klassen in de objectgeoriënteerde C++ taal. Aan de hand van deze softwarebasis worden klassen gemaakt. Door hiervan op de juiste plaats een object aan te maken kan een volledige schermstructuur en –layout opgebouwd worden. Kennis over de werking en samenhang van de softwarestructuur is dus van groot belang bij het maken van onze eigen GUI.
Figuur 7: SWELL software logo
1.2 Werking Om de bibliotheek te gebruiken op een systeem moeten enkele instellingen gebeuren, deze staan in een notendop vermeld in PEG+ bijlage 2. Voor deze masterproef waren de voorbereidingen reeds getroffen maar af en toe moest er nog een controle gebeuren. We starten dus van een systeem waarbij de PEG+ library toegevoegd is. Om nu effectief aan de slag te gaan als programmeur en schermen te maken, moeten we het een en ander weten over de PEG+ werking. PEG+ is een object georiënteerde C++ bibliotheek. Bij een grondige studie van de bibliotheek zien we twee belangrijke elementen: de object georiënteerde structuur en de communicatie via berichten. Deze pijlers worden uitvoerig besproken maar het algemeen plaatje ziet er als volgt uit:
8 Hanne Deschildre
Hoofdstuk 2: PEG+
Alles wat te zien is op het scherm (elke button, elk tekstvak, elk window,…) is een object van een PEG+ klasse. Deze objecten communiceren met elkaar aan de hand van berichten. Dus telkens wanneer een gebeurtenis plaatsvindt (e.g. een button wordt ingedrukt), wordt een bericht gestuurd van een object (de button) naar een ander object (het window) om te laten weten dat er “iets” gebeurt is. Bij de ontvanger kunnen 2 scenario’s voorvallen: de voorziene afhandelcode wordt doorlopen of het bericht wordt genegeerd.
1.2.1
Objectgeoriënteerd aspect van PEG+
PEG+ is sterk object georiënteerd1 en elk soort element is afgeleid van de klasse PegThing. Voor alle elementen (buttons, tekstvakken, windows,…) bestaat een klasse waarvan bij initialisatie een object wordt aangemaakt. Al deze klassen zijn dus via via of rechtsreeks afgeleid van PegThing, dat de basis eigenschappen voorziet. Basiseigenschappen zijn o.a.: - Is het object zichtbaar? - Wie is de parent van het object? - Welke children heeft het object? - Is interactie met de gebruiker mogelijk? -… Deze gegevens worden bijgehouden in attributen die PegThing aanbiedt. Aangezien alles hiervan erft, bezit elk element van de GUI deze attributen en per object worden ze ingevuld. Een voorbeeld zal duidelijk maken dat overerving een elementair begrip is bij PEG+. Voorbeeld: Het scherm bevat volgende elementen: - scherm met titelbalk - 2 buttons
Figuur 8: Voorbeeldscherm
1
Als de lezer niet goed op de hoogte is van het object georiënteerd programmeren wordt aangeraden om een korte samenvatting te lezen over dit onderwerp (Tip: Lafore, R., Object-Oriented Programming in C++, Third edition ).
9 Hanne Deschildre
Hoofdstuk 2: PEG+
Het scherm object wordt aangemaakt van de klasse PegDialog => PegDialog erft van PegWindow => PegWindow erft van PegTextThing => PegTextThing erft van PegThing Via elke klasse wordt functionaliteit toegevoegd. Het nut van de overerving kan als volgt aangetoond worden: PegTextThing is een tussenklasse die ervoor zorgt dat tekst kan weergegeven worden op het object. Zowel een PegButton, PegWindow, PegTitle, PegString,… hebben deze functionaliteit nodig en als alternatief voor code herhaling is overerving ideaal.
1.2.2
Berichtenstroom
De objectenstructuur is nu duidelijk. Voor de communicatie tussen deze objecten gebruikt PEG+ berichten. Als een button - die een ander scherm oproept - wordt ingedrukt, moet een melding gegenereerd worden die meedeelt aan het actief scherm dat die de focus verliest. De melding gebeurt via een bericht. Om de berichtenstroom te kunnen volgen lichten we de vier pijlers van de PEG+ communicatie nader toe: a. PegTask b. PegPresentationManager c. PegMessageQueue d. PegScreen PegPresentationManager en PegMessageQueue zijn de belangrijkste bij het programmeren van een GUI. PegTask en PegScreen spreek je niet rechtstreeks aan maar vervullen heel wat taken op de achtergrond. De pijlers en hun onderling verband worden schematisch weergegeven in figuur 9.
a. PegTask PegTask vormt de scheiding tussen het realtime besturingssysteem (RTOS) en alles wat te maken heeft met de opbouw van de GUI. Het zorgt ervoor dat het RTOS (hier Quadros) kan samenwerken met PEG+.
10 Hanne Deschildre
Hoofdstuk 2: PEG+
Figuur 9: Blokschema van de 4 PEG+ pijlers en hun onderling verband
b. PegPresentationManager De presentation manager is een window met als hoofdoel: zorgen voor de orde op het scherm. Zijn basistaken zijn: - het window en zijn subobjecten bijhouden (zoals buttons, tekstvakjes,…) - bijhouden wie focus heeft en bijgevolg de user input moet ontvangen - bijhouden welk scherm voor een ander staat
Hoe vervult de PegPresentationManager zijn taak? Zoals eerder besproken2 erft alles van PegThing. Elk object van PegThing (of object van een afgeleide klasse) bezit een pointer naar zijn First child en naar zijn next sibling. Op die manier wordt heel de schermstructuur en de lay-out van elk scherm bijgehouden in een boomstructuur. Volgende figuur geeft dit schematisch weer.
2
Hoofdstuk 2 PEG+, onder punt 1.2.1 Objectgeoriënteerd aspect van PEG+ 11
Hanne Deschildre
Hoofdstuk 2: PEG+
Figuur 10: De boomstructuur waarmee PegPresentationManager de orde bijhoudt.
Bemerk dat PegPresentationManager via via ook afgeleid is van PegThing. De manager erft namelijk van PegWindow (wat een pegThing-afgeleide is). Het is weliswaar een window zonder rand dat vaak onzichtbaar is en altijd de volledige display vult. Voor de manier van bijhouden (figuur 10) is PegPresentationManager dus de parent van ALLE windows! (het nut van een presentation manager als parent wordt duidelijk wanneer de berichtenstroom uitgelegd wordt). Als PegPresentation beïnvloed wordt (e.g. een window toevoegen), worden volgende functies gebruikt: add(), remove(), First(), en next().
Event Driven Programming Event gedreven programmeren houdt hier de communicatie via berichten in. Wanneer het PegThing (e.g. een button) een verandering ondergaat (ze wordt ingedrukt); verstuurt het een bericht naar zijn parent om dit te laten weten. De parent (het window) vangt dit bericht op en handelt de nodige code af. Binnen de bibliotheek zijn er al enkele standaard berichten voorzien maar als gebruiker kan je ze ook zelf definiëren. Beiden hebben dezelfde structuur (figuur 11).
12 Hanne Deschildre
Hoofdstuk 2: PEG+
Figuur 11: De vorm van een PegMessage
Het bericht bevat enkele elementaire velden zoals psource (de oorsprong), ptarget (de bestemming), wType (een identificatie) en iData (de informatie), alsook enkele optionele elementen vb lData : extra informatie of pData: pointer naar extra informatie. De programmeur kan berichten versturen die hij zelf definieert of die standaard al bestaan binnen PEG+. Die worden opgevangen in de switch-case structuur van het target-object. Aan de hand van een voorbeeld met standaardberichten wordt alles duidelijker:
Voorbeeld: Dit bericht wordt door de programmeur verstuurd.
Figuur 12: Bericht dat de programmeur verstuurt voor een Tab
Dit is een standaardbericht dat ervoor zorgt dat de button die de focus heeft, zijn focus verliest en een volgende button geselecteerd wordt. Analoog met de Tabfunctietoets van uw PC. De programmeur verzendt dit bericht op de gepaste plaats in zijn code en bij de PegButton klasse is code voorzien om het op te vangen (figuur 13).
13 Hanne Deschildre
Hoofdstuk 2: PEG+
Figuur 13: Code binnen PEG+ die het Tab bericht opvangt.
Elke klasse heeft een switch-case structuur waarin opgegeven wordt voor welke berichten het object van deze klasse zich interesseert. De klasse PegButton vermeldt in zijn switch-case dat hij bij de ontvangst van een PM_KEY message de bovenstaande code wil uitvoeren. Voor elk button object wordt in de buttonklasse deze case overlopen wanneer de button het bericht ontvangt. PegPresentationManager weet welke button focus heeft en wie zijn opvolger (next sibling) is. Op die manier kan hij eenvoudigweg de focus verleggen. Als programmeur moet dus geen code worden voorzien om het bericht op te vangen en dat maakt de standaardberichten zo aangenaam. Nog een aantal standaardberichten worden meegegeven in PEG+ bijlage 3. PEG+ bijlage 4 toont een bericht dat gebruikt kan worden bij het scrollen.
Keyboard input In veel systemen komen gelijkaardige functies voor, denk maar aan Tab, Enter, Escape,… Standaardberichten zijn ontworpen om dergelijke functionaliteiten op te vangen. Aangezien ze bij alle systemen dezelfde werking hebben zijn ze reeds aangemaakt in PEG+. De werking 14 Hanne Deschildre
Hoofdstuk 2: PEG+
ervan is steeds dezelfde en dit maakt het mogelijk voor de bibliotheek om de opvangcode zelf al te voorzien. Deze opvangcode is te vinden in de klasse PegButton. De programmeur zelf hoeft niet naar de code te kijken en kan de berichten zorgeloos verzenden. Een goede keuze van de key’s op uw device kan het programmeren hierdoor dus lichtjes vereenvoudigen.
Input Focus Tree De aandachtige lezer heeft wellicht gemerkt dat in het voorgaand voorbeeld onder Event Driven programming (figuur 12) geen pTarget wordt meegegeven aan het bericht. Toch kan de PresentationManager een oplossing verzekeren. Het pTarget-veld is geen verplicht veld doordat PEG+ met een focustree werkt. De focustree kan voorgesteld worden als een boomstructuur van objecten. Wanneer een object (e.g. een button) geselecteerd wordt, ontvangt hij de focus. Hierdoor krijgt de hele familie3 van dit object ook focus.Via de focustree kent de PegPresentationManager de familie van het object en weet dus wie hierdoor ook focus krijgt en hoe ze zich verhouden ten opzichte van elkaar (parent/ sibling/child). Binnen PEG+ zit een bottom up afhandeling van de berichten (figuur 14), dat wil zeggen dat wanneer een bericht niet afgehandeld wordt door een object, het automatisch naar zijn parent wordt gestuurd. Handelt die het niet af dan komt het bij de parent van deze laatste, enzovoort... De grand-grand-grand…-parent in dit geheel is altijd PegPresentationManager. Als het bericht tot bij hem raakt, dan wordt het verworpen. Standaardberichten worden altijd ergens binnenin verwerkt, zelfgedefinieerde berichten kunnen weleens tot boven bij de PegPresentationManager komen maar dat wil meestal zeggen dat de programmeur vergat om ze op te vangen.
Figuur 14: De bottom up afhandeling van berichten.
3
Met de familie van het object worden hier alle parents, siblings, children bedoeld. Op figuur 4 staan 2 dergelijke families voorgesteld: 2 windows met alle children. 15 Hanne Deschildre
Hoofdstuk 2: PEG+
c. PegMessageQueue Bij een gebeurtenis worden vaak meerdere berichten tegelijk verzonden (of met een relatief kleine vertraging tussenbeide). Om een goede afhandeling te garanderen is een PEG message queue voorzien.De PegMessageQueue is een FIFO-rij (First in First out) waarin de berichten terechtkomen voordat de presentation manager ze naar het juiste object verstuurt. d. PegScreen PegScreen vormt de verbindingslaag tussen het fysisch scherm en PEG+ (figuur 9). Dit element zorgt voor het effectief tekenen van alle objecten. Als programmeur heb je met dit element van PEG+ weinig te maken.
1.3 Tools Ter ondersteuning biedt SWELL software 3 tools aan. De Window Builder, de Font Capture en de Image Convert. 1.3.1
Window Builder
Aan de hand van deze tool kunnen alle visuele aspecten aangemaakt worden. De Window Builder genereert de constructor die bij het opgebouwd scherm hoort. De builder is heel handig wat betreft het visuele aspect en levert een houvast voor het programmeren van een constructor maar is niet genoeg om alle schermen voor deze masterproef te maken. Door de modulariteit, nodig bij de schermen van deze masterpoef, werd de Window Builder eerder als hulp gebruikt. Niet zozeer voor het programmeren zelf maar eerder bij de studie van de structuren, objecten en methoden die PEG+ hanteert. Door te bestuderen wat de Window Builder aflevert bij een voorbeeldscherm wordt duidelijk hoe eigen constructoren opgebouwd moeten worden. Aangezien het compileren en inladen veel tijd in beslag neemt is het handig om via de Window Builder een basisidee te hebben van hoe de lay-out opgebouwd wordt.
Figuur 15: Snapshot van de PEG Window Builder
16 Hanne Deschildre
Hoofdstuk 2: PEG+
De Window Builder genereert een header bestand en een cpp-bestand. Het cpp-bestand bevat de constructor en het geraamte voor de berichtafhandeling. Het header bestand wordt toegevoegd (include) door elke klasse die functies van deze klasse wil gebruiken of objecten ervan wenst aan te maken.
Figuur 16: De files die de Window Builder genereert
Onder het menu configure => directories => source worden paden opgegeven voor de .cpp en .hpp files. Die paden zijn relatief ten opzichte van de plaats waar het project staat. Het beste is om de originele files meteen op de juiste plaats te zetten in plaats van een kopie. Een update van de files is mogelijk en dan wordt het juiste bestand meteen aangepast. De constructoren veranderen tussen het begin van de constructor en de commentaarlijn /* WB End
17 Hanne Deschildre
Hoofdstuk 2: PEG+
Construction */. Bij een verandering van de message handler wordt niets verwijderd, nieuwe zaken worden wel toegevoegd. De String Table Een extra feature binnen PEG+ is de String Table. Oorspronkelijk werd gekozen om deze te implementeren maar daar werd later van afgestapt. De weergave van de tekst wordt nu anders opgelost. De stringtable wordt aangeboden om voor eenzelfde string, de tekst in verschillende talen aan te bieden. Elke string heeft een ID en via de ID wordt hij opgeroepen. Die ID kan dan wijzen naar verschillende woorden, al naargelang de taal en de ingestelde text bij de String Table Editor (figuur 18). In de applicatie kan een selectiescherm voorzien worden die er voor zorgt dat de tekst in de juiste taal verschijnt (de juiste woorden worden aan de ID gelinkt). Dit gebeurt via de functie: SetCurrentLanguage(iLanguage) waarbij iLanguage het taalnummer is. De instellingen om een String Table te gebruiken staan in figuur 17.
Figuur 17: Instellingen voor de String Table
Figuur 18: De String Table Editor
Oorspronkelijk werd de String Table geïmplementeerd omdat een gewone tekstweergave problemen geeft. Dit werd later verworpen en opgelost door met de functie AsciiToUnicode(PEGCHAR temp,”Text”) elke string in Unicode te plaatsen en te stockeren in een variabele temp. Dit houdt in dat we de extra .cpp en .hpp files voor de stringtable niet langer nodig hebben, wat toch een voordeel is. Een String Table maakt dus een taalselectie 18 Hanne Deschildre
Hoofdstuk 2: PEG+
mogelijk en dat was voor deze masterproef niet nodig. Aangezien de String Table niet gebruikt wordt, wordt er niet verder op in gegaan. Meer informatie hierover staat in de Programmers manual en de API van PEG+. 1.3.2
Image Convert
Wanneer figuren op de schermen worden geplaatst, is er een extra bestand nodig dat alle informatie levert om die figuur opnieuw op te bouwen. Aan de hand van de Image Convert tool kunnen we een dergelijke bestand voor de figuren genereren.
Figuur 19: Snapshot van de PEG Image Convert
Figuur 20: De code die de PEG Image Convert genereert
Binnen de Window Builder wordt de figuur toegevoegd en vervolgens naar het scherm gesleept.
19 Hanne Deschildre
Hoofdstuk 2: PEG+
1.3.3
Font Capture
Standaard zijn twee fonts aanwezig binnen PEG+ : SysFont en MenuFont. Als daarnaast nog opmaakmodellen voor tekst nodig zijn kunnen die gemaakt worden met behulp van de Font Capture tool.
Figuur 21: Snapshot van de PEG Font Capture tool
Figuur 22: De code die de PEG Font Capture genereert voor een nieuwe font
Dit bestand wordt in de Window Builder geïmporteerd en vervolgens gesleept op alle teksten die een dergelijke font wensen.
20 Hanne Deschildre
Hoofdstuk 2: PEG+
2. PEG+ toegepast op de Handheld 2.1 Schermstructuur Na een grondige studie van PEG+ moet beslist worden welke schermen per aangesloten toestel zichtbaar zijn. We moeten weten hoeveel schermen nodig zijn, welke soorten, hoe ze eruitzien en welke informatie ze weergeven. Om hier een duidelijk zicht op te krijgen worden de project ingenieurs geraadpleegd. Één ervan verduidelijkt wat hij verwacht voor Modbus devices, de ander doet hetzelfde maar dan voor CANopen. Aan de hand van twee toepassingen, gemaakt door PsiControl, leggen ze uit wat verwacht wordt. 2.1.1
CANopen schermstructuur
Om een idee te vormen van de informatie en schermen die nodig zijn voor CANopen werd de BSD (Bekaert SR Drive) gebruikt. Dit is een project, uitgewerkt voor bekaert, waarbij een SEC750 wordt gebruikt om SR motoren aan te sturen. Deze motoren doen dienst in een oprolmechanisme voor metaaldraden, waar ze in een constant-vermogen modus ingezet worden. De projectingenieur maakt een schets en geeft enkele elementen aan die de schermen zeker moeten weergeven. Dit zijn voornamelijk protocol specifieke elementen. Na overleg en enkele schermvoorstellen (zie PEG+ bijlage 5) ligt het idee vast en krijgen we een overzicht van CANopen schermen. Bemerk dat in dit hoofdstuk nog geen protocol specifieke elementen aan bod komen, in hoofdstuk 4 staat de rest van de uiteenzetting rond de keuze van CANopen schermen. Het CANopen selectiescherm: wenst de gebruiker een bus overzicht te zien of wil hij alle aangesloten CANopen devices in een bepaalde state plaatsen? De CANopen Busoverview: Dit scherm bevat alle aangesloten CANopen toestellen. Naast hun naam en adresnummer wordt nog wat extra informatie meegegeven. Het algemeen NMT-state scherm: Elk CANopen toestel kan in een bepaalde status gezet worden, meer informatie hierover in hoofdstuk 4: CANopen. Met dit scherm kunnen alle aangesloten toestellen in dezelfde state worden geplaatst. Onderaan wordt hun huidige state weergegeven.
21 Hanne Deschildre
Hoofdstuk 2: PEG+
Figuur 23: Begin van de schermstructuur voor de CANopen slaves (Standaard schermen)
Bij het bus overview scherm kan een toestel geselecteerd worden. Hierna komt men steeds terecht bij een CANopen slave specifiek scherm; een scherm dat specifieke informatie voor elke slave bevat. Hier wordt de state van deze slave uitgelezen en kan ze aangepast worden. Onderaan dit scherm kiest de gebruiker naar welk parameterscherm hij wenst te gaan door de overeenkomstige button te selecteren. In dit geval kunnen schermen worden gekozen specifiek voor CANopen, hun betekenis wordt in hoofdstuk 4 toegelicht.
22 Hanne Deschildre
Hoofdstuk 2: PEG+
CANopen slave specifieke schermen
Parameter schermen
Figuur 24: 2e deel van de schermstructuur (Applicatie specifieke schermen)
De schermstructuur moet modulair zijn voor elk aangesloten toestel. Daarom wordt gekozen om enkele schermen standaard te voorzien en een aantal andere volledig te laten bepalen door externen. Die zelf te bepalen schermen zijn uniek qua inhoud maar ook qua opbouw en layout. Het bepalen van de schermen gebeurt in een XML-bestand dat wordt meegegeven op een SD-kaart bij de HCD. Meer uitleg hierover in hoofdstuk 5. Er zijn 5 schermen:
- Het CANopen selectiescherm - De CANopen busoverview - Het algemeen NMT-state scherm - Het CANopen slave specifiek scherm - Het parameterscherm
1 per HCD 1 per aangesloten slave
23 Hanne Deschildre
Hoofdstuk 2: PEG+
Voor de eerste drie schermen is per HCD één aanwezig. Die drie zijn overkoepelend voor alle aangesloten CANopen slaves. Per slave is daarenboven één CANopen specifiek scherm en elke slave kan een onbepaald aantal parameterschermen hebben.
2.1.2
Modbus schermstructuur
Analoog als bij CANopen wordt een structuur voor Modbus uitgewerkt. Ook hier heel wat overleg met een projectingenieur die ervaring heeft met Modbus toestellen. Aan de hand van de Warner applicatie4 legt hij de vereisten uit. Dit resulteert in de volgende structuur.
Modbus slave specifieke schermen
Par. Scherm1
Par. Scherm2
Par. Scherm3
Figuur 25: De schermstructuur voor Modbus schermen
Ook hier is een Bus overview scherm. Door selectie van een slave komt de gebruiker op een Modbus specifiek scherm. Ook een Modbus toestel heeft states (zie hoofdstuk 3), vandaar een state scherm per slave. Onderaan de Modbus specifieke schermen kunnen Parameterschermen worden geselecteerd.
4
De Warner is een project waarbij 8 remmen aangestuurd worden. Elke rem heeft zijn eigen state machine 24
Hanne Deschildre
Hoofdstuk 2: PEG+
2.1.3
Applicatie specifieke schermen en standaardschermen
De schermen per protocol liggen nu vast. Maar waar haalt de HCD zijn informatie vandaan om ze op te bouwen? Enerzijds zijn er schermen die opgebouwd worden met standaardinformatie. Dit zijn gegevens die bij elke slave op dezelfde plaats te vinden zijn, voor modbus: vaste holding registers, voor CANopen vaste indexen en subindexen in de object dictionary 5 . Anderzijds worden er schermen opgebouwd met informatie die specifiek is per soort aangesloten toestel. De eerste groep zijn de standaardschermen, de tweede groep bestaat uit applicatie specifieke schermen. De standaardschermen zitten zowiezo in de HCD en komen slechts 1 maal voor. Applicatiespecifieke schermen zijn meer afhankelijk van het aantal en de soort van aangesloten toestellen. Ze zijn dan ook in meerdere mate aanwezig, de exacte hoeveelheid hangt af van het aantal slaves en de parameterschermen die per slave gedefinieerd worden. De standaardschermen Voor CANopen zijn dit de schermen van figuur 24. Bij de busoverview zien we de naam, het adres, de softwareversie en de hardwareversie van elk aangesloten CANopen toestel. Deze gegevens worden opgehaald op vaste plaatsen bij elk toestel. Het algemeen NMT-state scherm leest de state van elk toestel uit en stelt een nieuwe in wanneer de gebruiker een button indrukt. Voor elk CANopen toestel staat de state op een vaste plaats en veranderen van een state wordt bij allemaal analoog uitgevoerd. Voor elk CANopen toestel kunnen deze schermen opgemaakt worden zonder extra kennis over de aangesloten toestellen. Bij modbus is maar 1 standaardscherm aanwezig: de bus overview. Analoog als bij CANopen vindt de HCD de informatie voor de opbouw van dit scherm op een vaste plaats bij elke slave. De applicatie specifieke schermen Op de standaardschermen volgen de applicatie specifieke schermen. Hier is wel voorkennis van de aangesloten toestellen vereist. De HCD heeft een SD-kaart input wat de mogelijkheid biedt om extra informatie per slave te specifiëren6. Op figuur 18 zien we de CANopen slave specifieke schermen. Voor Modbus behoren de parameterschermen en Modbus slave specifieke schermen tot deze groep. Nog een laatste scherm werd niet vermeld: het informatiescherm. Per slave (zowel voor Modbus- als CANopen slaves) wordt op de SD-kaart informatie meegegeven voor een informatiescherm. Op elk moment in de boomstructuur van schermen kan dit informatiescherm opgeroepen worden zodat de gebruiker steeds weet met wie hij te maken heeft. Via de SD-kaart weet de HCD waar hij de informatie moet halen om het scherm op te bouwen.
5 6
Zie hoofdstuk 4: CANopen Zie hoofdstuk 5: XML- en software structuur 25
Hanne Deschildre
Hoofdstuk 2: PEG+
Figuur 26: Het informatiescherm
De structuur en layout van alle schermen ligt nu vast. Hoe enn waar de HCD zijn informatie precies haalt wordt duidelijk in hoofdstuk 3 en 4, waneer dieper ingegaan wordt op de protocollen.
2.1.4
Het resultaat: een boomstructuur van schermen
Stapsgewijs en na veel vragen worden enkele voorstellen op tafel gelegd. Door studie rond de protocollen en bespreking van de voorstellen worden de schermen verfijnd en op die manier zo algemeen mogelijk gemaakt. Het eindresultaat is een overzicht van alle mogelijke schermen waartussen de gebruiker switcht. De naamgeving is analoog aan de naam van de schermklasses.
Figuur 27:: Boomstructuur van schermen
26 Hanne Deschildre
Hoofdstuk 2: PEG+
Visueel wordt dit:
Standaard schermen
Figuur 28: Standaardschermen van de HCD Hanne Deschildre
Hoofdstuk 2: PEG+
27
Applicatie specifieke schermen
Par. Scherm1
Figuur 29: Applicatie specifieke schermen van de HCD
Hanne Deschildre
Hoofdstuk 2: PEG+
28
In de boomstructuur zien we nog 2 onbesproken schermen. Bij opstart verschijnt het start scherm en na 5 seconden verdwijnt dit om plaats te maken voor het protocolkeuze scherm. Op die manier is de boom vervolledigd. Om de handheld gebruiksvriendelijk te maken wordt voor veel analogie gezorgd. Zowel op visueel aspect als bij het gebruik. Visuele analogie -
Alle Modbusschermen zijn bordeaux gekleurd, alle CANopen schermen donkerblauw. De basislayout van alle schermen is gelijk: een titelbalk met een titel en enkele basisknoppen (als die van toepassing zijn op het scherm). Wanneer een selectie kan gemaakt worden op het scherm wordt een visuele “knop” gebruikt. Simpele tekst wordt nooit zo getoond. Bus overviews zien er gelijkaardig uit voor CANopen- en Modbus toestellen. Op het parameterscherm worden bepaalde waarden uitgelezen bij een slave, andere ingesteld. De uitgelezen waarden die niet in te stellen zijn krijgen een grijze achtergrond, de instelbare een witte. Dit naar analogie met veel computertoepassingen. Door de analoge vorm weet de gebruiker hoe het werkt.
Gebruiksanalogie -
-
Elk applicatie specifiek scherm bevat links boven een knop om het gegevensscherm van die slave op te roepen. Zodat de gebruiker op elk moment weet met “wie” hij bezig is. Elke slave heeft een state machine maar hier staat in hoofdstukken 3 en 4 meer te lezen. De HCD is voorzien van een display en 8 toetsen. Voor elke toets wordt een “standaard” functie bedacht zodat bij elk scherm de toetsen dezelfde werking hebben. Dit maakt de werking ervan eenvoudig voor de gebruiker.
4
7 6
2
5 1 0 3
Figuur 30: Toetsen van de HCD
Figuur 30 toont de aanwezige toetsen (key’s). Key 0: de selectietoets (“enter”) Key 1, 2, 3 en 4: pijltjes (rechts, links, onder en boven) Key 5: de tab-toets (selecteert het volgende element) Key 6: schakel het toestel uit Key 7: zet het toestel aan Hanne Deschildre
Hoofdstuk 2: PEG+
29
Wanneer meer dan 1 button op het scherm staat zijn de pijltjes- en tab-toetsen van toepassing. Als we het bus overzicht bekijken (het standaard scherm voor modbus: HcdModbusOverview), dan zien we dat op elke slave kan geklikt worden. Maar rechts boven is ook een button aanwezig om het vorige scherm terug op te roepen. Met Tab kan geswitcht worden tussen deze ene toets en de slaves. Met pijltjes toesten overloop je dan alle slaves om er uiteindelijk eentje van te selecteren. Voor elk scherm is deze werking gekozen omdat je op die manier snel de “terug” toets (rechts boven) van elk scherm kunt bereiken. Was deze methode niet gekozen, dan zou je alle slaves moeten overlopen vooraleer je kunt terugkeren naar een vorig scherm. In dit hoofdstuk worden nog geen protocol specifieke zaken uitgeklaard. Zo ook de inhoud van de schermen niet. Dit komt in hoofdstukken 3 en 4 aan bod na de studie rond Modbus en CANopen.
2.2
Praktisch: opbouw van de schermstructuur
Het bouwen van een dergelijke structuur is doenbaar wanneer je PEG+ goed kent. Maar het is toch altijd wat zoeken naar de juiste en efficiëntste methodes. De meegeleverde programmers manual en API zijn tamelijk volledig maar leggen niet altijd de zaken uit die nu net bij dit project nodig zijn. Voor de vorm en inhoud van de schermen wordt overlegd met projectingenieurs. Ze maken duidelijk wat protocol gebonden is en zeker moet te zien zijn op de schermen. Verder leggen ze uit welke device specifieke karakteristieken een Modbus of CANopen toestel kan hebben. Op die manier wordt een beeld gevormd van wat de project ingenieurs verwachten van de HCD. CANopen is relatief nieuw binnen PsiControl dus hier is het nog wat aftasten. Voor Modbus bestaat er al een duidelijker beeld en via een eerdere implementatie, de Warner applicatie, wordt een beeld gemaakt van wat de HCD in deze toepassing moet kunnen instellen of uitlezen. Stapsgewijs wordt uitgelegd hoe het project bij de HCD aangepakt werd.
2.2.1
Stap1: project bestuderen
In de beginfase van het HCD-project worden bestaande CANopen- en Modbus projecten bestudeerd om te weten welke informatie van de slaves kan komen en wat zinvol is om aan de gebruiker weer te geven. De protocol specifieke zaken die standaard aanwezig zijn bij elke slave worden dan in de schermstructuur verwerkt (denk maar aan de state-machines7). Dit gebeurt in nauw overleg met ingenieurs die meewerkten aan de voorbeeldprojecten. Na enkele voorstellen wordt een benaderende schets van figuren 28 en 29 bekomen.
7
Zie hoofdstuk 3 en 4 waar uitleg staat over state machines bij CANopen- en Modbus slaves.
Hanne Deschildre
Hoofdstuk 2: PEG+
30
2.2.2
Stap2: standaardschermen en applicatie specifieke schermen
Deze onderverdeling helpt bij het begrijpen van de structuur. De standaardschermen zijn altijd aanwezig en gelden voor alle slaves samen, applicatie specifieke schermen zijn enkel geldig voor de slave waarover ze informatie bieden. Onder punt 2.1.3 wordt het onderscheid tussen beide nauwkeurig uitgelegd. De onderverdeling helpt bij het programmeren door de analogie binnen de twee groepen. 2.2.3
Stap 3: schermen (Window Builder) en boomstructuur maken
Met de Window Builder kan je voor het programmeren al tekenen hoe het scherm er precies moet uitzien. Deze tool is dus niet alleen handig bij het maken van de constructor voor een schermklasse. Alle schermen worden samengebracht in een boomstructuur om het overzicht te bewaren (figuren 28 en 29). Binnen PsiControl is een algemene structuur voor de projecten. Het .wbp8 project en de foto’s plaatsen we op: C:\depot\software\uc_dsp_platform\product\2008\00818\main\peggen Voor de files die via de Window builder aangemaakt worden, worden de volgende paden opgegeven. -
2.2.4
Voor de source en include files (.cpp en .hpp): ..\..\..\..\..\source\app\2008\00818\main\common\peg_files De figuren op: ..\..\..\..\..\product\2008\00818\main\peggen
Stap 4: informatie opzoeken
Voor elk scherm is nu bepaald hoe het er moet uitzien en welke informatie getoond wordt. Nu moet nog uitgezocht worden waar de HCD die informatie haalt. Zowel de tekst als de lay-out moet ergens binnen de HCD vastgelegd worden (of de HCD moet weten waar hij de informatie haalt om de schermen at runtime op te bouwen). Mogelijkheden zijn:
8
-
Vast gecodeerde tekst weergeven (bvb. de tekst op het HcdProtocol scherm, figuur 37).
-
Informatie op vaste plaatsen bij de slave ophalen. De HCD weet waar de informatie zit bij de slave (in welk holding register bij een Modbus slave of in welke index bij de OD van een CANopen slave). Zaken zoals een busscanning gebeuren altijd op dezelfde manier en op de zelfde plaats in de code, de manier van ophalen staat dus vastgecodeerd bij de
.wbp is de extensie van een Window Builder project
Hanne Deschildre
Hoofdstuk 2: PEG+
31
HCD. (bvb. Voor de opbouw van HcdModbusOverview is een busscanning nodig, deze staat vastgecodeerd bij de HCD.) -
Informatie ophalen bij de slave, de manier van ophalen staat in het XML-bestand. Voor de parameterschermen staat alles vermeld in een XML-bestand. Dus de lay-out en alle informatie die verschijnt alsook de manier van ophalen. Ook de gegevensschermen en modbus/CANopen specifieke schermen staan in het XML-bestand.
Voor informatie die via protocolberichten opgehaald wordt, wordt in deze fase uitgezocht hoe dat gebeurd en waar de informatie te vinden is. Onder hoofdstuk 3 en 4 staat dit nader toegelicht.
2.2.5
Stap 5: scherm per scherm programmeren
Met behulp van de Window Builder is de structuur van het cpp en hpp bestand gegenereerd. De constructor en een switch-case structuur is aangemaakt. Doordat verschillende en verschillende soorten schermen aangesloten kunnen worden zal die constructor voor de meeste schermen waarschijnlijk sterk aangepast worden. We overlopen de schermen en letten bij elk scherm op specifieke eigenschappen. We overlopen 9 schermen:
a. HcdStartupScreen b. HcdProtocol c. HcdModbusOverview d. HcdCANopenScreen e. HcdCANopenOverview f. HcdNmtAllSlavesScreen g. HcdModbusSpecific h. HcdSlaveInfo i. HcdCANopenSpecific j. HcdParameterScreen
Standaard schermen
Applicatie specifieke schemen
a. HcdStartupScreen
Figuur 31: HcdStartupScreen
Hanne Deschildre
Hoofdstuk 2: PEG+
32
Dit scherm verschijnt bij opstart en na 5 seconden komt een object van de klasse HcdProtocol te voorschijn. Dit startscherm toont ons wat vastgecodeerde informatie en 2 figuren.
Oproep van dit scherm: Bij de Window Builder kan de mogelijkheid “startup window” aangevinkt worden (eerst rechtermuisklik op de modulenaam). Dit zorgt ervoor dat de functie PegAppInitialize (figuur 26) in de klasse wordt voorzien (naast een constructor en de message handler). Vanuit de main wordt deze functie opgeroepen en op die manier verschijnt het start scherm.
Figuur 32: De initialisatiefunctie voor het tonen van PEG+ schermen
De timer: Bij verschijning van het scherm ontvangt HcdStartupScreen een PM_SHOW bericht. Dit bericht wordt opgevangen in de message handler9 binnen HcdStartupscreen. Hier wordt een eerste timer gestart (figuur 33). Het duurt 5 seconden voor hij de eerste keer afloopt, de volgende meldingen gebeuren om de seconde. Telkens de timer afloopt wordt een PM_TIMER bericht naar het scherm gestuurd. In onze applicatie roepen we een volgend scherm op bij de eerste keer dat de timer afloopt (figuur 24). Samengevat: PM_SHOW: De timer wordt aangemaakt bij oproep van het scherm. PM_TIMER: De code die uitgevoerd wordt per timerpuls. PM_HIDE: De timer wordt stilgelegd.
Figuur 33: Start van de timer als het scherm verschijnt
9
Figuur 16 toont de inhoud van een cpp-file. De switch-case structuur vangt de berichten op voor het scherm in kwestie. Hanne Deschildre
Hoofdstuk 2: PEG+
33
Oproep van het volgend scherm: Wanneer de timer afloopt ontvangt het scherm een bericht PM_TIMER. Dit wordt opgevangen in de message handler. Op dat moment wordt het volgend scherm opgeroepen. Op dit moment wordt ook de timer gestopt.
Figuur 34: Oproep van een nieuw protocol scherm
Afsluiten van het scherm: Wanneer een nieuw scherm verschijnt wordt de melding naar HcdStartupScreen gezonden dat hij niet meer zichtbaar is: PM_HIDE. Bij deze melding wordt het scherm verwijderd (hide + destroy).
Figuur 35: Verwijderen van een scherm
De figuren: Op het scherm komen twee figuren te voorschijn. Zoals eerder vermeld moet de Image Convert hiervoor een cpp - bestand aanmaken met code die deze figuren voorstelt. Ze zijn allebei gedefinieerd in het bestand: HcdImage.cpp. In de constructor van HcdStartupScreen wordt de naam van de figuur gebruikt om te verwijzen naar deze code, vandaar een “extern” vermelding voor beide namen.
Figuur 36: Vermeldingen in HcdStartupScreen om de figuren op het scherm te plaatsen
Hanne Deschildre
Hoofdstuk 2: PEG+
34
b. HcdProtocol
Figuur 37: HcdProtocol
Dit scherm bevat enkel vastgecodeerde tekst en 2 buttons. Bij het drukken op de buttons verschijnt een nieuw scherm. De methode om dat nieuwe scherm op te roepen is analoog als bij figuur 34.
De scanning van buttons gebeurt als volgt: -
Bij elk scherm dat buttons afscant moet het prototype worden meegegeven (figuur 38). De functie wordt in de library (817) gedefinieerd en kan met deze declaratie probleemloos gebruikt worden. Bemerk de vermelding “C”, het is immers een Cfunctie die in C++ opgeroepen wordt en dan ook door een C++ compiler verwerkt wordt.
Figuur 38: Prototype voor de key-scan-functie
-
Een timer wordt geïnitialiseerd bij de weergave van het scherm.
Figuur 39: Initialisatie van de timer voor key scanning
-
Per timer puls (PM_TIMER) wordt gecontroleerd of de key ingedrukt is. De controle van key0 gebeurt in figuur 40. De extra variabele key_flag0 dient om te voorkomen dat de code meer dan één maal uitgevoerd wordt. Er wordt een soort rising edge detectie gemaakt. De functie levert true wanneer key0 ingedrukt wordt, dan komen we in de else. Staat de vlag op false, dan betekent dit een eerste doortocht door de structuur. De code wordt uitgevoerd en de vlag op true gezet. De functie wordt slechts één maal doorlopen doordat de vlag nu op true staat.
Hanne Deschildre
Hoofdstuk 2: PEG+
35
Figuur 40: Key scanning code
Naargelang key 5 of 0 ingedrukt wordt hebben we een specifieke werking. Key 0 is de selectie toets, bij key 5 wordt een tab uitgelokt. In beide gevallen wordt op dat moment een bericht verzonden om te laten weten wat er moet gebeuren bij het indrukken van de key’s (figuur 41 en 42). Dit bericht wordt bij PEG+ intern opgevangen in de klasse pButton.cpp, daar staat een message handler die de functie vervult.
Figuur 41: Berichten die verzonden worden bij de “enter”-functie
Figuur 42: Berichten die verzonden worden bij een “tab”-functie.
Hanne Deschildre
Hoofdstuk 2: PEG+
36
Bij figuren 41 en 42 bemerken we het volgende: -
-
Twee berichten zijn nodig in beide gevallen. Één om de Selectie te doen, een tweede om de selectie op te heffen. Bij de enter-key kan dit vertaald worden naar het indrukken van de knop en die vervolgens terug loslaten. In beide gevallen wordt lData op 0 geplaatst. Als dit niet gebeurt dan worden willekeurige waardes meegegeven, wat tot een onverwachte werking kan leiden. Wanneer een tab in tegengestelde richting nodig is, wordt lData = KF_SHIFT.
c. HcdModbusOverview
Figuur 43: HcdModbusOverview
Om dit scherm op te bouwen, worden vast gecodeerde waarden gebruikt, in volgende stappen halen we de informatie op bij de slaves via Modbus berichten. Het scherm wordt opgemaakt met de Window Builder maar de constructor wordt sterk aangepast en modulair gemaakt; vooraf weet men immers niet hoeveel slaves aan de HCD zullen geschakeld worden. Hier verschijnt voor het eerst de button rechts boven. Met deze button wordt het vorig scherm opgeroepen. We maken geen nieuw object van het vorig scherm aan, daarom moet een include van de vorige klasse voorzien zijn alsook een “extern” prototype van de object initialisatie:
Figuur 44: Nodige declaraties om het protocolScreen opnieuw op te roepen
Figuur 45: De oproep van het vorig scherm: ProtocolScreen
Hanne Deschildre
Hoofdstuk 2: PEG+
37
Omdat het aantal slaves sterk kan verschillen is het moeilijk om bij het houden welke button nu geselecteerd is (de tab-functie wordt gebruikt en het scherm ziet de slave buttons niet als uniek). Daarom wordt softwarematig bijgehouden welke slave button (Warner, Warner-2 of Warner-3 op figuur 43) nu geselecteerd is. We nemen een static variabele zodat de waarde behouden blijft wanneer we de klasse verlaten.
d. HcdCANopenScreen
Figuur 46: HcdCANopenScreen
Deze schermklasse is analoog als HcdProtocol. e. HcdCANopenOverview
Figuur 47: HcdCANopenOverview
De informatie op dit scherm wordt voorlopig vast gecodeerd. Wanneer de CANopen software geïmplementeerd wordt kunnen de vast gecodeerde waarden vervangen worden.
Hanne Deschildre
Hoofdstuk 2: PEG+
38
f. HcdNmtAllSlavesScreen
Figuur 48: HcdNmtAllSlavesScreen
De inhoud van dit scherm wordt in hoofdstuk 4 toegelicht. Enkel de uitgelezen states zijn veranderlijk en bij latere implementatie van CANopen kunnen de states van de slaves ,via de Timer in PEG+, periodisch opgevraagd worden. De knoppen bovenaan zetten alle slaves in een bepaalde state. De CANopen berichten die hiervoor verstuurd moeten worden kunnen bij de HCD via een loop vast geprogrammeerd worden.
g. HcdModbusSpecific
Figuur 49: HcdModbusSpecific
Hanne Deschildre
Hoofdstuk 2: PEG+
39
Dit scherm is uniek per slave. Er wordt een overzicht gegeven van alle subdevices die de slave bevat. Bij de Warner applicatie zijn 8 subdevices (remmen) aanwezig. Op dit scherm kunnen ze ingesteld worden in 3 states en het scherm kan nog 3 andere parameterschermen oproepen. Het scherm wordt opgebouwd aan de hand van het XML-bestand die per slave meegegeven wordt (zie hoofdstuk 5). We zien voor het eerst de knop links boven. Voor de applicatie specifieke schermen kan op elk moment gecontroleerd worden met welke slave de gebruiker bezig is.
h. HcdSlaveInfo
Figuur 50: HcdSlaveInfo
De gegevens op dit scherm staan gedefinieerd in het XML-bestand (hoofdstuk 5). Er verschijnt standaard informatie of er worden zaken uitgelezen bij de slave. Het enige wat de gebruiker kan doen is OK selecteren zodat het vorige scherm terugkomt.
i. HcdCANopenSpecific
Figuur 51: HcdCANopenSpecific
Hanne Deschildre
Hoofdstuk 2: PEG+
40
Dit applicatie specifiek scherm toont de state van de slave en die kan door de gebruiker aangepast worden. De onderste buttons leiden naar parameterschermen. De werking van dit geheel wordt duidelijk in hoofdstuk 4 en 5. Bovenaan links zien we opnieuw de button naar het gegevensscherm. Rechts boven laat een terugkeer naar het vorig scherm toe (HcdCANopenOverview) en een selectie van de buurslaves.
j. HcdParameterScreen
Figuur 52: HcdParameterScreen
Dit is het meest modulaire scherm. Dit scherm wordt volledig beschreven in het XMLbestand. Voor Modbus ziet het scherm er hetzelfde uit, alleen de achtergrond is dan bordeaux in plaats van blauw.
2.2.6
Stap 6: informatie ophalen bij het XML-bestand
In de vorige stap werd alles geprogrammeerd met vastgecodeerde waarden (al dan niet in een array). Nu wordt alle nodige XML-informatie opgehaald bij het juiste XML-bestand en ingevuld in de code in plaats van de vastgecodeerde waarden.
2.2.7
Stap 7: alle protocolfuncties implementeren
Het laatste wat opgehaald moet worden is slave informatie via Modbus- of CANopen berichten. Ook deze vastgecodeerde waarden worden vervangen. Verdere uitleg hierover in hoofdstuk 3 en 4
Hanne Deschildre
Hoofdstuk 2: PEG+
41
Hoofdstuk 3: Modbus 1. Geschiedenis van de Modbus interface Modbus is een open serieel communicatieprotocol dat in 1979 ontwikkeld werd voor gebruik met PLC’s. Nu wordt het wijd gebruikt voor de connectie tussen verscheidene industriële elektronische toestellen. De fysieke layer voor dit protocol is vrij te kiezen. Het protocol werd meteen door veel producenten geaccepteerd en gebruikt omdat het opensource is. Het maakt gebruik van een simpele berichtenstructuur (request/reply) wat de implementatie ervan vergemakkelijkt t.o.v. andere protocollen. Dit voordeel en het feit dat er weinig beperkingen voor vermeld zijn maakt het gebruik ervan aantrekkelijk. Alle specificaties omtrent het protocol zijn terug te vinden in een naslagwerk: MODBUS Application Protocol Specifications V1.1b Modbus- IDA. In het begin werd Modbus voornamelijk gebruikt op bedrade seriële communicatielijnen maar er zijn ook uitbreidingen op de standaard voor draadloze communicatie en TCP/IP netwerken. In de opstelling communiceert de HCD met de modbus slave via RS485.
2. Modbus protocol principe 2.1 Protocol omschrijving Modbus is een berichtenprotocol voor de applicatielaag. Het zorgt voor client/server communicatie tussen toestellen, geconnecteerd op verschillende types bussen of netwerken. Het protocol omschrijft een simpele protocol data unit (PDU) die onafhankelijk is van de onderliggende lagen. Op de Application data unit (ADU) worden extra velden voorzien voor de mapping van modbus op de specifieke bussen.
Figuur 53: Modbus bericht
Hanne Deschildre
Hoofdstuk 3: Modbus
42
De modbus ADU wordt opgesteld door de client die de transactie opstart. De Adressering in de berichtkop wordt gebruikt om te definiëren welk apparaat moet reageren op de melding. Alle andere knooppunten in het Modbus netwerk negeren het bericht als het adresveld niet overeenkomt met hun eigen adres. De functie code vertelt de server welk soort actie uitgevoerd moet worden. Functie code 0 wordt niet gebruikt, 1 tot 255 zijn wel geldig (het bereik 128-255 is gereserveerd voor “exceptions”). Het dataveld bevat alle informatie die de server nodig heeft voor een goede respons op het bericht. Dit omvat holding register adressen, het aantal te behandelen items, het aantal databytes,… Het veld kan echter ook overbodig zijn. De client zendt zijn request naar de server en, als geen fouten optreden, antwoordt die met een bericht met dezelfde functie code als de aanvraag. Het bericht bevat de gevraagde data. Wanneer de communicatie misloopt bevat het dataveld een “exeption” code die de server applicatie gebruikt om zijn volgende actie te bepalen. De exception functie code van het antwoord kenmerkt de functie code van de oorspronkelijke aanvraag.
Client Initialiseer aanvraag
Server
Functie code | Data aanvraag
Voer de actie uit Initialiseer een antwoord Functie code | Data antwoord
Ontvang het antwoord Figuur 54: Foutvrije Modbus transactie
Client Initialiseer aanvraag
Server
Functie code | Data aanvraag
Detecteer een fout Initialiseer een foutmelding
Ontvang het antwoord
Exception Functie code | Exception code
Figuur 55: Modbus transactie die foutloopt
Hanne Deschildre
Hoofdstuk 3: Modbus
43
Het is aangewezen om een time out te voorzien zodat niet oneindig wordt gewacht op een bericht dat misschien nooit toekomt. Er zijn dus 3 PDU’s: -
Request PDU = {1byte function code, n bytes request data} Response PDU = {1byte function code10, n bytes response data} Exception response PDU = {1 byte exception function = function code1 + 0x80, 1byte exception code}
De antwoordmogelijkheden op een request: -
-
De request wordt niet ontvangen door de server. Bij de client valt een time out. De request wordt ontvangen maar er is een communicatiefout aanwezig (pariteit, crc,…). Nu wordt geen antwoord gegenereerd en opnieuw valt een time out voor bij de client. De Response PDU wordt door de server verstuurd (bij goede communicatie). De server ontvangt een request zonder communicatiefout maar kan het niet afhandelen. Er wordt een exception response gegenereerd en teruggezonden. Dit antwoord legt uit waar het probleem ligt.
2.2 Modbus adressering De eerste informatie in een Modbus request bericht is het adres van de ontvanger. Het adres is 1 byte groot en de adressen 1 tot 247 mogen gebruikt worden. De server antwoordt hierop met een bericht met zelfde Modbus adres. Zo ziet de master dat de slave op zijn verzoek antwoordt. De HCD (master) kan Coils (uitgangen), discrete inputs, input registers en holding registers van de slaves bereiken. Tabellen
Objec type
Type
commentaar
Discrete inputs
1 bit
Read-only
Uitgangen (coils)
1 bit
Read/write
Input registers
16 bit woord
Read-only
Holding registers
16 bit woord
Read/write
Dit soort data kan geleverd worden door een I/0 systeem. Dit soort data kan gewijzigd worden door het applicatie programma. Dit soort data kan geleverd worden door een I/O systeem Dit soort data kan gewijzigd worden door het applicatie programma.
Figuur 56: De tabellen bij Modbus adressering
10
Dit is dezelfde functie code als bij de request PDU
Hanne Deschildre
Hoofdstuk 3: Modbus
44
Het Modbus applicatie protocol definieert de PDU adresseringsregels. In een Modbus PDU wordt alle data geadresseerd van 0 tot 65535. Er wordt een Modbus data model gedefinieerd bestaande uit 4 blokken die elementen bevatten. Binnen elke blok worden de elementen genummerd van 1 tot n. Daarna moeten de Modbus data blokken gelinkt worden aan de applicatie. De mapping van het Modbus data model in de toestelapplicatie is volledig fabrikant-specifiek. Het gebeurt vaak dat de tabellen overlappen in het geheugen. De figuur toont de werking van het model. Er wordt een bericht gezonden om bijvoorbeeld de eerste discrete input te lezen. De PDU om discrete inputs te lezen wordt opgesteld en waarde 0 wordt meegegeven. Waar de discrete inputs in het geheugen van de slave staan is volledig applicatie afhankelijk, enkel de toegang via PDU’s moet analoog zijn bij alle slaves en daarom ligt het protocolsgewijs vast. Hier staan de 4 blokken apart in het geheugen, voor sommige toestellen kunnen ze overlappen, al naargelang de keuze van de programmeur.
Figuur 57: Het Modbus adresseringsmodel
Hanne Deschildre
Hoofdstuk 3: Modbus
45
2.3 Modbus functie codes Een functie code geeft aan wat van de ontvanger verwacht wordt en hoe de data van het bericht eruit ziet. Er zijn publieke en user defined functie codes:
Publieke functie codes User defined functie codes Publieke functie codes User defined functie codes Publieke functie codes
127 110 100 72 65
1 Figuur 58: Modbus functie code categorieën
Enkele algemene Modbus functie codes: -
01: Lees de coil status 02: Lees discrete input 03: Lees de holding registers 04: Lees de input registers 05: Schrijf de coil 06: Schrijf enkel register 07: Lees uitzonderingsstatus (exception) 15: Schrijf meerdere coils 16: Schrijf meerdere registers 17: Rapporteer de slave ID
Als voorbeeld tonen we functie code 01: Lees coil status: Wanneer een discrete uitgangswaarde moet uitgelezen worden, wordt een PDU met deze functie code verzonden. Met zo’n PDU is het slechts mogelijk om één slave tegelijkertijd uit te vragen. De functie kan worden gebruikt om meerdere opeenvolgende uitgangen tegelijkertijd op te vragen. Het adres en het aantal coils wordt meegegeven met de aanvraag:
Figuur 59: Aanvraag met functie code 01: lees coil status
Hanne Deschildre
Hoofdstuk 3: Modbus
46
Bemerk dat bijvoorbeeld coils 1 tot 16 geadresseerd worden als 0 tot 15. Het antwoord wordt teruggestuurd met zelfde functie code, een nummer N dat aangeeft hoeveel bytes gevuld zijn met coil statussen en daarna de effectieve statussen. N is het aantal coils gedeeld door 8, als de rest verschild van 0 wordt N+1 genomen. Wanneer het aantal uitgelezen coils geen veelvoud van 8 is dan worden de overige plaatsen gevuld met 0.
Figuur 60: Antwoord op een “lees coil” aanvraag
Treedt een fout op, dan wordt een exception PDU voorzien. De MSB11 van de functie code wordt hoog gezet en de meegegeven exception code hangt af van de fout die voorvalt.
Figuur 61: Foutmelding bij een “lees coil” aanvraag
Stel, de master wil coils 20 tot 38 opvragen. De berichten bij een goede transfer zien er als volgt uit:
De status van de uitgangen 27-20 worden gegeven door CDhex (1100 1101 binair). De data bytes van het antwoord geven per byte de status van de coils mee, van hoogst coil adres naar laagst. De laatste byte is 05 hex (0000 0101). Hierin stelt de 6e bit in de rij coil 38 voor, de laatste is coil 36 en de rest wordt opgevuld met nullen. Op die manier is de volledige communicatie via een “lees coil” aanvraag volledig uitgelegd. De rest van de functie codes worden nader toegelicht in de specificeren van het Modbus protocol (Modbus Application Protocol V1.1b).
11
Most significant bit = de meest beduidende bit
Hanne Deschildre
Hoofdstuk 3: Modbus
47
2.4 Modbus error codes
Wanneer een Modbus slave een verzoek beantwoordt gebruikt hij dezelfde functiecode als bij het verzoek. Wanneer er echter een fout optreedt wordt de hoogste bit van de functiecode aangezet, op die manier kan de master snel zien of de transfer gelukt is. Modbus bijlage 2 toont een overzicht van de foutcodes. De volgende figuur toont de plaatsen waar enkele van deze foutcodes kunnen optreden.
Figuur 62: Modbus transactie state diagram
Hanne Deschildre
Hoofdstuk 3: Modbus
48
3. Modbus toegepast op de Handheld 3.1 Modbus files Modbus werd al toegepast op enkele applicaties binnen PsiControl en de nodige software was al voorzien. De files werden nog nooit gebruikt in samenwerking met een besturingssysteem, wat bij de HCD wel aanwezig is. Wim Sampers, master student in de industriële wetenschappen optie automatisering, had dezelfde processor en dezelfde files nodig en overbrugde de problemen, een diepere uiteenzetting hiervan staat te lezen in zijn masterproef; Software bib voor de MODBUS® communicatie tussen SoftPLC en OXI™. Om modbus te kunnen gebruiken moeten de volgende files worden toegevoegd aan het project: -
StdAlModbusM.c en StdAlModbusM.h StdDllModbus.c en StdDll.h StdNlModbusMaster.c en StdNlMaster.h
-
DrvTmrTick.c en DrvTmrTick.h
-
DrvSci.c en DrvSci.h
-
StdTask.c en StdTask.h
In appMain.c moeten de juiste functies opgeroepen worden om deze modules op te starten. In AppConfig.h moeten de juiste #defines toegevoegd worden. Ook de juiste baudrate moet ingesteld staan. Bemerk dat al deze files toegevoegd worden aan de 817 wat de bibliotheek voorstelt voor de applicatie in de 818. In de PEG+ applicatie worden op de juiste momenten de Modbus berichten verzonden en opgevangen maar verder is er geen opbouw van Modbus functionaliteit binnen de 818. Het programma start vanaf de main waarbinnen AppMainInitAllObjects() opgeroepen wordt. In deze functie gebeuren dan ook de Modbus initialisaties:
Figuur 63: Initialisaties voor Modbus
Hanne Deschildre
Hoofdstuk 3: Modbus
49
3.2 Werking van de bestaande software Om de communicatie voor de HCD op poten te zetten, moet de werking van de software duidelijk zijn. Hiervoor moet even stilgestaan worden bij de “hooks”. Hooks Bij Modbus wordt een bericht verzonden naar de slave. Na een tijdje komt de respons terug en moet een actie ondernomen worden. De software lost dit op door een functie op te roepen bij ontvangst van een bericht met bepaalde functie code. Bij initialisatie wordt gezegd welke functie opgeroepen moet worden. De main roept een functie op die alle initialisaties in orde brengt: AppMainInitAllObjects(). In die functie gebeurt een eerste initialisatie waarbij alle hooks op 0 geplaatst worden aan de hand van de functie StdAlModbusInit. Daarna wordt, bij elke hook die de applicatie gebruikt, een functie toegekend die opgeroepen moet worden bij ontvangst van een antwoord op een dergelijke vraag. Bvb.:
Figuur 64: Initialisatie van een hook
De client (hier de HCD) zendt een vraag naar een bepaalde slave om een holding register te lezen. Wanneer het antwoord ontvangen wordt, wordt de AppModbusHcdReadHoldReg functie opgeroepen en handelt de HCD de code af. Zonder initialisatie weet de HCD niet welke functie opgeroepen moet worden wanneer het antwoord toekomt. Handig om weten is dat je de functie mag plaatsen waar je wil, het AppMain-bestand heeft enkel een prototype nodig:
Figuur 65: Prototype van de opvangfunctie voor een Modbusbericht
Om nu een modbus bericht te verzenden moet op de juiste plaats in de applicatie het volgende gebeuren.
Figuur 66: Verzenden van een Modbus toestel identificatie aanvraag
De applicatie vraagt aan de slave wat zijn ID is. Bij ontvangst van het antwoord komt de applicatie automatisch in AppModbusHcdReadHoldReg, waar die ook staat. Hanne Deschildre
Hoofdstuk 3: Modbus
50
Normaalgezien bieden onderliggende lagen hun software aan, aan de laag erboven. Hier kan nu een laag, door middel van een hook, een functie oproepen van een bovenliggende laag. Die functie kan ingevuld worden in de applicatielaag.
3.3 Modbus software voor de schermen Om een scherm op te bouwen moet informatie opgehaald worden bij de slaves. Vanuit de applicatiesoftware moet hiervoor dan ook op het goede moment een Modbus bericht worden verzonden. Per scherm wordt verklaard wat gebeurd op gebied van communicatie. Naast de oproepen zijn nog 2 extra files voorzien: AppModbusHcd.c en AppModbusHcd.h
HcdStartupScreen: Bij opstart van de HCD moet een busscanning gebeuren. Als eerste wordt de opstart klasse opgeroepen daarom beginnen we hier met de scanning (figuur 67). Een eerste bericht wordt verstuurd om de ID van het toestel op adres 1 te weten te komen. De request_index wordt op 1 geplaatst, zo weten we steeds welk soort bericht afgehandeld wordt. Bij ontvangst van een antwoord wordt de functie AppModbusHcdDeviceId opgeroepen (figuur 68) die op zijn beurt een volgende slave ID oproept. De ontvangen informatie wordt opgeslaan in de slave objecten die meteen ook aangemaakt worden bij ontvangst van een antwoord per slave (figuur 69). Dit systeem onderhoudt zichzelf tot een slave niet reageert (omdat die niet aanwezig is) en een time out voorvalt (figuur 70). De request_index onthoudt welk bericht laatst verzonden is zo is geweten bij welk bericht de time out voorvalt. Op dat moment is de busscanning gedaan en wordt een boolean geset voor latere controle (figuur 71).
Figuur 67: De busscanning start met de verzending van een bericht naar de eerste slave
Figuur 68: Functie die wordt opgeroepen bij ontvangst van het antwoord op de ID request
Hanne Deschildre
Hoofdstuk 3: Modbus
51
Figuur 69: Aanmaak van een object per slave dat alle informatie omtrent de slave vasthoudt
Figuur 70: Functie, opgeroepen bij een time out
Figuur 71: Functie, opgeroepen als busscanning beëindigd wordt
Hanne Deschildre
Hoofdstuk 3: Modbus
52
Opmerking: Bij deze busscanning volgen alle aangesloten devices elkaar op d.m.v. van hun adres. Als er een tussenliggend adres ontbreekt, valt een time out voor en stopt de scanning. Hierbij worden dus de adressen, die na het ontbrekend adres liggen, vergeten. Dit probleem kan opgelost worden door de busscanning op een time out niet te stoppen. Dan worden alle mogelijke adressen overlopen en gebeurt de busscanning altijd volledig. Wenst de programmeur toch niet altijd alles te overlopen dan kan hij het aantal time out’s bij de scanning bijhouden en na een ongewenst aantal de scanning toch te stoppen.
HcdProtocol Vanuit het protocolkeuze scherm wordt het Modbus busoverzicht opgeroepen. Hiervoor moet de busscan afgelopen zijn. Bij oproep van het overzichtscherm wordt gecontroleerd of de busscan_done bit true is, als dat het geval is wordt het busoverzicht opgeroepen. Als de busscan nog niet gedaan is wordt een timer gestart en bij elke puls van de timer, die om de halve seconde afloopt, wordt gecontroleerd of de busscan voorbij is. Door de tijd die de gebruiker nodig heeft om alle schermen te overlopen en de 5 seconden van het opstartscherm zal de scan waarschijnlijk al lang voorbij zijn, toch wordt er op die manier een beveiliging ingebouwd. Als de timer nodig was en die merkt dat de busscan nu wel in orde is, stopt hij zichzelf en hij roept hij het busoverzicht op.
HcdModbusOverview Wanneer in het protocolscherm gekozen werd voor Modbus, wordt een overzicht weergegeven van alle slaves op de bus. Hun adres, naam en softwareversie wordt weergegeven. Deze gegevens werden al eerder opgeroepen en staan gestockeerd in een structuur van attributen per slave (objecten van HcdSlave, deze klasse komt straks aan bod). Bemerk dat de naam van een slave wordt weergegeven als code. Een hardgecodeerde omzetting zorgt ervoor dat de code aan een naam gelinkt wordt, zodat deze naam weergegeven wordt op het scherm in plaats van de code. Later kan een extra bestand op de SD-kaart worden voorzien die een code verbindt met zijn respectievelijke slave naam. Het moet een apart bestand zijn omdat de HCD op dit moment nog geen specifieke slave bestanden uitgelezen heeft.
Hanne Deschildre
Hoofdstuk 3: Modbus
53
HcdSlave Voor elke slave haalt de HCD informatie op. Enerzijds zijn dit gegevens die de slaves bewaren op een vaste plaats en anderzijds specifieke zaken die opgehaald worden met behulp van een XML-bestand. Al deze gegevens moeten bijgehouden worden in een structuur en daarom wordt de klasse HcdSlave geïntroduceerd. Deze basisklasse bevat enkel attributen. Bij de busscanning wordt per slave een object van de klasse aangemaakt en toegevoegd aan een slave array. Figuur 69 toont de aanmaak van een object telkens een nieuwe slave wordt ontdekt bij de busscanning. Bemerk hierbij dat de attributen pointers zijn. Wanneer een gegevenswaarde wordt ingevuld zal een nieuw stukje geheugen worden gereserveerd met het keyword “new” en zal de pointer naar deze nieuwe, ingevulde, geheugenplaats wijzen. Dit keyword is dus belangrijk om ervoor te zorgen dat de gegevens later, in de loop van het programma, niet worden overschreven. De objecten die aangemaakt worden, staan in een array. Bij elk scherm wordt de array meegegeven zodat de schermen alle gegevens van de slaves kunnen gebruiken voor hun opbouw en werking. De structuur (met heel wat substructuren en array’s) zorgt ervoor dat alle gegevens bijgehouden worden en toegankelijk zijn. De volgende figuur toont een onderdeel van de gegevensklasse HcdSlave:
Figuur 72: Deel van de structuur binnen HcdSlave
Hanne Deschildre
Hoofdstuk 3: Modbus
54
HcdModbusSpecific Wanneer een slave geselecteerd wordt op het busoverzicht, wordt gekeken op de SD-kaart of er een bestand aanwezig is dat genoemd is naar de softwareversie van de slave in kwestie. Als dit niet het geval is zal de selectie geen gevolgen hebben. Wanneer de programmeur echter een bestand voorziet zal het uitgelezen worden. Standaard informatie wordt opgeslagen in de structuur en een eerste slave specifiek scherm wordt getoond. Alle elementen die weergegeven worden, worden opgehaald doordat binnen het XML-bestand informatie op de slave ter beschikking wordt gesteld. Figuur 49 toont alle gegevens die worden weergegeven op dit scherm. De state van elk subdevice wordt periodisch opgevraagd (om de halve seconde) via de functie StdAlModbusMReadHoldReg. Hiervoor wordt een tweede timer gestart (naast de timer die buttons afscant). Het antwoord op deze leesactie wordt opgevangen binnen HcdModbus. Via de request_index weet de HCD wat hij moet uitvoeren bij deze leesactie. Concreet wordt dan de state waarde van de subdevices geüpdate voor de objecten van HcdSlave en daarna wordt de tekst in de tekstboxen vervangen. Voor deze laatste actie moet de pointer naar elke tekstbox gekend zijn. Vandaar dat bij constructie ervan, een array is opgesteld met pointers naar de respectievelijke tekstboxen.
Bij selectie van een state button worden de nodige holding registers beschreven met de state waarde. Aangezien de holding registers voor het beïnvloeden van de state van alle subdevices na elkaar staan kan dit simultaan gebeuren met behulp van de functie: StdAlModbusMWrMultHoldReg.
HcdParameterScreen en HcdSlaveInfo Deze schermen zijn nog niet geprogrammeerd, het concept ligt wel al volledig vast. Voor het informatiescherm wordt een luik voorzien binnen het XML-bestand. Dit scherm moet 3 zaken kunnen: Modbus identificatie gegevens weergeven (geen communicatie voor nodig aangezien deze gegevens al opgehaald werden bij busscanning) - Tekst weergeven die meegegeven wordt in de XML-file - Holding registers uitlezen De communicatie bij dit scherm is dus vrij beperkt. -
Het parameterscherm is wat complexer. Hier moeten voorzieningen gebeuren voor inlezen en instellen van holding registers. Naast de constructor zal nu ook de message handler van deze klasse heel modulair zijn, ook op gebied van communicatie.
Hanne Deschildre
Hoofdstuk 3: Modbus
55
Hoofdstuk 4: CANopen 1. CANopen studie 1.1 Inleiding Voor veel ingebedde netwerk applicaties wordt CAN, het Control Area Network, geïmplementeerd omdat de CAN interface aanwezig is op microcontrollers van meer dan 25 verschillende chip fabrikanten. Maar CAN is op zich niet genoeg om een communicatienetwerk te implementeren. Een hoger-laags protocol is nodig om de voorgedefinieerde communicatiefuncties in te vullen. De juiste identificaties moeten voor de berichten voorzien zijn zodat elk bericht de juiste prioriteit krijgt. CANopen is een CANgebaseerd protocol dat deze applicatielaag voorziet. Via standaarden, vastgelegd door de CiA groep12, is de CANopen werking voor een toestel bepaald. De standaarden staan vermeld als “CiA DS xxx” en zijn vrij te implementeren, vandaar ook het succes. CANopen is mooi afgelijnd en zeer flexibel; er wordt nog steeds aan gewerkt om het protocol zo wijd mogelijk uit te diepen aan de hand van nieuwe standaarden. Gestandaardiseerde CANopen toestellen en applicatieprofielen vereenvoudigen de taak om een CANopen systeem te integreren. “Off-the-shelf” toestellen, tools en protocol stacks zijn wijd beschikbaar aan doenbare prijzen. Voor systeemontwerpers is het belangrijk om applicatiesoftware te kunnen hergebruiken. Dit betekent niet alleen communicatie compatibiliteit, maar ook gebruiksanalogie. Gestandaardiseerde interfaces zorgen voor een “plug and play” implementatie van CANopen toestellen in een CANopen netwerk. Niettegenstaande al deze afspraken laat CANopen een implementatie van fabrikant-specifieke functionaliteit toe. De standaard bereikt een grote markt en wordt als maar populairder. Voordelen en mogelijkheden van CANopen: CANopen - is gestandaardiseerd (EN50325-4), open en toegankelijk voor elke fabrikant - ondersteunt de werking van een uitgebreid gamma aan toestellen. - biedt hoge snelheids real-time mogelijkheden. - is ideaal voor complexe toestellen. - is gebruiksvriendelijk en er bestaan verscheidene ondersteunende tools of stacks - maakt een eenvoudig toegang naar alle toestelparameters mogelijk. - biedt synchronisatie tussen de toestellen. - biedt cyclische en event-driven data overdracht. - biedt synchrone uitlezing of instelling van inputs, outputs en parameters. 12
De internationale gebruikers en fabrikanten groep, gesticht in 1992 promoot CAN en ondersteunt CAN-gebaseerde hogerlaagse protocollen (www.can-cia.org).
Hanne Deschildre
Hoofdstuk 4: CANopen
56
In de software moet rekening gehouden met volgende zaken: de communicatieobjecten voor real-time data verkeer (PDO’s), configuratie data objecten (SDO’s), speciale functies (time stamp, sync berichten en emergency berichten), netwerk management (boot-up berichten, NMT berichten en error controle berichten) en een object dictionary voor elk toestel. Al deze elementen worden in dit hoofdstuk uitvoerig uitgelegd. Voor lezers die nog geen enkele notie van dit protocol hebben, wordt aangeraden dit hoofdstuk twee maal goed door te lezen. Een eerste keer om een globaal idee te creëren, daarna een tweede keer om de exacte werking van CANopen te begrijpen.
1.2 De object dictionary Elke node13 heeft zijn eigen object dictionary (OD). Dit is nodig voor configuratie en nietrealtime communicatie met het toestel. Alle parameters en diensten die beschikbaar zijn op het toestel en hun karakteristieken liggen vast. Ze worden vertegenwoordigd door objecten in de OD. Elk object wordt geadresseerd met behulp van een 16-bit index en optionele subindexen van 8 bit. Er zijn maximaal 65536 ingangen in de OD. De 16-bit index is nodig om alle ingangen van de OD te adresseren. Als een simpele variabele geadresseerd wordt is enkel de index nodig. Als complexe datastructuren zoals array’s of records nodig zijn, wordt met de index de volledige structuur aangesproken. Om dan de individuele elementen van de data te bereiken, zijn de subindexen voorzien. Bij eenvoudige structuren zoals integers, booleans, unsigned integers,… is de subindex waarde nul. Bij uitgebreide structuren met meerdere elementen staat onder subindex 0 het aantal elementen in de datastructuur in de vorm van een unsigned 8 14. Het adresseren van de aparte elementen begint bij subindex 1. Tabel 1: De object dictionary gebieden
Index
Gereserveerd voor…
0000h 0001h-001Fh 0020h-0023h 0024h-003Fh 0040h-005Fh 0060h-007F 0080h-009Fh 00A0h-0FFFh 1000h-1FFFh 2000h-5FFFh 6000h-9FFFh A000h-FFFh
wordt niet gebruikt de standaard data types voorgedefinieerde complexe data types toekomstige standaard data structuren complexe data typen van de fabrikant toestel profiel specifieke standaard data types toestel profiel specifieke complexe data types toekomstig gebruik communicatieparameters fabrieks specifieke profiel definiëring Standaard device profiel bereik wordt niet gebruikt
13 14
Elk CANopen device op de bus heeft een adres en wordt aangesproken met node
. Een unsigned 8 is een getal van 8 bits zonder teken
Hanne Deschildre
Hoofdstuk 4: CANopen
57
De OD, adresseerbaar via de 16 bit indexen, bevat gereserveerde velden. Tabel 1 geeft deze velden weer. Bij de opmaak van de OD voor een toestel moet elk gegevensobject dus in het juiste indexbereik liggen. Binnen het protocol mag hiervan niet afgeweken worden. De OD bevat indexen, subindexen, datatypen, waarden… Tabel 2 geeft een overzicht van alles wat in de OD beschrijving in de standaard terug te vinden is. Tabel 2: Alle elementen die kunnen voorkomen in een OD
OD element
Toelichting
Index Subindex Object type Object naam Data type Attribuut PDO map Default M/O
16 bit adres van een object Om subelementen van een object te bereiken Het datatype van het gegeven dat gestockeerd wordt(1) Een symbolische naam voor de OD-ingang Data type voor veld De toegangsrechten tot het element (2) Vertelt of het object te mappen is in een PDO15 Een default waarde voor de parameter Geeft aan of dit een verplicht (mandatory) of optioneel (optional) veld is voor het toestel
(1) De object types kunnen zijn:
(2) De toegangsrechten:
- VAR : één enkele waarde - ARRAY: reeks van elementen van hetzelfde type - RECORD: reeks elementen die van verschillende types
- read/write - read-only - write-only - read only constant
Dit is heel wat informatie ineens. Een voorbeeldje verduidelijkt: In Tabel 3 worden de communicatieparameters 16 meegegeven. Deze zijn standaard in de DS30117 en worden gemapped binnen het index bereik: 0x1000 – 0x1FFF (“communicatieprofiel gebied”). De eerste ingangen van dit bereik worden getoond: het device type, een error register en de fabrikantnaam van het toestel. Elk element moet bereikbaar zijn via een unieke index-subindex combinatie. Aangezien het object type telkens “VAR” is, is een subindex niet 15
Dit komt later nog uitgebreid aan bod onder punt 1.5.3 PDO’s Communicatieparameters zijn belangrijk bij PDO’s 17 Een CiA standaard 16
Hanne Deschildre
Hoofdstuk 4: CANopen
58
nodig. Verder wordt het type meegegeven om de waarde te kunnen interpreteren en een attribuut dat vertelt hoe de elementen aanspreekbaar zijn. Het mandatory/optional veld vertelt ons dat de fabrikantnaam hier optioneel is, de rest verplicht.
Tabel 3: Voorbeeld van een OD
Index
Object naam
Naam
Type
0x1000 0x1001 … 0x1008
Attribuut
M/O
VAR VAR
Device type Error register
UNSIGNED32 UNSIGNED8
ro ro
M M
VAR
Manufacturer device name
Visible String
const
O
Als de functie en opdeling van de OD nu nog niet duidelijk is, geen paniek. Alles wordt gaandeweg duidelijker wanneer de andere pijlers van CANopen aan bod komen. Bijlage CANopen 1 toont een voorbeeld van een OD ingang.
1.3 Communicatieobjecten De fysische laag van CANopen (CANbus) verzendt korte pakketjes. Deze pakketen bestaan uit een identificatie (id) van 11bit18 en 0 tot 8 bytes data. CANopen frame Een CANopen frame ziet er als volgt uit: OB-ID 11bit
Data Byte 0
Byte 1
Byte 2
Byte 3
Byte 4
Byte 5
Byte 6
Byte 7
Figuur 73: Een CANopen frame
COB-ID De 11-bit COB-id (Communication Object identifier) bestaat uit 4 bit functie code en een 7 bit CANopen node id. COB staat voor communication object identifier. De functie code geeft informatie over het bericht weer, de node id geeft de ontvanger weer. De 7 bit zorgt ervoor dat in het netwerk maximaal 127 toestellen aangesloten kunnen worden. Bij een transmissie botsing van 2 of meer berichten zorgt de busarbitrage bij CANbus ervoor dat het frame met de kleinste id prioriteit heeft. De 1e 4 bit functie code is dan ook een laag binair getal voor tijdskritische functies zodat steeds de laagst mogelijke delay voorvalt.
18
Een 29-bit id is ook mogelijk, hier wordt de 11-bit id toegepast.
Hanne Deschildre
Hoofdstuk 4: CANopen
59
Tabel 4: COB-ID van een CANopen frame
COB-ID Functie code 4 bit
Node id 7 bit
De functie codes De functie codes zijn betekenisvol voor de te verzenden berichten. Berichten met laagste COB-ID krijgen voorrang en een COB-ID begint met de functie code. De functie code is daarom van groot belang bij prioriteitstoewijzing. De 4-bit codes worden toegekend aan de soorten berichten, een overzicht van alle functie codes staat in de CANopen bijlage 2. Straks wordt duidelijk waarom deze berichten nodig zijn.
1.4 Communicatiemodellen Voor de berichtgeving tussen communicatiemodellen gebruikt.
CANopen
nodes
worden
verschillende
soorten
Bij het master/slave model is één node de master en die vraagt data aan de slaves of zendt er zelf. Het NMT protocol gebruikt dit communicatiemodel. Een client/slave relatie wordt gebruikt bij het SDO protocol. De SDO client vraagt de data aan een SDO server. Dit gebeurt via een bericht waarin de index en subindex alsook de node van de server vervat zit. De server zoekt de data op en zendt één of meer pakketen terug met de gevraagde data (= de inhoud van de gevraagde index in zijn object dictionary. Het procuder/consumer model wordt gebruikt bij de Heartbeat en Node Guarding protocollen. Wanneer het push-model gebruikt wordt, zendt de producer data naar de consumer zonder dat hiervoor een request werd verzonden. Bij het pull model moet de consumer aan de producer naar de data in kwestie vragen.
1.5 Protocollen 1.5.1
Network management (NMT)
Netwerk management wordt beschreven in de standaard DS301. Hierin worden specificaties omtrent de NMT state machine, node guarding en life guarding vermeld.
a. De NMT state machine Elk CANopen toestel heeft zijn eigen NMT state machine. De NMT master beïnvloedt de state van de andere toestellen op de bus, in ons geval is de HCD master. Via CANopen Hanne Deschildre
Hoofdstuk 4: CANopen
60
objecten (berichten) kan de HCD de aangesloten toestellen starten, stoppen of in een andere NMT state brengen. Hij handelt de configuratie, initialisatie en error management van het CANopen netwerk af. De COB-ID van zo’n CANopen frame voor netwerk management is altijd 0. Functie code en node id zijn dus allebei 0 zodat het bericht de hoogste prioriteit heeft en elke node in het netwerk dit bericht ontvangt. De slave node, voor wie het commando bedoeld is, wordt meegegeven als data. Wanneer dit datagedeelte 0 is, moeten alle toestellen op de bus naar deze state.
Figuur 74 toont de NMT state machine van een CANopen toestel. We zien volgende overgangen: -
(3) (5 )(8) (4)(7) (9)(10)(11) (12)(13)(14) (2)
= Start_Remote_Node = Stop_Remote_Node = Enter_Pre_Operational = Reset_Node = Reset_Communication = Initialisation finished; enter pre-operational automatically
Figuur 74: NMT state machine van een CANopen toestel
Hanne Deschildre
Hoofdstuk 4: CANopen
61
Overzicht van de werking van een dergelijke state machine: - Power on De slave gaat naar Initialisation state.
- Initialisation state De applicatie initialiseert het device.
- Pre-Operational state Na initialisatie gaat de slave automatisch in Pre-operational state. De NMT master (hier HCD) wordt op de hoogte gebracht van deze overgang via een BOOTUP bericht van elke slave. In deze state kan enkel de SDO-berichtgeving 19 gebruikt worden. Instellingen omtrent PDO-berichtgeving worden hier gedaan en dat kan op dit moment enkel via SDO’s. Wanneer de slave geen geheugen voorziet om de mapping en communicatieparameters voor PDO’s op te slaan en deze parameters geen default waarden zijn dan moet de master de waarden meedelen aan de node via het netwerk, vandaar het belang van SDO’s op dit moment.
- Operational state Om de datacommunicatie te starten moet de slave overgaan naar Operational state. De master zorgt ervoor dat dit gebeurt via het Start_Remote_Node bericht. Bij deze overgang worden alle TPDO’s verzonden. Hierna worden enkel PDO’s verzonden als er ook echt een event voor optreedt.
- Stopped state (= prepared state) Analoog als het Start_Remote_Node bericht, kan een Stop_Remote_Node bericht worden verzonden om het slave device te laten stoppen. SDO en PDO communicatie zijn niet mogelijk in deze state; enkel node guarding, life guarding en heartbeat zijn hier mogelijk.
19
SDO’s en PDO’s komen aan bod onder punt 1.5.2 en 1.5.3
Hanne Deschildre
Hoofdstuk 4: CANopen
62
Enter_Pre_Operational wordt gebruikt om van stopped en operational terug te keren naar pre-operational state. Reset_Node dient om de applicatie specifieke data en de communicatieparameters van de node te resetten. De initiële waarden worden opgeladen bij de slave. Reset_communication dient ook voor een stateverandering naar Initialisation maar het verschil met Reset_Node is dat hier enkel de initiële waarden voor de communicatieparameters worden geladen.
De berichten die de master (HCD) naar een slave zendt om die van state te doen veranderen zien er als volgt uit:
COB-ID 0h
Databyte 1 cs
Databyte 2 Node-id
Figuur 75: Een NMT-bericht dat de slave van state doet veranderen
Waarbij databyte 1, de cs (command specifier), meegeeft welke overgang moet plaatsvinden en databyte 2 verklaart welke node van state moet veranderen. De node id’s lopen van 1 tot 127 voor de beïnvloeding van een specifieke slave, node id 0 zorgt ervoor dat alle nodes hun state wijzigen. Met
cs = 1: Start_Remote_Node cs = 2: Stop_Remote_Node cs = 128: Enter-Pre-Operational cs = 128: Reset_Node cs = 130: Reset_Communication
In CANopen bijlage 3 wordt getoond welke berichten mogelijk zijn in welke states.
Hanne Deschildre
Hoofdstuk 4: CANopen
63
b. Node guarding of life guarding Bij node guarding (of life guarding) kan de master controleren of zijn slaves nog steeds correct werken. Hiervoor zendt hij een node-guarding bericht naar de nodes. Dit is een CANopen frame met als eerste 12 bits 0x700 plus het node adres van de NMT slave. Het antwoord van de slave is een bericht met zijn huidige NMT state en een toggle bit die verandert tussen twee opeenvolgende dergelijke berichten. Bij opstart is deze eerst toggle bit steeds 0. De NMT master initialiseert de node guarding in Pre-Operational state van de slave door een remote frame te zenden. De slave kan op zijn beurt ook controleren of zijn master nog steeds aanwezig is. Intern kan hij kijken of node guarding plaats vindt binnen het gedefinieerde tijdsinterval (Life Guarding). Het berichtverloop ziet er als volgt uit: Van master naar slave: COB-ID 700h + node id slave
Databytes
Van slave naar master: COB-ID 700h + eigen node id
Databytes Data byte 0 ingevuld
Figuur 76: Berichten bij node guarding
Bemerk dat 700h als eerste 11 bits wordt genomen (de twaalfde, meest beduidende bit is 0). Dit resulteert in een decimale COB-ID van 1792. Tel hierbij de node id van de slave op en je bekomt de nodige COB-ID van de berichten. De inhoud van de databyte bij het antwoordbericht is van de volgende vorm: Bit 7: toggle bit (0 na initialisatie of reset) Bits 0 … 6: NMT state - 00 voor BOOTUP - 05 voor operational - 04 voor stopped - 127 voor pre-operational
c. Heartbeat Als alternatief voor node- of life guarding werd heartbeat gedefinieerd. Hier zendt de slave (heartbeat producer) zelf cyclisch een bericht naar de master (heartbeat consumer) met COBID 0x700 plus zijn node adres. De data van dit bericht bevat de status van de slave. De tijd tussen twee dergelijke berichten wordt bepaald aan de hand van de objecten: Life Guard Time en Life Time Factor in de object dictionary van de slave. Als binnen de heartbeat consumer tijd geen heartbeat ontvangen wordt, wordt de master applicatie geïnformeerd. CANopen bijlage 4 toont het principe aan de hand van een figuur. Hanne Deschildre
Hoofdstuk 4: CANopen
64
Bij opstart gaan CANopen toestellen over van Initialisatie naar Pre-operational. Bij deze overgang wordt door de producer één heartbeat bericht verzonden naar de bus.
1.5.2
Service data object (SDO)
De service data objecten dienen om parameters in de object dictionary van een ander device op de bus uit te lezen of in te stellen. Dit protocol wordt gedefinieerd in de CiA DS202 standaard. Het toestel die zijn OD aanbiedt heet de server, de node die het uitleest of instelt heet de SDO client. De communicatie via SDO’s wordt steeds gestart door de client, in dit geval de HCD. Een leesactie wordt ‘upload’ genoemd, een schrijfactie is een ‘download’. De acties worden bekeken vanuit het standpunt van de server, vandaar de terminologie. De communicatie verloopt met tenminste twee berichten. De eerste wordt verzonden vanuit de client die data wil lezen of een aanvraag doet om in de OD van de server te schrijven. Dit bericht wordt de CSDO(client SDO) genoemd. Deze laatste reageert met een SSDO-bericht (server SDO) dat de gevraagde data meegeeft bij een upload en een simpel antwoordbericht is bij een download. Deze twee berichten zijn voldoende bij een “expedited” berichtgeving. Elk bericht bevat 8 databytes ook al worden ze niet alle 8 gebruikt (SDO berichtgeving is tamelijk traag). Bij verzending van grotere blokken data wordt “segmented”- of “block” berichtgeving gebruikt. Bij aanvang van deze masterproef werd duidelijk gemaakt dat expedited en segmented zeker geïmplementeerd moesten worden. Block SDO overdracht was minder belangrijk daarom komt het hier niet aan bod. Elk OD-object dat verzonden wordt en langer is dan 4 bytes wordt gesplitst in (n) 7 byte segmenten, de transfer vereist (n+1) * 2 berichten in deze “segmented” transfer.
Een SDO bericht ziet er als volgt uit: COB-ID 11 bit
Command Byte 1
Index Byte 2 Byte 3 LSB MSB
Sub index Byte 4
Service data Byte 5 Byte 6 Byte 7 Byte 8 LSB MSB
Figuur 77: Structuur van een SDO-bericht
Alle communicatie tussen 2 toestellen via SDO’s gebeurt met behulp van slechts 2 COB-ID’s: • •
600H + Node ID voor master naar slave 580H + Node ID voor slave naar master
Bij de volgende figuren worden de 8 bytes na de COB-ID getoond.
Hanne Deschildre
Hoofdstuk 4: CANopen
65
Read OD (expedited download)
Figuur 78: SDO expedited leesactie
Read OD (segmented download)
Figuur 79: SDO segmented leesactie
Hanne Deschildre
Hoofdstuk 4: CANopen
66
Write OD (expedited upload)
Figuur 80: SDO expedited schrijfactie
Write OD (segmented upload)
Figuur 81: SDO segmented schrijfactie
Hanne Deschildre
Hoofdstuk 4: CANopen
67
De velden hebben volgende betekenis: •
ccs/scs: client/server command specifier
0 1 2 3 4
ccs waarden download segment aanvraag initieel download aanvraag initieel upload aanvraag upload segment aanvraag abort transfer (stop de dataoverdracht)
scs waarden upload segment antwoord download segment antwoord initieel upload antwoord initieel download antwoord abort transfer
•
t: bij expedited is bit 4 steeds 0, bij segmented is dit de togglebit die verandert tussen 2 berichten. In het eerste bericht is dit 0.
•
x: wanneer een bit niet van toepassing is staat x, ze stellen niets voor en worden met 0 ingevuld.
•
e: duidt het transfer type aan => 0: een segmented transfer => 1: een expedited transfer
•
s: is de grootte indicator
•
n: deze bits hebben enkel betekenis als e = 1 en s = 1, anders zijn ze 0. Als dit het geval is stellen ze het aantal bits voor in d dat geen data bevat. Bytes 8-n tot en met 7 bevatten geen data.
•
m = multiplexer: dit stelt de index/sub-index voor van de data die via de SDO overgedragen wordt.
•
d = data: e=0 e=0
s=0 s=1
e=1 e=1
s=1 s=0
=> 0: de data grootte wordt niet meegegeven => 1: de data grootte wordt wel meegegeven
d is gereserveerd voor later gebruik d bevat het aantal bytes dat gedownload moet worden. Byte 4 bevat de LSB, byte 7 de MSB d bevat de data, met een lengte 4-n, die gedownload moet worden d bevat een niet-gespecificeerd aantal bytes die gedownload moeten worden
•
reserved: de bits zijn gereservoord voor later gebruik, nu zijn ze steeds 0
•
seg-data: de (maximaal) 7 bits data bij een segmented transfer
•
c: indiceert of er nog segmenten gedownload moeten worden, 0 betekent nee, 1 is ja
Hanne Deschildre
Hoofdstuk 4: CANopen
68
Tot slot kan bij SDO communicatie nog één soort berichten verstuurd worden. Zowel Client als server kan de communicatie stopzetten met een abort SDO transfer bericht.
Figuur 82: Abort SDO transfer bericht
Parameter d bevat nu de abort code die de reden van stopzetting meedeelt.
1.5.3
Process data object (PDO)
Wanneer een toestel in operational mode zit (de “gewone” werking) dan gebeurt dataoverdracht hoofdzakelijk via PDO’s. Ze zijn handig bij het real time versturen van berichten, SDO’s zijn hiervoor te traag. Een PDO wordt van of naar een toestel gestuurd en bevat tot 8 bytes data die 1 of meerdere dictionary entries bevat. Dit real-time bericht wordt snel en zonder aanvraag gezonden, toch is er een trigger nodig. Binnen de software kan de versturing gestart worden op een event, een afgelopen tijd, een synchronisatiemelding of een request frame van een andere node. Hoe de PDO’s eruit zien wordt vastgelegd in de OD van het toestel in kwestie. Standaard zijn altijd 4 RPDO’s (Read PDO) en 4 TPDO’s (Transmit PDO) voorzien maar in principe zijn er tot 512 per soort mogelijk. TPDO’s van een toestel worden verstuurd om data beschikbaar te stellen, RPDO’s worden ontvangen. De data kan informatie leveren over 1 of meerdere ingangen van de OD, daarom is een goede omschrijving over de inhoud en opmaak van zo’n bericht nodig. In de OD van elk device is per PDO een communicatie- en mapping parameter vermeld om de berichten volledig vast te leggen. De communicatieparameter omschrijft wat de PDO kan op gebied van communicatie, de mapping parameter verklaart welke data de PDO bevat. De indexen in de OD die deze informatie bevatten zijn: -
RPDO communicatieparameter index = 1400h + RPDO nummer – 1 TPDO communicatieparameter index = 1800h + TPDO nummer – 1 RPDO mapping parameter index = 1600h + RPDO nummer – 1 TPDO mapping parameter index = 1A00h + TPDO nummer – 1
Hanne Deschildre
Hoofdstuk 4: CANopen
69
Figuur 83: De verzending van een PDO
De producer zendt een PDO met informatie naar de consumer. In de OD van de producer staat deze gemapped als TPDO, voor de consumer is het een RPDO. Bij de masterproefopstelling leveren de slaves(producers) via PDO’s informatie aan de HCD (consumer) en omgekeerd. Hoe de berichten eruitzien staat vermeld in de OD’s van zowel de slave in kwestie als de HCD. Voorbeeld: Een PDO wordt verzonden van toestel A naar B en bevat de inputs 2 en 3 van toestel A. Na ontvangst bij B wordt deze informatie ingevuld in ouput 1 en 3. Beide toestellen ondersteunen de PDO als volgt: Toestel A: Input 1 staat op OD index 6000h, subindex 1 (8bit) Input 2 staat op OD index 6000h, subindex 2 (8bit) De TPDO mapping bij A ziet er als volgt uit: Index, sub index in OD Betekenis 0x1A00h, 0h Aantal ingangen (sub indexen) 0x1A00h, 1h 1st mapping object 0x1A00h, 2h 2nd mapping object
Waarde 2 60000108h 60000208h
De TPDO communicatieparameter bij A ziet er als volgt uit: Index, sub index in OD Betekenis 0x1800h, 0h Aantal ingangen (sub indexen) 0x1800h, 1h COB - ID 0x1800h, 2h Transmission type
Waarde 2 01C0h 255
De verstuurde PDO: COB – ID 0x01C0
Data Input 1
Input 2
Toestel B: Output 2 staat op OD index 6200h, subindex 2 (8bit) Output 3 staat op OD index 6200h, subindex 3 (8bit) De RPDO mapping bij B ziet er als volgt uit
Hanne Deschildre
Hoofdstuk 4: CANopen
70
Index, sub index in OD 0x1600h, 0h 0x1600h, 1h 0x1600h, 2h
Betekenis Aantal ingangen (sub indexen) 1st mapping object 2nd mapping object
De RPDO communicatieparameter bij B ziet er als volgt uit: Index, sub index in OD Betekenis 0x1400h, 0h Aantal ingangen (sub indexen) 0x1400h, 1h COB - ID 0x1400h, 2h Transmission type
Waarde 2 62000208h 62000308h
Waarde 2 01C0h 255
De ontvangen RPDO: COB – ID 0x01C0
Data Output 1
Output 2
Wanneer B zijn PDO ontvangt analyseert hij hem op basis van de gegevens in de OD. Na analyse worden de inputs van A opgeslaan in outputs bij B.
1.5.4
Synchronization object (SYNC)
Om devices te synchroniseren werd binnen het CANopen protocol een SYNC object voorzien. Deze melding met COB-ID 0x80 is een broadcast, verzonden door de producer. In onze opstelling zal dit de HCD worden. Bij ontvangst kunnen slaves de synchrone taken starten, waaronder ook de verzending van PDO’s die op een SYNC getriggerd worden.
Figuur 84: Het SYNC object met de synchrone en asynchrone PDO verzending
Hanne Deschildre
Hoofdstuk 4: CANopen
71
1.5.5
Time stamp object (TIME)
Voor tijdskritische applicaties is een zeer accurate synchronisatie nodig. Hiervoor werd binnen het CANopen protocol de time stamp gedefinieerd. Binnen PsiControl wordt dit niet gebruikt daarom wordt hier niet dieper op ingegaan.
1.5.6
Emergency object (EMCY)
Een emergency bericht wordt verzonden wanneer een fatale situatie zich voordoet. De berichten krijgen de hoogste prioriteit om er zeker van te zijn dat ze op de bus worden geplaatst zonder vertraging. Een EMCY bericht heeft functie code 0001h. De databytes bevatten de foutcode.
2. CANopen toegepast op de Handheld 2.1 Probleemstelling De studie rond CANopen wordt in de voorgaande bladzijden vrij in detail besproken. Het protocol kon dan ook gezien worden als ongeveer de helft van deze masterproef, althans bij aanvang… Bij het opstellen van de projectfiche werden de mijlpalen afgelijnd en één ervan was de implementatie van CANopen. Samen met PEG+, de XML parser en de schermstructuur uitwerking zou dit een hele boterham worden, er viel m.a.w. geen tijd te verliezen. CANopen was nieuw binnen PsiControl en ook voor PEG+ bestonden geen grote uitgewerkte voorbeelden er werd dus gestart met een gedetailleerde studie om later die semester te beginnen met het schrijven van software voor allebei. Mooi op schema werden de resultaten in december via een presentatie meegedeeld. De CANopen stack Eind tweede semester (rond december) werd beslist om voor CANopen de software niet zelf te schrijven maar een stack aan te kopen. 2 ingenieurs in Roemenië onderzochten de werking ervan en gaven een uiteenzetting. Aangezien de aangekochte stack niet volledig was zou de software voor de HCD niet volledig gegenereerd kunnen worden. Slechts 15 plaatsen in de OD waren mogelijk (indexen en subindexen samen), te weinig voor elke deftige applicatie. Er stond me dus nog wat programmeerwerk op gebied van CANopen te wachten. Verder zou in Roemenië uitgezocht worden welke onderste lagen nodig waren om CANopen op de BF536 te gebruiken, in samenwerking met Quadros.
Hanne Deschildre
Hoofdstuk 4: CANopen
72
Ook in de tweede semester werd voortgegaan op hetzelfde elan. Wachtend op vooruitgang in Roemenië werd verdergewerkt aan de parser en PEG+ schermen. Bij elke stap werd rekening gehouden met een latere implementatie van Modbus maar CANopen bleef prioritair. Tot in maart… In maart (2e semester) zijn beide ingenieurs vertrokken uit PsiControl en kwam de implementatie voor CANopen op de HCD in gedrang. In overleg met de projectingenieurs in België werd beslist om verder te gaan met Modbus als primair protocol. Niet alles was verloren maar het was een hele ommekeer. De afwerking van alle onafgewerkte CANopen zaken werden meteen stopgezet.
CANopen als secundair protocol CANopen wordt nu het secundaire protocol op de HCD. Dit houdt in dat de software op zich niet geïmplementeerd wordt binnen de scoop van deze masterproef, er moet wel rekening mee gehouden worden. In dat opzicht is de CANopen missie van de masterproef volbracht. Toch werd al te veel tijd in gestopt om het niet te vermelden in deze uiteenzetting en ook voor de latere implementatie kan dit naslagwerk een handige houvast zijn. Daarom staan alle realisaties en ideeën rond CANopen in de volgend alinea’s vermeld.
2.2 CANopen uitwerking 2.2.1
CANopen schermideeën
Voor de boomstructuur van schermen werd uitgelegd hoe het visuele gemaakt wordt. Waarom een scherm die specifieke inhoud heeft is eerder protocol afhankelijk. Daarom komen de CANopen schermen hier opnieuw aanbod, nu wordt de keuze van de soorten schermen toegelicht. Bemerk dat de software hiervoor nog niet geschreven is maar omdat er al wat onderzoek naar gebeurd is, wordt uitgelegd hoe tewerk kan worden gegaan. Dit kan later nog van pas komen wanneer CANopen daadwerkelijk geïmplementeerd wordt. HcdCANopenBusoverview
Figuur 85: HcdCANopenOverview
Hanne Deschildre
Hoofdstuk 4: CANopen
73
De keuze voor dit scherm is vrij logisch: een bus vereist een overzicht van de aanwezige slaves. De keuze van gegevens per slave werd vastgelegd met de projectingenieurs. Al deze gegevens kunnen opgevraagd worden via een busscanning. -
De busscanning: Elk toestel zendt bij opstart een bootup bericht. Dit bericht, met COB-ID 700h + nodeid is voorzien omdat de slave aan de master zou kunnen laten weten dat hij de Preoperational state bereikt heeft. Zo is meteen duidelijk welke nodes (adressen) op de bus aanwezig zijn. Een tweede mogelijkheid is de heartbeat. Zo kan het scherm voortdurend opgefrist worden, het kan altijd dat een toestel wegvalt en dan blijft het scherm up to date.
-
Het adres: De node wordt meegegeven met het boot-up bericht. Ook de heartbeat kan deze parameter meegeven.
-
De naam: OD index 1008h
-
Het type: OD index 1000h
-
De hardware versie: OD index 1009h
-
De software versie: OD index 100Ah
HcdNmtAllSlaveScreen
Figuur 86: HcdNmtAllSlavesScreen
Dit scherm werd voorzien omdat alle slaves eenzelfde state machine hebben. De koper van een HCD kan op die manier zijn slaves allemaal ter zelfde tijd een bepaalde state toekennen en de huidige states uitlezen.
Hanne Deschildre
Hoofdstuk 4: CANopen
74
-
Het uitlezen van states: Via de heartbeat zendt elke slave automatisch zijn state naar de master. Elke state heeft zijn specifieke waarde(zie punt 1.5.1). Softwarematig kan hieraan de naam (tekst) worden toegekend. De naam van de state kan via de PEG+ timer automatisch opgefrist worden of de refresh kan getriggerd worden bij ontvangst van een heartbeat.
-
Toekennen van states: Figuur 75 toont een NMT-bericht dat de slave van state doet veranderen. Bij het indrukken van een knop kan binnen PEG+ worden voorzien dat op dat moment ‘x’ aantal dergelijke berichten naar alle ‘x’ de slaves worden gezonden.
-
De slave namen Bij het vorig scherm werden deze namen opgehaald.
-
De synchronisatie starten/stoppen OD indexen 1005h-1006h-1007h staan in verband met de synchronisatie. Bemerk dat wanneer je de SYNC berichten stopt of start, er ook aanpassingen in de OD moeten gebeuren omtrent de PDO’s (zeker als ze enkel worden verstuurd op SYNC bevel). Zowel voor de HCD als sync producer als de slaves, die de syncberichten verwachten, moeten bij een selectie van deze knoppen instellingen gebeuren.
HcdCANopenSpecific
Figuur 87: HcdCANopenSpecific
Bij de busoverview kan een slave geselecteerd worden. Daarna komt de gebruiker terecht op de NMT state machine van de slave in kwestie. Analoog als bij het algemeen NMT scherm wordt bij de keuze van een state-button, een NMT-bericht gestuurd. Ook de huidige state kan via de heartbeat continu geüpdate worden. De onderstaande buttons verwijzen naar de mogelijke parameterschermen.
Hanne Deschildre
Hoofdstuk 4: CANopen
75
HcdParameterScreen
Figuur 88: HcdParameterScreen
Dit scherm, volledig bepaald via een XML-bestand, heeft alle CANopen informatie nodig om correct te werken. In hoofdstuk 5 wordt in detail uitgelegd hoe de HCD-gebruiker zijn informatie structureel kan meegeven. In de software moet (na uitlezen van het XML-bestand) het juiste bericht opgesteld worden om de waardes uit te lezen of in te stellen. Het bestand levert volgende CANopen informatie: -
De OD index van de parameters Een duiding of de parameter wordt gelezen uit of weggeschreven naar de OD van de slave in kwestie De eenheid van de parameters (voor de vaste teksten: mA en m/s) De mogelijke omzetting voor de parameters (als de uitgelezen waarde nog niet de weer te geven waarde is maar nog omgezet moet worden)
HcdSlaveInfo
Figuur 89: HcdSlaveInfo
Analoog als bij de parameterschermen wordt in het XML-bestand alle nodige CANopen gegevens ter beschikking gesteld. Hier treden echter enkele beperkingen op omdat het “slechts” een informatiescherm is. Meer daarover in hoofdstuk 5
Hanne Deschildre
Hoofdstuk 4: CANopen
76
2.2.2
Praktisch besluit
Het komt er dus op neer de stack te implementeren. Standaard bouwt die een beperkte CANopen softwarestructuur op die handmatig verder uitgewerkt moet worden. Daarna moeten de constructoren van de PEG+ schermen modulair gemaakt worden en op de juiste plaats worden dan CANopen berichten gezonden/ontvangen om alle informatie van de slaves te hebben. Zo houdt de programmeur best CANopen- en PEG+ software zo lang mogelijk gescheiden en analoog als bij Modbus kunnen de nodige functies op het juiste tijdstip binnen de PEG+klassen opgeroepen worden. Aan de hand van de CANopen studie en de meegegeven tips en ideeën zou het gemakkelijker moeten gaan om hieraan te beginnen. Verder wordt aangeraden hoofdstuk 5 na te lezen aangezien de XML-parser voor CANopen ook op de juiste plaatsen in de software zijn werk moet doen. Hou ook steeds de CANopen schermen en CANopen XML-structuur bij de hand. Deze structuren kunnen altijd aangepast worden (geen probleem zolang de software nog niet geschreven is); maar bedenk dat er nogal wat tijd in gestoken is en dusdanig al goed over nagedacht werd. Na alle problemen omtrent de protocolverandering kan de studie en structuur die uitgedokterd werd waarschijnlijk toch nog gebruikt worden. In principe ontbreekt enkel de software. Bemerk dat in de eerste semester software geschreven werd voor verzending en ontvangst van SDO’s (client SDO software voor de HCD) en PDO’s. Aan de hand van bestaande CAN-files werden de berichten vanuit de HCD naar een CANopen slave (een BSD) verzonden. Via SDO’s werd de state van de slave ingesteld en op hyperterminal was de verandering te zien. Daarna werd de stack gekocht en toegelicht alsook de CANtools. De studie was echter te beknopt om te vermelden in deze uiteenzetting.
Hanne Deschildre
Hoofdstuk 4: CANopen
77
Hoofdstuk 5: XML-structuur en opmerkingen 1. XML-structuur Per slave wordt op de SD-kaart een XML-bestand opgesteld met informatie, nodig om de schermen op te bouwen. Het bestand structuur is gelijkaardig voor Modbus en CANopen slaves, enkel protocolspecifieke zaken zijn verschillend. Er werd voor XML gekozen omwille van de overzichtelijke structuur. De naam van een bestand is de softwareversie van de applicatie.
1.1 XML voor Modbus Om de opbouw van een XML-bestand voor Modbus slaves uit te leggen nemen we een OXI. Aan de hand van deze slave stellen we een schermstructuur op. Ook voor de demo bij de masterproef presentatie wordt het bestand gebruikt. Eerst kijken we welke schermen we wensen en hoe ze opgebouwd moeten zijn. De standaardschermen zijn al vooraf bepaald, zelfs voor het Modbus overzichtscherm is geen specifieke informatie nodig. We zien dat een busscanning 1 slave oplevert, onze OXI.
Figuur 90: Standaard schermen voor de oefening
Voor de applicatie specifieke schermen heeft de HCD wel extra informatie nodig. In dit geval bevat de aangesloten OXI testsoftware met softwarenummer 0.0.65329.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
78
De OXI heeft enkele specifieke kenmerken die we in het XML-bestand kunnen meegeven. We vinden ze terug in de functional description. Aan de hand van deze uiteenzetting maken we een kleine oefening: -
-
De OXI stuurt 2 motoren aan (= de subdevices) Elke motor heeft een state machine van 13 states. De states zijn: Power Down, Open Circuit, Short Circuit, Power Up, Standby, Standby Hold, Moving, Moving Boost, Torque Mode, Speed Mode, Position Mode, Cam Mode, Moving Table We zouden graag de snelheid instellen van motor 1 We zouden graag de snelheid uitlezen van motor 2 Op elk moment moet in het infoscherm de slavenaam , de fabrikant, het softwarenummer en een regeltje tekst (“Dit is een DEMO.”) te zien zijn.
De applicatie specifieke schermen moeten er als volgt uitzien:
Figuur 91: Applicatie specifieke schermen voor de oefening
Om de schermen te kunnen maken heeft de HCD het volgende bestand nodig: 1. De states van de statemachine voor dit toestel worden meegegeven in hexadecimale waarde en overeenkomstige naam:
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
79
Figuur 92: State opsomming in het XML-bestand
2. Verder moet de HCD weten in welke holding registers de state moet geschreven worden.
Figuur 93: Holding register voor het instellen van de state
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
80
3. Per slave wordt 1 ModbusSlaveScreen gedefinieerd in het XML-bestand. Aan de hand van <screenType> weet de parser dat nu de informatie voor dit scherm volgt. Het scherm krijgt een identificatienummer en als er nog slaves op de bus zitten kan het een rechter- en linkerbuur hebben, dan wordt ook hun id meegegeven. Hier zijn geen andere slaves aangesloten op de bus, daarom: geen buren. Als 0 ingevuld wordt en er zijn geen buren kan geen buurscherm getoond worden maar als er toch een buur slave zou zijn dan zal de HCD automatisch het ModbusSlaveScreen oproepen van de volgende/vorige slave oproepen. Er wordt 1 parameterscherm vastgelegd, daarom wordt hier een button voorzien om dit te kunnen oproepen. geeft het identificatienummer mee van het op te roepen scherm. Bemerk dat het er niet toe doet welk scherm eerst gedefinieerd wordt; dit wordt immers opgevangen in de code. Het is wel belangerijk dat stateinformatie voor de schermdefinities komt.
Figuur 94: ModbusSlaveScreen specificaties in het XML-bestand
4. Per aangesloten toestel wordt een informatie scherm meegegeven dat basisinformatie bevat die op elk moment (bij elk applicatie specifiek scherm) kan opgeroepen worden. De informatie hierop kan een element van de Modbus identificatie zijn (naam, verkoper of softwarenummer), een uitlezing van een holdingregister of simpelweg tekst. Wanneer een holdingregister wordt uitgelezen stelt pLinkType het hexadecimale adres voor.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
81
Figuur 95: SlaveInfoScreen specificaties in het XML-bestand
5. Per slave kunnen een aantal parameterschermen meegegeven worden. Deze hebben een identificatienummer, kennen hun parent en, als er meerdere zijn, kunnen ze linker en rechterburen hebben. De parameters worden gedefinieerd tussen <screenParameters> en . Elke Modbus parameter heeft de volgende eigenschappen:
Tabel 5: Parameter specificaties in het XML-bestand
ScreenRow Name Linktype
Rangnummer voor de button De tekst die wordt getoond als parameternaam. De manier waarop de tekst opgehaald wordt. Er kunnen coils, discrete inputs, holding registers worden gekozen om in te stellen of uit te lezen. De respectievelijke invoermogelijkheden zijn: COIL, DINPUT en HREG. Bij tekst wordt 0 meegegeven. LinkId Het holding register, het adres van de coil of het adres van de discrete input wordt meegegeven. Bij weergave van tekst wordt hier het regeltje tekst meegegeven. Notation Hier wordt DEC meegegeven als de opgehaalde waarde nog moet omgezet worden van hex naar decimaal. Unit De eenheid die op het scherm wordt getoond. ValuePurpose Er wordt een schrijf of leesactie uitgevoerd, respectievelijk gekozen via “Editable” of “Read” of “Monitoring”. Click Deze boolean wordt true gezet als bij selectie van de parameter een volgend parameterscherm moet verschijnen. CallScreenId Voor het vorige op te roepen scherm moet een identificatienummer worden meegegeven. Increase Als de waarde instelbaar is wordt die aan de hand van de pijltjes veranderd. Het “increase” element geeft aan hoeveel de waarde stijgt/daalt per druk op de pijl. Multiply en Devide Als de opgehaalde/in te stellen waarde niet in dezelfde vorm wordt Factor opgeslagen bij de slave gebeurt de omzetting automatisch door deze 2 parameters. Start- en Endbit Wanneer slechts een paar bits weergegeven moeten worden kan dat in het XML-bestand meegegeven worden.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
82
Figuur 96: ParameterScreen specificaties in het XML-bestand
In de software wordt aan de hand van deze structuur de volgende Modbus berichten ondersteund: -
StdAlModbusMReadCoils StdAlModbusMReadDiscInp StdAlModbusMReadHoldReg StdAlModbusMReadInpReg StdAlModbusMWrSingleCoil StdAlModbusMWrSingleHoldReg
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
83
1.2 XML voor CANopen Analoog als bij Modbus wordt één CANopenSlaveScreen per slave opgegeven. Ook hier moeten enkel de buttons worden toegelicht die de parameterschermen oproepen. De statemachine van elk CANopen apparaat is dezelfde alsook de indexen in de OD van de slave waarin een state kan geschreven of uitgelezen worden. Daarom wordt deze informatie niet meegegeven met het XML-bestand.
Figuur 97: CANopenSlaveScreen specificaties in het XML-bestand
Het informatiescherm bij CANopen kan als volgt meegegeven worden:
Figuur 98: SlaveInfoScreen specificaties in het XML-bestand
Bemerk dat ook hier het er niet toe doet wat de volgorde van de schermen binnen XML is. Als de parser analoog geprogrammeerd wordt als deze bij Modbus is het geen probleem om de schermen te wisselen van plaats.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
84
Ook bij CANopen zijn parameterschermen mogelijk. De structuur binnen XML is gelijkaardig maar door protocolspecifieke zaken toch niet volledig gelijk aan de Modbus structuur.
Figuur 99: ParameterScreen specificaties in het XML-bestand
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
85
1.3 XML-parser Het XML-bestand vol informatie wordt uitgelezen en alle elementen moeten hun weg vinden naar de attributen van de slave objecten. Er moet een systeem uitgewerkt worden om de bestanden aan te spreken en informatie op te halen. Er is een FAT filesysteem nodig en code om de elementen uit het XML-bestand toe te kennen aan de attributen van de objecten van de klasse HcdSlave (opslagplaats voor alle slave informatie).
1.3.1
FAT filesysteem
Het doel van een FAT filesysteem is het filesysteem interfacen op een flash kaart, RAM geheugen en flash geheugen. De afspraak binnen dit project (en voorgaande ACMkV projecten) is: -
B drive = FLASH card (de HCD doet beroep op deze drive) A drive = RAM C drive = FLASH
Voor dit filesysteem bestaat een aangekochte bibliotheek, RtxFatFile folder. Op die manier bereiken we de gegevens op de SD-kaart maar nu is nog een een parser20 nodig.
1.3.2 Parser XML staat voor “eXtensible Markup Language” en laat toe om een document te maken met eigen onderverdelingen. HTML doet mooi werk om documenten op te stellen voor browsers, XML laat toe gelijk welk soort markeringen binnen een dergelijk document te gebruiken. In principe kunnen alle datastructuren via een XML-structuur vervangen worden. Het is een alomtegenwoordig formaat. Na een onderzoek naar de parsers wordt gekozen voor de tinyXmlParser. Een TinyXML leest een XML-document en bouwt hier van een DOM (document object model) dat gelezen kan worden, aangepast en opgeslagen. De parser is beschikbaar als open source C++ code. Ander beschikbare parse-technieken zijn ook mogelijk maar de tinyXmlParser is een goede keuze. De parser is niet zo groot als vele andere maar bevat toch genoeg voor deze applicatie. De bestanden die toegevoegd worden aan project 817: -
Tinystr.cpp en Tinystr.h Tinyxml.cpp en Tinyxml.h Tinyxmlerror.cpp
20
Een parser is een programma dat de grammaticale structuur van een invoer volgens een vastgelegde grammatica ontleedt (parset). Een parser zet ingevoerde tekst om in een datastructuur. Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
86
-
Tinyxmlparser.cpp
-
AppSdCard.h: voor initialisatie van de SD-kaart (AppSdCardInit() in AppMainInitAllObjects(void) )
-
AppXmlInterface.cpp en AppXmlInterface.hpp: hierin worden de deel-parserfuncties ingevuld. Ze worden opgeroepen vanuit de schermklasses (in de 818).
Het principe: Er zijn verschillende manieren om toegang te hebben tot XML data. TinyXML gebruikt een DOM wat betekent dat het bestand geparst wordt in C++ objecten. Die worden overlopen en gemanipuleerd om daarna naar een disk of andere ouput te schrijven. Er kan zelfs een XML document worden opgesteld met de C++ objecten. TinyXML werd ontworpen als simpele parser die de programmeur snel onder de knie heeft. Er zijn twee header- en vier cpp bestanden nodig. Na toevoeging van deze bestanden kan de omzetting gebeuren. De XML-structuren worden opgebouwd uit nodes, elementen, tekst, en commentaar. (Attributen en declaraties kunnen ook maar worden binnen de XML-files voor de HCD niet gebruikt.) De HCD gebruikt enkele basiseigenschappen en –functies van dit systeem.
In de code: -
Een document wordt gemaakt om de file in te bewaren: TiXmlDocument doc(“demo.xml”); result = AppXmlInterfaceLoadXmlFile(str_path, (TiXmlDocument*) &doc); de functie geeft een true weer als het document op pad: str_path” met succes in doc geladen wordt.
-
Nu kunnen alle elementen aangesproken worden als objecten van klasses: TiXmlNode* node_ptr = 0; TiXmlElement* element_ptr = 0;
-
Een node is de parent klasse voor alles binnen DOM (behalve de attributen, maar die worden hier niet gebruikt). Nodes hebben siblings, een parent en children. Een node kan onderdeel zijn van een document of op zichzelf bestaan. Het type (TiXmlNode) kan op zich gebruikt worden of het kan gecast worden naar zijn meer gedefinieerd type (bijvoorbeeld naar een element). De HCD maakt gebruik van de volgende functies per node:
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
87
• • • • • • •
FirstChild() Parent() LastChild() PreviousSibling() NextSibling() ToElement() Value()
-
Een element is een container klasse. Het heeft een bepaalde waarde (Value), een elementnaam en kan andere elementen, tekst, commentaar en onbekenden bevatten. De functies die de HCD voor elementen gebruikt: • FirstChildElement() • NextSiblingElement() • Value()
-
Een document is steeds de top level node. Het houdt alle XML onderdelen samen. De belangerijkste acties op een document zijn: opslaan en laden. De waarde (Value) van een document is steeds de naam van het XML bestand.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
88
2. Tips & Tricks Doorheen de masterproef is heel wat ervaring opgedaan omtrent de programmeeromgeving DSP, de programmeertalen C en C++, pointers,… Dit punt wordt meegegeven voor programmeurs die, net als ik, heel wat nieuwigheden ondervinden bij een dergelijk project. Er worden problemen toegelicht die bij uitvoering van dit project optraden maar bij gelijk welk ander project kunnen voorvallen. Naast problemen ook weetjes, handig voor wie zijn eerste Visual DSP project maakt.
Visual DSP, C en C++ - Enkel wanneer het programma ingeladen, gerund en daarna gestopt is, kan via rechtermuisklik de functie “go to definition” geselecteerd worden. Handig als de invulling van de functie getoond moet worden. - Zijn er linker problemen dan kan één van de volgende zaken de oorzaak zijn: • Een variabele stond extern maar werd uiteindelijk nergens gevonden. • Een variabele staat 2 maal globaal gedefinieerd, zet één ervan extern. • Een functie prototype werd extern geplaatst om te gebruiken in een bestand maar de originele functie heeft een ander prototype. - Dit project werd gestart op een laptop van het bedrijf met een licentie via het netwerk, later is overgegaan op een vaste. Bij een netwerklicentie valt de connectie af en toe weg wanneer het programma compileert. Het is geen grote moeite of tijdverlies om dat opnieuw te starten want Visual DSP onthoudt wat gecompileerd werd. Maar als de keuze voorvalt wordt vanuit dit project aanbevolen om een vaste licentie te gebruiken. - Het connecteren en inladen van een programma duurt even en als dat voortdurend moet gebeuren kruipt er wat tijd in. Door F5 en Shift F5 wordt een programma gerund en gestopt, gebruik deze commando’s in plaats van telkens te disconnecten. - Breakpoints zijn handig maar hebben soms kuren. Vaak moet je de vorige breakpoint wegdoen vooraleer een F5- of F10-commando werkt. In de loop van deze masterproef moest een voorgaande breakpoint af en toe weggelaten worden, niet echt volgens patroon. Vandaar de term “kuren”. - Bemerk dat foutmeldingen niet altijd alle nodige informatie bieden. Vaak duiden ze het probleem nauwkeurig aan maar soms moet je wat verder denken. Een vergeten “ ; ” kan soms leiden tot een foutmelding op een regel code die wat verder staat (met enkel commentaarregels tussen de vergeten ; en de aangeduide regel). Vooral met de structuur van de design rules, waar veel commentaar regels voorkomen, kan de afstand tussen de fout en de meldingsregel groot zijn.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
89
- Een C functie die in C++ wordt gebruikt (of omgekeerd) wordt aangeduid via de vermelding extern “C” . - Compileren kan lang duren, vermijd met andere woorden een “Rebuild All”. Als die toch nodig is, wordt het tijd voor een koffiepauze… - Een handig element bij het debuggen is de weergave van de stack. Binnen de PEG+ structuur is de overerving op die manier mooi zichtbaar - Als het programma crasht voor het breakpoint in AppMain bereikt wordt, is het mogelijk dat één van de C++ constructoren fouten bevat. Dit is voorgevallen binnen deze masterproef. De foutmelding staat op dat moment meestal totaal los van de echte fout. - Geef relatieve paden op binnen Visual DSP. De paden kunnen veranderen, wat heel wat problemen kan geven. Een groep bestanden kan verplaatst worden samen met het project maar meestal worden bestanden niet verplaatst relatief ten opzichte van hun project. - Bij een oneindige for-lus wordt geen foutmelding gegeven in Visual DSP, ook wanneer het programma crasht is geen zinvolle weergave van het probleem. Via F10 en F11 kan de code overlopen worden en wordt het probleem snel gevonden. - Let op met pointers. Zorg ervoor dat geheugenplaats voorzien is bij het definiëren van een (locale) variabele. Dit kan met de term “new”. Als je vergeet geheugenplaats te voorzien kunnen elementaire zaken in het geheugen overschreven worden. Hierop volgt vaak een lange zoektocht naar het effectieve probleem. Het volgende probleem is voorgevallen: 2 strings (char[ ]) werden samengevoegd met de bestaande functie strcat(). Hierbij wordt de tweede tekst toegevoegd aan de eerste. Let op dat de eerste karakter rij voldoende plaats heeft om die tweede erbij te nemen. Indien niet, worden in het geheugen ander zaken overschreven. De oplossing is een definiëring van de eerste string die groot genoeg is (20 karakters in dit geval):
Figuur 100: Oplossen van een pointer probleem
- Zoals hierboven vermeld staat zijn pointers uiterst belangrijk bij C en C++ code. Een tweede voorbeeld toont dit aan:
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
90
Plots werd vastgesteld dat code, die vroeger perfect functioneerde, niet meer werkt na het bijprogrammeren van totaal andere softwareblokken. Blijkbaar werden eerder opgeslagen variabelen in het geheugen overschreven. De XML-parser geeft pointers naar uitgelezen waarden mee. Deze waarden worden verder in het programma gebruikt. Omdat enkel de pointer ter beschikking wordt gesteld, is de data, naar waar de pointer wijst, onbereikbaar geworden. Via een omweg kopieer ik de inhoud naar een nieuwe karakterrij. De software die de informatie via pointers ter beschikking stelt is software die reeds aanwezig was. Er werd geen rekening gehouden met het pointerprobleem maar via een kopie van de waardes wordt het verholpen. - Bij het aanmaken van een scherm werkte plots de PEG+ timer niet meer. We zijn toen op zoek gegaan naar de oorzaak van dit probleem en na een dag grondig zoeken ontdekten we wat er scheelde. Bij het ophalen van de XML-file werd die op de stack geplaatst. Hiervoor had de programmeur, van de software in kwestie, 6kB gereserveerd in een (deel)stack die slechts 4kB aankan. De totale stack is natuurlijk veel groter dan 4kB maar deze wordt onderverdeeld en de deelstack kon de 4kB niet aan. Door de gegevens op een gereserveerd stuk geheugen te plaatsen lossen we dit probleem op. We maken de gereserveerde ruimte static in onze code. Dit probleem had dus geen direct verband met de timer van PEG+ maar doordat het geheugen overschreven werd, raakte de timer in moeilijkheden. Zo wordt duidelijk dat een probleem soms veroorzaakt wordt door een oorzaak waarop je niet meteen denkt. Geheugenbeheer is erg belangrijk.
PEG+ - Voor de WindowBuilder: sla de wijzigingen tijdig op. Het programma is gedurende de masterproef meer dan eens “gecrasht”. Bemerk dat de reflex “control S” hier niet werkt. - Bij het bestand HcdSlave.c staat de vermelding #include "peg.hpp" nog voor de include van zijn eigen header file. Een latere vermelding van peg.hpp geeft problemen die niet direct af te leiden zijn uit bijhorende foutmeldingen. - In de API en programmers manual van PEG+ staat veel maar het is niet altijd even duidelijk, een voorbeeld helpt de programmeur vaak beter op weg. Één van die zaken is de de verzending van een bericht. In deze uiteenzetting en het HCD-project staan heel wat voorbeelden. - Wanneer een bericht in een klasse wordt opgevangen kan het zijn dat die nog moet doorgegeven worden aan een parent klasse. De regel “Pegdialog::message” lost dit op. Bij het vergeten van de regen loopt het fout.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
91
- Als in de API niet snel wordt teruggevonden welke berichten een PegThing afhandelt kan in de CPP bestanden gekeken worden. De Switch-case structuur verduidelijkt snel, daar waar de API tamelijk lang is en niet overal even duidelijk. - Wanneer de programmeur wil weten of een bepaald object een functie ondersteunt dan kan zijn .c bestand (de klasse) duiding geven. Bemerk dat de functie ook opgevuld kan zijn door mogelijke parents, in dat geval is de functie ondersteund maar niet te zien in de eigen klasse. Bij de HCD werden deze bestanden vaak geraadpleegd naar mogelijke attributen en functies bij een klasse-object (zelfst vaker dan de API). - De API en programmers manual is heel handig om het concept rond PEG+ te begrijpen, een blik op de bestanden van de effectieve softwarebibliotheek is handig bij het programmeren.
Algemeen - Hou rekening met de design rules bij het opstellen van een .c of .h bestand. - Controleer of de aangesloten toestellen, in deze masterproef de slaves, de juiste software bevatten. Vooral bij een nieuwe applicatie die getest wordt denkt men vaak dat de fout aan de applicatie zelf ligt en niet aan de aangesloten, voorgeprogrammeerde toestellen. Soms duurt het even voor dit ontdekt wordt. - Er wordt sterk aanbevolen de bestanden elke avond in Perforce in te checken en tijdig te syncen.
Hanne Deschildre
Hoofdstuk 5: XML-structuur en opmerkingen
92
Besluit Voor de aansturing van toestellen wordt vaak gezocht naar de meest geschikte interface om toestelparameters aan de gebruiker weer te geven. Bij deze masterproef werd opdracht gegeven om een handheld device te programmeren als interface naar aangesloten toestellen. De handheld hardware bestaat reeds en is gebaseerd op een bestaande vaste module. De schermen worden grafisch opgebouwd aan de hand van een softwarebibliotheek PEG+. Communicatie met aangesloten toestellen wordt voorzien via het Modbus protocol en er wordt rekening gehouden met een latere implementatie van CANopen.
PEG+ Een software bibliotheek, PEG+, moet worden gebruikt om schermen op te bouwen en interactie met de gebruiker te voorzien. Na een grondige studie werd een schermstructuur samengesteld. De studie was heel belangrijk om de PEG+ objecten en hun functionaliteiten te leren kennen. Op die manier werd de schermstructuur theoretisch opgebouwd met maximale benutting van PEG+ faciliteiten. Bovendien werd er gecontroleerd of alle theoretische beschouwingen later praktisch programmeerbaar waren met de bibliotheek. Bij het effectief programmeren van de schermen kon, dankzij deze diepgaande studie, alles voor de theoretisch uitgewerkte schermen zonder aanpassingen geprogrammeerd worden. De PEG+ studie ging gepaard met 2 protocolstudies. Modbus en CANopen werden onderzocht naar hun werking en mogelijkheden voor deze handheld.
Modbus en CANopen Aangezien oorspronkelijk CANopen geïmplementeerd moest worden, werd gestart met een diepgaande studie ervan. Hieruit bleek dat het een veelzijdig, ingewikkeld protocol is dat veel mogelijkheden biedt voor de handheld. Later werd overgegaan tot Modbus als primair protocol waardoor ook hiernaar onderzoek werd verricht. De effectieve implementatie van Modbus gebeurde aan de hand van bestaande software. De methodes moesten correct worden gebruikt binnen de PEG+ schermsoftware. Naast het gebruik van bestaande methodes werden communicatieproblemen, specifiek voor de handheld, aangepakt met eigen communicatiealgoritmes.
XML-structuur De handheld moet alle Modbus toestellen op zijn bus herkennen. Indien gewenst, moeten er per slave specifieke schermen worden weergegeven. Om deze schermen at runtime op te bouwen moet de handheld per aangesloten toestel over extra, specifieke informatie
Hanne Deschildre
93
beschikken. Hiervoor wordt de SD-kaart gebruikt die voorzien is bij de handheld. Er werd gezocht naar een uniforme structuur om de informatie aan te bieden. Via een XML-bestand per slave kan de programmeur slave-specifieke schermen op gebied van layout en inhoud volledig zelf bepalen. De structuur verschilt voor Modbus- en CANopentoestellen. De bestanden voor Modbus slaves worden softwarematig ingelezen door de handheld, geparst en geven de gewenste schermen weer. Bij onderzoek naar een dergelijke XML-structuur was een goede kennis van XML-mogelijkheden nodig. Ook moest onderzocht worden welke informatie vereist is om via Modbus of CANopen de nodige gegevens op te halen of weg te schrijven.
Resultaat De handheld kan elk Modbus toestel interfacen op de manier die de gebruiker wenst. Op structureel gebied is alles uitgewerkt en het idee staat volledig vast. 4 van de 6 schermen die gedemonstreerd worden, werken zoals het hoort en voor de resterende 2 is het pad geëffend via een duidelijke omschrijving in het masterproefverslag. Het primair protocol (Modbus) werd grotendeels voorzien en het CANopen protocol werd volledig in rekening gebracht. De handheld kan er probleemloos mee uitgebreid worden zodra de CANopen stack beschikbaar is op dit platform.
Hanne Deschildre
94
Literatuurlijst 1. PEG+ Artikels en documenten Beurghs, J., Objectgeoriënteerd programmeren, Druk 1. Kelly, A. and Pohl, I., De programmeertaal C, Vierde editie. Pearson Education Benelux, 2005 Lafore, R., Object-Oriented Programming in C++, Third edition. PsiControl Mechatronics, Design rules C-style guidelines, revision 01. 2008 PsiControl Mechatronics, PEG+ presentatie. 2007 Stroustrup, B., History of programming languages. New York: ACM. 1996 Swell Software, API Reference Manual PEG+ Library Release 1.96, Second printing. 2006 Swell Software, PEG+ Programming Manual, Tenth Printing. 2006 Swell Software, PEG Development toolkit User’s Manual, First Printing. 2005
Programma’s PEG Window Builder, release 1.98.c, Swell Software PEG Imageconvert, release 1.98.c, Swell Software PEG FontCapture, release 1.98.c, Swell Software VisualDSP++ IDDE, 4.5, Analog Devices
2. Modbus Documenten PsiControl Mechatronics, Oxi™ Functional Description.2008. PsiControl Mechatronics, Oxi™ Proto CLDRV8 Board, revision 02. 2007. Modbus-IDA, Modbus Application Protocol, V1.1 b. 2006. Hanne Deschildre
I
Websites Modbus. 15/04/2009. http://www.icpdas.com/products/PAC/i-8000/modbus.htm Modbus. 28/12/2006. 03/04/2009. http://www.Modbus-IDA.org Modbus. 09/04/2009. http://www.lammertbies.nl/comm/info/nl_modbus.html Modbus protocol, 07/04/2009. http://www.intellicom.se/modbus.shtml Protocol, 05/04/2009. http://jamod.sourceforge.net/kbase/protocol.html
3. CANopen Artikels en documenten Decouttere, T., CAN_OPEN_TDCT. 2008 Deniere, F., CANopen2. 2008. Vankeirsbilck, G., DS_BSD_20080212_UK_V0011. Cavalieri, S., Proposal and evaluation of dynamic assignment of priorities in CAN. University of Catania, 2005.
Websites Can in Automation. 23/11/2008. http://www.can-cia.org Can information. 11/04/2009. http://www.thaiio.com/CANinfo CAN dictionary. 03/04/2009. http://www.can-cia.org/fileadmin/cia/pdfs/CANdictionary v4.pdf CANopen OD indexen. 23/03/2009. http://www.lpkf-mc.de/others/4/1651-dac1005 object dictionary.pdf CANopen PDO’s. 15/10/2008. http://www.esacademy.com/faq/docs/canopen/pdos.html CANopen.03/03/2009. http://74.125.77.132/search?q=cache:pS8apwqkm0EJ:www.triomotion .com/upload/TN30_11-%2520CAN%2520Peer_Peer.pdf+canopen+ds202&cd=8&hl=nl&ct= clnk Softing. 12/04/2009. http://www.softing/home/index.php
Hanne Deschildre
II
4. XML Artikels Kelsey, R., XML-based representation. 01/02/2009
Websites Application Development. 03/03/2009. http://www.jkp-ads.com/Articles/XMLAndExcel04NL .asp Build lightweight XML DOM parser. 04/03/2009. http://www.devx.com/xml/Article/10114/0/ page/4 Tiny XML. 08/03/2009. http://www.grinninglizard.com/tinyxmldocs/index.html The skew.org XML Tutorial. 12/03/2009. http://skew.org/xml/tutorial
Hanne Deschildre
III
Bijlagen PEG+ Bijlage 1: PEG+ is porteerbaar naar elk systeem. Hierbij ook het systeem van deze masterpoef.
Figuur 101: De compilers en processors mogelijk voor PEG+ Hanne Deschildre
Bijlagen
I
Bijlage 2: Voorbereidingen om de PEG+ bibliotheek te kunnen gebruiken:
-
Voeg de library toe. Stel het pconfig.h bestand in: - Selecteer target system - Selecteer screen driver - Keyboard input - Mouse input -…
-
Wanneer iets niet werkt wordt af en toe gecontroleerd of de juiste selecties zijn gemaakt in dit pConfig.h bestand.
Bijlage 3:
Figuur 102: Voorbeelden van mogelijke berichten
Hanne Deschildre
Bijlagen
II
Bijlage 4: Om te kunnen scrollen werd gezocht naar de nodige berichten. Dit staat niet vermeld in de API of programmers manual. Uiteindelijk leidt het volgende bericht tot een scroll commando. In de masterproef werd het nog niet geïmplementeerd. De elementen die moeten verplaatst worden via een scroll beweging zitten allemaal in een window waarnaar de pointer ptrWindow wijst. Ze worden verplaatst door het volgende bericht te zenden: PegMessage* mssg1 = new PegMessage(); mssg1->wType = PM_VSCROLL; mssg1->lData = 2; mssg1->iData = 10; ptrWindow->Message(*mssg1);
Er wordt gescrold over (IData - lData) pixels. Scrollen naar de andere kant kan door de waardes van lData en iData om te wisselen. Bemerk dat in pConfig.hpp de definitie FAST_BLIT in commentaar werd gezet.
Bijlage 5:
Figuur 103: Eerste voorstel voor een schermstructuur
Een eerste schermvoorstel. Dit werd ingediend nog voor de uiteenzetting van de projectingenieurs. Na veel overleg evolueerde het tot een veel gedetailleerdere boomstructuur.
Hanne Deschildre
Bijlagen
III
Modbus Bijlage 1:
Figuur 104: RJ11 connector
Bijlage 2:
Hanne Deschildre
Bijlagen
IV
Figuur 105: Modbus exception codes
Hanne Deschildre
Bijlagen
V
CANopen Bijlage 1:
Figuur 106: Voorbeeld van een OD ingang
In de software moet index 1018h al deze gegevens kunnen stockeren. Een object dictionary is dus meer dan een gewone tabel. Hanne Deschildre
Bijlagen
VI
Bijlage 2: Object
Functie code (binair)
Rest van de COB-ID (hex)
Database Database Commentaar Communica- Mapping tion Index Index
NMT SYNC
0000 0001
0h 80h
(1005h)
-
Broadcast Broadcast
Emergency PDO1 (tx) PDO1 (rx) PDO2 (tx) PDO2 (rx) PDO3 (tx) PDO3 (rx) PDO4 (tx) PDO4 (rx) SDO (tx) SDO (rx) Node guarding
0001 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100
81h-FFh 181h-1FFh 201h-27Fh 281h-2FFh 301h-37Fh 381h-3FFh 401h-47Fh 481h-4FFh 501h-57Fh 581h-5FFh 601h-67Fh
(1014h) 1800h 1400h 1801h 1401h 1802h 1402h 1803h 1403h
1A00h 1600h 1A01h 1601h 1A02h 1602h 1A03h 1603h
Jumper setting + 080H Jumper setting + 180H Jumper setting + 200H Jumper setting + 280H Jumper setting + 300H Jumper setting + 380H Jumper setting + 400H Jumper setting + 480H Jumper setting + 500H Jumper setting + 580H Jumper setting + 600H
1110
701h-77Fh
(100Eh)
Jumper setting + 700H
Figuur 107: Overzicht van de functie codes
-
(rx) en (tx) worden gezien vanuit slave standpunt Bemerk dat functie code 0010 (Time Stamp) niet gebruikt wordt, de applicaties zijn meestal niet zo tijdskritisch dat ze een dergelijke accurate synchronisatie vereisen. De jumper settings zijn jumpers op elke slave die het nodeadres aanduiden.
Bijlage 3:
Figuur 108: Mogelijke CANopen berichten per state
Hanne Deschildre
Bijlagen
VII
Bijlage 4:
Figuur 109: Heartbeat principe
Bijlage 5:
Figuur 110: DB9 connector
Hanne Deschildre
Bijlagen
VIII
