Prosjekt i Styresystemer og Reguleringsteknikk TELE2008-A V2016 Totank. Gruppe 1 Gruppe 2

Transkript

1 Prosjekt i Styresystemer og Reguleringsteknikk TELE2008-A V2016 Totank Gruppe 1 Gruppe 2 Morten Andre Astad [MAA] Endre Bøen [EB] Albert Danielsen [AD] Irja Gravdahl [IG] Marius Loraas [ML] Ruben Winsjansen [RW] Simen Rogn Aune [SRA] Vebjørn Eklo [VE] Anders Lunde Engen [ALE] Marius Vatnehol Fjørtoft [MVF] Petter Liljenstrøm [PL] Stein Ivar Sylte [SIS] 4. mai 2016

2 Sammendrag For en enkel gjennomgang av prosjektet er det her inkludert to sammendrag, ett om prosjektorganiseringsbiten og ett om den tekniske delen. Gruppene er godt fornøyd med gjennomføringen av prosjektet som helhet og prosjektdelens samarbeid har vært givende del for alle involerte. Prosjektorganisering [VE] Under prosjektet for to tanker, skal to grupper slå seg sammen om å forbedre og videreutvikle to forskjellige løsninger på samme oppgave, til en optimal løsning på oppgaven til totankprosjektet. Gruppene har fått oppleve prosjektstyring på tvers av hverandre. Med forskjellige arbeidsmetoder og løsninger på problemstillinger, har utfordringen ligget i å samkjøre disse. Arbeidsfordelingen foregikk veldig naturlig. Enkelte ønsket å bytte beite, mens andre valgte å fortsette med de samme arbeidsoppgave de hadde fra tidligere prosjektdeler. Prosessen var kjapp, noe som gav mulighet for å ta fatt på oppgaven tidlig i samarbeidet. Begge gruppene brakte med seg løsninger fra tidligere prosjektdeler. Hvordan de forskjellige arbeidsstasjonene taklet dette var ulikt. Noen valgte å ta utgangspunkt i den ene gruppens tidligere arbeid. Noen valgte i stor grad å sveise sammen de ulike delene, mens andre startet fra scratch med idéer tydelig inspirert fra begge gruppene. Det var mulig å løse dette så forskjellig på grunn av den røde tråden i samarbeidet, nemlig prosjektstyringen. Et felles mål for oppgaven gjorde samarbeidet og motivasjonen langt bedre. Det ble tidlig i prosessen opprettet felles arbeidspakker for denne delen av prosjektet. Det gav gruppene et godt utgangspunkt for et bra samarbeid. En kommunikasjonsplattform ble også tidlig opprettet for utveksling av vesentlig materiale og informasjon. Denne tidlige initiativtakingen har gjenspeilet seg gjennom hele uka vi nå har samkjørt, og er grunntonen til at samarbeidet på tvers av gruppene gikk bedre enn forventet. Teknisk del [ALE] Under Kapittel 2 Teknisk del finnes det oversikt over gjennomføring av de forskjellig tekniske delene av totank-prosjektet. I tillegg finner vi anleggsbeskrivelse som forteller hvordan anlegget er satt opp med de forskjellige komponentene og apparatene. Et prosessdiagram er inkludert for å gi innblikk av oppsett på riggen. Ordliste og hardware har vi valgt å referere til i Entank, ved at dette ble nøye beskrevet der. Videre forklares prosessen for opprydding av program i PLS og hvordan vi håndterte sammenslåing av hver av gruppenes resultater. For gruppe 2 ble det gjort en del endringer i funksjoner, alarmer og verdier pga ulikt oppsett av tank 2 og tank 1 på riggen. Under 2.3 Brukergrensesnitt, InTouch har vi gått ut ifra tilbakemeldinger fra Entank-presentasjonene til begge gruppene, og satt sammen et helt nytt brukergrensesnitt for begge tankene. Her ser man design av hvert enkelt vindu, og detaljert beskrivelse av oppsett av noe av de vanskeligere 1

3 delene benyttet i vårt brukergrensesnitt. En ny tagliste ble opprettet av tags fra begge grupper og ordnet for å gjøre det mest mulig intutivt på InTouch en. Oppsett av ix-panelet blir forklart under 2.4, vist med utklipp av de forskjellige vinduene. Syntese av hver av gruppenes resultat har her også blitt satt sammen til et oversiktlig sluttprodukt. Morten Andre Astad Simen Rogn Aune Endre Bøen Vebjørn Eklo Albert Danielsen Anders Lunde Engen Irja Gravdahl Marius Fjørtoft Marius Loraas Petter Liljenstrøm Ruben Winsjansen Stein Ivar Sylte 2

4 Innhold 1 Prosjektorganisering Innledning [IG] Problemstilling [IG] Prosjektstyring, Gruppe 1 [IG] Prosjektmål [IG] Samarbeid med Gruppe 2 [IG] Tidsstyring [AD] Prosjektstyring, Gruppe 2 [SRA] Samarbeid med Gruppe 1 [SRA] Konklusjon [SRA] Teknisk del Anleggsbeskrivelse [IG] Prosessdiagram [EB] Fiks av flowmåler [ML] PLS-programmet Hovedstruktur [MAA] Fremgangsmåte for utforming av logikk [ML] Opprydding av program for Gruppe 2 [MVF] og [SIS] Brukergrensesnitt, InTouch Arbeidsfordeling, koordinering og samarbeid [IG] Design [IG] Tagliste [IG] Alarmhåndtering for to tanker [ALE] Brukergrensesnitt, ix Panel TA Arbeidsfordeling, koordinering og samarbeid [RW] Innledning [SRA] og [PL] Valg av brukergrensesnitt [SRA] og [PL] Tags [RW] Alarmhåndtering [RW] Fjernstyring av ix-panel over web [ML] Filter i praksis [ML] Testskjemaer Testskjema, InTouch [VE] Testskjema, ix Panel TA100 [SRA] og [PL]

5 3 Bonusoppgave, Gruppe Frekvensomformer Kommunikasjon [EB] PLS-programmet [EB] Master-programmet [EB] Slave-programmet [EB] Brukergrensesnitt [EB] og [RW] ix Panel [RW] Konklusjon [EB] Bonusoppgave, Gruppe PID-instruksjonen + PID Settings [MVF] Vedlegg Bonusoppgave: GX Works PID-blokk, Gruppe 1 [AD] Blokkens funksjon [AD] Blokkens formler [AD] Bruk av blokken [AD] Testing og Konklusjon [AD] Komplettering av Entankrapport, Gruppe 1 [MAA] Bruk av PROFIBUS brukerdiagnostikk [MAA] Arbeidspakkeskjema, Gruppe 1 [IG] Gantt-diagram for totank, Gruppe 1 [RW]

6 Kapittel 1 Prosjektorganisering 1.1 Innledning [IG] Som en siste hoveddel av prosjektet i faget Styresystemer og reguleringsteknikk skal det gjennomføres en prosjektdel, totank. Nå var det ikke lenger en tank det skulle reguleres, men to. I tillegg til dobbelt opp med tanker ble vi dobbelt så mange på gruppen, gruppe 1 og gruppe 2 ble slått sammen til en større samarbeidsgruppe. Målet med denne prosjektdelen var å skru sammen det begge gruppene hadde kommet frem til i entankdelen av prosjektet. Hver gruppe skulle styre vær sin tank med det de hadde kommet frem til tidligere og dette samarbeidet har fungert meget godt. Det ble bestemt at gruppe 1 skulle få styre master-pls en og slave 1, mens gruppe 2 skulle da råde over slave 2 med sine program. Etter justeringer og utbedringer, både i PLS ene og for begge brukergrensesnittene, for å få alle komponenter til å samarbeide kom programmene fint sammen til presentasjonen. I tillegg til tekniske tilrettelegginger ble det plutselig en annen form på prosjektstyringen for denne nå dobbelt så store gruppen. Ettersom begge gruppene har hatt egne gode interne rutiner for sine grupper frem til totankdelen, ble det organisert et møte hvor vi la ned noen grunnleggende linjer alle enkelt kunne forholde seg til; dette innebar enkelt og greit at alle måtte møte opp, at terskelen for å spørre om hjelp skulle være like lav selv om vi var flere og at vi kunne forvente av hverandre en topp innsats slik at vi kunne komme i mål med alt vi ønsket å oppnå i god tid med hensyn til både interne og eksterne tidsfrister. Gruppene er godt fornøyd med totankdelen av prosjektet og hvordan denne har utviklet seg til et godt samarbeid og et flott resultat i form av en god demo for veiledere og at alle involverte har blitt godt kjent med hverandre og fått innsikt i andres måte å jobbe på. Vi ønsker å takke våre veileder Pål Gisvold og Arnfinn Hofstad for veiledning og hjelp under prosjektdelen. 5

7 1.2 Problemstilling [IG] I totankdelen av prosjektet er det mange krav som skal oppfylles for å få godkjent presentasjonen og rapporten, disse er de samme som i entank, men nå skal to grupper regulere på to tanker. Problemstillingen omhandler hva som skal løses og hvilke krav det stilles til en gjennomgående god rapport og et godt reguleringsmessig produkt. Kravene til systemet reguleringsmessig mm. er som følger: 1. Regulatoren skal justeres inn slik at det blir et innsvingnignsforløp av typen minumum areal når nivået har stabilisert seg uten stasjonært avvik med referanse på 60% og det kommer et sprang i utløpet fra ca 3/3 utløp til ca 1/3 utløp, altså fra tre magnetventiler åpne til en magnetventil åpen. 2. Det skal være raskest mulig innsvingningstid til nivået av tanken holder seg innenfor ±2% av måleområdet. 3. Det dynamiske avviket skal være minst mulig. 4. Regulatoren skal kunne fungere som både P- og PI-regulator. 5. Regulatoren skal inneholde mulighet for foroverkobling av P-, D- og PDtype. 6. I foroverkoblingsdelen skal det være mulig å sette både K p F F, T d F F og NF F. 7. Regulatoren skal ha både direkte og reversert modus 8. Det skal være mulig å sette regulatoren i manuell modus i tillegg til det automatiske. 9. Det skal være rykkfri overgang mellom P- og PI-regulator, samt mellom manuell og automatisk modus. 10. Det skal gå alarm dersom nivået avviker mer enn 25% fra referansen. 11. Kritisk alarm skal aktiveres dersom det absolutte nivået overstiger 90% eller går under 10%. 12. Ved vanlig alarm skal ei varsellampe på tanken blinke med 0.5 sekunder på og 0.5 sekunder av. 13. Ved kritisk alarm skal blinkefrekvensen økes slik at lampen blinker med 0.2 sekunder på og 0.2 sekunder av. 14. Dersom alarmen er kvittert fra enten InTouch eller ix Panel TA100, men det fortsatt er alarmtilstand skal lampe holde fast lys til det ikke lenger er registert alarmtilstand. 15. Dersom det ikke er alarmtilstand skal lampen bli mørk. 16. Om prosessen går ut av alarmtilstand uten at alarmen er kvittert skal lampen fortsette å blinke til alarmen er kvittert. 6

8 17. Alarmtilstander som varer mindre enn 5 sekunder skal ikke utløse alarmene. 18. Programmet skal utformes slik at det er mulig å skru pumpa av og på. Ved kritisk høy alarm skal pumpa skru seg av automatisk. 19. Det skal brukes antialiasingfiltre i forbindelse med regulatoren. Det ene skal brukes på målt nivå i tanken og skal være av 2. orden. Det andre skal filtrere på målt utløp. 20. I InTouch skal det være muligheter for innlogging av 3 operatører med følgende brukernavn og passord. Brukernavn: OPERATØR1 og passord Op1, OPERATØR2 og passord Op2 og OPERATØR3 og passord Op3. Operatørene har forskjellige rettigheter som vist i tabell Prosjektstyring, Gruppe 1 [IG] God prosjektstyring er nøkkelen til et velykket prosjekt. Prosjektet har hatt et stort omfang og dette har gruppen merket godt allerede ved gjennomføringen av de tidligere rapportene og prosjektdelene. Da prosjektet har klare tidsfrister, er det enda viktigere med god tidsstyring slik at vi får etablert effektive arbeidager som gir utbytte, gode resultater og enda mer pågangsmot. En vurdering av prosjektet, fra utdeling av oppgaveteksten til totankrapportens innlevering, skal inngå som en del av totankrapporten for begge gruppene. Da det nå ble dobbelt så mange personer involvert i et prosjekt på den samme riggen, får man raskt merke forskjeller og likheter innad i gruppene. Det har vært veldig lærerrikt å jobbe sammen med en annen gruppe om den samme oppgaven, og se hvordan de har valgt å løse tidligere utfordringer sammenliknet med hvordan vi har valgt å løse mange av de samme tilfellene. Prosjektstyring på en god måte når gruppens størrelse øker og det å få arbeidsdager, oppgaver og utfordringer til å gå opp har preget prosjektstyringen i denne prosjektdelen, og samarbeidet har gått over all forventning. Vi som gruppe har fortsatt det gode samarbeidet innad i gruppen og samtidig fått jobbet tett på andre medstudenter som var like motivert som oss til å gjøre det bra. Videre følger en vurdering av prosjektstyringen fra prosjektets start som vi har konkludert med at har vært meget god Prosjektmål [IG] Prosjektmål handler om hvor vi ønsker å ende opp og hvordan vi har tenkt å komme dit. Med klare mål blir prosjektet lettere å gjennomføre og gjør gruppen adskillig mer motivert, når man etterhvert som tiden går og prosjektet utvikler seg kan nå delmål og etterhvert et endelig hovedmål. Det å ha noen klare mål gjorde det enklere for gruppen å nå det endelig hovedmålet. Prosjektmålet for hele prosjektperioden har hovedsaklig vært læringsutbytte som vi kan ta med oss videre som veldig god erfaring. Dette målet har vi nådd; hele gruppen har hatt enormt læringsutbytte gjennom hele prosjektperioden, og vi kan ikke si noe annet enn at vi er veldig fornøyd med vår egen innsats og gjennomføring av prosjektet. 7

9 Resultatmål [IG] Fra oppstarten av prosjektet med forprosjekt har gruppen vært klar på å sette gode spesifikke mål både med tanke på hva vi ønsker å oppnå og hvordan vi har tenkt å nå disse målene. I forprosjektet var resultatmålene å bli godt kjent med hverandre, organisere oss og kartlegge sterke og svakere sider med gruppas medlemmer og gruppen som helhet. Et hovedmål med forprosjektet som gruppen har truffet veldig godt med er god planlegging av ressurser gjennom utarbeiding av detaljerte arbeidspakker og Gantt-diagram. Gruppen kom godt i mål med å bli kjent, og vi har jobbet godt gjennom hele perioden med å utfylle og hjelpe hverandre der vi selv føler vi muligens kommer litt til kort. I miniprosjektet sto målet om å oppnå kommunikasjon i sentrum. PLS, Profibus og operatørpanel skulle alle kommunisere effektivt og uten tap av data. Dette ble sikret gjennom grundig testing av systemetet, forståelse når det kom til overføring av data og det at vi satt oss inn i hvordan informasjonen leses og skrives gjorde at vi oppnådde dette målet raskt og kunne utbrodere miniprosjektet som en forberedelse til entankdelen av prosjektet, og få en tjuvstart på målene vi satt oss til den prosjektdelen. Simulinknotatets mål innebar å utvikle en så komplett og godt fungerende modell som overhodet mulig. Innstillingene vi kom frem til der fungerte veldig godt og all jobben som gikk inn i modelleringen gjorde reguleringen i entankdelen grei å etterjustere. Målet ved simulinknotatet om en meget grundig modell synes vi ble nådd, og utført veldig bra. Resultatmålet for entankdelen av prosjektet var å bygge en god reguleringsstruktur rundt én tank. For å oppnå dette benyttet vi master- og slaveregulator i tillegg til de hjelpemidler vi har til vår disposisjon fra fagene vi har gjennomført så langt i vår utdanning. God regulering av nivået i tanken innebar rask respons, stabilitet og sikkerhet mot støy. To antialiasingfilter ble også implementert. Disse overordnede målene ble oppnådd med glans og gruppen er spesielt fornøyd med innsatsen som ble utøvd under denne prosjektdelen. Det at gruppen klarte å jobbe så mye og godt over lang tid med denne delen, gjorde alle meget motivert til å fortsette prosjektet i et samarbeid med gruppe 2. Totankdelen av prosjektet har sirkulert rundt de samme målene som i entankdelen av prosjektet. God regulering og gode regulatorparametere. I tillegg til dette målet har målet om god prosjektstyring og et mål om samarbeid på tvers av gruppene har stått veldig sentralt. Dette målet mener vi er oppnådd med tanke på at gruppene har fungert meget godt sammen, utvekslet ideer og hørt på hverandres meninger gjennom hele prosessen. Det å endelig kunen ha riggen hver dag har også bidratt til god stemning. Da vi alle jobbet mot det samme målet sammen, ble det motiverende å jobbe mot et så godt som mulig resultet; både teknisk og samarbeidsmessig. Et overordnet mål gjennom hele prosjektet har vært at systemet skulle kunne styres intuitivt, raskt og responsivt. Noen uten bakgrunn i automatisering skulle 8

