Rapport Entank. Prosjekt i emnet «Styresystemer og reguleringsteknikk» Gruppe 01. Høgskolen i Sør-Trøndelag

Rapport Entank Prosjekt i emnet «Styresystemer og reguleringsteknikk» Gruppe 01 Høgskolen i Sør-Trøndelag 2015

Sammendrag (Skrevet av TM) Entank-prosjektet er en del av et større prosjekt som går i vårsemesteret i emnet «Reguleringsteknikk og styresystemer» for 2EA. Formålet med oppgaven er å regulere nivået i en tank etter gitte kriterier og ved hjelp av det utstyret vi har blitt tildelt fra skolen. Rapporten beskriver detaljert hvordan vi har programmert regulatorer i PLS, kommunikasjonen mellom de forskjellige enhetene, og flere løsninger på brukergrensesnitt. I tillegg til rapporten kommer et simuleringsnotat som vedlegg, hvor modellering, simulering og uthenting av regulatorparametere er beskrevet. Hovedresultatet har blitt en tank med en velfungerende nivåregulering med et innsvingningsforløp av typen «minimum forstyrrelse». Vi har fungerende og oversiktlige brukergrensesnitt, og i tillegg en webserver man kan lese og skrive noen verdier fra. Parameterne fra simuleringsnotatet ga et innsvingningsforløp på riggen som gjenspeilte resultatene fra simuleringen. Erfaringer vi har gjort oss er viktigheten av rekkefølgen av aksjonene i PLS-programmet, regulering med heltallsaritmetikk, og at man må være påpasselig med å ha god oversikt over adresser som blir brukt og oppdaterer disse forløpende. I PLS har kan vi velge om vi skal regulere med P-, eller PI-regulator. I tillegg har vi konstruert P-, D- og PD-foroverkobling. Best resultat oppnådde vi med PI-serieregulator med PD-foroverkobling. De beste innstillingene vi kom frem til er: PI-reg: P: 5.5 I-tid: 4.2 sekunder PD-foroverkobling: P: 0.7 D-tid: 0.3 Kravet gitt i oppgaveteksten var et innsvingningsforløp av typen minimum areal. Vårt innsvingningsforløp er av typen «minimum forstyrrelse». Vi har prøvd hardt å oppnå «minimum areal», men har konkludert med at dynamikken til selve utstyret er et hinder til å oppnå dette. Forord (Skrevet av TM) Denne prosjektrapporten representerer «Entank»-delen i prosjektet som holdes hver vår i emnet «Reguleringsteknikk og styresystemer» for 2EA. Vi i gruppe 1 retter vår takk til de ansatte og våre medstudenter ved HiST AFT - Program for elektrofag. Gjennomføringen av prosjektet har vært lærerikt og utfordrende, vi har alle fått kjent på mestringsfølelsen. Det har vært lærerikt fordi vi har fått konkretisert mye av det vi hadde i forelesninger tidligere i år. Man kan si at prosjektet har gitt oss flere knagger å henge klærne på. Det har vært utfordrende fordi mye av programvaren har vært ny for oss, og fordi vi ikke har lagd et PLSprogram som har vært så omfattende tidligere i utdanning. Vi vil rette en spesiell takk til vår veileder På Gisvold for den hjelpen vi har fått.

Innholdsfortegnelse 1.0 Innledning... 2 1.1 Bakgrunn... 2 1.2 Utstyr, programvare, definisjoner og forkortelser... 2 1.2.1 Forkortelser... 2 1.2.2 Definisjoner... 3 1.2.3 Utstyr... 4 1.2.4 Software... 4 1.3 Hjemmeside... 5 2.0 Teknisk del... 7 2.1 Problemstilling... 7 2.2 Prosessbeskrivelse... 8 2.2.1 Flytskjema... 8 2.2.2 Bilder av systemet... 9 2.2.3 Kommunikasjon... 11 2.3 Antialiasing filter... 12 2.4 Regulatoralgoritmer... 16 2.5 PLS programmering (EB)... 20 2.5.1 Master-PLS... 22 2.5.2 Slave-PLS... 27 2.5.3 Serieregulator... 31 2.5.4 Foroverkobling... 35 2.5.5 Alarmhåndtering... 39 2.6 HMI programmering... 43 2.6.1 OPC-server og tagger... 43 2.6.2 Design InTouch... 45 2.6.3 Design ix-panel... 49 2.6.4 Alarmhåndtering InTouch... 54 2.6.5 Alarmhåndtering ix-panel... 57 2.6.6 Operatørnivåer og rettigheter... 58 2.6.7 Web-grensesnitt for ix panel... 62 2.7 Simulering... 64 2.7.1 Serieregulering... 64 2.7.2 Foroverkobling... 66

3.0 Innregulering... 68 3.1 Krav til reguleringen... 68 3.2 Manuelle innjusteringsmetoder... 68 3.3 Serieregulering... 69 3.4 Foroverkobling... 70 3.5 Parametere fra simulering... 71 4.0 Testskjema... 72 4.1 Operatørpanel... 72 4.2 InTouch... 72 4.3 PLS... 73 5.0 Prosjektgjennomføring, erfaringer og konklusjon... 74 5.1 Prosjektgjennomføring... 74 5.2 Erfaringer og forslag til forbedringer... 74 5.3 Konklusjon... 75 6.0 Vedlegg... 1 6.1 PLS program Master... 1 6.2 PLS program Slave... 1 6.3 Simuleringsnotat... 1

Figur liste Figur 1 Eksempel kildekode hjemmeside... 5 Figur 2 Eksempel CSS hjemmeside... 5 Figur 3 Eksempel formattering hjemmeside... 5 Figur 4 Hjemmeside... 6 Figur 5 Flytskjema... 8 Bilde 1 PLS-rigg... 9 Bilde 2 Tankrigg... 10 Bilde 3 Tankrigg bakside... 10 Figur 6 Kommunikasjon... 11 Figur 7 Kretsskjema antialiasing filter... 12 Figur 8 Bode diagram filter... 13 Figur 9 Kobling MultiSim filter... 14 Figur 10 Sprang 1 til 5 volt filter MultiSim... 14 Figur 11 Ferdig filter... 15 Figur 12 Karakteristikk AD/DA omformer... 17 Figur 13 Prinsipp P-reg foroverkobling... 18 Figur 14 Prinsipp D-reg foroverkobling... 18 Figur 15 Prinsipp PD-reg foroverkobling... 19 Figur 16 MOV blokk... 20 Figur 17 TO blokk... 20 Figur 18 FROM blokk... 20 Figur 19 LD blokk... 21 Figur 20 PLS / PLF blokk... 21 Figur 21 Kontakt positiv flanke... 21 Figur 22 PLS initiering status... 22 Figur 23 PLS Flytte fra data til enkelte bit... 22 Figur 24 PLS enkelt Bit til Data... 23 Figur 25 PLS Flytte til batterimatede minneceller... 23 Figur 26 PLS Flytte parametre til Profibus... 23 Figur 27 PLS Start/Stopp pumpe... 24 Figur 28 PLS Auto/Manuell... 24 Figur 29 Velge P/PI regulator... 25 Figur 30 PLS valg av foroverkobling... 25 Figur 31 PLS Valg av utløp / Magnetventiler... 26 Figur 32 PLS Status magnetventiler... 27 Figur 33 PLS Slave struktur... 27 Figur 34 PLS Slave til/fra Master... 28 Figur 35 PLS Status bit sendes via Dataregister... 29 Figur 36 PLS Aksjoner mottatt fra Master... 29 Figur 37 PLS Styring utganger Slave... 30 Figur 38 PLS Skriv/les AD/DA slave... 30 Figur 39 PLS P-regulator... 31 Figur 40 PLS P-regulator algoritme - mellomregning... 31 Figur 41 PLS Grensesjekk og pådrag... 32

Figur 42 PLS Av/På P-regulator... 32 Figur 43 PLS PI-regulator... 33 Figur 44 PLS PI mellomregning 1... 33 Figur 45 PLS PI mellomregning 2... 33 Figur 46 PLS PI grensesjekk og pådrag... 34 Figur 47 PLS PI-reg pådrag... 34 Figur 48 PLS Foroverkobling... 35 Figur 49 PLS Foroverkobling P-Reg pådrag... 35 Figur 50 PLS Foroverkobling D-Reg endring av Kp til 1... 36 Figur 51 PLS Foroverkobling D-Reg... 36 Figur 52 PLS Foroverkobling pådrag D-del... 36 Figur 53 PLS Foroverkobling PD-Reg... 37 Figur 54 PLS Pådrag til DA-omformer... 37 Figur 55 PLS Manuelt pådrag... 38 Figur 56 PLS Rykkfrie overganger... 38 Figur 57 PLS Samplingstid... 38 Figur 58 PLS Revers/Direkte regulering... 39 Figur 59 PLS Status Profibus... 39 Figur 60 PLS funksjonsblokk Alarmer... 40 Figur 61 PLS Alarm 25% under ref.... 40 Figur 62 PLS Alarm Kritisk lavt nivå... 40 Figur 63 PLS Alarmer tidsbegresning... 41 Figur 64 PLS Alarmer Tidsforsinkelse... 41 Figur 65 PLS Alarmer Kvittering... 41 Figur 66 PLS Alarmlampe blink... 42 Figur 67 PLS Alarmlampe... 42 Figur 68 PLS Alarmer kvittering... 42 Figur 69 OPC Tag liste... 43 Figur 70 OPC Tag eksempel skalering... 44 Figur 71 InTouch Nivå tag... 45 Figur 72 InTouch Plassering av referanse... 46 Figur 73 InTouch Reguleringsventil... 46 Figur 74 InTouch Pumpe... 46 Figur 75 InTouch Animering pumpe... 47 Figur 76 InTouch Animering rør/ventil... 47 Figur 77 InTouch display av verdier... 47 Figur 78 InTouch Regulator parametere... 48 Figur 79 InTouch Knapper utløpsventiler... 48 Figur 80 InTouch Knapper... 48 Figur 81 InTouch Trender... 49 Figur 82 ix-panel Navigasjonsmuligheter... 50 Figur 83 ix-panel Nivåindikator... 51 Figur 84 ix-panel Actions til knapper... 51 Figur 85 ix-panel Trendvindu... 52 Figur 86 ix-panel Trendkurver oppsett... 52 Figur 87 ix-panel Skjermbilde Instillinger... 53 Figur 88 ix-panel Indikatorfarger... 53

Figur 89 InTouch Alarmtag... 54 Figur 90 InTouch Alarmvindu... 54 Figur 91 InTouch Kvitterings script... 55 Figur 92 InTouch Alarmknapp animering... 55 Figur 93 InTouch Oppsett blinking alarm... 56 Figur 94 InTouch Alarm indikatorer... 56 Figur 95 ix-panel Alarmvindu... 57 Figur 96 ix-panel Alarmserver... 57 Figur 97 ix-panel innlogging... 61 Figur 98 ix-panel operatørnivåer... 61 Figur 99 ix-panel Webgrensesnitt... 62 Figur 100 ix-panel HTML kode eksempel... 62 Figur 101 Simulering Serieregulering... 64 Figur 102 Simulering Ziegler-Nichols... 64 Figur 103 Simulering Etterjustering... 65 Figur 104 Simulering Etterjustering... 65 Figur 105 Simulering Forenklet foroverkobling... 66 Figur 106 Simulering Modell for foroverkobling... 66 Figur 107 Simulering Innsvingningsforløp med PD-foroverkobling... 67 Figur 108 Manuell selvjustering... 69 Figur 109 Serieregulering... 69 Figur 110 Foroverkobling... 70 Figur 111 Test av parametere... 71

Gruppedeltakere Prosjektgruppen består av følgende medlemmer Eyvind E. Bjørsland Allmenn 90915799 Eivind_eb@hotmail.com Anders Aabakken Elektriker 95992849 a.aabakken@gmail.com Magnus K. Bergsbakk Fagbrev sveiser 99026094 magnus438@hotmail.com Øyvind Eklo Automatiker 92894293 o_eklo@hotmail.com Torbjørn Morken Prosesstekniker 45272224 torbjornmorken@gmail.com Veileder Pål Gisvold er veileder for prosjektgruppen Han jobber som Høgskolelektor ved avdeling for teknologi ved HiST, ved program for elektro- og datateknikk. Mail: pal.gisvold@hist.no

