ENTANK 2EA GRUPPE

Transkript

1 ENTANK EA GRUPPE

2

3 Forord [EAH] Entankrapporten er en del av et stort prosjektarbeid som vi fikk tildelt våren 2015 i faget Styresystemer og reguleringsteknikk. Prosjektgruppen består av Erik Heggstad, Herman Bråten Romnes, Jonas Kalland, Necati Yayan, Gøran Moksnes Sæther og Jens Cappelen Andresen. Etter at gruppen hadde levert inn miniprosjektrapporten til arbeidsgiver, tok gruppen fatt på å modellere prosessen i Simulink, lage program i PLS og program for HMI. De har også bygget et filter for filtrering av støyen i nivåmålingene av tanken og støyen fra magnetventilene. Resultatet av modellering og simulering av prosessen er tatt med som vedlegg for entankrapporten. Prosjektarbeidet har hjulpet oss i gruppen med å få bedre innsikt i hverdagen til en automasjonsingeniør, og hva slags arbeidsoppgaver en har. Vi har også fått med oss god erfaring innenfor prosjektarbeid og prosjektstyring. Vi er svært takknemlig for veiledningen vi har fått hos Dag Aune gjennom prosjektet, og ønsker å takke han for god støtte og tilbakemeldinger. Jens C. Andresen Jonas G. Kalland Gøran M. Sæther Erik Heggstad Herman B. Romnes Necati Yayan

4 Sammendrag [EAH] Arbeidsoppgavene prosjektgruppen har arbeidet med: Utvikling av brukergrensesnitt til PC og Touchskjerm. Utvikling av PLS programmer i h.h.t. Problemstilling. Kommunikasjonen mellom PLS og grensesnitt. Simulering og konstruering av anti-aliasfilter. Simulering og modellering av systemet, med tilhørende simuleringsnotat. Problemstillingen vi har i oppgave er å lage styring- og reguleringen til et tankanlegg, samt to forskjellige brukergrensesnitt. Ett brukergrensesnitt for operatørpanelet som er montert på framsiden av el-tavlen og ett for skjermstyringen som vises på operatør PC-en. Vi skal overvåke og styre nivået til en tank som har innløps- og utløpsventiler. Dette skal programmeres i fra bunnen av, ved hjelp av en master PLS og to slaver PLS er, som skal snakke sammen over PROFIBUS. Det skal også programmeres et alarmsystem. Gruppen har delt opp arbeidsoppgavene i forhold til entankprosjektet, og på slutten av prosessen skal hver og en sitt arbeid settes sammen og testes ut i fra de spesifikasjonene som er gitt i oppgaveteksten. Selv om arbeidsoppgavene er blitt fordelt, er det hver og en sin oppgave å sørge for at de til en hver tid får ett innblikk innenfor de ulike fagfeltene.

5 Innholdsfortegnelse 1 Innledning [NY] Oppgavetekst [HBR] Teknisk del [NY] Problemstilling Prosessbeskrivelse [HBR] Prosjektmål [NY] Effektmål Resultatmål Prosessmål Prosjektbeskrivelse [NY] Spesifikasjoner [NY] PLS-Master PLS-Slave InTouch Alarmer [HBR] ix-panel [HBR] Nettside [HBR] PLS-programmering Master PLS [GMS] Profibus programbit Kommunikasjon_Slave_1 programbit: Slave 1 PLS [JK] AD_DA [GMS] Alarm [GMS] Profibus [GMS]... 28

6 7.2.4 Regulator [GMS] Regulatorblokken [JK] Samplingsklokken [JK] Direkte og reversert regulering [JK] P-regulator [JK] PI-regulator Foroverkobling Rykkfri overgang (bumpless transfer) InTouch [JA] Innledning Sikkerhet, innlogging og tilgangsnivå Oversikt over brukerne Innloggingsvindu Menylinjen Prosessbildet Skjermbildet for Operatør Skjermbildet for Operatør Skjermbildet for Operatør Oppsett av knapper Oppsett av sanntidstrend Historikk-bildet Alarmer Kommunikasjon-bildet Skript ix-panel [EAH] Innlogging/Hovedbildet [EAH] Prosess [EAH] Alarmer [EAH]... 70

7 8.4 Historikk [EAH] Kommunikasjon [EAH] Programmering i ix Developer [EAH] Figurer [EAH] Tags [EAH] Alarmer [EAH] Datalogging [EAH] Web-server [EAH] Antialiasingfilter [HBR og NY] Nivåmåler [HBR og NY] Strømningsmåler [HBR og NY] Konklusjon filter [HBR og NY] Test av tankens regulering [HBR og NY] Tidsforbruk [JA] Litteraturliste Vedleggsliste... 93

8 Figurliste Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur

9 Figur Figur 7.21 Regulatorens funksjonsblokk Figur 7.22 Samplingsklokken i GX Works Figur 7.23 Utregning av avvik Figur 7.24 P-regulator Figur 7.25 PI-regulator Figur Foroverkobling Figur 7.27 Foroverkobling med D-forsterkning, usammenhengende for å få med hele bildet Figur 7.28 PD-forsterkning Figur Figur Figur Figur 8.3 Vindusskriptet for innloggingsvinduet Figur 8.4 Ikke innlogget Figur Logg inn-knappskriptet Figur 8.6 Innlogging Figur 8.7 Logget inn som Operatør Figur 8.8 Menylinjen Figur 8.9 Oppbygging av brukergrensesnittet Figur 8.10 Prosessbildet Figur 8.11 Prosessbildet for Operatør Figur 2.12 Prosessbildet for operatør Figur 2.13 Prosessbildet for operatør Figur 8.14 Oppsett av knapp, Visibility og Disable Figur 8.15 Oppsett av knapp, Line Color... 58

10 Figur 8.16 Sanntidstrend Figur 8.17 Oppsett av sanntidstrend Figur 8.18 Historikk-skjermbildet Figur 8.18 Wizard Selection Figur 8.19 Vindusskript for start og stopp av logging Figur 8.20 Oppsett av kvitteringsknappene Figur 8.21 Condition-skript Figur 2.22 Kommunikasjon Figur 8.23 Window Script for Prosess Figur Oppstartsbildet/logginn Figur Prosessoversikt Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur Figur

11 Figur Figur Støymåling av nivåmåler Figur Andreordens filter Figur Andreordens filter Figur 11.4 Testing av filteret i Multisim Figur Pol i venstre halvplan Figur 11.6 Støysignalet fra utløpet Figur Førsteordens filter Figur 13.2 Utstrømningssignal før og etter filtrering Figur 13.3 Simulering av prosess med P-regulator, PI-regulator, PI-regulator med PD foroverkobling. Sprang fra 3 åpne ventiler til 1 åpen ventil Figur 13.4 Finjusterte reguleringsparametere med foroverkobling Figur 13.5 Finjusterte reguleringsparametere uten foroverkobling Figur

12 Tabell-liste Tabell Tabell Tabell Tabell Tabell Tabell Tabell Tabell Tabell Tabell Tabell 9.1 som viser ønskede skrive- og leserettigheter for operatørpanelet Tabell 9.2 som viser ekstra skrive- og leserettigheter for operatørpanelet Tabell 13.1 Modulerte regulatorparametere Tabell 13.2 Tabell over finjusterte parameterinnstillinger Formell-liste Formel Formel Formel Formel

13 1 Innledning [NY] Ved Høgskolen i Sør-Trøndelag, HiST, program for Elektro- og Datateknikk, studieretning Automatiseringsteknikk, skal alle ingeniørstudentene gjennomføre ett prosjekt i løpet av vårsemesteret i det andre året. Elevene blir delt opp i grupper på fem til seks elever og får utlevert en oppgave som skal gjennomføres som om det var et prosjekt som forekommer i arbeidslivet. Dette er et større prosjekt hvor både planlegging av prosjektet i et forprosjekt og utførelsen av prosjektet inngår. Studentene skal også presentere prosjektet når arbeidet med det er ferdig. I prosjektet så kreves det at studentene bruker kunnskap de har fått med seg halvveis inn i bachelorprogrammet, og setter det ut i praksis. Samtidig så må studentene for å gjennomføre prosjektet fordype seg innen aktuelle fagområder som inngår i oppgaven. Prosjektet utgjør 12 studiepoeng, dvs. 40 % av et semester, og tidsmessig vil dette utgjøre cirka 320 arbeidstimer per student. Det er faglærerne som leverer ut oppgaven til studentene, og de opptrer selv som veileder og arbeidsgiver under prosjektet. Prosjektet går samtidig som undervisning i store deler av prosjektperioden, mens nærmere slutten av perioden vil det bli mindre undervisninger og mer avsatt tid til jobbing med prosjektet. Entanksprosjektet har vært en videreføring av miniprosjektet. Kommunikasjonen på AD-DAmodulen har blitt videreført til et større program. Vi har modellert prosessen og funnet fram til optimale regulatorinnstillinger som vi har tatt i bruk. Vi har skrevet et PLS-program med HMI for styring og regulering av nivået i tanken. 1

