TOTANK RAPPORT. Gruppe 1 og 2

Transkript

1 TOTANK RAPPORT Gruppe 1 og 2 Høgskolen i Sør-Trøndelag 2015

2

3 Sammendrag Totank-prosjektet og bonusoppgaven er deler av ett større prosjekt i faget «Reguleringsteknikk og styresystemer» for 2EA. Totank-prosjektet er ett sammarbeidsprosjekt mellom to og to prosjektgrupper, og bygger videre på entank-prosjektet, mens bonusoppgaven skal gjennomføres gruppevis. Denne rapporten er skrevet i samarbeid med begge gruppene, mens en egen rapport for bonusoppgavene er skrevet av hver enkelt gruppe. Rapporten beskriver godt arbeidet som er utført, de endringene vi har foretatt som følge av erfaringer og tilbakemeldinger fra entank-prosjektet, i tillegg til samarbeidet mellom de to prosjektgruppene og de forskjellige prosjektdeltagerne. Resultatet har blitt en meget tilfredsstillende nivåreguleringen av to forskjellige tankene på tankriggen, samt to veldig ryddige og oversiktlige brukergrensesnitt. Erfaringene vi har gjort oss er mange, men hovedforskjellen i dette prosjektet kontra tidligere gjennomførte prosjekt, må være måtene vi har løst utfordringene med å få 11 personer til å samarbeide sammen. I tillegg kommer problemene som dukker opp når man skal slå sammen PLS-programmering fra to forskjellige prosjektgrupper som har to forskjellige måter å programmere på. På tank 1 brukte vi manuell selvjustering, mens på tank 2 brukte vi ITAE-kriteriet for å komme fram til følgende parameter: Tank 1 Tank 2 K p T i For tank 1 får vi ett innsvingningsforløp som kan beskrives som minimum forstyrrelse, mens tank 2 får innsvingninger som ligner minimum areal.

4 Forord Vi har i løpet av denne perioden skrevet flere rapporter om tankriggen som står i Gunnerusgata. Dette er den siste delen av den lange rekka med rapporter, og vi sitter igjen med erfaringer og tanker. Hvilke tanker? To tanker, begge med velfungerende nivåregulering. Den største utfordringen med to tank-prosjektet trodde vi kom til å bli størrelsen på gruppa. Det førte til at vi hadde fokus på organisering og arbeidsfordeling fra starten av. Vi vil takke våre medstudenter, våre familier og våre veiledere. Trondheim Gruppe 1: Eyvind Bjørsland Torbjørn Morken Anders Aabakken Øyvind Eklo Magnus Bergsbakk Gruppe 2: Martin Sivertsen Henrik Malvik Hilde Bye Jonas Henriksen Anders Aglen Pedersen Helge Gården

5 Innholdsfortegnelse 1 Oppgavetekst Flytskjema Bilder av riggene Gruppedeltakere Prosjektgruppe Prosjektgruppe Veiledere Totank Kommunikasjon (AAa) Programmet i Q00 master PLS-en (HMH) Programmet i FX1N slave 1 PLS-en (EB) Programmet i FX1N slave 2 PLS-en (HMH) Brukergrensesnitt PC (MGS) Operatør panel (JH) Innregulering Resultat Bonus Gruppe 1 Frekvensomformer Kommunikasjon (TM) PLS (MB) Brukergrensesnitt - HMI (MB) Innregulering (ØE) Resultat Bonus Gruppe 2 Frekvensomformer Konfigurasjon (AAP) Programendringer i PLS (HILB) Brukergrensesnitt (HBG) Operatørpanelet (HBG) Resultat Prosjektstyring Gruppe Gruppe Samarbeid totank... 43

6 7 Forkortelser, definisjoner, utstyr og software Forkortelser (MB) Definisjoner (ØE) Utstyr (MB og ØE) Software (ØE) Vedlegg Vedlegg 1: PLS-program Master Vedlegg 2: PLS-program Slave 1 Vedlegg 3: PLS-program Slave 2 Vedlegg 4: Testskjema totank Vedlegg 5: Testskjema bonusoppgave Gruppe 1 Vedlegg 6: Lese-/Skriverettigheter InTouch Figurliste Figur 3-1 Nettverksoversikt... 7 Figur Blokksjema som beskriver prosessen i masterprogrammet Figur Inndeling av POU'er i masterprogrammet Figur Oversikt over alle berørte bufferminner og dataregistre som er benyttet i utvekslingen av data mellom masteren og slave PLS-ene Figur Deklarering av boolske tilstandsvariable Figur 3-6 Flytskjema PLS slave Figur 3-7 Funksjonsblokk alarmer slave Figur 3-8 Start/Stopp pumpe slave Figur 3-9 Styring av utløpsventiler slave Figur 3-10 Rykkfrie overganger slave Figur 3-11 Rykkfrie overganger slave Figur Blokkskjema som beskriver prosessen i programmet til slave Figur Inndeling av POU'er i slaveprogrammet for slave Figur Speiling av minneceller slik at bit #0 og #4 fra Slave2_ERverdiFraOperatør sendes ned til slave 1 for videre bearbeiding Figur Omgjøring av hjelpevariabelen til PI-regulatoren Figur Oppdatering av forrige avvik i avviksutregneren Figur Hovedvindu for overvåkning av totankprosessen Figur Alarmhåndteringsvindu for to tanker Figur Vindu for historisk trend Figur Oppretting av alarmgrupper Figur Tilordning av tag til ny alarmgruppe Figur Endring av alarmgruppe fra $System til Tank Figur Endring av alarmgruppe i action-scriptet... 20

7 Figur 3-24 Navigasjons oversikt Figur 3-25 Hovedvindu for to tank panelet Figur 3-26 Paneletvindu for tank Figur 3-27 Panelvindu for tank Figur 3-28 Panelvindu for alarmhåndtering Figur 3-29 Innsvingning manuell selvjustering Figur Sprangrespons på tank 2 når referansen går fra 30-60% Figur Oppdagelse av t1, t2 og Δy ved hjelp av sprangrespons i tanken Figur Sprang i utløp fra 3/3-1/3 i tank Figur Sprang i referansen fra 30-60% i tank Figur 4-1 Skisse Bonusoppgave gruppe Figur 4-2 Kommunikasjon bonusoppgave gruppe Figur 4-3 Oppsett GX-Developer Figur 4-4 Bit oversikt VLT Figur 4-5 Konvertering fra INT til DINT Figur 4-6 Skalering pådrag til VLT Figur 4-7 Skalering pådrag 0% Figur 4-8 Skrive ti VLT Figur 4-9 Setting av bit til VLT Figur 4-10 Start/Stopp pumpe via flagg Figur 4-11 Lese fra VLT Figur 4-12 Sette reg. ventil åpen Figur 4-13 Alarmlampe Frekvensomformer Figur 4-14 Ikon pumpe i InTouch Figur 4-15 Front VLT Figur 4-16 Regulator innstillinger Figur 4-17 Innsvingningsforløp 33% til 100% og 100% til 33% Figur 4-18 Innsvingningsforløp foroverkobling Figur 4-19 Innsvingningsforløp foroverkobling manuelt utløp Figur 4-20 Innsvingningsforløp beste resultat Figur 5-1 Profibus konfigurasjon Figur 5-2 Bit oversikt frekvensomformer Figur 5-3 Profibuskonfigurasjons-POU som legges i Master-PLS Figur blir sendt som et konstant pådrag Figur 5-5 Nye verdier i grensekontroll Figur 5-6 Omregning av pådrag fra regulator til frekvensomformer Figur 5-7 Oversikt av kontrollord fra manual VLT 2800, DP V1 PROFIBUS som viser hvilke funksjoner de ulike bitverdiene har Figur 5-8 Start og stopp av pumpe via frekvensomformer Figur 5-9 Vi leser av er-verdi til omformer og sender det til HMI Figur 5-10 Riggbildet med endringer for frekvensomformerstyring Figur 5-11 Inntasting av desimaler for Ti ble fikset Figur 5-12 Pop-up skjermen for pumpen Figur 5-13 Pumpen er «klikkbar» og gjort større Figur 5-14 Innsvingningsforløp... 40

