Masterproef Tester Real-Time Software For Weaving Machine

Masterproef Tester Real-Time Software For Weaving Machine

Studiegebied Industriële wetenschappen en technologie Opleiding Master of Science in de industriële wetenschappen: elektromechanica Academiejaar 2011-2012

Jeroen Vandenweghe Academische bachelor- en masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

Voorwoord Nadat ik mijn diploma Bachelor Elektromechanica behaald had, startte ik het brugprogramma Industrieel Ingenieur Elektromechanica optie Elektromechanica aan de Hogeschool West-Vlaanderen, campus PIH te Kortrijk. En nu als laatstejaarsstudent sta ik klaar om mijn masterjaar in ere en mooi af te sluiten. Allereerst wil ik de firma PsiControl Mechatronics bedanken voor de mogelijkheden die zij mij gegeven hebben om dit eindwerk te kunnen realiseren. Een bijzonder woord van dank gaat uit naar mijn externe promotor De Heer Chris Noppe die dit werk opgevolgd en begeleid heeft. Zijn visie en raad hebben me doorheen het ganse project geholpen. Zijn bereidwilligheid om mijn vragen en problemen op te lossen hebben mede geleid tot het welslagen van dit eindwerk. Ook wil ik De Heer Jos Knockaert, mijn interne promotor, bedanken, die altijd klaar stond om te helpen. Tenslotte nog een woord van dank aan mijn familie die mij altijd gesteund hebben om deze studie tot een goed einde te brengen. Vandenweghe Jeroen Mei 2012

II Masterproef 2011-2012 / Vandenweghe Jeroen

Abstract This book is a report of my final year project. For my thesis I chose the company PsiControl Mechatronics. The company is a subsidiary of the Picanol Group and focuses on the design, development, production and support for the electronic and mechatronic systems in weaving machines. PsiControl Mechatronics has a hardware-in-the-loop model of a weaving machine that runs on a National Instruments PXI system. But for the moment not all devices ( ex. Valves) are integrated in the simulation. The simulator consists of 70% HIL models and 30% devices who are still physically integrated in de simulator setup and the test coverage is only 5% at the moment. Making a 100% HIL modeled simulator is not possible, because it entails a cost that would be too high. On the other hand making a 100% SIL or Software-in-the-Loop modeled simulator will also not be possible, because of the Real-Time aspect that is needed for weaving machines. The main goal of the project is checking if it is possible to make a 100% modeled weaving machine that can be implemented in a simulator setup. This model will be a merger between HIL and SIL models that has a acceptable cost, Real-Time aspect and a test coverage of 100%. The devices who are still integrated in the simulator are controlled by slave boards who communicate with a master board. The first step in this project is making a program that is able to read and analyze all communication between de master en slave boards. This way it can be determent if it is possible to gather the useful data and this without any mistakes. The second step in the project is simulating the slave boards. Here the program will start sending over data to the master instead of the slave boards. The answers that are send back from the slaves are depended of the data that the first part of the program has gathered. The conclusion for the this thesis is that the first steps in making a 100% weaving machine simulator has a positive outcome. The designed program is capable of reading and analyzing all communication between master and slave boards. It ‘s also able to communicate with the master without having a physical slave board.

III Masterproef 2011-2012 / Vandenweghe Jeroen

Inhoudsopgave

Voorwoord .............................................................................................................................................................. II Abstract .................................................................................................................................................................. III Inhoudsopgave ....................................................................................................................................................... IV Lijst met figuren ..................................................................................................................................................... VI 1.

2.

3.

Inleiding ........................................................................................................................................................... 1 1.1

Voorstelling van het bedrijf ................................................................................................................... 1

1.2

Doelstelling ............................................................................................................................................ 2

Werking van een weefmachine ....................................................................................................................... 3 2.1

Principe .................................................................................................................................................. 3

2.2

Huidige situering simulator ................................................................................................................... 5

2.3

Situering masterproef ............................................................................................................................ 8

HIL, SIL of MIL .................................................................................................................................................. 9 3.1

Hardware in the Loop ............................................................................................................................ 9

3.2

Software in the Loop ........................................................................................................................... 12

3.3

Model in the Loop ............................................................................................................................... 12

4.

Embedded systemen ..................................................................................................................................... 13

5.

Real-Time systemen ...................................................................................................................................... 14

6.

Fast Serial Bus ( FSB ) .................................................................................................................................... 15

7.

8.

6.1

Fysische laag ........................................................................................................................................ 16

6.2

Datatransmissie ................................................................................................................................... 17

6.2.1

Berichtformaat ................................................................................................................................ 17

6.2.2

Mogelijke modes ............................................................................................................................. 18

6.3

Controle Checksum .............................................................................................................................. 19

6.4

Voorbeeld datatransmissie op de bus ................................................................................................. 21

National Instruments .................................................................................................................................... 22 7.1

Software .............................................................................................................................................. 22

7.2

Hardware ............................................................................................................................................. 24

7.3

Kostprijs ............................................................................................................................................... 26

Alternatieve mogelijkheden .......................................................................................................................... 27 8.1

ADLINK Technology.............................................................................................................................. 27

8.2.1

Software .......................................................................................................................................... 27

8.2.2

Hardware ......................................................................................................................................... 27

8.2.3

ADLINK Technology versus National Instruments ........................................................................... 28

IV Masterproef 2011-2012 / Vandenweghe Jeroen

8.2

Agilent Technologies............................................................................................................................ 28

8.2.1

Software .......................................................................................................................................... 28

8.2.2

Hardware ......................................................................................................................................... 29

8.2.3

Agilent Technologies versus National Instruments ......................................................................... 29

8.3

MathWorks .......................................................................................................................................... 30

8.3.1

Software .......................................................................................................................................... 30

8.3.2

Hardware ......................................................................................................................................... 31

8.3.3

MathWorks versus National Instruments ....................................................................................... 31

8.4

9.

dSPACE ................................................................................................................................................. 32

8.4.1

Software .......................................................................................................................................... 32

8.4.2

Hardware ......................................................................................................................................... 32

8.4.3

dSPACE versus National Instruments .............................................................................................. 32

Testopstelling ................................................................................................................................................ 33 9.1

Testopstelling probleem ...................................................................................................................... 33

9.2

Testopstelling oplossing ...................................................................................................................... 34

10.

Programma .............................................................................................................................................. 36

10.1

Aanmaken project ............................................................................................................................... 36

10.2

Inlezen datalijnen ................................................................................................................................ 36

10.2.1

Controle datalijnen ..................................................................................................................... 37

10.2.2

Bepalen flank FSB clock ............................................................................................................... 38

10.3

10.3.1

Mode en Adres bepalen .............................................................................................................. 39

10.3.2

Data bepalen ............................................................................................................................... 42

10.3.3

Controle data .............................................................................................................................. 43

10.3.4

Checksum controle ..................................................................................................................... 45

10.3.5

Controle checksum ..................................................................................................................... 45

10.3.6

Startwaarde ................................................................................................................................ 46

10.4

11.

Data analyseren ................................................................................................................................... 38

MISO lijn schrijven ............................................................................................................................... 47

10.4.1

Start schrijven MISO ................................................................................................................... 47

10.4.2

Controle start schrijven MISO ..................................................................................................... 48

10.4.3

Interruptvragen ........................................................................................................................... 48

10.4.4

Ms Opvragingen .......................................................................................................................... 52

10.4.5

Commando’s ............................................................................................................................... 53

Besluit ...................................................................................................................................................... 55

Bibliografie ............................................................................................................................................................ 57 Bijlagen .................................................................................................................................................................. 58

V Masterproef 2011-2012 / Vandenweghe Jeroen

Lijst met figuren Figuur 1: Bedrijfslogo .............................................................................................................................................. 1 Figuur 2: Picanol Weefmachine .............................................................................................................................. 3 Figuur 3: Weef Principe ........................................................................................................................................... 3 Figuur 4: Principe Weef - Assen .............................................................................................................................. 4 Figuur 5: Block Diagram Simulator .......................................................................................................................... 5 Figuur 6: Schema simulator..................................................................................................................................... 6 Figuur 7: Simulator opstelling ................................................................................................................................. 7 Figuur 8: Huidige simulator versus toekomstige simulator .................................................................................... 8 Figuur 9: Principe HIL .............................................................................................................................................. 9 Figuur 10: Blokschema HIL ...................................................................................................................................... 9 Figuur 11: Voorbeelden Real-Time target ............................................................................................................. 10 Figuur 12: Toepassingen HIL systemen ................................................................................................................. 11 Figuur 13: Block diagram Software in the Loop .................................................................................................... 12 Figuur 14: Verschil Soft en Hard Real-Time........................................................................................................... 14 Figuur 15: Datatransmissie ethernet .................................................................................................................... 15 Figuur 16: Fysische laag FSB .................................................................................................................................. 16 Figuur 17: Datatransmissie FSB bus ...................................................................................................................... 17 Figuur 18: Lineair Feedback Shift Register ............................................................................................................ 19 Figuur 19: Werking vier bit Shift Register ............................................................................................................. 19 Figuur 20: Werking XOR Shift Register .................................................................................................................. 19 Figuur 21: Uitwerking voorbeeld checksum ......................................................................................................... 20 Figuur 22: Voorbeeld datatransmissie FSB bus ..................................................................................................... 21 Figuur 23: Voorbeeld LabVIEW schema ................................................................................................................ 23 Figuur 24: Werking FPGA ...................................................................................................................................... 25 Figuur 25: Besteklijst National Instruments .......................................................................................................... 26 Figuur 26: ADLINK DAQPilot .................................................................................................................................. 27 Figuur 27: ADLINK hardware ................................................................................................................................. 27 Figuur 28: Agilent VEE pro..................................................................................................................................... 28 Figuur 29: Agilent Technology hardware .............................................................................................................. 29 Figuur 30: Script MATLAB...................................................................................................................................... 30 Figuur 31: Voorbeeld Simulink model ................................................................................................................... 31 Figuur 32: Mathworks Turnkey ............................................................................................................................. 31 Figuur 33: Testopstelling FSB ................................................................................................................................ 33 Figuur 34: Verbinding PXI en FSB bus ................................................................................................................... 34 Figuur 35: Scoopbeeld Clock FSB 1m kabel ........................................................................................................... 34 Figuur 36: Scoopbeeld Clock FSB ingekorte kabel................................................................................................. 35 Figuur 37: Scoopbeeld Clock FSB ingekorte kabel + RC filter ................................................................................ 35 Figuur 39: Datalijnen FSB ...................................................................................................................................... 36 Figuur 38: Structuur LabVIEW project ................................................................................................................... 36 Figuur 40: Controleren van ingelezen datalijnen .................................................................................................. 37 Figuur 41: Datalijnen FSB versus naar buiten gestuurde datalijnen ..................................................................... 37 Figuur 42: Controle stijgende/dalende flank clock ............................................................................................... 38 Figuur 43: Bepalen Mode en Adres ....................................................................................................................... 39

VI Masterproef 2011-2012 / Vandenweghe Jeroen

Figuur 44: Scoopbeeld bepalen Mode .................................................................................................................. 39 Figuur 45: Wegschrijven mode/adres in FIFO ....................................................................................................... 40 Figuur 46: Schrijven Mode/Adres in FIFO Data Log .............................................................................................. 40 Figuur 47: Controle mode/adres fout ................................................................................................................... 41 Figuur 48: Controle mode correct ......................................................................................................................... 41 Figuur 49: Bewaren data MOSI 0/MOSI 1 ............................................................................................................. 42 Figuur 50: Schrijven data MOSI 0-1 in FIFO Data Log ............................................................................................ 43 Figuur 51: Controle data MOSI 0-1 fout ................................................................................................................ 43 Figuur 52: Databits verloren tijdens inlezen ......................................................................................................... 44 Figuur 53: Loop programma versie 1 .................................................................................................................... 44 Figuur 54: Controle checksum .............................................................................................................................. 45 Figuur 55: Scoopbeeld checksum .......................................................................................................................... 45 Figuur 56: Scoopbeeld startwaarde ...................................................................................................................... 46 Figuur 57: Start schrijven MISO lijn ....................................................................................................................... 47 Figuur 58: Controle start schrijven op MISO ......................................................................................................... 48 Figuur 59: Start schrijven MISO correct ................................................................................................................ 49 Figuur 60: Statemachine Interruptvragen ............................................................................................................. 49 Figuur 61: Slave 6 schrijft niet op MISO ................................................................................................................ 50 Figuur 62: Slave 6 schrijft op MISO ....................................................................................................................... 50 Figuur 63: FSB Debugger Interruptvragen ............................................................................................................ 51 Figuur 64: FSB Debugger Ms Opvragingen ............................................................................................................ 53 Figuur 65: Bepalen commando's ........................................................................................................................... 54 Figuur 66: Blokschema ontworpen model ............................................................................................................ 55

VII Masterproef 2011-2012 / Vandenweghe Jeroen

1. Inleiding 1.1

Voorstelling van het bedrijf

Figuur 1: Bedrijfslogo

PsiControl Mechatronics is lid van de Picanol groep. De Picanol groep is een internationale groep die zich toelegt in de ontwikkeling, productie en verkoop van weefmachines en hoogperformante producten, systemen en diensten. De groep streeft naar een actief innovatiebeleid en investeert constant in nieuw onderzoek en ontwikkeling. De dochteronderneming PsiControl Mechatronics richt zich vooral op het ontwerp, ontwikkeling, productie van elektrische en mechatronische systemen. Het bedrijf heeft een sterk klantgerichte visie en wil steeds het hoogst mogelijk niveau van kwaliteit behalen in hun branche. Om dit te kunnen realiseren streven ze continue naar het verbeteren van efficiëntie, ontwikkeling van de meest innovatieve processen in de industrie en zorgen voor een sterk communicatie beleid in het productie proces.