1.0 Innledning 1.1 Bakgrunn (Skrevet av ØE) Det har blitt en tradisjon at studenter i 4. semester ved Elektro- og datateknikk, med valgt spesialisering automatisering, kjører et prosjekt i emnet «Styresystemer og reguleringsteknikk». I dette prosjektet skal vi prøve ut teorien vi har lært tidligere i semesteret i praksis. «Entank» er hoveddelen av prosjektet. Prosjektet omhandler alle de tre hoveddelene i emnet, reguleringsteknikk, sanntids datateknikk og PLS-/HMI-programmering. Prosjektet teller 40% av karakteren i emnet «Styresystemer og reguleringsteknikk». Klassen er delt inn i seks prosjektgrupper, som igjen består av fem eller seks studenter. 1.2 Utstyr, programvare, definisjoner og forkortelser 1.2.1 Forkortelser (Skrevet av MB) HiST OPC PC PLS HMI PID AD DA ma V Kp Ti Td HTML WAN Høgskolen i Sør-Trøndelag Object Linking and Embedding for Process Control. Personal computer Programmerbar logisk styring Human-Machine-Interface Proporsjonal-, Integral- og Derivat-regulator Analog til digital Digital til analog Milliampere Volt Forsterkning Integrasjonstid Derivasjonstid HyperText Markup Language Wide Area Network Skolens nettverk i vårt tilfelle Side 2 av 75

1.2.2 Definisjoner (Skrevet av MB og ØE) HMI Brukergrensesnitt for skriving og lesing til prosessen. BUS Kommunikasjonssystem for overføring av data. Profibus-DP Feltbuss kommunikasjonsstandard brukt innen automatikk InTouch Verktøy for programmering av HMI. IEC International standards and conformity. HTML Programmeringsspråk som kan brukes for å kode hjemmesider. CSS «Cascading Sheet Styles» formateringsspråk til HTML PID-regulator P-regulator: Sørger for å endre pådraget proporsjonalt med avviket. PI-regulator: I-delen (integratordelen) har i oppgave å gjøre det stasjonære avviket lik null. PD-Regulator: D-delen (derivatdelen) har i oppgave å redusere det dynamiske avviket. Den gir ingen bidrag til stasjonært avvik. Stasjonært avvik Forskjellen mellom referanse og måling ved stabilt system. Dynamisk avvik Det største avviket fra referansen i et innsvingningsforløp. Innsvingningsforløp Karakteristikk på prosessverdiens forløp før systemet er stabilt. Vi opererer hovedsakelig med tre typer innsvingningsforløp: Minimum forstyrrelse, minimum areal eller minimum amplitude. Minimum areal Innsvingningsforløp med 4-6 halvperioder. Minimum amplitude Innsvingningsforløp med 10-15 halvperioder. Minimum forstyrrelse Innsvingningsforløp med 1-2 halvperioder. Foroverkobling Reguleringsstrategi for å motvirke forstyrrelser i prosessregulering. 4-20 ma Signal der 4 ma representerer 0% og 20 ma representerer 100%. 1-5 V Signal der 1 V representerer 0% og 5 V representerer 100%. Side 3 av 75

1.2.3 Utstyr (Skrevet av ØE og MB) Utstyr på PLS riggen: Mitsubishi FX1N PLS Mitsubishi Q00CPU Mitsubishi Q61P-A2 Powersupply modul Mitsubishi QJ71PB92D Ethernet modul Mitsubishi QJ71E71-100 Profibus modul DLink AirPlus G+ Router Mitsubishi FX0N-3A AD/DA modul Mitsubishi FX0N-32NT-DP Profibus modul Beijer ix Panel TA100 Beijer OPC server PC med InTouch software Utstyr brukt under prosjektet: Agilent Technologies Oscilloscope m/usb tilkobling Antall: 2 stk. 1 stk. 1 stk. 1 stk. 1 stk. 1 stk. 2 stk. 2 stk. 1 stk. 1 stk. 1 stk. 1 stk. 1.2.4 Software (Skrevet av ØE) Software navn: Benyttet til: Hjemmeside: Wonderware InTouch HMI interface http://www.invensys.com GX Works 2 PLS programmering http://www.beijer.no Beijer OPC server OPC link mellom PLS og HMI http://www.beijer.no ix Developer 2.10 ix touchpanel programmering http://www.beijer.no GX Configurator-DP Oppsett Profibus-DP http://www.beijer.no GX IEC Developer Oppsett Ethernet PLS http://www.beijer.no MatLab m/ Simulink Simulering og filter design http://www.mathworks.com NI MultiSim Simulering av filteret http://www.ni.com Notepad++ Hjemmeside programmering http://notepad-plus-plus.org/ WinSCP Opplasting av hjemmeside http://www.winscp.net Side 4 av 75

1.3 Hjemmeside (Skrevet og kodet av ØE) Prosjektet har egen hjemmeside som publiserer alle rapportene, arbeidsnotatene og tidsskriftartikkelen. Her har vi også lagt ut kort hva prosjektoppgaven går ut på og hvem som er med i prosjekt gruppen. Hjemmesiden finner du på: http://www.hekta.org/~p2ea1 Til koden har vi benyttes oss av programmet notepad++, og språket som er benyttet er HTML 4.01. Figur 1 Eksempel kildekode hjemmeside Formatering av sidene er gjort ved hjelp av «Cascading Style Sheets», eller CSS 3.0. Det vil si at vi henter inn ferdige *.css filer i <head> i hver html fil. På den måten slipper vi å skrive formateringskoden for hver gang vi lager en ny html fil. Vi har laget to CSS filer, samt hentet en med font type fra Google. Vi ser i figuren over hvordan disse blir hentet inn i selve HTML filen, på linje 6, 7 og 8. Koden på linje 9 og 10 forteller web-browseren hvilket tegnsett som skal brukes, og hvilket språk siden er på. Dette må være med slik at vi få nordiske bokstaver som æ, ø og å. Koden som står i <style> taggen gir oss muligheten til å formatere hver enkelt HTML side med ting som kun gjelder denne siden. Figur 2 Eksempel CSS hjemmeside Her ser vi et eksempel på hvordan elementet «overskrift» er formatert under <style>. Høyde, bredde, plassering fra toppen og fra venstre. Her settes også bakgrunnsfargen, som her er representert med RGB tall, til grå. Figur 3 Eksempel formattering hjemmeside Ved å velge class=«overskrift» i <div> elementet, velger vi formattering for hele. Vi bruker <div> til å plassere alt av tekst, bilder og linker. Side 5 av 75

Hovedsiden er laget slik at menyer og overskrift kun lastes inn første gang. Innholdsdelen er laget ved hjelp av et <iframe> element, som henter opp og viser HTML sider. Det er laget en HTML side for hver side i menyen. Dette gjør at det blir enkelt å navigere i menyen, siden den ikke lastes hver gang. Størrelsen på siden er også prosent basert slik at den tilpasses skjermstørrelsen på hver PC som laster den. Koden for HTML og CSS er sjekket for kompabilitet mot gjeldende standarder på http://www.w3.org Dette gjør at vi kan benytte oss av logoer som viser at vi har utført denne sjekken av koden. Denne måten å lage hjemmesider på er veldig forskjellig fra den måten vi lærte i emnet Datateknikk. Vi har derfor måtte bruke mye tid på å lese oss opp på hvordan hjemmesider kodes til dagens HTML standard. Bruken av CSS var helt ny for oss, slik at vi begynte fra «scratch». Webgrensesnitt HMI I forbindelse med HMI-delen skulle det settes opp et web-grensesnitt mot touchpanelet. Dette bygger på en innebygget Java del i panelet. Det er satt opp en link fra hjemmesiden til Java serveren i panelet, men denne vil kun være operativ når vår del er lastet inn. Java delen i panelet er av en eldre, usikker type, som blir blokkert av nyere versjoner av Java. For å få denne funksjonen til å fungere må det derfor være installert en Java versjon som er versjon 7.0 eller eldre. Istedenfor er det kodet et webgrensesnitt som viser nivå, pådragsverdi og referanse. Referanse og manuelt pådrag kan også endres. Vi har prøvd å laget knapper som styrer utløpet, pumpe og kvitterer alarmer, men vi har ikke funnet koden som skal til for å styre enkelte bit-verdier. Dette grensesnittet fungerer kun når man er koblet til routeren lokalt. Grensesnittet finnes på http://192.168.1.104 Figur 4 Hjemmeside Side 6 av 75

2.0 Teknisk del 2.1 Problemstilling (Skrevet av ØE) Nivået i en tank skal reguleres med referanse 60%. Pådraget til tanken styres av en reguleringsventil. Det er 3 magnetventiler i utløpet som gir forstyrrelser til systemet. Prosjektgruppen skal programmere en regulator i PLSen, og utvikle brukergrensesnitt for prosessen i InTouch, samt et touch brukerpanel montert på riggen. Det skal prøves ut regulatorparametere fra simuleringsnotatet som ble ferdigstilt tidligere. Det er gitte krav til funksjoner og tilgangsnivåer til InTouch og touchpanelet i oppgaveteksten. Reguleringsmetodene som kan benyttes er følgende: Serieregulering: P-Regulator med nominelt pådrag. PI-Regulator. Foroverkobling: P-regulator med P-regulator foroverkobling. PI-regulator med P-regulator foroverkobling. P-regulator med D-regulator foroverkobling. PI-regulator med D-regulator foroverkobling. P-regulator med PD-regulator foroverkobling. PI-regulator med PD-regulator foroverkobling. Kravene til reguleringen er: Intet stasjonært avvik. Innsvingningsforløp av typen «minimum areal». Kjappest mulig innsvingning til ±2% av måleområdet når referansen er 60%. Det skal utarbeides en rapport på 60-80 sider for delprosjektet, samt publiseres på egen hjemmeside. Det praktiske arbeidet skal vises frem til faglærere Tirsdag 28.04.2015 Side 7 av 75

2.2 Prosessbeskrivelse 2.2.1 Flytskjema (Laget av AA) Figur 5 Flytskjema Side 8 av 75

2.2.2 Bilder av systemet (Tatt av EB) Bilde 1 PLS-rigg Side 9 av 75

Bilde 2 Tankrigg Bilde 3 Tankrigg bakside Side 10 av 75

2.2.3 Kommunikasjon (Skrevet av AA) Kommunikasjon mellom de forskjellige nodene i nettverket foregår på forskjellige måter. Vi bruker Ethernet mellom master PLS, operatørpanel og PC med InTouch. Mellom master PLS og slave PLS bruker vi ProfiBus DP. Masteren vil da fungere som en «tolk» mellom operatørpanel, PC med InTouch og slave PLS. Dette er primæroppgaven til master PLS i dette prosjektet. Ofte må man bruke slike «overganger» mellom forskjellige typer kommunikasjonsprotokoller. Dette kommer ofte av at de forskjellige produsentene ikke støtter andre leverandørers protokoller. Da blir det mye mer komplisert, og ikke minst fordyrende. Det kan også være nødvendig å bytte bus type dersom det er store krav til hastighet mellom noen av nodene. Alle bus typer har også en klar begrensning i rekkevidde. Her kan det være veldig kostbare noder som kommuniserer over store avstander, mens rimeligere noder brukes lokalt i de forskjellige avdelingene. Ett eksempel på dette kan være en fabrikk som har flere produksjonslokaler på ett industriområde. I hvert lokale kan det være flere mindre maskiner som har sine egne PLSer. Lokalt på hver enkelt maskin kan det være for eksempel ASI BUS som henter inn signal fra de forskjellige sensorene inn til PLSen. Deretter knyttes de forskjellige maskinene sammen med ProfiBus DP. Til slutt bruker man kanskje Ethernet IP for å sende data fra hver avdeling inn til hovedkontoret som ønsker å se driftsstatus, tilstander og produksjonsstatistikk. For å gjøre dette er man avhengig av noder som kommuniserer på minimum 2 nett samtidig, akkurat slik som vår master PLS gjør. Figur 6 Kommunikasjon Side 11 av 75

2.3 Antialiasing filter (Skrevet av ØE) Spesifikasjon AD omformer 8bit 4-20 ma 0-250 oppløsning 250 Ohm motstand inngang til filter 100 ms i samplingstid i PLS (valgt av oss) 2. ordens Butterworth filter Tar utgangspunkt i ukjent støy, og designer filteret ut i fra at alt over halve samplingsfrekvensen skal dempes med 20 db per dekade. Inngangssignalet på 4-20 ma gjøres om til 1-5V ved hjelp av en 250 Ω motstand i parallell med inngangssignalet. Figur 7 Kretsskjema antialiasing filter 1LSB = 5 1V = 0.016 V 1 0.016V LSB = 250 2 2 ω s = 2π = π rad = 31.4 2 2h 0.1 s ω 0 = 0.1 1/2 31.4 = 0.316 31.4 = 9.93 rad s = 0.008 V 10 20/20 = 0.1 rad 10 = 1.6 Hz 2 Side 12 av 75