8 1 Oppgavetekst Totankprosjektet har som hovedmål å teste to gruppers evner til å samarbeide om en felles problemstilling. Begge gruppene har tidligere arbeidet med liknende oppgaver hver for seg i tidligere faser av prosjektet. De har dermed tidligere løst tilsvarende tekniske utfordringer. Prosjektets utfordring er å regulere nivået i to separate tanker. De har samme matepumpe, men tilførselen kontrolleres av 2 reguleringsventiler. I tank 1 er det en elektromotor som driver ventilen, mens det i tank 2 er en pneumatisk ventil. Pneumatisk vil si at den er drevet av trykkluft fra en kompressor. Dynamikken til systemet med to tanker gjør at vi må finne nye parametere til regulatorene. Noe av utfordringene ved dette prosjektet er samarbeidet om de delene av prosjektet som omfatter felleskomponenter for tankene. Her må man bli enige om hvilke områder i PLS som skal brukes av hvilken tank. En av gruppene må ta ansvar for operatørpanel og det PC baserte brukergrensesnittet, og videre finne felles adresser med den andre gruppen. Det er essensielt at koordineringen går bra, da gruppene ellers vil ødelegge for hverandre, og sannsynligvis allokere samme minneområder. Gruppene må også samhandle i dokumentasjonen av prosjektet, da dette skal fremstå som helhetlig. Suksesskriteriet vil være at leseren opplever gruppene som én samkjørt prosjektgruppe. 1.1 Flytskjema Side 1 av 45

9 1.2 Bilder av riggene (Tatt av EB) Bilde 1 PLS-rigg Side 2 av 45

10 Bilde 2 Tankrigg Bilde 3 Tankrigg bakside Side 3 av 45

11 2 Gruppedeltakere 2.1 Prosjektgruppe 1 Prosjektgruppe 1 består av følgende medlemmer: Eyvind E. Bjørsland Allmen Eivind_eb@hotmail.com Anders Aabakken Elektriker a.aabakken@gmail.com Magnus K. Bergsbakk Fagbrev sveiser magnus438@hotmail.com Øyvind Eklo Automatiker o_eklo@hotmail.com Torbjørn Morken Prosesstekniker torbjornmorken@gmail.com Side 4 av 45

12 2.2 Prosjektgruppe 2 Prosjektgruppe 2 består av følgende medlemmer: Henrik Malvik Allmen henrikmh@student.hist.no Anders Aglen Pedersen Automatiker andersap@student.hist.no Jonas Henriksen Elektriker jonashen@student.hist.no Hilde Bye Bachelor i språk, fransk og nordisk hibye@student.hist.no Helge Gården Automatiker helgegaa@student.hist.no Martin Grimstad Sivertsen Allmen martigs@student.hist.no Side 5 av 45

13 2.3 Veiledere Prosjekt i Styresystemer og reguleringsteknikk Pål Gisvold er veileder for prosjektgruppe 1 Han jobber som Høgskolelektor ved avdeling for teknologi ved HiST, ved program for elektro- og datateknikk. Mail: pal.gisvold@hist.no Arnfinn Hofstad er veileder for prosjektgruppe 2 Han jobber som Førstelektor ved avdeling for teknologi ved HiST, ved program for elektro- og datateknikk Mail: arnfinn.hofstad@hist.no Side 6 av 45

14 3 Totank Prosjekt i Styresystemer og reguleringsteknikk 3.1 Kommunikasjon (AAa) I denne delen av prosjektet skal vi bruke de samme komponentene som i miniprosjektet. Oppsettet vil da bestå av; master PLS, slave PLS 1, slave PLS 2, ix touchpanel og PC basert skjermsystem. Det vil si at master PLSen blir bindeleddet mellom slave PLSene, operatørpanelet og det PC baserte skjermsystemet. All logikk vil ligge i de to slave PLSene, mens det i master kun vil ligge ett program som mottar og sender telegram mellom slaver og betjeningsorganer. Dette vil være positivt med tanke på kommunikasjonsbrudd, da reguleringen vil opprettholdes med de eksisterende settpunkt. Alle settpunkt og regulatorparameter blir lagret i batterimatede dataregister. Dette sørger for å starte prosessen med de samme driftsinnstillingene dersom man er utsatt for ett strømbrudd. Alle kontrollfunksjoner opereres ved SET/RESET funksjoner. Dette fordi man skal ha muligheten til å kontrollere prosessen fra flere steder. Vi kan da for eksempel bruke SET funksjonen med en puls fra operatørpanelet, og RESET med en puls fra InTouch. Slave 1 brukes til å kontrollere nivået i tank 1. Den mottar settpunkt og regulatorparameter fra InTouch eller operatørpanelet. Da vi har måling i utløpet av tank 1, er det mulig å velge flere forskjellige typer foroverkopling. Slave 2 brukes til å regulere nivået i tank 2. På denne tanken har vi kun mulighet til ordinær regulering, da utløpet ikke er målt. Denne tanken har en pneumatisk reguleringsventil. Den vil normalt virke mye raskere enn den som er motorstyrt. Figur 3-1 Nettverksoversikt Side 7 av 45

15 3.2 Programmet i Q00 master PLS-en (HMH) Programmets oppbygning Når vi begynte med totanksprosjektet var det et behov for å ta en vurdering om hvilket PLS-program som skulle benyttes, da vi nå var to grupper som skulle slås sammen. I bunn og grunn fungerer master-programmet til begge gruppene like godt, men de fungerte på vidt forskjellige måter. Siden det ble gjort den vurderingen av HMI-gjengen at brukergrensesnittet på operatør PC-en til gruppe 2 skulle bli tatt i bruk, falt det også naturlig å forholde seg til masterprogrammet til gruppe 2. På denne måten vil InTouch, OPC-server og master kunne kommunisere på samme måte som i entankprosjektet, uten at det må til ekstra arbeid for å få disse programdelene til å samarbeide. Vi konkluderte dermed at vi skal bruke masterprogrammet til gruppe 2. Masterprogrammet til gruppe 2 fungerer kun som en videreformidler av data - en bro mellom slave PLS-ene og HMI -, og siden det nå skal sendes data til to slaver, og ikke én, er det et behov for å utvide programmet. Masterprogrammet skal i tillegg fungere som normalt etter et strømbrudd, og denne programbiten har blitt utvidet for å lagre parameterne som skal sendes til slave 2. Les kapittel Strømbrudd i Q00 PLS i entankrapporten til gruppe 2 for videre informasjon angående hvordan det er tatt stilling til strømbrudds-situasjonen i master PLS-en. Masterprogrammet får følgende funksjon: Figur Blokksjema som beskriver prosessen i masterprogrammet. Det er verdt å merke seg at dette blokkskjemaet beskriver i detalj hvordan et scan i master PLS-en går gjennom dette programmet. Det er hensiktsmessig for oss å danne en POU for hver blokk presentert i dette skjemaet. Side 8 av 45

16 Figur Inndeling av POU'er i masterprogrammet Dataoverføring mellom master, slave 1 og slave 2 Dataoverføringen mellom master PLS-en og slave PLS-ene har i all hovedsak blitt realisert på samme måte som i entanksprosjektet og miniprosjektet. Les kapittel PROFIBUS-DP, Master-PLSprogram og Program for FX1N slave PLS-ene i miniprosjektrapporten til gruppe 2 for mer informasjon angående dataoverføring via Profibus. Igjen er det viktig å merke seg at vi velger å fortsette å bruke ProfiBus-konfigurasjonen fra miniprosjektet, da dette gir oss muligheten til å sende og motta 16 dataregistre mellom masteren og slave PLS-ene hver for seg. Totanksprosjektet krever at en god del parametere blir sendt mellom PLSene, og vi har dermed valgt å dedikere et bufferminne for hver parameter og dens respektive dataord. Vi benytter oss av MOV-blokker for å utveksle data mellom våre globale variabler og dataregistrene dedikert for kommunikasjon via Profibus. Hvilke dataregister og bufferminner i PLSene som blir berørt av dataoverføringen blir illustrert i figuren under. Figur Oversikt over alle berørte bufferminner og dataregistre som er benyttet i utvekslingen av data mellom masteren og slave PLS-ene. Side 9 av 45