1 Masterproef 2011-2012 / Vandenweghe Jeroen

1.2

Doelstelling

PsiControl Mechatronics heeft als doel de volledige weefmachine te simuleren om de embedded software automatisch te testen. Op heden gebeurt dit met een aantal weefmachine componenten die niet gesimuleerd worden en dus als devices aanwezig zijn in de simulator omgeving (vb. kleppen, stappenmotoren). De reden hiervoor is dat enorm veel inspanningen kost om stappenmotoren en kleppen in een model om te zetten, zowel naar hardware en software toe. Het simuleren van motoren en kleppen komt overeen met het simuleren van stromenopbouw in een spoel. Hierdoor kwam het idee om niet meer Hardware In the Loop (HIL) te gaan testen, maar een deel van de hardware, namelijk slaveboards, niet meer op te nemen in het simulator model. Veel van die devices worden door slave boards gestuurd. Deze slave boards communiceren met de hoofdprocessor via de FSB (Fast Serial Bus). Dit is een eigen hardware en software ontwerp van PsiControl Mechatronics. Met dit project wil men nagaan of het mogelijk is om alle slave boards, die via de FSB bus communiceren met de hoofdprocessor, te vervangen door een simulator. Hiervoor moet dus het hardware en software protocol van de FSB bus geïmplementeerd worden op een simulator, waarna ook alle logica van de slave boards dient gesimuleerd te worden. Het doel van dit project is de haalbaarheid in kaart te brengen. PsiControl Mechatronics heeft een kostenbaten analyse nodig om te beslissen de volledige uitwerking van dit project verder te zetten. De eerste stap van de opdracht bestaat erin de volledige werking van de FSB te begrijpen, en zicht te krijgen op de huidige toestand van de simulator, om daarna mogelijke opties te onderzoeken en deze met elkaar te vergelijken. Indien de investering het toelaat, zal een proof_of_concept uitgewerkt worden. Deze masterproef is onderdeel van een project bij i-MOCCA INTERREG.


2. Werking van een weefmachine

Figuur 2: Picanol Weefmachine

2.1

Principe

Weefmachines [4] bezitten twee types draden ( garens), namelijk de kettingdraad of scheringdraad en de inslagdraad. Deze kunnen zowel van wol, katoen, zijde of glasvezel zijn. De kettingdraden zijn allemaal parallel naast elkaar gespannen en de inslagdraad wordt tussen de kettingdraden gevlochten. Door middel van weeframen ( kaders ) worden de kettingdraden op en neer bewogen. Als we er vanuit gaan dat een weefmachine vier weeframen heeft, gebeurt dit als volgt: de eerste kettingdraad gaat door het eerste oogje van het eerste weefraam, de tweede kettingdraad gaat door het eerste oogje van het tweede weefraam, de derde draad gaat door het eerste oogje van het derde weefraam, de vierde kettingdraad gaat door de het eerste oogje van het vierde weefraam, de vijfde kettingdraad gaat door het tweede oogje van het eerste weefraam, enz.…

Figuur 3: Weef Principe

Als we dan alle even kaders naar boven laten bewegen en alle oneven kaders naar beneden, ontstaat er een gaap ( opening ). In deze gaap wordt één of meerdere inslagdraden van links naar rechts gebracht, dit kan door gebruik te maken van een weefspoel of met behulp van perslucht waar de inslagdraad erdoor wordt geblazen. Een inslagwachter zal controleren of de inslagdraad de overzijde gehaald heeft vooraleer de weefmachine verdergaat. De aanslag ( weefriet ) zal telkens de inslag draad aandrukken. De aanslag is een lang rechthoekig raam dat bestaat uit lamellen ( fijne ijzeren strips) die de kettingdraden onderling evenwijdig houden. Daarna zullen de


kaders de omgekeerde beweging maken om dan opnieuw één of meerdere inslagdraden door de ontstane opening te blazen. Deze procedure wordt constant herhaald. Andere stoffen kunnen geproduceerd worden door de kaders op verschillende manieren te laten bewegen t.o.v. elkaar of door de kettingdraden op andere plaatsen in de kaders aan te brengen.

Figuur 4: Principe Weef - Assen

De hoofdas (2) van de Picanol weefmachine wordt aangedreven door een SR motor ( Switched Reluctance), waar een hoekopnemer opstaat die de positie terug stuurt. Deze as gaat door middel van een 1:1 overbrenging de kader- en ladeas gaan aandrijven. De ladeas (1) dient om de aanslag naar voor en naar achter te bewegen en drukt de inslagdraden na het doorblazen aan. De derde as is de kaderas (3), deze zorgt voor de op en neer gaande beweging van de kaders, deze beweging is afhankelijk van het type weefsel die geproduceerd wordt. Om een zo optimale weefselkwaliteit te verkrijgen, wordt zoveel mogelijk verhinderd dat het riet (op lade as) het weefsel onnodig gaat aanraken. Dit doet men door middel van het vastzetten van de lade as (1) ( hoofdas axiaal laten bewegen). Op deze manier kan de kaderas blijven bewegen zonder het gevormde weefsel onnodig te aanraken met het riet. Om ervoor te zorgen dat de lade as (1) niet verdraaid is er per 15° een pengat voorzien om het tandwiel vast te zetten. Op deze manier gaat de positie van de lade as niet verloren en kan de kader as manueel bewogen worden.


2.2

Huidige situering simulator

Het nut van de Picanol Weef Machine HIL is het testen van de besturing software. Daar er voor de weefmachine meer dan 1000 mogelijke configuraties zijn, is het onmogelijk om elk besturingssoftware in de praktijk te testen. Een simulator is dus nodig om al deze configuraties te testen. De HIL moet ook voldoen aan bepaalde specificaties, hieronder behoort onder andere het simuleren van een toerental van 0 – 2000 rpm met een nauwkeurigheid van 0,5 rpm en 0,1°. Het doel van het HIL systeem bestaat uit twee grote aspecten: 1) De programmeurs willen nieuwe functies kunnen testen van de sofware applicaties op de simulator. Daarnaast moeten ze de mogelijkheid hebben om fouten (bv. signaal dat te laat binnenkomt ) te generen om de nieuwe functie te testen. 2) Het tweede grote aspect is het Automatic Test System ( ATS ). De besturingssoftware moet een functionele test ondergaan, omdat elke vernieuwing van de software kan resulteren in een bug. De ATS moet de toegang hebben tot de machine parameters en controleren of de besturing zich gedraagt zoals deze vooraf is opgesteld. Als de ATS een fout detecteert in de besturing software moet deze de fout kunnen loggen, zodoende dat de programmeur hierop een oplossing kan vinden.

Figuur 5: Block Diagram Simulator

In bovenstaande figuur wordt de weefmachine voorgesteld in een blok diagram. Deze bestaat uit drie onderdelen, namelijk HMI (Human Machine Interface), Machine Controller en de Machine Simulator.

Mc Uh Uc Y Uh

Berichten van machine controller naar HMI Inputs van HMI ( parameter aanpassingen, setpoints,enz.) naar machine controller Inputs van machine controller naar machine simulator Feedback van simulator naar machine controler Extra vector tussen HMI en simulator die de mogelijkheid biedt de communicatie tussen de twee na te gaan.


Het HIL systeem is eigenlijk een MIMO (Multiple-Input Multiple Output) systeem, waarbij het aantal inputs niet gelijk hoeft te zijn aan het aantal outputs. Omdat een HIL systeem de machine dient na te bootsen, wordt de HIL verbonden met de output vector Uc van de machine controller en de output vector Y van de machine simulator (HIL) wordt verbonden met de machine controller. De controller van de weefmachine is gebaseerd op een PowerPC processor bord die communiceert met meerdere I/O via een FSB (Fast Serial Bus). Het PowerPC-board heeft een FPGA voor alle tijdkritische systemen. Daarnaast is het PowerPC-board voorzien van twee CAN bussen die dienen om apparaten en drives te interfacen. De reden voor gebruik te maken van een CAN bus is dat deze betrouwbaarder en snelleer zijn dan ethernet. Een ethernet link wordt gebruikt om te communiceren tussen de machine controller en de HMI. Van de twee CAN bussen is er slecht één die gebruikt kan worden om een nieuw apparaat op aan te sluiten. De CAN bus die niet aangepast kan worden is degene waar de hoofdmotor, ELO( Electrical Let Off) en ETU(Electrical Take Up) zich op bevinden. De ELO staat in voor de ketting aflaat en de ETU voor de doekopwikkeling na het weven. De andere CAN bus is de bus waar de VAW ( Voor Af Wikkelaar ), IW ( Inslag Wachter ), enz. zich op bevinden. Door de vele configuratie mogelijkheden veranderen deze constant en moet de CAN bus dus bij iedere configuratie hergedefinieerd worden. De machine heeft een cyclus van 30ms bij 2000rpm en per cyclus worden er zo’n 150 input/output signalen verzonden/ontvangen.

Figuur 6: Schema simulator


Het HIL systeem moet meerdere loops kunnen uitvoeren op verschillende frequenties. De meeste loops moeten minstens werken op 2kHz en een groot deel hiervan dient te werken op een frequentie die kan oplopen tot 120kHz. De enige hardware die hiervoor krachtig genoeg is, is een FPGA. Deze FPGA moet in staat zijn om meerdere parallelle loops uit te voeren en gelogde data terug te sturen naar de Real-Time host. Als het blokschema in figuur 5 vergeleken wordt met de praktijk, dan is de Machine Simulator vervangen door de machine zelf. De vector Uh van de HMI naar de HIL is een extra vector die gebruikt wordt voor het detecteren van ethernet berichten tussen de HMI en de machine controller. Deze verbinding is een essentieel onderdeel van de ATS, maar niet van de HIL. De communicatie tussen HMI en machine controller gebeurt via vector Mc en Uh. De vector Mc stuurt berichten naar de HMI voor de gebruiker en Uh stuurt de inputs van de HMI naar de controller. Vector Uc stuurt de inputs van de controller naar de machine.

Figuur 7: Simulator opstelling


2.3

Situering masterproef

Het einddoel van de simulator is het automatische kunnen testen van nieuwe versies van de software en het gedrag controleren indien er een fout optreedt. Op heden kunnen alreeds verschillende fouten manueel gecontroleerd worden zoals een gebroken draad, een inslagdraad die te laat komt of kleppen die niet functioneren. Voor vele van deze fouten is reeds een model ontwikkeld om dit te kunnen simuleren, maar voor de kleppen bestaat er enkel een model die relais aanstuurt om de fysiek aanwezige kleppen te onderbreken. Dit heeft als gevolg dat deze niet real-time gesimuleerd kunnen worden en dat dit een belemmering vorm om over gaan tot een automatische simulator. Elke klep heeft zijn eigen model nodig en iedere simulator heeft meer dan veertig kleppen. Het model van iedere klep moet in staat zijn om stroom in beide richtingen te sturen. Deze stroom wordt opgebouwd via een spoel. De opbouw van deze stroom mag niet te traag maar ook niet snel gebeuren anders worden hierop fouten weergegeven. De kleppen worden niet in een model gegoten omdat de kostprijs daarvan te hoog zou uitvallen.

Figuur 8: Huidige simulator versus toekomstige simulator

Om de kleppen en andere externe componenten te kunnen simuleren is ervoor geopteerd niet op het niveau van de componenten te gaan modelleren, maar op niveau van de Fast Serial Bus. Alle communicatie tussen de slave boards, die componenten aansturen, en de master gebeurd via de Fast Serial Bus. Om die reden is ervoor geopteerd om een model te ontwerpen die in staat is al deze data in te lezen, om deze dan te gaan ontleden. Het model stuurt nu (in plaats van de slave) een antwoord terug naar de master. Op deze manier zullen zowel de componenten als de slave boards overbodig worden.


3. HIL, SIL of MIL 3.1

Hardware in the Loop

Hardware-in-the-loop [1] of kortweg HIL is een virtuele simulatieomgeving die toegepast wordt op Real-Time embedded systemen. Deze systemen bestaan nog maar zo’n 15 à 20 jaar en zijn ontstaan in de luchtvaart industrie. De reden waarom HIL systemen op de dag van vandaag in zowat alle industrieën gebruikt wordt is te vinden in twee hoofdredenen: ontwikkelingstijd en complexiteit. Bij hardware-in-the-loop is er nog een Elektronisch Controller Unit of ECU aanwezig in de lus.

Figuur 9: Principe HIL

Een typisch HIL systeem bestaat uit volgende onderdelen: 1. 2. 3. 4. 5. 6. 7. 8.

Een model( bv. motor of machine) Model van de sensoren Een Real-Time target met I/O Bestaande of gesimuleerde belastingen Fout integratie Een hoofd computer met connecties aan de Real-Time target en een verbinding met de ECU Een Grafische User Interface applicatie om een Real-Time proces te downloaden en te controleren Een automatische test applicatie

Figuur 10: Blokschema HIL