10 kunne forstå hvordan man opererer reguleringen av systemet. For å oppnå dette ble det gjennom hele prosjektet utviklet brukergrensesnitt på operatørpanel og PC og rapportene bar preg av grundig gjennomgang som omhandlet hvordan og hvorfor enkelte ting er blitt gjort. Underveis har også gruppen levert inn meget grundige, gjennomgående gode rapporter med en godt gjenkjennelig rød tråd. Rapportene reflekterer både de tekniske resultatene og prosjektorganiseringen. Ingen av de ovennevnte målene hadde vært mulig uten at arbeidsgruppa organiserte seg på en hensiktsmessig måte. Vi sørget hele tiden for at vi alle hadde arbeidsoppgaver og at vi var behjelpelige ovenfor hverandre underveis i prosjektet. Det var viktig at vi hverken brukte for mye eller for lite tid sammenlagt, men at vi fulgte arbeidsfordelingen gitt i tidsplanen og arbeidspakkene. Gruppen er svært fornøyd med resultatene som er blitt oppnådd; både med tanke på teknisk måloppnåelse og det å ha jobbet godt sammen i det som har vært en omfattende samarbeidssituasjon. Effektmål [IG] Figur 1.1: En regulert læringsprosess Det gjennomgående effektmålet for Gruppe 1 har hele tiden vært læringsutbytte. Det å få jobbe på en ny måte, tilegne seg kunnskap om forskjellige aspekter ved programmering og regulering og få jobbe i en veldig god gruppe har vært viktig for oss og gjort det mulig for oss å oppnå dette målet. Med tanke på prosjektstyring og forprosjektet fikk vi erfaring innen etableringen av arbeidsgrupper og gruppen har fått følelsen av hvordan vi individuelt arbeider med tanke på tidsfrister. Kartleggingen av gruppedynamikken har vært viktig for at prosjektet i det hele tatt ble gjennomført innen rimelig tid. Miniprosjektet ga oss i innsikt i hvordan de forskjellige komponenteren vi tok i bruk kommuniserte med hverandre og hvordan data lagres. Vi lærte masse om dataoverføring, lesing og skriving i PLS ene, forskjellige kabler, overføringsprotokoller og utstyr som vi vil møte i industrien. Effekten av dette var at når vi kom til entankdelen av prosjektet var vi alle allerede bevisst på hvordan kommunikasjonen foregikk; dermed kunne vi bruke mer tid på fokuspunktene våre der, isteden for å jobbe med opprettelsen av kontakt. Simuleringsnotatet ga oss enorm innsikt både i systemet vårt og generell bruk av simuleringsverktøy. Ved at vi fikk modellert skikkelig og sammenliknet dette med den virkelige modellen så vi sammenhenger mellom matematikken og den virkelige verden. Med bedre kunnskap kom evnen til å regulere det virkelige systemet på en egnet måte. Ved prosjektets slutt har vi en bedre forståelse og er mer erfarne i programmene Matlab og Simulink. 9

11 Programmering av regulatoralgoritmer og styring av prosessen gjennom simuleringen ga gruppa erfaring i hvordan man praktisk tok i bruk teorien fra faget Styresystemer og reguleringsteknikk. Systemets reaksjon på våre innstillinger viste hvordan fysiske systemer reagerer på kriteriene vi dimensjonerte etter og dette var en del av prosjektet alle fulgte med på og kom med innspill til. Under opprettelsen av brukergrensesnitt lærte gruppen mye om hvordan er HMI burde opprettes og hvilke krav som ble stilt for at denne typen medium skulle sørge for god kommunikajon mellom operatøren og reguleringen. Rapportene underveis og presentasjonene på møter skulle gi tilhørerne en grundig oversikt over prosjektets utførelse. Effekten av dette har vært at vi klarer å presentere mye informasjon på en god og forståelig måte. Formidling av det vi har utført av arbeid, er minst like viktig som å skjønne arbeidet. Andre produkter av rapporteringen og presentasjonene er at vi har fått styrket vår egen kunnskap om prosjektet og at vi får erfaring i fremføringer av et prosjekt med så vidt omfang. Organiseringen av prosjektet, fordelingen av oppgaver, møter og samarbeid innad i gruppa har ført til verdifull erfaring i ingeniørhverdagen. Målet med prosjektstyringen har vært å sørge for at alle gruppas medlemmer får oppgaver de føler at de kan mestre. Uten å samarbeide tett og bli godt kjent med hverandre ville dette vært nærmest umulig. I arbeidslivet arbeider ingeniører gjerne tett sammen, så å få et dypere innblikk i hvordan man selv fungerer i en arbeidsgruppe har vært uvurdelig. Gruppen er veldig fornøyd med effekten av prosjektet og hvor mye vi har lært, både om oss selv, hverandre og flere aspekter ved styresystemer og reguleringsteknikk Samarbeid med Gruppe 2 [IG] Under totank-delen av prosjektet blir to og to grupper slått sammen om å regulere nivået i to tanker på samme rigg. Gruppe 1 og gruppe 2 ble slått sammen og skulle samarbeide om å sy sammen program fra entankdelen av prosjektet for å ende opp med god regulering på tvers av gruppene; både med tanke på program i PLS ene, to brukergrensesnitt og prosjektstyring. Samarbeidet har gått veldig bra; vi tok initiativ til å ha en god dialog med den andre gruppen fra start av ved små møter og gruppechat på Facebook så vi var alle enkelt tilgjengelige. Så tidlig som i forprosjektet jobbet vi sammen om å utvikle felles arbeidspakker for denne delen av prosjektet. Fordeling av tid på riggen har også gått ganske fint gjennom hele perioden, selv om begge gruppene gjerne skulle ha hatt riggen hver dag når det har nærmet seg milepæler. Nå som vi har jobbet sammen har vi lært hverandre å kjenne og det å ha flere personer på gruppen å kaste ball med har vært veldig lærerrikt. Felles plass på internett til deling av filer, fast arbeidstid og et gjennomgående ønske om å gjøre det godt har vært motiverende for alle involvert. 10

12 1.3.3 Tidsstyring [AD] Gjennom hele prosjektet har alle gruppas deltakere vært opptatte av at planlegging og tilrettelegging av effektivt arbeid er viktig. Mesteparten av tiden vi har brukt i dette prosjektet har gått med til planlegging, samt rapportering av arbeidet. På den måten føler vi i at vi har fått maksimalt utbytte av den lærdommen vi har tatt til oss. Gantt-skjemaene og arbeidspakkeskjemaene som skal kreditteres til Ruben Winsjansen og Irja Gravdahl, respektivt, har vært sentrale i å holde en god struktur på arbeidet. Mad en slik overordnet plan for arbeidet har vi vært i stand til å unngå at noen har tomme hender, altså står uten arbeidsoppgave. En annen ting som har hjulpet gruppen er at vi har vært noe strenge på å komme for sent. Vi har avtalt tider for oppmøte, og fulgt disse tidene. Slik har vi kunnet startet arbeidsdagen i rett tid, gjerne før klokka ni, og sluppet å sitte til sent på kveld. Det å sitte til sent å jobbe er noe som tærer på kropp og sinn og derfor noe vi har unngått så langt det har latt seg gjøre. Gantt-diagram [AD] I Kapittel 5 Vedlegg ligger Gantt-diagrammet for totankprosjektet på arbeidspakkenivå. Totankprosjektets forløp har gått tilnærmet likt det som ble forutsett i Gantt-diagrammet, se figur 5.9. Timeforbruk [AD] I februar, ved prosjektets start, satte vi et mål om å bruke under 1800 timer på hele prosjektet. Vi ville se på timer brukt som en ressurs, og rett og slett tenke at flere timer brukt tilsvarer et dyrere prosjekt. Gjennom hele prosjektet har gruppas medlemmer ført alle timene arbeid i et Excel-ark slik at vi har full oversikt. Og nå er vi i stand til å konkludere med antall timer, og at vi har holdt oss innenfor vårt budsjett. Figur 1.2: S-kurve for Gruppe 1 11

13 1.4 Prosjektstyring, Gruppe 2 [SRA] I dette kapittelet vil det bli framstilt hvordan vi i prosjektgruppe 2 har erfart det har gått å arbeide sammen i dette prosjektet. Prosjektets varighet har vært på nærmere 3 måneder. På denne tiden har vi tilegnet oss betraktelig med ny kunnskap ved forskjellige fronter. Alle deltakere føler de sitter igjen med en dypere forståelse av hvordan et prosjekt av et større omfang blir praktisert. Gruppens framtredende avgjørelser og tankegang rundt forskjellige deler av prosjektet vil bli kommentert. Samarbeidet med prosjektgruppe 1 vil også ha en betydelig rolle i dette kapittelet. I siste avsnitt vil det komme en konkluderende sammenfatning av prosjektet i sin helhet, som innebærer samarbeide med og uten prosjektgruppe 1. Prosjektgruppen ble satt sammen av en av våre lærere i Styresystemer og reguleringsteknikk, som også er vår veileder (prosjektgruppe 2), Arnfinn Hofstad. Han satte sammen gruppene basert på to forhold; at noen på enhver gruppe hadde praktisk erfaring (fagbrev i automasjon f.eks.), og at hver enkelt kom på gruppe med en de hadde kjennskap til fra før (Arnfinn hadde fått med seg hvem som jobbet sammen ved ulike lab/pc-øvinger tidligere i semesteret). Gruppen vår inneholder personer fra alle landets kanter. Likevel hadde vi god kjennskap til hverandre før prosjektets start. I den anledning var det ingenting som stod i veien for et godt samarbeid fra begynnelsen. Behandling og oppbevaring av dokumenter ble foretatt på OneDrive. Dette verktøyet finnes gjennom Office 365, og er utviklet av Microsoft. Gjennom skolen har vi fått lisens til dette produktet. Det aksesseres gjennom It s Learning. Lagringsplassen er stor, det kan legges inn hendelser i en kalender og flere kan arbeide på et dokument samtidig. Vi konkluderte raskt med at vi ønsket å benytte oss av dette verktøyet. Helt i begynnelsen gikk dagene til utarbeidelse av forprosjektrapporten. Planlegging og strukturering av arbeidsoppgaver var vesentlig her. En rekke arbeidspakker ble laget, og på den måten ble vi godt kjent med hvilke oppgaver vi hadde i møte. Ingen konkrete oppgaver, som for eksempel programmering av PLS og brukergrensesnitt i InTouch/operatørpanel ble tildelt enkeltpersoner. Vi ventet med dette til vi kom til miniprosjektet. Rollen som Word-ansvarlig fikk Simen, som hovedsakelig innebar å sette sammen alle sitt arbeid inn i den aktuelle rapporten og gjøre den presentabel. Her ligger det mye arbeid som kanskje havner under radaren. Under et internt møte i startfasen av miniprosjektet begynte vi å diskutere hvordan vi skulle fordele oppgavene. Vi endte med å tildele guttene med fagbrev, Marius og Stein-Ivar, PLS-programmeringen. De besatt det høyeste kunnskapsnivået på dette området. Anders endte opp med InTouch og Petter med operatørpanelet. Simen og Vebjørn drev med diverse oppsett av kommunikasjon. Vi jobbet tett sammen og ga hverandre tilbakemeldinger på hverandres arbeid. Brukergrensesnittene ble ikke utarbeidet av kun en person, men i samråd med resten. I entank-delen beholdt vi de samme oppgavene. Simen og Vebjørn utførte simuleringer og modelleringer av systemet i Simulink, som resulterte i Simuleringsnotatet. Hvordan fordelingen av oppgaver foregikk i totank-delen kommer 12

14 senere under Samarbeid med gruppe 1. Enkelte dager ble tilbrakt på labben til sent på kveld. Spesielt i perioder hvor et produkt skulle innleveres/vises frem i de kommende dagene. Forklaringen på at det ble slik er nødvendigvis ikke på grunn av dårlig planlegging, men at vi alltid følte det var noe å rette på. Dette erfarte vi spesielt i dagene før entank-delen skulle vises frem. Vi endret på programbiter rett før presentasjonen skulle finne sted. Det hele resulterte i at tank-riggen plutselig ikke lengre responderte slik vi ønsket den skulle. Her fikk vi en god lærepenge som vi kan ta med oss videre i livet. Ikke endre på et fungerende program rett før visning! Gjennom en rekke prosjektmøter med vår veileder fikk vi god trening i å både være møteleder og møtereferent. Kvaliteten på møtene ble større og større for hver gang. I starten var møteinnkallingene med mangler og møtereferatene litt for tynne. Vi går fremdeles på skolen, og er her for å lære. Å få til alt på første forsøk er ikke meningen. Det gir også god læring i å feile. På møtene kom veileder Arnfinn med gode og konstruktive tilbakemeldinger på arbeidet vårt. Vi tok til oss alle kommentarer, og gjorde det vi kunne for å få ordnet opp i feil/mangler til neste gang Samarbeid med Gruppe 1 [SRA] I prosjektets oppstartsfase stiftet vi bekjentskap med gruppe 1. Vi var tidlige klare over at vi i en kommende del av prosjektet skulle samarbeide. I den sammenheng ble det arrangert et møte med deltakere fra begge prosjektgruppene tidlig prosjektet. På møtet kom det et forslag fra gruppe 1 om at vi i forprosjektet skulle dele arbeidspakker angående totank-prosjektet. Det syntes vi var en god idé. Hovedformålet med møtet var å opprette kommunikasjon mellom gruppene. En kommunikasjonskanal ble etablert. Felles gruppechat på det sosiale mediet Facebook ble plattformen. Der fløt samtalen mellom gruppene fritt, og vi var plutselig til enhver tid kun en melding unna hverandre. Mot slutten av miniprosjektet ble vi enige med gruppe 1 om å benytte tankriggen annenhver dag. Dette fungerte som regel veldig fint, selv om vi mot slutten av entank-prosjektet gjerne skulle ønsket at vi hadde riggen hver dag. I stedet ble det lange dager på skolen de dagen vi hadde riggen til vår disposisjon. I totank-prosjektet gikk samarbeidet knirkefritt. Tiden gikk med til å flette/utvikle brukergrensesnitt i både InTouch og operatørpanelet, mens de ansvarlige for programmering av PLS satt sammen sine program etter hva som egnet seg best. Når det gjaldt rapporten godtok vi forespørselen fra gruppe 1 om å skrive den i tekstbehandlingsprogrammet LaTeX. Programmet skiller seg fra Microsoft Word som vi har brukt på alle våre tidligere rapporter og notat. Gruppe 1 har brukt LaTeX i alle sine tidligere skriverier, og ønsket dermed å beholde denne formen for rapportering Konklusjon [SRA] Vi konkluderer med at dette har vært en svært lærerik prosess for oss på veldig mange ulike måter. Hvordan det er å arbeide i et team tror vi vil ha meget stor 13