17 Ut i fra figuren på forrige side kan man merke seg at funksjonene til datautvekslingen mellom hver slave og master er de samme. Ved hjelp av POU KommunikasjonSlave1 i masterprogrammet skriver og leser vi verdier til og fra slave 1, og ved hjelp av POU KommunikasjonSlave2 i masterprogrammet skriver og leser vi verdier til og fra slave 2. Det er også lagt inn muligheter for at slavene kan overskrive verdier i master, les kapittel 2.2 Dataoverføring mellom Master og Slave i entanksrapporten til gruppe 2, for ytterligere informasjon om hvordan overskrivning av verdier fra slave til master foregår og hvorfor det er et behov for denne funksjonen. Det er dog verdt å merke seg at dataregistrene som består av boolske tilstandsvariabler er svært forskjellige fra de to slavene, les neste delkapittel Globale variabler i master Globale variabler i master Når det kommer til de globale variablene i masteren, er det bare et behov for å utvide oppsettet fra entanksprosjektet slik at vi også tar hensyn til utvekslingen mellom den nye slaven. Les kapittel Globale variabler i master i entanksrapporten til gruppe 2 for en grunnleggende innføring i oppsettet av global label. For å etablere et ryddig oppsett har vi bestemt oss for at alle globale variabler som har med slave 1 å gjøre, skal starte med fornavnet Slave1_, hvorav alle globale variabler som har med slave 2 å gjøre, skal starte med fornavnet Slave2_. Figur Deklarering av boolske tilstandsvariable. I begge slavene er det interessant å lese ER-verdier og skrive SKAL-verdier for å styre prosessen i begge slaveprogrammene. Vi har derfor valgt å danne to variabler som skriver SKAL-verdier til hver sin slave, og to variabler som leser ER-verdier fra hver sin slave. Inne i disse dataordene finner vi boolske tilstandsvariable, hvor hver bit i ordet henviser til om en tilstand er sann eller usann, høy eller lav. Siden at slaveprogrammene er forskjellige, vil også hver bit i disse dataordene ha forskjellige funksjoner, se tabellen under. Bit Slave1_SkalVerdiFraOperatør, K4M0 Slave1_ERverdiFraOperatør, K4M16 LSB 0 Reguleringstype, P eller PI Tilstand alarm HH 1 Velg P-foroverkobling Tilstand alarm H 2 Velg D-foroverkobling Tilstand alarm L 3 Av/På Magnetventil 1 Tilstand alarm LL 4 Av/På Magnetventil 2 Tilstand pumpe 5 Av/På Magnetventil 3 Tilstand magnetventil 1 6 Start/Stopp Pumpe Tilstand magnetventil 2 7 Reguleringsmodus, auto eller manuell Tilstand magnetventil 3 8 Kvitter alarm Tilstand alarmlampe 9 Reguleringsmodus, direkte eller reversert Tilstand kvittering Bit Slave2_SKALverdiFraOperatør, K4M40 Slave2_ERverdiFraOperatør, K4M56 LSB 0 Reguleringstype, P eller PI Tilstand alarm HH 1 Reguleringsmodus, auto eller manuell Tilstand alarm H 2 Kvitter alarm Tilstand alarm L 3 Reguleringsmodus, direkte eller reversert Tilstand alarm LL 4 Ingen funksjon Tilstand alarmlampe Side 10 av 45

18 3.3 Programmet i FX1N slave 1 PLS-en (EB) Detaljert og full programbeskrivelse for slave 1 er vist i entankrapporten. I denne rapporten tar vi for oss endringer fra entankprosjektet, som både omfatter tilpassning til ny master, slave 2 og feilrettinger. Oppgaven til slave 1 er å regulere nivået i tank 1, styre magnetventilene og håndtere alarmaksjoner fra slave 2. Manglene fra entank som vi har fikset, er bidraget fra D-foroverkoblingen og rykkfrie overganger Flytskjema slave 1 Under, i figur 3-6, er et flytskjema som viser gangen i programmet. Skjemaet er ikke en eksakt representativ modell for rekkefølgen oppgavene utføres i, men en tilnærming. Figur 3-6 Flytskjema PLS slave Programstruktur og funksjon Hele PLS-programmet har utgangspunkt i programmet for entankprosjektet. Oppgaven har vært å tilpasse slave 1 til master-programmet, og rette opp feil/mangler fra entank-delen. Endringene som er gjort, er styring av pumpe og ventiler, ekstra funksjon for alarmhåndtering for slave 2, rykkfrie overganger er fikset og D-foroverkoblingen er endret slik at den gir mer bidrag til pådraget. Side 11 av 45

19 3.3.3 Alarmhåndtering Alarmlampe og styring av pumpe er bare koblet til slave 1. Derfor må slave 1 få indikasjon på pumpestopp og blink for alarmlampe fra slave 2 via master. Det er lagt til to minneceller (M560 og M561) som får sin status fra slave 2. M560 har navnet «AlarmLampeSLAVE2» og indikerer blinksekvens til alarmlampa på riggen. Den går inn i funksjonsblokka og er videre koblet direkte til alarmlampa på utgangen av blokka, i parallell med blinkindikatorer for alarm i slave 1 (OR-funksjon). Hvordan pumpestopp ved kritisk alarm i slave 2 er lagt inn, er beskevet i avsnittet for styring av pumpe og ventiler. Figur 3-7 Funksjonsblokk alarmer slave Styring pumpe og ventiler I totankprosjektet har vi måttet flytte noe enkel logikk for styring av pumpe og ventiler fra master og ned i slaven. Det brukes en togglevippe laget som en funksjonsblokk til å starte/stopp pumpe og åpne/lukke ventiler. Pumpa skal stoppe ved kritisk høyt nivå (nivå > 90%) også for tank 2. Vi har lagt inn et bit, «HighLevelAlarm_SLAVE2», som indikerer pumpestopp ved kritisk høyt nivå i slave 2. Figur 3-8 Start/Stopp pumpe slave 1 Togglevippa er også brukt til styring av ventilene. Denne funksjonen var oppe i master hos gruppe 1 i entankprosjektet. Under er styring av ventiler i slave 1 vist. Status for ventiler sendes tilbake til master på samme måte som i entankprosjektet. Figur 3-9 Styring av utløpsventiler slave 1 Side 12 av 45

20 3.3.5 Rykkfrie overganger Rykkfrie overganger (Bumpless transfer) var ikke helt på plass i entankprosjektet for gruppe 1 sin slave. Dette er implementert i totankprosjektet. Rykkfrie overganger vil si at det ikke skal oppstå sprang i pådragsorganer når det byttes mellom regulatormoduser. Dette gjelder både P til PI og motsatt, og mellom manuell og auto. Ved bytte fra P- til PI-regulator vil PI-pådraget bli satt lik det siste P-pådraget. Deretter vil PIregulatoren straks begynne å regulere seg mot referansen hvis nivået avviker, men uten store hopp i pådraget akkurat ved regulatorskifte. Ved bytte fra PI- til P-regulator vil det nominelle pådraget for P-regulatoren bli satt lik det forrige PIpådraget, slik at om nivået ligger på referansen, vil det bli værende der også ved bytte til P-regulator, uten noe sprang i pådraget. Det nominelle pådraget overskrives hele tiden mens PI-regulatoren er aktivert. Når regulatoren står i auto, oppdateres det manuelle pådraget hele tiden til det siste pådraget fra enten P- eller PI-regulatoren. Dermed vil nivået i tanken ligge stabilt og pådraget vil ikke hoppe ved bytte til manuell regulering. I manuell modus gjøres det kontinuerlig klart for skifte til både P- og PI-regulator. Det manuelle pådraget skrives til det nominelle pådraget for P-regulatoren, og det skrives også til «forrige pådrag» for PI-regulatoren. Nivået overskriver referansen hele tiden, så når man bytter til automatisk modus vil referansen være lik det forrige nivået mens regulatoren var i manuell modus. Da får man ikke noe hopp i pådraget eller nivået. Programdelen for rykkfrie overganger er vist i figur 3-10 og figur 3-11 under. Figur 3-10 Rykkfrie overganger slave 1 Figur 3-11 Rykkfrie overganger slave 1 Side 13 av 45