Vi velger kondensatorer først, for så å bestemme verdiene til motstandene. h inn ut R 1 = = Velger C 1 = C 2 = 1 μf 1 2ω 0 C 1 = R 2 = 2 ω 0 C 2 = 1 2 10 rad s 10 rad s 2 1 μf 70kΩ 1 μf 140 kω 1 R 1 R 2 C 2 1 s 2 + R 2 C 2 s + 1 = 1 0.0098s 2 + 0.14s + 1 Dette blir ideelle verdier for motstandene. Vi må velge fra reelle verdier som ligger nærmest disse. Vi velger da: R 1 = 68 kω, R 2 = 150 kω Bode diagram 0 Bode Diagram Antialiasing filter -10-20 Magnitude (db) -30-40 -50-60 -70-80 0-45 Phase (deg) -90-135 -180 (rad/s) 10-1 10 0 10 1 Frequency 10 2 10 3 Figur 8 Bode diagram filter Side 13 av 75

Test av filteret i MultiSim MultiSim simulering av filteret med inngangssignal 1-5V og 50Hz støy med 2V amplitude. Vi valgte først kondensatorer på 47 μf, men ble anbefalt av Stein-Olav Lund, Labingeniør ved HiST, å velge kondensatorer mellom 1 og 2.2 μf. Disse hadde mindre lekkasjestrømmer, og filteret ble bedre. Vi har simulert det opprinnelige filteret i MultiSim, og siden dette har samme karakteristikk som det vi skal lage, har vi valgt å ta med figur av simuleringen Figur 9 Kobling MultiSim filter Figur 10 Sprang 1 til 5 volt filter MultiSim Rødkurve = inngangssignal, Blåkurve = utgangssignal, Sprang fra 1 til 5 V Scope innstillinger for kurven over. Side 14 av 75

Filteret i praksis Figur 11 Ferdig filter Systemet er generelt plaget med mye støy, både nettstøy og fra frekvensomformeren. Denne støyen forplantet seg til AD/DA omformeren, slik at den oppfattet at signalet inn endret verdi, selv om nivået var stasjonært. Vi så en klar forbedring når vi koblet til filteret. Støyen ble fjernet, og inngangssignalet ble uforandret når vi hadde stasjonært nivå i tanken. Systemet er fortsatt plaget med støy når spolene til utløpsventilene slår inn. Vi får da en «peak» som tolkes som verdien 250 i AD omformeren. Side 15 av 75

2.4 Regulatoralgoritmer (Skrevet av ØE) Vi velger å bruke bakoverdifferans for numerisk integrasjon. s = 1 Z 1 h Det skal være mulig å kjøre hovedregulatoren i både direkte og revers Vi har følgende kombinasjoner for regulatorene: Serieregulering: P-Regulator med nominelt pådrag PI-Regulator (uten nom. Pådrag) Foroverkobling: P-regulator med P-regulator foroverkobling PI-regulator med P-regulator foroverkobling P-regulator med D-regulator foroverkobling med nom. pådrag PI-regulator med D-regulator foroverkobling P-regulator med PD-regulator foroverkobling PI-regulator med PD-regulator foroverkobling Regulator parametere Grenseverdier for Kp, Ti og samplingstid h K p = 0.1 til 100 T i = 0.1 til 100 sek h sampling = 0.1 sek Ved heltallsaritmetikk multipliseres disse verdiene opp, slik at vi får kun heltall: K p10 = K p 10 = 1 til 1000 T i10 = T i 10 = 1 til 1000 sek h = h sampling 10 = 1 sek Vi vil få det samme for foroverkoblingsregulatorens parametere, K pff, T dff, K pff10, T dff10. T dff = 0.1 til 100 sek T dff10 = T dff 10 = 1 til 1000 sek Side 16 av 75

Avvik Det dynamiske avviket regnes ut på følgende måte Reversert: e = r y konstant r: pådraget økes når y reduseres Direkte: e = y r konstant r: pådraget økes når y økes Hvor r = referansen og y = måltverdi Inn- og utgangsverdier på AD/DA omformer 4-20 ma gjøres om til 0-250 i digitale verdier for AD. 0-250 i digitale verdier gjøres om til 4-20 ma i DA. Figur 12 Karakteristikk AD/DA omformer Serieregulator (Hovedregulator) P-regulator med nominelt pådrag Desimaltallalgoritme: Heltallsalgoritme: u(k) = K p e(k) + u 0 PI-regulator Desimaltallalgoritme: u = K p10 e(k) + u 10 0 u(k) = u(k 1) + K p ((1 + h T i ) e(k) e(k 1)) Heltallsalgoritme: Hjelpevariabel: X = T i10 h (K p10 (e(k) e(k 1)) + K p10 e(k) ) X u(k) = u(k 1) + 10 Side 17 av 75

Foroverkobling P-regulator Desimalalgoritme: Heltallsalgoritme: u Pff (k) = K pff (v(k) v(k 1)) u Pff (k) = K pff10 (v(k) v(k 1)) 10 D-regulator Heltallalgoritme: K pff settes til 1 ved ren D Figur 13 Prinsipp P-reg foroverkobling u Dff (k) = T dff10 u Dff (k 1) + K pff10 T dff10 (v(k) v(k 1)) 10 N 10 10 (h + T dff N ) Figur 14 Prinsipp D-reg foroverkobling Side 18 av 75

PD-regulator u PD (k) = u D (k) + u P (k) Kun u P (k) grensetestes i forbindelse med wind-up kontrollen. Figur 15 Prinsipp PD-reg foroverkobling Side 19 av 75

2.5 PLS programmering (EB) Slave-PLSen er den enheten hvor all regulering foregår. Den mottar datainput fra en maste-pls virker som et bindeledd mellom slaven, InTouch og operatørpanelet. Videre vil vi først forklare noen grunnleggende instruksjoner i programmeringen for å enkelt kunne forstå hva som skjer. Deretter viser vi hva master gjør og deretter slave-plsen. Detaljert beskrivelse av programkoden inne i funksjonsblokkene er gitt etter en generell beskrivelse av blokka. MOV-blokka Figur 16 MOV blokk MOV-blokka brukes til å kopiere data fra en plass til en annen. Den kan for eksempel kopiere data fra et dataregister over til et sett med minneceller. Da skrives dataregisteret på s-inngangen til blokka. På utgangen d kan man for eksempel skrive «K4M100». Da legges de 16-bits dataene fra dataregisteret over i 16 minneceller fra og med M100-M115. K4 betyr 4 kvartiler. I tilfellet i figur # kopierer den verdien 250 over i et dataregister som er kalt «Pådrag_u». TO- og FROM-blokkene Figur 17 TO blokk TO-blokka brukes for å skrive data til et bufferminne på Profibus. «s» angir hvilke data som skal sendes, n1 forteller hvilket slotnummer enheten som skal motta dataene har, n2 forteller hvilket bufferminne (BFM#) dataene skal sendes på og n3 forteller hvor mange 16-bits ord som skal sendes. Figur 18 FROM blokk FROM-blokka brukes til å lese data fra et bufferminne på Profibus. n1 angir slotnummeret for enheten dataene skal leses fra, n2 angir BFM# og n3 forteller hvor mange 16-bits ord som skal leses. Utgangen d angir hvor dataene skal leses til, for eksempel et dataregister eller et sett minneceller. Side 20 av 75

LD sammenligningsblokker LD-blokkene er et sett med blokker som sammenligner to verdier. Om påstanden til blokka er sann, vil de etterfølgende instruksjonene bli utført. Denne funksjonen bruker vi for å grensesjekke verdier så de holder seg innenfor tillatte grenser. F.eks. kan ikke pådraget ut på DA-omformeren overskride 250 eller være mindre enn 0. Da må pådraget grensesjekkes etter utregning slik at det holder seg innenfor 0 og 250. Figur 19 LD blokk I figur # sjekkes «Pådrag_u» om verdien er over 250. Hvis den er det, kopieres verdien 250 til pådraget, slik at det ikke blir større. Dette er også en del av anti-windup-funksjonen til regulatoren, slik at integratoren ikke fortsetter å integrere opp når pådraget når sine grenser. PLS og PLF Mye av aksjonene og utregningene skal skje på et bestemt tidspunkt, og ikke kontinuerlig. Dette gjelder set/reset av minneceller som styrer aksjoner, utregning av pådrag fra regulatoren, oppdatering av gamle verdier etc. PLS-blokka går høy i et scan på positiv flanke når noe trigger den. PLF-blokka går høy et scan på negativ flanke. En kan se for seg en knapp som trykkes på. PLS-blokka går høy et scan når knappen trykkes inn (den forblir ikke høy selv om knappen holdes inne), og den PLF-blokka går høy et scan når knappen slippes. Figur 20 PLS / PLF blokk Det er også mulig å sette at en overgang skal trigge på positiv eller negativ flanke, at etterfølgende aksjoner bare trigges et scan på den respektive flanken. Pilen, vist i figur 21, indikerer om den trigger på positiv flanke (pil opp) eller negativ flanke (pil ned). Figur 21 Kontakt positiv flanke Side 21 av 75

2.5.1 Master-PLS Initiering og backup Først i programmet i master ligger en del som resetter alle statuser ved oppstart og henter tilstanden for aksjoner fra batterimatede minneceller. Oppgaven sier at regulering av tanken skal skje direkte etter strøminnkopling ved strømbrudd. Det medfører at vi må ta vare på regulatorparametere og aksjoner i batterimatede dataregistre og minneceller. Dataregistrene som er batterimatede er av typen R#, og minnecellene av typen L#. Disse beholder sine verdier selv om strømmen er borte, via et batteri i strømforsyningsenheten til master. Figur 22 PLS initiering status Statuser I master har vi satt av et sett med minneceller til indikering av statuser fra slave-plsen. Master mottar et dataregister, D130, hvor verdiene kopieres over i minneceller for å lese av hvert enkelt bit. K4L16 betyr 4 kvartetter (4x4 bit) fra minnecelle L16 tom. L31. Ved oppstart/strøminnkopling nullstilles alle statuser med spesialminnecelle SM402, som kun er høy første scan etter oppstart. I figur 23 er programbiten for statushåndtering vist. Figur 23 PLS Flytte fra data til enkelte bit Status for kommunikasjon med Profibus er programmert på samme måte som i miniprosjektet. Side 22 av 75

Aksjoner Aksjoner som skal styres settes via batterimatede minneceller samles i et dataregister og sendes ut på Profibus til slave. Dette er aksjoner som «start/stopp pumpe», «åpne en ventil» etc., hvor vi bruker bitverdier til å sette/resette utganger på slaven. Dette er vist i figur 24. Figur 24 PLS enkelt Bit til Data Sende regulatorparametere Det er master som sender ned alle parametere satt i InTouch eller operatørpanel ned til slave, og som mottar alle statuser sendt opp fra slaven og videreformidler disse til Intouch og operatørpanel. Da de batterimatede dataregistrene ikke automatisk sendes ut på ProfiBus, bruker vi en MOV-blokk for å kontinuerlig kopiere parameterne over i dataregistre som sendes ut på ProfiBus. Vi har laget en funksjonsblokk som flytter alle parameterne over i dataregister som går ut på ProfiBusen. Funksjonsblokka har ingen innganger eller utganger, da alle dataregistre fra D100-D115 automatisk sendes ut på ProfiBus. Hensikten med å samle koden i en blokk er å gjøre programmet kompakt og oversiktlig. Figur 25 PLS Flytte til batterimatede minneceller Figur 26 PLS Flytte parametre til Profibus Side 23 av 75

Starte og stoppe pumpa Pumpa skal startes både fra Intouch og operatørpanel. Vi har brukt et batterimatet dataregister som vi har kalt «PUMPE_data» som enten har verdien 0 eller 1 ettersom pumpa skal starte (1) elle stoppe (0). Ved strømbrudd beholder dataregisteret sin verdi slik at pumpa beholder samme status etter som før strømbruddet. Figur 27 PLS Start/Stopp pumpe Å få pumpa til å starte etter strømbrudd var et problem vi jobbet en stund, da de batterimatede minnecellene vi satte ble resatt etter strøminnkopling av ukjent grunn. Derfor endte vi opp med å la verdien på et dataregister bestemme om minnecellene skulle være satt eller ikke. Pumpa stoppes automatisk ved kritisk lavt eller høyt nivå (over 90% eller under 10%). Denne programbiten er presentert i alarmdelen for slaven. Auto/manuell regulering Det er gitt i oppgaven at regulatoren, i tillegg til automatisk regulering, også skal kunne styres manuelt. Dette gjøres ved å sette den i manuell modus hvor pådraget blir gitt av operatør som «manuelt pådrag». Denne funksjonen må også ha en set/reset-funksjon av samme grunn som pumpa. Vi har programmert regulatoren til å være i auto så lenge «AUTO_MAN_IN» er resatt (lav). InTouch og operatørpanelet kommuniserer med «Aktiver_manuell» og «Stopp_manuell», se figur 28. Figur 28 PLS Auto/Manuell Side 24 av 75