15 overføringsverdi når vi en dag skal ut i arbeidslivet. I tillegg mener vi at det vært fordelaktig å kunne bruke det vi har lært i forelesninger mot noe praktisk. Læringskurven har vært høy, og vi har tilegnet oss kunnskap om vitale elementer i automatiseringsbransjen. Selv om det finnes mange ulike programvarer som benyttes, har vi lært oss hvordan et operatørgrensesnitt skal se ut, hvordan diverse kommunikasjonsenheter samspiller med hverandre, og hvordan og hva som kreves når oppgaver av denne typen skal løses med tanke på PLS-ens oppbygning og virkemåte. Prosjektet har krevd mye av oss individuelt og som en gruppe. Hver enkelt deltaker har som regel gjort seg opp noen tanker i hodet angående hvordan de ønsker å løse enkelte oppgaver. I et prosjekt av denne størrelsen, hvor arbeidsoppgavene er flerfoldige og forskjellige, er det ikke mulig å ha full forståelse på alle fronter. I alle fall ikke samtidig. Derfor var det meget viktig med god kommunikasjon innad i gruppen, slik at informasjon kunne videreføres. Vi har vært nødt til å stå på for hverandre for at det skulle være mulig å gjennomføre. Stemningen i gruppen har vært upåklagelig. Det har ført til at det ikke har vært et problem å tilbringe mye tid sammen på labben. 14

16 Kapittel 2 Teknisk del 2.1 Anleggsbeskrivelse [IG] For en komplett oversikt over Ordliste og Hardware og Software benyttet i det tekniske arbeidet, refererer vi til Entankrapport for Gruppe 1, s og Entankrapport for Gruppe 2, s. 9. Prosessen som vist i figur 2.1 består av en pumpe som går med konstant frekvens og leverer et vanntrykk til oversiden av reguleringsventilen. Reguleringsventilen er prosessens pådragsorgan og er styrt av en motoaktuator som får sitt signal på 4-20mA fra PLS en. Videre fordeles vannet over to tanker ved hjelp av en ventil som åpnes slik at vannet også strømmer inn i den høyre tanken på riggen. I bunnen av hver tank sitter det en nivåmåler som registrerer nivået og kommer med en tilbakemelding på dette til PLS en, denne informasjonen sendes tilbake til PLS en. I den venstre tanken går vannet gjennom en strømningsmåler og informasjonen om denne strømnignen sendes også tilbake til PLS en. Utstrømningen fra den venstre tanken styres av tre kontrollerbare magnetventiler og en manuell ventil. En manuell ventil kan også endre utløpet til den høyre tanken, disse kan ikke styres fra PLS ene. Regulering og databehandling foregår i PLS ene, men for å gjøre dette tigjengelig for brukeren er det utviklet to brukergrensesnitt for prosessen med to tanker; ett på ix-panelet og ett på PC ved bruk av Wonderware InTouch. I brukergrensesnittene kan man sette parametere som registreres i PLS en, sender signal til pådragsorganet og dermed regulerer prosessen. Tre filter og også inkludert i prosessen, disse ble utviklet i entankdelen av prosjektet. Et filter på hver nivåmåler og et for å dempe støy i utløpet fra den venstre tanken. I tabell 2.1 finnes en liten oversikt over de forskjellige komponenete som er benyttet på riggen. 15

17 Tabell 2.1: Oversikt og komponenter på tankriggen Komponenter på tankriggen Komponenet Spesifikasjon Pumpe Grundfos UPS Frekvensomformer Danfoss VLT serie 2800 Reguleringsventil Bürkert 3010-PAA002 motoraktuator Nivåmåler 2 Tecsis, type Flowmåler Flow-Teknikk Magnetventil 3 Danfoss BB230AS Prosessdiagram [EB] Figur 2.1: Prosessdiagram, totank 16

18 2.1.2 Fiks av flowma ler [ML] Som vi diskuterte ba de i simuleringsnotatet og e ntankrapporten, behøves en fiks for at flowma leren skal fungere optimalt, da den ikke lar seg kalibrere. En forsterkning ble implementert flowma lerens filter, og løsningen innga r som en del av anlegget ogsa under totankprosjektet og bonusoppgavene. Under følger dokumentasjon pa løsningen Figur 2.2: Filteret til venstre er det som sitter pa flowma leren. Legg merke til potensiometeret, som lar en tekniker regulere forsterkningsfaktoren. + Ved a øke filterets ma lemotstand fra 250Ω til 370Ω, settes det opp en større spenning over filterinngangen som gjør at flowma lerens ma gir 1-5 Volt inn pa operasjonsforsterkeren. Denne spenningen buffres i operasjonsforsterkeren, og driver en strøm pa filterutgangen og igjennom PLSens indremotstand, pa 4-20 ma. Ma lemotstanden er gjort justerbar i form av et potensiometer, slik at forsterkningen kan justeres til ønsket niva. - - I 1 uf kω 250 Ω kω + - Målemotstand (Potensiometer) - - Pådrag fra flowmåler + + LM uf Måleelement ADC i PLS Figur 2.3: Her vises det hvordan potensiometeret er implementert i filterets signalinngang slik at man kan justere hvor stor spenning et pa trykt strømsignal skal sette opp. 17

19 2.2 PLS-programmet Hovedstruktur [MAA] Det ble raskt etablert at gruppe 1 skal ha hovedansvar for master-pls, da det eksisterende programmet fra Entank-prosjektet, var enklest å tilpasse til et felles oppsett, med alt av tidligere tilgjengelig funksjonalitet. Dette var en god beslutning da master-programmet til gruppe 1 allerede var bygget med et større system i tankene, og programmet kan i teorien med noen få endringer, for-løkker og funksjonsblokker, utvides til en hel tank-farm av samme sort. Det er ikke implementert en slik ferdig løsning i Totank-prosjektet, men utgangspunktet er likt for begge tankene, og implementeringen av den andre tanken i master-pls, består i stor grad av klipp og lim fra eksisterende løsninger fra Entank-prosjektet. Det var allikevel ikke helt problemfritt å inkludere den andre tanken i master-pls, da tankemåte og valg av løsninger, var noe forskjellig. Dette var spesielt gjeldende i forhold til variabelskalering og alarmhåndtering. Skaleringsproblematikken ble løst i ixpanel og InTouch, hvor gruppe 2 hadde valgt å bruke den samme skaleringen, som den proprietære PID-blokken fra Mitsubishi. Alarmhåndteringen viste seg å bli noe mer innfløkt, som følge av alarmlampestyring på tvers av tilstander i begge tankene, og faktumet at gruppe 2 hadde valgt å ha mulighet for individuell alarmkvittering. Det ble bestemt at vi i gruppe 1, også skal implementere mulighet for individuell alarmkvittering, da vi mente det kunne være en interessant problemstilling å løse, og det er en generell konsensus om å holde en konsekvent struktur for begge tankene. For utredning av fastlys til alarmlampe og individuell alarmkvittering, se seksjon 1.2.2, side 7-9, ved Marius Loraas. For utredning av hovedstruktur for gruppe 1 i Entank-prosjektet, se seksjon og 3.4.2, side i Entank-rapport, ved Morten Astad. Figur 2.4: Deklarering av strukturert datatype Tank2 wprofi av type Tank2 SkrivProfibus, for variabler tilhørende skrive-mellomlager i master-pls, for PROFIBUS-kommunikasjon med Tank 2. 18

20 Figur 2.4 viser hvordan en tilnærmet lik datastruktur som i Entank-prosjektet til gruppe 1, blir deklarert for Tank 2. Figuren innebefatter også de nye kvitteringsflaggene for individuell alarmkvittering. Kvittering av individuelle alarmer fungerer slik at når en alarm blir kvittert i brukergrensesnittet, så går et kvitteringsflagg for den tilhørende alarmen til slave-pls høyt, og et flagg for tilbakemelding fra slave-pls blir satt, forutsatt at det faktisk er alarmtilstand i slave-pls, og ligger høyt så lenge alarmtilstanden vedvarer. Tank1_FeilStatus.LoLo == 1 Tank1_rProfi.AckLoLoRtn = 1 Tank1_wProfi.AckLoLo == 1 Tank1_rProfi.AckLoLoRtn = 0 Tank1_FeilStatus.LoLo == 0 Figur 2.5: Sekvensiell representasjon for individuell kvittering av kritisk lavnivåalarm, sett fra master-pls. Et enkelt = tegn tilsier at en verdi blir satt, og doble = tegn tilsier en sammenligning, som må være sann for å gå videre til neste steg. Framstillingen blir lik for begge tankene, og for alle alarmene som inngår i prosjektet. Den innebygde løsningen for brukerlagd statusinformasjon, og utstyrsdiagnose i PROFIBUS DP, blir også brukt i Totank-prosjektet, hvor gruppe 2 har endret programkoden sin, slik at alarmtilstander blir skrevet til bufferminne #28, for egenlagd brukerdiagnostikk i PROFIBUS-slave. Denne statusinformasjonen blir håndtert på samme måte som beskrevet i Entank-rapport for gruppe 1, se vedlegg; Bruk av PROFIBUS brukerdiagnostikk [MAA], side Problemet med den innebygde løsningen, er at statusinformasjonen kun blir sendt ved statusendring med positiv flanke på individuelle bit-verdier. Det vil med andre ord si, at hvis det kun blir sendt feilflagg over den innebygde løsningen, så blir det aldri sendt oppdatert statusinformasjon når feiltilstanden forsvinner igjen. Det er dermed vanlig praksis å innføre flagg for normaltilstand sammen med feilflaggene, slik at PROFIBUS-master får tilsendt oppdatert statusinformasjon når prosessen returnerer til normaltilstand. Flagg for normaltilstand FeilStatus.LoLo FeilStatus.Low FeilStatus.High FeilStatus.HiHi wprofi.normaltilstand Kritisk lavnivå-alarm == 0 lavnivå-alarm == 0 Kritisk høynivå-alarm == 0 Høynivå-alarm == 0 wprofi.normaltilstand Figur 2.6: Sekvensiell representasjon av hvordan normaltilstand-flagget er oppbygd, og realiseringen av denne i PLS-programmet. Denne oppbyggingen er lik for begge gruppene. 19

21 Sammen med den brukerlagde statusinformasjonen, blir det vedlagt standard PROFIBUS-diagnoseinformasjon, som for eksempel flagg for kommunikasjonsfeil. Det er dette flagget som brukes for alarmovervåkning og visuell representasjon i brukergrensesnittet. ProfiTroubleAddress[0].SlaveAddress 2 EN s1 s2 LD= ProfiError[0].IOdataUnable Tank2_FeilStatus.Profibus ENO S ProfiError[0].IOdataUnable Tank2_FeilStatus.Profibus R Figur 2.7: Programkode for overvåkning av kommunikasjonsfeil. Det første denne programkoden gjør er å sjekke om det foreligger statusinformasjon for slave 2, øverst i listen for statusinformasjon, for så å sjekke om det har oppstått kommunikasjonsfeil. Hvis det har oppstått kommunikasjonsfeil blir et tilhørende statusflagg satt høyt, og eventuelt satt lav igjen hvis PROFIBUS-enheten returnerer til normaltilstand. Alarmhåndteringen rundt PROFIBUS-kommunikasjonsfeil, er et godt eksempel på hvordan en felles liste for statusinformasjon kan håndteres. Alle tilkoblede og konfigurerte enheter på PROFIBUS-nettverket deler den samme listen, med plass til 8 statusmeldinger på en gang, og det er dermed nødvendig å innføre lignende logikk som vist for å mellomlagre og håndtere statusverdier. Bumpless2transfer2.2PI2]>2P2/2AUTO2]>2MAN:2 u02=2u.k]1r2r2tank22 Tank2_wProfiåRegType[0] Tank2_rProfiåPådrag EN s MOV ENO d Tank2_wProfiåRegU0 Tank2_wProfiåRegMAN Figur 2.8: Programkode for rykkfrie overganger i master-pls, som sørger for at forrige-pådrag blir skrevet til nominelt pådrag ved modusendring. Programkoden er strukturmessig lik for begge tankene. Gruppe 1 hadde i Entank-delen av prosjektet valgt å løse problematikken med rykkfrie overganger i brukergrensesnittet, mens gruppe 2 løste den samme problemstillingen i master-pls. Gruppene ble innad enig om å innføre logikk for rykkfrie overganger i master-pls, som vist i figur 2.8. Det ble i Totank-prosjektet innført feilflagg for strømbrudd i master-pls. Dette feilflagget er oppbygd på samme måte, med litt ekstra logikk, som initieringsflagget fra sekvensprogrammet i figur 5.3.4, s. 105 i PLS-teknikk bok (april 2013), ved Arnfinn Hofstad. Feilflagget baserer seg på et batterimatet initieringsflagg, som setter seg selv høyt for all framtid. Hvis initieringsflagget er høyt, anses prosessen som initiert. De fleste PLS-er innehar en initieringspuls, som er høy ved første programgjennomkjøring. Det er denne initieringspulsen, sammen med initieringsflagget som utgjør feilflagget for strømbrudd. Hvis både initieringspulsen og initieringsflagget er høyt samtidig, så er det et sikkert tegn på at PLS-en har vært utenfor sin normale operasjonsmodus, som ved for eksempel strømbrudd. 20

22 2.2.2 Fremgangsmåte for utforming av logikk [ML] Under utformingen av PLS-programmet støtte vi på flere hvis-såfremt-ifall -situasjoner der en bit skal settes høy eller lav, hvis én bit er sånn og en annen er slik. Særlig under utformingen av alarmlogikken ble dette en utfordring, med en hel rekke betingelser for hva som skal skje, avhengig av tilstand på både alarmer og kvitteringsflagg. Et eksempel på en slik situasjon var når de to PLS-programmene skulle sys sammen. Da satt vi med to i utgangspunktet uavhengige programmer, som skulle styre éi fysisk alarmlampe. En systematisk løsning på disse problemene fant vi igjennom å benyttes oss av hjelpemidler fra digitalteknikken, med sannhetstabeller, karnaughdiagram, boolske uttrykk og simulering av skjema med logiske porter. Under er det drøftet et eksempel på hvordan logikken for fast lys i alarmlampen på riggen ble utformet. Først satte vi opp en sannhetstabell med de mulige kombinasjoner av innganger, og hvorvidt alarmlampen skal lyse eller ikke. Umulige inngangskombinasjoner ble satt som valgfrie tilstander, og bidrar til å forenkle uttrykket. Tabell 2.2: Sannhetstabell for tilstand fast lys i lampen på riggen. Der utgangen er merket med en x er dette en såkalt valgfri tilstand, fordi inngangene aldri skal kunne ha denne kombinasjonen av bits. Innganger Utganger AlarmTank1 AlarmTank2 KvittertTank1 KvittertTank2 (AlT1) (AlT2) (AckT1) (AchT2) FastLys x x x x x x x Deretter ble denne tabellen prosessert igjennom et karnaughdiagram 21