14 2 Oppgavetekst [HBR] Prosjektgruppen skal lage program for InTouch, operatørpanel og PLS ene som oppfyller prosjektkravene når det gjelder styring av den ene tanken på tankriggen ved hjelp av en FX1N-PLS. Dette skal presenteres for veileder og godkjennes som entanksprosjektet. Entanksprosjektet skal dokumenteres i en rapport. Gruppen skal kunne bruke operatørpanelet og InTouch for å sette parametere som referanse, og se at nivået skal svinge stille seg inn på angitt referanse. Det skal bli lagt inn alarmer for angitte nivå i tanken, som vi kan se og behandle i HMI-ene, som er InTouch og IX-panel. Vi skal finne frem til regulatorinnstillinger ved å modellere og simulere prosessen i Simulink. Programmet Gx- Works2 skal bli benyttet for å programmere. Den skal ha et innsvingingsforløp av typen minimum areal. Målet er å oppnå raskest mulig innsvingingstid ved endring i utløpet (magnetventilene) fra 3 åpne til 1 åpen. Programmet skal kunne fungere både som P- og PIregulator med rykkfri overgang ved skifte av regulatortype i tillegg til skifte mellom manuell modus og automatisk modus. Gruppen skal konstruere et filter for å filtrere bort støy i nivået og et filter for filtrering av støy fra flowmåleren, som er utstrømning fra magnetventilene. De skal se hvordan støyen blir filtrert bort ved å koble filtrene til riggen. Gruppen vil gjennomgå egne selvlagde testskjema for «entanksprosjektet» før det skal demonstreres for arbeidsgiver. Arbeidsgiver vil ha eget testskjema som vil bli gjennomgått ved selve demonstrasjonen, for se at alt fungerer etter spesifikasjonene. Nettsiden skal være oppdatert og vil bli evaluert av arbeidsgiver i løpet av entanksprosjektet. 2

15 3 Teknisk del [NY] 3.1 Problemstilling Riggen er allerede ferdigkoblet. Vi må sette oss inn i koblingstegninger for å finne ut hvordan vi skal kjøre sprang på prosessen. Deretter så må vi finne riktige regulatorinnstillinger for prosessen. Det er viktig å modellere prosessen for å kunne oppnå best mulig regulering. Det skal lages 2 anti-aliasfilter, av typen butterworth for å redusere støy på systemet. 2. ordens til nivåtransmitteren og et 1.ordens til flowtransmitteren. Under filterberegningene er det viktig å finne riktige verdier for å få luket bort mest mulig støy og ikke miste nyttesignal. Systemet skal også simuleres og modelleres og et simuleringsnotat skal levers i løpet av perioden som entankdelen av prosjektet går. 3.2 Prosessbeskrivelse [HBR] Systemet reguleres og behandles i slave-plsen, mens den styres fra HMI ene. Det stilles inn ønsket nivå og reguleringsmetode i HMIene, før PLSen sender verdier til ventilen som kontrollerer hvor mye vann som strømmer inn i tanken. Tankriggen har enheter som måler utløp og nivå, som hjelper PLSen til å kontrollere ventilen. På denne måten får PLSens regulator regulert inn nivået til innstilt referanse. Utløpene stilles inn i HMIene, og der kan også alle verdier leses av. 3

16 4 Prosjektmål [NY] 4.1 Effektmål 1. Vise hvordan vi på en god måte kan styre og regulere nivået i en tank. 2. Legge grunnlaget for videre arbeid med riggen til totanksprosjektet. 3. Oppdatere fremgang gjennom nettsida. 4.2 Resultatmål Prosjektgruppen skal: 1. Oppdatere programvare til InTouch og ix-panelet for styring og regulering av nivået i tanken. 2. Programmere PLSen for å regulere nivå og behandle alarm. PLSen skal utvides for å ha mulighet for bruk av foroverkobling. 3. Oppdatere Q-PLS med nye kommunikasjonsadresser. 4. Måle støy, dimensjonere og lage filter. 5. Modellere prosess for å kunne beregne regulatorparametere. 6. Vurdere følgende bonusoppgaver dersom tid: Regulering av nivået ved hjelp av frekvensomformer. 4.3 Prosessmål Studentene skal: 1. Øke kompetansen og forståelsen av styring og regulering av nivå i tank. 2. Øke kompetansen om riktig bruk av grafiske elementer i HMI, i forhold til prosessen. 3. Øke kompetansen om kommunikasjonsprotokollene som knytter de ulike delene sammen. 4. Øke evnen til å lære seg ny teknologi gjennom tilleggsoppgavene. 5. Øke det sosiale samarbeidet og trivselen innad i gruppa. 4

17 5 Prosjektbeskrivelse [NY] I entanksprosjektet har gruppen jobbet med regulering og styring av tanken. Prosessen blir styrt fra IX-panelet og InTouch, og skal regulere seg inn til referanse ved endring i utløp. Entanksprosjektet er «hovedprosjektet», som forprosjektet og miniprosjektet ligger til grunnlag for. De store utfordringene vil komme i denne delen av prosjektet, hvor vi møter problem. Entanksprosjektet vil ligge til grunnlag for totanksprosjektet som vil komme etter entanksprosjektet er ferdig. Det er derfor viktig at entanksprosjektet blir grundig gjennomgått, slik at totanksprosjektet blir enklere å samkjøre med den andre gruppen. Figur 5.1 5

18 6 Spesifikasjoner [NY] 6.1 PLS-Master Anlegget består av to datanettverk som lar styringsenhetene i anlegget kommunisere med hverandre. Dette er et Ethernet og en Profibus-DP feltbuss. MasterPLS-en er en modulbasert PLS av typen Mitsubishi Q00 og skal være bindeleddet mellom nettverkene. MasterPLS-en muliggjør kommunikasjon mellom SlavePLS, koblet til Profibus-DP, og HMI, koblet til Ethernet. Produktspesifikasjoner til MasterPLS er beskrevet i prosjektets miniprosjektrapport. Figur 6.1 6

19 6.2 PLS-Slave Væskenivået i en tank skal reguleres. Denne tanken har et innløp, som styres av reguleringsventil, og et utløp, som styres av tre magnetventiler. SlavePLSen er en PLS av typen Mitsubishi FX1N med mulighet for utvidelser. SlavePLSens oppgave er å stå for reguleringen av nivået i tanken. Detaljerte produktspesifikasjoner til SlavePLS er beskrevet i prosjektets miniprosjektrapport. Slaven skal lese nivå og utstrømning samt sende ut signal til reguleringsventilen ved hjelp av en ekstern analog modul. Slaven skal kommunisere direkte med MasterPLSen ved hjelp av Profibus-DP og skal sende ut følgende verdier: Analoge verdier: Avvik Nivå Utstrømning Manuelt pådrag Referanse Nominelt pådrag Pådraget til ventil Digitale verdier: Stopp av pumpe Alarm ved avvik over 25 % Alarm ved nivå over 90 % Alarm ved nivå under 10 % Resetting av kvittering 7

20 I tillegg skal Slaven motta følgende verdier fra MasterPLS-en: Analoge verdier: Referanse Samplingstid Kp Ti KpFF TdFF Nominelt pådrag NFF Manuelt pådrag Digitale verdier: Auto/manuell P/PI Foroverkobling på/av Pumpe på/av Utløpsventil 1 på/av Utløpsventil 2 på/av Utløpsventil 3 på/av Alarmkvittering Reverserende/direkte regulator Programmet skal kunne fungere både som P- og PI-regulator med rykkfri overgang (bumpless transfer) ved skifte av regulatortype. Det skal ha både direkte og reversert modus. Det skal også være mulig å sette regulatoren i manuell modus i tillegg til den automatiske. Regulatoren skal også inneholde mulighet for foroverkobling av PD type. Overgangen mellom manuell og automatisk modus skal også foregå rykkfritt. Følgende parametere skal kunne justeres i regulatoren: proporsjonal forsterkning (Kp), integrasjonstid (Ti), nominelt pådrag, referanse og samplingstid. 8

21 I manuell modus skal pådraget styres fra MasterPLS. I foroverkoblingsdelen skal det være mulig å stille inn KpFF, TdFF og NFF. Regulatoren skal justeres inn så det blir et innsvingningsforløp av typen minimum 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 3 ventiler til 1 ventil åpen. Det skal gå alarm dersom nivået avviker mer enn 25 % fra referansen (25 % av totalt måleområde). Kritisk alarm skal aktiveres dersom det absolutte nivået i tanken overstiger 90 % eller går under 10 %. Ved vanlig alarm skal ei varsellampe, koblet til SlavePLS-ens utgang Y5, på tanken blinke med 0,5 sekunder på og 0,5 sekunder av. Ved kritisk alarm skal blinkefrekvensen økes slik at lampa står på i 0,2 sekunder og av i 0,2 sekunder. Dersom alarmen er kvittert ut fra operatørpanelet eller InTouch applikasjonen, men det fortsatt er alarmtilstand, skal lampa ha fast lys. Lampa skal bli mørk når det ikke lenger er alarmtilstand. Hvis prosessen går ut av alarmtilstand uten at alarmen er kvittert, skal lampa fortsette å blinke inntil alarmen er kvittert. Alarmtilstander som varer mindre enn fem sekunder skal ikke utløse alarm. Programmet må utformes slik at pumpa til tanken skal kunne slås av og på. Ved kritisk høy alarm skal pumpa stoppes automatisk. Det er viktig at programmet automatisk sørger for at nivået i tanken reguleres rett ved strøminnkobling etter strømbrudd. De tre magnetventilene som styrer utløpet er styrt av SlavePLS-ens utganger. Programmet i PLS-en skal utformes slik at magnetventilene kan styres av PC med HMIprogram. Figur 6.2 9

22 6.3 InTouch InTouch er et operatør-grensesnitt hvor operatør kan koble seg til PC for å styre og overvåke prosessen. Operatørgrensesnittet har tre forskjellige operatører som har ulik tilgang til styringen av prosessen. Eksempel på hvordan operatør-grensesnittet ser ut er vist i bildet under. Figur

23 6.4 Alarmer [HBR] Det går alarm dersom nivået har et avvik på mer en 25 % i forhold til referansen. Dersom nivået er under 10 % vil kritisk alarm aktiveres. Kritisk alarm dersom det absolutte nivået oversiger 90 % i tanken. Alarmtilstand som varer i mindre enn 5 sekunder vil ikke aktiveres. Alarmer vil kunne kvitteres fra InTouch. Alarmhistorikk vil være tilgjengelig i Alarm-vinduet i InTouch. 11