21 3.3.6 D-foroverkobling D-foroverkoblingen ga for lite pådrag ved endringer i utløpet i «entank»-delen til gruppe 1. Dette var bare forårsaket av en skaleringsfeil i algoritmen, hvor det ble dividert på 100 istedenfor 10. Algoritmen som er brukt for D-foroverkoblingen er: u Dff (k) = T dff10 u Dff (k 1) + K pff10 T dff10 (v(k) v(k 1)) 10 N 10 (h + T dff N ) Feilen lå i nevneren i det siste leddet, hvor det var multiplisert med 10 to ganger: (h + T dff N ). Side 14 av 45

22 3.5 Programmet i FX1N slave 2 PLS-en (HMH) Programmets oppbygning I slave 2 finner vi gruppe 2 sitt slaveprogram fra entankprosjektet, men en noe forenklet versjon. Slave PLS-en har ingen flowmåler på inngangen til AD/DA-modulen, og den har heller ikke noen mulighet til å skru av og på magnetventiler eller endre tilstanden til pumpa direkte. På denne måten sløyfes følgende funksjoner fra slaveprogrammet: Foroverkoblingsregulatorene fjernes. Ingen behov for summering av pådraget, pådragsblokken fjernes. Styring av magnetventilene fjernes. Styring av utgangen som tidligere hørte til pumpa fjernes. Resten av funksjonene fra entankprosjektet beholdes, les kapittel 2 PLS-Program i entankrapporten til gruppe 2 for en innføring på hvordan programmet er oppbygd. Dette gir oss følgende blokkskjema som beskriver PLS-programmets gang: Figur Blokkskjema som beskriver prosessen i programmet til slave 2. Det er hensiktsmessig for oss å danne oss en POU for hver blokk i dette skjemaet. POU ene Profibusmodul og ADDA-modul er lik som i entankprosjektet, hvorav POU en Regulering er den samme som FX1NPLS-enhet fra entankprosjektet til gruppe 2, bare at vi har sløyfet noen funksjoner og gitt den et mer beskrivende navn. Etter ønske fra veileder har vi også lagt alarmhåndteringen i sin egen programbit. De globale variablene i slave2-programmet er ellers likt fra entankprosjektet. Side 15 av 45

23 Figur Inndeling av POU'er i slaveprogrammet for slave Alarmhåndtering i slave 2 Samme spesifikasjoner for alarmblokken i slave 1 gjelder også for slave 2. Hva dette vil si er at slave 2 skal også ha muligheten for å skru av pumpa ved kritisk høy tilstand, samt kunne få alarmlampen til å blinke. Siden at slaven ikke er koblet direkte til alarmlampen eller pumpa, trenger vi å sende bit ned til slave 1 slik at vi kan indirekte ta styring. Vi velger derfor å legge bit #0 og bit #4 i Slave2_ERverdiFraOperatør i bit #10 og bit #11 i Slave1_SKALverdiFraOperatør slik at høy kritisk alarm fra slave 2 samt beskjeden om at alarmlampen skal lyse blir sendt ned til slave 1 fra slave 2. Se 0 Globale variabler i master Dette gjøres ved å speile minnecelle M60 med minnecelle M10, samt speile minnecelle M56 med minnecelle M11. Figur Speiling av minneceller slik at bit #0 og #4 fra Slave2_ERverdiFraOperatør sendes ned til slave 1 for videre bearbeiding. Dette gjør at bit#10 og bit#11 i Slave1_SKALverdiFraOperatør også får en funksjon: Bit Slave1_SKALverdiFraOperatør, K4M0 10 Slave 2 alarmlampe 11 Slave 2 stopp pumpe Side 16 av 45

24 3.5.3 Endringer i slaveprogrammet til slave 2 Som nevnt tidligere fungerer slaveprogrammet i slave 2 svært likt som slaveprogrammet i entankprosjektet til gruppe 2, bare at noen funksjoner er sløyfet. Det er dog et behov for å gjøre noen endringer, da ikke alt fungerte helt optimalt på entankdemonstrasjonen. Følgende endringer har måttet ta plass: Legge inn mulighet for å skrive desimaltall i integrasjonstiden til PI-regulatoren. Rykkfri overgang fra manuell regulator til PI-regulator. For å gjøre det slik at desimaltall blir oppfattet av slaven, trenger vi at innskrevet integrasjonstid fra HMI blir ganget med 10 slik at tallet blir gjort om til et heltall. Siden PLS-programmet nå får inn en integrasjonstid ganget med 10, trenger vi å gjøre om på hjelpevariabelen til integrasjonstida i PIregulatoren. Vi endrer den fra Ti * h * 100, til Ti10 * h * 10. Les kapittel 2.11 PI-regulator i entankrapporten til gruppe 2 for mer informasjon angående denne hjelpevariabelen. Figur Omgjøring av hjelpevariabelen til PI-regulatoren. Den rykkfrie overgangen fra manuell regulator til PI-regulator var ikke rykkfri siden at det forrige avviket ble kun oppdatert når vi var i PI-modus. Dette gjorde at når vi gikk tilbake til PI-regulatoren, så arbeidet regulatoren med en forrige avviksverdi som ikke lenger er gjeldende. Ved å flytte oppdateringen av forrige avvik til avviks-utregneren, blir denne verdien oppdatert hele tiden, og overgangene fra manuell til PI-regulatoren blir nå rykkfri. Figur Oppdatering av forrige avvik i avviksutregneren. Oppdateringen av forrige avvik skjer i starten av funksjonsblokken før vi regner ut det nye aktuelle avviket, på denne måten ligger det forrige avviket i variabelen Avvik, som vi så flytter til utgangen Forrige_Avvik. Denne utgangen er koblet til den globale variabelen ForrigeAvvik1000_32, som så går inn til PI-regulatoren. Les kapittel 2.8 Avviksutregning i entanksrapporten til gruppe 2 for mer informasjon angående denne funksjonsblokken. Side 17 av 45

25 3.6 Brukergrensesnitt PC (MGS) I og med at vi i totank-delen av prosjektet skulle samarbeide med en annen gruppe måtte det tas en vurdering og påfølgende avgjørelse om hvilken gruppe sin HMI (Human Machine Interface) vi skulle jobbe videre med. Vi lagde et utkast og begge gruppene ble enige om å fortsette med gruppe 2 sitt HMI. Deretter var det bare å gjøre forbedringer (ordne funksjoner som ikke var helt optimale under entank-demonstrasjonen) og utvide det for å regulere to tanker Utvidelse av brukergrensesnitt fra en til to tanker Når vi nå skulle utvide HMI-et til å inneholde styring av tanker, så innebar det to sett med tanker, to sett med regulatorinnstillinger og to sett med sanntidstrender. Det kunne fort blitt rotete å ha alt dette i ett vindu, men vi tok en vurdering og fant at det ble mest oversiktlig å ha all styring og observasjon av verdier i ett hovedvindu. Slik slipper man å forflytte seg mellom flere vinduer når man skal styre og overvåke prosessen men i stedet bare flytte blikket rundt på samme side. Vi la stor vekt på å prøve å organisere elementene på hovedvinduet slik at det ble så ryddig og oversiktlig som mulig, og ga minst mulig mulighet for misforståelse og uklarhet i funksjoner. Under kan du se hvordan de ferdige vinduene ble seende ut, man kan navigere imellom de ved å trykke på knappene øverst, trykker man Bytt bruker så kommer det et lite pop-up-vindu der man kan endre bruker eller logge av. Figur Hovedvindu for overvåkning av totankprosessen All utvidelse gikk i hovedsak ut på å lage kopier av elementene i tank 1 og deretter tilordne nye tagger som ble opprettet for funksjonene til tank 2. Tank 2 har hverken utstrømmingsmåler eller magnetventiler, så foroverkoplingsdelen (som baserer seg på målt utløp) utgår. Side 18 av 45