23 Figur 2.9: Karnaughdiagram med tre konstellasjoner Vi valgte i dette tilfellet å ta utgangspunkt i sum-av-produktform, da dette gir det peneste resultat når koden til slutt skal realiseres i ladderdiagram. AlarmRigg1 Ack2 + AlarmRigg2 Ack1 + Ack1 Ack2 Selv om det er fint mulig å gå fra dette boolske uttrykket til kode i ladderdiagram, valgte vi å realisere det logiske skjemaet for å kunne simulere det i programmet Logisim. Dette lar oss verifisere at oppførselen er som forventet, ved å sette kombinasjoner av innganger til høy eller lav, og se at utgangen oppfører seg som den skal. Skjemaet ble seende slik ut: AlT1 x 1 AlT2 x 1 FastLys x 1 AckT1 x 1 AckT2 x 1 Figur 2.10: Skjema som realiserer alarmlogikken for fast lys i lampen på riggen Til slutt ble det skrevet en kodesnutt i Ladderdiagram som tilsvarer det logiske uttrykket. 22

24 Logikk for fast lys Tank1_AlarmKvittert Tank2_NivåAlarm AlarmLampe rprofi.tank2_alarmkvittert Tank1_NivåAlarm Tank1_AlarmKvittert rprofi.tank2_alarmkvittert Figur 2.11: Logikken realisert i PLSen som ladderdiagram Denne strukturerte fremgangsmåten viste seg å være et kraftig verktøy når logikken i systemet skulle utformes. Den ble benyttet som hjelpemiddel på flere større og mindre utfordringer underveis Opprydding av program for Gruppe 2 [MVF] og [SIS] For slaveprogrammet til gruppe 2 ble det en del endringer og opprydding av diverse funksjoner, alarmer og verdier. I og med at tank 2 bare har en manuell ut-ventil, ingen strømningsmåler og ingen kontroll over pumpe og magnetventiler var dette noe som ikke var nødvendig å kommunisere over profibus. I tillegg var det to forskjellige måter å håndtere alarmer på og derfor måtte det gjøres store endringer på alarmsystemet. Gruppe 2 måtte endre alarmhåndteringen slik at det passet til alarmsystemet for både slave 1 og master-pls. Etter en god innføring i hvordan alarmsystemet til gruppe 1 fungerte ble det gjort store endringer, der noen signal ble fjernet og flere ble lagt til. I tillegg ble alle alarmer flyttet over til et eget bufferminne laget for alarmer i profibus. Resultatet av endringene kan sees på figur 2.12, 2.13 og

25 Figur 2.12: PLS, slave 2, endringer i Read Figur 2.13: PLS, slave 2, endringer i Write 24

26 Figur 2.14: PLS, slave 2, endringer i Alarm En alarm som gruppe 2 brukte på entank, avvik-alarm, ble delt opp i to deler slik at det var mulig å se om nivået i tanken var for høyt eller for lavt i forhold til referansen. I tillegg ble det innført egne alarmer for høy/lav alarm og kritisk alarm. Disse var i tillegg til signal for de fire selvstendige alarmene. For å gjøre håndteringen av signallampen på riggen enklere ble det laget et eget signal for når lampen skulle lyse fast. Måten kvittering av alarmer ble håndtert hadde vi gjort forskjellig i entank-prosjektet, men vi kom frem til at mulighet for kvittering av hver enkelt alarm var en nyttig funksjon å ha med i HMI. Vi la stor vekt på at begge tankene skulle håndtere alarmer helt likt, og noen alarmkriterier ble endret for tank 2. De kritiske alarmene fikk en 0,5 sekunders forsinkelse istedenfor 5 sekunder som gruppe 2 brukte tidligere. Dette mente vi var en bedre løsning slik at pumpen stopper med en gang og vi slipper at vannet renner over tanken, men med 0,5 sekunders forsinkelse vil det ikke bli kritisk alarm på grunn av støy. Ved oppstart innførte vi 15 sekunders forsinkelse for kritisk lav- og avviks-alarm for å slippe indikasjoner på feil før nivået i tanken hadde kommet seg ut av alarmområdet. 2.3 Brukergrensesnitt, InTouch Utformingen og implementeringen av brukergrensenittet i InTouch ble gjort av Irja Gravdahl (Gruppe 1), Vebjørn Eklo (Gruppe 2) og Anders Lunde Engen (Gruppe 2). I oppgaveteksten står det spesifisert hva som skal være med i dette bruker- 25

27 grensesnittet: Et av skjermbildene skal inneholde et prosessbilde der det blant annet vises informasjon om pumpens tilstand, nivå i tankene, pådrag og alarmtilstander. Sanntidstrender over prosessen skal være tilstede. Historiske trender for begge tankene Innloggingsvindu, der tre operatører kan logge inn med forskjellige tilgangsrettigheter. Brukerne skal være OPERATØR1, OPERATØR2 OG OPERATØR3, med henholdsvis passordene Op1, Op2 og Op3 Alarmhåndtering (lesing og logging av alarmer, kvittering av alarmen til PLS). Mulighet for å endre på regulatorinnstillinger for begge tankene. Ved å ta utgangspunkt i entank-designet for begge gruppende, de overstående punktene for to tanker og informasjonen i tabell 2.3 med tilbakemeldingene fra entank var det klart for utbedring av brukergrensesnittet Arbeidsfordeling, koordinering og samarbeid [IG] Etter vel gjennomført prosjekt så langt for begge gruppene, satte vi oss ned og fordelte oppgaver jevnt mellom gruppene. Noe av det begge gruppende tok med seg videre, var umiddelbare tilbakemeldinger fra fremvisning av entank-delen. Når det kom til InTouch var hovedtilbakemeldingene til begge gruppene som følger: Tabell 2.3: Tilbakemeldinger fra entank Tilbakemeldinger på entankpresentasjon Tilbakemeldinger, Gruppe 1 Tilbakemeldinger, Gruppe 2 Flytende alarmområde Riktig skalering av samplingstiden, T s Pil som indikerer referansen Blinking av alarmlampene i InTouch Benevning på parametere For små rammer rundt knappene Pil som indikerer referansen Blinking av alarmlampene i InTouch Forklaring av grafene på alle sider Begge gruppene ønsket å forbedre sine brukergrensesnitt i henhold til tilbakemeldingene, så det å sy sammen det beste fra begge brukergrensesnitt samt å implementere tilbakemeldingene som ble mottatt sto i sentrum for utformingen. Da begge gruppende hadde fått grundig øvelse i bruk av InTouch gikk utformingen og opprettelsen av et nytt brukergrensesnitt godt. Det kom bidrag til designet fra begge gruppene og samarbeidet fungerte godt. 26

28 2.3.2 Design [IG] Figur 2.15: Skrive- og leserettigheter til InTouch Variabel Leses Skrives Operatør 1 Operatør 2 Operatør 3 Operatør 1 Operatør 2 Referanse til tank1 og tank2 X X X X X Nivå i tank1 og tank2 X X X Kp til regulator tank1 og tank2 X X Ti til regulator tank1 og tank2 X X U0 til regulator tank1 og tank2 X X Valg mellom P- og PI-regulator tank1 og tank2 Operatør 3 X X X KpFF til regulator tank1 X X TdFF til regulator tank1 X X NFF til regulator tank 1 X X Valg av foroverkoplingstype tank1. Ingen, P, D eller PD X X X Magnetventiler utløp X X X Utstrømming fra gjennomstrømmingsmåler Start/stopp tilstand til pumpe, tank1 og tank2 X X X X X X X X Auto/manuell tilstand tank1 og tank2 X X X X X Pådrag for tank1 og tank2 X X X X X Melding om alarmer fra tank1 og tank2 Kvittering av alarmer fra tank1 og tank2 X X X Samplingstid tank1 og tank2 X X X X Ved sammenslåing gruppe 1 og gruppe 2 og innføring av en ekstra tank, ble hovedutfordringen i InTouch å få samlet nesten dobbelt så mye informasjon på den samme plassen som gruppene hadde til disposisjon i miniprosjektet og entankdelen av prosjektet. For å gjøre dette så stilrent og oversiktlig som mulig gikk vi først igjennom det begge gruppene hadde gjort i entank, og hvordan gruppene hadde utformet brukergrensesnittene sine derifra forskjellig. Vi oppdaget raskt at tankemåten hadde vært relativt lik og dette tok vi til å bety noe positivt. Ved opprettelsen av brukergrensesnittet til totank tok vi da de beste løsningene fra begge grup- 27

29 pene, og satte de sammen. Innloggingsprosedyren ble lignende den i entank for begge gruppene. En knapp med teksten Logg inn inviterer brukeren til å klikke på knappen for deretter å skrive inn sitt brukernavn og tilhørende passord. Etter at dette er skrevet inn vises to knapper, en med Fortsett og en med Bytt bruker. Her kan man velge om man ønsker å fortsette som den brukeren man har logget seg på med eller om man vil skifte bruker. Figur 2.16: Innloggingsvinduet i InTouch; her vises muligheter for innlogging. Man logger inn og får mulighet til å fortsette eller endre bruker. Bildet viser også hvilken prosjektdel som omhandles og hvilke grupper som er involvert. Egenutformet logo (laget av Marius Loraas, Gruppe 1) ble også med på innloggingsvinduet nederst i venstre hjørne; det var enighet i at dette så bra ut og at vi ønsket å beholde dette. Om man velger Fortsett -knappen i innloggingsvinduet blir man sendt videre til bilde som heter Oversikt (i menylinjen) uavhengig av hvilken bruker som logger seg inn. Her vises tydelig oppbyggningen av prosessen til venstre, med to tanker, alle tilhørende ventiler, pumpe og vannreservoaret nederst på riggen. Det er tydelig merket hvilken tank som er 1 og 2, og tilhørende sanntidstrend vises til venstre i bilde slik som man ser i figur

30 Figur 2.17: Oversiktsvinduet i InTouch, tanken og sanntidstrender vises. For at det ikke skulle bli for mye informasjon og for lite plass, valgte vi å legge alle innstillinger angående reguleringen under fanen Regulator, her har man mulighet til å endre alt som er indikert i tabell Om man da velger fanen merket Regulator ser man de samme sanntidstrendene, også her med forklaring på hva som er hva, på nøyaktig samme plass. Overgangen fra oversiktsbildet er da kun at tankoppsettet er erstattet med innstillinger for tankene. Da kan man observere de samme linjene som i Oversikt når man bytter til Regulator, for deretter endre på innstillinger og se hvilke påvirkninger endringene kommer til å ha på de forskjellige forløpene. Det var bred enighet i at dette var en god løsning og at det ble nok plass til all informasjon som var nødvendig å ha med. Oppsettet for Regulator sees i figur Figur 2.18: Regulatoren i InTouch; her kan alle innstillinger for regulatoren, samt pumpen og utløpet styres. Dette er vinduet operatør 3 ser. 29

31 Under fanen Alarmtilstander har vi satt alarmloggingen for de to tankene side om side, tydelig merket. For begge tankene er det gitt mulighet for 6 forskjellige handlinger med tanke på kvittering; man kan kvittere Kritisk lav, Kritisk høy, Høyt nivå, Lavt nivå. Kvitter alle og Kommunikasjon. Alarmene kan enten kvitteres hver for seg, eller man kan velge å kvittere en og en etter eget ønske. Lampene blinker også med den intensiteten indikert i oppgaveteksten tilhørende normal alarm eller kritisk alarm. Oppsettet ble endret til at alarmene må kvitteres inne i fanen Alarmer. Vi tok en avgjørelse på at det var mest gunstig å samle lik informasjon på samme plass når såpass mye informasjon skulle presenteres i brukergrensesnittet på en gang. Figur 2.19: Løsningen på alarmhåndtering i InTouch. Alle alarmer kan her kvitteres, enten hver for seg, eller alle samtidig for en og en tank. Det gis også beskjed om det er problemer med kommunikasjonen. For å gi brukeren beskjed om at prosessen har gått inn (og/eller ut) av en alarmtilstand vises to lamper hele tiden i menylinjen. En for nivåfeil, altså om det er nivået som trenger operatørens oppmerksomhet, og en for kommunikasjon, for å vise at det er kommunikasjonen som trenger tilsyn. Deretter må operatøren klikke seg inn i alarmfanen for å få mer informasjon og kvittere den enkelte alarm der. Da vil all informasjon om alarmer vises og bearbeides i ett bilde. Om operatøren ønsker det kan man klikke seg inn i fanen Historisk trend for å se på prosessen forløp over en lengre tidsperiode. Også her ligger de historiske trendene side om side, med forklaring, slik at man enkelt kan sammenlikne og oberservere begge tankene. For enkelhets skyld er fargene alltid de samme på kurvene slik som indikert på bildene uavhengig av hvilken fane man er i. 30

32 Figur 2.20: Historisk trend for tank 1 og tank 2 side om side. I menylinjen vises alle fanene som tilhører prosessen. I høyre hjørne finner man Logg ut -knappen som tar operatøren tilbake til innloggingsvinduet for å enkelt kunne bytte bruker. Ved siden av denne knappen ser man også hele tiden hvilken operatør som er logget inn. For nøyktig gjennomgang av hvordan man gjennomfører opprettelsen av knapper, inntastingsfelt og andre aspekter ved brukergrensesnittet refererer vi til Miniprosjektrapport og Entankrapport for Gruppe 1 og Gruppe 2. Dette vil ikke bli gjennomgått her. Referanselinje [VE] Etter tilbakemeldinger under demo for entankprosjektet, ble det gitt ønsker av veilederne om en enklere måte å lese referansen på. For å realisere dette på en grafisk og brukervennlig måte, var idéen å legge en referanselinje over tankene slik som sett i figur2.23. Denne referanselinjen skal kunne bevege seg etter den gjeldende referansen, og samtidig vise denne verdien grafisk i forhold til tankenes høyde. Dette er mulig å gjennomføre ved å legge til en Touch Link på den markerte referanselinja, vist i figur Her er det nødvendig å få referanselinja til å følge tankens høyde. Dette blir gjort ved å huke av for Vertical under Sliders i figur Linja har nå mulighet for å bevege seg i vertikal retning. 31

33 Figur 2.21: InTouch, konfigurering av referanselinje Det er viktig å spesifisere hvor langt referanselinja har mulighet for å bevege seg i vertikal retning. Høyden til tanken er målt i antall pixler, vist som de svarte prikkene i fiur2.21. Avstanden mellom pixel 1 og pixel 2 har verdien 10. Dette gir tanken en høyde på 360. Plasseres referanselinja på 0% av tankens høyde, kan man i vinduet for Vertical Slider vist i 2.22, putte inn verdien 360 som det høyeste linja kan stige fra null. Nå er referanselinja knyttet til tankens høyde. Figur 2.22: InTouch, konfigurering av tag til referanselinje I figur 2.22 kan man se at det også er et felt som heter Value. Her er det viktig å skrive inn de samme verdiene som er brukt som skalering av referansen i tankene. I vårt tilfelle er skaleringen fra 0-100%. Det også ønskelig å lese verdien til referansen ved siden av linjen. Dette gjøres ved å legge til tekst som under Value Display blir knyttet til taggen for referanse i den gjeldene tanken. 32

34 Tekstboksen knyttes så til referanselinje som en celle. Det endelige resultatet er vist i figur Figur 2.23: InTouch, referanselinjen Windowscripts [IG] Enkelte ganger er ikke allerede innebygde funksjoner i InTouch nok, eller riktig, for det man ønsker å gjøre; dermed kan man innføre et eller flere script for å komplementere dette. Et tilfelle vi ønsker å trekke frem er hvordan foroverkoblingsbiten ble løst. Vi brukte samme fremgangsmåte som Gruppe 1 benyttet seg av i Entank (Løsningen er kommet frem til av Endre Bøen). Figur 2.24: Foroverkoblingsregulator De fire knappene man kan trykke på øverst i figur 2.24 er i utgangspunktet ikke koblet sammen, slik at flere kan være trykket inn samtidig. Det ble dermed opprettet en lokal tag i InTouch kalt Foroverkobling som ble brukt til å programmere disse knappene og inntastingsfeltene, for å få de til å prate med 33

