Styring af decentralt rensningsanlæg

Transkript

1 Styring af decentralt rensningsanlæg -med et distribueret indlejret system Afsluttende eksamensprojekt ved: Diplomingeniøruddannelsen, IMM, DTU Udarbejdet af: Allan Krogh Jensen (d973989) 25/ / Under vejledning af: Knud Smed Christensen, DTU Mads Siggaard-Andersen, Logos Control Systems AS

2 2

3 Forord Dette eksamensprojekt er afslutningen på Diplomingeniøruddannelsen ved Institut for Informatik & Matematisk Modellering (IMM) på Danmarks Tekniske Universitet i Lyngby. Projektet er udført hos Logos Control Systems, som en del af et større projekt (B-Ware), firmaet er i gang med. Jeg vil gerne takke mine vejledere Mads Siggaard Andersen (Logos Control Systems) og Knud Smed Christensen (DTU), for konstruktiv kritik og vejledning igennem hele projektforløbet. Jeg vil også takke ingeniørerne hos Logos Control Systems, især Preben Bech for generel information vedr. B- Ware projektet, samt Bo Kjøller for generel hjælp vedr. hardware. Projektets omfang er blevet beskåret lidt igennem projektforløbet, efter samråd med mine vejledere. Løsningsmetoderne og testmetoder er løbende blevet forbedret. Alle disse handlinger er beskrevet i rapporten, sideløbende med den praktiske udformning af projektet. Rapporten er opbygget struktureret fra starten. Selve dokumentationen vedr. løsning og test af projektet er inddelt efter emneområde, som hver især beskriver den løbende udvikling, i kronologisk rækkefølge, inden for pågældende emne. Denne struktur er valgt for at sikre ensartet dækning af alle projektets underopgaver. Det forudsættes at læseren har et grundlæggende kendskab til indlejrede systemer og programmering af disse i ANSI C. Det er endvidere en fordel, hvis læseren har grundlæggende kendskab til I²C-bussen samt A-D Konvertering og HTML. Kgs. Lyngby, Februar 2003 Allan Krogh Jensen d / s

4 Resumé Dette projekt er første del af en større opgave, som består i at implementere et distribueret indlejret system, til styring af et decentralt rensningsanlæg. Rensningsanlægget er et EU-støttet projekt, kaldet B-Ware, som udføres i samarbejde med en række andre europæiske firmaer. Hele rensningsanlægget styres i øjeblikket af to PC er og en stor mængde I/O udstyr. Målet er at det distribuerede indlejrede system skal være mindre, billigere og mere pålideligt. Eksamensprojektet skulle i første omgang omfatte implementering af den nye styring i en tredjedel af rensningsanlægget, nemlig i det såkaldte Bioreaktor Modul. Det viste sig dog hurtigt at være en alt for stor opgave til et 10 ugers eksamensprojekt. Derfor blev projektet begrænset til af omfatte indledende test af I²C-bussen i et hårdt miljø og styring af en pumpe, udfra væskeniveauet i en beholder. Brugergrænsefladen er webbasseret, og kan derfor styres via netværket, fra en browser. På baggrund af dette oplæg udføres en lang række tests af forskellige I²Ckabler og deres immunitet over for støj i forskellige situationer. Disse tests udføres efterhånden som den nødvendige hardware og software færdigøres, med automatisk testsoftware, som styres via websider. Styringssoftwaren forener delopgaverne i projektet, idet sensorinputtet bruges til automatisk kontrol af en tænd/sluk pumpe. Sensorerns måleværdier logges og kan løbende vises som en graf. Hvis styringen ikke er tilsluttet et netværk, kan den overvåges fra en lokal Touch-Screen. Til slut installeres den nye styring i forsøgsanlægget, hvor den nu har overtaget den fulde kontrol med kælderpumpen. 4

5 Indholdsfortegnelse FORORD...3 RESUMÉ...4 INDHOLDSFORTEGNELSE INDLEDNING OPGAVEFORMULERING TIDSPLAN B-WARE PROJEKTET TEKNIKKEN BAG B-WARE Bioreaktor Modulet Ultrafilter Modulet Nanofilter Modulet PROBLEMFORMULERING PROJEKTAFGRÆNSNING PARAMETRE Vandmængde i Equalizeren og Bioreaktoren Ilt-mængde i Bioreaktoren UDSTYR SOM SKAL STYRES Kælderpumpen (P1) Ventilerne (V1, V2 og V3) Fødepumpen (PO1) Omrøreren (RO1) Luftblæseren (PO2) Sprinkleren (P3) Ventilatoren (M2) STYRING Manuel styring Automatisk styring Alarm generering Processorkortet PROBLEMANALYSE ANALYSE AF I/O-KRAV Nøjagtigheden i væskeniveau målingerne Nøjagtigheden af ilt-styringen ANALYSE AF EKSISTERENDE RESOURCER Eksisterende hardware Eksisterende software til processorkortet Eksisterende ekspertise OPDELING AF PROJEKTET Distribuering af interfacekortene Objekt Orienteret analyse af styringen REVIDERET PROJEKTAFGRÆNSNING SOFTWARE UDVIKLINGSMILJØET SOFTWAREMODULERNE STYRING AF POWERRELAY-KORTET Driveren til PowerRelay-kortet Adgang til I²C-bussen fra Webinterface Automatisk test af I²C-kabel m.m LÆSNING FRA ADC MODULET Driver til ADC-kredsen Læsning via Webinterface

6 4.4.3 Automatisk test via Webinterface STYRING AF DAC MODULET STYRING AF KÆLDERPUMPEN Overvågning via webinterface Synkroniseret opdatering og styring Kalibrering af sensor Opsætning af grænseværdier Logning af tidligere måleresultater Overvågning via displayet HARDWARE POWERRELAY-KORTET OG I²C KABLET Valg af kabel Stik og Konnektorer Test af PowerRelay-kortet ADC MODULET Valg og bestilling af ADC-kreds Overordnet design Interface til Strømsløjfen Spændings-I²C konverteringen I²C-driver til brug ved lange kabler Test af ADC Modulet Revision B DAC MODULET Valg og bestilling af DAC Overordnet design I²C-Spændings konverteringen Udgangsforstærkeren SAMLET STYRING Automations test i laboratoriet Indbygning i kabinetter Installation og test i forsøgsanlægget...82 KONKLUSION...84 LITTERATURLISTE...85 APPENDIX...86 APPENDIX A TIDSPLANER...86 Appendix A1 Oprindelig Tidsplan...86 Appendix A2 Revideret Tidsplan...87 APPENDIX B KILDEKODE...88 Appendix B1 WebIO.c...88 Appendix B2 ADS7823.c...98 Appendix B3 BWare.c Appendix B4 DeviceLog.c Appendix B5 UWelcome.c APPENDIX C DIAGRAMMER Appendix C1 PowerRelay-kortet Appendix C2 ADC Modulet Rev. A Appendix C2 ADC Modulet Rev. B Appendix C3 DAC Modulet APPENDIX D DATABLADE Appendix D1 ADS7823 (uddrag af databladet)

7 1 Indledning 1.1 Opgaveformulering Logos Control Systems er med i et fælles Europæisk projekt, kaldet B-Ware, som går ud på at udvikle et decentralt rensningsanlæg. Styringen til dette udvikles af Logos Control Systems. Der er opbygget et forsøgsanlæg, som er tilsluttet et vaskeri i Helsingør. Her foregår styringen indtil videre med to PC er, samt dertil hørende software, men da hele anlægget gerne skulle fylde meget mindre end det gør nu, og være billigere, ønskes styringen foretaget af en eller flere mindre indlejrede processorkort. Det er her mit eksamensprojekt kommer ind i billedet. Da projektet skal udføres på 10 uger, begrænses det til at omfatte en mindre del af anlægget. Der tages udgangspunkt i et processorkort som Logos Control Systems, selv har udviklet, og som bygger på en Intel StrongARM processor. Systemet skal kunne styre tilførelsen af spildevand til anlægget, og styre bioreaktoren. Bioreaktoren er første etape af anlægget, og udgør en tank med en bakteriekultur, som skal passes for at overleve. Systemet skal kunne udvides til at styre hele anlægget, på et senere tidspunkt. Projektet indebærer styring af fem motorer, en variabel og fire on/off, samt to ventiler. Til styring af On/off motorerne og ventilerne skal der konstrueres et Relækort. Til styring af luftpumpen, som har variabel hastighed, konstrueres et PWM-motorstyringskort. Al styring foretages på baggrund af to væskeniveau sensorer, og en ilt-sensor, som læses via et ADC-kort. Pumper og sensorer eksisterer allerede i anlægget. Processorkortet kommunikerer, med kortene, via en I²C-bus. Det skal desuden kunne styres/overvåges fra en ekstern PC, derfor skal der også udvikles et web-interface, der nås via dets Ethernet-port. Systemet skal til slut installeres, i det fugtige og støjfyldte miljø, i forsøgsanlægget. Godkendt af Knud Smed Christensen 18/ Tidsplan Sammen med opgaveformulering, er der udarbejdet en tidsplan for projektet. Projektet skal påbegyndes 25/ og afleveres 13/2-2002, tiden herimellem er så blevet fordelt, efter hvor meget hver enkelt delopgave antages at kræve. Tidsplanen kan ses i Appendix A1. 7

8 1.3 B-Ware Projektet Formålet med B-Ware Projektet er at udvikle et vandrensningssystem, som gør det muligt at genbruge vandet decentralt, der hvor det forurenes, og derved spare på det dyrebare drikkevand. Endvidere spares en del på opvarmning af vandet, da det renses og sendes tilbage imens det stadig er en smule varmt. Anlægget skal kunne bruges til en række forskellige spildevandskilder, som f.eks. vaskerier, bilvaske haller og swimmingpools. B-Ware Projektet er et fælles europæisk projekt, blandt seks firmaer, under Eureka samarbejdet (se ). Firmaerne er: IPM Management (DK), som tager sig af projektledelsen. VITO (B), som står for ultrafiltre og nanofiltre. Envidan (DK), som står for den biologiske rensning. Logos Control Systems (DK), som står for den elektriske styring. Miele Danmark (DK), som stiller krav til hvad det skal kunne, for at virke sammen med et vaskeri. Ocyasa (E), som stiller krav til hvad det skal kunne, for at virke sammen med en swimmingpool. Figur 1-1: Containeren som indeholder forsøgsanlægget, der er tilsluttet vaskeriet til højre. Figur 1-2: Vaskeriet i Sundparken, Helsingør. Projektet startede i 1998, og har siden da været i en udviklings fase, hvor der er blevet opbygget et forsøgsanlæg, i en container. Containeren sendes, på skift rundt til de medvirkende firmaer, i de forskellige lande. P.t. er containeren tilsluttet et vaskeri i Helsingør, hvor Logos Control Systems kan udvikle og teste deres styrings system. Når forsøgsanlægget virker planmæssigt, skal der konstrueres en noget mindre og simpel prototype, da det færdige anlæg gerne skal kunne installeres af en almindelig VVS-montør eller lignende. Det er et mål at et færdigt B-Ware anlæg skal kunne tjene sig selv ind på mindre end 5 år, derfor skal det selvsagt også være så rationelt som muligt. 8

9 1.4 Teknikken bag B-Ware Spildevandet fra vaskeriet, løber ned i en lille tank i kælderen, hver gang en maskine skyller ud. Her sørger den autonome kælderpumpe for at pumpe vandet op i forsøgsanlægget, når tanken er tilpas fuld. Vaskeriet kan så hente rent vand direkte fra anlægget, i en begrænset mængde. Da der er tale om et samarbejde imellem en række firmaer, som hver har sin måde at gøre tingene på, er det selvsagt ikke den mest rationelle måde anlægget fungerer på. Det er også grunden til at anlægget styres af to PC er med hver sin type software. Logos PC med selvudviklet software, og VITO s PC med LabView-software. B-Ware Anlæg Bioreaktor Modul Ultrafilter Modul Nanofilter Modul Spilde Vand Vaskeri Rent Vand Figur 1-3: Blokdiagram for B-Ware anlægget tilsluttet et vaskeri Anlægget anvender tre velkendte teknologier; Mekanisk/Biologisk rensning, Ultrafiltrering og Nanofiltrering, til at rense vandet. Spildevandet renses på alle tre måder før det er rent nok. Anlægget kan derfor opdeles i tre moduler, en til hver metode. Vandets flow er skitseret herover. Hvert modul beskrives nærmere i de følgende afsnit Bioreaktor Modulet Bioreaktor Modulet er første etape af anlægget, og udgøres hovedsageligt af en Equalizer-tank og selve Bioreaktoren. Equalizeren udjævner det uforudsigelige flow fra kældertanken, således at Bioreaktoren får et konstant input flow. Modulet sørger også for at det tunge bundfald fjernes, med en mekanisk rensning, i form af en Clarifier. Bioreaktoren indeholder den bakteriekultur som står for den biologiske rensning af vandet. I øjeblikket styres modulet af en PC fra Logos Control Systems. 9

10 Figur 1-4: Et kig ind i containeren. Bioreaktor Modulet er nede for enden. Til højre ses lidt af Ultrafilter og Nanofilter Modulet. Figur 1-5: Et kig ned i Bioreaktoren. Den er stort set fyldt med små plastikstykker, hvorpå bakterierne sidder. Øverst ses en sprinkler dysse. Gitteret til højre sørger for at plastikstykkerne ikke flyder ud sammen med vandet Ultrafilter Modulet Ultrafilter Modulet er anden etape af anlægget, og udgøres af et ultrafilter kredsløb Ultrafilter kredsløbet pumper vandet igennem nogle membranfiltre, under højttryk. Vandet der udskilles i filtret løber så over i Nanofiltrets Equalizer-tank. Ultrafiltret fjerner alle partikler med en størrelse på ned til 0,35 µm. Modulet blev indtil fornyelig styret af en PC fra VITO, men styres nu af samme PC som styrer Bioreaktor Modulet Nanofilter Modulet Nanofilter Modulet er tredje etape af anlægget og udgør hovedsageligt en Equalizer-tank, selve nanofiltret og en beholder til det rene vand. Equalizeren udjævner det uforudsigelige flow fra ultrafiltret, således at nanofiltret får et konstant input flow. Nanofiltret fjerner de resterende partikler fra vandet. Modulet styres af en PC fra VITO. 10