24 6.5 ix-panel [HBR] IX-panelet er et operatørpanel med touchskjerm lokalt på riggen. Skjermen viser et bilde av prosessen. Panelet er for enkelt kunne styre og overvåke prosessen, og for å detektere og kvittere alarmer. Figur

25 6.6 Nettside [HBR] Det er laget en nettside som presenterer gruppe og prosjektet på en enkel måte. Nettsiden ligger på WEB-adressa Figur 6.5 Figur 6.5 viser hvordan forsiden på nettstedet er utformet. Nettsidene inneholder informasjon om prosjektet med beskrivelse av gruppa og oppgaven. Dokumentarkivet på siden inneholder blant annet rapporter, innkallinger og referater. En side presenterer fremdriften på prosjektet og blir jevnlig oppdatert. 13

26 7 PLS-programmering 7.1 Master PLS [GMS] Figur 7.1 Master PLS-programmet er delt opp i 3 forskjellige programbiter. De tre ulike programbitene er delt opp slik: «Kommunikasjon_Slave_1» «Kommunikasjon_Slave_2» «Profibus» Dette føltes mest hensiktsmessig i og med at master PLSen kun skal fungere som en bindeledd / kommunikasjonsledd mellom slavene og brukergrensesnittet til operatørpanelet og InTouch. Dermed ble det naturlig å lage en programbit for kommunikasjon med slave 1, en programbit for kommunikasjon med slave 2 og til slutt en programbit for oppsettet av profibusnettverket. Oversikt over spesialminneceller som er brukt: Navn SM400 SM402 Tabell 7.1 Forklaring Alltid høy (1) når PLS er i RUN. Går lav (0) når PLS går i STOP Høy (1) kun i første scan etter at PLS har gått fra STOP til RUN. Ellers lav (0) 14

27 7.1.1 Profibus programbit Her ligger programkoden som er generert med GX Configurator-DP, som er et program hvor man enkelt kan sette opp et profibusnettverk ved å bestemme hvem som er master, bestemme hvilke dataregister som skal brukes til å sende og motta over profibusnettverket mellom master og slaver, og tildeler slavene hver sin adresse på profibusnettverket. (man gir egentlig ikke slavene en adresse, men forteller master på hvilke adresser den skal forvente å finne de tilkoblede slavene, da slavenes adresse blir konfigurert i hver enkelt slave). Etter man har satt opp nettverket genererer man en programkode i IL (instruction list) som videre blir importert i profibus programbiten i GX Works 2. Hvordan alt dette ble gjort er forklart i «Miniprosjekt Rapport G3» vedlegg 7. Men det er verdt å merke seg at vi nå har endret på hvilke dataregister master-plsen bruker på å sende data til slave 1 og slave 2. Dette pga. at vi er avhengige av at master «husker» regulatorinnstillingene samt. Husker tilstandene til magnetventiler med mer. Vi har med dette byttet ut D120 D135 R120 R135 og D220 D235 R220 R235. Dataregister som begynner med bokstaven «R» er batterimatet, dvs. at dataregistrenes verdi forblir uforandret ved strømbrudd og ved oppstart etter strømbrudd. Se figur 7.2 for endring av kode. Figur 7.2 For komplett oversikt over kommunikasjon mellom master og slaver via bufferminner, se vedlegg 4. 15

28 7.1.2 Kommunikasjon_Slave_1 programbit: Figur 7.3 I figur 7.3 er det programmert hvordan de minnecellene som brukes i operatørskjermen og InTouch blir pakket inn i dataregister R120 som er programmert til å sendes til slave 1. Dersom det har vært strømbrudd husker R120 verdiene til minnecellene, og flytter disse ut igjen i første scan ved oppstart etter strømbrudd. Figur 7.4 Figur 7.4 viser at alarmer som kommer fra slave 1 legges i minnecellene M100 til M

29 Figur 7.5 Figur 7.5 viser en enkel alarmfunksjon som mottar en 50ms puls fra slave 1 for å detektere om det er kommunikasjon. Ved brudd vil pulsen stoppe og en av tellerne teller opp til 80ms og «Alarm_Kommunikasjon_Slave1» (M10) går høy. Denne alarmen «resetter» seg selv dersom kommunikasjonen oppstår igjen. «M10» blir brukt for å visuelt vise kommunikasjonsbrudd på operatørpanel og InTouch. Tilsvarende er gjort for slave 2 med «M20», men den blir det ikke bruk for før «To-tank prosjektet». Figur 7.6 Figur 7.6 viser at dersom regulatoren står i manuell sendes referansen fra slave 1 til master, mens dersom den står i auto sendes referansen fra master til slave 1. 17

30 Figur 7.7 Figur 7.7 viser at dersom regulatoren står i auto og ikke er i første scan sendes manuelt pådrag fra slave 1 til master, mens dersom den står i manuell eller i første scan sendes referansen fra master til slave 1. Figur 7.8 Figur 7.8 viser at dersom regulatoren står i manuell eller i PI-reg sendes nominelt pådrag fra slave 1 til master, mens dersom den står i auto og i P-reg sendes referansen fra master til slave 1. 18

31 7.2 Slave 1 PLS [JK] Prosjektets regulator skal drives av en Mitsubishi MELSEC PLS FX1N og skal fungere som en PI-regulator med PD-foroverkobling, og med muligheten for manuell styring. Operatøren skal ha muligheten til å velge en kombinasjon av P- eller PI-regulering med P-, D- eller PDforoverkobling, og muligheten til å innstille både regulatoren og foroverkoblingens parametere. Sammen med det nominelle pådraget i P-regulering, valget av direkte eller reversert regulator og samplingstiden, skal dette bestemmes ved hjelp av et brukergrensesnitt i InTouch og ix-panel. Ved skifte av regulatortype skal overgangen skje rykkfritt. Det vil si at dersom prosessen er stasjonær, skal ikke bytte av regulatortype endre væskenivået. Regulatoren skal justeres inn slik at innsvingningsforløpet blir av typen minimum areal når nivået har stabilisert seg uten stasjonært avvik med en referanse på 60% av tankens væskenivå, og det kommer et sprang i utløpet fra 3/3 til 1/3 av fullt utløp. Det dynamiske avviket skal være minst mulig og innsvingningstiden skal være så hurtig som mulig. Regulatorens algoritme er hentet fra læreboka Sanntidsdatateknikk, Digitale regulatorer av Per Hveem (Januar 2014, Kybernetes forlag). Her er en oversiktlig henholdsvis fremstilling av regulatorens virkemåte: // Logiske operatorer: //! = Ikke-operator // && = AND-operator // = OR-operator // Direkte og reversert modus If(DIR && AUTO) {Ek = NIVÅ - REF} If(!DIR && AUTO) {Ek = REF - NIVÅ} // P-regulator for med og uten P- og PD-foroverkobling If(!PI && AUTO &&!P_foroverkoblet &&!PD_foroverkoblet) {ukp = (Kp10 * Ek)/10 + u0} If(!PI && AUTO && (P_foroverkoblet PD_foroverkoblet)) {ukp = (Kp10 * Ek)/10} 19

32 // PI-regulator ( Tih = Ti/h ) If(PI && AUTO) {ui_restk = (Kp10*Ek + ui_restk_1)%(tih*10) uik = (Kp10*Ek + ui_restk_1)/(tih*10) ukpi = ukpi_1 + uik + Kp10*(Ek Ek_1)/10} // Foroverkobling(FF), samplet forstyrrelse = vk If((P_foroverkoblet PD_foroverkoblet) && AUTO) {upffk = Kp_FF * vk} If((D_foroverkoblet PD_foroverkoblet) && AUTO) {If(D_foroverkoblet) {Kp_FF = 1} Tf_FF = Td_FF / N udffk = Tf_FF*uDFFk_1 + Kp_FF*(vK vk_1)/(h+tf_ff)} If(PD_foroverkoblet) {updffk = upffk + udffk} // Grensesjekk av pådragene mellom 0 og 250 If(ukP < 0) {ukp = 0} IF(ukP > 250) {ukp = 250} If(ukPI < 0) {ukpi = 0} IF(ukPI > 250) {ukpi = 250} If(uPFFk < 0) {upffk = 0} IF(uPFFk > 250) {upffk = 250} If(uDFFk < 0) {udffk = 0} IF(uDFFk > 250) {udffk = 250} 20

33 // Addering av regulator- og foroverkobling-pådrag If(PI && AUTO) {If(P_foroverkoblet) {uk = ukpi + upffk} If(D_foroverkoblet) {uk = ukpi + udffk} If(PD_foroverkoblet) {uk = ukpi + updffk}} If(!PI && AUTO) {If(P_foroverkoblet) {uk = ukp + upffk} If(D_foroverkoblet) {uk = ukp + udffk} If(PD_foroverkoblet) {uk = ukp + updffk}} // Grensesjekk mellom 0 og 250 If(uk < 0) {uk = 0} IF(uk > 250) {uk = 250} // Flytting av gamle verdier Ek = Ek_1 ukp = ukp_1 ukpi = ukpi_1 ui_restk = ui_restk_1 If(D_foroverkoblet PD_foroverkoblet) {udffk = udffk_1 vk = vk_1} // Manuelt pådrag If(MAN) {uk = um REF = NIVÅ u0 = um} 21