35 hverandre og innføre avhengighet. Et utsnitt av skriptet følger: IF F oroverkobling == 0 T HEN dt ank1w F F T ype ddel OP CEntank = 0; dt ank1w F F T ype pdel OP CEntank = 0; ENDIF ; Her ser vi at om den interne taggen er funnet til å være lik 0, settes både P-del og D-del til 0. Dette er altså det som skjer når brukeren har markert knappen Ingen. Om Foroverkobling er funnet til å være 1, vil P-delen aktiveres, altså når brukeren har markert knappen P. Om brukeren markerer PD vil både P-delen og D-delen settes til 1, altså at de begge aktiveres. Dette ble en fin løsning på problemstillingen og det er enkelt for en bruker å benytte seg av Tagliste [IG] Ettersom designprosessen i InTouch er relativt brukervennlig var ikke dette vanskelig når vi var flere om jobben. Utveksling av ideer og meninger, ga et godt design på brukergrensesnittet. Når vi var fornøyd med utseende på brukergrensesnittet, var det tid for å opprette tagger i OPC server, importere gjennom OPCLink, binde opp til forskjellige knapper, inntastingsfelt, grafer og lys i InTouch og i PLS ene. Med tanke på at det var brukt forskjellige dataregister, minneceller, innganger og utganger, var det å sette sammen en ny komplett tagliste en liten utfordring. Det var enighet i at Gruppe 1 skulle bruke Tank 1 (den til venstre på riggen) med tilhørende foroverkobling og at samme gruppe skulle beholde programmet i Q00- PLS en (master). Dermed utgår foroverkoblingen til Tank 2 da utstrømningen ikke går gjennom strømningsmåleren på riggen. Taglisten til Gruppe 1 ble dermed veldig lik den i entank-del, med unntak av innføringen av et flytende alarmområde som var en mangel fra entankpresentasjonen. Programmet til Gruppe 2 ble også utbedret og sto ovenfor noen små endringer i PLS-programmet som påvirket hvilke adresser som skulle benyttes i brukergrensesnittene for å få de forskjellige komponentene til å samarbeide. Med tanke på utbedringer i begge program ble en ny tagliste, med noen av de samme taggene brukt i entank, opprettet i OPC server og importert med OPCLink. En komplett liste følger i figur 2.25 og

36 Figur 2.25: InTouch, Komplett tagliste 35

37 Figur 2.26: InTouch, Komplett tagliste Alarmhåndtering for to tanker [ALE] Et oversiktlig brukergrensesnitt er kun starten på et komplett produkt som kan brukes på vår prosess. Med to flytende alarmområder, forskjellig intensitet på blinkingen, kun én lampe og dobbelt opp av alt blir alarmhåndteringen den største utfordringen i vår oppfattelse. For å gjøre dette så oversiktlig som mu- 36

38 lig ble det først opprettet samme type struktur på taggene som skulle brukes i alarmhåndteringen for begge tankene. For eksempel indikerer begge taggene under samme tilstand, men for hver sin tank. Dette er taggen for at tanken har et lavt nivå på 25% fra referansen. T ank1r Low T ank2r Low Ved god organisering av taggene ble det å binde de til knapper og blinkende lys veldig greit, da vi kun satt opp alle komponenter for den ene tanken først, og deretter kopiere dette og erstattet et tegn i hver tag. Etter at designet var klart kunne taggene bindes opp; det første som måtte gjøres var å deklarere taggen som en alarmtilstand slk som i figur Figur 2.27: InTouch, Konfigurering av tagger. Her velges hvilken tag som skal konfigureres. Her må man huke av for Log Data, Condition må velges under ACK Model og Alarm State må velges til On for at det skal bli en alarmtag. Her kan man legge inn en kommentar til alarmen som vil dukke opp i alarmhistorikken. I og med at det nå skulle opprettes et alarmsystem for to tanker, måtte vi bestemme hvilke alarmtagger som skulle dukke opp i hvilket historisk alarm-vindu. Om det kun ble opprettet alarmtagger slik som det ble gjort i Entank og de ble bundet opp mot knappene, ville alle alarmene uavhengig av hvilken tank som fikk en alarmtilstand, dukke opp i begge vinduene. Dette er jo ikke det ønskelige scenarioet så vi tok i bruk Priority -funksjonen. Her tilegnet vi tank 1 prioritet 1, og tank 2 prioritet 2. Dette betyr ikke at alarmene for tank 2 er mindre viktige, kun at de dukker opp i alarmvinduet for tank 2 og ikke i tank 1. (se figur 2.28) Dette gjør brukeropplevelsen mye bedre, da det hele tiden er klart hvilken tank man har alarmtilstand på og at det er samsvar mellom hvilken alarm man kvitterer og i hvilket vindu de dukker opp. 37

39 På denne måten får man også et tydelig skille mellom de to tankene, men man opprettholder likevel full kontroll på begge tankene. Når man dobbelklikker på alarmhistorikkvinduet får man opp forskjellige alternativer til hva man ønsker å vise i historikken og ved hver alarm. Noen ting er allerede huket av, men det var viktig for gruppene at det kom tydelig frem hvilken alarm som er kvittert, ikke kvittert eller har oppstått. En tekst som beskriver hvilken alarm som har oppstått vil vises i alarmhistorikken om man huker av for Show Message. Dette vises i figur 2.28 Figur 2.28: Dette vinduet dukker opp når man dobbelklikker på alarmhistorikkvinduet. Her kan man huke av for Show Message for at en beskrivende tekst skal vises i alarmhistorikken. Her setter man også hvilken Priority vinduet skal bruke. Her er den satt til 1, dermed er dette vinduet for alarmer til tank 1. Opprettelsen av tagger sett i figur 2.27 må også tilegnes en prioritet for å knytte taggen til et av vinduene. Man kan også velge om nye alarmer skal komme nederst eller øverst i alarmhistorikken. Ved å velge Query type til Historical blir alarmene lagret etter at de er blitt kvittert. Hadde denne stått som Summary som er det andre alternativet, ville alarmene forsvunnet rett etter at de hadde blitt kvittert Når alarmene fungerte etter spesifikasjonene gitt i oppgaveteksten og alarmhistorikken ga riktige beskjeder var brukergrensesnittet nær ferdigstilling. Skalering av tagger (se Entankrapport gruppe 1, s Entankrapport gruppe 2, s. 35) ble utført der dette var nødvendig og oppsettet ble testet mot prosessen ved hjelp av testskjemaer utviklet av Vebjørn Eklo. 38

40 2.4 Brukergrensesnitt, ix Panel TA Arbeidsfordeling, koordinering og samarbeid [RW] I utviklingen av grensesnittet til ix-panelet møtte vi på nye utfordringer som vi ikke hadde på entankprosjektet. Flere personer var involvert, og ulike løsninger skulle kombineres til et felles resultat. For et godt læringsutbytte er det hensiktsmessig at begge gruppene er involvert i alle aspekter av prosjektet, og dette gjelder også ix-panelet. Når man oppretter et grensesnitt i ix developer, vil ikke arbeidet gå spesielt raskere dersom vi setter flere folk på jobben. Derfor måtte vi fordele oppgavene godt. Den overordnede planen ble utviklet i samarbeid. Vi sammenlignet løsningene våre og kom frem til hvilke funksjoner vi skulle beholde, samt hvordan de skulle sorteres utover ulike skjermbilder. Videre fikk gruppe 2 jobben med å utforme det visuelle på en ryddig og oversiktlig måte. Knapper, slidere og avlesningsvindu ble opprettet slik at det stemte med kravene i listen over hva som skal kunne leses og skrives. Gruppe 1 fikk ansvaret for å knytte knapper og funksjoner opp mot tags, slik at panelet kan kommunisere med PLS ene. Denne arbeidsfordelingen ble valgt fordi gruppe 1 også har ansvaret for programmet i master-plsen, og det er nettopp denne enheten panelet har direkte kontakt med. Siden det er mange måter å løse et enkelt problem på, er det viktig at de som jobber med PLS og de som utformer grensesnittet har oversikt over hva motparten trenger for å få sin del av styringen til å fungere Innledning [SRA] og [PL] Programmet utviklet i ix Developer utvides fra en til to tanker. Gruppene som benytter seg av tank-rigg 1 skal i samråd skape et grensesnitt basert på to tanker. Sammen arbeidet vi med å utvikle et operatørpanel med en syntese av gruppenes beste løsninger. Veien frem til sluttproduktet basert på programmets design vil bli forklart i de kommende avsnittene. Vi ble raskt enige om å hovedsakelig benytte oss av prosjektgruppe 2 sin løsning av operatørbrukergrensesnittet fra entank-prosjektet (se entankrapport til prosjektgruppe 2 for innsikt i hvordan brukergrensesnittet i utgangspunktet så ut). Det var en rekke endringer som vi var nødt til å gjøre. I tabell 1, som er hentet fra oppgaveteksten, er en rekke krav til brukergrensesnittet satt. For eksempel skal det være mulig å både skrive og lese referansen i begge tankene. Melding om alarmer skal bare kunne leses og ikke skrives. I vårt sluttprodukt er alle krav implementert på det vi mener er en funksjonell og intuitiv måte. 39

41 Figur 2.29: Skrive- og leserettigheter til ix Panel TA100 Variabel Skrives Leses Referanse til tank1 X X Referanse til tank2 X X Manuelt pådrag til tank1 X X Manuelt pådrag til tank2 X X Omstilling fra manuelt pådrag til automatisk nivåregulering for tank1 Omstilling fra manuelt pådrag til automatisk nivåregulering for tank2 Pådrag for tank1 Pådrag for tank2 Nivå i tank1 Nivå i tank2 Melding om alarmer fra tank1 Melding om alarmer fra tank2 Kvittering av alarmer fra tank1 Kvittering av alarmer fra tank2 X X X X X X X X X X X X Start/stopp pumpe 1 X X Valg av brukergrensesnitt [SRA] og [PL] Ved å ta utgangspunkt i tidligere program kom vi raskt i gang med utforming av design for det nye programmet. Som sagt ville vi beholde utseende på grensesnittet fra prosjektgruppe 2. Det viste seg å være en stor utfordring å designe de ulike vinduene på en enkel og oversiktlig måte når vi i denne delen benytter oss av to tanker. Operatørpanelet er betraktelig mindre i fysisk størrelse enn en PC-skjerm, noe som fører til at vinduet fort blir overfylt. Totalt inneholder grensesnittet fire skjermer; Hjem (innlogging), Prosess, Trend og Alarmer. I innloggingsvinduet (se figur 2.30) er det ikke gjort endringer sammenlignet med entankprosjektet. Det er fremdeles kun mulig å logge seg inn på en bruker, Operatør1, med op1 som passord. 40

42 Figur 2.30: ix-panel, innlogging Generelt sett fokuserte vi på tydelige knapper og tekst med størrelse. Det skal være enkelt å både se og trykke seg rundt på panelet. Vi valgte kun å ha med funksjoner/variabler som er spesifisert i figur Ingen ekstra funksjoner ble implementert. Dette på grunn av et ønske om å gjøre det så oversiktlig som mulig med det som var nødvendig. Med ekstra funksjoner vil det resultere i mindre plass og/eller flere vinduer, noe som igjen vil gjøre programmet mindre oversiktlig. Det mener vi gir et mindre brukervennlig program med et forverret estetisk uttrykk. Vi ønsket at vinduene skulle inneholde informasjon om begge tankene for enkel sammenligning. På den måten er nivået i både tank 1 og tank 2 simulert på panelet. Referansen kan leses og skrives, mens pådraget er satt til å kun leses ( Read Only i ix Developer). Regulatormodus kan settes til auto eller manuell. Når modusen er i manuell vil det være mulig å skrive manuelt pådrag. I automatisk modus kan dette feltet kun leses av brukeren. Start og stopp av pumpen er plassert i et felt som symboliserer at det gjelde begge tankene. Det er kun en pumpe på tank-riggen som styrer all strømning av vannet. Viktigheten av et tydelig grensesnitt er meget vesentlig. Fremstillingen av de to tankene skal gjøre at brukeren enkelt kan se hvilke innstillinger som tilhører henholdsvis tank 1 og tank 2. Dette ble løst ved å tilordne blokker med egen overskrift for de forskjellige tankene og ved å plassere justeringsmulighetene innenfor disse. Hvordan dette ble løst er visualisert i figur

43 Figur 2.31: ix-panel, prosessvindu Vi utvidet trendvinduet på samme måte som prosessvinduet. Trendvinduet inneholder nå en historisk trend for både tank 1 og tank 2. Her var det et stort fokus på å designe vinduet slik at grafene ble størst mulig i format. Vi konkluderte med at dette var en grei størrelse (se figur 2.32), særlig ettersom vi har gjort det mulig å skalere x- og y-aksen. På x-aksen skaleres tiden, mens på y-aksen skaleres den normaliserte verdien (0-100%). Således kan man zoome inn om man ønsker et mer tydelig bilde på prosessen. Innstillingene kan stilles på for tank 1 og tank 2 uavhengig av hverandre, ettersom nivået i tankene opptrer divergerende. Figur 2.32: ix-panel, trendvindu Alarmvinduet består av varsellamper, kvitteringsknapper og en boks for alarmhistorikk (se figur 2.33). Det er lagt et tydelig visuelt skille mellom alarmene for tank 1 og tank 2. Gruppene hadde løst alarmproblematikken på ulike måter tidligere med tanke på kvitteringsmuligheter. Det var et spørsmål om det var nødvendig å kvittere forskjellige typer alarmer hver for seg, eller om det holdt med en knapp for å kvittere alle alarmer. For kun en tank kunne det vært greit med en knapp for å kvittere alle alarmer, men for to tanker ble vi demokratisk 42

44 enige om at det burde være mulig å kunne kvittere hver og en alarm for seg. Det er også det mest logiske i og med at alarmene opptrer uavhengig og tar utgangspunkt i forskjellige tanker. Med andre ord, en kvitter alle knapp når vi arbeider med to uavhengige tanker er ikke særlig hensiktsmessig. I den anledning ble det opprettet to felter med kvitteringsmuligheter for tank 1 og tank 2. For å bruke arealet på operatørpanelet mest mulig effektivt ble alarmhistorikken koblet opp mot begge tankene, slik at alle utløste alarmer havnet i samme liste. Fra entank-grensesnittet valgte vi å fjerne fargeforklaringen ved ulike tilstander. Implementeringen av dette i grensesnittet var rett og slett ikke plass til. Det er nok at statusen til alarmen vises i alarmlisten (Venstre kolonne State ). Hver tilstand er knyttet opp mot en farge. I tabell 2.4 er tilstanden med tilhørende farge i alarmlisten forklart. Tabell 2.4: Tilhørende farger til tilstander i alarmliste Tilstand NORMAL ACTIVE INACTIVE ACKNOWLEDGE Farge Hvit Rød Oransje Grønn Under alarmhistorikklisten er det lagt inn to kvitteringsknapper og stautslamper for profibustilkoblingen til slave 1 og slave 2. Nappes profibustilkoblingen ut, skifter lampen farge fra grønn til rød. Figur 2.33: ix-panel, alarmvindu 43

45 Figur 2.34: ix-panel, menylinje En gjennomgående menylinje (figur 2.34) er en effektiv måte å gi oversikt i et program. Vi velger her en enkel menylinje med store og tydelige knapper. For mer informasjon angående oppsett av menylinje, se entankrapport fra prosjektgruppegruppe 2, kapittel 4.5. Alarmknappen i menylinjen har en ekstra funksjon utenom å sende brukeren til alarmvinduet. Denne knappen vil i tillegg fungere som en alarmindikator, og vil være synlig fra hvilket som helst vindu. Ved utløsing av en alarm, vil knappen begynne å blinke. Dette symboliserer at alarmvindu krever oppmerksomhet. Knappen vil fortsette å blinke helt til operatøren har klikket seg inn på alarmvinduet, kvittert alarmen og fått fjernet alarmtilstanden. Blinkingen samsvarer med lampen på tank-riggen. Den lyser med en periode på 1 sekund når det er et avvik på 25% i en av tankene, en periode på 0,4 sekunder ved kritisk alarm og knappen skal ha fast lys når en/alle alarm(er) er kvitterte men ikke ute av sin tilstand Tags [RW] En tag er en merkelapp som henviser til minneceller i PLS en. Man gir taggene navn som er lettere å huske enn en minnecelle-adresse. Ved å knytte tagger opp mot knapper eller andre objekter, kan man endre verdien i minnecellene. Dermed får man muligheten til å kontrollere PLS en fra grensesnittet. I figur 2.35 kan man se den komplette taglisten vår. Navn til taggene er valgt slik at det skal være lett å holde oversikt. Første ord beskriver plasseringen til taggen. Det er fire ulike plasseringer: Tank 1, tank 2, master og lokal. 44