11 Basement Vessel Equalizer Mixer Clarifier V--2 Ventilator V--2 Bioreactor Airblower 2 Problemformulering 2.1 Projektafgrænsning Det er som udgangspunkt meningen at hele B-Ware anlægget med tiden skal styres af en eller flere processorkort fra Logos Control Systems, i stedet for de to PC er som anvendes nu. Men da dette Eksamensprojekt skal udføres på 10 uger, afgrænses det til kun at omfatte styring af Bioreaktor Modulet. Jeg har valgt dette modul fordi det er det eneste modul der p.t. kører stort set fejlfrit, hvorved det bliver nemmere at teste den nye styring. Atmosfæren RO1 M2 Fra Vaskeriet S1 Smudsfilter Clarifier S3 Equalizer S2 Bioreaktor Til Ultrafilter Modulet PO1 P1 V--1 V1 V2 V3 P3 PO2 Kældertanken Kloak Kloak Kloak Figur 2-1: Diagram for Bioreaktor Modulet som det ser ud nu Bioreaktor Modulet som det er vist herover, styres i øjeblikket af en PC med nogle I/O-kort. De gule komponenter er pumper, ventiler og motorer som skal styres automatisk. De grønne komponenter er sensorer. 2.2 Parametre Modulet styres på baggrund af i alt tre variable proces parametre, som måles af hver sin sensor. To tryksensorer (S1 og S2), som bruges til at måle væskeniveauet i henholdsvis Equalizeren og Bioreaktoren, samt en iltsensor (S3) der måler iltniveauet i Bioreaktoren Vandmængde i Equalizeren og Bioreaktoren Styringen har brug for at vide om der er for meget, for lidt, eller en tilpas mængde vand i henholdsvis Equalizeren (S1) og bioreaktoren (S2). Det måles med én tryksensor i bunden af hver tank, da trykket derved er proportionalt med vandmængden i tanken. 11

12 Sensorern som anvendes til dette er en Kobold SEN-3251-B146 (se datablad på CD en). Den anvender standarden 4-20 ma, hvilket vil sige den sender en strøm på mellem 4 og 20 ma rundt i en strømsløjfe, afhængig af den målte værdi. Hvor 4 ma svarer til 0 bar og 20 ma svarer til 0,25 bar. Fordelen ved at anvende en strømsløjfe, fremfor bare at afgive en spænding, er at signalet ikke forringes ved at blive sendt igennem lange kabler. En anden fordel er at en ødelagt sensor eller kabel hurtigt kan opdages, eftersom strømmen da er mindre end 4 ma. Figur 2-2: Niveausensor (tryksensor S1) og bundventil på Equalizeren (V1) Figur 2-3: Niveausensorern (tryksensorern S2) på Bioreaktoren For at kunne vurdere vandmængden i tankene, skal der angives nogle faste min. og max. værdier, som vandmængden gerne skal holdes indenfor. De er selvsagt afhængige af tankenes størrelse. Equalizeren og Bioreaktoren har et volumen på ca liter hver. Equalizeren bruges, som navnet antyder, til at udligne den meget varierende vandtilførsel, så Bioreaktoren kan få en nogenlunde konstant vandtilførsel. Equalizerens min. niveau (EMin) sættes til 50 liter, og dens max. niveau (EMax) til 950 liter. Bioreaktorens min. niveau (BMin) sættes til 900 liter, og dens max. niveau til 950 liter. Derved tvinges niveauet i Bioreaktoren til at være maximalt, imens Equalizerens niveau er mere varierende. Nøjagtigheden på niveauet, behøver ikke at være bedre end +/- 5 liter, da selve volumen ikke er interessant, men kun om volumen overskrider grænseværdierne Ilt-mængde i Bioreaktoren For at styringen kan regulere lufttilførelsen til Bioreaktoren automatisk, har den brug for at vide hvor højt et indhold af ilt (mg/liter), der er i Bioreaktoren. Dette måles med en ilt sensor (S3). Ilt-sensoren er af typen Vernier DO-DIN, og kan måle ilt-inhold på mellem 0 og 14 mg/liter, med en nøjagtighed på +/- 0,2 mg/liter. Det tager ca. 45 sekunder, efter sensoren er placeret under vandet, til den afgiver en præcis 12

13 måling. Hvis resultatet istedet ønskes i ilt-procent, skal temperaturen og barometertrykket også kendes. Da der hverken er tilsluttet termometer eller barometer til systemet, vurderes værdien i mg/liter til at være god nok, til brug ved regulering af lufttilførelsen. Ilt-sensorern måler i øjeblikket ikke mængden af opløst ilt i vandet, da den er placeret for tæt på luftindblæsningsdysserne. Derfor skal den flyttes til et mindre turbulent område af bioreaktoren for at kunne måle rigtigt. Et sådan område kunne f.eks. være under gitteret (se figur 1-5), hvor vandet flyder ud af bioreaktoren, langt fra luftdysserne. Det vides endnu ikke præcist hvilken ilt-mængde der er optimal for bioreaktoren, da der stadig udføres forsøg med forskellige bakteriekulturer. Det er derfor vigtigt at alle parametre til PID reguleringen, inkl. Ilt-mængde setpoint, kan justeres manuelt via webinterfacet. 2.3 Udstyr som skal styres Modulet skal styre i alt otte pumper, ventiler og motorer. Luftblæseren (M3) skal kunne kører med variabel hastighed. Resten skal bare kunne tændes og slukkes Kælderpumpen (P1) Kælderpumpen hører egentlig ikke med til selve anlægget, men er nødvendig for at få spildevandet fra kældertanken op til anlægget som står på stueetage niveau. Kælderpumpen styrer sig selv, og begynder automatisk at pumpe, hvis der er for meget vand i kældertanken. Det er derfor kun muligt for styringen at bestemme om pumpen må pumpe eller ej, den kan ikke startes på kommando, kun stoppes. Figur 2-4: Kælderpumpen (P1). Spildvandet kommer fra vaskeriet via det grå rør, og pumpes op til anlægget via den grønne slange. Figur 2-5: Fødepumpen (PO1), Clarifieren s bundventil (V2)og Luftblæseren (PO2). 13

14 Den kælderpumpe der anvendes er en Grundfos APL , som ses på figur 2-4. Den bruger 230 V, i en fase, og trækker ca. 10,7 A, når den kørerr. Den styres i øjeblikket af en contactor, som styres via en DO (Digital Output) port fra PC ens I/O-kort Ventilerne (V1, V2 og V3) Bundventilerne i Equalizeren, Clarifieren og Bioreaktoren, bruges alle til at tømme bundfald ud i kloakken. De kan også bruges til at tømme tankene helt ved rensning af disse. Ventilerne skal derfor kun kunne være helt åbne eller helt lukkede. De bundventiler der anvendes er af typen Bernard OA8, og bruger en elektromotor til at åbne og lukke for ventilen. Det tager ca. seks sekunder for ventilen at komme fra den ene yder position til den anden, hvis motoren kører for fuld kraft. Derved kan ventilen stilles i en vilkårlig position, blot med styring via et relæ. Motoren bruger 230 V i en fase, og trækker 1,2 A, når den kørerr. Ventilerne er lige blevet monteret i anlægget, og styres endnu ikke Fødepumpen (PO1) PO1 sørger for at pumpe vandet fra Equalizeren over i Clarifieren, som så lader det øverste lag vand passere videre til Bioreaktoren. Derved er det værste bundfald sorteret fra. Pumpen kan enten være tændt eller slukket. Fødepumpen er af typen Bredel SP/15 som er en peristaltisk slangepumpe. Dvs. at den pumper ved at presse på forskellige steder af overfladen, på en gummislange, hvori væsken befinder sig. Pumpen bruger 230 V i tre faser og trækker 1,4 A når den kører. Pumpen styres i øjeblikket af en contactor, som styres via en DO-port fra PC ens I/O-kort Omrøreren (RO1) I forsøgsanlægget bruges Clarifieren til at bundfælde det tyktflydende slam. For at gøre dette, anvendes en motoriseret omrører. Den nuværende motor/gearkasse gør imidlertid at omrøreren kører alt for hurtigt, hvorved den modsatte effekt opnås. Slammet slynges rundt i vandet, og både vand og slam sendes videre til bioreaktoren. Derfor er der indsat et smudsfilter før Clarifieren, til at tage det værste slam. Omrøreren bruges derfor kun til at opløse evt. tilsætningsstoffer, som bruges til forsøg med anlægget. Den indgår ikke i den automatiske styring. Men skal dog stadig kunne styres manuelt fra web-interfacet. Omrøreren skal kun kører i en hastighed, hvorved det kun er nødvendigt at kunne tænde og slukke for den. Omrøreren er en form for propel, der er nedsænket i Clarifieren. Propellen roteres af Magnetek elektromotor, der bruger 230 V, i tre faser, og som trækker 0,7 A når den kører. Den styres i øjeblikket af en contactor, som styres via en DO-port fra PC ens I/O-kort. 14

15 2.3.5 Luftblæseren (PO2) Bakterierne i bioreaktoren behøver ilt for at overleve. Luftblæseren blæser luft op fra bunden af bioreaktoren, således at luftboblerne spredes til alle bakterierne. Luftblæseren skal kunne blæse med variabel hastighed, således at det er muligt at regulere iltindholdet i Bioreaktoren optimalt. Luftblæseren er af typen Rietschle SAP 90, som bruger 400 V i tre faser, og trækker 1,75 A når den kørerr. Den styres i øjeblikket af en frekvensmotorstyring (også kaldet PWM-motorstyring), af typen Siemens Micromaster Vector 6SE32. Den styrer motorens tre faser udfra en spænding på 0-10 V, som kommer fra en AO (Analog Output) port på PC ens I/O-kort. Motorstyringssignalet bliver altså konverteret to gange, først fra 12-bit digital til en spænding, derefter fra en spænding til et tre faset PWM-signal. Der skal derfor konstrueres en ny motorstyring til Luftblæseren, som danner PWMsignalet udfra kommandoer via I²C-bussen. Luftblæseren skal, med den ny styring, kunne styres lige så præcist som ilt-sensorerns målinger læses. Laveste hastighed skal få motoren til at stoppe helt, og ikke brumme som den gør nu Sprinkleren (P3) Sprinkleren sørger for at vandet fra bunden af Bioreaktoren kommer op til overfladen. Hvorved vandet kommer forbi bakterierne flere gange, og derved renses bedre. Desuden bidrager sprinkleren også til at ilte vandet, og fjerne skum fra overfladen. Sprinkleren skal derfor altid være tændt når anlægget kører automatisk, men skal dog alligevel kunne styres manuelt fra webinterfacet. Figur 2-6: Sprinkleren monteret på Bioreaktoren Figur 2-7: Ventilatoren Pumpen til sprinkleren er af typen Pedrollo PKSM 65, som bruger 230 V i en fase, og trækker 3,7 A når den kørerr. Den styres i øjeblikket af en contactor, som styres via en DO-port fra PC ens I/O-kort. 15

16 2.3.7 Ventilatoren (M2) Ventilatoren sørger for at kultveilte og andet brugt luft ledes bort fra Bioreaktoren. Desuden bidrager ventilatoren til nedkølingen af hele containeren. Ventilatoren skal derfor altid kører, men skal kunne styres fra web-interfacet. Ventilatoren kan enten være tændt eller slukket. Ventilatoren bruger 230 V i en fase, og trækker under 2 A når den kørerr. Den styres i øjeblikket af et almindeligt 230 V relæ, som styres via en DO-port fra PC ens I/O-kort. 2.4 Styring Fremgangsmåden, eller algoritmen, til hvordan anlægget skal styres kendes allerede, og den virker som den skal. Styringen foretages af software på processorkortet. Det nye i styringssoftwaren er at den skal kunne kommunikere med både et web-interface, og med udstyr på en I²C-bus. Figur 2-8: De to PC'er som i øjeblikket styrer anlægget. Øverst den fra Logos. Nederst den fra VITO. Figur 2-9: Skabet med den nuværende styring til Bioreaktor Modulet. Det skulle gerne være overflødigt når dette projekt er afsluttet! Manuel styring Selvom B-Ware til slut gerne skulle kører fuldautomatisk, er der selvfølgelig stadig brug for at hver enkelt pumpe, motor og ventil kan styres manuelt, samt at alle sensorerrnes måleværdier kan aflæses. Derved kan anlægget nemmere testes og serviceres. Den manuelle styring og overvågning skal foretages af et web-interface. Via webinterfacet skal det være muligt at skifte mellem manuel og automatisk styring. Alle sensorerrnes måleværdier i Volt, samt henholdsvis Liter og Iltprocent skal opdateres og vises jævnligt. Hvis der opstår en alarmtilstand skal 16