Het model Het model bestaat uit alles wat de ECU verwacht: een motor -, auto -, vliegtuig -, weefmachine model, enz. De typische vraag is: “Waar kan ik zo’n model verkrijgen en hoe goed moet dit model zijn?”. Hiervoor zijn er twee mogelijkheden, namelijk door een gemaakt model aan te kopen of door er zelf één aan te maken. Deze gekochte modellen zijn veelal van Simulink die ontwikkeld zijn om in Real-Time omgeving te gebruiken. Hoe goed ze moeten zijn is sterk afhankelijk van applicatie tot applicatie. Met andere woorden, ze moeten betrouwbaar zijn en moeten geschikt zijn voor hun einddoel. Het typische gebruik is het testen van het diagnostische vermogen van de ECU. Sensoren model De sensor outputs van een model zijn perfect, terwijl ze in de realiteit niet zo zijn. Hun grootste imperfectie is de niet - lineariteit. De ECU’s compenseren voor de niet - lineariteit van de sensoren, deze imperfectie dient dus ook gemodelleerd te worden. Sommige HIL systemen zullen een hele processor toewijden aan de sensoren modellen, en loskoppelen van het model. Real-Time target en I/O Het merendeel van de HIL systemen gebruikt embedded computers om hun modellen in Real-Time te laten lopen. De reden hiervoor is om de Real-Time berekeningen van het HIL systeem los te koppelen van de hoofd computer. De computer met Windows erop draait niet Real-Time. De embedded computers of targets communiceren met elkaar en met de systeem I/O via een data bus. Deze bus kan een VME, PCI of PXI zijn. Deze bezitten een processor en verschillende I/O borden .

Figuur 11: Voorbeelden Real-Time target

Belastingen Belastingen in een HIL systeem kunnen bestaand of gesimuleerd zijn. Fout integratie Het grote deel van HIL tijd word gebruikt om de fout detectie van de ECU te testen. De moderne ECU’s besteden de helft van hun geheugen aan deze taak. De sleutel tot het testen is het integreren van fouten zoals kabel breuk, stroom tekorten of falende sensor/actoren. Het simuleren van deze gebeurtenissen gebeurt door een terugkoppelmatrix tussen de HIL en de ECU. Deze matrix wordt gecontroleerd door de hoofd computer. De link tussen de matrix en hoofd computer varieert van fabrikant tot fabrikant. Sommige gebruiken een Controller Area Network ( CAN) omdat deze toch nodig zijn voor het HIL systeem.


Host PC De hoofdcomputer wordt gebruikt om de gebruiker te voorzien van een Grafische User Interface (GUI). Dit om de componenten van het HIL systeem te besturen, testen uit te voeren, ontwikkelen en aanpassingen te maken aan de modellen, enz. De verbinding tussen de hoofdcomputer en het Real-Time systeem gebeurt meestal via Ethernet. GUI De GUI applicatie loopt op de hoofdcomputer. De applicatie laat toe om het Real-Time proces te besturen, zoals download, starten, stoppen, observatie en data opslag. Test applicatie Deze applicatie is mogelijk opgebouwd in een GUI of kan een aparte applicatie zijn dat “bovenop” de GUI zit. Dit zorgt ervoor dat de gebruiker de mogelijkheid heeft om automatisch te testen. Dit kan gerealiseerd worden door de gebruiker te voorzien van een test cyclus. Deze cyclus kan een test script zijn van bv. Visual Basic of kan symbolisch zijn zoals een flowchart. Momenteel is er geen standaard taal voor automatische HIL tests. Het voordeel van een HIL simulatie is dat er situaties kunnen worden uitgevoerd in allerlei simulaties. Een tweede voordeel is dat voor de realisatie van een ontwerp al een inschatting kan gemaakt worden omtrent het verwachte gedrag die in de reële wereld niet mogelijk of als te gevaarlijk worden beschouwd. Het nadeel van een HIL simulatie is dat het een nabootsing is van een toekomstig verwacht gedrag van een systeem of product. Het is mogelijk dat het werkelijke gedrag afwijkt van het voorspelde gedrag, omdat nooit alle variabelen in een wiskundig model kunnen worden gegoten. Daarnaast is het ook moeilijk om te bepalen wat er juist gebeurt in de embedded software. Als het fout loopt is het aan de hand van de weinige outputs moeilijk te bepalen welke delen er uitgevoerd werden of welke de waarden van de interne variabelen waren.

Toepassingen

   

Voertuigen Kerncentrales Ruimtevaart Medische toestellen

Figuur 12: Toepassingen HIL systemen


3.2

Software in the Loop

Bij software in the loop of SIL is de software code opgenomen in een wiskundige simulatie die modellen bevat van een fysiek systeem. Bij deze modellen is er geen hardware aanwezig. Dit wordt gedaan om software functionaliteiten toe te voegen waarvoor nog geen modellen bestaan of om snellere simulaties mogelijk te maken. Aangezien de programmeer omgeving virtueel is, is een Real-Time omgeving niet nodig. In de meeste gevallen worden SIL en testen uitgevoerd op Windows of Linux bestuurde computers. Doel:

1) Het opnemen van algoritmische functionaliteiten waarvoor geen model bestaat 2) Verhogen van de simulatie snelheid 3) Garanderen dat een algoritme in de modelomgeving op dezelfde manier zal functioneren als datzelfde algoritme in een ECU

Figuur 13: Block diagram Software in the Loop

3.3

Model in the Loop

Model in the Loop of MIL is gebaseerd op een model van het systeem zelf. Het testen van een embedded systeem op MIL niveau betekent dat het model en de omgeving zijn gesimuleerd zonder enige fysieke hardware componenten. Dit maakt het testen in een vroeg stadium van de ontwikkelingsfase mogelijk. Er bestaan verschillende soorten van modellen. De functionele modellen ( fysische modellen) zijn abstract en houden geen rekening met alle aspecten, zoals de robuustheid en de prestaties. Tijdens het ontwikkelen van de deze modellen worden deze dan omgezet in implementatie modellen. Deze modellen zijn ontworpen om te voldoen aan de vooropgestelde eisen. MIL is een goedkope manier om embedded systemen te testen. Ontwikkeling en simulatie omgeving voor model gebaseerde ontwikkeling kan bijvoorbeeld worden gecreëerd in: MATLAB/ Simulink of ASCET.


4. Embedded systemen Een embedded systeem [9] (ingebed of geïntegreerd systeem genoemd) is een elektronisch systeem, bestaande uit hardware en sofware, dat geïntegreerd is in gebruiksartikelen of apparaten. De essentie is dat er software ingebed zit in een hardware apparaat en om dan een vorm van intelligentie te bezorgen. Een voorbeeld hiervan zijn elektronische meet -en regelsystemen die vroeger volledig uit hardware bestonden, terwijl vandaag een embedded systeem via software een gedeelte van deze elektronische meet –en regeltaken overneemt. Daar de software eenvoudig vervangen kan worden, wordt het apparaat flexibeler om aan te passen aan de toekomstige eisen. Algemeen bestaat een embedded systeem uit een sensorgedeelte dat instaat om de omgeving waar te nemen, een communicatiegedeelte dat de waargenomen informatie doorstuurt naar een informatieverwerkend gedeelte ( processor en software) en een actuator gedeelte dat het gedrag van de omgeving aanstuurt op basis van de beslissingen die genomen werden in het informatieverwerkende gedeelte. Doordat er steeds goedkopere en flexibele chips zijn komen er steeds meer embedded systemen op de markt zoals: kopieermachines, meetapparatuur, ziekenhuisapparatuur, enz. Een embedded systeem bevat vijf hoofdeigenschappen: 1. 2.

3.

4. 5.

Heterogeen: Het is mogelijk om te communiceren met verschillende soorten netwerken en andere embedded systemen. Onopvallend: Een embedded systeem zit ingebouwd in machines en apparaten, met de bedoeling dat de gebruiker zich er niet van bewust is dat ze aanwezig zijn. Door gebruik te maken van sensoren, die bv. stemgeluid of temperatuur analyseren kan een embedded systeem daar automatisch op reageren zonder dat er tussenkomst nodig is van de mens. Zuinig: Is van groot belang aangezien de meeste embedded systemen niet aan het elektriciteitsnet gekoppeld zijn. Hiervoor gaan ze energie winnen uit hun omgeving, zonlicht of lichaamswarmte om een embedded systeem te voeden. Flexibel: Ze moeten kunnen worden aangepast aan de individuele eisen van een gebruiker of van naburige embedded systemen. Hierdoor worden ze zelf- configurerend. Betrouwbaarheid: Ze moeten gedurende heel lange tijd zelfstandig en betrouwbaar kunnen functioneren.

Embedded systemen worden ontworpen om slechts één taak te vervullen. Je kan bijvoorbeeld op het embedded systeem dat dient voor de ABS in je auto geen computerspellen spelen of tekstdocumenten bewerken. En dit is meteen het belangrijkste verschil met de computer, je computer kan je gebruiken voor allerlei taken: spelletjes, tekstverwerking, internet, enz.


5. Real-Time systemen Een Real-Time systeem wil niet zeggen dat het “zeer snel” werkt, het kan ook zijn dat het trager werkt. Bij RealTime is het de bedoeling dat er exact kan bepaald worden wanneer een bepaald deel van het programma uitgevoerd zal worden en hoe lang dit zal duren.  Hard Real-Time Bij dit type moet er gegarandeerd worden dat kritische taken binnen een bepaalde tijd worden uitgevoerd. Het doel eist dat alle vertragingen in het systeem begrensd zijn van het ontvangen van de data tot de tijd die nodig is om het te verwerken.  Soft Real-Time Een soft real-time systeem is een systeem waar tijdkritische taken een hogere prioriteit heeft dan andere en deze hogere prioriteit dient behouden te worden tot deze taak is uitgevoerd. Net zoals bij een hard real-time systeem moeten de vertragingen begrensd zijn.

Figuur 14: Verschil Soft en Hard Real-Time

Tussen een gewoon besturingsysteem en een Real-Time besturingsysteem zijn er enkele grote verschillen: Gewone OS 

Functies o GUI o Achtergrond applicaties o OS controleert alle planningen



Applicaties o Acquisitie opgeslagen data o Offline data analyse o Data voorstelling

Real-Time OS 

Functies o Embedded o Deterministisch o Controle over OS o Hoge prioriteitstaken worden eerst uitgevoerd



Applicaties o Closed Loop Control o Tijdskritische beslissingen nemen o Uitgebreide verwerkingstijd o Verhoogde betrouwbaarheid o Autonoom systeem

Data-acquisitie: is het verzamelen van gegevens - met een computer - over parameters van bedrijfsprocessen, waarbij het resultaat vaak direct geanalyseerd en gepresenteerd wordt. Deterministisch: bij computersimulatie: verschijnsel dat het resultaat van een berekening voorspelbaar is Autonoom systeem: op zichzelf staand systeem


6. Fast Serial Bus ( FSB ) Bij weefmachines [5,6] dient nagenoeg alles real-time te gebeuren. Dit wil zeggen: als er een bepaalde actie uitgevoerd wordt, moet dit gebeuren in een bepaald tijdsbestek, dit zowel in een MIN en MAX tijd. Als we dit nu toepassen, bijvoorbeeld op het sturen van een klep, dan moet de klep geopend of gesloten worden binnen de 100μs en 150μs, niet vroeger en ook niet later. Dit betekent dat er een communicatiemiddel nodig is die voldoet aan de real-time eisen. Ethernet wordt het meest gebruikt voor lokale netwerken ( LAN ). Het voordeel van ethernet is de hoge snelheden die behaald kunnen worden, namelijk tot 1GBit/s.

Figuur 15: Datatransmissie ethernet

In de eerste twee velden kan het adres van de verzender en ontvanger gevonden worden. Daarna wordt het type van data meegegeven en de data zelf. Op het laatst is er een CRC ( Cyclic Redundancy Check ) voorzien die errors in het frame detecteert. Het grote nadeel van ethernet is dat er geen garantie naar tijd is, zeker als er veel verschillende data op hetzelfde ogenblik verzonden wordt kan er vertraging optreden. Naast ethernet bestaan er nog andere types veldbussen, zoals de ethernet variant etherCAT. EtherCAT staat voor Ethernet for Control Automation Technology. Het is als enige ethernet type eerder een klemmensysteem dan een netwerk, waardoor het voor de machinebouwer vertrouwd overkomt. Daar een weefmachine een kostprijsgedreven product is,is de kostprijs van het etherCAT systeem te hoog. Door het gebrek aan een bussysteem die zowel een garantie op datasnelheid, real-time sturing en een lage kostprijs bezit, heeft PsiControl Mechatronics ervoor geopteerd om een eigen bussysteem te gaan ontwikkelen, namelijk de FSB. De FSB of Fast Serial Bus is een bussysteem die dezelfde vereisten heeft als iedere ander bussysteem die beschikbaar is op de bedrijfsmarkt. De FSB kan in beide richtingen heel snel communiceren, heeft een hoge datatransmissie en met een garantie dat dit real-time gestuurd wordt.


6.1

Fysische laag

De FSB bevat vier uitgaande signalen: CLK, A&M/D, MOSI[1], MOSI[0] en één inkomend signaal, namelijk de MISO. Doordat er met één massa gewerkt wordt voor zowel de signalen als de power werd er ground bounce verkregen wanneer de stromen van de FSB ingeschakeld werden. Om dit op te vangen wordt er een communicatiekanaal gebruikt dat voldoende common mode range heeft. Om voldoende common mode range te hebben worden de signalen differentieel verstuurt. Doordat op de bus een snelheid behaald wordt van 33 MHz waren de gewone differentiële drivers niet snel genoeg (bv. RS 485). LVDS transceivers zijn wel voorzien voor die hogere snelheden (tot 200 bps), maar hebben slechts een common mode range van ±1V. Om toch de hogere common mode range te bekomen werd er gekozen voor LVDS transceivers die specifiek ontworpen zijn voor hogere common mode range.