46 Figur 2.35: Tagliste for totankprosjektet Tank 1 og tank 2 har et identisk utvalg tags. I utgangspunktet hadde vi et ulikt antall tags siden vi hadde ulike løsninger. Den største forskjellen var i alarmhånteringen hvor gruppe 1 hadde en felles tag for kvittering av alle alar- 45

47 mer, mens gruppe 2 hadde individuelle kviteringsknapper. Det var også et skille i hvilke oppgaver som ble tildelt PLS og panelet. Gruppe 1 brukte Gain i ix Developer til å oversette verdier til prosent, mens gruppe 2 tok denne utregningen i PLS. Gruppe 1 brukte også noen enkle skript i situasjoner hvor to eller flere tags skulle styre et enkelt objekt, mens gruppe 2 utførte denne logikken i PLS slik at man hadde én bestemt tag å forholde seg til i ix Developer. I totankprosjektet har vi kommet fram til en felles løsning, slik at det eneste som skiller de to tankene, er en liten forskjell i gain som skyldes ulik handtering av heltallsproblematikk. T ags med navn som starter med Master, gjelder for funksjoner som finnes i master-pls, eller som er felles for begge tanker. F.eks er det master-plsen som oppdager at den har mistet kontakt med en av slavene, og setter profibus alarmen høy. M aster Kritisk tilstand, M aster Alarmtilstand og Master Alarmkvittert Feil vedvarer er koblet til mineceller i masteren som bestemmer om alarmlampen på riggen skal lyse, blinke sakte eller blinke raskt. Master- PLSen ser på alarmtilstanden i begge tankene og bruker denne informasjonen til å styre lampen. Disse taggene benyttes til å lage den samme blinkeeffekten på alarmknappen i menyen. Pumpen styres derimot av slave 1, men siden det er en funksjon som har felles effekt på begge tankene, har den blitt merket som en Master tag. T aggene med navn som starter med lokal, har ikke noen tilknytning til PLSen. Man kan likevel tildele de verdier, som kan leses senere. En lokal tag blir altså som en liten lagringsplass. Det er seks lokale tags som brukes av trendvinduene som man kan se på figur Dette er for å styre tidsvindu, minimumverdi og maksverdi. Disse verdiene er ikke relevante for PLSene, men må likevell knyttes opp mot en tag dersom man skal kunne endre dem etter behov. Dette gjelder også for Lokal Ack prof ibus, som kvitterer alarmen som oppstår dersom man mister kontakt med en slave-pls. Selv om denne alarmen oppstår i PLS, trenger den ikke å kvitteres der for å forsvinne. Så snart systemet har gjenoprettet kontakt, vil alarmen settes til 0. Alarmen må likevel kvitteres i alarmloggen, og derfor er det opprettet lokale tags til dette. Lokale tags er også nyttig for å lage enkel logikk. Man kan bruke flere tags som har tilknyttning til PLSen, og utføre regneoperasjoner der resultatet lagres i en lokal tag. Lokal alarm avvik styrer alarmlampen som skal lyse ved for store avvik (se figur 2.33). Det er to slike lamper. En for hver tank. PLSen har to separate alarmflagg for avvik slik at man vet om nivået er for høyt eller for lavt. For å spare plass i alarmvinduet, har vi kombinert disse to tilfellene til en felles lampe for avvik. Det er likevel mulig å se nøyaktig hva som skjedde ut fra alarmloggen. Verdien til den lokale avviksvariabelen blir utregnet i et skript ved å kjøre en OR-operasjon på alarmene for høyt og lavt nivå. I entankrapporten til gruppe 1 s. 67 er det beskrevet hvordan man oppretter slike skript Alarmhåndtering [RW] Vi har fortsatt å bruke ix Developer sin ferdige løsning for håntering av alarmer. I alarmvinduet i figur 2.33 vil alarmene vises i 5 ulike farger ettersom hvilken status de har. Rød farge med meldingen Active betyr at alarmflagget er høyt. Gul farge med meldingen Inactive betyr at alarmen har tidligere vært høy 46

48 uten å bli kvittert. Grønn farge med meldingen Acknowledged betyr at alarmen fortsatt er høy, men har blitt kvittert. Hvit farge betyr at alarmen har vært aktiv, men er borte og kvittert. I praksis vil ikke meldingen Inactive oppstå veldig ofte. Dette er fordi alarmflaggene for nivå holdes høy i PLSen helt til de blir kvittert. Det er bare profibusalarmen som kan komme og gå uten kvittering. En Inactive melding på en av alarmene for nivå vil derfor bety at panelet har vært avslått mens alarmene ble kvittert. I figur 2.36 kan man se alarmlisten vår. Figur 2.36: Alarmliste I alarmlisten legger man inn de taggene som indikerer alarmer. Man kan bestemme hvilken verdi som skal utløse alarmen. For vanlige alarmflagg vil verdien 1 utløse alarm, men man kunne i prinsippet lagt til nivå-taggen i alarmlisten og få den til å indikere alarm på et gitt nivå. I vårt prosjekt befinner denne logikken seg i PLS, og vi forholder oss bare til verdier på 1 og 0. Vi har fire ulike nivåalarmer for hver tank, i tillegg til alarmer som oppstår når man mister kontakt med slavene. Alarmene har også mulighet for å kvitteres fra et annet grensesnitt. I kolonnen Remote Acknowledge, ser man listen over tags som vil kvittere en alarm dersom de går høy. Kvitteringsknappene på figur?? er koblet opp mot disse taggene, og dermed får vi kvittert alarmene hver for seg. 2.5 Fjernstyring av ix-panel over web [ML] Da gruppene kom sammen og skulle avgjøre på hvilken måte vi ville oppfylle kravet i oppgaven om at tanken skulle kunne fjernstyres over web, så vi at gruppene hadde valgt to forsjellige løsninger for dette. Gruppe 1 hadde valgt en løsning der det eksisterende brukergrensesnittet på ix-panelet ble fjernstyrt i nettleseren, mens gruppe 2 hadde utviklet et tredje brukergrensesnitt i HTML og Javascript som kjørte på ix-panelets webserver. Valget falt på å videreføre løsningen der ix-panelets eksisterende brukergrensesnitt blir fjernstyrt. Årsaken til dette er at vi anser det som resursbesparende å slippe å utvikle et tredje brukergrensesnitt i HTML-kode, når det allerede 47

49 fins et flott grensesnitt som med enkle midler kan pressenteres i en nettleser for brukeren. Vi satte nok en gang opp en Raspberry PI som proxy i mellom ix-panelet og nettleseren til brukeren, for a eliminere den utdaterte javaklienten pa ix-panelet. Figur 2.37: Raspberry PI er en liten datamaskin basert pa ARM-arkitektur, som kan kjøre Linux. Med sin lave pris (230,- KR) og solid-state-arkitektur uten vifter og andre mekaniske slitbare deler, er denne svært godt egnet til a løse sma problemer i prosessindustrien. Raspberryen kobler til ix-panelets VNC-server, og pressenterer dette skjermbildet til brukeren over HTTP ved hjelp av HTML5, slik at man slipper problemene som Java ofte fører med seg. HTML5 er støttet av alle moderne nettlesere, ogsa mobiltelefoner og nettbrett. Programvaren som ble benyttet til dette forma let heter novnc og kjører pa det Debian-baserte operativsystemet Raspbian. Figur 2.38: Logisk fremstilling av hvordan de forsjellige delene av systemet utveksler data for fjernstyring av ix -panelet over internett. Raspberryen ligger som en mellomtjener mellom brukerterminalen og ix -panelet, slik at VNCklienten som pressenteres for brukeren er oppdatert og ikke genererer javafeilmelding. 48

50 VΩ A AnalogInput Power Supply Filter i praksis [ML] I tidligere rapporter har betraktningene rundt filterene i stor grad vært bassert på matematiske modeller og teoretiske beregninger. Vi tenkte det hadde vært spennende å gjøre et sett målinger og se om den faktiske oppførselen er slik som forventet. Vi tok for oss filteret for nivåmåleren til gruppe 1, og koblet dette opp i en målerigg basert på National Instruments NI mydaq. Oppsettet er vist i figuren under. AUDIO IN AUDIO OUT Figur 2.39: NI mydaq sett fra siden, med de forsjellige tilkoblingsmulighetene NI mydaq USB Current Limiter DC-toDC Converter ±15 V 5V SystemTiming Controller Digital Input/Output DIO Digital Multimeter Analogto-Digital Converter Digitalto-Analog Converter AnalogOutput Gain Switch Multiplexer AO AI AUDIOIN AUDIOOUT VΩ A NI mydaqsystemdiagram In Vcc Out Analog ICs suppliedb y GND 60 V 20 Vrms MAX HI COM HI 1 A MAX Figur 2.40: Oppsettet av måleriggen for filteret som viser hvordan tilkoblingen ble utført. Måleinstrumentet NI mydaq ble så tilkoblet en PC, og programvaren NI EL- VISmx Bode Analyzer (en del av LabVIEW) ble benyttet. Filteret påtrykkes automatisk en serie av frekvenser og responsen på utgangen av filteret blir målt og logget. Datagrunnlaget ble importert i Matlab og plottet i samme graf som den teoretiske modellen for filteret. 49

51 Phase (deg) Magnitude (db) 0 Bode Diagram Frequency (Hz) Figur 2.41: Her ser vi hvordan det fysiske filteret (rødt) følger den teoretiske modellen (blå) inntil operasjonsforsterkeren når metning Dessverre er det en begrensning i måleutstyret som gjør at vi kun får målt i området Hz. Imidlertid ser vi at i det området vi fikk målt, følger filteret den teoretiske modellen svært godt, inntil operasjonsforsterkerens båndbredde blir begrensende faktor. 50

52 2.6 Testskjemaer Testskjema, InTouch [VE] Tabell 2.5: Testskjema, alarmer InTouch, tank 1 Testskjema, alarmer i InTouch, tank 1 Nr Tilstand Status Kommentar 1 Alarm tank 1: Kritisk høyt nivå. Blink med høy frekvens OK 2 Alarm tank 1: Kritisk lavt nivå. Blink med høy frekvens OK 3 Alarm tank 1: 25% avvik over referansen på 60%. Blink med middels frekvens 4 Alarm tank 1: 25% avvik under referansen på 60%. Blink med middels frekvens 5 Alarm tank 1: Kvittert alarm kritisk høyt, med tilstand utenom alarmnivå. Hvit alarmlampe 6 Alarm tank 1: Kvittert alarm kritisk lavt, med tilstand utenom alarmnivå. Hvit alarmlampe 7 Alarm tank 1: Kvittert alarm kritisk høyt, fortsatt alarmtilstand. Fast alarmlys 8 Alarm tank 1: Kvittert alarm kritisk lavt, fortsatt alarmtilstand. Fast alarmlys 9 Alarm tank 1: Kvittert alarm 25% avvik over referanse på 60%, med tilstand utenom alarmnivå. Hvit alarmlampe 10 Alarm tank 1: Kvittert alarm 25% avvik under referanse på 60%, med tilstand utenom alarmnivå. Hvit alarmlampe 11 Alarm tank 1: Kvittert alarm 25% avvik over referanse på 60%, fortsatt alarmtilstand. Fast alarmlys 12 Alarm tank 1: Kvittert alarm 25% avvik under referanse på 60%, fortsatt alarmtilstand. Fast alarmlys OK OK OK OK OK OK OK OK OK OK 13 Alarm tank 1: Kvitter alle alarmer OK 51

53 Tabell 2.6: Testskjema, alarmer i InTouch, tank 2 Testskjema, alarmer InTouch, tank 2 Nr Tilstand Status Kommentar 1 Alarm tank 2: Kritisk høyt nivå. Blink med høy frekvens OK 2 Alarm tank 2: Kritisk lavt nivå. Blink med høy frekvens OK 3 Alarm tank 2: 25% avvik over referansen på 60%. Blink med middels frekvens 4 Alarm tank 2: 25% avvik under referansen på 60%. Blink med middels frekvens 5 Alarm tank 2: Kvittert alarm kritisk høyt, med tilstand utenom alarmnivå. Hvit alarmlampe 6 Alarm tank 2: Kvittert alarm kritisk lavt, med tilstand utenom alarmnivå. Hvit alarmlampe 7 Alarm tank 2: Kvittert alarm kritisk høyt, fortsatt alarmtilstand. Fast alarmlys 8 Alarm tank 2: Kvittert alarm kritisk lavt, fortsatt alarmtilstand. Fast alarmlys 9 Alarm tank 2: Kvittert alarm 25% avvik over referanse på 60%, med tilstand utenom alarmnivå. Hvit alarmlampe 10 Alarm tank 2: Kvittert alarm 25% avvik under referanse på 60%, med tilstand utenom alarmnivå. Hvit alarmlampe 11 Alarm tank 2: Kvittert alarm 25% avvik over referanse på 60%, fortsatt alarmtilstand. Fast alarmlys 12 Alarm tank 2: Kvittert alarm 25% avvik under referanse på 60%, fortsatt alarmtilstand. Fast alarmlys OK OK OK OK OK OK OK OK OK OK 13 Alarm tank 2: Kvitter alle alarmer OK 52

54 2.6.2 Testskjema, ix Panel TA100 [SRA] og [PL] Tabell 2.7: Testskjema, ix Panel TA100 Testskjema, ix Panel TA100 Tankrigg nr: 1 Gruppe nr: 1 & 2 Test utført av: Dato: Nr Testbeskrivelse OK/ikke OK Kommentar 1 Innlogging Operatør1 OK 2 Start/stopp pumpe OK 3 Tank 1: Lese og skrive referansen OK 4 Tank 1: Omstilling fra manuell til auto OK 5 Tank 1: Lese og skrive manuelt pådrag OK 6 Tank 1: Lese automatisk pådrag OK 7 Tank 1: Sammenligne nivået i tanken med nivået på operatørpanelet OK 8 Tank 1: Kvittere alarmer OK 9 Tank 1: Avviksalarm: 25% over referanse OK 10 Tank 1: Avviksalarm: 25% under referanse OK 11 Tank 1: Kritisk alarm: Nivå over 90% OK 12 Tank 1: Kritisk alarm: Nivå under 10% OK 13 Tank 1: Kritisk alarm: Lys blinker 0.2 sek av og 0.2 sek på 14 Tank 1: Avvik alarm: Lys blinker 0.5 sek av og 0.5 sek på 15 Tank 1: Etter oppstart skal det ta 15 sek før en alarm skal vises 16 Tank 1: Fortsatt alarmtilstand, men kvittert gir fast lys OK OK OK OK 17 Tank 1: Profibustilkobling OK 18 Tank 2: Lese og skrive referansen OK 19 Tank 2: Omstilling fra manuell til auto OK 20 Tank 2: Lese og skrive manuelt pådrag OK 21 Tank 2: Lese automatisk pådrag OK 53