Regulatormoduser Regulatoren skal kunne fungere både som P- og PI-regulator, og begge enten uten eller med P-, D-, eller PD-foroverkobling. I Intouch har vi brukt «radio buttons», som ikke kunne gi diskrete, men bare analoge verdier, 1, 2, 3 osv. Dermed har vi måtte lage en programdel som legger verdiene fra knappene i Intouch over i dataregistre, for så å sammenligne disse med bestemte verdier for å sette eller resette bitverdiene som angir regulatormodus. Valg av regulatormodus settes bare i Intouch, ikke i operatørpanel. Valg av P- og PI-regulator er vist i figur 29. Figur 29 Velge P/PI regulator «Radio»-Knappene i Intouch har verdiene 1 og 2 når det er to knapper som står sammen, som her styrer P- og PI-modus. Det samme er tilfellet med aktivering/deaktivering av foroverkoblingen, som vist i figur 30, mens for valg av type foroverkobling gir knappene verdiene 1, 2 eller 3, da det er tre valg. Dette har resultert i at vi bruker verdien i gitte dataregistre for å bestemme hvilken regulatormodus som skal være satt. Programdelen for valg av foroverkoblingsmodus er vist i figur 30. Her er det programmert slik at hvis D- og PD-foroverkobling er resatt, er P-foroverkoblingsmodus satt. Hvordan dette settes i slaven er vist under avsnitt 2.5.3 Foroverkoblinsregulator. Figur 30 PLS valg av foroverkobling Side 25 av 75

Styring magnetventiler Riggen har tre magnetventiler som vi kan styre via Intouch eller operatørpanelet. Vi har laget programmet slik at vi kan sette utløp til 0% (alle lukket), 33% (en ventil åpen), 66% (to ventiler åpne) eller 100% (alle ventiler åpne), se figur #. Dette settes både i Intouch og i operatørpanelet. For at statusen for ventilene skulle holde seg etter strømbrudd, måtte vi også bruke dataregistre for indikasjon på hvor mange ventiler som skulle åpnes. Hvis vi brukte direkte set/reset-funksjon uten dataregistre, beholdt de bare statusen sin en kort stund (ca. et scan) før de ble resatt. Dette problemet var gjengående for alle aksjoner som skulle starte etter strømstans. Under, i figur 31 vises programkoden som lukker alle ventilene, og her vises også koden som åpner to ventiler. Den samme koden gjelder for alle utløp, null, en, to og tre ventiler åpne. Verdien i «VENTIL_data» gjenspeiler antall åpne ventiler. Figur 31 PLS Valg av utløp / Magnetventiler Side 26 av 75

En egen programdel gir status på hvor mange ventiler som er åpne til Intouch og operatørpanelet. Dette er vist i figur 32 under. Figur 32 PLS Status magnetventiler 2.5.2 Slave-PLS For å holde oversikt over hva som skjer i de forskjellige programdelene og for lett å kunne feilsøke, har vi delt inn programmet i flere deler med hver sin oppgave. Dette er også viktig for å styre rekkefølgen oppgaver utføres i. F.eks. må avleste verdier som vi tar vare på for videre beregninger, oppdateres til slutt i programsekvensen, etter at pådraget ut fra regulatoren er sendt ut på DAomformeren. For å styre denne rekkefølgen legges programdelene i «Task 1», «Task 2» osv etter hvilken rekkefølge de skal utføres i. Dette er vist i figur 33. Figur 33 PLS Slave struktur I Task 1 ligger programdelene for skriving og henting av data til og fra master, styring av pumpe og ventiler, regulatorene og alarmhåndteringen. I Task 2 ligger programdelen som skriver og leser til og fra AD/DA-omformeren. Det er viktig at denne oppgaven ikke gjøres samtidig som utregningene fra regulatoren, men etter pådraget er regnet ut. I Task 3 oppdateres «forrige verdier». Dette må skje til slutt etter at pådraget er sendt ut på DA og dataene er lest av. Side 27 av 75

Til/Fra Profibus «Til_Fra_Bus» inneholder programkoden som sender og henter all data til og fra Profibus/master- PLS. Vi har laget funksjonsblokker som bruker TO- og FROM-blokker til å sende og hente data. Når vi samler alle disse blokkene i egne funksjonsblokker blir programmet mer oversiktlig og lettere å lese under monitorering når vi kjører reguleringen. Da kan vi enkelt lese av hvilke verdier som sendes og hentes til og fra master. Figur 34 PLS Slave til/fra Master De ledige utgangene fra funksjonsblokkene er utganger fra bufferminner som ikke brukes. Vi har mulighet til å hente og sende data fra og til totalt 15 bufferminner fra ProfiBus. Ved å lage en funksjonsblokk som leser/skriver fra/til alle og tildeler hvert bufferminne et dataregister, kan vi enkelt delegere hvilke verdier som skal hvor i slaven. Da har vi også oversikt over hva som er i bruk og hva som er ledig av bufferminner og dataregistre. Programdelen i funksjonsblokkene i figur # og # er vist i vedlegg #. Side 28 av 75

Statuser fra slave I slaven har vi satt av 16 minneceller for statusindikasjoner som samles i et dataregister og sendes opp til master. Statusene brukes som bekreftelser på at de aksjoner og innstillinger vi har satt fra pc eller operatørpanel er utført/satt. Statuser som sendes opp er status for: Pumpe (Start eller stopp) Magnetventiler (åpen eller lukket) Alarmer (avvik fra referanse og kritisk høyt eller lavt nivå) MOV-blokka kopierer 16 minneceller fra M500-M515 over i dataregister D130 som sendes ut på Profibus opp til master. K4 bety fire kvartetter som er lik 16 minneceller. Figur 35 PLS Status bit sendes via Dataregister Aksjoner fra master Slaven mottar også et sett med minneceller «pakket» inn i et dataregister fra master på samme måte som statuser fra slaven blir sendt. Dataregisteret kopieres over til et sett med minneceller med ei MOV-blokk. Hvert enkelt bit setter hver sin funksjon, som er kommentert i figur 36. Figur 36 PLS Aksjoner mottatt fra Master Styring av pumpe og magnetventiler, slave Pumpa på riggen startes ved å sette utgang Y4 på slaven høy. Det er et krav i oppgaven at den skal stoppe om nivået når kritisk lavt (under 10%) eller høyt (over 90%) nivå, og tilstanden varer i over fem sekunder. Om enten «LowLevelAlarm» eller «HighLevelAlarm» aktiveres, stopper pumpa. Pumpa må også kunne overstyre i manuell modus, slik at man kan komme seg opp fra et kritisk lavt nivå, eller ved en oppstartsfase av tanken. Magnetventilene på riggen styres av utgangene Y10, Y11 og Y12. Status på utgangene sendes opp til master. Side 29 av 75

Figur 37 PLS Styring utganger Slave Avlesning av nivå, utstrømning og skriving av pådrag I miniprosjektet laget vi en funksjonsblokk som skrev pådrag ut på DA-omformeren og leste av nivå og utstrømning (flow) fra AD-omformeren. Denne funksjonsblokka har vi brukt videre i entankprosjektet, men vi gjentar ikke innholdet inne i funksjonsblokka. Figur 38 PLS Skriv/les AD/DA slave Side 30 av 75

2.5.3 Serieregulator P-regulator Funksjonsblokka for P-regulatoren er vist over i figur #. Inn i blokka sendes Kp-verdien (Kp10), nominelt pådrag (NomineltPadrag_u0), referanse (Referanse_r), avvik, aktivering av P-regulator (RegModus) og indikasjon for manuell eller automatisk modus (ManAuto). Kp- og Ti-verdiene er multiplisert med 10 før de blir sendt til slaven pga. heltallalgoritmen. Dette gjelder også for PIregulatoren og foroverkoblingen (Kpff og Tdff). Ut fra blokka sendes pådraget, som videre legges sammen med et eventuelt pådrag fra foroverkoblingen og det grensesjekkes og sendes ut på DAomformeren. Figur 39 PLS P-regulator Funksjonsblokken inneholder heltallsalgoritmen for P-regulator hentet fra avsnitt 2.4: u = K p10 e(k) + u 10 0. Når P-foroverkobling er valg skal ikke det nominelle pådraget skrives til pådraget fra P-regulatoren. Dette er det satt opp en sperre for i programmet. Figur 40 PLS P-regulator algoritme - mellomregning Side 31 av 75

«Mellomverdi» er pådraget fra P-regulatoren før det er grensesjekket. Pådraget skal skrives som en 8-bits verdi fra 0-250. Hvis utregningen blir negativ, settes pådraget til null, og hvis det blir over 250, settes det til 250 før det kopieres over i den endelige variabelen for pådraget, «P_Pådrag», som går ut av funksjonsblokka. Grensesjekken er vist i figur 41. Det er lagt inn sperrer for skriving til pådraget hvis PI-regulator eller manuell modus er aktivert. Figur 41 PLS Grensesjekk og pådrag Under, i figur 42, er programbiten som kopierer 0 over til pådraget fra P-regulatoren om PIregulatoren er aktivert. Når «Regmod» er høy, betyr det at PI-regulator er aktivert. Figur 42 PLS Av/På P-regulator Side 32 av 75

PI-regulator Prosjekt i styresystemer 2015 Figur 43 PLS PI-regulator PI-regulatoren er også programmert som en egen funksjonsblokk. Parameterne som sendes inn i blokka er referanse (Referanse_r), avvik, Kp (Kp10), integrasjonstid Ti (Ti10), forrige pådrag (Um1), forrige avvik (em1), aktivering av PI-regulatoren (RegModus), indikasjon på manuell eller automatisk modus (ManAuto) og samplingstiden (h_sampling). Ut fra blokka sendes pådraget, «Pådrag_PI», som videre legges sammen med et eventuelt pådrag fra foroverkoblingen og deretter grensesjekkes før det sendes ut på DA-omformeren. Algoritmen som er brukt i regulatoren er hentet fra boka «Sanntidsdatateknikk. Per Hveem, 2014». Først innfører vi hjelpevariabelen Tih = Ti h Del 1 av mellomregningene vist under: ΔU ik = K p10 e k +ΔIRest k 1 Tih 10 Figur 44 PLS PI mellomregning 1 Del 2 av mellomregningene vist under: ΔU irestk = (K p10 e k + ΔiRest k 1 )%(Tih 10) Uttrykket er det samme som i del 1, med en modulofunksjon, %, er brukt for å tar vare på resten av heltallsdivisjonen som senere legges til. Den er representert av MOD_E-blokka. Figur 45 PLS PI mellomregning 2 Side 33 av 75

Til slutt regnes det endelige pådraget ut, som så grensesjekkes før det sendes ut av funksjonsblokka. U k = U k 1 + ΔU ik + K p10 (e k e k 1 ) 10 Figur 46 PLS PI grensesjekk og pådrag Resten av hjelpevariabelen ΔiRest k oppdateres på negativ flanke, når samplingstimeren går lav. Det gis bare bidrag fra «PI_Pådrag» om «Regmodus», altså PI-regulatoren, er aktivert og den ikke står i manuell modus. Pådraget skrives på positiv flanke når samplingstimeren går høy. Figur 47 PLS PI-reg pådrag Side 34 av 75