Master

CLK A&M/D MOSI[0] MOSI[1]

FPGA

LVC buffer

MISO

FPGA

LVDS receiver

Slave

R deling

R deling

LVDS receiver

CPLD

CPLD

Figuur 16: Fysische laag FSB


6.2

Datatransmissie

In figuur 8 wordt de datatransmissie van de FSB weergegeven. In totaal zijn er vijf lijnen die elk hun eigen functionaliteit hebben. De eerste lijn is de CLK, dit is de bus klok van 33MHz. De volgende lijn is de AM_D lijn, deze lijn is laag op het moment dat de master (moederbord) data aan het versturen is naar een slave. Nadat alle nodige data verzonden is wordt deze lijn opnieuw hoog. Vanaf dat moment wordt er opnieuw gepold naar een nieuw adres op MOSI(1) en de mode op MOSI(0). De twee MOSI lijnen zijn verantwoordelijk voor het versturen van de data naar de slaves. De mode beschrijft hoe de verzonden data eruit zal zien. Op alle boards zijn een aantal basis modes aanwezig. De laatste lijn is de MISO lijn, dit is de lijn waarop de slave indien nodig data terugstuurt of bevestigt dat de data is aangekomen. Dit kan pas gebeuren nadat de AM_D lijn laag is en er een aantal klokpulsen voorbij gegaan zijn. De master mag het bericht pas als verzonden beschouwen als er geen errors terugkomen en de checksum van de MISO klopt.

Figuur 17: Datatransmissie FSB bus

6.2.1

Berichtformaat



Adres Het adres bestaat steeds uit vijf bits en hiermee wordt het slotadres meegegeven voor welke slave op het rack het bericht bestemd is. Iedere slave kan zijn eigen positie op de rack uitlezen Wanneer het slotadres ‘00000’ is komt dit overeen met een broadcast. Een broadcast dient om de kaderposities mee te geven aan de aanwezige slaves.



Mode Net zoals het adres bestaat de mode uit vijf bits, de mode bepaalt welk type data er verstuurd zal worden.



Checksum MOSI (Master) De checksum wordt uitgevoerd nadat de datatransmissievoorbij is. Deze checksum wordt door de master zelf gegenereerd. Pas als deze checksum correct is mag de slave de gekregen data daadwerkelijk gaan gebruiken. Indien de data een vraag bevat mag de slave reeds een antwoord genereren, maar bij een foute checksum zal hij met een error duidelijk maken dat de data corrupt was en dat de master de gekregen data mag weggooien.




ACK Een ACK bit wordt gegeven als de slave de data gezien heeft en dat het slotadres klopt. In rust toestand staat de ACK op ‘1’, bij bevestiging wordt deze op ‘0’ gezet. Dit is niet van toepassingen als het slotadres ‘00000’ is, wat overeenkomt met een broadcast.



ERR Een error komt overeen met een ‘0’ doorsturen. Dit bestaat uit twee of drie bits. Ook dit is niet van toepassingen bij een broadcast. Een error wordt meegegeven als bv. de mode niet gekend is, de checksum niet klopt, er een interne fout is opgetreden, enz.



Checksum MISO (slave) Net zoals bij de master zal de slave na het versturen van zijn data een checksum genereren. De master mag de data pas gaan gebruiken als de checksum klopt en er geen error bit meegegeven werd door de slave.

6.2.2

Mogelijke modes

1) Broadcast Nuttige data: 12 bits (enkel data op MOSI 0 is nuttig) Een broadcast bericht wordt elke 100μs verzonden en dit naar iedere slave. Dit bericht bevat bv. de huidige positie van de machine. In het huidige systeem wordt dit meegegeven aan alle slaves, maar wordt er niks mee gedaan. Als er overgegaan wordt naar een volledig automatische simulator zal de broadcast gebruikt worden om de positie van de machine te controleren. Bij een broadcast wordt er geen data teruggestuurd van de slave.

2) Commando’s Nuttige data: 16 bits (x 2 MOSI lijnen) In totaal zijn er tweeëndertig mogelijke commando’s, die telkens uit een functienummer en een actie weergeven. Bij een commando wordt er geen data teruggestuurd van de slave.

3) Interruptvragen Nuttige data: 24 bits Bij de mode hebben de slave borden de mogelijkheid om interrupts te genereren. Iedere 100 μs wordt aan elke slave de vraag gesteld of ze interrupt hebben. Bij een interrupts wordt er data teruggestuurd van de slave naar de master.

4) Ms opvraging Nuttige data: 512 bits (x 2 MOSI lijnen) Tijdens deze mode wordt telkens één slave bord ondervraagd naar zijn trage inputs. Bij een Ms opvraging wordt er data van de slave naar de master verzonden.

5) Q_A ( Question en Anwser) Nuttige data: 16 bits Iedere 100 μs wordt een Q_A verzonden naar de slaves. Indien er geen geldige vraag is worden er nullen verzonden. Een vraag wordt eenmaal verzonden, de rest van de tijd worden nullen verzonden. Deze nullen bieden de slave plaats om een antwoord testuren.


6.3

Controle Checksum

Het belangrijkste onderdeel op de datalijnen is het checksum. Deze staat in voor de controle van de ingelezen data die van slave of master afkomstig is. Hiervoor wordt gebruik gemaakt van een Lineair Feedback Shift Register of LFSR. Het checksum bestaat uit vier bits, om deze te controleren wordt dan ook gebruik gemaakt van een vier bit Shift Register.

DIN

D

Q

D

3

Q

D

2

>C

Q

D

1

>C

Q 0

>C

>C

Figuur 18: Lineair Feedback Shift Register

Om het checksum te controleren wordt alle ontvangen data aan de ontvangerszijde door het LFSR verwerkt. Na de data wordt ook het gegenereerde checksum die door de verzenderzijde meegezonden werd verwerkt in het LFSR. Enkel wanneer het bekomen resultaat in de registers van het LFSR “0000” is kan er aangenomen worden dat de ontvangen data correct is. Indien het resultaat niet gelijk is aan “0000”, mag de ontvangen data verwijderd worden aangezien er een fout opgetreden is tijdens het samenstellen ervan. Het berekenen van de vier bits die bekomen worden in het LFSR gebeurt als volgt: 3

2

DIN xor SR3 = SR3

SR3

1

0

SR2 xor SR0 SR1 xor SR0

Figuur 19: Werking vier bit Shift Register

Het bekomen resultaat van een XOR bewerking is als volgt:

1 1 0

1 0 0

0 1 0

Figuur 20: Werking XOR Shift Register

Uit figuur 20 kan er opgemaakt worden dat er enkel een logische “0” bekomen wordt in het shift register als de twee te bewerken bits gelijk zijn aan elkaar. Bij het starten van de controle van de ontvangen data staan alle registers van de LFSR op “1”. Wanneer alle databits en het checksum door de LFSR verwerkt zijn moet het resultaat “0000” zijn. Is dit niet het geval dan betekent dit dat de verzonden data incorrect is en dat deze dus genegeerd mag worden. In het antwoordt van de slave naar de master is een ERROR bit voorzien waarmee de slave kan aangeven of de ontvangen data al dan niet correct was. Hierdoor weet de master dat er een fout opgetreden is bij het generen van de data en kan hij de data opnieuw zenden of beslissen om nieuwe data te verzenden.


Voorbeeld controle checksum In het voorbeeld bestaat de data uit zestien bits (bit 0 tot 15). DIN wordt aanzien als de ingelezen data aan de ontvangerszijde. SR (shift register) zijn de vier bits die zich in het LFSR bevinden, bij de start staan deze ingesteld op “1”. Het bepalen van de nieuwe waarde in de SR gebeurt als volgt.

Op deze manier zullen eerst de zestien databits verwerkt worden door het LFSR. Daarna zullen nog de vier checksum bits op dezelfde manier verwerkt worden. Als de laatste checksum bit verwerkt is, dan moet het resultaat in alle vier de SR gelijk zijn aan nul. Wanneer de slave een antwoordt terugstuurt naar de master wordt dezelfde methode gebruikt om het checksum te bepalen die meegeven wordt na de data.

Figuur 21: Uitwerking voorbeeld checksum


6.4

Voorbeeld datatransmissie op de bus

Adres : Mode : Data master : Data slave : Checksum master MOSI_0 : Checksum master MOSI_1 : ACK bit : ERR : Checksum slave :

01010 10101 4A9F2D65 E8BE 1011 1110 0 11 1101

(32 bit) (16 bit)

(dus een ACK geven, “1” is rusttoestand van de bus) (geen errors)

Beeld datatransmissie:

Figuur 22: Voorbeeld datatransmissie FSB bus


7. National Instruments

National Instruments [8] of NI werd in 1976 opgericht aan de universiteit in Texas. Wanneer NI werd opgericht waren de eerste producten interfacekaarten om klassieke instrumenten te verbinden met de standaard computers. Toen in de jaren tachtig de eerste desktops op de markt gebracht werden, had NI meteen de link gelegd naar de vele mogelijkheden voor ingenieurs en de wetenschap. Men ontwikkelde met die visie instrumentatiesoftware- en hardwaretools voor het gebruik in instrumentatietoepassingen. Op heden zijn de meest bekende producten van NI de PCI (Peripheral Component Interconnect), PXI (PCI eXtensions for Instrumentation) instrumenten, evenals de LabVIEW en Measurement Studio softwarepakketten. Sedert enkele jaren heeft NI hun gamma verder uitgebreid met producten voor Real-Time en motion control toepassingen.

7.1

Software

 LabVIEW

Laboratory Virtual Instrumentation Engineering Workbench of kortweg LabVIEW is een grafische programmeeromgeving. Het is een omgeving die uiterst geschikt is voor besturingstechniek, data-acquisitie en het communiceren met meetinstrumenten. Door het feit dat de LabVIEW - programmeertaal nog steeds dezelfde taalconstructies en datastructuren bezit zoals de traditionele programmeertalen, heeft het een brede waaier van software toepassingen. Het programma kan op de Windows, Linux en MacOS X besturingssystemen gebruikt worden. LabVIEW werd in 1986 ontwikkeld voor de Apple Macintosh, deze was destijds het enige computersysteem dat een grafische gebruikersinterface had. De allereerste toepassing voor LabVIEW was het automatiseren van metingen en voor het zorgen van een eenvoudige en goede communicatie tussen de meetinstrumenten en de computer. Juist door het feit dat de programmeercode grafisch is, sluit het goed aan op de manier waarop ingenieurs denken, namelijk in (blok)schema’s. Om te komen waar LabVIEW vandaag staat zijn er talloze toevoegingen aan het software pakket geweest, zoals de mogelijkheid deze te laten werken op meerdere besturingssystemen. De softwaretoepassingen onder LabVIEW worden omschreven als Virtuele Instrumenten. Deze Virtuele Instrumenten, aangeduid met de letters VI, kan men het best vergelijken met subroutines en functies die in andere programmeertalen worden gebruikt. Zoals bij de traditionele meetinstrumenten heeft een VI twee aanzichten:  

Een bedieningspaneel met bedieningsorganen en indicatoren (wat de gebruiker ziet op de GUI als het programma in werking is) Een schematisch overzicht van de werking van het programma, ook wel een blokschema genoemd (wat enkel zichtbaar is voor het programmeur en niet voor de gebruiker)


Het aanmaken van een LabVIEW programma gebeurt volledig in de grafische omgeving. De functies en subroutines worden weergegeven als blokjes. Deze worden dan onderling door middel van gekleurde lijnen met elkaar verbonden. De lijnen stellen de variabelen voor van het programma en het kleur van de lijnen stelt het type voor. Het kleur oranje staat voor een real type en het kleur blauw voor een integer type. Daarnaast kunnen de lijndiktes ook variëren: een dikke lijn stelt een eendimensionale array voor en een dubbeldikke lijn een multidimensionale array. De rechthoeken in het programma zijn de lussen (loop) en de case-statements die worden weergegeven. Alle code die binnen deze rechthoek geplaatst is, wordt binnen de lus uitgevoerd. Als een software ontwikkelaar zijn proces netjes programmeert, kan een wiskundige die het proces kent maar geen kennis op het gebied van software heeft meestal in één oogopslag zien of het proces goed gemodelleerd is.

Figuur 23: Voorbeeld LabVIEW schema

De gekleurde lijnen die de functieblokken met elkaar verbinden dienen voor twee zaken. In de eerste plaatst zorgen deze verbindingen voor de gegevensoverdracht tussen de verschillende functieblokken. Ten tweede zorgt de volgorde waarin de functieblokken staan ook voor de volgorde waarin deze zullen worden uitgevoerd. Speciaal hierbij is dat alle parallel lopende functies gelijktijdig uitgevoerd worden. Dit wordt ook Multi threading genoemd, waardoor alles veel sneller verwerkt kan worden.


7.2

Hardware

 PXI Een PXI is een open, PC – gebaseerd platform dat ontwikkeld is om te testen, meten en besturen. De PXI combineert elektrische bus functies met de modulaire CompactPCI en voegt dan gespecialiseerde synchronisatie bussen en software functies toe. De PXI werd in 1998 op de markt gebracht. Deze bestaat uit drie systeemcomponenten, namelijk:   