34 Dersom det forekommer et strømbrudd skal riggens master PLS «huske» verdier fra før strømbruddet. PLSen er utstyrt med batterimatede minneceller som brukes til bevaring av prosess-data. Deretter skal master videreføre informasjonen til slave PLSen (F1XN) slik at den kan fortsette reguleringen der den slapp. En skal også ha muligheten til å slå pumpen og alle de tre utgangsventilene av og på via operatørpanelene. Hvis prosessen har et stasjonært avvik over 25% skal det oppstå en alarmtilstand, og dersom væskenivået ligger under 10% - eller over 90% av tankens totale nivå skal det oppstå en kritisk alarmtilstand. Om fem sekunder går uten at alarmtilstandene er gått over, skal et alarm-flagg settes høyt. Dersom det er et vanlig alarm-flagg (stasjonært avvik) skal en alarmlampe på tank-riggen blinke med 1 Hz hastighet. Hvis det kritiske alarm-flagget er høyt skal lampen blinke med 2.5 Hz hastighet. En skal kunne kvittere på at alarmen er sett via operatørpanelene og denne kvitteringen skal enten slå av lampen dersom problemet er løst, eller gi lampen et kontinuerlig lys om problemet er fortsatt aktivt. Programmeringsspråk: Ladder logikk Utviklermiljø: MELSOF Series GX Works2 22

35 Figur 7.9 Slave 1 PLS-programmet er delt opp i 5 forskjellige programbiter. De tre ulike programbitene er delt opp slik: AD_DA Alarm Fysiske_Utganger Profibus Regulator Dette er gjort med hensikt i å holde en grei oversikt over hva som er programmert hvor. Grunner til dette er for å forenkle programmeringen for en selv, forenkle feilsøking samt. Lette forståelsen for andre. Oversikt over spesialminneceller som er brukt: Navn Forklaring M8000 Alltid høy (1) når PLS er i RUN. Går lav (0) når PLS går i STOP M8002 Høy (1) kun i første scan etter at PLS har gått fra STOP til RUN. Ellers lav (0) M8011 Pulstog, 10ms. 5ms høy (1), 5 ms lav (0) M8013 Pulstog, 1s. 500ms høy (1), 500ms lav (0) Tabell

36 7.2.1 AD_DA [GMS] Her ligger programmeringen av kommunikasjon mellom Slave 1 og dens AD/DA-omformer. AD/DA-omformeren ligger på modulplass 0, og TO-/FROM-instruksjoner blir brukt for kommunikasjon. Kort oppsummert av hva som er programmert i AD_DA er at verdien til nivåføleren samt. flowmåleren fra tank 1 leses av og legges i hhv. D0 «Analog_Inn_K0_LT_16» og D1 «Analog_Inn_K1_FT_16». Pådraget fra PID-blokka sendes ut fra dataregister D2 «Analog_Ut_RV_16». For detaljert forklaring på programkode og oppsett, se «Miniprosjekt Rapport GR3» side Se også vedlegg 6. Figur 7.10 Figur 7.10 er et utdrag fra programkoden i AD_DA. Nivået i tanken leses av og legges i et dataregister i slaven. Her gir slaven beskjed om å start A/D-omforming på kanal 0 ved at BFM #17 gis verdi 2. Deretter hentes verdien fra kanal 0 ved at verdien fra BFM #0 legges i D0 «Analog_Inn_K0_LT_16». 24

37 7.2.2 Alarm [GMS] I programdelen «Alarm» er alle alarmene programmert. Gitt av oppgaveteksten skal det gå alarm dersom nivået avviker mer enn 25 % fra referansen, dersom det absolutte nivået overstiger 90 %, eller gå under 10 %. Over 90 % nivå, og under 10 % nivå, er kritiske alarmer. Ved vanlig alarm (ikke kritisk, avviket er over 25 % fra referansen) skal alarmlampe «Alarm_H1» (M22) blinke med 0.5 sek intervall. Ved kritisk alarm (nivå over 90 % og nivå under 10 %) skal alarmlampe «Alarm_H1» (M22) blinke med 0.2 sek intervall. Dersom alle alarmer er kvittert, men det fortsatt er alarmtilstand skal alarmlampe «Alarm_H1» (M22) lyse fast helt til prosessen går ut av alarmtilstand. Det skal ikke utløses før det har vært alarmtilstand i 5 sekunder eller mer. Måten dette er løst på der ved å definere tre minneceller for tilstander i prosessen (ikke alarmtilstander): Minnecelle M104 M105 M106 Navn Avvik_over_25 Niva_over90 Niva_under10 Forklaring Avviket er Nivået er Nivået er over 25% over 90% under 10% Tabell 7.3 Og tre minneceller for alarmtilstander i prosessen: Minnec elle Navn Forklari ng Tabell 7.4 M101 M102 M103 Alarm_Avvik_ov Alarm_Niva_o Alarm_Niva_un er_25 ver90 der10 Avviket har vært Nivået har Nivået har vært over 25% i 5 sek vært over 90% under 10% i 5 sammenhengen i 5 sek sek de sammenhenge sammenhengen nde de 25

38 Figur 7.11 Figur 7.11 viser hvordan minnecellene som forteller om tilstandene i prosessen går høy dersom avviket er over 25 %, nivået er over 90 % og nivået er under 10 %. Detaljert forklaring står i kommentarboksene. Figur 7.12 Figur 7.12 viser hvordan alarmtilstand «Alarm_Avvik_over_25» blir satt dersom avviket har vært kontinuerlig i over 5 sekunder. Timer T1 utgang TS1 går høy og alarmen blir satt. Tilsvarende er gjort for «Alarm_Niva_over90» og «Alarm_Niva_under10». 26

39 Figur 7.13 Figur 7.13 viser hvordan alarmene blir resatt dersom kvitteringsbit fra operatørpanel går høy (dvs. operatøren har kvittert), samt. At den faktiske tilstanden i prosessen er utenfor tilstand som skal gi alarm. Dersom begge disse er oppfylt vil alarm minnecellen(e) bli resatt. Figur 7.14 Figur 7.14 viser hvordan alarmlampas minnecelle «Alarm_H1» (M22) styres gitt ulike alarmtilstander med og uten kvittering. Forklaring står i kommentarboks. «Puls_20ms_1» er en selvlaget blinkefrekvens med 20ms intervall laget med sekvensprogrammering og to timere. Se vedlegg 6 «Alarm POU» nettverk 2. 27

40 7.2.3 Profibus [GMS] Her ligger programmeringen av kommunikasjon mellom slave 1 og QPLS via profibuskabelen. Kort oppsummert blir alarmtilstandene (M100-M115), og dataregistrene D100-D115 overført fra slave 1 til master, mens minnecellene fra master (M120-M135), og dataregistrene D120-D135 blir overført fra master til slave1. Vedlegg 4 viser en grei oversikt over hva som overføres til hvor. Figur 7.15 Figur 7.15 er et utdrag fra Profibus programdelen som viser hvordan slave 1 blir gitt sin slaveadresse. Se vedlegg 6 og/eller «Miniprosjekt Rapport G3» side for mer detaljert beskrivelse av Profibus programdelen da det ikke har vært nødvendig med noen endringer siden Miniprosjektet hvor vi opprettet kommunikasjonen. Fysiske utganger: I denne programdelen kobles minneceller fra HIM (operatørpanel og InTouch) til de fysiske utgangene på Slave 1-PLSen. Dette er en kort og presis programdel, da det kun er 5 utganger som skal styres. I tabell 7.5 er en oversikt over hvilke minneceller som er koblet til hvilke utganger samt. Hvilke navn som er brukt i programmet. Utga Y4 Y5 Y10 Y11 Y12 ng Minn M M22 M127 M128 M129 ecell e 13 0 Navn P_ Alarm MV_1 MV_2 MV_3 28

41 1 _H1 Forkl Pu Alarm Magnet Magnet Magnet aring m lamp ventil1 ventil2 ventil3 pe e Tabell 7.5 Figur 7.16 Figur 7.16 viser hvordan minnecellene er koblet til de fysiske utgangene. Pumpa «P_1» (Y4) skiller seg ut fra resten ved at pumpa skal stoppe ved kritisk alarm når nivået er over 90 %. Dermed blir utgangen resatt ved denne alarmen, og kan ikke startes før nivået er under 90 %, og alarmen er kvittert fra operatørpanelet eller InTouch. I operatørpanelet blir «P_1» (M130) resatt ved denne alarmtilstanden, slik at pumpa ikke starter opp av seg selv dersom du kun kvitterer alarmen, du må altså starte pumpa på nytt etter at nivået er under 90 %, og du har kvittert alarmen. Dette er gjort for at det bør være en bevist handling av operatøren dersom pumpa skal startes igjen etter en slik kritisk alarm. 29

42 7.2.4 Regulator [GMS] I Regulator programdelen tar vi for oss en del omregning fra prosent til bitverdier, omregning fra bitverdier til prosent, omgjøring fra 16-bits ord til 32-bits ord og omgjøring fra 32-bits ord til 16-bits ord. Her blir også alle dataregistrene og minnecellene som skal brukes i regulatoren koblet sammen med PID-blokka. Vi har valgt å omgjøre alle 16-bits ord til 32-bits ord før de brukes inni regulator-blokka for å unngå komplikasjoner med de matematiske operasjonsblokkene i GX-Works 2. Også det som går ut av regulator-blokka (nominelt pådrag «u0_32», manuelt pådrag «u_man_32» og referansen «ref_32») kommer som et 32-bits ord, for så å bli omgjort til et 16-bits ord etter omregning til prosent. Det 16-bits ordet sendes så tilbake til master. Navnsetting: Da det er mange dataregistre å holde styr på i programmet har vi valgt å standardisere noen for å opprettholde en noenlunde god oversikt. Dataregister som ender på «_TilQ» er dataregister som går over profibus fra slave 1 til master. Dataregister som ender på «_Fra_Q» er dataregister som går over profibus fra master til slave 1. Dataregister som ender på «_16» er 16-bits enkle dataregister. Disse blir brukt til omregning til prosent. Dataregister som ender på «_32» er 32-bits doble dataregister. Disse blir brukt i regulatorblokka. Omgjøring fra 16-bits dataregister til 32-bits dataregister: 30