2.5.4 Foroverkobling Foroverkoblingen er et tillegg til hovedregulatoren og gir ekstra pådrag på bakgrunn av utstrømningen. Flowmåleren måler utstrømningen, som reagerer raskere enn målingen av nivået i tanken. Ved å gi et pådrag på bakgrunn av utstrømningen kan man raskere regulere inn nivået ved åpningen av ventilene. Foroverkoblingen skal fungere enten som P-, D-, eller PD-foroverkobling som skal styres fra PC. Vi har laget en funksjonsblokk som inneholder mulighet for alle typene foroverkobling. Figur 48 PLS Foroverkobling P-foroverkobling Algoritmen i sin helhet er vist i avsnitt 2.4. PLS-programmet for heltallsalgoritmen som regner ut pådraget er vist i figur #: u Pff (k) = K pff10 (v(k) v(k 1)) 10 Pådraget skal regnes ut enten når P-foroverkobling eller PD-foroverkobling er aktivert. Differansen mellom nåværende og forrige utstrømning multipliseres med en K-forsterkning og divideres til slutt på 10. Jo større differanse det er mellom dem i nåværende utstrømnings favør, jo større blir pådraget. Figur 49 PLS Foroverkobling P-Reg pådrag Pådraget fra P-foroverkoblingen grensesjekkes før det legges til pådraget fra serieregulatoren og sendes ut på DA. Side 35 av 75

D-foroverkobling Foroverkoblingen skal også ha en ren D-foroverkobling. Derivatordelen registrerer hvor hurtig endringer skjer, i vårt tilfelle hvor hurtig utstrømningen endres. Den gir så pådrag etter hvor hurtig endringene skjer. Når ren D-foroverkobling er aktivert settes K pff = 1 K pff10 = 10. Dette skjer utenom funksjonsblokka, under POUen «Parametere». Figur 50 PLS Foroverkobling D-Reg endring av Kp til 1 Heltallsalgoritme for D-foroverkobling: u Dff (k) = T dff10 u Dff (k 1) + K pff10 T dff10 (v(k) v(k 1)) 10 N 10 10 (h + T dff N ) Figur 51 PLS Foroverkobling D-Reg De tre øverste blokkene, i figur 51 over, representerer den første brøken i uttrykket. Den nedre halvdel, bestående av sju blokker representerer den andre brøken. Disse brøkene adderes til slutt. D- delen av foroverkoblingen skal være utenfor anti-windup (grensesjekk), så det sendes rett ut av funksjonsblokka og adderes til pådraget fra serieregulatoren. Figur 52 PLS Foroverkobling pådrag D-del Side 36 av 75

PD-foroverkobling PD-foroverkoblingen summerer pådragene fra P- og D-delen. P-delen grensesjekkes, og deretter legges bidraget fra D-delen til. Etter de er summert sendes de ut av funksjonsblokka. Figur 53 PLS Foroverkobling PD-Reg Pådrag ut på DA-omformer Når pådraget fra serieregulatoren og foroverkoblingen er regnet ut, legges de sammen etter hvilken regulatortype som er valgt i pc eller operatørpanel. «Pådrag_u» grensesjekkes så, før det kopieres over i «Pådrag_ut», som skrives til DA-omformeren. Figur 54 PLS Pådrag til DA-omformer Side 37 av 75

Manuelt pådrag Når manuelt pådrag er valgt, er skriving fra regulatorpådraget deaktivert. Figur 55 PLS Manuelt pådrag Rykkfrie overganger Rykkfrie overganger (Bumpless Transfer) vil si at endring av regulatortype eller fra manuell til auto og motsatt ikke skaper rykk/hopp i prosessen eller pådraget. Oppgaven vår setter rykkfrie overganger som et krav. Vi har sørget for at overgangen mellom P og PI går rykkfritt ved at begge pådragene regnes ut kontinuerlig, og at vi bestemmer hvem som skal skrive til det endelige pådraget ut på DAomformeren. Pådraget mellom manuell og auto har vi satt slik at om manuell settes, blir pådraget som er skrevet inn i Intouch eller operatørpanel, satt. Det forutsetter at manuelt pådrag er satt lik det automatiske pådraget for at pådraget skal ligge urørt etter overgang. Figur 56 PLS Rykkfrie overganger Sampling Vi har laget en timer som bestemmer når verdier skal skrives, leses og oppdateres under reguleringen. Samplingstiden til regulatoren kan settes i Intouch, og bestemmer hvor ofte regulatoren skal avlese nivå og utstrømning og skrive pådrag. Standard samplingstid for regulatoren vår er 0.1 sekund. Timeren er laget slik at den resettes seg selv. Figur 57 PLS Samplingstid Side 38 av 75

Revers og direkte modus Oppgaven er det gitt at det skal være mulig å velge revers eller direkte modus for regulatoren. Forskjellen er måten avviket regnes ut på. Det var ikke videre gitt at regulatorens skulle fungere i begge moduser, så regulatoren er bare skikkelig fungerende i reversert modus, hvor avviket er lik referansen minus nivået. Ved direkte modus er avviket lik nivået minus referansen. Figur 58 PLS Revers/Direkte regulering 2.5.5 Alarmhåndtering (Skrevet av MB) Programmeringen av alarmer på nivå og referanse ble gjort i slaven ettersom alle verdiene vi trenger ligger der, samt utgangen til alarmlampen er i slaven. Alarm for kommunikasjon ble programmert i master. Statusen for ProfiBus-kommunikasjonen ligger i bufferminne nr. 21. Dersom kommunikasjonen mellom master og slave ikke fungerer går bit 12 i BFM#21 høy. Vi henter ut denne biten med en FROM-blokk. Dersom statusen er lik 1 settes ett flagg som indikerer at Profibus-kommunikasjonen er nede. Figur 59 PLS Status Profibus Side 39 av 75

Vi laget en egen funksjonsblokk for alarmhåndteringen i slaven slik at alt som går inn og ut av programbiten blir oversiktlig framstilt. Vi trengte kun nivået i tanken og referansen på inngangene til funksjonsblokken for å regne ut alarmtilstandene. I tillegg måtte kvitteringen av alarmer fra brukergrensesnittene inn på blokka. Ut fra blokka kommer alle alarmtilstandene pluss utgangen til alarmlampen. Figur 60 PLS funksjonsblokk Alarmer Hvis nivået avviker mer enn 25% fra referansen skal det gå vanlig alarm. Det ble delvis utført på måten vist i bildet under. I neste bilde regner vi ut om nivået er 25% under referansen. Referansen blir trukket fra verdien 62 som er 25% av det totale nivået i tanken uttrykt i bit verdi. Dette blir gjort med SUB-blokken vist i bildet nedenfor. Så blir verdien fra subtraksjonen sendt videre til sammenligningsblokken LD<. Her blir verdien sammenlignet med nivået i tanken. Hvis nivået er mindre enn verdien sendt fra SUB-blokka, settes et flagg for at avviket mellom nivå og referanse er for stort. En lik programkode ble skrevet for avvik over referansen. SUB-blokka ble da byttet ut med en ADD-blokk med de samme verdiene. Verdien blir sendt videre til en blokk som sammenligner om nivået er større enn denne verdien. Figur 61 PLS Alarm 25% under ref. Kritisk alarm skal aktiveres om nivået går over 90% av tanken eller under 10%. I bildet under regner vi ut om nivået er mindre enn verdien 25, som er 10% av det absolutte nivået i tanken. Når verdien i Nivå er mindre enn 25 settes ett flagg for kritisk lavt nivå i tanken. For å regne ut kritisk alarm når nivået er over 90% brukte vi en «større enn»-blokk som regner ut om nivået er større enn verdien 225 som er 90% av det absolutte nivået i tanken uttrykt i bitverdi. Når den kritiske alarmen går skal pumpa automatisk stoppes. Figur 62 PLS Alarm Kritisk lavt nivå Side 40 av 75

Ett av kravene til alarmene var at en alarmtilstand som ikke varte lenger enn 5 sekunder ikke skulle utløse noen alarm. Det ble realisert på følgende måte, som også er vist i bildet under. Alarmflaggene som blir satt etter utregningene får sine egne «timere». Så lenge ett av flaggene er satt vil den respektive blokka OUT_T begynne å telle opp til verdien som er satt i inngangen «TValue». Verdien er oppgitt i tidels sekund. Når blokka har telt opp til 5 settes en individuell bit for hver blokk. Figur 63 PLS Alarmer tidsbegresning For blokka «TC1» heter den individuelle bit en «TS1». Når denne blir satt høy 5 sekunder etter at alarmtilstanden ble satt, får vi varsel om alarmtilstanden. Varselet sendes på utgangen til funksjonsblokka ved at utgangen settes høy. Figur 64 PLS Alarmer Tidsforsinkelse Alarmen kan kun resettes dersom tanken går ut av alarmtilstand, som igjen setter TS1 lav, i tillegg til at det fysisk må kvitteres fra ett av brukergrensesnittene som er koblet til systemet. Figur 65 PLS Alarmer Kvittering I tillegg til at alarmer skal vises i brukergrensesnittene skal en lampe på selve riggen indikere om en alarm er kritisk, vanlig, eller kvittert. Ved vanlig alarm skal lampen blinke på og av med 0,5 sekunders intervaller. Ved kritisk alarm skal lampen blinke med 0,2 sekunders intervaller. Når en alarm er kvittert men det fortsatt er alarmtilstand skal lampen lyse konstant. Når det ikke lenger er alarmtilstand og den er kvittert slukkes lampen. Neste bilde viser hvordan vi realiserte den kritiske alarm frekvensen ved hjelp av en timer og en holdekrets. En timer sender ut en puls hvert 2. tidels sekund ved at timeren resetter seg selv ett scan etter at den er ferdig å telle. For hver puls på TS5 vil M1 bytte status mellom høy og lav. For vanlig alarm på 0,5 sekunds intervaller ble en identisk programkode laget med en endret «TValue» på 5. For vanlig alarm brukte vi minnecelle M0 i holdekretsen. Side 41 av 75

Figur 66 PLS Alarmlampe blink Neste bilde viser programbiten for alarmlampen. Vi ser at når vi har vanlig alarm men ikke kritisk alarm, i tillegg til at vi ikke har fått noen kvittering fra operatøren, vil M0 gjøre at alarmlampen blinker med frekvens på 0,5 sekund på og 0,5 sekund av. Skulle en kritisk alarm bli utløst derimot, vil minnecelle M1 gjøre at lampen blinker med frekvens 0,2 sekund. Dersom vi har kvittert alarmen men fortsatt har alarmtilstand vil lampen lyse konstant. Figur 67 PLS Alarmlampe For å sørge for at alle alarmer må kvitteres blir kvitteringen satt og resatt. Kvitteringen blir satt av operatør på ett av brukergrensesnittene. Kvitteringen resettes hver gang en alarm går. På denne måten vil alle nye alarmer resette kvitteringen, som sørger for at operatøren fysisk må kvittere for alle alarmer som går. Figur 68 PLS Alarmer kvittering Side 42 av 75

2.6 HMI programmering 2.6.1 OPC-server og tagger (Skrevet av MB) OPC gjør kommunikasjonen mellom produkter fra forskjellige produsenter mulig. En OPC server ble derfor satt opp for å muliggjøre kommunikasjon mellom Mitsubishi master-pls og brukergrensesnittet som ble laget i Wonderware Intouch. Det er viktig at PLS-programmet er overført til PLSen, og at GX Works er lukket før man setter opp OPC serveren første gang. Det første vi gjør etter vi har åpnet OPC serveren er å konfigurere den for vår master-pls som er en Mitsubishi Q-E71. Vi velger merke og serie og skriver inn PLSen sin IPadresse. Nå vet OPC serveren hvilken adresse den skal kommunisere med på Ethernettet. I master-plsen brukes bit- og ordadresser for å overføre informasjon til og fra både slaven og brukergrensesnittene. I OPC serveren definerer vi alle de brukte adressene som tagger. Vi spesifiserer også hva slags type adresse den skal prate med enten det er en bitadresse, for eksempel en minnecelle, eller en ordadresse, eller et dataregister. Nå vet serveren hvilke adresser den skal kommunisere med i selve PLSen. Taggene får samme verdi i OPC som i PLSen, og disse endres ettersom verdiene endres i PLS. Når vi er ferdig med å opprette alle taggene vi trenger startes OPC serveren. Den har nå forbindelse til PLSen og vi kan monitorere verdiene til alle adressene som vi har definert i serveren. Vi kan også monitorere statusen på forbindelsen mellom server og PLS. Så lenge serveren er oppe og går kan vi ikke endre de taggene vi allerede har opprettet, men vi kan opprette nye tagger og grupper. OPC serveren er nå oppe og går, og klar til bruk. Vinduet må ikke lukkes så lenge vi skal ha kommunikasjon mellom utstyret. Figur 69 OPC Tag liste I tillegg til en OPC server trenger vi en OPC klient som er forbindelse fra utstyret inn til serveren. Klienten som oversetter data inn fra/ut til PLSen er innebygd i OPC serveren. OPC klienten som forbinder OPC server og Intouch heter Wonderware OPC Link og følger med Intouch. Når man åpner OPC Link må man opprette en konfigurasjonsfil hvor de satte innstillingene lagres. Dette fordi Intouch skal kunne åpne OPC Link automatisk når man åpner prosjektet. Etter man har opprettet filen definerer man hva OPC serveren heter som Intouch skal ha forbindelse med. I vårt tilfelle Beijer.Electronics.OPC.Server. I tillegg definerer vi hva PLSen heter. Dette gjøres fordi man i Intouch gjerne styrer mange forskjellige PLSer. Vi har nå kommunikasjon mellom Intouch og server, og videre til master-pls. Side 43 av 75