Chassis Controllers Modules

 PXIe-8133 De PXIe-8133 is een hoog performante Intel Core processor die gebaseerd is op de embedded controller voor de PXI systemen. Voor processor intensive, modulaire instrumentatie en data-acquisitie applicaties is de PXIe-833 ideaal. De Quad-Core processors bevat vier cores of rekenkernen in één fysiek pakket.

 PXI-7853R De PXI 7853R multifunctionele RIO module bevat een gebruikers programmeerbare FPGA chip voor onboard processing en flexibele I/O bewerkingen. Door gebruik te maken van de grafische blokdiagrammen in LabVIEW en de FPGA module kunnen alle analoge en digitale functionaliteiten geconfigureerd worden. Wanneer het blokdiagram gedownload is in de hardware heeft het te gebruiker directe controle over alle I/O signalen. Dit heeft de mogelijkheid tot hoge performantie, zoals:   

Complete controle over alle synchronisatie en timing van alle signalen en bewerkingen Levert hoge betrouwbaarheid Individueel configureren van de alle inputs, outputs, timers, communicatie protocollen, enz

In de simulators wordt de FPGA gebruikt om alle tijdskritische modellen, zoals encoders uit te voeren.


 FPGA Een Field Programmable Gate Array (FPGA) is een silicon chip die hergeprogrammeerd kan worden aan de hand van een Verilog Hardware Desciptive Language (VHDL). Bij het programmeren worden er logische functies gebruikt zoals AND ,OR, enz. Door middel van de VHDL wordt het programma omgezet in een binaire code, die dan op de FPGA gedownload kan worden. National Instruments LabVIEW en de module LabVIEW FPGA geven de mogelijkheid tot een grafische programmeeromgeving op de NI herconfigureerbare I/O hardware. Met behulp van de NI LabVIEW FPGA module, kunnen er FPGA VI’s ( Virtual Instruments) geprogrammeerd worden op een computer voorzien van Windows, LabVIEW compileert en implementeert deze code dan in de hardware. De LabVIEW FPGA vervangt de omzetting van het VDHL. Er kunnen FPGA VI’s ontworpen worden die directe toegang geven tot I/O met gebruiker bepaalde logica om aangepaste hardware te definiëren zoals digitale protocol communicatie, HIL simulatie en snelle controle prototyping. De FPGA VI’s worden dan op een PXI modules geladen.

Figuur 24: Werking FPGA

Het grote voordeel van een FPGA is dat deze parallel werkt, wat wil zeggen dat er meerdere acties op hetzelfde moment uitgevoerd kunnen worden. Hierdoor zal de FPGA ook alles veel sneller kunnen gaan verwerken. Daarnaast staat er geen limiet op het aantal keren dat je een FPGA opnieuw kan programmeren. Het nadeel is dat de grootte van een FPGA beperkt is en er kan dus niet te veel code ontwikkeld worden.


 PXI-8512 De PXI-8512 is een hoge snelheid CAN interface voor het ontwikkelen van CAN applicaties. Als basisonderdeel van de NI-XNET, is de PXI-812 uiterst geschikt voor Real-Time, hoge snelheid manipulaties van honderden signalen, zoals HIL simulatie, rapid control prototyping, enz. De PXI-8512 wordt in de simulators gebruikt om alle niet tijdskritische modellen uit te voeren.

7.3

Kostprijs

Wanneer alle software en hardware benodigdheden van National Instruments worden samengevoegd in een besteklijst, wordt er al snel een kostprijs van €18.000 en meer bekomen voor het maken van een Real-Time opstelling.

Software NI Developer Suite LabVIEW Real-Time FPGA Development Option Industrial Monitoring Option

€ € € €

5.049,00 2.599,00 2.599,00 2.599,00

PXIe-1062Q PXIe-8133 PXI-7853R PXI-8512 PXI-6509

€ € € € €

2.519,10 4.949,10 4.274,10 764,10 359,10

Hardware

Totaal

€ 18.063,50 Figuur 25: Besteklijst National Instruments


8. Alternatieve mogelijkheden Sinds de lancering van de PXI in 1997 door National Instruments zijn er verschillende nieuwe spelers op de markt bijgekomen, de twee grootste zijn: ADLINK, Agilent Technologies. Deze bedrijven zijn allemaal lid van de PXI Systems Alliance of PXISA. De reden voor de intrede komt door de exponentiële groei van de PXI markt de laatste paar jaar. In 2007 werd de wereldwijde marktwaarde van de PXI geschat op €213 miljoen en in 2010 was de marktwaarde al verdubbeld naar €400 miljoen en blijft deze nog steeds groeien.

8.1

ADLINK Technology

Het bedrijf ADLINK Technology werd in 1995 in Taiwan opgericht. Ze bieden een breed scala van embedded producten en diensten aan voor test en meting, communicatie, medische-, netwerk -beveiliging en transport. ADLINK producten zijn onder andere PCI Express gebaseerde data-acquisitie en I/O, motion control en koeling vrije embedded controllers voor industriële computers.

8.2.1

Software

ADLINK heeft geen eigen software pakket zoals National Instruments. De software die nodig is om de verschillende programma’s te ondersteunen is wel beschikbaar. Daarnaast is er software, DAQPilot, die ter beschikking staat en die gebruikt kan worden om extra functies te verkrijgen in LabVIEW.

Figuur 26: ADLINK DAQPilot

8.2.2

Hardware

Net zoals bij National Instruments heeft ADLINK verschillende PXI Chassis die oplopen van zes tot negentien slot modules. De PXI embedded controller en PXI modules hebben gelijklopende specificaties als de modules van NI.

Figuur 27: ADLINK hardware


8.2.3

ADLINK Technology versus National Instruments

Aangezien ADLINK geen eigen ontwerp software ter beschikking heeft slaat het voordeel onmiddellijk door naar de kant van National Instruments. De hardware is gelijkaardig van beide leveranciers, dus lijkt het aannemelijk dat bij aankoop van hardware en software dit bij een en dezelfde leverancier zou gebeuren.

8.2

Agilent Technologies

In 1939 werd het bedrijf Hewlett Packard opgericht. Het eerste succesvolle product die op de markt werd gebracht was de HP200A, dit is een audio oscillator waarmee geluidsinstallaties getest konden worden. In 1966 maakte HP zijn intrede op de computermarkt met de HP200/HP1000 die een omvang hadden van één à twee koelkasten. In 1999 besloot HP dat alle niet computer -, dataopslag, of foto- gerelateerde activiteiten van HP af te stoten, dit omdat het niet langer tot de kernactiviteiten van HP behoorde. De productie van wetenschappelijke instrumenten, halfgeleiders, netwerkapparatuur en testuitrusting voor telecommunicatie werden ondergebracht onder de naam Agilent, en naar de beurs gebracht. Op de dag van vandaag is Agilent Technologies marktleider in test en meet systemen. Agilent Technologies hebben intrede gemaakt in de PXI markt in 2006 door de bedrijven Acqiris en PXIT over te nemen.

8.2.1

Software

Agilent VEE Agilent VEE is een grafische programmeer omgeving die gebruikt kan worden voor geautomatiseerde testen, metingen, data analyse en rapportering. De afkorting VEE staat voor Visual Engineering Environment. Net zoals bij LabVIEW worden VEE programma’s gemaakt door het plaatsen van grafische functies in het werkgebied en deze te verbinden door lijnen. VEE gebruikt de term “objecten” voor de functie blokken. Deze objecten bieden een groot aantal verschillende taken aan, zoals: toevoegen van nummers, logische beslissingen, lezen van externe bestanden, grafieken weergeven, besturen van instrumenten, enz.

Figuur 28: Agilent VEE pro


8.2.2

Hardware

De hardware van de Agilent kan vergeleken worden met deze van National Instruments. Afhankelijk van de toepassing kunnen alle mogelijke combinaties van PXI modules gemaakt worden. Ook zijn er modules in hun aanbod beschikbaar waardoor het mogelijk is om naast Agilent VEE ook test systemen te ontwikkelen op hun PXI’s met andere software, zoals LabVIEW, C# en Visual Basic.

Figuur 29: Agilent Technology hardware

8.2.3

Agilent Technologies versus National Instruments

Als de twee leveranciers met elkaar vergeleken worden, wordt het al snel duidelijk dat er sterke gelijkenissen te vinden zijn. Net zoals in LabVIEW wordt er in Agilent VEE door middel van functie blokken gewerkt die met elkaar verbonden dienen te worden. Het voordeel dat LabVIEW heeft is dat het programma gemakkelijker te programmeren, flexibeler en sneller te debuggen is. Voor personen die geen kennis hebben van LabVIEW is de programmeercode ook beter te begrijpen. Bij de hardware hebben ze een gelijklopend aanbod. Wat wel opgemerkt kan worden is dat de modules van Agilent duurder uitvallen dan de beschikbare modules bij National Instruments.


8.3

MathWorks

MathWorks is een in 1984 opgerichte firma die gespecialiseerd is in wiskundige computer software. De twee hoofdproducten van de firma zijn MATLAB en Simulink. De software wordt wereldwijd gebruikt als studiemateriaal in scholen alsook voor onderzoek en ontwikkeling in de industrie.

8.3.1 8.3.1.1

Software MATLAB

MATLAB of MATrix LABoratory is een technische softwareomgeving die door MathWorks is gelanceerd en het wordt gebruikt in zowel de industrie als in de academische wereld voor allerhande wiskundige toepassingen. Deze toepassingen gaan van het berekenen van functies, bewerken van matrices, tekenen van grafieken tot het maken van grafische gebruikersinterfaces. Het uitvoeren van een de MATLAB-code gebeurt door commandolijnen, deze opeenvolgende commando’s kunnen opgeslagen worden in een tekstbestand en worden uitgevoerd als een script.

Figuur 30: Script MATLAB

8.3.1.2

Simulink

Bij MATLAB hoort er een simulatieomgeving genaamd Simulink die gebruikt maakt van modellen. Deze omgeving biedt gebruikers de kans om op een efficiënte manier systemen te simuleren en/of te implementeren. Simulink werkt op basis van Toolboxes die gespecialiseerde blokken bevatten voor het uitbreiden van de functionaliteiten. Daarnaast bestaat er een Fixed-point toolbox die de gebruikers toelaat het model aan bepaalde precisieparameters te laten voldoen en het systeem vervolgens om te zetten naar een Hardware-Description Language (HDL) zoals VHDL of Verilog.


Simulink heeft een wijd aanbod aan toepassingen waaronder: Digitale signaal verwerking, Communicatie systemen, mechatronica en embedded systemen.

Figuur 31: Voorbeeld Simulink model

8.3.2

Hardware

xPC Target Turnkey Via de xPC Target Turnkey is het mogelijk om Simulink modellen uit te voeren van Hardware-in-the-loop simulaties, rapid control prototyping en andere Real-Time tests applicaties. Het is een volledig geassembleerde Real-Time tester die de xPC Target combineert met een hoog performante Real-Time target en I/O modules.

Figuur 32: Mathworks Turnkey

8.3.3

MathWorks versus National Instruments

Na het vergelijken van Mathworks en NI kan geconcludeerd worden dat de producten van Mathworks ook de mogelijkheid bieden om in een Real-Time omgeving te gaan simuleren. Net zoals bij LabVIEW wordt er bij MatLab/Simulink gebruik gemaakt van functieblokken. De hardware van beiden zijn gelijklopend. Mathworks wordt in tegenstelling tot NI meer in de academische wereld gebruikt.


8.4

dSPACE

De firma dSPACE werd in Duistland in 1988 opgericht. Al meer dan twintig jaar zijn ze actief in de rapid control prototyping en hardware-in-the-loop simulaties. Op heden is dSPACE één van de hoofdproducten op het gebied van engineering tools voor het ontwerpen en testen van mechatronische systemen. Ze zijn vooral actief in de automobiel, luchtvaart industrie en industriële automatisering.

8.4.1

Software

Voor software zijn er verschillende mogelijkheden in het aanbod van dSPACE, namelijk: Implementatie -, Test en Experiment -, Productie code -, ECU Interface Software en automobiel Simulatie modellen. Wat al deze software gemeenschappelijk hebben is hun GUI, ze zijn allemaal hetzelfde wat het ontwerp proces vereenvoudigt. Daarnaast biedt de software ook de mogelijkheid om modellen van MATLAB/Simulink te importeren, wat het codeer- en ontwerp tijd sterk doet dalen.

8.4.2

Hardware

dSPACE heeft in zijn aanbod verschillende simulator hardware zoals: Scalexio, dSPACE Simulator EcoLine en dSPACE Simulator Full-Size. Deze simulators zijn speciaal gebouwd om closed-loop HIL simulaties uit te voeren. De verschillende types van simulators kunnen ook via netwerk met elkaar gecombineerd worden.

8.4.3

dSPACE versus National Instruments

Na het vergelijken van dSPACE en NI kan geconcludeerd worden dat de producten van Mathworks ook de mogelijkheid bieden om in een Real-Time omgeving te gaan simuleren. Het grote verschil is dat bij dSPACE alle software en hardware ontwikkeld is de automobiel industrie, namelijk het simuleren van motoren.


9. Testopstelling Om de werking van de FSB te begrijpen werd een testopstelling gemaakt. Het was de bedoeling om de data die verstuurd wordt tussen de master en de slave in te lezen in de computer en deze te analyseren en begrijpen. Door gebruik te maken van LabVIEW werd een programma geschreven die in staat is deze data binnen te lezen. Eenmaal binnengelezen werd deze dan opgesplitst en vergeleken met de mogelijke data die verwacht kan worden. Later was het dan de bedoeling om afhankelijk van de binnengelezen data, indien nodig een antwoord te formuleren en deze terug naar de master te sturen.