26 Når det gjelder fargevalg har vi basert de på gjesteforelesningen av Edmund Knutsen, der han fortalte at «windows-grå» var forsket frem som den mest nøytrale og behagelige fargen å ha på en bakgrunn, og at ytterligere farger måtte brukes sparsomt og ha en klart definert funksjon. Hos oss har vi valgt å ha blått der det er vann/væske, grønt der ting er slått på/aktive og rødt der det er alarmtilstand/kritisk tilfelle. Vi hadde tidligere valgt at væskenivået i tanken skulle bli rødt når det var kritisk nivå, dette fordi det skulle være enda tydeligere at noe ureglementert var i gjære, men etter kommentarer fra oppdragsgiver/veileder som mente det var litt rart så har vi valgt å gå bort fra det. Visualiseringen av selve tankriggen er gjort slik at den skal ligne mest mulig på den fysiske riggen. Å ha sanntidstrend-vinduene overfor hverandre gjør at vi lettere kan følge med på om endringer i pådrag eller nivå i den ene tanken innvirker på den andre, noe som er meget praktisk. Både vinduet for alarmtilstander og historisk trend inneholder to sett med display for logging, ett til hver tank. Figur Alarmhåndteringsvindu for to tanker Figur Vindu for historisk trend Side 19 av 45

27 3.6.2 Alarmhåndtering for to tanker Nå som vi skal behandle alarmtilstandene til to forskjellige tanker så tenkte vi det ble mest mulig oversiktlig å ha to Distributed Alarm Display for alarmlogging og to knapper for kvittering, ett sett til hver tank. Det første vi gjør er å opprette to alarmgrupper, en til hver tank: Special Alarm Groups Add og legger til to nye, Tank1 og Tank2. Figur Oppretting av alarmgrupper Nå kan taggene som er tilknyttet alarmer tilordnes hver sin gruppe, dette gjør vi ved å åpne Tagname Dictionary (Ctrl + T i development-modus) og finne de taggene som er tilknyttet alarmer. Her ser vi at det er en knapp det står Group på, trykker vi på den kan vi velge hvilken gruppe den skal høre til. Som default er $System valgt, men vi endrer til Tank1 for de alarmene som tilhører tank 1 og vice versa. Figur Tilordning av tag til ny alarmgruppe Etter at alarmtaggene er tilordnet hver sin gruppe er det på tide å konfigurere Distributed Alarm Display (DAD) til å vise alarmer fra de nyopprettede alarmgruppene. Dette gjør vi ved å dobbeltklikke på DAD, da kommer vi inn på Alarm Configuration. Nederst i det vinduet står det Alarm Query, der må den overordnede alarmgruppen $System endres til Tank1 og (og tilsvarende til Tank2 i det andre DAD-et) Figur Endring av alarmgruppe fra $System til Tank1 Tilsvarende må også alarmkvitteringen endres fra $System til Tank1 (og Tank2) i action-scriptet tilhørende alarmkvitteringsknappene. Figur Endring av alarmgruppe i action-scriptet Nå skal alarmene til hver tank dukke opp i sitt respektive alarmloggingsvindu, og kan bli kvittert med hver sin knapp. Side 20 av 45

28 3.7 Operatør panel (JH) I starten av To Tank prosjektet måtte vi bestemme oss for hvilket av gruppenes operatørpanel vi skulle jobbe videre med, på grunn av at gruppenes forskjellige operatør panel var laget i forskjellige versjoner av ix-developer ble det til at det var gruppe nummer en sitt panel som ble valgt. For å få begge tankene opp og gå valgte jeg å lage nye tagger med navn lettere og finne frem til i programmet. Her valgte vi å kalle taggene med strukturen «TankX.Les/SkrivAksjon», for eksempel «Tank1.LesMagnetventil1», dette gjorde at det var veldig lett og lete frem riktig tagg, siden de ble sortert etter hvilken tank de tilhørte. Ved kopiering av gamle komponenter fra det originale operatørpanelet ble det dessverre et problem med at gamle tagger fulgte med, og lagde krøll, derfor ble det enklest og lage hele operatørpanelet fra bunnen av, men og bruke de to gruppenes paneler som inspirasjon. Siden operatørpanelets oppgave er å gi brukeren en rask og god oversikt over de viktigste parameterne i prosessen valgte jeg å lage et hovedpanelbilde som tilbyr dette. Dette gjør vi med sterke farger og enkle symboler. I hovedvinduet kan vi se satt referanse og nivå i begge tankene, samt styre pumpen, hvis noen av regulatorene er satt i manuell tilstand vil vi også kunne lese pådraget i stedet for referansen. I de aller fleste situasjoner vil Figur 3-24 Navigasjons oversikt det være nok for operatøren og se på dette bilde. Om vedkomne ønsker å styre og følge ekstra nøye med en tank, kan han gå inn på «Tank»-panelene ved å trykke på enten «Tank 1» eller «Tank 2», det er også mulig og trykke på selve tankene. I høyre hjørne er det en navigasjonsknapp som fører brukeren videre til alarmvinduet. Ved alarmtilstand kommer også en varsellampe til syne i venstre hjørne. Det er mulig å navigere mellom alle vinduene. Figur 3-25 Hovedvindu for to tank panelet Side 21 av 45

29 3.7.1 Tank-panelene I tank-panel vinduene er det meningen at brukeren skal få litt mer oversikt over hva som faktisk foregår i prosessen, her har vi også valgt og legge inn en sanntidstrend som viser de siste to minuttene, slik at det er mulig og se hva som har foregått. Ved å ha en slik trend kan operatøren gå inn å se hva som har skjedd før en alarm, noe som kan være veldig nyttig. De to tankene er relativt like, de har begge mulighet til å lese nivå og skrive referanse, pådrag og om regulatoren skal være i auto eller manuell. I vinduet til tank 1 er det også mulig og se tilstanden til magnetventilene, men ikke styre dem. Figur 3-26 Paneletvindu for tank 1 Figur 3-27 Panelvindu for tank 2 Side 22 av 45

30 3.7.2 Alarmvinduet Dette vinduet er nesten helt likt som i entank prosjektet, det eneste som er endret er knappestrukturen og at det kommer alarmer fra begge tanker inn i skjemaet. Kvitteringsknappen kvitterer som tidligere alarmen i operatørpanelet og PLS-ene. Figur 3-28 Panelvindu for alarmhåndtering 3.8 Innregulering I totankrosjektet reguleres begge tankene samtidig, med samme pumpe som ved regulering av en tank. Siden pumpa ikke gir noe mer vann gjennomrøret enn tidligere, vil trykket over ventilene til tank 1 og tank 2 minske, og vi må finne andre regulatorparametere for regulatorene Innregulering tank 1 (EB) For å finne regulatorinnstillinger for tank 1, brukte vi metoden for manuell sjøljustering til å finne kritisk forsterkning og periodetid. Dette er en enkel metode hvor vi setter regulatoren som P- regulator og Kp-forsterkningen til maksimal verdi. Vi får da stående svingninger i nivået, og pådraget hopper mellom min. og maks verdi. Formler for kritisk forsterkning og kritisk periodetid: K k = Topp til bunn for pådrag Topp til bunn for prosessverdi 1.27 T k = Periodetid for svingningene Side 23 av 45