Det første vi gjorde i Intouch var å opprette tagger for de adressene som brukes i PLSen. Taggene kan man si er et duplikat av adressene i PLSen, og vi kan aktivere disse for å styre adressene i PLSen. Vi vil at taggene som brukes skal referere til de taggene vi har opprettet i OPC serveren og må derfor bruke en modul i Intouch som heter OPC TagCreator. Etter at vi har koblet OPC serveren opp mot Intouch med OPC Link finner vi nå de samme taggene som vi opprettet i serveren igjen i TagCreator. Først velger vi den topicen vi ønsker fra OPC Link. Her finner vi igjen navnet på PLSen. Så lager vi et accessname for de taggene vi skal opprette. Vi laget bare ett accessname kalt master, men om man har flere PLSer og massevis av tagger er det viktig å organisere taggene med flere accessnames. Så oppretter vi en og en tag som deretter dukker opp i en liste i et eget vindu nederst på skjermen. Vi importerer taggene til Intouch. Vi kan se at TagCreator har importert gruppene vi laget i OPC serveren og taggene som ligger i hver gruppe. Når vi markerer en tag kan åpnes muligheten for å trykke Create Tag. Hvis vi trykker på denne vises den nye taggen i en liste. En liste over alle tagger finner vi under Tag Directory. Her kan man også redigere navnet på taggene, hva slags type tag det skal være og andre detaljer. Noe vi fikk mye bruk for i dette prosjektet var skaleringen av taggene. Dette betyr at verdien endres i Intouch før den sendes ut på OP serveren. Som vi ser på figur 70 skriver vi inn en verdi mellom 0 og 100 i Intouch. Verdien blir skalert til en verdi mellom 0 0g 250 og denne verdien sendes ut til OPC serveren Figur 70 OPC Tag eksempel skalering Side 44 av 75

2.6.2 Design InTouch (Skrevet av MB) Det første som ble laget i Intouch var det hele prosjektet egentlig handler om, nemlig tanken. Det var viktig at designet av tankgrafikken var enkel, lett gjenkjennelig, samtidig som den skal passe inn i et større system av grafikk med ventiler, pumpe og andre komponenter. Hovedpoenget med designet av tanken var allikevel å vise nivået i tanken på en måte som gjør at man umiddelbart får en ide om hvor høyt vannstanden ligger. Vanntanken ble designet meget enkelt som en gjennomsiktig tank med sorte kantlinjer, blått fyll og en anelse lysere bakgrunn enn resten av skjermbildet. På denne måten skjønner operatøren umiddelbart hva dette er, samtidig som framstillingen er enkel og grafikken blir «ren» og ryddig. Tanken ble plassert midt i hovedprosessbildet for videre å tydeliggjøre at dette er hva hele programmet handler om. Fyllet i tanken ble koblet til taggen for nivået i tanken i menyen Animation Links->Vertical Fill. Man kommer seg til denne menyen ved å dobbeltklikke på grafikken man vil endre animasjonsinnstillingene på. Her skriver man også inn hva verdien på taggen man bruker er ved maksimum fyll og minimum fyll. Figur 71 InTouch Nivå tag Neste steg ble å legge inn referansen som en stripe på tankgrafikken. Vi valgte å bruke en fargen gul for å framheve at dette ikke er nivået i tanken. Vi unngår å bruke fargen rød da denne fargen brukes utelukkende på alarmer for å unngå forvirring. Vi vil at denne referanse-stripen skal flyttes opp og ned etter hva vi setter referansen til. Vi går derfor inn i Animation Links->Vertical Location hvor vi kobler denne til referanse-taggen. Ved denne innstillingen kan vi få referanse-stripen til å bevege seg vertikalt etter hva verdien på referanse-taggen er. Måten vi gjorde dette på var ved å plassere stripen der hvor 100 % av referansen ville være, og brukte koordinatene på windows-pilen som ligger nede til høyre i InTouch vinduet til å finne koordinatene til det som ville være 0 % av referansen. Verdiene ble skrevet inn i Vertical Location-vinduet som vist i figur 72. Side 45 av 75

Figur 72 InTouch Plassering av referanse Etter vi følte oss ferdig med tanken kom designet og animasjon av resten av riggen. Vi begynte med reguleringsventilen. Vi ville fortsette med det enkle, rene designet som vi begynte med på tanken og bestemte oss for å lage en ventil som viser pådraget som fyll. Dette gir operatøren raskt en anelse om hvor stort pådraget er i forhold til maksimum pådrag. Symbolet for reguleringsventilen ble bygget opp av flere andre symboler, noe som gjør at muligheten til å lage celler i Intouch kommer godt til nytte. Denne funksjonen gjør at vi kan sette flere symbol sammen til én celle, noe som gjør alt mye lettere i Intouch om man for eksempel skal flytte om på grafikk man har laget. Vi kan lett se for oss forskjellen på figur 73 under. Figur 73 InTouch Reguleringsventil Utløpsventilene på selve tankriggen er magnetventiler så de måtte designes på en annen måte enn reguleringsventilen. Ventilene er enten åpen eller lukket så fargen på fyllet ble satt til enten fullt eller tomt. Det var viktig å få fram statusen på pumpen på tankriggen på en tydelig måte. Vi valgte å fortsette trenden med grønt fyll når ting i systemet var åpent, eller på. Dette gjorde vi også for pumpa, men i tillegg ville vi endre posisjon på symbolet for å tydeliggjøre om pumpa var på eller av. Vi ville derfor vri symbolet 90 grader når pumpa var slått av. Figur 74 InTouch Pumpe Side 46 av 75

Dette gjøres ganske enkelt i Animation Links->Orientation. Man skriver inn hva verdien på taggen er i posisjonene maksimum moturs og maksimum medurs, i tillegg til hvor mange grader man vil at symbolet skal vris og i hvilken retning i forhold til startposisjon. Figur 75 InTouch Animering pumpe Til slutt lagde vi rørene mellom de forskjellige komponentene på riggen. Vi valgte å animere rørene for å tydeliggjøre hvor det faktisk renner vann i rørsystemet. Fyllet endrer dermed farge i forhold til hvilke komponenter som er åpen eller lukket. På denne måten kan enhver person oppfatte hva som skjer i prosessbildet. Dette vil i tillegg få fram statusen på de forskjellige komponentene på en bedre måte enn om rørene hadde en konstant farge. Vi valgte selvfølgelig blå farge når det renner vann i rørene, mens vi valgte en mørkgrå tone når rørene er tomme. Grunnen til dette var for å skille rørene fra bakgrunnen og i tillegg få en kontrast til tanken i tom tilstand. Figur 76 InTouch Animering rør/ventil Vi valgte å legge til små vinduer med de forskjellige målte verdiene slik at man i tillegg til å se på de grafiske modellene, kan lese av en eksakt verdi for målingene. Figur 77 InTouch display av verdier Side 47 av 75

Vi valgte å plassere prosessbildet i midten av fanen for å framheve at dette er midtpunktet i hele programmet. Til venstre begynte vi å plassere små ruter for de forskjellige parameterne på regulatoren og foroverkoblingen. Vi skiller mellom de forskjellige gruppene parametere ved å ramme de inn slik som vist på figur 78. Vi valgte radioknapper for å bytte mellom P og PI for regulatoren, og P, D og PD for foroverkoblingen. Disse ble valgt på grunn av det enkle designet, samt at man lett ser hva slags innstilling man står i. Figur 78 InTouch Regulator parametere Vi valgte å se på de tre utløpsventilene som en ventil når vi setter den fra Intouch. Vi laget derfor fire knapper som setter utløpet i prosent. Statusen på ventilene vises fortsatt som tre individuelle ventiler på prosessbildet. Vi valgte å gjøre det på denne måten for å gjøre presentasjonen så enkel som mulig. Da kan man enkelt hoppe fra én åpen ventil til tre åpne ventiler i ett klikk. Figur 79 InTouch Knapper utløpsventiler For innstillingene av pumpa og det manuelle pådraget valgte vi trykknapper som vist i figur 80. Grunnen til dette var at disse funksjonene skal kunne styres både fra Intouch og ix Panelet, noe som gjør at sett og reset-knapper er mest hensiktsmessig. Da kan begge funksjonene styres og endres samtidig av både Intouch og ix panelet. Det vil si at om pumpa startes i Intouch vises dette i ix panelet. Figur 80 InTouch Knapper Side 48 av 75

Sanntidstrender er viktig for å vise utviklingen av en prosess den siste tiden. En egen sanntidsfane ble laget med to forskjellige trender. Den ene viser nivået med referansen og pådraget. Den andre viser pådrag og flow i forhold til hverandre. Begge viser trenden de siste 5 minuttene. I tillegg til dette ønsket vi å ha en trend i hovedfanen slik at man lett kan se hva som har skjedd i prosessen uten å bytte fane. Dette er hjelpsomt om man er borte fra arbeidsstasjonen i en stund eller opptatt med noe annet i et øyeblikk. I figur 81 vises innstillingene for et sanntidstrendvindu. Vi ser hvordan trenden blir med disse innstillingene også. Figur 81 InTouch Trender En historisk trend ble også laget slik at man kan søke seg tilbake flere timer eller dager for å se hvordan utviklingen av prosessen har vært over lengre tid. Dette kan være viktig om man ser at prosessen ikke er som den skal og man vil finne ut når dette skjedde, og hva som skjedde med de andre målte verdiene. 2.6.3 Design ix-panel (Skrevet av AA) For En-tank prosjektet ligger det klare føringer i oppgaveteksten for hvilke betjeningsmuligheter man skal ha på operatørpanelet. Dette operatørpanelet vil ikke ha brukerkontroll i form av innlogging eller andre sperrer. Dermed er det hensiktsmessig å ikke legge for mange innstillingsrettigheter på operatørpanelet. Derfor er det hos oss kun mulig å bytte mellom manuell og automatisk regulator. Man må også ha muligheten for å sette manuelt pådrag for regulatoren i manuell modus. Man kan også sette referanse fra operatørpanelet. Da operatørpanelet kun er ett alternativ til InTouch, må man lage skjermbildene slik at de ikke overstyrer og blokkerer for hverandre. Dette løser man med å velge variabler/tagger som har muligheten til både å lese og skrive. Disse «Read/Write» variablene velger man i starten av prosjektet under opprettelsen av tagger. Disse kommuniserer mot ett dataregister eller ett bit i master-plsen. Her leser det stadig av verdien, slik at panelet vil vise riktig verdi dersom verdien endres fra ett annet sted enn operatørpanelet. Dette er viktig for å unngå forvirring. Side 49 av 75

Dersom kommunikasjonen mellom operatørpanelet og controlleren faller ut, vil man få feilmeldingen «comm err station 1». Da fungerer selvfølgelig ikke panelet på noen som helst måte. Operatørpanelet har vi designet slik at det skal være enkelt å finne den informasjonen du er ute etter. Det skal ikke ha for mange momenter som tiltrekker seg din oppmerksomhet uten å være viktig. Derfor bruker vi grå og rolige farger. Ved grafisk illustrering bør man holde grafikken på ett fornuftig nivå. Her kan det fort bli for mye unødvendige illustrasjoner. Vi har valgt å kun animere tanken for å vise nivået. Alle de andre komponenter i systemet har vi laget lamper og brytere til. Dette fordi vi mener at alle rør og detaljerte tegninger over prosessen hører hjemme på InTouch, og kun vil virke forstyrrende på operatørpanelet. Operatøren kjenner likevel prosessen, slik at vi trenger ikke vise hvor pumpen henter vannet, og hvor den leverer det. Ventilene er også åpenbart i bunnen. Slike animasjoner og grafikk virker ofte mot sin hensikt. Det viser seg at analoge animerte verdier oppfattes raskere og enklere av mennesker enn digitale verdier. Dette er grunnen til at vi animerer tankverdien. Informasjonen på operatørpanelet bør deles inn i ulike grupper ut ifra hvor i prosessen de forskjellige komponentene befinner seg. Man kan også dele opp i forskjellige komponentkategorier og funksjoner i egne «rammer» på skjermen. Dette gjør at man enklere finner riktig komponent. Vi har total fem vinduer å velge mellom i operatørpanelet Oversiksvindu 2 x trendvinduer Vindu for Innstillinger Alarmvindu Navigasjonen mellom vinduene gjøres ved hjelp av knapper plassert i bunnen av skjermbildene. Vinduet som heter Oversikt er utgangsvinduet vårt som man kan navigere frem og tilbake fra. Figur 82 ix-panel Navigasjonsmuligheter Side 50 av 75