Figuur 33: Testopstelling FSB

9.1

Testopstelling probleem

Vooraleer de stap werd gemaakt naar het testen van de geprogrammeerde code werd het clock signaal van de FSB gemeten. Dit omdat het signaal een zo goed mogelijk bloksignaal diende te zijn. Indien het signaal geen mooie vorm had was het zinloos om verder te gaan met het programmeren. Want zonder een mooi signaal kon er niet gegarandeerd worden dat de data op een correcte manier binnengelezen werd op de computer. Het signaal werd opgemeten aan de uitgang van de differentieel – TTL omvormer( begin van de bus ). Hieruit bleek dat het signaal ver van bruikbaar was om correct de nodige data binnen te lezen.


Figuur 34: Verbinding PXI en FSB bus

Figuur 35: Scoopbeeld Clock FSB 1m kabel

9.2

Testopstelling oplossing

De vervorming van het signaal was te wijten aan de te lange kabel NSC68-5050) die gebruikt werd om de FSB met PXI kaart te verbinden. De oplossing hiervoor was het inkorten van de kabel. De oorspronkelijke kabel had een lengte van 1m en deze werd ingekort tot zo’n 15cm. Op de scoopbeelden In figuur 35 was te zien dat er nog wat reflecties aanwezig waren. De oorzaak hiervan ligt bij de plaats waar het signaal wordt opgemeten. Doordat het niet mogelijk was om het signaal te controleren op het einde van de bus werd er gemeten aan het begin, wat reflecties tot gevolg heeft. Deze reflecties waren veroorzaakt doordat het signaal in het begin van de FSB gemeten werd, namelijk aan de uitgang van de differentieel – TTL omvormer. De omvormer is nodig om het PXI toestel geen differentieel signalen kan inlezen.


Figuur 36: Scoopbeeld Clock FSB ingekorte kabel

Om de signaalvorm nog verder te verbeteren werd een RC filter bijgevoegd op de differentieel – TTL omvormer. Het gebruikte RC filter bestaat uit een 100 ohm weerstand met in serie een 10pF capaciteit naar de massa. Normaal gezien wordt zo’n filter geplaatst dicht bij de ontvanger zijde, maar in dit geval werd ze dicht bij de zenderzijde geplaatst. De scoopbeelden tonen een duidelijk verbetering naar reflecties na het plaatsen van de filter. Nu kan er wel overgegaan worden tot het testen van het programma, aangezien er nu met zekerheid kan aangenomen worden dat de data op een correcte manier zal binnengelezen worden.

Figuur 37: Scoopbeeld Clock FSB ingekorte kabel + RC filter


10.

Programma

10.1 Aanmaken project Het allereerste dat dient te gebeuren bij het programmeren in LabVIEW is het aanmaken van een Project, hieronder worden dan alle VI’s ( Virtual Instruments ) aangemaakt. Door gebruik te maken van virtuele folders en logische benamingen kan er een gestructureerde omgeving gecreëerd worden. In de virtuele folders kunnen nieuwe VI’s aangemaakt worden. Als een VI opgestart wordt, worden er twee tabbladen aangemaakt, één voor de Front Panel en één voor het Block Diagram. De Font Panel is hetgeen de gebruiker te zien krijgt tijdens het runnen van het programma. Deze omgeving kan volledig ontworpen worden naar de behoefte van de gebruiker, door middel van een uitgebreid palet van controllers en indicatoren die beschikbaar zijn. Het Block Diagram is de geprogrammeerde code die op de achtergrond draait. Ook hier is een uitgebreide palet ter beschikking met alle mogelijke blokken. Als er op het Front Panel controllers of indicatoren zijn toegevoegd, dan worden deze ook zichtbaar in het Block Diagram. Daar kunnen deze dan door middel van lijnen en functies met elkaar verbonden worden. In wezen kan dit vergeleken worden met Visual Basic, maar in plaats van alle acties te gaan programmeren met woorden kan men hier alle acties aan elkaar linken via lijnen en de beschikbare functies.

Figuur 38: Structuur LabVIEW project

10.2 Inlezen datalijnen De eerste stap in het programma is het inlezen van de verschillende datalijnen op de FSB bus. In dit deel moet er slechts rekening gehouden worden met vier van de vijf datalijnen, namelijk de FSB clock-, AM_D-, MOSI 0en MOSI 1 lijn. Met de MISO lijn moet er geen rekening gehouden worden aangezien er eerst geconcentreerd wordt op het correct inlezen van de data om daaruit dan de nuttige data te gaan bepalen. Het terugsturen van data naar de master via de MISO lijn zal in een later stadium in het programma gebeuren. In onderstaande figuur zijn de vier datalijnen te zien van de FSB.

FSB clock lijn

AM_D lijn

MOSI 0 lijn MOSI 1 lijn Figuur 39: Datalijnen FSB


De FSB clock heeft een snelheid van 33MHz, dit betekent dat er elke 30,3 ns een puls gegenereerd wordt en dus ook een nieuwe databit op de andere lijnen. De AM_D lijn geeft aan wanneer er data dient gelezen te worden van de MOSI 0 en MOSI 1 lijn. Via deze twee lijnen wordt door de master: de mode, het adres, de data en checksum meegegeven aan de slaves. Er moet telkens op de stijgende flank van de clock één maal de status van de andere lijnen gelezen. De dalende flank van de clock zal later gebruikt worden om data op de MISO lijn te schrijven.

10.2.1 Controle datalijnen Vooraleer er kan overgegaan worden tot het programmeren moet er eerst gecontroleerd worden of de data die ingelezen is wel correct is en hoe groot de vertraging is op de ingelezen bits. Om dit te gaan controleren werden de ingelezen bits onmiddellijk terug naar buiten gestuurd om deze dan via een scoop te kunnen vergelijken met de werkelijke signalen van de FSB.

Figuur 40: Controleren van ingelezen datalijnen

Uit de scoopbeelden kan opgemaakt worden dat de datalijnen op een correcte manier worden ingelezen, maar dat er een vertraging van ongeveer 30ns aanwezig is op de naar buiten gestuurde bits. De vertraging kan verklaart worden door het feit dat de het programma de tijd nodig heeft om de bits in te lezen en zijn variabelen up te daten in het programma vooraleer ze dan terug naar buiten kunnen gestuurd worden. Op dit moment vormt de vertraging geen probleem aangezien enkel de bits van de lijnen moeten worden ingelezen, maar later zal hiermee rekening moeten gehouden worden als er op de MISO lijn geschreven wordt. Dit omdat het belangrijk is dat er op het juiste moment data op de lijn geschreven wordt. 30ns s

Figuur 41: Datalijnen FSB versus naar buiten gestuurde datalijnen


10.2.2 Bepalen flank FSB clock Er wordt gezorgd dat het programma aan een hogere snelheid werkt dan de FSB clock. Om dit te realiseren wordt gebruik gemaakt van een Timed Loop van 160MHz, dit wil zeggen dat het programma elke 6,25 ns uitgevoerd wordt. Aangezien de FSB clock aan een snelheid werkt van 33MHz en de Timed Loop aan 160MHz, zal het programma zo’n vijf keer doorlopen worden per puls op de FSB. Om ervoor te zorgen dat er slechts één maal een bit ingelezen wordt, controleert het eerste stukje in het programma twee zaken. Als eerste wordt nagegaan of de flank van de FSB clock gewijzigd is t.o.v. van vorige keer dat Timed Loop doorlopen werd. En als tweede of er al dan niet bij een stijgende flank reeds een bit ingelezen werd.

Figuur 42: Controle stijgende/dalende flank clock

10.3 Data analyseren Het tweede deel van het programma staat in voor het verwerken van de gelezen data. Er wordt gewerkt met een state machine, de eerste state is de “Init state” of initialisatie fase. Deze fase wordt slecht één maal uitgevoerd en dit bij het opstarten van het programma. In deze state worden alle shift registers die gebruikt worden ingesteld op hun startwaarde. Eenmaal dit is uitgevoerd wordt er overgegaan naar de tweede state, de “RESYNC1 state”. Het is in deze state dat alle ingelezen bits verwerkt worden. Het verwerken van de bits zal in verschillende stappen uitgevoerd worden: 1) 2) 3) 4)

Mode en Adres bepalen Data bepalen Checksum bepalen en controleren Startwaarde voor een nieuw bericht


10.3.1 Mode en Adres bepalen Als er een stijgende flank van de FSB clock is, is het eerste dat gecontroleerd wordt de bits van de AM_D lijn, dit omdat deze geven aan of de AM_D lijn hoog of laag is. Indien de bits laag zijn zal er niks door het programma worden uitgevoerd. Er wordt gewacht tot de bits opnieuw hoog worden om dan over te gaan met het bepalen van mode en adres.

Figuur 43: Bepalen Mode en Adres

Tijdens de periode dat de bits van de AM_D lijn hoog zijn worden de laatste tweeëndertig bits van MOSI 0 en MOSI 1 lijn bijgehouden. Op de MOSI 0 wordt de mode meegegeven en op de MOSI 1 het adres van de slave. Daarnaast wordt ook geteld of er vijf bits gevonden zijn voor de mode en adres. Om de mode af te lezen van het scoopbeeld moeten de laatste vijf bits van rechts naar links gelezen worden als de AM_D lijn laag komt. De mode die dan bekomen wordt is “10100” en komt overeen met een Question_ Answer.

FSB Clock

AM_D lijn

MOSI 0 lijn

Figuur 44: Scoopbeeld bepalen Mode

Wanneer de bits van de AM_D lijn laag worden, wordt er gecontroleerd of er inderdaad vijf bits gevonden zijn. Indien dit zo is worden de tweeëndertig gevonden bits met vijf geroteerd, op deze manier komen ze achteraan te staan in het pakket. Door een AND functie worden de eerste ( de oudste ) achtentwintig bits vervangen door een nul. Nu blijven enkel de laatste vijf gevonden bits (mode en adres) over en worden deze weggeschreven in de voorziene FIFO. De controle van de vijf bits heeft nog een tweede doel en dit is het bevestigen of het programma mag beginnen met het opslaan van data. Wanneer uit de controle blijkt dat er minder dan vijf bits gevonden werden tijdens het zoeken naar een mode en adres, wordt er niks uitgevoerd en wacht het programma tot de bits van de AM_D lijn opnieuw hoog worden om op zoek te gaan naar een nieuwe mode en adres.


Figuur 45: Wegschrijven mode/adres in FIFO

10.3.1.1

Controle mode/adres

Het controleren van de mode en adres kan niet gebeuren in het programma zelf. Aangezien alles Real-Time gebeurd, is het onmogelijk om te kunnen volgen wat er precies uitgevoerd wordt door het programma. Hiervoor wordt gebruik gemaakt van twee zijprogramma’s. Een tweede tijdelijke loop werd aangemaakt waar de FIFO’s van de modes en adressen uitgelezen en in een FIFO Data Log geschreven worden. Voordat de mode en adres werden weggeschreven in de FIFO Data Log werd er nog een code meegegeven zodat deze later van elkaar onderscheiden konden worden. Voor de mode werd de code “1” meegegeven en voor het adres de code “2”.

Figuur 46: Schrijven Mode/Adres in FIFO Data Log

Door de mode en adres samen in één FIFO te schrijven kan deze nu door het eerste zijprogramma uitgelezen worden en worden alle gevonden bits in een bitfile bijgehouden. Op deze manier wordt alle data bewaard om deze dan via het tweede zijprogramma terug uit de bitfile te gaan lezen. De gevonden data kan dan verwerkt worden en op het GUI gesorteerd weergegeven worden. Hierdoor kan gecontroleerd worden of de gevonden modes en adressen correct zijn. De eerste keren dat de modes en adressen via deze weg gecontroleerd werden kon er al snel geconcludeerd worden dat er iets niet correct was. De modes en adressen die bekomen werden kwamen geheel niet overeen met de modes en adressen die op de scoop te zien waren. Voor de modes zijn er slechts vijf mogelijkheden die genummerd zijn van één tot vijf, terwijl het programma’s modes vond van zeven en zelfs zevenendertig. Bij de adressen was het een gelijkaardig probleem.


Figuur 47: Controle mode/adres fout

Het probleem van de foute resultaten kan verklaart worden door een timing probleem. De klok van de FPGA target staat altijd op de default waarde van 40MHz. Hierdoor werd een deel van het programma slechts aan 40MHz, terwijl een ander deel aan 160MHz werkte. Dit had als gevolg dat er maar een vierde van de gevonden bits verwerkt werden in het programma en al de rest verloren ging. De target klok kon via de instellingen in het project aangepast worden. Eenmaal dit was aangepast werden wel de te verwachten modes en adressen gevonden.

Figuur 48: Controle mode correct


10.3.2 Data bepalen Wanneer het programma de bevestiging krijgt dat de mode en adres correct zijn begint deze met het opslaan van alle data. Gedurende de volledige tijd dat de bits van de AM_D lijn laag zijn wordt er data verzonden op de MOSI 0 en MOSI 1 lijn. Wanneer er begonnen wordt met opslaan van de data bits kan er vooraf niet voorzien worden hoeveel dit er zullen zijn. Wat wel geweten is dat het aantal bits data steeds een veelvoud van acht is.     