31 Topp-til-bunn Pådrag Periodetid Topp-til-bunn prosessverdi Figur 3-29 Innsvingning manuell selvjustering Med utgangspunkt i de grafiske dataene i figur 3-29 kunne vi bruke Ziegler-Nichols medtode for utregning av Kp og Ti for PI-regulator. K k = = 14.1 K p = 0.45 K k = = 6.3 T k = 15 sek T i = 0.85 T k = sek = sek Regulatorinnstillinger for tank 2 (HMH) Når vi skulle finne regulatorparametere til tank 2, valgte vi å danne oss en FOPDT-modell, for så å utføre ITAE-kriteriet på denne modellen for å komme til passende regulatorinnstillinger. Siden at denne regulatoren ikke skal være innstilt for et sprang i forstyrrelsen, utførte vi et sprang fra 30% - 60% i referansen. Dette ga oss følgende forløp: Figur Sprangrespons på tank 2 når referansen går fra 30-60%. Side 24 av 45

32 Det er verdt å merke seg at vi lot ventilen på tank 1 ha en konstant åpning hvor nivået ville ligge rundt arbeidspunktet, altså 60% nivå. På denne måten har vi tatt hensyn til trykkfallet over tank 1 sin reguleringsventil, samt tap av innløp på tank 1. Vi dannet en FOPDT-modell ut fra den øvrige figuren. y(t2) = y s = = = 37.7 y(t1) = y s = = = Ut fra figuren på neste side vil dette gi oss: Vi får ta følgende tidskonstant og tidsforsinkelse: Ut fra spranget får vi også følgende forsterkning: y(t2) t2 = 9 y(t1) t1 = 4.4 T = 3 (t2 t1) = τ = t2 T = 2.1 K = y u = = 0.93 Figur Oppdagelse av t1, t2 og Δy ved hjelp av sprangrespons i tanken. Vi ender da opp med denne FOPDT-modellen: H(s) = s e 2.1s Vi utfører ITAE-kriteriet ved hjelp av FOPDT-modellen vår: K p = ( ) 0.93 = Ti = ( 2.1 = ) Side 25 av 45

33 3.9 Resultat Prosjekt i Styresystemer og reguleringsteknikk Resultat for innreguleringen (HMH) Vi tok regulatorinnstillingene vi fant for tank 1 og tank 2 og kjørte sprang på tankene. Vi utførte et sprang på utløpet i tank 1 da oppgaveteksten spesifiserer at vi skal regulere etter et sprang i utløpet. I tank 2 utførte vi et sprang i referansen da tankrigget er innstilt for dette, siden vi kun kan styre utløpet manuelt og ikke via PLS. Vi fikk følgende innsvingningsforløp for tankriggene: Figur Sprang i utløp fra 3/3-1/3 i tank 1. Figur Sprang i referansen fra 30-60% i tank 2. Ut fra innsvingingsforløpene kan vi se at de ligger innenfor spesifikasjonene, altså under seks halvperioder med svingning på begge tankene. Vi konkluderer med at dette er mer enn godt nok, og at det ikke er behov for etterjustering. Side 26 av 45

34 4 Bonus Gruppe 1 Frekvensomformer I løpet av prosjektet skulle vi vurdere om vi fikk tid til å gjennomføre en bonusoppgave. I starten av prosjektet bestemte vi oss for at hvis vi fikk tid til dette, skulle vi velge nivåregulering med frekvensstyrt pumpe. Grunnen til at vi tok dette valget var at oppgaven virket relevant i forhold til hvordan ting gjøres i industrien, og at den virket mer utfordrende enn de andre alternativene. I bonusoppgaven blir pådraget endret fra en motorstyrt ventil til en frekvensomformer som styrer turtallet til en pumpe. I entank-delen gikk styresignalet på 4-20 ma fra DA-omformeren på PLS til ventilen. Nå vil kommunikasjonen gå direkte via Profibus fra PLS til frekvensomformeren. 4.1 Kommunikasjon (TM) I bonusoppgaven blir pådraget vårt endret fra ventil til en frekvensomformer som styrer turtallet til en pumpe. I entank-biten gikk styresignalet på 4-20 ma fra DA-omformeren på PLS til ventilen. Nå vil kommunikasjonen gå direkte via Profibus fra PLS til frekvensomformeren. Figur 4-1 Skisse Bonusoppgave gruppe 1 Frekvensomformeren er en Danfoss VLT Den har i utgangspunktet innebygd regulator, men vi bruker den som et pådragsorgan som får signal fra regulatoren som er programmert i PLS. Figur 4-2 Kommunikasjon bonusoppgave gruppe 1 Ettersom vi skulle koble et nytt ledd til Profibusen, var vi nødt til å lage en ny konfigurasjon. Vi lastet ned en samling GSD-filer fra Danfoss sine hjemmesider. GSD er kort for Gerätestammdaten, eller general station description på engelsk. Fila forteller hva enheten er for noe og om dens innganger og utganger. Side 27 av 45

35 Når den riktige gsd-filen var på plass satte vi de parameterne vi ønsket for frekvensomformeren. FDLadressen fant vi ved å se inn på selve menyen til frekvensomformeren, der fant vi at var satt til 30. Vi valgte den minste kommunikasjonstypen, type 3 som gir to 16 bits ord opp og to 16 bits ord ned. I vårt tilfelle ble dette D300 og D301 inn til frekvensomformeren fra PLS og D320 og D321 til PLS fra frekvensomformeren Frekvensomformeren leser ordene fra MSB til LSB, og ikke fra LSB til MSB som vi gjør. Derfor huket vi at «Swap I/O Bytes in Master» for å slippe ekstraarbeid. Figur 4-3 Oppsett GX-Developer Vi sender pådraget fra regulatoren inn på D300, men for at det skal få virke på frekvensomformeren må D301 inneholde informasjonen som er nødvendig for at frekvensomformeren skal oppføre seg som vi vil. I tabellene under er det listet opp hva de forskjellige bitene i de 16 bits ordene opp og ned representerer. Control word er fra PLS, mens Status word er til PLS. Fra tabellen for Control word kom vi fram til at vi måtte ha ( )på D301 for å få lov til å styre frekvensomformeren. Figur 4-4 Bit oversikt VLT 2800 Side 28 av 45

36 4.2 PLS (MB) Regulatoren vi bruker på denne bonusoppgaven er den samme som i entank prosjektet. Det vil si at regulatoren er i slave-plsen, mens frekvensomformeren blir styrt fra master-plsen. Pådraget blir dermed regnet ut i slaven, sendt opp til master og videre ut til omformeren. Siden frekvensomformeren opererer med verdier som er skalert forskjellig i forhold til i PLSen, må vi gjøre en skalering i masteren før vi sender pådraget ut på Profibus-nettverket og til omformeren. I PLSene oppgis pådraget i en skala fra 0 til 250, mens omformeren vil ha verdien fra til For å gjennomføre denne skaleringen må vi først sende pådraget til ett 32-bits dataregister for å unngå overflyt av data, da tallet blir over 16-bit under utregningen. Figur 4-5 Konvertering fra INT til DINT Pådraget i ett 32-bits register blir så skalert i forhold til omformeren. Vi bruker blokkene MUL_E og DIV_E for henholdsvis multiplikasjon og divisjon under utregningen fordi disse takler å regne med 32- bit ord. Etter skaleringen blir verdien satt tilbake til en 16-bits verdi for at det skal passe i ett enkelt dataregister. Så adderes denne verdien med for at verdien skal passe i spekteret til omformeren før den sendes ut på Profibus-nettverket. Figur 4-6 Skalering pådrag til VLT 2800 Da vi testet ut disse instillingene i praksis fant vi ut at det ikke funket helt optimalt. Siden pumpa skal pumpe vann fra bunnen av riggen og helt til toppen, blir den rett og slett for svak ved de laveste frekvensene til å den klarer å pumpe vannet inn i tanken. Vi måtte dermed finne nye grenseverdier når vannet faktisk begynner å renne inn i tanken. Vi fant ut at vannet begynte å renne inn ved 19.5 Hz, eller ved verdien 117 på pådraget fra regulatoren. Vi måtte dermed foreta enda en skalering som tar høyde for dette. Pådraget fra regulatoren skaleres slik at når den gir verdien 0, blir verdien som sendes videre 117. Dermed står omformeren på 19.5 Hz når pådraget er 0%. Figur 4-7 Skalering pådrag 0% Side 29 av 45