Oversiktsbilde Det første vinduet om kommer opp er et oversiktsbilde hvor nødvendig informasjon vises og man kan bestemme utløpet man vil ha. Hver knapp og indikator er knyttet opp mot en tag som gjør kommunikasjonen mellom panelet og PLS mulig. Helt til høyre i panelet står det en indikator som leser nivået i tanken, det er også en rute som viser nivået i prosent. Figur 83 ix-panel Nivåindikator I bildet over vises hvordan indikatoren er knyttet til tag Niva_tank_1, mer om tagger er beskrevet senere i dette avsnittet. En utfordring med knappene i panelet var å få de til å gi pulser i stedet for å sette en verdi høy hele tiden. Eksempelvis hvis det ønskes 33% utløp, og det trykkes på knappen for 33% utløp vil den sette en minnecelle høy i PLS, og den vil derfor være «oppbrukt». Dette løste vi med en innebygd funksjon i ix Developer som lar oss sette og resette taggene ved forskjellige handlinger. Vi har valg at taggen settes når knappen blir trykt ned, og resatt når den slippes opp. Figur 84 ix-panel Actions til knapper Side 51 av 75

Trend Vi ønsker å kunne vise historisk trend på operatørpanelet. Dette for at operatøren ute i felt ønsker å raskt kunne se om prosessen tilfredsstiller kravene som stilles. Figur 85 ix-panel Trendvindu Dette trenger ikke å være avansert, med god oppløsning, kun en rask visning av hvordan ting utvikler seg. ixpanelet har muligheten til å vise flere grafer i samme vindu. Dette er greit når dataen som skal vises er innenfor omtrent samme område. Dersom det er store sprik i størrelsene på verdiene bør man bruke flere trendvinduer. Dette for at vi skal få en grei oppløsning på Y- aksen. Hos oss ønsker vi å vise settpunkt, nivå og pådrag. Alle disse verdiene er i prosent, og kan da vises i ett vindu med grei skalering av Y-aksen. Figur 86 ix-panel Trendkurver oppsett Man velger selv hvor lang tid man ønsker å vise i trendvinduet. Dersom prosessen er rask, bør man velge ett kort tids-intervall for å få ei grei oppløsning i grafen. Hvis prosessen har en form for svingninger kan det være lurt å ha ett mye lenger tidsvindu enn periodetiden på svingningene. Da spiller ikke oppløsningen på kurven noen stor rolle, men derimot muligheten til å se flere svingninger på samme bilde. Dette gjør at man kan danne seg ett bilde av om svingningene tiltar eller avtar i amplitude. Her bør man ha muligheten til å se mange svingninger for å se hvordan de forskjellige innsvingningsforløpene ser ut med forskjellige innstillinger. Når man arbeider med å trimme inn en prosess, kan det noen ganger være ønskelig å stanse loggingen for å se nøyere på en spesiell tidsperiode. Dette kan man enkelt gjøre i ix-panelet. Man oppretter bare en knapp som man tildeler de riktige egenskapene i forhold til trendviseren. Dersom man under logging opplever kommunikasjonsproblemer mellom operatørpanelet og controlleren den er tilkoblet vil man se på kurvene at tegningen stanser i den perioden kommunikasjonen er nede. Kurvetegning starter igjen automatisk når kommunikasjon på nytt er etablert. Vi har to trendvinduer i panelet, et med en oppløsning på ett minutt og et med oppløsning på en time. Side 52 av 75

Innstillinger På en arbeidsplass med hvor de ansatte har varierende kunnskap om utstyret kan det lønne seg å sortere hvem som skal få gjøre kritiske forandringer på systemet. Det er kritisk at regulatorparameterne blir forandret av en som vet hva han driver med. Vinduet for innstillinger er derfor brukerbegrenset. Figur 87 ix-panel Skjermbilde Instillinger Her kan regulatorparameterene leses og skrives, og man kan bytte fra Auto til Manuell og fra P til PI. Lampene indikerer hva som er av og hva som er på ved grå og grønn farge. Dette er gjort ved å knytte de til statusminneceller. Byttet mellom P og PI gjøres ved at en minnecelle settes høy ved PIregulering og resettes ved P-regulering. Vi har valgt å ha med indikatoren for nivået i tanken her slik at man hele tiden har god oversikt over prosessen. Figur 88 ix-panel Indikatorfarger Side 53 av 75

2.6.4 Alarmhåndtering InTouch (Skrevet av MB) Det første vi måtte gjøre var å la Intouch få vite hvilke tagger som skal gi alarm. Dette gjøres i Tagname Dictionary. I figur 2.6.4.1 under kan man se dette vinduet. Hvis vi klikker på alarmer kan vi velge om det skal gå alarm når taggen går høy under Alarm state. Siden alle våre alarmer er diskrete er dette det eneste vi trenger å gjøre for at en tag skal gi alarm. I tillegg kan vi velge hvilken prioritet alarmen skal ha under Priority. Prioriteten på alarmene går fra 1-249 for kritisk prioritet, 250-499 for høy prioritet, 500-749 for liten prioritet og 750-999 for de som kun er til informasjon. I tillegg kan vi legge inn en kommentar som skal vises i alarmvinduet når en eventuell alarm går. Figur 89 InTouch Alarmtag Alarmhåndteringen i Intouch blir utført fra et eget vindu kalt «alarmer». Knappen for å komme til denne siden ligger på menylinjen øverst i programbildet. Her skal vi kunne lese alarmer som har gått, kvittere alarmer, og lese alarmer som er kvittert. Vi valgte å legge inn et vindu som lister alle alarmer som går. Dette vinduet ligger forhåndslaget i InTouch. Her får vi oppgitt massse info om alarmen blant annet tidspunkt for alarmen, hvilket prioritet alarmen har og operatøren som var innlogget ved alarmtidspunktet. Figur 90 InTouch Alarmvindu Side 54 av 75

Vi trengte også en måte å kvittere alarmene på. Dette kan gjøres ved å høyreklikke på det forhåndslagde alarmvinduet og kvittere derfra, men vi ville ha en enklere måte å gjøre dette på. I tillegg til å kvittere alarmene i InTouch måtte vi også sende en kvittering til PLS for å kunne starte pumpe og slukke alarmlampe på riggen. Dette ble kombinert ved å lage en knapp som kvitterer alarmene både i Intouch og i PLSen. I menyen Animation Links->Touch Pushbuttons->Action kan vi skrive et skript som utfører flere aksjoner i Intouch ved forskjellige steg i utførelsen av selve trykket på knappen. I figur 91 ser vi hvordan vi kvitterer for alarmene i Intouch samtidig som vi setter taggen som kvitterer alarmer i PLSen høy når venstre museknapp trykkes ned. For å resette taggen som kvitterer i PLS velger vi at når venstre museknapp slippes skal kvitteringstaggen settes lav igjen. På denne måten sender vi kun en puls ned til PLS. Dette fordi kvitteringen i PLSen skjer på puls. Figur 91 InTouch Kvitterings script Det som nå gjensto var å finne en måte å alarmere operatøren på, på en enkel men effektiv måte. Vi ble enig om at hvis knappen som åpner alarmvinduet blinker rødt ved alarm ville dette være hensiktsmessig på flere måter. Først og fremst fordi knappen er ganske stor i seg selv så hvis det blinker rødt rundt den ville dette vises veldig godt i programvinduet. I tillegg viser det med en gang hvor operatøren skal klikke for å finne ut alle detaljer om hva det er som har skjedd. Dette ble gjennomført ved delvis å gjemme en rød rute bak alarmknappen som kun vises og blinker ved alarmtilstand. Figur 92 InTouch Alarmknapp animering Under Animation Links->Miscellaneous->Blink gjøres dette ganske lett ved å velge en tagg som skal bestemme når den røde ruten skal blinke. Vi krysser av for at den skal «Blink Invisible». Så går vi under Visibility og velger at når taggen som gjør at ruten blinker går lav, skal ruten ikke vises i det hele tatt. Dette er vist i figur 93. Side 55 av 75

Figur 93 InTouch Oppsett blinking alarm For å gi operatøren en viss anelse om hvilken alarm det er som har gått laget vi tre lamper for de tre alarmkategoriene vi har på dette prosjektet. Vi laget en for kommunikasjonen mellom master- og slave-pls, en for kritisk alarm som gjelder nivået i tanken, og en for vanlig alarm som gjelder for store avvik fra referansen. Figur 94 InTouch Alarm indikatorer Side 56 av 75

2.6.5 Alarmhåndtering ix-panel (Skrevet av AA) Ix Developer programmet har en egen alarmkontroller. I denne kontrolleren kan man legge til tagger som skal gi alarm på panelet. Man har muligheter til å lage alle betingelsene for alarm lokalt i operatørpanelet. Dette kan eksempelvis være: «Nivå>65». Dette vil gi en alarm når verdien for taggen «nivå» overstiger 65. Man kan også lage digitale alarmer ved å gi betingelsen >0. Normalt bør man holde opprettelsen av alarmer til PLSen. Dette på grunn av at alarmer bør opprettes på ett sted for å ha et godt system i alarmene. Figur 95 ix-panel Alarmvindu Det å få Ack et alarmene på panelet og videre i PLS viste seg å bli et problem når vi brukte standardoppsettet i ix-developer. I standardoppsettet ligger det en Ack-knapp ved clearknappen i bildet over. Problemet var at vi ikke fikk resatt minnecellen vi heftet til knappen. Løsningen ble å lage «Ack all alarms»- knappen som setter og resetter minnecellen ved trykk som nevnt tidligere. I alarmserveren lager man en tekst som vil bli den teksten som vises på skjermen i det alarmen trigges. Dette bør være kort, men beskrivende for hvilken tilstand som har oppstått. Dette for å raskt kunne få forståelse for hva som har skjedd. Figur 96 ix-panel Alarmserver Side 57 av 75

Man bør gi en alarm for den første feilen som oppstår. Feil som oppstår som en følge av den første feilen bør ikke gi alarm, da de som regel er «følgefeil», og ikke relevant. Hvordan dette skal presenteres velger man blant mange alternativ i menyen. Dersom man har flere operatørpanel eller skjermsystemer bør man velge en metode som avstiller og resetter alarmene på alle steder samtidig. Dette gjøres ved å velge «Remote Acknowledge» i innstillingene. Dette vil være et bit som kommer fra controlleren, men kan settes hvor som helst blant operatørpanelene. Dersom man kun har ett operatørpanel trenger man ikke å bruke denne funksjonen, da alarmviseren har en innebygget knapp for resetting av alarmer. 2.6.6 Operatørnivåer og rettigheter (Skrevet av AA) Både i InTouch og på operatørpanelet har vi laget forskjellige nivåer av rettigheter. Her vil vi tildele forskjellige muligheter til de ulike nivåene av kompetanse brukerne sitter med. Det laveste nivået 1 vil ha muligheter til å lese av driftsstatus på deler av prosessen, samt noen alarmer. Denne brukeren vil ha sterk begrensede muligheter for å skrive inn ny data til prosessen. Nivå 2 vil være den typiske operatøren som kjenner prosessen godt, og som vet hva han/hun holder på med. Dette vil tillate endring av settpunkt, samt kvittering av alarmer. Dette vil være nok rettigheter til å kjøre prosessen i en normal driftssituasjon. Nivå 3 vil være «superbrukeren». Dette er personell som har dyptgående kompetanse, og har ofte vært deltagende i designet av anlegget. Disse kan endre på måten prosessen kjøres på. Dette vil være endring av regulatortype og regulatorparameter. Her vil man som regel være svært restriktiv i å tildele personell tilgang, da disse innstillingene ofte er ett resultat av erfaringene fra lang tids drift av anlegget. Side 58 av 75