17 denne skrives på webinterfacet, således at kun den nyeste vises. Hvis der kørers med Manuel styring, skal det selvsagt være muligt at tænde/slukke for pumperne, åbne/lukke for ventilerne, samt angive en hastighed for Luftblæseren. Desuden skal det være muligt at kalibrere sensorerne efter et linært sammenhæng, ved at angive to måleværdier, og deres tilsvarende værdi i henholdsvis liter og Ilt-procent. Altsammen noget der kan gøres med den eksisterende PC styring Automatisk styring Når systemet, via web-interfacet, sættes til at kører automatisk. Skal det selv overtage kontrollen over anlægget, og styre det efter en fastlagt metode. Flowcharten nedenfor illustrerer hvordan den automatiske styring foregår i øjeblikket, og det virker som det skal, derfor er det også sådan min styring skal virke. Imens systemet kører automatisk skal det stadig være muligt at overvåge sensor målinger og status på pumper m.m., men dog ikke muligt at styre dem. Start Tænd PO1, PO2 og P1 Luk V1,V2 og V3 S1>EMax? Ja Stop P1 Nej S1<EMin? Ja Start P1 Nej Stop PO1 Ja S2>BMax? Nej Start PO1 Ja S2<BMin? Nej Justér PO2 afhængig af S3 Ja Auto? Nej Slut Figur 2-10: Den automatiske styring af Bioreaktor Modulet, som den er nu. 17

18 Inden automationssløjfen starter initialiseres det udstyr som ikke er afhængigt af sensorerrnes målinger. Dvs. at sprinkleren (P3) og ventilatoren (M2) startes, hvis de da ikke allerede kører, for at holde liv i bakterierne. Derudover lukkes alle bundventilerne (V1, V2 og V3). Herefter begynder sløjfen med at sammenligne Equalizerens niveau (S1) med dens grænseværdier, hvis niveauet er større end EMax, stoppes P1. Hvis det er mindre end EMin, startes P1. Det samme sker med Bioreaktorens niveau (S2), her er det blot P2 som styres. Efter det justeres hastigheden på luftblæseren (PO2), udfra iltprocenten i Bioreaktoren. Denne justering er ikke bare start/stop, som de andre pumper, men anvender en såkaldt PID regulerings algoritme (Proportional-Integral-Derivative). PID algoritmen skal bruge et ønsket iltniveau, kaldet setpoint, for at virke. PID teknologien går kort fortalt ud på at styringen ikke skal være oscilerende, dvs. outputtet ikke bare tændes og slukkes, men justeres ind på det ønskede niveau (setpoint). Den automatiske styring skal til enhver tid kunne afbrydes via web-interfacet, hvorved der skiftes til manuel kontrol Alarm generering Hvis styringen eller anlægget kommer i en tilstand, hvor det ikke fungerer som forventet, skal der vises en alarmmelding på web-interfacet. De alarm tilstande som styringen skal kunne registrere, er listet herunder. Alarm: S3 Malfunction Betingelse: S3 <= 0 % eller S3 > 50 % Handling: Sæt luftblæserens (PO2) hastighed til 50 % Alarm: P1 or S1 Malfunction Betingelse: P1=Tændt, PO1=Slukket og Equalizerens niveau konstant i 5 min. Handling: Stop P1 og P2 Alarm: PO2 or S3 Malfunction Betingelse: PO2 <> Setpoint i 10 min. Sagt med andre ord: Det lykkedes ikke PID reguleringen at nå det ønskede ilt-niveau inden for 10 min. Handling: Meld fejlen På et senere tidspunkt skal alarmerne evt. også sendes pr. til nogle der kan servicere anlægget hurtigst muligt. Men min styring begrænses dog til bare at vise alarmerne på web-interfacet og udføre den beskrevne nødhandling Processorkortet Til styringen af anlægget bruges et processorkort som Logos Control Systems oprindelig har udviklet til styring af vaskemaskinereservationer, for Miele. Men da kortet er meget fleksibelt, er det meningen at det efterhånden skal indgå i alle styringer fra Logos Control Systems. IK6 som kortet kaldes, bygger på en 18

19 Intel StrongARM SA-1110 processor suppleret med bl.a. Flash RAM, USB, Ethernet, RS-232, kortlæser interface til både magnet- og chipkort og display, samt I²C. Figur 2-11: Blokdiagram for Intel StrongARM SA-1110 processoren. StrongARM processoren er en 32-bit RISC processor, som normalt bruges i PDA er og mobiltelefoner. Derfor har den også en række ekstra features, i forhold til almindelige processorer. Den har f.eks. LCD display controller og PCMCIA interface. Processorkortet var i første omgang ikke designet til at styre eksternt I²C-udstyr, men har dog I²C-bussen ført ud i ekspantionsstikket. For at Processorkortet kan styre PowerRelay-kortet, har Logos måttet lave et ekspansionskort, i form af et såkaldt piggyboard. Det fører I²C-bussen fra ekspantionsstikket, og ud i et lille 4 polet stik, der udover I²C-bussen indeholder 5 V og GND. 19

20 3 Problemanalyse 3.1 Analyse af I/O-krav Systemet drejer sig i bund og grund om styring af en række pumper, ventiler og motorer, udfra målinger på nogle sensorer. Derfor kortlægges alle inputs/outputs (se tabellen herunder), for at få et overblik over hvilken hardware der skal anvendes. Udstyr Navn I/O Beskrivelse Løsning S1 Equalizerens 4-20 ma Input AD Konverter m.m. Niveausensor Forsynes med VDC S2 Bioreaktorens 4-20 ma Input AD Konverter m.m. Niveausensor Forsynes med VDC S3 Ilt-sensoreren 0-5 V Input AD Konverter m.m. Forsynes med VDC V1 Equalizerens 230 V, 1 fase, 1,7 A, Relæ Bundventil Tænd/Sluk Output V2 Clarifierens 230 V, 1 fase, 1,7 A, Relæ Bundventil Tænd/Sluk Output V3 Bioreaktorens 230 V, 1 fase, 1,7 A, Relæ Bundventil Tænd/Sluk Output P1 Kælderpumpen 230 V, 1 fase, 10,7 A, Relæ med Contactor Tænd/Sluk Output PO1 Fødepumpen 230 V, 3 faser, 1,4 A, Relæ med Contactor Tænd/Sluk Output PO2 Luftblæseren 400 V, 3 faser, 1,75 A, PWM Motorstyring Variabel Hastighed Output P3 Sprinkleren 230 V, 1 fase, 3,7 A, Relæ med Contactor Tænd/Sluk Output RO1 Omrøreren 230 V, 3 faser, 0,7 A Relæ med Contactor Tænd/Sluk Output M2 Ventilatoren 230 V, 1 fase, 2 A, Tænd/Sluk Output Relæ Som det ses kan alt I/O, interfaces med brug af fire forskellige hardware typer. De to niveausensorer skal have omsat deres strømsløjfe signal, til et digitalt som kan læses fra I²C-bussen. Ilt-sensoreren skal have omsat sit spændingssignal til digitalt som kan læses fra I²C-bussen. Sensorerne skal også forsynes med en spænding på mellem 10 og 30 VDC. Alle outputs, undtaget Luftblæseren, skal styres af et relæ, evt. med contactor. En contactor er i princippet et relæ, der kan tåle meget store strømme igennem sig, og styres som oftest af en 230 V spænding. Derfor kræver en contactor et mindre relæ til styring. I systemet anvendes contactorer til de pumper/motorer der er tre-faset, og/eller trækker mere end 2 A. Luftblæseren skal som tidligere nævnt styres af en tre-faset motorstyring. 20

21 3.1.1 Nøjagtigheden i væskeniveau målingerne Det I/O-kort der i øjeblikket anvendes til at opsamle data fra sensorerrne, anvender en 12-bit AD-konverter. Kortet er købt som standardvare, men da det højest sandsynligt ikke er nødvendigt at kunne skelne imellem 4096 væskeniveauer, vil jeg analysere problemet nærmere. Equalizeren og Bioreaktoren har begge en volumen på 1000 liter, og det er i følge problemformulering nok med en nøjagtighed på +/- 5 liter. De tryksensorer der anvendes kan måle fra 0 til 0,25 bar. Hverken bundventiler eller sensorer er, som Figur 2-2 og 2-3 viser, placeret helt nede i bunden af tankene. Sensorerrne kan derfor ikke måle al væsken. Tankenes volumen måles derfor eksklusiv det væske der ligger i bunden. I Equalizeren er massen af vandet i en fuld tank (M) ca kg. Dens volumen er V=1 m3. Massetætheden kan så findes med følgende formel: = V M ρ 1000 = = 1000 kg/m3 1 Trykket på niveausensorern når tanken er fuld kan så findes med følgende formel: 5 3 p= p + ρ gy= 1, ,8 1= 111,1 Pa 0 10 Hvor p er i trykket på sensorern i Pascal [Pa]. p0 er trykket ved vandoverfladen, dvs. det atmosfæriske tryk [Pa]. ρ er massetætheden [kg/m3] for vandet. g er er tyngdeaccelerationen [m/s2]. y er afstanden fra vandoverfladen og ned til sensorern [m]. Trykket omregnes til bar; 1,111 bar. Sensorerrne måler kun trykket udover det atmosfæriske tryk (1,013 bar), altså vil den maksimale trykændring som sensorern bliver udsat for være på 1,111-1,013=0,098 bar. Hvilket kun er ca. 40 % af sensorerns måleområde, på 0 til 0,250 bar. Hvis volumen er på mellem 0 og 1000 liter, og skal kunne måles med +/- 5 liters nøjagtighed, skal der kunne skelnes imellem min. 1000/5=200 forskellige væskeniveauer. Da sensorern kun måler i 40% af sit måleområde, skal dens 4-20 ma måleværdi min. kunne skelnes blandt: = 500 niveauer 0,4 Det er stort set samme procedure for niveausensorern i Bioreaktoren. Eneste forskel er, at massen M, for 1000 liter vand her er lidt større. Bioreaktoren er ca. halvt fyldt med plastikstykker, hvorpå der er bakteriemasse (se figur 1-5). Det antages derfor at 1000 liter vand m.m., her vejer ca kg. Hvorved der fås en massetæthed på 1010 kg/m3. I følge den tidligere anvendte formel giver det et tryk, på sensorern, på 111,2 Kpa, svarende til 1,112 bar. Hvilket giver en trykændring på 1,112-1,013=0,099 bar. Altså stort set det samme 21

22 som ved Equalizeren, dens måleværdi skal derfor også kunne skelnes imellem min. 500 niveauer. Det forudsættes her at niveauerne er målt med en nøjagtighed på +/- 0%, hvilket i praksis er umuligt. Det kan der kompenseres for ved bl.a. at konvertere til flere niveauer, men mere om det senere Nøjagtigheden af ilt-styringen Nøjagtigheden af ilt-sensorern og luftblæserens hastighed er tæt knyttet sammen. Det giver ikke mening at have mange flere forskellige hastighedsniveauer, end forskellige ilt-niveauer sensorern kan måle, men det gør ikke noget at have flere sensor-niveauer end hastighedsniveauer. Derved kan sensormålingerne midles, og bruges til kompensering for den manglende nøjagtighed. Der skal dog tages højde for at sensorern ikke måler lige så momentant (ca. 45 sekunders forsinkelse), som luftblæseren kan skifte hastighed, men det er noget der skal justeres i PID reguleringen. Hvis Ilt-mængden måles imellem 0 og 14 mg/liter, med en nøjagtighed på +/- 0,2 mg/liter, skal der minimum kunne skelnes imellem niveauer større end 0,2 mg/liter, svarende til 14/0,2=70 niveauer. Det vil dog alligevel, som tidligere nævnt, være smart med flere niveauer, netop for at prøve at kompensere lidt for usikkerheden på +/- 0,2 mg/liter. Antallet af hastighedsniveauer for luftblæseren, skal så ligge lidt under antallet af sensor-niveauer. 3.2 Analyse af eksisterende resourcer Logos Control Systems laver til daglig indlejrede styrings systemer, så der er ingen grund til at starte helt fra bunden med at genopfinde hjulet. Det ser jeg som en væsentlig fordel ved at udføre projektet i en virksomhed Eksisterende hardware Logos Control Systems laver hovedsageligt systemer til styring af reservationerne i vaskerier, for vaskemaskineproducenten Miele. Men de har også en række mindre kunder, som skal have lavet kundespecifikke projekter. Derfor har de også en hardwaredesigns fra tidligere tider, som kan tages frem og genbruges. Det er allerede nævnt at jeg vil anvende deres selvudviklede processorkort IK6, til selve styringen. Under min praktikperiode hos Logos Control Systems, fik de til opgave at konstruere noget hardware, for Miele. Konstruktionen skulle gøre det muligt for IK6, at tænde og slukke for nogle 230 V spændinger, i en vaskemaskine. Disse spændinger er bl.a. til låsning af vaskemaskinens dør. Konstruktionen skulle også kunne aflæse værdien af to kontakter. Opgaven resulterede i en printplade, kaldet PowerRelay, som Logos p.t. får produceret i større styktal. Derfor vil det være ret smart hvis det kan anvendes til noget af dette projekt. Et PowerRelay-print har to 2 A relæ outputs, og to digitale inputs isoleret med optokoblere. Printet har desuden en 230V - 22