37 Kontroll ordet som legges i D300 blir satt av minnecellene L60 til L75. Ved å sette de forskjellige bitene høy eller lav kan vi bestemme innstillingene til frekvensomformeren. Figur 4-8 Skrive ti VLT 2800 I denne oppgaven ønsker vi kun å styre om pumpa skal være av eller på. Vi setter dermed alle bitene vi trenger høy, utenom det som styrer start og stopp av pumpa. Denne biten styrer vi fra brukergrensesnittene. Figur 4-9 Setting av bit til VLT 2800 Pumpa settes høy og lav av to forskjellige bit via puls. Vi programmerer på denne måten for at begge brukergrensesnittene skal kunne styre statusen til pumpa uten at de snakker direkte med hverandre. Dette gjøres for å unngå komplikasjoner med at én bit styres fra flere forskjellige plasser. På samme måte som med kontroll ordet blir de forskjellige statusene for omformeren satt av D320 som inneholder status ordet. Her kan vi se om de forskjellige bitene er satt høy eller lav av omformeren og på denne Figur 4-10 Start/Stopp pumpe via flagg måten hente ut informasjon om omformeren. Vi valgte å hente ut bitene som viser om pumpa kjører, og som viser om det er noen feil med pumpa. Figur 4-11 Lese fra VLT 2800 Så setter vi reguleringsventilen til full åpning slik at reguleringen kun styres av pumpa og frekvensomformeren. Figur 4-12 Sette reg. ventil åpen Side 30 av 45

38 4.3 Brukergrensesnitt - HMI (MB) I Intouch ble en ny alarmindikator laget for feil på frekvensomformeren. Denne indikatoren ble plassert ved de andre alarmlampene i hovedvinduet i brukergrensesnittet. I tillegg vises feil på omformeren som alarm i alarmvinduet. Hvordan dette gjøres er godt dokumentert i Entankrapporten til gruppe 1, i kapittel (Alarmhåndtering i Intouch) Figur 4-13 Alarmlampe Frekvensomformer Reguleringsventilen ble fjernet helt fra prosessbildet da den i realiteten ikke lenger er med i prosessen. Indikatorene for regulator, foroverkobling, samt displayet for pådraget ble flyttet. Vi valgte å plassere dette ved pumpa istedenfor da dette viser at det er pumpa som faktisk regulerer prosessen. Endringer fra Entank Figur 4-14 Ikon pumpe i InTouch Vi har rettet opp de tingene som ble påpekt under Entank demonstrasjonen. Dette er følgende punkter: Alarmknapp blinker kun når lampe blinker, ved aktiv alarm Endret slik at riktig alarm kommer opp, høy ved høy og lav ved lav. Maskert bort felter som ikke er i bruk; nominelt pådrag etc. Fjernet streker fra statisk nivå- og referanseindikator ved siden av tanken. Feltet for å endre nominelt pådrag viser pådraget i auto også. Vi har ikke gjort noen design endringer for ix panelet. Her har vi kun gått over tag-liste og lagt til ekstra alarmer fra frekvensomformeren. Vennligst se «entank» rapporten Side 31 av 45

39 4.4 Innregulering (ØE) Serieregulering For å fylle innløpsrøret delvis med væsken lar vi frekvensomformeren gå ved ca. 20 Hz når vi har 0 i pådrag, som beskrevet i 4.2. Dette gjør at systemet ikke får en så stor tidsforsinkelse på transporten av væsken opp selve røret. Dette gjør at dynamikken til selve systemet blir ganske likt som ved reguleringen ved hjelp av ventilen, slik vi gjorde det i «entank» delen av prosjektet. Figur 4-15 Front VLT 2800 Vi prøvde derfor de parameterne vi fikk fra «Entank» delen, disse var de samme parameterne vi fikk fra simuleringsnotatet. Disse fungerte meget godt også til regulering med frekvensomformeren. For vanlig serieregulering benyttet vi disse parameterne uten å måtte gjøre noen etterjusteringer. Vi benyttet PI-regulator for å klare kravet om null stasjonært avvik. Figur 4-16 Regulator innstillinger Dette ga oss en kjapt innsvingningsforløp med lite dynamisk avvik, ved sprang i utløpet fra 33% til 100%, og ved sprang fra 100% utløp til 33%. Se figur 4-17 under. Innsvingningsforløpet ble av typen «minimum forstyrrelse», med kun 1-2 svingninger. Figur 4-17 Innsvingningsforløp 33% til 100% og 100% til 33% Dette gir oss en god regulering, med rask innsvingning, null stasjonært avvik og innsvingningsforløp bedre enn «minimum areal». Side 32 av 45

40 Foroverkobling Prosjekt i Styresystemer og reguleringsteknikk Når vi bruker foroverkobling som reguleringsmetode, fortsatte vi med samme innstillinger for PI hovedregulatoren. Vi prøvde først ut PD foroverkoblingsregulator, som ble beste resultat fra «Entank» delen. I «Entank» fikk vi veldig lite virkning fra D-delen på grunn av en feil i algoritmen, se kapittel i «Entank rapport» fra gruppe 1, figur 51. Her har vi delt på 100, mens det kun skal være 10. Etter å ha rettet opp programmeringen, måtte vi benytte andre parametere enn fra «Entank». Vi prøvde oss litt frem, og fikk samme Kp, mens vi måtte øke Td noe. Ved å benytte foroverkobling fikk vi mye mer oversving, enn ved vanlig serieregulering. Innsvingningsforløpet var fortsatt kjapt, og av typen «minimum forstyrrelse» fortsatt når vi hadde sprang fra 33% utløp til 100%. Se figur Figur 4-18 Innsvingningsforløp foroverkobling Vi prøvde også med et sprang i den manuelle utløpsventilen, når utløpet var åpent 100% i systemet. Når vi benyttet fast frekvens på pumpen og regulerte med ventilen i «Entank», klarte ikke systemet å regulere seg inn ved et så stort utløp. Ved å regulere frekvensen istedenfor får vi levert tilstrekkelig med vann i innløpet til å fjerne det dynamiske avviket meget kjapt. Her fikk vi heller ikke noe oversving, som vi hadde med mindre sprang i utløpet. Se figur Figur 4-19 Innsvingningsforløp foroverkobling manuelt utløp Side 33 av 45

41 4.5 Resultat Ved å la pumpen kjøre med en konstant frekvens fikk vi en dynamikk som lot seg regulere forholdsvis enkelt. Vi prøvde først uten denne «offseten», og da ble det veldig lang transport tid i hele systemet. Dette gjorde at det ble fortere og større over- og undersving ved sprang i utløpet. Vi fikk gode resultater ved å kun benytte serieregulering. Ved utløp kun med magnetventilene fra 0 til 100% er det ikke behov for å bruke foroverkobling. Foroverkobling fungerte best når vi hadde det ekstra utløpet fra den manuelle ventilen. De parameterne vi brukte var de vi fant under simuleringen for serieregulatoren. De regulatorparameterne som fungerte best var: Serieregulering: Kp = 5.5 Ti = 4.2 sek Foroverkobling: KpFF= 0.7 TdFF = 2.0 sek Figur 4-20 Innsvingningsforløp beste resultat Side 34 av 45