Broadcast Commando’s Interruptvragen Ms opvragingen Q_A

24 bits 16 bits 24 bits 512 bits 16 bits

=> => => => =>

3 x 8 bits 2 x 8 bits 3 x 8 bits 64 x 8 bits 2 x 8 bits

Om die reden werd ervoor gekozen om steeds datapakketten te maken die acht bits groot zijn. Eenmaal een pakket compleet is wordt hier ook een code meegegeven vooraleer ze in de voorziene FIFO’s geschreven worden. Deze code dient om later te kunnen bepalen welke het laatste pakket is van een datareeks en of deze van de MOSI 0 of MOSI 1 lijn afkomstig is. Ook wordt het aantal aangemaakt datapakketten bijgehouden. Op het moment dat de twee datapakketten worden weggeschreven moeten de nieuwe databits ook bewaart worden anders zullen deze verloren gaan en is de volledige datareeks incorrect. Doordat de hoeveelheid data bits steeds een veelvoud is van acht, moet er op het moment dat de bits van de AM_D lijn hoog worden niet meer gecontroleerd worden hoeveel bits er in het laatste pakket zitten op het moment dat deze wordt weggeschreven in de FIFO’s.

Figuur 49: Bewaren data MOSI 0/MOSI 1

In het programma wordt de data van beide MOSI lijnen bewaard, afhankelijk van de mode bestaat de mogelijkheid dat de data maar van één lijn of zelfs van geen van beide lijnen nuttig is. Bij een broadcast wordt er enkel op de MOSI 0 lijn nuttige data meegegeven. Terwijl bij een ms opvraging de data op beide MOSI lijnen nuttig is en bij Interruptvragen wordt er geen nuttige data verstuurt naar de slaves.


10.3.3 Controle data Het controleren van de data gebeurt opnieuw via de twee zijprogramma’s. Eerst en vooral worden in de tijdelijke loop in het hoofdprogramma de FIFO’s uitgelezen en net zoals de modes en adressen wordt de data nu ook opgeslagen in de FIFO Data Log. Doordat er werd bijgehouden hoeveel datapakketten er gevonden zijn kan er nu gebruik gemaakt worden van een For Loop. De For Loop zorgt ervoor dat de FIFO’s een gelijk aantal keren gelezen worden als het aantal pakketten die gevonden werden en dat de gelezen data weggeschreven wordt in de FIFO Data Log.

Figuur 50: Schrijven data MOSI 0-1 in FIFO Data Log

Het tweede zijprogramma werd aangepast zodat naast modes en adressen, nu ook de data van MOSI 0 en MOSI 1 gesorteerd en weergegeven wordt op de GUI. Net zoals bij de eerste testen van modes en adressen is de verkregen data op de twee MOSI lijnen incorrect.

Figuur 51: Controle data MOSI 0-1 fout

Na controle van het programma bleken er een paar redeneer fouten aanwezig te zijn in de tellers van de pakketten waardoor de data op een foutieve manier werd verwerkt. Door de uitgestuurde data opnieuw te vergelijken met de datalijnen op de FSB, kon het probleem snel gevonden worden. Op de scoopbeelden was te zien dat er steeds een wederkerende verlies van enkele bits was. Ditmaal was het geen timing probleem, maar was het te wijten aan een stukje code dat aan het programma toegevoegd was om de GUI te pauzeren.


Figuur 52: Databits verloren tijdens inlezen

Bovenstaande scoopbeeld toont duidelijk aan dat er enkelen bits verloren gingen. Het stukje code dat toegevoegd was diende om tijdens de beginfase van het programma de GUI te pauzeren om zo enkele zaken te kunnen controleren. In de eerste versie van het programma werden de datalijnen nog in een aparte loop ingelezen. Met de ingelezen bits werden er dan pakketten gemaakt van tweeëndertig bits. Deze pakketten werden daarna naar een tweede loop verzonden om deze daar te gaan verwerken. Het stukje code die geprogrammeerd was om een controle uit te voeren ging er telkens voor zorgen dat op het moment dat er een pakket aangemaakt was er een deel van de eerste loop gestopt werd. Dit had als gevolg dat een aantal bits niet werden ingelezen en dus ook foutieve data met zich meebracht. Door dit stukje code te verwijderen was het probleem met de foutieve data opgelost. In een laten stadium werden de twee loops samengevoegd tot één geheel. Dit omdat de eerste versie te traag was om correcte data op de MISO te schrijven.

Figuur 53: Loop programma versie 1


10.3.4 Checksum controle Nu de AM_D lijn terug hoog geworden is zal er een checksum controle uitgevoerd worden. Zoals in 3.1.3 reeds werd uitgelegd moet alle data en het checksum die door de master meegestuurd werd door de Linear Feedback shift register gecontroleerd worden. Eenmaal alle data gecontroleerd worden alle registers die de checksum waarden bijhouden met elkaar vergeleken. Indien er één van de registers niet gelijk is aan nul, wordt er een True bekomen en is de data incorrect. De uitkomst van de checksum wordt in een FIFO weggeschreven om dan, indien nodig, alle data die gevonden werd te verwijderen.

Figuur 54: Controle checksum

10.3.5 Controle checksum De controle voor de checksum kan onmiddellijk gebeuren in de tijdelijke lus die aangemaakt is. Bij de FIFO’s is er een functie aanwezig, namelijk “Get Number of Elements to Read”. Door hiervan gebruik te maken kan ervoor gezorgd worden dat de tijdelijke loop niets in de FIFO Data Log schrijft zolang de checksum niet gecontroleerd is. Pas als er een checksum controle is uitgevoerd en deze is in orde mag de loop beginnen met alles in de FIFO Data Log te schrijven. Indien de checksum niet in orde is wordt alle data uit de FIFO’s verwijderd. Via het tweede zijprogramma kan er snel gecontroleerd worden of de checksum al of niet correct wordt uitgevoerd. Indien niet alle data weergeven wordt die normaal gevonden moet worden, kan er geconcludeerd worden dat er ergens een fout zit in de checksum controle. Dit was niet het geval, dus kan er besloten worden dat de checksum controle correct is.

FSB clock

AM_D lijn

MOSI 0 lijn Figuur 55: Scoopbeeld checksum


10.3.6 Startwaarde Eenmaal de checksum controle is afgelopen wordt er nog gezocht naar een startwaarde. Dit is de allerlaatste stap vooraleer er opnieuw naar een mode en adres wordt gezocht. Via de startwaarde wordt aangegeven dat het bericht is afgelopen en dat er een nieuw bericht op komst is. Deze startwaarde is nodig zodat de master en slave gesynchroniseerd zouden zijn. De startwaarde op beide MOSI lijnen bedraagt “1111”. Op het moment dat deze waarde gevonden is kan het programma terug starten en van vooraf aan beginnen.

FSB clock

AM_D lijn

MOSI 0 lijn Figuur 56: Scoopbeeld startwaarde


10.4 MISO lijn schrijven Nu het inlezen en verwerken van de data volledig is afgewerkt kan er overgegaan worden tot het tweede gedeelte, namelijk het versturen van antwoorden naar de master. Hier wordt de stap gezet in het manipuleren van de FSB door in plaats van de slaves te gaan antwoorden. De lengte van het antwoord zal afhankelijk zijn van de ontvangen mode. Niet op alle modes verwacht de master dat er een antwoord wordt teruggestuurd door de slaves. Van de vijf modes zijn er slechts drie die effectief een antwoord gaan sturen naar de master, namelijk: Interruptvragen, Ms opvraging en Q_A. De opbouw van het antwoord gebeurt altijd op dezelfde manier. Eerst wordt er data verstuurd, daarna een ACK, twee ERROR bits en als laatste het checksum zodat de master de binnengelezen data kan controleren op fouten. Bij het manipuleren van de FSB zal het programma zich voordoen als slave 6.

10.4.1 Start schrijven MISO Het eerste dat dient te gebeuren is het nagaan op welk moment een slave die effectief aanwezig is op de FSB start met het schrijven van data. Dit moet nagegaan worden zodat er gecontroleerd kan worden of het programma niet te vroeg of te laat zou schrijven. Indien er te vroeg of te laat begonnen wordt met schrijven zal de data nooit correct ingelezen worden door de master.

Figuur 57: Start schrijven MISO lijn

Op bovenstaande scoopbeeld is de eerste maal te zien wanneer er op de lijn geschreven wordt, dit gebeurt op de de 5 dalende flank nadat de AM_D lijn laag geworden is. Vooraleer er gestart wordt met het schrijven van data is de MOSI lijn hoog , dit komt overeen met de rusttoestand.


10.4.2 Controle start schrijven MISO Om na te gaan op welk moment er gestart wordt met het schrijven door het programma wordt er gebruik gemaakt van twee pulsen. De eerste puls heeft aan op welk moment het eerste deel van het programma een mode heeft gevonden en deze wegschrijft in de voorziene FIFO. In het tweede deel van het programma werd deze FIFO dan opnieuw uitgelezen en werd een tweede puls naar buiten gestuurd op het moment dat de eerste bit geschreven zou worden op de MISO lijn.

Figuur 58: Controle start schrijven op MISO de

Op het scoopbeeld is duidelijk te zien dat de eerste bit al op de 3 dalende flank geschreven zou worden. Er kan dus besloten worden dat er te vroeg gestart wordt en dat de vertraging bij het inlezen van de datalijnen geen invloed heeft op het schrijven van data. Het programma zal twee kloktijden moeten wachten vooraleer deze mag starten met het schrijven van data op de MISO lijn.

10.4.3 Interruptvragen De eerste mode die geprogrammeerd wordt zijn de Interruptvragen. De reden voor die keuze komt door het feit dat de master bij opstart van de FSB begint met Interruptvragen en Ms opvragingen te verzenden. Op deze manier gaat de master na welke slaves er aanwezig zijn op de FSB. De data van de Interruptvragen wordt opgedeeld in twee stukken. Het eerste stuk bestaat uit interrupts en het tweede stuk bevat de Real Time Data. Net zoals in het eerste deel van het programma wordt de flank van de FSB clock gecontroleerd, maar ditmaal wordt er gezocht naar de dalende flank. Op elke dalende flank wordt er éénmaal gecontroleerd of er reeds iets in de FIFO’s van de mode en adres geschreven staat. Is dit niet het geval zal het programma niks uitvoeren. Indien er wel iets in geschreven staat zullen de twee FIFO’s uitgelezen worden en zal er bij de volgende dalende flank begonnen worden met het schrijven op de MISO lijn. Bij het programmeren van de Interruptvragen wordt gebruik gemaakt van een statemachine. Op deze manier kan het geheel opgedeeld worden in de verschillende stukken data die Interruptvragen bevatten en kan er later indien nodig gemakkelijk aanpassingen aangebracht worden.


Vooraleer er over gegaan kan worden tot het programmeren van de Interruptvragen zelf moet er eerst een vertraging geprogrammeerd worden. Dit is nodig omdat er anders te vroeg gestart wordt met schrijven. De eerste state van de statemachine is de “Wait” case. Op het moment dat er een mode en adres gevonden is, is dit de eerste case die doorlopen zal worden. Deze case zorgt ervoor dat het programma twee clock pulsen wacht voor hij start met schrijven op de MISO lijn. Wanneer één case is uitgevoerd van de statemachine wordt er automatisch overgegaan naar de volgende. Dit blijft hij doen totdat alle verschillende states zijn doorlopen. Eenmaal alle states doorlopen zijn zal het programma weer starten met het nagaan of er een mode en adres in de FIFO’s staat.

Figuur 59: Start schrijven MISO correct

10.4.3.1

Mode Interruptvragen uitwerken

Het programmeren van de Interruptvragen is in één keer geprogrammeerd. De interrupts en Real Time Data worden gesimuleerd door een array van Booleans. Op deze manier kan tijdens het runnen van het programma zelf een keuze gemaakt worden op het GUI welke interrupt en Real Time Data bits actief zijn. Voor de ACK bit wordt er steeds een False geschreven, hiermee wordt bevestigt dat de slave het bericht en het adres gezien heeft. Bij de twee ERROR bits wordt steeds een True geschreven, dit wil zeggen dat er geen fouten zijn opgetreden tijdens het ontvangen van de data en dat het checksum ervan correct is. En als laatste wordt de checksum bepaald die bij de data behoort zodat de master de ontvangen data kan controleren.

Figuur 60: Statemachine Interruptvragen


10.4.3.2

Controle Interruptvragen

De eerste controle voor het schrijven van de Interruptvragen gebeurde via de scoop. In de twee onderstaande scoopbeelden wordt het verschil aangetoont tussen het niet en wel schrijven op de MISO lijn. Op het eerste beeld is te zien dat slave 2, die effectief aanwezig is op de FSB, schijft, maar dat slave 6 die het programma simuleerd niet schrijft. Dit is duidelijk te zien aan het feit dat de FSB terug naar zijn rustpositie gaat na het antwoordt van slave 2 te hebben geschreven. Het eerste beeld werd genomen op een moment dat het programma nog niet actief was. Eenmaal het programma geactiveerd was, werd er wel op de MISO lijn geschreven op de momenten dat dit diende te gebeuren. Bij de eerste tests werden dezelfde interrupt en Real Time Data bits naar buiten gestuurd zoals degene die actief zijn bij slave 2. Wanneer er via het GUI andere interrupt bits actief werden gemaakt, bracht dit zoals gewenst een verandering teweeg bij het schrijven op de MISO. Deze verandering stemde overeen met de instellingen op het GUI. Hieruit kan er besloten worden dat er het programma in staat is om op het juiste moment te starten met schrijven op de FSB en dat de naar buiten gestuurde data ook correct is.