43 Figur 7.17 Figur 7.17 viser et utsnitt av hvordan vi «omgjør» 16-bits dataregister som kommer fra master til 32-bits dataregister som ligger lokalt i slave 1 for videre bruk i regulator-blokka. Omregning fra prosent til bitverdi, og omregning fra bitverdi til prosent: Figur 7.18 Figur 7.18 viser et utdrag fra regulator programdelen som tar for seg omregning av referansen i prosent til bitverdi, og omregning av referansen i bitverdi til prosent. Dette er nødvendig i og med at referansen skal kunne settes som en prosentverdi i HMI dersom regulatoren er i auto-modus. Dermed må regulatoren motta denne referansen fra HMI omregnet til bitverdi, for å kunne behandle referansen videre. Er regulatoren derimot i 31

44 manuell-modus skal referansen settes lik prosessverdien for å oppnå rykkfri overgang ved bytte av regulatortype. Dermed blir referansen satt lik bitverdien til nåværende verdi i tanken (dette skjer inne i regulator-blokka), og lagt i «ref_32» (D20). «ref_32» er et 32-bits dataregister og kan ikke overføres til master med profibusoppsettet vårt, dermed blir «ref_32»-verdi kopiert over til et 16-bits dataregister «ref_til_q_16» (D55) som igjen blir omregnet til prosent og lagt i «Ref_TilQ» (D102) som sendes til master. Tilsvarende er gjort både for nominelt pådrag og manuelt pådrag. Avhengig av ulike kriterier. Se vedlegg 6 Regulator POU nettverk 5 og 6. Prosessverdi (nåverdi i tank), flowverdi (gjennomstrømning i utløp) og pådrag til reguleringsventil skal alltid sendes fra slave 1 til master for å overvåke prosessens tilstand. Dette er gjort på samme måte som med referansen bortsett fra at man ikke trenger å ta hensyn til å motta noe fra master. Se figur Figur

45 Figur 7.20 Figur 7.20 viser hvordan regulatorblokka ser ut med tilhørende inn- og utganger tilkoblet. Videre kommer tabeller som viser en oversikt over hvordan de globale dataregistrene og minnecellene er koblet sammen med regulator-blokkas lokale. Tabell 7.6 viser en oversikt over dataregistre som kun skal leses (read only) av regulatorblokka. Navn global Dataregister Navn lokal (PID-blokk) global Samptid_h_32 D43 samp_h Analog_Inn_K0_LT_32 D36 PV_Nivå Analog_Inn_K1_FT_32 D38 vk Kp_32 D10 Kp Ti_32 D24 Ti Kp_FF_32 D26 Kp_FF Td_FF_32 D28 Td_FF N_orden_FF_32 D30 N_FF Tabell

46 Tabell 7.7 viser en oversikt over dataregistre som skal kunne leses og skrives til av regulatorblokka: Navn global Dataregister Navn lokal (PID-blokk) global u0_32 D16 u0 u_man_32 D41 ukm ref_32 D20 ref_r Tabell 7.7 Tabell 7.8 viser en oversikt over dataregistre som kun skal skrives til (write only) i regulatorblokka: Navn global Dataregister Navn lokal (PID-blokk) global Pådrag_Til_DA_32 D18 u_pid Tabell 7.8 Tabell 7.9 viser en oversikt over minneceller som kun skal leses av (read only) regulatorblokka: Navn global Dataregister Navn lokal (PID-blokk) global MAN_AUTO M120 MAN DIRE_REV M121 Dir_Rev PI_P_valg M122 PI_P PFF_valgt M124 P_FF_reg DFF_valgt M125 D_FF_reg PDFF_valgt M126 PD_FF_reg Tabell 7.9 De lokale navnene (PID-blokk) er de som brukes til videre programmering inne i regulatorblokka. Mens de globale navnene med tilhørende dataregistre/minneceller blir brukt til behandling av verdiene som sendes ut av blokka. 34

47 35

48 7.2.5 Regulatorblokken [JK] For ordens skyld er selve reguleringen begrenset til en funksjonsblokk kalt PID_blokk1. Dette gjør gjenbruk av regulatoren mye enklere og programmet i sin helhet blir mer oversiktlig å lese. På venstre side av blokken (se figur 7.21) er funksjonsblokkens innganger. Disse variablene kommer fra operatøren og styrer de forskjellige parameterne i regulatoren. De åtte øverste- og de tre nederste inngangene på blokken er 32-bits variabler, mens de gjenværende inngangene er boolske variabler av typen bit. Høyre side av funksjonsblokken holder de kalkulerte utgangene som sendes tilbake. Pådrag_Til_DA_32 er det regulatorbestemte pådraget som skal sendes til reguleringsventilen. For å unngå endringer i det stasjonære nivået ved endring av regulatortype må regulatoren få muligheten til å sette noen av parameterne selv. Nederst til høyre på figuren står det nominelle pådraget u0, det manuelle pådraget ukm og referansen ref_r som utganger. Dette er for å holde operatørpanelene oppdatert på de kalkulerte parameterne som trengs for en rykkfri overgang. Figur 7.21 Regulatorens funksjonsblokk 36

49 7.2.6 Samplingsklokken [JK] Samplingsklokken er inspirert av sekvensprogrammering, der tilstanden Sampling (se figur 7.22) holder seg selv høy så lenge neste tilstand (Sampling_invers) ikke er høy og motsatt. Tilstandene starter to individuelle men like timere med funksjonsblokken OUT_T og tidskretsene T200 og T201. Den ene tilstandens tidskrets er den andre tilstandens overgangsbetingelse, slik at begge tilstandene veksler mellom å være høy. Tidskretsene T200 og T201 er av typen 10 ms tidskretser, som betyr at for hvert heltall inn på inngangen TValue i OUT_T blokken teller timeren 10 millisekunder. Her blir samplingsvariabelen Data22 satt som inngang på TValue. Denne variabelen er kvotienten av samplingstiden gitt i ms delt på 20. Det er valgt å dele på 20, slik at hver av tellerne teller til halve samplingstiden. Tilstandsvariabelen Sampling blir brukt i regulatorens pådragsalgoritmer som en stigende puls, slik at det kun kalkuleres i det Sampling går høy og ikke før hele samplingstiden har passert. 37

50 Figur 7.22 Samplingsklokken i GX Works 2 38

51 7.2.7 Direkte og reversert regulering [JK] Operatøren skal ha muligheten til å velge mellom direkte og reversert reguleringsmodus. Dette kan være ønskelig i mange tilfeller, men i dette prosjektet brukes kun det reversvirkende avviket. Figur 7.23 Utregning av avvik Substitusjonsblokken DSUB er brukt til å kalkulere avviket ek_32. I reversvirkende regulering ser det matematiske regnestykket slik ut: Avvik = Referanse Væskenivå 39

52 7.2.8 P-regulator [JK] Dersom operatøren velger å regulere kun med P-forsterkning, vil den boolske variabelen PI_P gå lav. Sammen med andre kriterier skal dette åpne for kalkulering av pådrag med en P- forsterkningsalgoritme. P-regulering (proporsjonal regulering) har to justerbare parametere; proporsjonalforsterkningskonstant Kp og nominelt pådrag u0. Begge er inngangsverdier som leses av regulatorblokken, slik at de kan bli bestemt av operatøren. Dersom det også er valgt foroverkobling med P-forsterkning skal det nominelle pådraget fjernes. I regulatorblokken for P-regulering er det derfor laget to forskjellige kalkuleringer, med og uten nominelt pådrag (se figur 7.24). Figur 7.24 P-regulator De matematiske funksjonene henholdsvis med og uten nominelt pådrag ser slik ut: Pådrag = Avvik*Kp + u0 Pådrag = Avvik*Kp 40

53 7.2.9 PI-regulator Dersom PI-regulator er valgt av operatøren, vil den boolske variabelen PI_P gå høy. Dette åpner for PI-delen av programmet, og lukker P-delen. Den brukte algoritmen er basert på et eksempel i boka Sanntidsdatateknikk (side 108): Formel 7.1 Δu IK = (K p10 e K + Δu I_REST_K 1 ) ( T i h 10) Δu I_REST_K = (K p10 e K + Δu I_REST_K 1 )%(T i h 10) u k = u K 1 + Δu IK + K p10 (e K e K 1 ) 10 Figur 7.25 PI-regulator Algoritmen er lagd med hensyn på at det vil forekomme avrundingsrester ved divisjon og at disse må bli bevart for bedre nøyaktighet i utregning av pådraget. 41

54 Foroverkobling I et system preget av forstyrrelse kan det lønne seg å bruke en foroverkobling i tillegg til bakoverkoblingen. Istedenfor å beregne pådrag ut i fra avviket, gir foroverkobling et pådrag basert på forstyrrelser på prosessen. I dette tilfellet er forstyrrelsen utstrømning fra tanken. Tanken er utstyrt med tre magnetventiler som en fritt kan styre både manuelt og via operatørpanelene. Utstrømningen gjennom magnetventilene blir gjort mål på og kommer til regulatorblokken i variabelen vk. Regulatorblokken har blant flere tre innganger med navnene P_FF_reg, D_FF_reg og PD_FF_reg. Disse bestemmer hvilken regulatortype som skal brukes i foroverkoblingen. Kun en av de boolske variablene kan være høy til enhver tid, og dersom ingen er høye, er foroverkoblingen deaktivert. Operatøren har muligheten til å justere de tre foroverkoblingsparameterne Kp, Td og N. Dersom D-regulering i foroverkoblingen er valgt, velges Kp til 1 utenfor regulatorblokken. Foroverkoblingsalgoritmene er hentet fra læreboka Sanntidsdatateknikk (side 95): P-forsterkning: Formel 7.2 u PFFK = K PFF V K Figur Foroverkobling 42