23 12V/5V strømforsyning, der kan levere 500 ma. Alle inputs og outputs kan styres via I²C-bus. Diagrammer for printet findes i appendix. PowerRelay-printet har kun to relæ-udgange, hvilket langt fra er nok til styring af Bioreaktor Modulet, men der kan tilsluttes op til fire PowerRelay-print på en I²C-bus, hvis de blot får forskellig adresse. Adressen sættes nemt på printet via en DIP-switch. Strømforsyningen, som er dimensioneret til at levere mere end printet selv skal bruge, kan bruges til at forsyne andre interfacekort. PowerRelay-printet bør derfor anvendes til så meget som muligt Eksisterende software til processorkortet Da Logos bruger processorkortet til meget forskelligt, findes der selvsagt allerede en mængde software, alt sammen skrevet i C. Derfor er det også et krav at jeg skriver den nye software i C. Noget af det er skrevet i en flad funktionsorienteret struktur, imens andet er skrevet i en form for objektorienteret struktur. Der findes selvfølgelig driver software til processorkortets basale funktionaliteter, så som bl.a. I²C og Ethernet, som begge skal bruges i dette projekt. Desuden er der netop lavet noget driver software til PowerRelayprintet. Så heller ikke her startes på bar bund Eksisterende ekspertise Ingeniørerne på Logos Control Systems, har selvfølgelig en del ekspertise, når det gælder deres processorkort. Derudover har en af ingeniørerne speciale i stærkstrøm og har før lavet en PWM motorstyring, så han kan blive en god hjælp når motorstyringen skal designes. 3.3 Opdeling af projektet Som den foreløbige tidsplan også antyder, kan dette projekt opdeles, i nogle mindre delprojekter. I de følgende afsnit vil det blive forklaret, hvorfor det er struktureret som det er Distribuering af interfacekortene Fordelen ved at anvende et distribueret indlejret system er, udover at minimere den fysiske størrelse af styringssystemet, også at erstatte mange af de kabler, som går fra den centrale styring og ud til pumper og ventiler m.m., med et enkelt kommunikationskabel (i dette tilfælde I²C-bus). Ideelt set skal der være et lokalt interfacekort, ved hver enkelt udstyr, for at have et minimalt antal ledninger. I Bioreaktor Modulet ville det kræve ikke mindre end 12 interfacekort, hvis det skulle realiseres. Det vurderes imidlertid lidt for omfattende og omkostningsfuldt til dette projekt. I stedet tages der udgangspunkt i optimal udnyttelse af relæerne på PowerRelay-printene, hvilket indebærer at der skal bruges fire af disse, til styring af de i alt otte tænd/sluk ventiler, pumper m.m. De tre sensorerrs inputs konverteres til I²C-bus, på et interfacekort, i stedet for 23

24 Basement Vessel Equalizer Clarifier Bioreactor tre, af samme årsag. Der konstrueres et selvstændigt kort til motorstyringen. Dermed skal der i alt bruges 6 interfacekort, hvoraf de 4 er PowerRelay-print. For at udnytte strømforsyningen på PowerRelay-printet, tilsluttes konverterkortet og motorstyringskortet til hver sit PowerRelay-print. Derved er interfacekortene delt op i fire lokale klynger, som senere hver især skal udgøre en interfacebox (IB), og indbygges i kabinetter. Fra Vaskeriet IB1 S1 V1 Equalizer RO1 Clarifier IB2 Smudsfilter PO1 PO2 IB3 M2 V3 Bioreaktor S3 IB4 P3 S2 Til Ultrafilter Modulet V ma Input 0-5 V Input P1 Relæ Output Kældertanken Relæ og Contactor Output Variabel Hastighed Output Interfacebox Figur 3-1: Fysisk placering af udstyret i Bioreaktor Modulet Hvis ledningerne som anvendes, fra pumper, ventiler m.m. til interfaceboxene, skal være så korte som muligt, skal de fire interfaceboxe fysisk placeres strategisk korrekt i Bioreaktor Modulet. En smart distribuering af interfaceboxene (IB1-4), vises på figur 3-1. Som det ses, repræsenterer cirklerne udstyr, som skal måles eller styres. Firkanterne repræsenterer interfacekortene IB1, IB2, IB3 og IB3. Alt er placeret med omtrent samme måleforhold til hinanden, som den virkelige bioreaktor. En cm på Figurn, svarer ca. til 25 cm i virkeligheden. Dog er afstanden fra IB1 og ned til kælderpumpen (P1), ca. 20 m i virkeligheden. I2C-bus IB1 IB2 IB3 IB4 Ethernet IK6 PR1 PR2 PR3 MC PR4 ADC Con1 Con2 Con3 Con4 Figur 3-2: Blokdiagram for hardware modulerne i det nye styresystem IB1 skal stå for styringen af kælderpumpen (P1) og Equalizerens bundventil (V1). Klyngen skal udover et PowerRelay-print (PR1), indeholde en contactor (Con1), til at trække P1. 24

25 IB2 skal stå for styringen af Fødepumpen (PO1), og Omrøreren (RO1). Klyngen skal udover et PowerRelay-print (PR2), indeholde to contactors (Con2 og Con3), da både PO1 og RO1 kræver det. IB3 skal stå for styringen af Clarifierens bundventil (V2), Bioreaktorens bundventil (V3), samt Luftblæseren (PO2). Derfor skal klyngen udover et PowerRelay-print (PR3), indeholde motorstyringskortet (MC), til Luftblæseren. IB4 skal stå for styringen af Ventilatoren (M2) og Sprinkleren (P3). Derudover skal det indsamle data fra alle sensorerrne, v.h.a. konverter kortet (ADC). Klyngen indeholder også et PowerRelay-print (PR4), og en contactor (Con4), til at drive Sprinkleren. Hardware modulerne kan altså deles op i fem forskellige typer: processorkortet (IK6), PowerRelay-printet (PR), Contactorer (Con), motorstyringskortet (MC), og konverter kortet (ADC). Hvoraf kun MC og ADC, skal designes helt fra bunden. Hardware-delen af projektet, kan altså deles op i følgende tre underopgaver: Konstruktion af Motorstyringskort, Konstruktion af Konverter Kort, og tilslutning/installation af eksisterende kort Objekt Orienteret analyse af styringen Selvom softwaren ikke skal implementeres i et 100% objekt orienteret programmeringssprog, men i ANSI C. Giver det alligevel et godt overblik, at analysere problemet udfra en objekt orienteret tankegang, og det er faktisk muligt at lave en form for objekt-orienteret program i ANSI C. Jeg vil anvende UML til analysen af problemet, og opdeling i klasser/moduler. Først opstilles et Use Case diagram, udfra kravene som blev stillet i problemformuleringen. Selvom det er meningen at styringen for det meste skal foregå automatisk, tager mani UML alligevel udgangspunkt i menneskets kommunikation med systemet. I dette tilfælde operatørens overvågning/styring via webinterfacet. Operatøren, som her f.eks. kan være en forsker, eller en VVS-montør, betegnes i UML som en aktør. Opsætning Overvågning / Styring Operatør Start/Stop Automatik Figur 3-3: Use Case diagram Operatøren har mulighed for at styre/overvåge systemet, opsætning af parametre, samt bestemme om anlægget skal kører automatisk, eller styres manuelt. Hver af disse funktionaliteter kan betegnes som en Use Case. 25

26 Use Case diagrammet bidrager blot til at give et overblik hvad systemet, skal kunne. Den resterende UML model med klassediagram, sekvensdiagram osv. vil i dette tilfælde blive droppet, da det antages at være for meget i forhold til softwaremængden i dette projekt. Desuden er den eksisterende kode hos Logos, en blanding af obejekt-orienteret og ikke-objekt-orienteret kode, hvilket besværliggører integrering af eksisterende softwaremoduler i klassedigrammet. 3.4 Revideret projektafgrænsning Efter denne problemanalyse, og samråd med mine vejledere, har vi besluttet, at projektet er alt for omfattende, til at kunne udarbejdes på 10 uger. Derfor er der beskåret en del af projekt, og udarbejdet en Revideret Tidsplan (se appendix). Design og konstruktion af en PWM-motorstyring, ville være et eksamensprojekt i sig selv, og er derfor fjernet helt fra projektet. I stedet for at bruge fire PowerRelay-print, bruges kun et (PR), da de alligevel virker ens, er der ingen grund til at demonstrerer det fire gange. Konverter kortet (ADC) skal stadig konstrueres, men kun med en kanal til en niveausensor. Derved kan den også komme til at sidde helt lokalt, hvor sensorern er placeret. Hvilket minimerer længden af det analoge signalkabel fra sensorern til konverteren. I stedet for motorstyringen, skal der konstrueres et Digital-Analog konverter kort (DAC), som kan bruges til styring af den eksisterende Siemens motorstyring. Desuden får webinterfacet højere prioritet, da det kan bruges til løbende at teste systemet. Den automatiske styringssoftware er nedprioriteret og ligger derfor sidst i projektet, og kommer selvsagt kun til at omfatte de ventiler/pumper, som systemet kan styre. I2C-bus IB1 IB2 IB3 IB4 Ethernet IK6 PR ADC DAC Eksist. MC Figur 3-4: Revideret blokdiagram for hardware modulerne i det nye styresystem For at sikre at projektet er på rette spor, skal der ca. halvvejs i forløbet (15. januar) afholdes en fremvisning for vejlederne, hvor de har mulighed for at evaluere projektet. Der vil også blive lagt mere vægt på løbende test af systemet, for hurtigst muligt at opdage fejl. Sammen med denne reviderede projekt afgrænsning, er der også udarbejdet en revideret og mere præcis tidsplan, som findes i Appendix A2. Afleveringsdatoen er desuden blevet udskudt til 17/ p.g.a. sygdom. 26

27 4 Software 4.1 Udviklingsmiljøet Alt det software som bruges til processorkortet er skrevet i ANSI C. Software udvikling foregår i udviklingsmiljøet Metrowerks CodeWarrior. Der er specielt velegnet til StrongARM-processoren, som sidder i processorkortet. Herfra kan softwaren kompileres og buildes til et binært image (*.bin-fil), som så senere kan downloades til FlashRAM en på processorkortet. Tidligere skulle dette image overføres til Flashen via en meget langsom seriel transmission kaldet JTAG. Men de nyeste versioner af Logos software kerne, indeholder en web-baseret FlashLoader, således at det er muligt at downloade programmet via netværket (Ethernet), fra en almindelig webbrowser. 4.2 Softwaremodulerne Meget af den grundlægggende software til at betjene processorkortets udstyr, har Logos allerede udviklet. Softwaren til dette projekt skal derfor så vidt muligt anvende de eksisterende softwaredrivere. Af eksisterende drivere kan bl.a. nævnes: iic.c til kommunikation på I²C-bussen, tempsens.c til aflæsning af processorkortets temperatursensor, http.c til kommunikation via et webinterface, desuden er der en række drivere til kommunikation med Touch-Screen displayet. Softwaremodulerne som er udviklet i dette projekt, og deres afhængighed af hinanden, er illustreret i figuren herunder: ADS7823 DeviceLog WebIO BWare UWelcome Figure 4-1: Softwaremodulerne (filererne) som er udviklet i dette projekt. Pilene angiver afhængigheder. 4.3 Styring af PowerRelay-kortet PowerRelay-kortet bruges i øjeblikket allerede til andre af Logos projekter. Derfror er softwaren til styring af det, for mit vedkommende, begrænset til at omfatte sammenspillet immellem relækortets driver, og min test/styrings software Driveren til PowerRelay-kortet Relækortet er oprindelig bl.a. udviklet til styring af en dørlås på et Mielevaskeri. Men det bruges også allerede til en række andre applikationer hvor processorkortet skal styre 230 V spændinger. Derfor findes der selvfølgelig 27

28 allerede en software driver til det, så det er ikke nødvendigt at starte helt fra bunden. Driveren som normalt bruges til dørlåsen er door.c, som selv bruger driveren iic.c til den basale I²C-kommunikation. Ved at inkludere dens header-fil, og oprette en lokal I²C-instans, er der adgang til relækortets funktionalitet. I²C-instansen til relækortet består af: Static ClassFunction_T *WebIOextioP; Static ClassExtInOutFuncs_T *WebIOextioFuncP; Hvor WebIOextioP er en pointer til en instans af relækortet, og WebIOextioFuncP er en pointer til funktionerne i driveren. Disse variable skal initialiseres før de kan bruges, hvilket gøres i WebIO_Init(), i filen WebIO.c. Herefter kan Relæerne styres med funktionen relayset(), og aflæses med relayget(). Optokoblerne på kortet kan aflæses med optoget(). Alle funktionerne skal have WebextioP medsendt som argument. Der kan vælges imellem 4 relæer og 4 optokoblere, selvom Relækortet kun har to relæer og to optokoblere. Det skyldes den I²C-kreds på kortet, som ialt har 8 I/O forbindelser Adgang til I²C-bussen fra Webinterface For at kunne teste projektet løbende, skrives først noget software til at kommunikere på I²C-bussen, via et webinterface. Softwaren ( WebIO.c ) er en sammenkobling imellem to eksisterende drivere, som Logos allerede anvender til andre formål. iic.c til kommunikation på I²C-bussen, og http.c som kan kommunikere via et webinterface. For at lære at bruge web og I²C driverne, starter jeg med at skrive et program som kan læse temperaturen fra en I²C temperatur sensor på processorkortet. Til læsning af denne sensor, findes eksisterende en driver tempsens.c. Derved er problemet begrænset til at skulle udskrive returværdien fra funktionen TempSensorRead(), på en webside. Funktionen HTTP_AppBufChunkStr fra http.c, gør det muligt at tilføje tekst, eller HTML kode, til den HTTP_MessageT- streng (amsg) som skal returnerers til webbrowseren. Strengen startes med funktionen HTTP_MakeReplyHeader, og sendes til browseren ved linien return HTTP_HANDLER_WANTX. Når processorkortet startes op eller rebootes, initialiseres WebIO.c med funktionen WebIO_Init(), hvori alle globale variabler i WebIO.c initialiseres. Det er også her I²C-forbindelsen til PowerRelay-kortet initialiseres. WebIO.c repræsenterer ialt fem Websider, som processorkortet kan vise. Hver side tilknyttes en handlerfunktion, med funktionen HTTP_Installhandler(). Alle websider fra WebIO.c kan kaldes fra en webbrowser, med følgende URL: (dog kun fra Logos intranet). /WebIO viser en liste med hyperlinks til de andre sider. /Temp viser temperaturen på processorkortet, målt med I²Ctemperatursensorkredsen. /Relay representerer en side til test af PowerRelay-kortet (se screenshot herunder). /ADS7823 repræsenterer en side til test af ADC Modulet. /AutoTestResults repræsenterer en side til visning af testresultater fra en AutoTest. 28