55 Nr Testbeskrivelse OK/ikke OK Kommentar 22 Tank 2: Sammenligne nivået i tanken med nivået på operatørpanelet OK 23 Tank 2: Kvittere alarmer OK 24 Tank 2: Avviksalarm: 25% over referanse OK 25 Tank 2: Avviksalarm: 25% under referanse OK 26 Tank 2: Kritisk alarm: Nivå over 90% OK 27 Tank 2: Kritisk alarm: Nivå under 10% OK 28 Tank 2: Kritisk alarm: Lys blinker 0.2 sek av og 0.2 sek på 29 Tank 2: Avvik alarm: Lys blinker 0.5 sek av og 0.5 sek på 30 Tank 2: Etter oppstart skal det ta 15 sek før en alarm skal vises 31 Tank 2: Fortsatt alarmtilstand, men kvittert gir fast lys OK OK OK OK 32 Tank 2: Profibustilkobling OK 54

56 Kapittel 3 Bonusoppgave, Gruppe 1 Gruppe 1 har utført 2 bonusoppgaver i samråd med veileder. Det ble gitt tillatelse til å legge ved den ene bonusoppgaven som vedlegg på grunn av sidebegrensning. Bonusoppgaven som omhandler PID-blokken i GW Works 2 finnes dermed som første vedlegg og er utført, testet og skrevet i sin helhet av Albert Danielsen [AD]. Se avsnitt 5.1 under Kapittel 5 Vedlegg. 3.1 Frekvensomformer Så tidlig som i forprosjektet skulle vi ta stilling til om gruppen hadde lyst å prøve seg på en bonusoppgave. Valget falt lett på frekvensomforming, fordi dette er en mye brukt teknologi i mange forskjellige sammenhenger i blant annet industrien. I tillegg virket dette som den mest utfordrende oppgaven. I prosjektet så langt har reguleringen bestått av å regulere åpningen til en servostyrt reguleringsventil, ved å sende et pådragssignal (4-20mA) fra PLS en til servoen. Reguleringsventilen er en av de største, om ikke den største, tregheten i prosessen. Den bruker omtrent 13 sekunder på å åpne fullt, og oppfører seg lineært. Ved å benytte frekvensregulering av pumpen for å styre innstrømning i tanken, står inn-ventilen konstant med 100% åpning. Derfor regner vi med at reguleringen vil bli betydelig bedre og raskere, enn med regulering av åpningen til ventilen Kommunikasjon [EB] Ved regulering av ventilen ble pådraget fra regulatoren i PLSen (0-255 bit) omsatt gjennom DA-omformeren til et styresignal på 4-20 ma som bestemte ventilåpningen. Med frekvensomforming vil kommunikasjonen skje direkte fra PLS til frekvensomformeren via PROFIBUS. Derfor måtte frekvensomformeren (Danfoss VLT 2800) legges til som et nytt ledd på PROFIBUS-konfigurasjonen. Dette gjøres enkelt ved å laste ned en GSD-fil fra hjemmesiden til Danfoss, og legge den til i GX Configurator DP. 55

57 GSD-filen (general station description) gir en beskrivelse av hva enheten er for noe, og informasjon om hvilke innganger og utganger som er tilgjengelig. Figur 3.1: Det er meget viktig at boksen Swap I/O Bytes in Master hukes av fordi frekvensomformeren leser ordene omvendt fra hvordan PLS en gjør det. Ved å bytte om rekkefølgen på de to bytesene (1 byte = 8 bit) i wordet som sendes, endres hva som oppfattes som LSB. I tillegg må man velge hvilken metode/oppsett kommunikasjonen skal forgå på. Vi valgte den miste kommunkasjonstypen, type 3, der vi får fire 16-bits ord til disposisjon, to ord opp og to ord ned (se Operating Instructions, Profibus DP V1, pdf.-fil funnet under Prosjektperm på ItsLearning). De to ordene som blir sendt til frekvensomformerern er CTW (control word) og MRV (main reference value). Det er disse to ordene styrer frekvensomformeren. I tillegg får vi tilbake to ord STW (status word) og MAV (main actual value), som gir oss en status på driften av frekvensomformeren. Det er CTW som bestemmer om statusen til frekvensomformeren. Dette kontrollordet er bygd opp på følgende måte: 56

58 Figur 3.2: For å starte frekvensomformeren må = skrives til CTW. Skal den stoppes, skrives = til CTW PLS-programmet [EB] Vi tok utgangspunkt i programmet vårt fra entankprosjektet, men det måtte gjøres noen endringer for å ha muligheten til å regulere frekvensen. Vi har ikke slettet delen for regulering av ventilen, bare lagt til en vekslemulighet mellom de to forskjellige pådragsorganene Master-programmet [EB] Det er master PLSen som har oppgaven å videreformidle beskjeder fra slaven til frekvensomformeren. Derfor opprettet vi en liten programbit som faktisk sjekker om hvilken slave som skal ha kontroll og tilgang til å regulere frekvensomformeren. Figur 3.3: Masterlogikk Det ble opprettet et flagg som heter Drive.TokenAddress. Dette bestemmes av master PLS en, og kan gi forskjellige enheter tilgang til frekvensomformeren. I vårt tilfelle er det slave 1 (som har posisjon 1 i Profibusnettverket) som skal ha kontroll over den. Derfor sammenligner vi om Drive.TokenAddress er lik 1, og dersom dette kravet er oppfylt, vil frekvensregulering starte. 57

59 Blokken BMOV sender Tank1 rprofi.vlt2800 CTW og Tank1 rprofi.vlt2800 MRV til frekvensomformeren. MRV inneholder verdien som regulatoren i slaven regnet ut, og vil sette frekvensen til omformeren Slave-programmet [EB] Det er slaveprogrammet som bestemmer hvilken frekvens pumpen skal kjøres på. Regulatoralgoritmen kjører fortsatt, og regner du et pådrag som må gis for at nivået skal komme seg til referansen. Ved frekvensomforming må pådraget fra regulatoren skaleres slik at et pådrag korresponderer med riktig frekvens på pumpe. Dette gjøres i figur 3.4. Figur 3.4: Slavelogikk Her kommer pådraget dpådrag inn fra regulatoren, og blir multiplisert med 100 for mer nøyaktighet i frekvensutregningen. For å få en så hurtig regulering som mulig, kom vi frem til at ved 0% pådrag fra regulatoren, skulle frekvensomformeren ha en dødgangsfrekvens på 24.0 Hz. Dermed ville det ta kortere tid før pumpen faktisk begynner å levere vann (vi kom frem til at ved ca 24.5 Hz vil pumpen begynne å levere vann inn i tanken). For å få realisert dette kom vi frem til at skaleringen i figur 3.4 fungerer perfekt. Pådraget til frekvensomformeren blir sendt via ordet MRV (main reference value). Formel for utregning: P ådrag frekvensomformer = P ådrag regulator ( ) 301 Først deler vi pådraget fra regulatoren ( ) på 301 slik at tallområdet blir skalert ned til , som er halvparten av frekvensomformerens arbeidsområde ( Hz). 58

60 Grunnen til at trekkes fra, er for å dra frekvensen ned til 0 Hz. Vi fant ut at tilsvarer en frekvens på ca 38.2 Hz (hastigheten pumpen kjørte på under entank). Denne tallverdien kommer fra spenningen 6.8V som blir satt over motstandene på baksiden av riggen legges til for å få en dødgangsfrekvens på 24.0 Hz ved 0 pådrag fra regulatoren. Dermed vil pådraget til frekvensomformeren være fra til 3842, noe som vil gi Hz Brukergrensesnitt [EB] og [RW] Brukergrensesnittene i bonusoppgaven byggere videre på det som ble gjort i entankprosjektet, men det måtte gjøres noen modifikasjoner slik at bonusoppgavene ble implementert. Vi har for så vidt to bonusoppgaver som måtte implementeres i brukergrensesnittene. Den ene var frekvensomformeren, og i tillegg skulle vi undersøke hvordan den ferdiglagde PID-regulatorblokken i GX Works2 fungerer, samt sammenligne den med en egenprodusert PID-algoritme. InTouch [EB] Siden vi valgte å beholde muligheten for å veksle mellom reguleringsventilen og frekvensomformeren som pådragsorgan, måtte dette legges inn i brukergrensesnittet. Dersom vi bruker reguleringsventilen som pådragsorgan, vil utseende i InTouch være omtrent identiske med det som ble laget for entank. Dersom frekvensregulering velges, vil pådraget som vises være frekvensen Hz gjort om til %. Ventilåpning vil vise 100%, samt at det kommer opp visningsfelt for momentanfrekvensen til frekvensomformeren. I tillegg fjernet vi valget mellom P- og PI-regulator, og byttet det ut med valget mellom å bruke vår reguleringsalgoritme for en PID-regulator eller bruke GX Works2 sin PID-blokk. Vi la også inn en alarmmelding for frekvensomformeren som blir håndtert på samme måte som nivåalarmene (se Entank, InTouch og Alarmhåndtering). I tillegg ble det utbedret noen få ting som ble påpekt under demonstrasjonen for entank: Implementerte flytende nivåalarm (± 25% fra referansen), fjernet statiske alarmindikasjoner på forskjellige grafiske fremstillinger. Riktig skalering av T s. Flytende pil som indikerer referansen i de forskjellige trendvinduene. Blinkende alarmlampe 59

61 Figur 3.5: Bonusoppgave, InTouch ix Panel [RW] Det har blitt gjort noen små justeringer i programmet til ix panelet for å vise frem frekvensstyrt regulering og bruk av GX Works2 sin ferdige PID-blokk. Vi benyttet også annledningen til å gjøre noen justeringer på ting som ble påpekt under presentasjonen av entankprosjektet. I entankprosjektet hadde vi inkludert muligheten til å justere regulatorparameter på ix panelet, noe som ikke sto oppført i listen over ønskede skrive- og leserettigheter. Dette er nå fjernet, og erstattet med indikasjonslamper som viser regulatorens status. På figur 3.6 ser man resultatet av denne endringen. Figur 3.6: Regulator i manuell og auto for bonusoppgave På prosess-skjermen har vi inkludert informasjon om hvilken frekvens pumpen kjøres på. Ventilstillingen settes også automatisk til 100% når tanken frekvensstyres. Prosesskejamet har blitt endret for å vise at regulatoren har kontroll over pumpen. 60

62 Figur 3.7: Prosess-skjerm for bonusoppgave Konklusjon [EB] For å gi et inntrykk over hvor bra regulering med av frekvensomformeren fungere, valgte vi å sammenligne reguleringen med de to forskjellige pådragsorganene. Innstillingene vi brukte på regulatoren vår var de samme for begge situasjonene for å få et godt sammenligningsgrunnlag. Parameterne som ble brukt, var de vi fant som mest gunstige i entankprosjektet. Ved sprang i magnetventiler fra 3 til 1 ventiler åpne, var det egentlig ikke så stor forskjell. At 2 magnetventiler lukker, har egentlig såpass lite å si for utløpet, at begge tilfellene hentet seg bra inn. Ved kjøre et sprang i referansen derimot, fikk man virkelig se hvor effektiv frekvensomformeren er i forhold til reguleringsventilen. I grafen under ble det påført et sprang i referansen fra 30% til 60% med 3 magnetventiler åpne. Vi la så begge sprangene inn i samme graf, slik at referansespranget kom på likt tidspunkt. 61

63 Figur 3.8: Sprang i referanse for ventilregulering (rød) og frekvensomformer (blå) Der er lett å se at frekvensomformeren er mye bedre enn reguleringsventilen både når det gjelder dynamisk avvik, innsvingningsløp og innsvingningshastighet. En annen ting som er bedre med frekvensomformeren er selve strømningen den gir. Mens vi regulerte med ventilen som pådragsorgan, gikk pumpen på konstant 38.2 Hz. Dette gjorde at dersom vi åpnet alle magnetventilen og manuellventilen, klarte ikke pumpene levere nok vann til at nivået holdt seg på en referanse på f.eks 60%. Med frekvensregulering derimot, kan pumpen gå med en frekvens på 50 Hz, og hadde null problem med å holde en stabil referanse med absolutt maks av utløp. 62

64 Kapittel 4 Bonusoppgave, Gruppe PID-instruksjonen + PID Settings [MVF] På prosjektmøte 4 ble vi tipset om at det var mulig å velge PID-instruksjonen i GX som en bonusoppgave, noe som ikke var nevnt i oppgaveteksten. I tillegg fikk vi utdelt en PDF-fil med instruksjoner for oppsett av PID-blokken fra en Melsec FX-programmering manual på norsk. Oppgaven ville da gå ut på å sette opp PID-blokka og få den til å fungere, i tillegg til å skrive litt om hvordan oppsettet virker. Etter at vi var ferdig med entank-prosjektet tenkte vi at det hadde vært interessant å se hvor bra den ferdige regulator-instruksjonen i GX ville fungere, så vi valgte denne oppgaven som bonusoppgave. Vi hadde akkurat begynt samarbeidet på totank-prosjektet der vi valgte å styre tank 2. Utløpet på tank-2 er styrt av en manuell ventil uten strømningsmåler, og siden PID-instruksjonen ikke har direkte mulighet for foroverkobling tenkte vi at det passet bra å bruke denne regulatoren på både totank og som bonusoppgave. Selve oppsettet av PID-instruksjonen er veldig enkelt når man først har fått det til. I starten brukte vi en del tid på å sette oss inn i hvordan oppsettet fungerte. Det er tre innganger på blokken der referanse, tank nivå og samplingstid settes, og en utgang som er pådragsverdien som skal sendes til reguleringsventilen. Adressen til samplingstiden er viktig fordi regulatoren leser av denne adressen og bruker de neste 24 adressene til regulatorinnstillinger, interne verdier, pådragsgrenser og alarmer. F.eks. brukte vi adressen D100 som samplingstid og regulatoren bruker da adressene D100-D124 til de forskjellige funksjonene. D100 - samplingstid D101 - Innstillinger b0 - Direkte/Reversert b5 - Aktivering av grenser for pådrag D102 - Inngangsfilter D103 - K p 63

65 D104 - T i D106 - T d D122 - Øvre grense for pådrag D123 - Nedre grense for pådrag I begynnelsen fikk vi ikke regulatoren til å fungere som vi ønsket. Pådraget låste seg og hoppet inn og ut av verdiområdet vi ønsket. Vi prøvde med det samme verdiområdet som AD/DA-omformeren som var 0-255, men dette fungerte ikke. Deretter prøvde vi å bruke hele området til PID-instruksjonen som var ±32767, og dette fungerte bedre, men da møtte vi et nytt problem. Om nivået i tanken var høyere enn referansen og pådraget ut fra regulatoren gikk til , hoppen den helt til andre enden av skalaen og opp til Vi prøvde å tvinge pådraget ut fra regulatoren, men det virket som det interne pådraget og det forrige pådraget ikke var det samme som vi brukte ut fra regulatoren, og pådraget hoppet etter hvert ut av området vi hadde limitert og fortsatte med å leve sitt eget liv. Vi hadde oversett en viktig del i manualen der det stod at vi også hadde mulighet til å tvinge de interne pådragene til å holde seg innenfor vårt ønskede område, men vi fant en løsning ved hjelp av manualen FX Series Programming manual der det stod noen tips om GX-regulatoren. Ved å aktivere bit 5 i adressen D101 var det mulig å sette en øvre- og nedre grenseverdi for pådraget ut fra regulatorblokken i adressene D122 og D123, som vist i figur 4.1. Dette løste problemene vi hadde med verdiområdet, og det var nå mulig å regulere tanknivået. Figur 4.1: Tabell over PID-regulatoren 64