Rettigheter for tilgangsnivåer i InTouch Variabel Leses Skrives Operatør 1 Operatør 2 Operatør 3 Operatør 1 Operatør 2 Operatør 3 Referanse X X X X X Nivå I tank X X X Kp til regulator X X Ti til regulator X X U0 til regulator X X Valg mellom P- og PI-regulator X X X KpFF til regulator X X TdFF til regulator X X NFF til regulator X X Valg av forroverkoblingstype. X X X Ingen, P, D, eller PD Magnetventiler utløp X X X Utstrømming fra X X X gjennomstrømningsmåler Start/stopp tilstand til pumpe X X X X X Auto/manuell tilstand X X X X X Pådrag X X X X X Melding om alarmer X X X Kvittering av alarmer X X Samplingstid tank X X Side 59 av 75

Rettigheter for tilgangsnivåer i ix-panelet Variabel Alle Operatør 3 Skrive Lese Skrive Lese Referanse X X X X Ekstra Manuelt pådrag X X X X Modus: Auto / Manuell X X X X Pådrag - X - X Nivå i tank - X - X Melding om alarmer - X - X Kvittering alarm X X Start/stopp pumpe X X X X Kp til regulator X X * Ti til regulator X X * Samplingstid X X * KpFF til foroverkobling X X * TdFF til foroverkobling X X * NFF til foroverkobling X X * Valg av modus serieregulator, X X * P/PI Åpning utløp, magnetventiler X X X X * Vi har valgt å legge til noen ekstra funksjoner til ix-panelet, utover de som er beskrevet i oppgaveteksten. Alle disse krever at brukeren logger inn med tilgangsnivå «Operatør 3». Side 60 av 75

Innlogging ix panel Vi har i utgangspunktet ikke laget noen innlogging for bruk av operatørpanelet. Dette for at det skal være raskt og enkelt å bruke. På siden for innstillinger har vi likevel valgt å legge noen restriksjoner. Vi har laget knappen som sender deg til bildet «Innstillinger» på en slik måte at den kun er synlig når man har logget seg inn med brukeren «Operatør3» som i InTouch har alle rettigheter. Dette vil forhindre at en uautorisert bruker roter til innstillingene i prosessen. Figur 97 ix-panel innlogging Man kan også gjøre det nødvendig å logge seg inn for i det hele tatt å bruke panelet. Dette vi være aktuelt i områder der ikke-kyndige ferdes, og i offentlige rom. Da er det også lurt å benytte seg av muligheten for at panelet automatisk logger ut brukeren dersom denne er inaktiv i noen minutter. Dersom det er påkrevd kan man lage flere nivåer i rettighetene. Dette kan gjøres for å la noen personer endre standard verdier som settpunkt, modus, pådrag etc. Andre derimot kan ha tilgang til å endre regulatorinnstillinger, alarmgrenser, slette loggfiler eller andre kritiske håndgrep. Figur 98 ix-panel operatørnivåer Side 61 av 75

2.6.7 Web-grensesnitt for ix panel (Skrevet av ØE) ix TA-100 panelet har mulighet til å settes opp med webgrensesnitt, for fjernstyring av prosessen. Det er flere måter å gjøre dette på. Panelet har en innebygget webserver, som viser en hjemmeside som ligger lagret i panelet, denne er kommuniserer. Panelet kan også settes opp slik at man koblet til via en Java Server, som viser skjermbildene fra panelet i webleseren. Via hjemmesiden (http://www.hekta.org/~p2ea1) er det lagt ut link til begge funksjonene. Webgrensesnitt Figur 99 ix-panel Webgrensesnitt For å lese ut og sette verdier benyttes det et innebygget Java Script i panelet. Vi hadde kun dokumentasjon på hvordan vi leste/skrev til dataregistre, og ikke til bit. Derfor fungerer ikke funksjonene som styrer pumpen, utløpet og kvittering av alarmer fra webgrensesnittet. Webgrensesnittet er kodet helt fra bunnen av, og formattert som selve hjemmesiden. Se kapittel 1.3 Hjemmesidefor mer informasjon om hvordan hjemmesiden er bygget opp. Figur 100 ix-panel HTML kode eksempel I figuren over ser vi eksempel på koden for å lese og endre referansen til systemet. Denne skriver til selve taggen i ix panelet. For å komme inn på webgrensesnittet må du logge inn. Brukernavn: Op3 Passord: gruppe1 Side 62 av 75

Javagrensesnitt Når du logger inn ved hjelp av Java Serveren vil du få opp samme bilde som vises på skjermen til panelet, bare via webleseren. Link til å logge på finner du på hjemmesiden (http://www.hekta.org/~p2ea1). I panelet ligger det en eldre versjon av Java, versjon 7.0. Denne har flere sikkerhetshull, og sider som kjører denne versjonen blir automatisk blokkert av nyere versjoner av Java. Derfor må vi nedgradere versjonen av Java til en eldre, for å få denne funksjonen til å fungere. Dette medfører en sikkerhetsrisiko som vi ikke anbefaler. En bedre løsning vil være å fjernstyre PCen med InTouch på. Enten via RemoteDesktop i Windows eller programvare, som for eksempel TeamViewer. På den måten vil vi få samme muligheter til å betjene systemet som i InTouch. Side 63 av 75

2.7 Simulering Her kommer utdrag fra simuleringsnotatet som ble utformet tidligere i prosjektet. Hele Simuleringsnotatet finner du som vedlegg til denne rapporten, eller på hjemmesiden (http://www.hekta.org/~p2ea1). I simuleringsnotatet er det gjort en feil i modellen for utløpet, hvor maksimal utstrømning i FT01 er beregnet feil. Feilen ligger i at det er lagt til «offset» på +4mA to ganger. 2.7.1 Serieregulering (Skrevet av ØE) Figur 101 Simulering Serieregulering Ved bruk av serieregulering, regulerer vi på avviket mellom referansen og den målte verdien. Ziegler-Nichols metode For å komme frem til passende regulatorparametere har vi benyttet Ziegler-Nichols metode. Der har vi koblet vekk integrator delen av regulatoren, og skrudd opp Kp til vi har fått stående svingninger. Denne verdien for Kp blir den Ziegler Nicholls - Stående svingninger kritiske verdien, Kk. I vårt tilfelle var Kk = 20. Vi måler så periodetiden, som blir den kritiske periodetiden. Tk = 4.9 sekunder. PI-regulator: K p = 0.45 K k = 9.0 Figur 102 Simulering Ziegler-Nichols Tid i sekunder T i = 0.85 T k = 4.165 sek P-regulator: K p = 0.5 K k = 10 Side 64 av 75

Etterjustering Vi ser av grafene i 3.1.2 at vi har et innsvingningsforløp som er mer likt «minimum amplitude», hvor vi har rundt 10 svingninger før det blir stasjonært. Vi ønsker «minimum areal», hvor vi kun har ca. 4-6 svingninger. For å få til dette må vi etterjustere. Ser på faseforskyvningen mellom den målte verdien og pådraget fra regulatoren. Blå kurve: Målt verdi,y. Rød kurve: Pådrag, u Pådraget og den målte verdien ligger ca. 180 forskjøvet i forhold til hverandre. Dette tyder på at vi har P-svingninger, som vi må etterjustere for. [Kilde: Reguleringsteknikk Grunnkurs: Bjørvik og Hveem, s. 55] Figur 103 Simulering Etterjustering Tid i sekunder Blå kurve: Ziegler-Nichols Rød kurve: Etterjustert Vi forsøker å senke P-forsterkningen. Da vil vi få en langsommere og roligere prosess. Vi ender opp med en P- forsterkning på 5.5, med I-tid på 4.165 som vi fikk fra 3.1.1 Figur 104 Simulering Etterjustering Tid i sekunder Side 65 av 75

2.7.2 Foroverkobling (Skrevet av TM) I tillegg til en serieregulering av tanken, skulle vi dimensjonere en foroverkobling i reguleringssløyfen. En foroverkobling er enkelt forklart en ekstra regulator som leser direkte på forstyrrelsen, og kompenserer ved endringer. Figur 105 Simulering Forenklet foroverkobling Styrken til en foroverkobling er at man får kompensert for forstyrrelsen før den rekker å påvirke systemet i stor grad. I vårt tilfelle vil det si at foroverkoblingen registrerer økt flow ut av tanken hvis vi lukker to ventiler, og den vil kompensere ved å bidra til økt pådrag. Dette er mye raskere enn at vi skal få et avvik som registreres av nivåmåleren. Figur 106 Simulering Modell for foroverkobling Illustrasjonen viser hvordan vi har modellert foroverkoblingen i simulink. Side 66 av 75

Vi fikk best resultat ved å bruke PI-regulator som hovedregulator, og PD-regulator til foroverkoblingen. Vi brukte følgende innstillinger: PI-reg: P: 5.5 I-tid: 4.165 sekunder PD-foroverkobling: P: 0.75 D-tid: 0.25 Vi fikk da følgende innsvingningsforløp: Innsvingningsforløp med PI-reg, og PD-foroverkobling Dette ga det minste dynamiske avviket og den korteste innsvingningstiden. Vi har også rundt 4 halvperioder i innsvingningene, slik vi skal ha i «minimum areal». Tid i sekunder Figur 107 Simulering Innsvingningsforløp med PD-foroverkobling Side 67 av 75

3.0 Innregulering (Skrevet av ØE og MB) 3.1 Krav til reguleringen Reguleringsmetodene som kan benyttes er følgende: Serieregulering: P-Regulator med nominelt pådrag. PI-Regulator (uten nom. pådrag). Foroverkobling: P-regulator med P-regulator foroverkobling PI-regulator med P-regulator foroverkobling. P-regulator med D-regulator foroverkobling. PI-regulator med D-regulator foroverkobling. P-regulator med PD-regulator foroverkobling. PI-regulator med PD-regulator foroverkobling. Kravene til reguleringen er: Intet stasjonært avvik. Innsvingningsforløp av typen «minimum areal». Kjappest mulig innsvingning til ±2% av måleområdet når referansen er 60%. For å klare kravet om intet stasjonært avvik må hovedregulatoren være av typen PI. 3.2 Manuelle innjusteringsmetoder Ziegler-Nichols For å finne regulatorparametere som fungere til prosessen prøvde vi først Ziegler-Nichols metode. Den går ut på å bruke kun P-regulator, for så å justere opp forsterkningen til vi får stående svingninger i prosessen. På denne måten finner vi kritisk forsterkning, Kk, til systemet. Periodetiden til svingningene utgjør den kritiske periodetiden, Tk. Vi hadde store problemer med å få stående svingninger i systemet. Vi prøvde helt opp til Kk = 60, noe som ville gitt en usannsynlig høy Kp i systemet. Vi måtte derfor gå over til en annen strategi for å finne parameterne. Side 68 av 75

Manuell selvjustering Manuell selvjustering går ut på å bruke en P-regulator med maksimal P-forsterkning, som en Av/Påregulator. Ved å lese av grafen, og benytte formelen for Kk og Tk, finner vi forslag til parameterne. Figur 108 Manuell selvjustering K k = Topp til bunn pådrag Topp til bunn prosessverdi 100 1.27 = 1.27 = 15.875 8 T k = periodetid for en svingning = 14 sek Bruker tabellen for Ziegler-Nichols for å finne Kp og Ti for PI-reg: K p = 0.45 K k = 7.14 T i = 0.85 T k = 11.9 sek 3.3 Serieregulering Her har vi benyttet parameterne vi fant i 3.2. Sprang i utløpet, fra 1 til 3 ventiler åpne. Vi ser at innsvingningsforløpet er innenfor kravet om ±2% av referansen innen ca. 3 sekunder. Vi har heller ikke innsvingningsforløp som er av typen «minimum areal». Vi har 1-2 halvperioder, noe som gir oss «minimum forstyrrelse». Figur 109 Serieregulering Side 69 av 75

Vi har prøvd å senke P-forsterkningen for å komme nærmere et innsvingningsforløp av typen «minimum areal», men siden dynamikken til systemet er så hurtig, får vi sjeldent oversving i innsvingningsforløpet. Ved å kun benytte de tre magnetventilene i utløpet får vi ikke store utslag i det dynamiske avviket. 3.4 Foroverkobling Siden systemet i utgangspunktet er ganske hurtig, vil det være tilstrekkelig med å kun bruke serieregulering. Foroverkoblingen vil gjøre innsvingningen enda kjappere, når det kommer forstyrrelser i utløpet. Forskjellen er at vi nå får et oversving med i innsvingningsforløpet. Vi har prøvd med PD-foroverkobling, hvor vi har valgt KpFF = 0.7 og TdFF = 0.3 Vi ser at det dynamiske avviket ikke går utover grensen på ±2% av referansen. Figur 110 Foroverkobling Side 70 av 75