29 Hvis siden /WebIO efterspørges fra en browser, kaldes funktionen WebIO_MainHandler(). Den genererer en meget simpel HTML side, kun bestående af tekst og hyperlinks, udfra den fremgangsmåde som tidligere er beskrevet. Hvis siden /Temp efterspørges, kaldes funktionen WebIO_DefaultHandler(), som genererer en simpel side med temperaturvisning. For at kunne læse fra temperatursensorern, kræver det driveren tempsens.c. TempSensorRead funktionen returnerer temperaturen som en integer, der repræsenterer temperaturen ganget med 100. For at få temperaturen udlæst som en float i C, er det altså nødvendigt at dividere værdien med 100. Floaten konverteres til en string med sprintf(), og kan derefter tilføjes til HTML-teksten. Figur 4-2: Screenshot af webinterfacet til test af PowerRelay-kortet Hvis /Relay siden efterspørges, kaldes funktionen WebIO_PowerRelayHandler(), som genererer siden der er vist herover. Siden er en HTML formular, hvilket vil sige at den evt. kan kalde sig selv med URL parametre, som f.eks. /Relay?R1=on. Derfor starter funktionen med at checke hvilke parametre der bliver overført, hvis der er nogen. Det gøres med funktionen HTTP_URLParamGetValue(). Alle URL parametre på /Relay genererers af Checkboxe. Dvs. sige at hver parameter enten kan være markeret eller tom (TRUE/FALSE). Kun hvis en checkbox er markeret medsender den sit URL-parameter, i form af F.eks. R1=on. 29

30 Siden er opbygget rimeligt overskueligt som en tabel med i alt 7 checkboxe. Der gør det muligt at styre de to relæer, og aflæse de to optokoblere, samt at kontrollere en AutoTest (se senere omtale). Checkboxene til optokoblerne kan dog ikke ændres manuelt fra websiden, da de kun er til læsning. Efter de ønskede checkboxe er markeret, klikkes på Apply/Update knappen for at sende URL parametrene. Relay checkboxene sender parametrene henholdsvis R1 og R2, Opto checkboxene sender O1 og O2. AutoTest checkboxene sender henholdsvis AutoTest, ShowFlash og ResetFlash. Alt efter om R1 og R2 medsendes som parametre, skiftes relæerne ON eller OFF. Udfra AutoTest parametret sættes den globale variabel EnableAutoTest, der er TRUE hvis systemet kører i AutoTest-mode (mere om det i næste afsnit). ShowFlash og ResetFlash udfører også hver sine funktioner, hvis de medsendes, men det er nærmere beskrevet i næste afsnit. Efter URL parametrene er aflæst, begynder genereringen af HTML-koden. Der er lidt dynamik i HTML koden, idet checkboxene automatisk markeres hvis det pågældende relæ eller optokobler, er tændt eller HIGH. Relæernes og optokoblerne status aflæses af henholdsvis WebIO_RelayGet() og WebIO_OptoGet(). Der er lokale funktioner, som kalder funktionerne i relækortets driver. AutoTest checkboxen markeres selvfølgelig også automatisk, hvis der kørers i AutoTest-mode Automatisk test af I²C-kabel m.m. For at sikre sig at systemet, kan fungere i forsøgsanlæggets hårde miljø. Skal der på et forholdsvis tidligt stadie i projektet laves en test. Den går ud på at stille et processorkort forbundet til et PowerRelay-board, via et langt I²C-kabel (se afsnit 5.1) op i forsøgsanlægget. Der skal processorkortet så automatisk stå og teste I²C-kablet og PowerRelay-boardet, ved kontinuerligt at afbryde/slutte et relæ, og tilbagelæse et input der er afhængigt af relæets status (se afsnit 5.3.1). Hvis resultatet er som forventet, er læsningen vellykket. Testen skal foregå over et antal Test Perioder, som hver kan have en varighed på f.eks. en time. I en Test Periode foretages et antal læsninger, med fast mellem rum (ReadbackDelay), på f.eks. et minut. Antallet af læsninger og forfejlede læsninger i hver Test Periode tælles og gemmes, som test resultater. Derved findes en fejlrate for hver Test Periode (tidsinterval), hvilket så senere kan sammenlignes med andre begivenheder (f.eks. temperatur ændringer) på samme tidspunkter, for at finde faktorer, der indvirker på stabiliteten af systemet, som der på sigt skal tages højde for. Til at udføre den automatiske test i anlægget, implementeres en funktion kaldet WebIO_AutoTestUpdate, og der tilføjes en checkbox på /Relay siden, til at starte/stoppe den automatiske test. Når den automatiske test er i gang vises også en tabel med de enkelte Test Perioder i den igangværende Test. For hver Test Periode vises dens no. (Test Period No.), antal læsninger (Tests) der blev udført i perioden, antal forfejlede læsninger (Failures), samt 30

31 en beregnet fejlprocent (Failure %). Antal læsninger er som regel det samme i alle Test Perioderne, men hvis det afviger, kan det tolkes som at der er sket en fejl på Processorkortet. Parametrene til den automatiske test, initialiseres i WebIO_Init() funktionen. Både ReadbackDelay og TestPeriodLenght måles i millisekunder. S_WAIT_FOR_HIGH ReadbackDelay Elapsed S_SWITCH_HIGH S_SWITCH_LOW ReadbackDelay Elapsed S_WAIT_FOR_LOW Figur 4-3: Tilstandsdiagram for AutoTest funktionaliteten til PowerRelay-kortet Hovedsløjfen ( Main.c ) sørger for at kalde WebIO_AutoTestUpdate, så ofte den kan komme til det. Funktionen er implementeret som en tilstandsmaskine, der sørger for at testprocessen foregår tidsstyret. Når AutoTest startes, er maskinen i tilstanden S_WAIT_FOR_LOW. Her ventes på at ReadbackDelay forsinkelsen er gået, før der skiftes til tilstanden S_SWITCH_HIGH. Den verificerer læsningen, idet den forventer et OFF (LO), og opdaterer statistikken. Til slut sættes Relæet til ON. Herefter skiftes betingelsesløst til tilstanden S_WAIT_FOR_HIGH, hvor der ventes på at AT_Data.ReadbackDelay forsinkelsen er gået, før der skiftes til tilstanden S_SWITCH_LOW. Den verificerer læsningen, idet den forventer et ON (HI), og opdaterer statistikken. Til slut sættes Relæet til OFF. Herefter skiftes tilbage til tilstanden S_WAIT_FOR_LOW osv. Hele tilstandsmaskinen kan kun kører hvis EnableAutoTest variablen er TRUE. Den styres af checkboksen Auto Test. Selvom systemet ikke er i AutoTest-mode, kaldes WebIO_AutoTestUpdate alligevel, men så kalder den en idle tilstand, hvor AutoTest derimod geninitialiseres. Test resultaterne kan så udlæses på HTML-siden, og gemmes som en tekstfil eller udskrives, fra browseren,. Tekstfilen, som kun består af den viste tekst på websiden (ikke HTML-koden), kan med få manuelle modifikationer omdannes til en tabulator-separeret datafil, som kan importeres direkte i Microsoft Excel. Det er også muligt at gemme siden som HTML-fil, markere testresultaterne, og kopiere dem over i en tekstfil. Derved vil dataene optræde, som en mellemrums (Space) separeret tekstfil, der også kan importeres direkte til Excel. 31

32 Der er dog et problem. Testresultaterne gemmes indtil videre kun i variabler, der ligger i Processorkortets RAM. Hvis strømmen til kortet forsvinder, eller hvis kortet går ned og rebooter sig selv (hvilket ikke er utænkeligt i forsøgsanlægget) går alle testresultaterne tabt. Det er selvfølgelig ikke brugbart, derfor skal testresultaterne gemmes i en eller anden form for persistent hukommelse. Processorkortet har hverken adgang til harddisk eller filsystemer, som en PC har. Derimod har det adgang til en FlashRAMhukommelse. Der eksisterer allerede en driver til at læse og skrive i Flash-hukommelsen, i form af FlashData.h. Dens funktioner FlashWriteData()og FlashReadData(), kan henholdsvis skrive og læse en struct til/fra Flashhukommelsen. Til det skal de bruge en start adresse, en såkaldt Base Adress, som angiver structens placering i Flashen. Da der ligger andre vigtige data i Flash-hukommelsen, er det vigtigt at to dataset ikke har samme Base Adress, eller overlapper hinanden. Derfor initialiseres alle Base Adresses i filen Hardware.h. Til at gemme AutoTest data i Flashen, oprettes en struct kaldet AutoTest, som indtil videre indeholder følgende komponenter: TestPeriodLenght, som angiver hvor mange millisekunder en test periode skal vare. ReadBackDelay, som angiver hvor mange millisekunder der skal gå fra relæet er skiftet, til optokobleren læses. AT_Total[2000], er en array som indeholder antallet af tests i hver testperiode. AT_Failures[2000], er en array som indeholder antallet af fejlbehæftede tests, i hver testperiode. TestPeriode nummeret er index til de to arrays. AutoTest structen gemmes i Flash en, hver gang tilstandsmaskinen afslutter tilstanden S_SWITCH_LOW. Den struct som er gemt i Flash en kan så vises eller slettes, henholdsvis med checkboxene Show Flash Results eller Reset Flash Results, fra /Relay siden. Flash en læses ind i AutoTest-structen med funktionen FlashDataRead(). Flashresultaterne slettes ved at fylde AutoTest-structen med 0 er, og skrive den til Flash en. Testresultaterne vises indtil videre i en tabel under den eksisterende tabel på /Relay siden. Den buffer som HTML koden lægges i inden den sendes afsted til browseren, har selvfølgelig en grænse for hvor meget der kan være i den. Det bevirker at der højest kan udskrives ca. 60 test resultater (Test Periods), hvilket ikke er smart da structen kan indeholde op til 2000 resultater. Derfor vil det være smart med en side der kan udlæse hele Flashen i mindre bidder ad gangen, hvor der så kan bladres blandt resultaterne. 4.4 Læsning fra ADC Modulet Til ADC Modulet skal der skrives software helt ned til I²C driveren iic.h. Idet den hovedsageligt består af specialkredsen ADS7823, som der først skal udvikles en driver til. Derudover skal der kodes et webinterface til ADCen, som anvender denne driver, til at læse den konverterede værdi, samt udføre automatiske tests af modulet og I²C-kablet. 32

33 4.4.1 Driver til ADC-kredsen Driveren til ADS7823-kredsen, udgør en I²C-forbindelse til denne kreds, samt funktioner til kommunikation med denne på forskellige niveauer. F.eks. læsning af en spænding på ADC ens indgang målt i Volt. Driveren døbes: ADS7823.c, og skal gerne kunne bruges i andre applikationer end ADC Modulet, derfor indeholder driveren også lidt mere funktionalitet end nødvendigt i dette projekt. Som alle de andre I²C-drivere (til f.eks. temperatursensorern: tempsens.c ), skal driveren initialiseres, og tildeles en unik I²C-adresse. Alle andre I²C-adresser defineres i filen hardware.h, så derfor skal ADC ens adresse også defineres her. Ifølge databladet for ADS7823 (se appendix), har kredsen følgende adresse: ADS7823_IIC_ADDR = 0x96 Denne adresse gælder når både A1 og A0 jumperne er sluttet, dvs. de begge er 1. Sidste bit som er RW-bitten, indgår ikke i selve adressen, men er altid sat til 0 under initialiseringen af driverne. Den vil løbende skifte imellem 0 og 1, alt efter om der læses eller skrives til pågældende kreds. Efter selve adressen er defineret, kan driveren initialiseres fra main.c filen, hvilket gøres med ADS7823_Init, for at få adgang til denne funktion, skal main.c selvfølgelig indkludere driverens headerfil ADS7823.h. ADS7823_ReadMeasurement() ADS7823_Calibrate() ADS7823_ReadVoltage() ADS7823_IsConnected() ADS7823_ReadSpike() ADS7823_SensorValid() ADS7823_ReadBinary() ADS7823_ReadPrevBinary() ADS7823_Init() ADS7823_SetMode() ADS7823_SetReference() Figur 4-4: Sammenspillet imellem funktionerne i ADS7823-driveren. En pil ind i en funktion angiver at funktionen kaldes af pilens afsender. En nærmere beskrivelse af de enkelte funktioner i driveren findes i følgende reference: void ADS7823_Init(unsigned char Addr) ADS7823_Init sørger for at oprette en I²C-forbindelse til kredsen, udfra adressen, der sendes med som argument (Addr). Efter det fastsættes en værdi for spændingsreferencen (Vref) på kredsen. Den er default fastsat til 3 V, men kan til enhver tid ændres med funktionen ADS7823_SetReference. Tillsut sørger ADS7823_Init for at starte konverteringen i kredsen. Dertil bruges funktionen ADS7823_SetMode. 33