55 D-forsterkning: T fff = T dff N u DFFK = T fff u DFFK 1 + K PFF (V K V K 1 ) ( h + T fff ) Formel 7.3 Figur 7.27 Foroverkobling med D-forsterkning, usammenhengende for å få med hele bildet. PD-forsterkning: Formel 7.4 u PDFFK = u PFFK + u DFFK Figur 7.28 PD-forsterkning 43

56 P-forsterkningen holder et pådrag proporsjonalt med utstrømningen av tanken. Strømningsmåleren sender inn en verdi som ligger mellom verdiene 0 til 250, og dermed trengs en lav Kp slik at pådraget fra foroverkoblingen ikke går helt i metning. I motsetning til P-forsterkningen, gir D-delen pådrag bare dersom utstrømningen endrer seg. En blanding av begge forsterkningene gir ofte best regulering av forstyrrelser. Dersom PDregulering er valgt, brukes begge de tidligere forsterkningene og summerer de til slutt. Dersom en bruker både foroverkobling og bakoverkobling bør D-delen i foroverkoblingen holdes utenfor wind-up kontrollen, mens P-delen inkluderes. Ved grensesjekk av pådragene mellom 0 og 250 før de lagres som forrige pådragsverdi til slutt i programmet, vil det fungere som en wind-up kontroll Rykkfri overgang (bumpless transfer) Dersom væskenivået i tanken har stabilisert seg er det svært ønskelig å beholde likt pådrag over regulatortypebytte, slik at en unngår et dynamisk avvik i overgangen. Det er forskjellige ting en må passe på i programmet avhengig av hvilken modus regulatoren står i og hvor den skal. De forskjellige overgangene er listet opp i læreboka Sanntidsdatateknikk (Kapittel 4). 44

57 Figur 7.29 I overgangen fra manuell til automatisk styring, settes referansen lik det målte nivået i tanken og legger det siste manuelle pådraget i variablene u0 og forrige PI-pådrag. Og i overgangen fra automatisk- til manuell styring, starter det manuelle pådraget i forrige automatiske pådrag. Fra P- til PI-regulering blir P-pådraget lagt i PI-pådragets forrige verdi som i utgangspunktet er 0. Og fra PI- til P-regulering settes u0 lik det automatiske pådraget fra PI-regulatoren. Dersom væskenivået var stasjonært vil ikke P-regulatoren skape stasjonært avvik på denne referansen. 45

58 8 InTouch [JA] 8.1 Innledning I denne delen vil det bli beskrevet hvordan brukergrensesnittet for entankstyringen med InTouch er bygget opp. Det vil bli forklart hvordan programmet er satt opp slik at man får innsikt i programmets funksjonalitet, og samtidig vises det hvordan funksjonene er satt opp på en enkel måte. Programmet består av følgende vinduer/skjermbilder: Innloggingsvindu Prosessvindu Historikk (historisk trend) Alarmvindu Kommunikasjonsvindu I tillegg kommer en menylinje som ligger øverst i alle skjermbildene. Dette gjør at man enkelt kan navigere mellom de forskjellige vinduene. Prosessvinduet og alarmvinduet har begrensede funksjoner basert på de forskjellige operatørenes tilgangsnivå. De andre vinduene har ingen begrensninger. Oppsettet av tagger i Beijer Electronics OPC Server og OPC Link ble gjennomgått i miniprosjektrapporten og vil ikke bli sett nærmere på her. For mer informasjon om kommunikasjonen mellom InTouch og QPLS, se miniprosjektrapporten «Del 8: Kommunikasjon mellom HMI og QPLS». Fullstendig liste over tagger som ble brukt i OPCserveren finnes som vedlegg 3. Enkle oppsett av knapper, tildelinger av tagger og variabler ble gjennomgått i miniprosjektrapporten «Del 9: PC HMI». Denne rapporten vil dekke de områdene som ikke ble innfattet i miniprosjektet, og gå litt er i dybden på de funksjoner som krever litt ekstra. 46

59 47

60 8.2 Sikkerhet, innlogging og tilgangsnivå Det første som ble gjort er å definere innloggingsnavn og tilgangsnivå for de ulike operatørene. Man går inn på «Special > Security > Select Security Type > InTouch», etter det velger man «Special > Security > Log On» og skriver inn brukernavn: Administrator og passord: wonderware. Figur 8.1 Nå har man tilgang til å velge «Special > Security >Configure Users». Figur 8.2 Her legges de tre operatørene til med tilhørende passord og tilgangsnivå. 48

61 8.2 Oversikt over brukerne Brukernavn Passord Tilgangsnivå Operatør1 Op1 1 Operatør2 Op2 2 Operatør3 Op3 3 Tabell Innloggingsvindu Da er det klart for å sette opp innloggingsvinduet. Figur 8.3 Vindusskriptet for innloggingsvinduet I dette vindusskriptet for innloggingsvinduet settes variabelen $OperatorEntered lik None, og $PasswordEntered til blankt, Dette sikrer at man er logget helt ut av systemet når man trykker logg av. For å unngå at uvedkommende får tilgang til noen av skjermbildene blir alle andre skjermbilder lukket. 49

62 Figur 8.4 Ikke innlogget Figur Logg inn-knappskriptet Dette er action-skriptet for innlogging som kjøres når «Logg inn»-knappen trykkes. «DIM LogonResult AS DISCRETE» definerer variabelen «LogonResult» som datatype DISCRETE. 50

63 «LogonResult = PostLogonDialog()» er en funksjon som viser innloggingsboksen når verdien «LogonResult» er sann. Figur 8.6 Innlogging I «Log On»-vinduet som dukker opp kan man skrive inn en av operatørene og tilhørende passord. Som eksempel er det logget inn med bruker: Operatør3 og passord: Op3. Figur 8.7 Logget inn som Operatør3 51

64 Når du er logget inn dukker det opp hvilken bruker som er aktiv og to knapper. Fortsettknappen tar deg med videre til «Prosess»-vinduet. Avbryt-knappen gjør at du blir logget ut og du blir tatt med tilbake til forrige bilde. 8.4 Menylinjen Figur 8.8 Menylinjen Menylinjen ligger øverst på alle bildene (unntatt logginn-vinduet). Her kan man navigere mellom de ulike vinduene, se tid og dato, se hvilken bruker som er logget inn og man kan logge seg ut. På «Logg ut»-knappen er det lagt inn «Touch Pushbuttons > Show Window»- skript. Dette tar deg med til innloggingsvinduet. På grunn av vindusskriptet på innloggingsvinduet blir man da automatisk logget ut. De andre navigeringsknappene har tilsvarende «Touch Pushbuttons > Show Window»-skript. Figur 8.9 Oppbygging av brukergrensesnittet 52

65 8.5 Prosessbildet Figur 8.10 Prosessbildet Dette er bildet man kommer til etter at innloggingen var vellykket og man trykker fortsett. Skjermbildet består av et prosessflytskjema, en sanntidstrend og muligheten for å velge regulatortypen, endre regulatorinnstillinger og valg for foroverkobling. Prosessvinduet er det skjermbildet som ser mest annerledes ut ettersom hvilken bruker som er logget inn. 53

66 8.6 Skjermbildet for Operatør1 Figur 8.11 Prosessbildet for Operatør1 Dette er skjermbildet for operatør1, det er den brukeren med færrest rettigheter. Operatør1 er beregnet for personell som ikke har noen innsikt i prosessen. Operatør1 har tilgang til å lese referanse, nivå, pådrag og om regulatoren står i auto eller manuell. I tillegg kommer muligheten til å se alarmer og å se om pumpa er i drift. 54

67 8.7 Skjermbildet for Operatør2 Figur 2.12 Prosessbildet for operatør2 Operatør2 har flere muligheter til å gjøre endringer på prosessen. Brukeren er beregnet for teknikere og personer som skal utføre vedlikehold av anlegget. Man har mulighet til å lese av måleverdier fra riggen, hvilke regulatortyper som er brukt og i hvilken modus regulatoren er satt. I tillegg kommer muligheten til å sette referansen, slå av eller på pumpen, velge mellom auto og manuell, sette pådraget og ha muligheten til å kvitere alarmer. 55

68 8.8 Skjermbildet for Operatør3 Figur 2.13 Prosessbildet for operatør3 Operatør3 har alle rettigheter. Denne brukeren er beregnet på ingeniøren som har innsikt i hvordan en regulator fungerer og hva alle funksjonene har som hensikt å gjøre. Operatør3 har mulighet til å endre på alle innstillinger på anlegget. 56

69 8.9 Oppsett av knapper At de forskjellige brukerne har forskjellige tilgangsnivå og skal ha muligheten til å se og endre forskjellige variabler er løst ved å bruke «Miscellaneous > Visibility»-link og «Miscellaneous > Disable»-link. Dette er gjort på f. eks. knappene for styring av magnetventilene. Linkene bruker variabelen $AccessLevel, den tilsvarer operatørenes tilgangsnivå. Hvis ikke kravene for tilgangsnivå i linkene er oppnådd vil ikke knappen være mulig å trykke, evt. være synlig. Figur 8.14 Oppsett av knapp, Visibility og Disable I dette tilfellet er det nødvendig med et tilgangsnivå på 3 for å kunne gjøre endringer, og et tilgangsnivå på 2 eller mer for å kunne se knappen som styrer magnetventil 1. Når en knapp blir usynlig vil også tilhørende tekst også bli usynlig, dette er gjort med samme type link som for knappen. I noen tilfeller brukes også «Location > Vertical»-linker for å holde brukergrensesnittet så enkelt og pent som mulig. Denne linken gjør at en knapp eller en tekst flyttes lengre opp på siden. 57