42 5 Bonus Gruppe 2 Frekvensomformer Frekvensomformerstyring er en bonusoppgave som vi har valgt å gjennomføre etter å ha vist at vi tidsmessig kommer i mål med det som er hovedoppgavene i prosjektet. Ved hjelp av frekvensomformerstyring av pumpemotoren skal vi kunne nivåregulere tanken via PROFIBUSnettverket, i stedet for at vi nivåregulerer ved å sende pådrag til ventilåpningen. Dette innebar at vi måtte endre PROFIBUS-konfigurasjonen og deler av PLS-programmet. Det ble også gjort endringer i brukergrensesnitt og operatørpanel. Vi har tatt utgangspunkt i programmene og konfigurasjonene som ble utviklet i entankprosjektet og bygget videre på disse. 5.1 Konfigurasjon (AAP) Henviser til kapittel Profibus-DP i miniprosjektet da bonusoppgaven bygger videre på dette. Frekvensomformeren styres ved hjelp av Profibus og dette må konfigureres i programmet i GXconfigurator. Vi har tatt utgangspunkt i konfigurasjonen vi kom fram til i miniprosjektet og videreført denne. Frekvensomformerenheten måtte hentes fra hjemmesiden til danfoss og importeres til GX-configurator deretter fikk vi inkludert omformeren inn i profibusnettet som figur 5-1 viser. Figur 5-1 Profibus konfigurasjon I oppsettet må man velge hvilken PPO (Parameter-process Data object) man skal bruke. PPO sier noe om hvor mange byte som skal tilegnes i kommunikasjonen over Profibus. Vi valgte «type 3» som figur 5-2 viser. Figur 5-2 Bit oversikt frekvensomformer Side 35 av 45

43 «Type 3 PPO» består av fire byte som igjen er to ord. På de fire bytene ser vi at det blir lagt et «control word (CTW)» i det første ordet, «status word(stw)» i det andre. «main reference value(mrv)» i det tredje og «main actual value(mav)» i det siste. Disse bruker vi til å styre og kontrollere frekvensomformeren. I kontrollordet (CTW) bestemmer vi hvilke tilstander vi ønsker å tildele frekvensomformeren, om den skal starte, stoppe, starte med rampe funksjon osv. I statusordet (STW) leser vi av hvilken tilstand omformeren er i. I main reference value (MRV) settes ønsket hastighet (Skal-verdi) I main actual value (STW) leser vi av faktisk hastighet til pumpa (ER-verdi). Figur 5-3 Profibuskonfigurasjons-POU som legges i Master-PLS Når konfigurasjonen i GX-configurator er gjort må det lages en POU som inneholder konfigurasjonen, se figur 5-3. Denne må legges inn i master PLS, se kapittel Miniprosjektrapport for hvordan dette gjøres. 5.2 Programendringer i PLS (HILB) Det ble gjort noen programendringer i PLS-programmet til både master og slave ved frekvensomformerstyring av pumpemotoren Endringer i slave 1 I entank styrte man pumpa ved å slå den av og på i slaven. Denne delen av programmet ble fjernet siden pumpa nå bare skal kunne styres via frekvensomformeren. Siden vi ved frekvensomformerstyring ikke lenger skal styre ventilåpningen, skal det sendes et konstant pådrag til ventilåpningen. I bonusoppgaven ble det spesifisert at ventilåpningen skal være 100 % åpen ved frekvensomformerstyring. Dette endrer vi i slaven ved at vi sender verdien 255, dette tilsvarer fullt pådrag, som et fast pådrag til ventilåpningen. Side 36 av 45

44 Figur blir sendt som et konstant pådrag. Ved testing av nivåreguleringa fant vi ut at reguleringa kunne gjøres bedre ved å sette et bunnpådrag. Ved utprøving kom vi fram til at vi fikk best regulering ved å sette et bunnpådrag på 117. Dette gjør at det konstant holdes vann i rørene slik at innstrømninga i tanken begynner momentant ved igangsetting av pumpa. Hadde det ikke vært for dette bunnpådraget, hadde innstrømninga til tanken fått ei tidsforsinkelse siden rørene først hadde måttet fyltes opp med vann. Vi bestemmer bunnpådraget ved å endre på nedre grense i funksjonsblokka Greneskontroll Figur 5-5 Nye verdier i grensekontroll Endringer i master For å finne pådragsområdet til frekvensomformeren prøvde vi oss fram med ulike verdier som vi sendte via masteren til frekvensomformeren. Da kom vi fram til et pådragsområde der gir null pådrag og 4000 gir fullt pådrag. Når masteren henter pådragsverdier i bitverdier må disse regnes om til å ligge i pådragsområdet til frekvensomformeren, , dette gjøres da i funksjonsblokka Omregning_paadrag_omformer. Figur 5-6 Omregning av pådrag fra regulator til frekvensomformer. Ut ifra kontrollordet som benyttes til å styre omformeren, se figur 5-7, kom vi fram til at for å starte pumpa måtte vi sette disse bitverdiene høye: Ved å regne om bitverdiene til en tallverdi får vi at dette blir Side 37 av 45

45 Figur 5-7 Oversikt av kontrollord fra manual VLT 2800, DP V1 PROFIBUS som viser hvilke funksjoner de ulike bitverdiene har. Denne tallverdien brukes videre til å styre tilstanden til pumpa. Ved å sende 1151 slås pumpa på, og ved å trekke fra 16, som tilsvarer bitverdi fire i kontrollordet, slås pumpa av ved rampestopp. Dette gjør at pumpa slipper unna bråstopp, noe som kan slite ut pumpa. I tillegg vil pumpa slås av når alarmen HH går av. Figur 5-8 Start og stopp av pumpe via frekvensomformer. Ved bruk av frekvensomformer til å sette pådraget kreves det at vi gjør noen endringer i HMI. Hastigheten til frekvensomformeren skal nå leses av i HMI. Vi sender pådragsverdien til omformeren til HMI ved hjelp av ei MOV-blokk som i figuren under. Figur 5-9 Vi leser av er-verdi til omformer og sender det til HMI. Side 38 av 45

46 5.3 Brukergrensesnitt (HBG) Siden bonusoppgaven bygger videre på det vi gjorde i entankdelen av prosjektet har vi ikke lagd nye brukergrensesnitt, men modifiserte de vi hadde figur Intouch Operatør PC Brukergrensesnittet gjennomgikk noen små endringer. Pådragsvisningen er fjernet fra ventilen siden denne skal ha 100 % åpning under kjøring. Pådraget vises nå nede ved pumpen i arbeidsområdet 0 50 Hz. I tillegg ble problemet med inntasting av desimaler for Ti løst. Se figur Figur 5-11 Inntasting av desimaler for Ti ble fikset. Figur 5-10 Riggbildet med endringer for frekvensomformerstyring. Side 39 av 45

47 5.4 Operatørpanelet (HBG) Det ble noen adresseendringer i PLS-programmet, og disse endringene ble oppdatert i taglisten for å få brukergrensesnittet til å fungere igjen. Pumpen er nå gjort større og «klikkbar», se figur Dette vil si at ved å trykke på pumpesymbolet vil du få opp en pop-up skjerm. På denne skjermen vil du kunne starte og stoppe pumpen, samt lese av frekvens. Se figur Figur 5-12 Pop-up skjermen for pumpen. Figur 5-13 Pumpen er «klikkbar» og gjort større. 5.5 Resultat Nivåreguleringen med frekvensstyrt pumpe som pådragsorgan fungerte veldig bra. Frekvensomformeren reagerer raskere enn reguleringsventilen, tåler store endringer i settpunkt og forstyrrelse og er mer gunstig med tanke på strømforbruket. Ved testing fant vi ut at regulatorparameterene som gir best regulering er: Kp = 2 Ti = 20 Ved store settpunktsendringer får vi en innsvingningstype tilsvarende en mellomting mellom minimum forstyrrelse og minimum areal. Ved små endringer i forstyrrelse får vi nesten ikke noen endringer i nivået. Figur 5-14 Innsvingningsforløp Side 40 av 45