34 void ADS7823_SetMode(unsigned char data) ADS7823_SetMode kan indstille kredsen i to forskellige modes: Wake-Up Mode eller Power-Down Mode. I Wake-Up Mode konverteres spændingen, og sendes ud i FIFO en, for derefter at blive læst fra kredsen. I Power-Down Mode slukkes den del af kredsen som indeholder selve Analog-Digital konverteren, hvilket gør at kredsen stort set ingen strøm bruger, men den kan selvfølgelig stadig modtage kommandoer via I²C-bussen. Faktisk har kredsen endnu en mode: High Speed Mode (HS), hvilket gør at kredsen understøtter I²C-kommunikationer med hastigheder op til 3,4 Mbits/s. Da processorkortet ikke p.t. understøtter så høje hastigheder, er denne mode ikke inplementeret i driveren. Desuden vil det tvivlsomt være nødvendigt (og muligt), med så høje hastigheder i denne applikation, da de værdier som måles ændre sig meget langsomt. Den aktuelle mode, angives af en Command Byte i kredsen, som der er direkte adgang til, ved blot at skrive til kredsen. Hvis de tre MSB i Command Byte er 0, er kredsen i Wake-Up Mode, alt andet får kredsen til at gå i Power- Down Mode. Derfor virker ADS7823_SetMode ved at der udfra om argumentet er ON eller OFF, vælges om Command Byten skal være 0x00 eller 0xFF. Command Byten skrives derefter til kredsen med funktionen iicfuncp->write, fra den generelle I²C-driver iic.c. void ADS7823_SetReference(float Vref) Driveren indeholder en global variabel kaldet Reference, som indeholder ADC kredsens referencespænding. Dvs. den maksimale spænding konverteren kan konvertere, svarende til den digitale heltalsværdi For at få adgang til at ændre Reference, kaldes denne funktion, med den nye referencespænding som argument (Vref). void ADS7823_ReadBinary(int *Value) Læser den rå konverterede værdi fra kredsen, og returnerer denne som en pointer til en integer. Funktionen starter med at sikre sig at kredsen er i Wake- Up Mode, ved at kalde ADS7823_SetMode(ON). Herefter læses de 2 bytes (hvoraf kun de 12 bits bruges) fra kredsen, med funktionen iicfuncp- >write. De to bytes sammensættes til en integer, som så kan være en værdi fra 0 til De fire MSB i integeren er alle 0. Inden værdien returnerers indsættes værdien i arrayet LatestBinValues, som indeholder de seneste 10 læsninger denne funktion har udført. BOOL ADS7823_ReadVoltage(float *Voltage) For at kunne aflæse en passende spænding med denne funktion, kræver det selvfølgelig af Reference variablen (referencespændingen) er sat til noget fornuftigt. Funktionen anvender ADS7823_ReadBinary til først at læse en binær værdi på kredsen, denne omregnes så til en spænding, ved at multiplicere den med størrelsen af en LSB dvs. (Reference / 4095). Inden Voltage returnerers, indsættes værdien i arrayen LatestVolValues, som indeholder de seneste 10 spændinger funktionen har målt, til gavn for nogle af de andre funktioner, i driveren. Til slut kaldes funktionen 34

35 ADS7823_SensorValid() for at tjekke om den tilsluttede sensor virker, kun hvis det er tilfældet returneres TRUE. BOOL ADS7823_SensorValid(float Voltage) Udfra den spænding der medsendes som parameter (Voltage), kan denne funktion detektere om en tilsluttet 4-20 ma sensor virker. Funktionen bygger på at en sådan sensor altid mindst skal sende 4 ma, rundt i strømsløjfen, hvis ikke denne strøm findes må der være en fejl med sensorern, eller kablet til sensorern. Det er altså et krav at der altid er min. 20 %, af den maksimale strøm (20 ma) i strømsløjfen. Eftersom strømmen konverteres til en spænding med en simpel modstand, gælder samme princip for spændingen. Det kræves at inputspændingen (Voltage) er min. 20 % af referencespændingen (Reference), for at sensorern kan antages at virke. F.eks. kræves min. 0,6 V ved en referencespænding på 3 V. Kun hvis sensorern antages at virke returnerer funktionen TRUE. BOOL ADS7823_IsConnected(void) Denne function returnerer kun TRUE hvis ADC-kredsen er forbundet til I²Cbussen. Hvis funktionen ADS7823_ReadBinary() ikke kan få fat i kredsen under læsningen, returnerer den en værdi på 0xFFFF. Hvilket er meget mere end de 0x0FFF, som 12-bit konverteren max. kan vise. Det er en klar fejl, som denne funktion kan detektere, og derfra konkludere om kredsen er tilsluttet. void ADS7823_ReadPrevBinary(int *Value) Som tidligere nævnt gemmes værdien af de seneste 10 læsninger, fra kredsen I et array kaldet LatestBinValues. Der findes også et globalt index til dette array, kaldet FIFOIndexBin, som angiver det sted hvor en ny læsning skal indsættes. Derfor kan den forrige læsning, som denne funktion skal returnererr, nemt findes, ved blot at springe til indexet umiddelbart før det nuværende. Funktionen bruges til test af ADC Modulet. BOOL ADS7823_ReadSpike(int *NewValue, int *PrevValue) Denne function returnerer TRUE, hvis der er et stort spring til den læste værdi (NewValue), i forhold til den forrige værdi (PrevValue). En såkaldt spike. Funktionen henter først den tidligere læste værdi, med funktionen ADS7823_ReadPrevBinary(), og gemmer den i variablen PrevVal. Herefter foretages en ny læsning fra kredsen, med funktionen ADS7823_ReadBinary(), som gemmes i variablen NewVal. Hvis forskellen på NewVal og PrevVal så er tilpas stor, antager funktionen at der er tale om en spike, og returnerer TRUE. Hvor meget forskel der skal være på de to værdier, for at dette kan antages, bestemmes af den globale variabel SpikeDev, som initialiseres i ADS7823_Init(). Som det ses returnerer funktionen også PrevValue og NewValue. void ADS7823_Calibrate(float p1x, float p1y, float p2x, float p2y) Denne function bruges til at kalibrere driveren, således at der kan udlæses andre måleenheder end Volt, blot de har en linær relation til spændingen. Kalibrering foregår udfra to fixpunkter (p1 og o2) på en ret linie, som 35

36 repræsenterer forholdet mellem spændingen (x) og den nye enhed (y). Disse fixpunkter medsendes som argumenter, i form af to koordinatsæt. Udfra fixpunkterne findes en ligning til den rette linie, hvilket vil sige at variablerne a og b beregnes. Hvor a betegner liniens hældning, og b betegner skæringen med y-aksen. Faktorerne beregnes med to relativt simple formler, eftersom liniens ligning udtrykkes som: y=a*x+b. Formlerne eksekveres dog kun hvis p1x og p2x ikke er ens, da det ellers vil fremtvinge en division med 0. BOOL ADS7823_ReadMeasurement(float *Voltage, float *Measurement) Denne funktion returnerer både gennemsnitsspænding (Voltage) for de seneste ti konverteringer, samt den tilsvarende værdi i en anden måleenhed (Measurement), udfra den seneste kalibrering. Desuden returnerer funktionen TRUE, hvis den tilsluttede sensor virker. Først udføres en ny spændingskonvertering, med funktionen ADS7823_ReadVoltage(). Den returnerer en angivelse af om sensorern virker eller ej, som gemmes midlertidigt i variablen SensorStatus. Herefter beregnes gennemsnitsspændingen for de senste 10 spændinger, ved at summere hele LatestVolValues arrayet, og dividere den med 10. Measurement værdien beregnes nu udfra liniens ligning, med de globale variable a og b. Til slut returnerers variablen SensorStatus Læsning via Webinterface For at kunne teste driveren til ADS7823, oprettes endnu en funktion i WebIO.c, nemlig WebIO_ADS7823Handler, opkaldt efter type nummeret på den ADC kreds der sidder i ADC Modulet. Siden /ADS7823 minder på mange måder om den tidligere beskrevne /Relay side, de har også samme slags funktionalitet. Blot med den forskel at /ADS7823 er et webinterface til ADC Modulet. Brugergrænsefladen til AutoTest-funktionaliteten er identisk med den på /Relay -diden. Selve ADC Modulet kan ikke styres fra webinterfacet (det er driverens opgave), den kan kun aflæses. De eneste URL parametre der kan medsendes til siden er derfor dem der bruges til AutoTest (beskrives senere). 36

37 Figur 4-5: Screenshot af webinterfacet til test af ADC Modulet Værdierne fra ADC Modulet skrives dynamisk i HTML-koden hver gang siden kaldes (reloades). Binary Value er den aktuelle heltalsværdi der står i A/Dkredsen. Da ADS7823 er en 12-bit kreds, kan denne værdi være imellem 0 og For at kunne kommunikere med kredsen, skal den nye driver ADS7823.c indkluderes i WebIO.c. Heltalsværdien læses med funktionen ADS7823_ReadBinary(), som konverteres til en streng, før den kan indsættes i HTML-koden. Voltage Value er den momentane spænding som sendes ind på A/D kredsen. Dvs. den er ikke midlet. Værdien læses som en float, med funktionen ADS7823_ReadVoltage(). Mean Voltage er den midlede spænding (nærmere beskrevet i tidligere afsnit). Værdien læses med funktionen ADS7823_ReadMeasurement(), der både returnerer middelspændingen og værdien konverteret til en anden måleenhed f.eks. liter Automatisk test via Webinterface AutoTest-funktionaliteten til ADC Modulet er en udbygning af den gamle til PowerRelay-modulet. Der er blevet tilføjet en række ekstra variable til AutoTest-structen: TargetVoltage indeholder værdi af den konstante inputspænding til ADC-kredsen, målt med et digitalt multimeter. Variablen bruges til at beregne afvigelse (Aberration), i konverteringerne. Der er også kommet to nye arrays: AT_ReadValue indeholder heltal som læses fra konverteren, med en given test periode som index. AT_Aberation indeholder den afvigelse den konverterede værdi har fra TargetVoltage, også her bruges test periode nummeret som index. 37

38 Der er også kommet nogle nye globale variabler til: MeanResults er TRUE hvis der udføres flere konverteringer i en TestPeriod, og gennemsnittet af disse ønskes gemt som et resultat. ResultsPrPage bruges af WebIO_AutoTestResultsHandler() funktionen, til at bestemme hvor mange test resultater der skal vises på en webside. AutoSaveInterval angiver hvor tit AutoTest-structen skal gemmes i Flash en. SpikesOnly er TRUE, hvis det kun er de særlige spændingshop ( spikes ), som skal registreres (beskrives mere senere). Alle disse nye variabler initialiseres i WebIO_Init() funktionen. Som tidligere beskrevet minder WebIO_ADS7823Handler() meget om WebIO_PowerRelayHandler(), der er blot lidt mere AutoTest-funktionalitet i den først nævnte. TargetVoltage vises også på siden, så det kan kontrolleres af spændingsafvigelsen (Aberration) beregnes på rette grundlag, inden en AutoTest startes. Når testresultaterne skal vises på siden, vises for hver TestPeriode, udover Test Period No. og Tests In Period, også spændingsafvigelsen Aberration, i procent eller Volt. Denne ekstra kolonne har bevirket at der nu kun kan vises 42 resultater på siden. Figur 4-6: Visning af testresultater i en langstrøm, med AutoTestResults-siden. Problemet løses med en separat webside, kaldet /AutoTestResults, som udelukkende har til opgave at vise testresultaterne fra Autotest-structen. Siden genererers af funktionen AutoTestResultsHandler(). Siden kan modtage to forskellige URL parametre: Prev og Next. Der angiver om der skal blades henholdsvis frem eller tilbage i testresultaterne. Hvis der ikke 38

39 medsendes et parameter, startes med det første resultat. De resultater som skal vises bestemmes udfra StartResultNo og ResultsPrPage. Hvis der blades frem ( Next ), inkrementeres StartResultNo med værdien af ResultsPrPage, og dekrementeres hvis der blades tilbage. Derved kan man bevæge en slags vindue henover alle testresultaterne. Inden resultaterne udskrives til websiden, opdateres structen med resultaterne fra Flash en. Således at alle gemte resultater kommer med, selvom processorkortet f.eks. lige har rebootet. På siden er det kun resultaterne i AT_ReadValue, der udskrives, da det p.t. er de eneste resultater som bruges i testene. Bladring frem eller tilbage, foregår ved at klikke på to forskellige hyperlinks: << eller >>. URL parametrene Prev og Next, bliver altså ikke sendt på traditionel vis, med formular og checkboxe, men blot ved at tilføje ekstra tekst i de to hyperlinks. Hyperlinket /AutoTestResults?Prev=on, sørger således for at sende URL parametret, som hvis det kom fra en checkbox. Der er også blevet tilføjet en hel del til WebIO_AutoTestUpdate() funktionen, for at muliggøre AutoTest af ADC Modulet. For at kunne kende forskel på om det er PowerRelay-kortet eller ADC Modulet der skal testes, har de dog fået hver sin tilstandsmaskine. Hvis AutoTesten drejer sig om ADC Modulet, er EnableADCAutoTest = TRUE. Den nye tilstandsmaskine er dog en del mere simpel end den gamle, idet den kun består af to tilstande: S_WAIT og S_READ_ADC. Der henholdsvis, venter på at en bestemt tid (ReadbackDelay) er gået, og udfører en læsning/konvertering fra ADC Modulet. Læsningen fra ADC Modulet kan efterhånden foregå på mange forskellige måder, eftersom der er blevet udført en lang række forskellige test, og den gamle funktionalitet er bibeholdt. Hvilken form for test/læsning der skal udføres bestemmes af variablerne MeanResults, SpikesOnly og AfterSpikeRecordsLeft. Hvis MeanResults er TRUE, læses den aktuelle spænding først med funktionen ADS7823_ReadVoltage(). Herefter beregnes dens afvigelse i forhold til TargetVoltage (VoltDif). Midlingen foregår nu ved at VoltDif konstant summeres op med den forrige VoltDif, og divideres med 2, indtil den igangværende TestPeriod er overstået. Testperioden slutter når tiden TestPeriodLenght er gået, herefter startes på en ny TestPeriod. Hvis MeanResults er FALSE, forstås det som at alle læsninger skal gemmes hver for sig, en læsning pr. TestPeriod. Der foretages med andre ord ingen midling. Under normale omstændigheder vil den læste værdi fra ADC Modulet blot blive gemt direkte i ReadValue arrayet. Men hvis der kun skal registreres spændingshop spikes, sættes SpikesOnly høj. Funktionen som kan bedømme om en spænding er en spike er ADS7823_ReadSpike(), som returnerer TRUE hvis der er tale om en spike. Samtidig returnerer den også den forrige læsning og den ny læsning (NewValue og PrevValue). Hvis der er tale om en spikes gemmes både PrevValue og NewValue, i ReadValuearrayet. Ydermere registrerer programmet også de 5 efterfølgende læsninger, for senere at kunne analysere om der er en sammenhæng imellem disse efterskælv. Disse ekstralæsninger gennemføres så længe 39