70 Figur 8.15 Oppsett av knapp, Line Color Knappene som indikerer om spesifikke innstillinger i programmet er aktivert har en grå ring rundt seg som går over til å være grønn når den aktuelle innstillingen er «på». Dette er gjort ved å bruke en «Line Color»-link. Den gjør at når en bestemt verdi går høy endrer linjen rundt farge. 58

71 8.10 Oppsett av sanntidstrend Sanntidstrenden ligger nederst til høyre i prosessbildet og viser en trend over referansen, nivået og pådraget til prosessen. Figur 8.16 Sanntidstrend Det første man gjør er å hente ut en «Real-Time Trend» fra verktøylinjen og strekker den ut til ønsket størrelse. Figur 8.17 Oppsett av sanntidstrend Dobbeltklikker man på trenden har man mulighet til å endre hvilke tags som skal tegnes opp. Det er også mulig å endre utseende og over hvor lang tid det er mulig å se dataene. Vi valgte å kunne se fem minutter tilbake i tid. 59

72 8.11 Historikk-bildet Figur 8.18 Historikk-skjermbildet Når man trykker på Historikk-knappen i menylinjen åpnes bildet på figur Her er det en historisk trend. Den brukes til å se på prosessverdiene over lengre tid. Man har muligheten til å zoome inn eller ut både på x- og y-aksen. Figur 8.18 Wizard Selection Den historiske trenden hentes fra «Wizard Selection» som finnes i verktøylinjen. Her velges alle objektene og legges inn i bildet. Det er viktig når man setter opp trenden at man velger det samme navnet på alle objektene slik at de refererer til den samme historiske trenden. Selve historikkvinduet heter HistTrend, da må de tilhørende objektene f.eks. zoom-verktøyet ha samme navn. 60

73 Det er plassert en knapp til høyre for grafvinduet, den starter eller stopper automatisk oppdatering av dataen. Knappen setter en diskret variabel «logging» høy eller lav. Variabelen blir brukt i et vindusskript for historikk-vinduet. Figur 8.19 Vindusskript for start og stopp av logging. Skriptet består av en if-setning som kjører funksjonen «HTUpdateToCurrentTime». Den oppdaterer den valgte trenden «HistTrend» til sanntid. Ønsker man å hente ut verdier fra et spesifikt tidspunkt må man slå av den automatiske oppdateringen. Skriptet kjøres hvert 50. ms mens vinduet er oppe. Helt nederst i vinduet er det en modul for å lagre de loggede dataene i en CSV-fil. Den er ferdigprogrammert fra InTouch, men man må huske å gi den det samme navnet som den historiske trenden den skal lagre dataene fra. 61

74 8.12 Alarmer Når en av de definerte alarmene inntreffer begynner det å blinke rødt rundt alarm-knappen på menylinjen. Dette indikerer at det har kommet en ny alarm. Hvis man nå trykker på alarm-knappen kommer man til alarmvinduet og knappen slutter å blinke. På alarmskjermen her det to blokker, en for sanntidsalarmer som viser de aktive alarmene, og en for alarmhistorikk. Under alarmvinduene er det to knapper for kvittering av alarmer. Den ene kvitterer kritiske alarmer og den andre kvitterer de «normale» alarmene, f. eks. avvik fra referansen på mer enn 25 %. Figur 8.20 Oppsett av kvitteringsknappene Alarmtaggene ble satt i hver sin «Group» i InTouch, de kritiske alarmene ble lagt i gruppen «Kritisk» og de normale alarmene ble lagt i gruppen «Normalalarm». Det er lagt in et «Touch > Action Script» på de to knappene. Når knappen for kvittering av kritisk alarm trykkes kjøres funksjonen «Ack» som kvitterer gruppen «Kritisk». I tillegg settes tre tags av typen diskret høye, dette for å si ifra til PLS og ix-panelet at alarmen er kvittert og for å si ifra til InTouch at alarmen er registrert. 62

75 Figur 8.21 Condition-skript Det er også lagt inn to «Condition»-skript som gjør at alarmene blir kvittert i InTouch hvis de blir kvittert via ix-panelet. Hver av de to skriptene kjøres i det kvitteringstaggen blir endret. Skriptene bruker samme funksjon som kvitteringsknappene. 63

76 8.13 Kommunikasjon-bildet Figur 2.22 Kommunikasjon Kommunikasjonsbildet består av et bilde som viser hvordan kommunikasjonen er satt opp på en enkel måte. I tillegg er det en lampe som viser om kommunikasjonen er ok. Hvis det er brudd mellom Master og Slave 1 lyser lampen rødt og det går en alarm i InTouch. 64

77 8.14 Skript På grunn av at PLSen ikke har mulighet for overføring av desimaltall måtte vi gange opp regulatorparameterne. Dette ble gjort ved hjelp av et «Window Script» som kjøres så lenge prosessvinduet er oppe. Figur 8.23 Window Script for Prosess Det ble laget interne tags for regulatorinnstillingene, det er disse man endrer på når man skriver inn i InTouch. Deretter ganges de opp med bestemte verdier og legges inn i taggen som er knyttet opp mot OPC-serveren. Kp, Ti, og TdFF blir ganget med 10, mens KpFF blir ganget med

78 9 ix-panel [EAH] På tankriggen er det montert et operatørpanel av type ix-panel TA100. Panelet brukes til å lese og skrive verdier til de to PLS-ene og kvittere ut alarmer. Operatørpanelet har veldige mange muligheter. Gruppen står fritt til å velge selv hvordan vi skal lage et mest mulig fint og brukervennlig operatørgrensesnitt. Styringsmulighetene vil være noe begrenset i forhold til brukergrensesnittet på PCen, men oppgaveteksten har med noen ønskede skrive- og leserettigheter som er listet opp under (se tabell under). I tillegg skal operatørpanelet settes opp som WEB-server for fjernstyring av tankriggen via internett. Som skrevet i miniprosjektrapporten er panelet et touchpanel, som lar for eksempel en operatør kunne styre tankriggen der tanken befinner seg. Variabel Skrives Leses Referanse til tank1 X X Manuelt pådrag til tank1 X X Omstilling fra manuelt pådrag til automatisk X X nivåregulering for tank1 Pådrag for tank1 X Nivå i tank1 X Melding om alarmer fra tank1 X Kvittering av alarmer fra tank1 X Start/stopp pumpe 1 X X Tabell 9.1 som viser ønskede skrive- og leserettigheter for operatørpanelet. I tillegg har vi lagt inn noen flere rettigheter. Dette er fordi vi mener operatørpanelet blir mer brukervennlig med de nye funksjonene, samtidig som operatøren får flere valgmuligheter og en mer oversikt over prosessen. De nye rettighetene står i tabellen under. Variabel Skrives Leses Valg av regulatortype P/PI X X Valg av magnetventiler MV1, MV2 og MV3 X X Tabell 9.2 som viser ekstra skrive- og leserettigheter for operatørpanelet. 66

79 8.1 Innlogging/Hovedbildet [EAH] Figur Oppstartsbildet/logginn Slik ser det ut når man starter opp riggen med operatørpanelet. Her kan man logge seg inn med brukernavn Operatør3 og passord op3. Operatør3 har alle rettigheter. I bildet har vi to knapper nede til høyre, der knappen med huset på sender deg Hjem, som er innloggingsbildet. Knappen med jorden logger den aktuelle brukeren ut og sender deg til Hjem bildet. 67

80 8.2 Prosess [EAH] Figur Prosessoversikt Dette er bildet man får opp etter å ha logget inn. Her ser vi oversiktsbildet over prosessen. Selve tanken og rørene er tegnet inn slik det ser ut i virkeligheten. Dette gjør det lettere hvis man må feilsøke på tankriggen, og man får en bedre oversikt. Til venstre ser vi et sanntidsvindu hvor vi kan lese av nivået i tanken, settpunktet til tanken og pådraget til reguleringsventilen i det aktuelle øyeblikket. Vi kan også lese av disse verdiene i tallverdier. Vi ser på reguleringsventilen at vi har tre forskjellige verdier. PV står for Prosessverdi, som er verdien som sendes ut i fra analogutgangen på PLSen til reguleringsventilen. Dette signalet blir framstilt som %. SP står for Settpunkt, som er en verdi som blir utregnet i PLS-programmet. Denne verdien blir endret hele tiden, hvor mye avhenger av hvor mye nivå vi skal ha i tanken. Prosessverdien skal hele tiden være nærmeste mulig settpunktet. MAN står for Manuell, denne vises kun på bildet når regulatoren er stilt inn i manuell modus. Da kan man overstyre signalet til reguleringsventilen. 68

81 Ved LT1 (Level Transmitter 1) i bildet har vi samme oppbygging som reguleringsventilen. Vi ser tallverdiene for nivået i tanken PV og det utregnet settpunktet til tanken SP. De tre magnetventilene er også tatt med. De viser grå farge når de er lukket og grønn når de er åpne. Pumpen som pumper vannet fra buffertanken til tanken er programmert på samme måte som magnetventilene. Her har man muligheten til å stoppe eller starte pumpen. Grønn farge indikerer at pumpen går, mens grå farge indikerer stopp. Disse funksjonene kan styres i fra operatørpanelet. Det er og tatt med regulator innstillinger. Her kan vi velge mellom P eller PI regulering, og om regulatoren skal stå i auto eller manuell. Øverst til venstre er det et led-lys som ved rød farge indikerer alarm. 69