Figuur 61: Slave 6 schrijft niet op MISO

Figuur 62: Slave 6 schrijft op MISO


De tweede controle die uitgevoerd wordt is het nagaan of de master het geschreven antwoord herkent. Dit gebeurt via een programma genaamt FSB debugger. Het is een programma die door PsiControl Mechatronics zelf aangemaakt is om de FSB te kunnen testen. Via dit programma kan er gecontroleerd worden of de master geen error heeft op het ontvangen van de slaves. Bij het controleren moet er gekeken worden naar de FSB Error Summary Register. De eerste vier bits (links beginnen) zijn de bits die de errors aangeven.

   

Bit 1: Commando’s Bit 2: Interruptvragen Bit 3: Ms Opvragingen Bit 4: Q_A

Bij de testopstelling zal er geen error verkregen worden bij de commando’s aangezien er geen commando’s verzonden worden door de master. De bit die momenteel van belang is, is de tweede. In het begin van deze controle bleek dat de tweede bit constant op “1” stond bij slave 6. Aangezien er wel correct op de MISO geschreven werd kon het probleem niet liggen bij het programmadeel dat instaat voor het schrijven van de Interruptvragen. Het probleem kon gevonden worden bij een enable signaal. Om het programma de toegang te geven tot het schrijven op de FSB moet er een signaal naar buiten gestuurd worden. De FSB gedraagt zich zoals een tokennetwerk, degene die wil schrijven houdt de token bij tot hij klaar is en geeft dan de token door aan de volgende. Maar dit enable signaal werd constant naar buiten gestuurd. Het gevolg hiervan was dat de FSB niet werd vrijgegeven voor de andere slaves en dat de master de antwoorden die teruggestuurd werden niet wilde herkennen. Door het signaal enkel te gaan enablen op het moment dat het programma gaat schrijven was het probleem opgelost en herkende de master het antwoord dat door het programma geschreven werd. In de FSB Error Summary Register is nu ook te zien dat er enkel nog een error fout gegeven wordt bij de Ms Opvraging en de Q_A en niet bij de Interruprvragen.

Figuur 63: FSB Debugger Interruptvragen


10.4.4 Ms Opvragingen De tweede mode die uitgewerkt wordt is de Ms Opvragingen, zoals reeds in 10.4.2 werd vermeld is deze mode van toepassing bij het opstarten van de FSB. Net zoals bij de Interruptvragen wordt er gebruik gemaakt van een state machine, waardoor er sterke gelijkenissen zijn tussen beiden. Ook zal er opnieuw rekening dienen gehouden te worden met het moment van schrijven op de MISO. Deze mode zal door de slave gebruikt worden om informatie omtrent actieve motoren en kleppen terug te sturen naar de master. Op die manier zal de master weten welke de volgende commando’s zijn die hij dient te versturen.

10.4.4.1

Mode Ms Opvragingen uitwerken

In tegenstelling tot de Interruptvragen bestaat de Ms Opvragingen uit één stuk data en wordt deze opnieuw door middel van een array van booleans gesimuleerd. Bij deze mode bestaat de data uit 512 databits. Om het overzicht te kunnen bewaren op de GUI wordt zestien maal dezelfde array van tweeëndertig bits na elkaar geschreven op de MISO. Na de data volgt opnieuw een ACK bit, twee ERROR bits en een checksum.

10.4.4.2

Controle Ms Opvragingen

De controle van de Ms Opvragingen gebeurt op dezelfde manier als bij de Interruptvragen. In eerste instantie werd de controle via de scoop uitgevoerd. Op het scoopbeeld van Ms Opvragingen werd een terugkerend patroon verwacht aangezien het model zestien keer dezelfde array van booleans op de MISO schreef. Dit was dan ook het geval. De tweede controle werd opnieuw met het programma FSB Debugger uitgevoerd. In figuur 63 is te zien dat bij het controleren van slave 6 de FSB Error Summary Registor slecht één bit heeft die nog hoog is, namelijk de ERROR bit van Q_A. Verder is nog te zien dat de master geen fouten meer geeft op de ontvangen data van de Interruptvragen en van de Ms Opvragingen. De mode Q_A zal niet worden uitgewerkt aangezien deze mode enkel de mogelijkheid bied om gegevens op te vragen aan de slave zoals: programma ID, slave ID, FPFA type ID, enz.


Figuur 64: FSB Debugger Ms Opvragingen

10.4.5 Commando’s Na het uitwerken van de Interruptvragen en Ms Opvragingen volgt de mode Commando’s. Bij deze mode wordt er geen nuttige data terug gestuurd naar de master. Het commando van de master dat naar de slave verzonden wordt bestaat uit een functie en een actie. Via deze twee gegevens weet de desbetreffende slave welke acties uitgevoerd dienen te worden. Door het programmeren van de commando’s wordt er een terugkoppeling gemaakt tussen de master en het model. Dit komt omdat de data die door de slave meegegeven wordt in de Ms Opvragingen steeds verandert met een nieuw commando. De slave gebruikt de Ms Opvragingen om de master op de hoogte te brengen van welke acties hij heeft kunnen uitvoeren. Op die manier weet de master welke het volgende commando zal zijn dat verstuurt moet worden. Door het feit dat de Ms Opvragingen bij elke nieuw commando verandert zal dus elk bestaand commando volledig apart geprogrammeerd moeten worden. Zo is het dan steeds mogelijk om de Ms Opvragingen up te daten. Wegens het feit dat het aanmaken van het model gebeurt op een testopstelling worden er geen commando’s door de master zelf verstuurd. Wel is het mogelijk om via de FSB Debugger de master te manipuleren en een commando te sturen. Op deze manier zal er een niet bestaand commando verstuurd worden om aan te tonen wat de werking van het model zal zijn in de toekomst.


Het uitwerken van de commando’s zal niet in het model gebeuren van de Interruptvragen en Ms Opvragingen. Bij het vinden van een commando zal er enkel een signaal gegeven worden naar een ander model, die dan het commando zal bepalen. De reden om het op deze manier te doen komt door het feit dat het model te zwaar zou worden en er timing problemen zouden optreden. Daarnaast zal elk commando zijn eigen model moeten hebben aangezien elk commando een andere uitwerking vereist. Nadat er een signaal is doorgegeven met een bevestiging dat er een commando gevonden is zal een ander model starten met zoeken naar het commando zelf. Zoals reeds vermeld werd bestaat het commando uit een functie en een actie. De functie wordt door de master meegegeven op de MOSI 0 lijn en de actie op de MOSI 1 lijn. Aangezien de functie uit twaalf bits en de actie uit zestien bits bestaat zullen er twee pakketten van acht bits uit de twee FIFO’s gelezen moeten worden en deze data zal dan opnieuw samengesteld moeten worden tot één geheel.

Figuur 65: Bepalen commando's

Eenmaal de verzonden functie en actie opnieuw één geheel zijn kan er een bijhorende Ms Opvragingen samengesteld worden om door het model naar de master te versturen. Bij de testopstelling worden enkel de zestien booleans van de Ms Opvragingen aangepast. Als de commando’s in de toekomst volledig worden uitgewerkt dan zal er hoogst waarschijnlijk een case aangemaakt moeten worden die oploopt van 0 tot 511 om zo elke bit van de Ms Opvragingen afzonderlijk te kunnen instellen.


11.

Besluit

Deze masterproef was een zeer leerrijke en unieke ervaring, zowel op educatief als op persoonlijk vlak. Een goeie planning en communicatie zorgden ervoor dat het project tot een goed eind werd gebracht. Uiteraard verliep alles met ups en downs maar met de opgedane kennis en de raad van ervaren mensen werd ieder probleem rustig aangepakt en opgelost. De doelstelling van dit project was nagaan of het mogelijk is om alle slave boards die via de FSB bus communiceren met de hoofdprocessor, te vervangen door een model. Ook het berekenen van de kostprijs van dit project was belangrijk daar dit doorslaggevend is voor het al of niet verder zetten van dit project. Het eerste deel van de masterproef bestond erin om een marktonderzoek te verrichten naar alternatieven voor het software pakket LabVIEW(National Instruments). Na marktonderzoek kan er opgemaakt worden dat National Instruments verschillenden concurrenten heeft, zoals ADLINK, Agilent Technologies, MathWorks en dSPACE. Een deel van de concurrenten stellen echter enkel maar hardware ter beschikking. Uit diegene die eveneens software aanbieden heeft PsiControl Mechatronics met LabVIEW een correcte keuze gemaakt. Het programma LabVIEW is gemakkelijker te programmeren, flexibeler en sneller te debuggen. Voor personen die geen kennis hebben van LabVIEW is de programmeertaal ook beter te begrijpen.

Figuur 66: Blokschema ontworpen model

Het tweede deel van de masterproef bestond erin om een model te ontwerpen om na te gaan of het al niet mogelijk is om de communicatie tussen master en slave boards te gaan simuleren. De eerste stap van het model bestond erin om alle communicatie tussen master en slave boards in te lezen. Hier is aangetoond dat het wel degelijk mogelijk is om alle data verzonden door de master zonder fouten te


kunnen inlezen. Het grootste probleem tijdens deze stap was het clock signaal van de Fast Serial Bus die in eerste instantie te veel vervormd was door een te lange verbindingskabel tussen PXI (PCI eXtensions for Instrumentation) en de Fast Serial Bus. De tweede stap in het model was het uitwerken van de ingelezen data. In deze stap werd alle data verwerkt om daaruit het slave adres , mode en bijhorende data te bepalen. Ook hier is het mogelijk om alle nuttige data te gaan onderscheiden van de ongeldige data en deze dan in geheugenlocaties op te slaan. De derde en laatste stap in het model was het formuleren van een antwoord die terug naar de master wordt gestuurd. Op deze manier werd er een terugkoppeling gemaakt met de master en werd de data constant aangepast. Het belangrijkste hierbij is niet het antwoord zelf maar het moment waarop het model het antwoord terugstuurt naar de master. Het is van cruciaal belang dat het versturen van een antwoord op het juiste moment gebeurd, anders wordt de data niet door de master aanvaard. De kostprijs dat de verdere uitwerking van dit project met zich zal meebrengen is afhankelijk van verschillende aspecten. Er wordt geschat dat er voor de verdere ontwikkeling één persoon minstens zes maanden fulltime hiermee bezig zal zijn. Dit komt neer op een kost van zo’n €50.000. Daarnaast zal er een extra FPGA ( ± €5.000) module aangekocht moeten worden per simulator. Momenteel zijn er drie simulators operationeel en zullen deze in de toekomst uitgebouwd worden naar vijf. Bij de laatste twee simulators zou de aankoop en het plaatsen van de devices niet meer van toepassing zijn wat neer komt op een besparing van zo’n € 7.000. Daarnaast is er nog het feit dat de PXI dichter zal moeten komen te staan van de Fast Serial Bus met het master board. Indien de afstand te groot is zullen er problemen ontstaan bij het inlezen van de data. Hiervoor zal er dus een kortere en stabiele verbinding nodig zijn tussen de PXI en de Fast Serial Bus. De kostprijs van dit project zal minstens €65.000 bedragen. Daar tegenover staat wel een sterke verbetering zowel op het vlak van kwaliteit, kwantiteit en de testmogelijkheden van de simulator. Deze masterproef dient als een fundament voor de verdere ontwikkeling van de simulators. De zes maanden die geschat worden voor de verdere ontwikkeling zullen vooral opgaan in de derde stap van het model, namelijk het aanmaken van modellen die de slave antwoorden simuleren. Daarnaast zal er ook nog een aanpassing dienen te gebeuren aan de simulators zelf, gezien momenteel de afstand tussen de PXI en Fast Serial Bus te groot is om bruikbare datasignalen te kunnen inlezen.


Bibliografie [1] Telemark University Colege (2011), Site [on line]. http://home.hit.no/~hansha/documents/lab/Lab%20Work/HIL%20Simulation/Background/Introduction%20to %20HIL%20Simulation.pdf (datum van opzoeking 25/02/2012) [2] National Instruments (2007), LabVIEW Basics 1: Introduction Course Manual, Austin Texas [3] National Instruments ( 2007), LabVIEW Basics 2:: Development Course Manual, Austin Texas [4] Schacht, Stijn ( 2010). HIL Weaving Machine Picano. België: Bavikhove [5] PsiControl Mechatronics (2010). FSB Optimalisatie hardware layer. België: Ieper [6] PsiControl Mechatronics (2008 ). PPF FSB(Fast Serial Bus). België: Ieper [7] EETime (2011), Site [on line]. http://www.eetimes.com/design/embedded/4024865/Hardware-in-the-Loop-Simulation ( datum van opzoeking (25/02/2012) [8] National Instruments ( 2011), Forum [on line]. http://forums.ni.com/t5/LabVIEW/bd-p/170 (datum van opzoeking 11/10/2011) [9] Wikipedia (2012), Site [on line]. http://en.wikipedia.org/wiki/Hardware-in-the-loop_simulation (datum van opzoeking 25/02/2012)


Bijlagen Alle bijlagen die betrekking hebben tot de masterpoef zijn terug te vinden op de CD-ROM. Daaraan is toegevoegd:    

Projectfiche Poster Samenvatting LabVIEW programma


Masterproef Tester Real-Time Software For Weaving Machine

Recommend Documents