40 AfterSpikeRecordsLeft er større end 0. Den initialiseres til 5, hver gang der detekteres en spike, og dekrementeres hver gang der laves en after spike - læsning. I slutningen af tilstanden S_READ_ADC gemmes hele AutoTest-structen i Flash en, men ikke ved hvert gennemløb, da der tit er mere end 1000 af disse pr. sekund. Desuden varer en Flash skrivning typisk 1 sekund, hvilket ville gøre at AutoTesten går helt i stå. I stedet foretages Flash-skrivningen kun hver gang AutoSaveInterval er gået, eller når der er gennemløbet et bestemt antal TestPeriods. 4.5 Styring af DAC Modulet Eftersom DAC Modulet blev nedprioriteret, og derfor ikke nåede at blive konstrueret, er softwaren til det heller ikke implementeret færdigt. Driveren til kredsen var netop påbegyndt, før nedprioriteringen af modulet. Den halvfærdige driver findes i form af filen AD5311.c på CD en. 4.6 Styring af Kælderpumpen For at få PowerRelay-kortet og ADC Modulet til at virke sammen, i en højere enhed, konstrueres den del af styringen, som omhandler fødning af anlægget, dvs. kælderpumpen. Det er en applikation som netop, kan konstrueres med et PowerRelay-kort til at trække Kælderpumpens contactor, og et ADC Modul til at læse input fra Equalizerens niveausensor. Styringen tager udgangspunkt i den nuværende PC, med hensyn til brugergrænsefladen. Dog med den forskel at det nu foregår via nogle websider, fremfor et Windows program. Selvom denne applikation kun omfatter styring af en sensor og en pumpe, skal den konstrueres således at den relativt nemt kan udvides til at omfatte hele B-Ware anlægget Overvågning via webinterface En vigtig funktionalitet ved styringen er at den skal give overblik, over alt tilsluttet udstyr (forstås som pumper, sensorer osv.). Denne overvågningsside, skal virke som en slags hovedside, for den webbaserede styring. Al webadgang til styringen foregår i filen Bware.c. På PC en foregår det i øjeblikket med en GUI (Graphical User Interface), som bl.a. består af et diagram over anlægget. Det giver selvfølgelig et godt overblik, men det ville i første omgang være en stor opgave at få al denne grafik ud på en website. Til denne webside, vil der derfor i stedet blive brugt en simpel tabel, til at holde styr på de enkelte sensorer, pumper osv. (Devices), som findes i anlægget. Bortset fra at tabellen ikke viser hvor i anlægget udstyret sidder, er den lige så god som en Windows GUI, til at give overblik over hver enkelt sensors måleværdi osv. Der lægges meget vægt på at webinterfacet er brugervenligt, og stadig fleksibelt nok til at kunne udvides med mere udstyr. En vigtig ting ved en brugervenlig brugergrænseflade, er at den skal have så ensartet og strømlinet et design som muligt, uden for mange små detaljer og 40

41 afvigelser. For at noget kan være ensartet kræver det at der skal vises mange informationer, som minder om hinanden. Det passer med alt det forskellige udstyr der skal kunne vises informationer om, i denne applikation. Udstyret kan godt være meget forskelligt, f.eks. er der stor forskel på en sensor og en pumpe. Derfor må der findes nogle fællesnævnere for alt udstyret, hvis det skal sættes ind i samme tabel. De mest indlysende fælles træk for udstyret, er selvfølgelig et navn eller en betegnelse (Device). Alt udstyr har også en variabel information tilknyttet, f.eks. har en sensor en måleværdi, og en motor f.eks. en omdrejningshastighed. Det skal der også være en kolonne til (Value). Udstyret kan deles op i nogle hoved kategorier, alt efter om der er tale om input eller output, samt hvilken type I/O der er tale om. I dette projekt hvor der indgår en tænd/sluk pumpe, og en analog sensor. Kan pumpen tilhøre kategorien Digital Output (DO), fordi den kun kan tændes eller slukkes (TRUE/FALSE). Sensorern kan tilhøre kategorien Analog Input (AI), fordi den måler et trinløst tryk i Equalizerens bund. Der findes også andre kategorier, som sagtens kan tilføjes til tabellen senere, blot der er en kolonne (Type), som informerer om hvilken type udstyr der er tale om. Udover at kunne overvåge/styre et Device, skal det også være muligt evt. at udføre andre funktioner med det. Til det findes kolonnen Options, med knapper (hyperlinks), til yderligere funktionalitet. Som standard har alt udstyr en Setup knap, det er dog afhængigt udstyrets type hvilke muligheder dette hyperlink giver (beskrives senere). Figur 4-7: Hovedsiden til overvågning og kontrol af Equalizerens niveau sensor og kælderpumpen. Alt udstyr som er tilsluttet skal med tiden vises i tabellen. Den grønne skrift til venstre angiver at udstyret er tilsluttet. 41

42 En anden vigtig funktionalitet ved en brugergrænseflade til procesovervågning, er at det skal være nemt at få øje på evt. fejl ved noget af udstyret. Den mest kritiske fejl ved denne applikation, er hvis kommunikationen med noget af udstyret forsvinder. Men det kunne lige så godt være hvis en kritisk sample værdi blev overskredet. Problemet løses ved at farve de kritiske informationer på brugerfladen. Hvis noget data er acceptabelt, er det farvet grønt. Hvis det ikke er acceptabelt, eller forfejlet, er det farvet rødt. Et hurtigt blik henover tabellen, vil så hurtig kunne registrere en rød farve. Til at angive om kommunikationen til udstyret er intakt, bruges type betegnelserne (AI og DO). De er grønne hvis udstyret er forbundet til I²Cbussen, og røde hvis ikke. En sidste funktionalitet på denne side, er kontrol af om systemet skal styres manuelt eller automatisk. Hvilket styres med en checkbox. Da denne information vedrøre alt udstyr, placeres checkboxen udenfor tabellen. Siden skal opdatere sig selv jævnligt, således at man kan følge med i udviklingen af de forskellige måleværdier, uden at skulle opdatere siden manuelt. Som tidligere beskrevet er det filen BWare.c, som står bag alle websiderne vedr. B-Ware styringen. Filen virker stort set på samme måde som WebIO.c, med hensyn til visning af websider. Hver webside har tilknyttet en handlerfunktion, som står for genereringen af den pågældende side. Overvågningssiden, som dette afsnit handler om, hedder /Control, og generes af funktionen Bware_ControlHandler(). /Control siden kan medtage to URL parametre Auto, og BRBP. Auto medsendes hvis checkboxen Auto Control er markeret, og det medfører at den globale variabel AutoControl sættes ON (TRUE). Hvis BRBP medsendes, er det fordi checkboxen til manuel tænding af kælder pumpen, er markeret. I det tilfælde sættes variablen Bware.Pump.Status = ON, for at indikere at pumpen skal tændes ved næste kald fra opdaterings timeren TimerUpdate (Nærmere beskrevet senere). Som tidligere nævnt skal websiden opdateres automatisk regelmæssigt, det gøres nemmest ved at afsende et HTML-tag, som beder browseren om at reloade siden, f.eks. hver andet sekund. Tagget hedder <META HTTP- EQUIV= Refresh CONTENT= 2 URL= /Control >, og indsættes i begyndelsen af HTML-koden, umiddelbart efter <HTML>. Nu skrives data vedr. sensoren ind i tabellen. Første kolonne som indeholder type betegnelsen for sensorern (AI), skrives kun med grøn farve, hvis variablen Bware.Sensor.Connected er TRUE, ellers skrives med rødt. Variablen opdateres også af TimerUpdate, i Bware_Update() funktionen. Måleværdien fra sensorern, som skrives i Value kolonnen, indeholder både værdien i liter og i Volt. Værdierne læses fra henholdsvis Bware.Sensor.ActualMeasure og Bware.Sensor.ActualVoltage. Hvis sensorern ikke virker som den skal, eller ADC Modulet ikke er tilsluttet, skrives i stedet henholdsvis Sensor Error eller Disconnected, i Value feltet. Hvis sensorern ikke virker er variablen Bware.Sensor.SensorOK = FALSE. I sensorens Options-kolonne, findes hyperlinks til en webside hvorfra sensoren kan kalibreres, og en hvor de seneste måleværdier vises som en 42

43 graf. Henholdsvis links til websider /AISetup og /LogGraph, som begge beskrives senere. Data vedr. pumpen skrives i samme rækkefølge. Her er det dog variablen Bware.Pump.Connected, som angiver om PowerRelay-kortet, der styrer pumpen, er tilsluttet Synkroniseret opdatering og styring Kernen i denne styringssoftware, er BWare_Update() funktionen, som sørger for den rutinemæssige læsning af sensorværdier, styring af pumper, logging af data og evt. fuldautomatisk kontrol af anlægget. Funktionen kaldes så ofte som muligt ude fra hovedsløjfen (Main Loop) i filen main.c. Bware_Update()bruger tre timere til at holde dens aktiviteter synkroniseret: TimerUpdate står for læsning af inputs og opdatering af outputs. TimerLog styrer logging af måleresultater. TimerAutoSave styrer den automatiske persistente lagring af alle Bware data (Bware structen) i Flash en. Først i funktionen foretages opdateringer af I/O, hvis TimerUpdate s interval (T_UPDATE) er gået. Alle opdateringer foregår sammen med Bware structen. Inputs fra sensorer skrives ind i structen, og outputs til f.eks. Kælderpumpen læses fra structen, og sendes ud. Derved findes de nyeste informationer, kun et sted; i Bware structen. Hver information som skrives eller læses fra structen, bruger sin egen specifikke funktion. Af dem er der to som ikke er beskrevet før, de bruges begge til kælder pumpen, og findes begge i Bware.c filen. Grunden til at de p.t. findes i denne fil er at der endnu ikke var grund til at oprette en driver til styring af en pumpe, via PowerRelay-kortet. De vil sikkert blive flyttet til en selvstændig fil engang i fremtiden. Funktionerne er nærmere beskrevet herunder: static void BWare_SetPumpStatus(int RelayNo, BOOL On) Funktionen bruges til at tænde og slukke for en pumpe (f.eks kælderpumpen), som er tilsluttet. Da PowerRelay-kortet har to relæer, bruges første argument (RelayNo) til at angive hvilke af disse det drejer sig om (Kælderpumpen er tilsluttet nr. 1). Sidste argument (On) er TRUE hvis pumpen skal tændes. BOOL BWare_PumpNotValid() Returnerer TRUE hvis PowerRelay-kortet (som Kælderpumpen er tilsluttet), ikke er tilsluttet I²C-bussen. Funktionen benytter sig af at Optokoblerne læses som ON, hvis der ikke er nogen kontakt med relækortet. Der er dog enkelte tilfælde hvor de alligevel læses som OFF, men sjældent flere læsninger i træk. Derfor indeholder funktionen en simpel tilstandsmaskine, hvor det kræver mere end 10 OFF-læsninger i træk, før det tolkes som at optokobleren virkelig er OFF, og relækortet derved antages at være tilsluttet. Hver gang TimerUpdate udfører en opdatering af Inputs/outputs, tændes den røde lysdiode på processorkortet (LED 4), og slukkes igen når det er overstået. Dens blink virker derfor som BWare opdateringens puls, hvis interval som sagt er defineret som T_UPDATE i BWare.h. headerfilen. 43

44 Logging af data sker kun når TimerLog s interval (T_LOG) er gået. Alle funktioner til datalogging, findes i filen DeviceLog.c, som beskrives senere. I dette projekt er det indtil videre kun niveau sensorerns måleværdi der logges, men det kan sagtens udvides til også at omfatte flere sensorer. Logging af sensorerns måleværdi, sker med funktionen DeviceLog_LogSensor().Timere kan finde på at afbryde eksekveringen af andet programkode, på et i praksis uforudsigeligt sted. Som det senere beskrives er Log arrayet et farligt sted for TimerLog at afbryde, især hvis Loggen er ved at blive udskrevet som en graf. Derfor er al adgang til Logarrayerne, beskyttet med en simpel semafor, i form af variablen LogEnable. TimerLog aktivere kun logningen hvis denne variabel er TRUE. TimerAutoSave kalder funktionen FlashDataWrite(), når den skal lagre BWare-structen i Flash en. Timerens interval er defineret som T_AUTOSAVE. Den automatiske kontrol af systemet, udføres hver gang BWare_Update() kaldes, dog kun hvis AutoControl er TRUE. Denne styring foregår udelukkende virtuelt ved at ændre på værdierne, i BWare-structen. Den rigtige fysike styring foretages stadig af TimerUpdate. I dette projekt består den automatiske styring blot i at tænde kælderpumpen, hvis niveauet i Equalizeren er under dens nedre grænse, og slukke den hvis niveauet kommer over dens øvre grænse. Disse grænseværdier kan indstilles via en webside (beskrives senere), og gemmes i henholdsvis BWare.Pump.LowerLimit og BWare.Pump.UpperLimit Kalibrering af sensor Signalet fra Equalizerens Niveau sensor, som faktisk er en tryksensor, måles i Volts, på ADC Modulet. Men da det er meningen at sensorern skal måle Equalizerens volumen eller niveau i liter, er det nødvendigt at kunne definere en sammenhæng imellem disse to måleenheder, en såkaldt kalibrering. Det gøres via websiden /AISetup, hvor der indtastes to fixpunkter, der ligger på den lineære relation imellem de to måleenheder. Hvert fixpunkt repræsenterer således en x-værdi ( Voltage [V] ) og y-værdi ( Volume [litres] ), som alle er overskueligt opstillet i en tabel. Når de ønskede værdier er skrevet i tekstfelterne, trykkes på Apply -knappen for at gemme dem og kalibrere sensorern. Websiden er vist herunder: 44