82 8.3 Alarmer [EAH] Figur 9.5 Figur 2 viser lesing/logging av alarmer, alle alarmer vises i sanntid. Under fanen State får man vite statusen på hver aktuelle alarm. Hvis vi har en aktiv alarm vil det stå Active her, samtidig som bakgrunnen for alarmen blir rød. Hvis den aktive alarmen går over av seg selv, vil statusen bli Inactive og bakgrunnen vil bli gul. Selv om alarmen har gått over, går den ikke bort, før man har kvittert den ut med Ack knappen. Trykker man Ack på den innaktive alarmen vil statusen gå over til Normal og bakgrunnen blir hvit. Alarmen vil fortsatt ligge i alarmhistorikken. Alle alarmer med status Normal forsvinner ved å trykke på Clear knappen. Det finnes også en Ack all knapp som kvitterer ut alle alarmer med status Active. Active Time fanen viser dato og klokkeslett for hver alarm, mens under Text står det en kort forklaring for alarmen. 70

83 8.4 Historikk [EAH] Figur 9.6 Figur 9.6 viser historikken til nivået i tanken, settpunktet til tanken og pådraget til reguleringsventilen framstilt i en trend. Her kan man selv velge hvor lang tid tilbake i historikken vi skal gå. Det er og muligheter for zooming inn og ut, å bla fram og tilbake i trenden og tilbakestille trendvinduet. 71

84 8.5 Kommunikasjon [EAH] Figur 9.7 Her er et enkelt oversiktsbilde over nettverkskommunikasjonen. Det er lagt inn alarmer som viser om kommunikasjonen er oppe å går til hver enkelt PLS. Denne oversikten skal hjelp ved feilsøking av kommunikasjonsfeil. Det hjelper veldig at det er tre forskjellige alarmer, og ikke bare en. For eksempel hvis det er feil på slave 2, så trenger man ikke feilsøke på slave 1. 72

85 8.6 Programmering i ix Developer [EAH] Her skal vi gi en veldig generell innføring i hvordan man programmerer de forskjellige skjermene i operatørpanelet. Vi ser først på hvordan vi tilknytter en knapp en oppgave. Figur 9.10 Vi markerer Logg inn knappen, og trykker oss inn på Actions fanen øverst i vundet. Der ser vi hva knappen skal gjøre i de ulike sammenhengene. Vi har valgt Click og der ligger det Multi Action. Så trykker vi oss inn på det valget og her ser vi midt i bildet hva som skjer når vi trykker på knappen. Først står det Login, det vil si at ved klikking på knappen så vil man få muligheten til å logge seg på forskjellige brukere. Under Login står det Show screen 2, det betyr at hvis man logger seg inn vil man bli sendt videre til bildet 2. Her ligger det altså to forskjellige oppgaver på en knapp. 73

86 8.7 Figurer [EAH] Alle figurer som er brukt er hentet i fra ix Developer sitt eget komponentbibliotek. Det kan åpnes ved å velge Multi Picture under Objects -fanen øverst i bildet. Etter du har valgt det må du trykke på som bildet under viser. Etter det kan du browse alle komponentene i biblioteket. Figur 9.11 Videre skal vi se på hvordan vi endrer farge på en komponent etter hvordan verdi taggen som er tilknyttet komponenten har. Ser vi på pumpen i bildet nr. 2 er den grå når pumpen ikke går og knappen har farge grå med teksten Av, altså taggen er 0. Når pumpen er i drift blir den grønn, samtidig som knappen endrer farge til grønn og teksten sier På. Taggen blir også satt til 1. 74

87 Under ser vi hvordan dette gjøres i ix Developer. Når det gjelder pumpen så finnes den i komponentbiblioteket. Her bruker vi to forskjellige bilder, ett for når pumpen er grå, og ett annet når den er grønn. Figur 9.12 For å endre farge og tekst på knappen må man inn på innstillingene for knappen. Bildet under viser ett utklipp av innstillingene for knappen til pumpen. 75

88 Figur 9.13 Her velger man Fill og Text, og får opp bilder under som viser hvordan man gjør fargeendringen. Figur

89 Under Actions til knappen for pumpen velger man hva som skal skje når man klikker på den. Her er det valgt Toggle Tag og referert til hvordan tagg som skal bli togglet. Bildet under viser hvordan. Figur

90 8.8 Tags [EAH] Bilder under viser en oversikt over taggene som er brukt. Hver tagg må ha et navn, datatype, lese- og/eller skriverettigheter og hvordan register taggen er linket opp mot. Figur 9.16 Det er noen tagger som ikke er linket opp mot et register. Dette er interne tagger, som har en initialverdi. Disse taggene brukes til å sette verdier i ulike faner og da må en velge hvilken verdi de skal ha til å begynne med. 78

91 8.9 Alarmer [EAH] ix Developer er utstyrt med en alarm server. Den ligger under Functions til venstre i bildet. Her kan man sett opp alarmene og hvordan de skal oppføre seg. Man legger inn en forklarende tekst, tagg, og hva som skal til for å aktivere alarmen. Alarmene er programmert i PLS programmet, og derfor bare linket opp mot hver enkelt tagg. Det hadde gått ant å programmert alarmene i ix Developer, men det hadde bare ført til en ny feilkilde. Bildet under viser hvordan alarmene er satt opp. Figur

92 9.10 Datalogging [EAH] Rett under hvor vi fant alarm serveren ligger Datalogger. Her kan vi velge hvilken verdi vi vil logge og lagre. Disse har vi bruk for når vi skal vise fram historikken til verdiene, og framstille dem i en trend. Bildet under viser hvordan dataloggeren er satt opp. Figur 9.18 I skjermbildet nr. 4 er det laget en trendframstilling for historikken. Når man trykker seg inn på innstillingene og videre inn på Curves må man pass på å velge Log Item og ikke Tag som man har gjort før. Dette er fordi vi skal framstille historikken til de taggene som vises i trenden på prosessbildet. Her velger man da verdiene ut i fra de man har opprettet i dataloggeren. Bildet under viser hvordan. Figur

93 9.11 Web-server [EAH] Oppgaveteksten ber oss om å sette opp operatørpanelet som en WEB-server for informasjon og fjernstyring av tankriggen via internett. Dette har vi løst ved å bruke ix Developer sin egen Remote Accsess (Se bildet under), som kobler seg opp mot en Java applikasjon som heter TightVNC. VNC er en protokoll som gjør fjernstyring av en datamaskin over nettverk mulig, slik at vi kan få tilgang til operatørpanelet via vår egen hjemmeside. Dette fører til at vi kan både skrive og lese verdier til systemet. Det eneste minuset er at man må ha en gammel versjon av Java installert på PCen. Det må også gjøres noen endringer på sikkerhetsinnstillingene, blant annet må Java stilles inn på laveste sikkerhetsinnstilling, samt at den spesifikke nettadressen til kamerasiden må legges til i unntakslisten til Java. Figur 9.20 Det ligger nå en fane med ix-panel på hjemmesiden, hvor man nå har tilgang til panelet (se bildet under). 81

94 Figur 9.21 Programkoden for å linke Java applikasjonen til nettsiden videre til ix-panelet er vist i bildet under. Det må deretter forwardes en port i ruteren, TCP 5800 og TCP Figur

95 10 Antialiasingfilter [HBR og NY] Som en del av prosjektet, skal prosjektgruppen konstruere to lavpass-filtre som skal settes inn før signalet går inn på AD-DA modulen i slave-pls en. Prosessen er plaget med en god del støy, forårsaket blant annet av fallhøyden fra innløpet i tanken til vannoverflaten, samt tankens smale radius. Ved å filtrere bort unyttig støy er tanken å få et bedre bilde av tankens faktiske tilstand. I bunnen av tanken på prosessriggen sitter det en trykktransmitter. Denne måler trykket i tanken, noe som brukes for å beregne vannivået. Vanntilførselen til tanken er øverst og vannet renner da rett ned og treffer vannoverflaten i tanken. Det at vanntilførselen skjer på denne måten sørger for en del plasking og spruting på vannoverflaten og et stykke under vannoverflaten. Denne plaskingen oppfattes som støy og gjør at målingen av nivået blir vanskelig. Det er derfor nødvendig å konstruere et filter som kan filtrere bort støyen, slik at nivåmålingen blir korrekt. Også skal vi konstruere en lavpass filter av første orden for utløpet. 11 Nivåmåler [HBR og NY] Nivåmåleren er relativt mye plaget av støy, og med ganske høy amplitude. Dette kunne gitt store feilmeldinger om nivåets stabilitet, hvis det ikke ble filtrert bort før det sendes inn i regulatoren. For å komme frem til en god design av filteret, måtte man først finne hvilke frekvenser man vil filtrere bort. Dette ble gjort ved at en ekstern regulator ble tilkoblet riggen, innstilt ved hjelp av autotuner, og at man så på støyfrekvens målt ved forskjellige høyder, samt forskjellige verdier på utløpet. Støyen ble målt med oscilloskop ut fra LT1 (-)(Level Transmitter 1) på tankriggen. Støymåling_LT1 viser gir oss verdier på hva slags støy vi måler fra LT1(-). Det man er mest interessert i, er målingene som gir oss lavest frekvens på støyen, da det er denne man må basere filteret ut på, men man er også interessert i hvilken amplitude dette signalet har. Filteret som skal være tilkoblet nivåmåleren til tank 1, LT1, skal ifølge Prosjekts spesifikasjonene være et andreordens Butterworth-filter. 83

96 Figur Støymåling av nivåmåler Figur Andreordens filter Figur Andreordens filter 84

97 Figur 11.4 Testing av filteret i Multisim 85