66 Vi var veldig usikre på hvilke regulatorinnstillinger vi skulle bruke. K p -verdien hadde verdiområdet fra 0 til 32767, og skalering var ikke nevnt, men vi fant etter hvert ut at det måtte bety at regulatoren brukte to desimaler, og den reelle verdien gikk fra 0 til 327,67. Samplingstiden var oppgitt i millisekunder, I-tiden som x100 millisekunder og T d som x10 millisekunder og etter mye prøving og feiling med forskjellige verdier fant vi ut hvilket område vi burde legge oss på. Siden tank-2 er forskjellig fra tank-1 og regulatorventilen er pneumatisk, i motsetning til den motor-styrte ventilen på tank-1, fikk vi veldig forskjellige verdier, men mye raskere innsvingningsforløp enn på entank-prosjektet. Vi endte opp med K p = 2 og T i = 20sek, som tilsvarer K p = 200 og T i = 200 inn til selve regulatorblokken. I-tiden vi fant syns vi var litt høy, men fungerte også veldig bra og det var det viktigste. Figur 4.2: PID-innstillinger, gruppe 2 Noe som var rart med regulatorblokken var at det ikke eksisterte en mulighet for et nominelt pådrag ved P-regulering. Dette var noe vi måtte legge til pådraget etter regulatoren, men det fungerte dårlig og pådraget jaget opp og ned. Løsningen ble å legge til det nominelle pådraget etter regulatoren, for så å fjerne det igjen før det kom inn på regulatoren igjen. Som en liten konklusjon kan vi si at PID-instruksjonen i GX fungerer utmerket og er veldig enkel å sette opp når man først vet hvordan. Manualene man finner på nettet er en smule tvetydige, men når man først får limitert pådraget til et verdiområde går resten stort sett fint. Det viste seg at denne regulatoren fungerte bedre enn den vi laget selv, og selv om at reguleringsventilen i tanken vi bruker nå er mye raskere, er nok selve regulatoren også mye raskere. D-delen i regulatoren fungerte dårlig på dette systemet. Ved lav T d ble innsvingningsforløpet bortimot like raskt, men reguleringsventilen jaget mye mer, så vi bestemte oss for å ikke fokusere veldig på PID-regulator, men heller PI-regulator. 65

67 Figur 4.3: Innsvingningsforløp 66

68 Kapittel 5 Vedlegg Etter avtale med veileder for gruppe 1, Pål Gisvold, ligger den andre bonusoppgaven til gruppe 1 vedlagt her på grunn av sidebegrensning i hovedrapporten. Gruppe 1 har dermed løst 2 bonusoppgaver; utforsket PID-blokken i GX Works2 og frekvensstyrt prosessen. 5.1 Bonusoppgave: GX Works PID-blokk, Gruppe 1 [AD] Innebygd i GX Works 2 eksisterer det allerede en funksjonsblokk som fungerer som PID-regulator. Virkemåten til denne blokka ble undersøkt, samt sammenliknet med regulatoren vi allerede har implementert fra entankprosjektet. Konklusjonen er at det er mulig å implementere den som en fungerende regulator for vårt system, selv om det krever litt fininstilling. I anledningen lagde vi også en derivatdel til PID-regulatoren vår, slik at vi kunne sammenligne GX Works blokka, med vår regulator Blokkens funksjon [AD] Blokken har fire innganger og én utgang. Den første inngangen er EN, som trenger en høy verdi inn for å aktivere regneoperasjonene i blokken. Den andre og tredje inngangen, s1 og s2, er ment som input for referanse og prosessverdi, respektivt. Den siste inngangen er s3, som er input for en liste bestående av 25 etterfølgende dataregister(word). Resultatet av regneoperasjonene kommer 67

69 ut på utgangen, d. Dette er et WORD som svarer til pådrag ut fra regulatoren. Ved å sammenligne referanse og prosessverdi er blokken i stand til å regulere på et fysisk system Blokkens formler [AD] Akkurat som regulatoren gruppe 1 implementerte i entankprosjektet er regulatoren vi finner her på inkrementell form, dvs. den regulerer på endring og det totale pådraget blir summen av alle foregående pådrag. Regulatorblokka har mulighet for aktiv og reversert modus. Dette kommer godt med i en PLS, her er det uønsket å regne med negative verdier. Derfor kan man velge modus slik at man etter behov kan bruke pådrag for å holde prosessverdien nede, eller for å øke den. I vårt tilfelle er det åpning av en reguleringsventil som er pådrag(denne er fail to close), derfor er det reversert modus som gjelder. y > r : Aktiv modus : avvik(e) = prosessverdi(y) ref eranse(r) (5.1) r > y : Reversert modus : avvik(e) = ref eranse(r) prosessverdi(y) (5.2) I aktiv modus kjøres denne formelen: Der derivatdelen ser slik ut: D = u(k) = K p [(e e(k 1)) + T s T I e(k) + D] (5.3) T D K d T d (2y(k 1) y(k) y(k 2)) + D(k 1) (5.4) T s + K d T d T s + K D T D Parametere: K P : Proporsjonal forsterkning T s : Samplingstid T I : Integrasjonstid T D : Derivasjonstid K D : Filterkoeffisient(derivatdelen) D(k 1) : Forrige derivasjonsverdi e(k 1) : Forrige avviksverdi u(k) : Pådragsverdi y(k 1) : Forrige prosessverdi y(k 2) : Prosessverdi for to sampler siden Med regulatoren i reversert modus endres fortegnene i derivatdelen: D = T D K d T d ( 2y(k 1) + y(k) + y(k 2)) + D(k 1) (5.5) T s + K d T d T s + K D T D 68

70 Prosessverdien inneholder et filter for systemer med prosessverdi som er plaget av støy. α er en faktor som vekter dette filteret fra 0 til 100 %, slik kan man velge hvor stor innvirkning denne filtreringen skal ha. 0 % vil si at prosessverdien leses rett ut og brukes i utregningen av pådrag. y(k) er filtrert prosessverdi, y(k) uf er ufiltrert. y(k) = y(k) uf + α(y(k 1) y(k) uf ) (5.6) Som stadfestet tidligere er PID-blokken på inkrementell form, dvs. pådragsverdien som regnes ut er ikke det faktiske pådraget som skal sendes, men kun endring i ønsket pådragsverdi. Derfor summeres alle endringer i pådrag før de blir sendt som en reell pådragsverdi på utgang, d. Faktisk prosessverdi = Bruk av blokken [AD] u(k) (5.7) For å ta i bruk blokken er det litt forarbeid som skal til. Inngangene s1 og s2 må først få inngangene sine referanse og prosessverdi respektivt. Referanseinngangen er grei nok, her sender man et WORD inn som kan styres inne i PLS, eller evt. fra et operatørpanel. Prosessverdien kommer helst fra et fysisk system og da gjerne gjennom en AD-omformer, slik får man en referanseverdi som kan styres av en operatør, i tillegg til en prosessverdi som er tilbakemelding fra noe fysisk. Inngangen, s3, krever litt mer jobb utenfor PID-blokken. Den skal lese 24 WORD som alle må være reservert i PLS-programmet. Se tabell 5.1. På grunn av dette må dataceller velges for reservering og de må pakkes på en god måte. Å bruke GX Works sin egen datastruktur er kanskje den beste. Å strukturere det slik gir en fornuftig måte å pakke alle 24 WORDene i en liste. For å ta i bruk blokken mest effektivt har vi i prosjektet tatt utgangspunkt i god datahåndtering, før ting så ledes inn i blokken. Samtidig har vi tatt i bruk de samme taggene fra operatørpanelene som vi brukte i entankprosjektet og totankprosjektet. De må konverteres fra DOUBLEWORD(32 bit) til WORD(16 bit) fordi det er det PID-blokka bruker. t=0 69

71 Tabell 5.1: PID parametere Tidsintervall for sampling. Bør Param. Navn Beskrivelse Verdiområde S 3+0 Samplingstid 1 til T s settes lik en faktor av systemets msec totale skanntid. f.eks 1 skanntid, 2 skanntid, osv. S 3+1 Alarmkontroll bit0: direkte(0)/reversert(1) bit1: Prosessverdialarm(1) bit2: Pådragsverdialarm(1) modus S 3+2 Filter for prosessverdi α Bestemmer filterets innvirkningsgrad 0 til 99%. Forsterkning Bestemmer den proporsjonelle for- 1 til 32767%. S 3+3 S 3+4 S 3+5 S 3+6 S 3+7 til S 3+19 K P Integrasjonstid T I Derivasjonskonstant K D Derivasjonstid T D S 3+20 Maks for prosessverdi S 3+21 Minimum for prosessverdi S 3+22 S 3+23 Maksendring (positiv) for pådragsverdi Maksendring (negativ) for pådragsverdi sterkningen i regulatoren Bestemmer integrasjonstiden for regulatoren. Sett denne lik 0 og integrasjonsleddet kobles ut Bestemmer hvor stor innvirkning derivatdelen har i regulatoren Derivatdelens derivasjonstid. Sett denne lik 0 og derivatleddet kobles ut Reservert for mellomregninger Dette er en maksgrense operatøren kan sette. Et alarmflagg, S 3+24 bit0, vil gå høyt om nivået overstiger denne verdien Dette er en minimumsgrense operatøren kan sette. Et alarmflagg, S 3+24 bit1, vil gå høyt om nivået blir lavere enn denne verdien Brukerdefinert maksgrense for positiv endring som kan skje i pådragsverdien. S 3+24 bit2 går høy hvis dette skjer Brukerdefinert maksgrense for negativ endring som kan skje i pådragsverdien. S 3+24 bit3 går høy hvis dette skjer S 3+24 Alarmflagg Beskrevet i S 3+20 til S 3+23 (0 til 32767) 100 msec. 1 til 100%. (0 til 32767) 10 msec 0 til til til til

72 Figur 5.1: Programutsnitt som viser hvordan tagger som vi har brukt tidligere i prosjektet gjenbrukes i GX Works PID blokk. Verdiene som ligger i datacellene for referanse og prosessverdi må gjøres om fra 32bits DOUBLE WORD til 16bits WORD. For det er dette området PID-blokka arbeider i. Samme operasjon blir gjort for alle dataceller fra entank. Samplingstida blir skalert opp med en faktor på 10. Figur 5.2: Programutsnitt som viser hvordan integrasjonsleddet kan kobles inn eller ut. Når RegData.RegType[0](I-ledd av eller på) er aktiv, kjører I-leddet i den matematiske utregninga. Samme metode som er vist i figur 5.2 er også inkludert for D-delen av regulatoren. På denne måten gjør man det mulig å velge mellom alle mulige regulatorkombinasjoner; P, PI, PD og PID. Noen innstillingsmuligheter ønsket vi å holde konstante, da vi testa PID-blokka på vår prosess. Dette gjelder parameterne: maks og minimumendring på prosessverdien, samt maks Figur 5.3: Maksverdi for prosessverdi og minimumendring på pådragsverdien. Eksempel på dette kan sees i figur 5.3 der maksendring på prosessverdien settes til 10% av vårt måleområde på bits. 71

73 Om man skulle ønske å bare kopiere den filstrukturen som er brukt i dette eksempelet henvises det til vedlegget ved denne rapporten. Figur 5.4: PID-blokka er i vår prosjektoppgave implementert på denne metoden. Øverst ser man PID-blokka og dens innganger, som består av referanse, prosessverdi og bufferet med sine 24 WORD(se tabell 5.1). Under blokka kommer en liten bit med logikk som sørger for at pådragsverdien er i samme område som det vi har brukt tidligere i prosjektet Testing og Konklusjon [AD] Ved testing av blokken og dens funksjon ble gode reguleringsparametere funnet. Forsterkning, P = 2 Integrasjonstid, I = 5 Derivasjonstid, D = 1 samplingstid, T s = 100 Prosessverdifilter α = 10 Denne blokka er noe mer konservativ enn den vi har laget selv og finpusset på igjennom entank- og totankprosjektet. Etter prosjektenes slutt var vi veldig fornøyde med de regulatorene vi laget ved diskretisering av laplaceformler, mer om dette kan leses om i entankrapporten til gruppe 1. Med de beste innstillingene vi klarte å finne for vår regulator sammenlignet med de beste innstillingene for GX Works egen PID-blokk vil vi konkludere med at vår regulator fungerer bedre for vårt system. Men ta i betraktning at vi kjenner vår egen regulator bedre, vi har brukt mer tid på å finjustere den og det kan hende den er bedre egnet for akkurat denne typen system. 72

74 5.2 Komplettering av Entankrapport, Gruppe 1 [MAA] Uheldigvis bla ca. 2 sider tilhørende entankrapporten til gruppe 1 ikke med. Dette omhandlet PLS-programmet og er skrevet av Morten Andre Astad. Dette følger under Bruk av PROFIBUS brukerdiagnostikk [MAA] Som en del av alarmhåndteringen, har vi valgt å bruke den innebygde løsningen i PROFIBUS DP for brukerlagd statusinformasjon, og utstyrsdiagnose. Denne funksjonaliteten er tilgjengelig for slave-pls ved bruk av bufferminne #28 for brukerdiagnostikk i PROFIBUS-slave. Dette er et status-word som sender et høyprioritert datatelegram med egenlagd statusinformasjon, og PROFIBUS diagnoseinformasjon som innpakning, ved statusendring. Det er med andre ord mulighet for 16 bit med egenkonstruerte statusflagg, tilgjengelig i PROFIBUSslaven som brukes i prosjektet. Figur 5.5: Deklarering av strukturert datatype FeilStatus av type FX0N- DP UserDiagnostics med egenkonstruerte statusflagg for bruk i programlogikk, og sending over PROFIBUS. Her fremgår både mellomlageret buffer som brukes for sending til PROFIBUS, og de enkle minnecellene som utgjør mellomlageret, og blir kopiert til mellomlageret før sending til PROFIBUS. 73

75 Figur 5.6: Sending av feilstatus til PROFIBUS gjøres på samme måte som vanlig data sendes i miniprosjektet, bortsett fra at det nå skrives til bufferminne #28 for brukerdiagnostikk. Se figur 5.19 i miniprosjektrapport, for hvordan kommunikasjon med PROFIBUS-slave blir utført. Master-PLS programmet følger stort sett de samme designfilosofiene som i miniprosjektet, hvor den stort sett fungerer som et dumt mellomledd for videreformidling av data, med minst mulig bruk av logikk. Det er likevel behov for å innføre logikk i forhold til håndtering av diagnoseinformasjon fra tilkoblede PROFIBUS-slaver. Når det oppstår feil i en slave, blir statusflagget til slaven høyt, og diagnoseinformasjon blir lagret i et FILO-register (First In Last Out), som kan sammenlignes med et samlebånd hvor ny diagnoseinformasjon går inn i den ene enden, og gammel går ut i den andre enden. Når det blir statusendring i de brukerlagde statusflaggene til slaven, så dukker det opp feilinformasjon i master-pls, med feilkode 512. Denne feilkoden er en generell feilkode, som inneholder generelle feilflagg for PROFIBUS. Blant disse feilflaggene befinner det seg et feilflagg for ytterlig diagnoseinformasjon, og gir om feilinformasjonen inneholder diagnoseinformasjon som ikke er i henhold til PROFIBUS standarden, slik som vår brukerlagde diagnoseinformasjon. Det er bare plass til ytterlig diagnoseinformasjon for en slave av gangen, og det er dermed nødvendig å kopiere til et lokalt mellomlager. Figur 5.7: Kopiering av ytterlig diagnoseinformasjon til lokalt mellomlager. Ytterlig diagnoseinformasjon er strukturert som bytes (8-bit), hvor WTOBinstruksjonen (Word to Byte) omgjør fra WORD med 2 bytes til to WORD, for å tilgjengeliggjøre diagnoseinformasjonen med riktig format. Denne koden kjører når et generelt feilflagg for alle slaver blir høyt, og ytterlig diagnoseinformasjon er tilgjengelig. Ytterlig vurdering av feilinformasjonen blir vurdert på slave-basis, men for vår del er det nok å tilgjengeliggjøre de brukerlagde statusflaggene i et lokalt mellomlager. 74