45 Figur 4-8: Side til kalibrering af niveausensoren, udfra to fixpunkter på en linie. Her svarer 3 V til 1000 liter vand i Equalizeren. Websiden genererers af funktionen BWare_AISetupHandler(), som kan modtage fire URL-parametre, 2 for hvert fixpunkt, kaldet p1x, p1y, p2x og p2y. Hvis disse parametre medsendes, gemmes i de BWare-structen som: BWare.Sensor.p1.x, BWare.Sensor.p1.y osv. og den lagres med det samme i Flash en, for at sikre det altid er den nyeste kalibrering, som anvendes. Hvis ingen parametre medsendes, hvilket er tilfældet når siden kaldes fra /Control, læses fixpunkterne blot fra BWare-structen, og indsættes i de passende tekstfelter. Herefter foretages selve kalibreringen med funktionen ADS7823_Calibrate(), som tidligere er beskrevet Opsætning af grænseværdier Den automatiske styring af pumpen, foregår som tidligere beskrevet, udfra to grænseværdier UpperLimit og LowerLimit. Disse to værdier sættes op på websiden /DOSetup, som er vist herunder. Der er adgang til denne side ved at klikke på Setup linket, for kælderpumpen, på /Control siden. 45

46 Figur 4-9: Side til opsætning af Equalizerens grænseværdier, som bruges til styring af kælderpumpen. Når niveauet kommer under "Lower Limit" tændes pumpen. Når niveauet kommer over "Upper Limit" slukkes pumpen. Siden kan selvfølgelig modtage to URL-parametre, nemlig de to føromtalte grænseværdier, her kaldet henholdsvis LL og UL. Lagring af disse grænser foregår i henholdsvis BWare.Pump.LowerLimit og BWare.Pump.UpperLimit Logning af tidligere måleresultater Equalizeren er som tidligere nævnt en slags buffer tank, som skal sørge for at der kommer et nogenlunde stabilt flow igennem Bioreaktoren. Eftersom vaskeriet levererer mest spildevand i dagtimerne, vil der være højvande i Equalizeren i denne periode, imens der vil være lavvande i nattetimerne. En analyse af denne døgnrytme kan bruges ved fremtidig dimensionering af anlægget. Hvis der skal kunne dannes et overblik over denne døgnrytme, skal måleresultater fra op til et døgn tilbage i tiden, logges og evt. kunne vises som en graf. Den følgende applikaton fokuserer på væskeniveauet i Equalizeren, men kunne sagtens tænkes at log-funktionaliteten engang i fremtiden skulle findes til alle sensorer. Til log-funktionaliteten af måleresultater, implementeres et selvstændigt softwaremodul (driver) kaldet DeviceLog.c. Funktionerne i denne fil er beskrevet i nedenstående reference: void DeviceLog_LogSensor(float Measurement) Funktionen sørger for at indsætte et måleresultat (Measurement), fra en sensor, i log-aarrayet. Indtil videre kan funktionen kun logge målinger fra Equalizerens niveau sensor. Måleresultatet indsættes i arrayet 46

47 Bware.Sensor.MeasureLog, på det globale index LogInsertIndex. Dette index peger altid på den plads i arrayet, hvor næste indsætning af et måleresultat skal foregå, derfor inkrementeres det umiddelbart efter en indsætning. Logarrayet skal som sagt kunne dække det sidste døgn, og er dimensioneret således at det har et kvarters opløsning, hvilket gør at det skal have plads til 24*4=96 måleresultater. Når LogInsertIndex kommer til 97, skal det derfor starte forfra ved 1, hvorved det ældste måleresultat samtidig slettes. BOOL DeviceLog_GraphSetDot(int x, int YLineValue, int YLineSpacing) Funktionen bruges som hjælp til at tegne en log-graf, på en webside. Den returnerer TRUE hvis der skal være en prik af grafen på koordinatet specificeret ved (x, YLineValue). YLineValue er en værdi som den loggede måleværdi afrundes til, hvis den ligger inden for en vis afstand (angivet ved YlineSpacing). Grafen skal tegnes således at det nyeste måleresultat altid er længst til højre. Derfor beregnes et midlertidligt index (LogIndex), som tager højde for det. Hvis funktionen skal returnerer TRUE, skal logværdien som ligger ved LogIndex, kunne afrundes til YLineValue. Til at vurdere det haves argumentet YLineSpacing, som angiver hvor mange enheder (liter), der er imellem hver række (y-koordinat) på grafen. int DeviceLog_Graph(int x) Funktionen bruges som hjælp til at tegne en log-graf på displayet. Hvilket kan foregå på en meget mere enkel måde, end ved udkrivning til en webside (som ovenstående funktion gør). Returnerer ganske enkelt måleresultatet (y), ud for en given x-værdi, stadig således at det ældste står længst til venstre. Da niveausensorern kan måle fra liter, divideres måleresultatet med 10, for at grafen skal kunne være i dens tildelte areal på displayet. Ved at klikke på linket View Log Graph på /Control siden, fremkommer siden /LogGraph, som genererers af funktionen BWare_LogGraphHandler(). Den viser de seneste logninger af vandstanden i Equalizeren, som en graf, der opdateres hver gang en ny logning kommer til. Således at det ældste måleresultat er længst til venstre og det nyeste længst til højre. Grafen tegnes med primitive ASCII-karrakterer, hvilket umiddelbart ikke giver en særlig høj opløsning, men alligevel et godt overblik over forløbet. Y-aksen repræsenterer vandstanden i liter (0-1000). X- aksen repræsenterer de seneste 96 måleresultater. Hvis der laves en logning pr. kvarter, svarer det ialt til et døgn. 47

48 Figur 4-10: LogGraph-siden viser en graf med de seneste 96 logninger. Websiden opdaterer sig selv lige så tit som der logges en måling, dvs. det bestemmes af konstanten T_LOG, som er defineret i BWare.h. Den automatiske opdatering udføres med samme type HTML-tag som /Control - siden anvender. ASCII-grafen udskrives med skrivemaskine skrift (Courier), for at tegnene skal få ens dimensioner. Graf arealet defineres til at have 25 rækker, med variablen LineNo, hvilket passer med at den kan være på en HTML-side uden scrolbar, på en 17 skærm med en opløsning på 1024*768. Variablen YLineSpacing angiver hvor meget en ASCII-række svarer til i måleenheder (liter). Da sensorern kan måle fra liter, og der er 25 linier, er den sat til 1000/25=40 liter. Springet fra en række til den næste er altså på 40 liter, så det er ikke den bedste opløsning der er tale om. Efter initialiseringen kan plotningen af grafen begynde, men da det indebærer mange kontinuerte læsninger fra loggen, er det vigtigt at TimerLog ikke samtidig skriver til den, da det ellers kan få processorkortet til at gå i stå. Grafen skal udskrives som en tekstside, hvilket vil sige der skal startes i øverste venstre hjørne. Det er normalt ikke på den måde en graf tegnes, derfor skal der holdes styr på hvilke logninger der er blevet plottet, og hvilke der endnu ikke er blevet plottet, hvilket håndteres af arrayet LogPlotted. Det skal selvfølgelig kun gælde midlertidligt, under een opdatering af siden. Derfor initialiseres det før graf tegningen, så det angiver at ingen logninger er blevet plottet endnu. Herefter gennemløbes de 25 rækker, oppe fra og ned. For hver række beregnes variablen LineValue, som er den værdi der skal stå ud for rækken på y-aksen. Eftersom det ikke er muligt at indsætte et enkelt mellemrum på 48

49 websiden, med HTTP_AppBufChunkStr()-funktionen, må der indsættes et passende antal 0 er foran værdien, afhængigt af hvor mange cifre den består af. Nu gennemløbes alle 96 kolonner i grafen, svarende til en pr. logning. Hvis den før omtalte funktion DeviceLog_GraphSetDot(), angiver at der skal sættes en prik på det pågældende koordinat, og hvis LogPlotted-arrayen angiver at pågældende logning (x-koordinat) ikke er plottet før, sættes et * på pågældende position. Hvis ikke sættes et.. Efter alle 96 kolonner er gennemløbet, skiftes videre til næste række osv Overvågning via displayet Ulemben ved at skulle kontrollerer og overvåge anlægget via websider, er at det kræver en netforbindelse. B-Ware anlægget skal engang i fremtiden kunne stå og passe sig selv. Derfor er det ikke sikkert at kunden vil ofre en internet forbindelse til anlægget, blot for at kunne overvåge dets status. Det er med andre ord mest under reparation af anlægget der er brug for kommunikation med det. Problemet kan løses ved at tilslutte en bærbar PC til processorkortets Ethernet-port, for at får adgang til webinterfacet, men til de mere simple opgave vil det være nemmere blot at bruge processorkortets Touch-Screen display. Dette display er ekstraudstyr, men Processorkortet har et specielt stik kun til det. Til displayet har Logos selvfølgelig også en række eksisterende drivere til bl.a. skrivning med fonte og tegning af simpel grafik. Softwaren til displayet minder meget om den der bruges i Windows, med messages osv. gcontrols.h indeholder GUI-komponenter som de kendes fra Windows, dvs. knapper, tekstfelter osv. genfonts.h indeholder forskellige skrifttyper (fonts), som f.eks. ArialBlack, der anvendes til denne applikation. Dispatch.h indeholder funktioner til real-time Message håndteringer, og event handling. fb.h indeholder den grundlæggende display driver. Displayapplikation som skal laves til dette projekt, skal kunne vise den aktuelle måleværdi fra Equalizerens niveausensor, Kælderpumpensstatus, om der kørers i Automatic Control mode, samt en log-graf identisk med den som vises via webinterfacet, blot med en langt større opløsning. Desuden skal det selvfølgelig være muligt at få adgang til den Service menu, som allerede findes i den eksisterende software. Service menuen kan bruges til forskellige former for opsætning af kortet, bl.a. opsærning af IP-adresse. Applikationen er samlet i filen UWelcome.c. Med udgangspunkt i disse krav tegnes en skitse for displayets layout (illustreret på figur 4-11). WelcomeField er et tekstfelt som skal indeholde informations teksten. SetupField er en touch-knap, hvorfra det skal være muligt at få adgang til Service-menuen. GraphArea er området hvor grafen skal vises. Det er 96 pixels bredt så det kan vise lige så mange logninger som webinterfacet, men det har en fire gange så høj opløsning på y-aksen, nemlig 100 pixels. 49

50 Figur 4-11: Layout skitse for touch-displayet. Alle mål er i pixels. Figur 4-12: Touch-Displayet som det ser ud i kabinettet med backlight. Uwelcome.c indeholder en funktion: FormWelcomeLoop(), som tegner alt på displayet, som var det en Form i Windows. Funktionen består af et switchstatement, som kan håndtere nogle forskellige Messages. Når formen initialiseres, kaldes MESSAGE_CREATE, som initialiserer de to tekstfelter (WelcomeField og SetupField) på formen. Da displayet er en Touch-Screen, er alle tekstfelter i princippet knapper, og initialiseres derfor som sådan. MESSAGE_PAINT kaldes hver gang formen skal opdateres, og det er derfor den der sørger for selve udskrivningen af data på displayet. Først sammensættes den tekst som skal indsættes i WelcomeField. Aktuelt måleresultat m.m. fås fra den globale BWare-struct. Den sammensatte tekst InfoText udskrives i tekstfeltet med funktionen GControlSetBitMap(). Under tekstfeltet, tegnes log-grafen i et fast tildelt rektangulært område på 97*100 pixels. Rektanglets øverste venstre hjørne har koordinaterne (GraphX, GraphY). Først slettes grafen ved at udfylde rektanglet med farven WHITE, hvilket af LCD-displayet forstås som gennemsigtigt. Inden graftegningen kan begynde, er det igen vigtigt at TimerLog-timeren ikke afbryder proceduren, derfor sættes LogEnabled = FALSE. Grafen tegnes ganske enkelt ved ved at gennemløbe de 96 x-koordinater, og få funktionen DeviceLog_Graph() til at returnere det passende y-koordinat. For at få grafen til at være inde i rektanglet, beregnes det relative koordinatsæt (XPixel, YPixel), som bruges af funktionen GdPoint() til at sætte en pixel det pågældende sted. MESSAGE_TIMER kaldes rutinemæssigt for at opdatere displayet med funktionen DispatchPaintMessage(). Softwarekernen som normalt bruges til styring af vaskemaskiner, har også et touch interface, hvorfra det er muligt at opsætte basale parametre for processorkortet, som f.eks. dets IPadresse. Denne setupmenu er også medtaget, i denne applikation. Der er adgang til menuen ved at trykke på SetupField. Når et tryk på tekstfeltet registreres sendes en MESSAGE_LBUTTONUP, som fremkalder setupmenuen. 50