1. No category

Høgskolen i Sør-Trøndelag
Totankprosjektrapport
Prosjektoppgave i Styresystemer 2AEL13H våren 2015
Gruppe 5 & 6
Emil Hatletveit
Kristian Strøm
Terje Magnus Sørensen
Stian Berg Dyrnes
Snorre Vongraven
Andreas Haugen
Roy Kenneth Solvang
Jørgen Nordvik Aasen
Andreas Stahl Rød
Knut Marius Røsberg
Fredrik Løkken
Michael-Alexander Mcgrory
07.05.2015
ii
Forord – AH
Alle studenter ved automasjonslinjen ved HiST gjennomfører i fjerde semester et større
prosjekt i faget Styresystemer og Reguleringsteknikk. Prosjektet har som hensikt å gi
studentene trening i samarbeid, rapportskriving og praktisk problemløsning, samt øke den
faglige kompetansen hos alle involverte.
I totanksprosjektet har gruppe 5 og 6 blitt slått sammen for å løse problemet å regulere
nivået i begge tankene på tankriggen. I denne rapporten er det gitt en detaljert beskrivelse
av hvordan totanksprosjektet er blitt utført. Slik at det er mulig for en ingeniør eller student
som kommer fra en lignende eller tilsvarende utdanningsbakgrunn skal kunne forstå
hvordan kommunikasjonen og nivåreguleringen fungerer i vårt system.
Rapporten består av arbeid utført i InTouch, iX-Developer, Master-PLS og Slave-PLS’ene. Det
er i tillegg beskrevet hvilke bonusoppgaver gruppene har valgt og hvordan de har blitt løst.
iii
Sammendrag – TMS
Denne rapporten har som formål å dokumentere totankprosjektet, som er en del av
prosjektoppgaven i faget styresystemer og reguleringsteknikk.
Vi skal i løpet av dette prosjektet regulere to forskjellige varianter av væsketanker, først med
en tank, og deretter med to tanker. Disse tankene skal reguleres ved hjelp av to PLS-er.
Begge disse PLS-ene er styrt av en tredje PLS, som også er programmert i Gx Works2. Det
skal i tillegg lages et brukergrensesnitt både på PC og på brukerpanel.
Hensikten med totankprosjektet var å nivåregulere to væsketanker ved hjelp av PLS-er.
Hvordan dette er gjort er delt opp i flere elementer:
-
Bestemme hvem som har ansvar for den enkelte delen av prosjektet.
-
Velge ut det beste fra hver gruppe på PLS-program og HMI-grensesnitt.
-
Programmering av PLS-er.
-
Utarbeiding av IX-panel og InTouch.
-
Det ble avsluttet med at begge gruppene gjorde en bonusoppgave hver.
o Gruppe 5; IP-Kamera
o Gruppe 6; Autotuning
Vi har i tillegg oppdatert nettsidene som rapportene blir lagt ut på. Det er med en
prosjektstyringsdel for begge gruppene, som sier hvordan prosjektet ble gjennomført. I
prosjektsyringsdelen er det også med en oppdatert kurve for arbeid i forhold til planlagt.
Totankprosjektet ble avsluttet med demonstrasjon. Nivåreguleringen i systemet ble funnet
tilfredsstillende og brukergrensesnittet brukervennlig, gruppene kan gjøre seg klar for
innlevering av tidsskrift og prosjektpresentasjon.
iv
Innhold
Forord – AH ______________________________________________________________________ iii
Sammendrag – TMS _______________________________________________________________ iv
1 Innledning ______________________________________________________________________ 1
1.1 Oppgavetekst – TMS __________________________________________________________ 1
1.2 Definisjoner – TMS ___________________________________________________________ 2
1.3 Prosjektmål – AH _____________________________________________________________ 4
1.3.1 Prosessmål ______________________________________________________________ 4
1.3.2 Resultatmål______________________________________________________________ 4
2 Teknisk del _____________________________________________________________________ 5
2.1 PLS-programmer og regulatorinnstillinger tank 1- EWH/KR/RS _________________________ 5
2.1.1 PLS-programmer__________________________________________________________ 5
2.1.2 Sprangrespons tank1, LV1 og LT1 ____________________________________________ 14
2.1.3 Førsteordensapproksimasjon FOPDT (First order plus dead time) __________________ 15
2.1.3 Regulatorinnstillinger for tank 2_____________________________________________ 17
2.1.4 Hysterese ______________________________________________________________ 19
2.2 IX-panel – AR, TMS, JA ________________________________________________________ 22
2.2.1 Kravspesifikasjoner _______________________________________________________ 22
2.2.2 Tags___________________________________________________________________ 23
2.2.3 Utforming og design ______________________________________________________ 24
2.3 InTouch ___________________________________________________________________ 27
_____________________________________________________________________________ 33
2.3.1 Sending av verdier _______________________________________________________ 34
2.3.2 IP Kamera ______________________________________________________________ 35
2.3.3 Alarmer ________________________________________________________________ 37
2.3.4 Definering av alarmer _____________________________________________________ 37
2.3.5 Sikkerhet _______________________________________________________________ 38
2.3.6 Access Level ____________________________________________________________ 39
2.4 Bonusprosjekt gruppe 5 – IP-Kamera – AR ________________________________________ 41
2.4.1 Oppsett: _______________________________________________________________ 41
2.5 Bonusprosjekt gruppe 6 – Autotuning ___________________________________________ 44
2.5.1 PLS-kode – SBD __________________________________________________________ 44
2.5.2 Betjening av autotuning i intouch – KS _______________________________________ 51
v
3 Prosjektstyring gruppe 5 _________________________________________________________ 52
3.1 Deltagere __________________________________________________________________ 52
3.2 Tidsbruk – KR _______________________________________________________________ 53
3.3 Prosjektstyring og samarbeid – AR & KR __________________________________________ 54
4 Prosjektstyring gruppe 6 _________________________________________________________ 55
4.1 Deltagere __________________________________________________________________ 55
4.2 Tidsbruk –TMS ______________________________________________________________ 56
4.3 Prosjektstyring og kvalitetssikring – SV ___________________________________________ 56
4.3.1 Statusrapportering _______________________________________________________ 56
4.3.2 Standardiserte skjemaer __________________________________________________ 57
4.3.3 Versjonskontroll _________________________________________________________ 57
4.3.4 Tester og sjekklister ______________________________________________________ 57
4.4 Prosjektstyring og samarbeid – SV & KS __________________________________________ 58
5 Prosjektstyring totank – AR & KR ___________________________________________________ 59
6 Konklusjon – SV ________________________________________________________________ 60
7 Litteratur – TMS ________________________________________________________________ 61
8 Vedlegg _______________________________________________________________________ 62
vi
1 Innledning
1.1 Oppgavetekst – TMS
I denne delen av prosjektet skal vi bruke nivåregulering for å få ønsket væskenivå i to tanker.
Dette skal gjøres via regulatorer som er bygd opp i to PLS-er. Du skal ha mulighet til å
regulere nivået i tanken med P- eller PI-regulator. I tillegg til dette skal det være mulig å
bruke foroverkopling fra forstyrrelsen i tank 2. Foroverkoplingen skal kunne brukes som P-,
D- eller PD-regulator. Du skal bruke pådrag fra regulatoren til å styre ventilene på innløpet.
Om det er tid skal gruppene gjennomføre et bonusprosjekt, der står gruppene fritt til å velge
mellom noen utvalgte oppgaver. For gruppe 5 ble bonusprosjektet oppsett av riggovervåking
via et IP-Kamera, mens gruppe 6 valgte autotuning som bonusoppgave.
Figur 1 – Oversiktsbilde kobling mellom PLS-rig og tank-rig
1
1.2 Definisjoner – TMS
AD/DA-omformer: Analog-Digital Digital-Analog, Elektrisk krets som gjør om fra analog
signal til binære verdier, og motsatt.
HMI: Human Machine Interface. Grensesnittet som brukeren presenteres for når han/hun
skal bruke en datamaskin for å utføre en oppgave. Brukergrensesnittet er bare en del av et
dataprogram (InTouch).
It's Learning: Nettportal tatt i bruk av HiST hvor man kan legge ut filer og faginformasjon.
Matlab/Simulink: Program for programmering, brukt for modellering og simulering.
GX Works2: Program for programmering av PLS.
HiST: Høyskolen i Sør-Trøndelag.
InTouch: Program for å konstruere brukergrensesnittet for operatør på PC.
iX Panel TA100: Operatørpanel festet på PLS-rigg, med berøring og farge skjerm.
PLS: Programmerbar Logisk Styring. En datamaskin med inn- og utganger som du kan koble
deg på. Vi benytter to typer under prosjektet to FX1N og en Q00.
Samplingstid: Tiden mellom hver gang AD-omformeren gir et signal binært signal, fra et
analogt signal.
Bit: Enhet for digital informasjon. Kan ha verdien 0 eller 1 (av/på), kan lagre en boolsk verdi.
Kan behandles i grupper på 4 (kvartett – K1), 8 (byte – 1B), 16 (word/dataord) og 32 (double
word).
Boolsk variable: Variabel som kan ha to verdier 0 eller 1 (av/på).
Bufferminne: Lagringssted for digital informasjon. I PLS-modulene er bufferminnet
nummerert (D0), alle bufferminner inneholder 16 bit.
I/O – Input/Output: Innganger og utganger på datamaskiner.
LD/ FBD – Ladderdiagram/Funksjonsblokkdiagram: Grafiske programmeringsspråk for PLS.
IL – Instruksjonsliste: Tekst basert programmeringsspråk for PLS.
Minne: Ligningssted for digital informasjon. For eksempel 1-bits minneceller (M0) og 16-bits
dataregister (D0).
POU: Program Organisation Unit, delprogram i GX Works2. Bygd opp av for eksempel
Ladderdiagram.
Tag: Digital merkelapp. Brukes for å linke dataregister, minneceller eller andre verdier for å
gi bedre oversikt i programmeringen.
2
Anti-aliasingfilter: Elektronisk filter bygd opp av operasjonsforsterker, motstand og
kondensator. Filteret er et lavpassfilter som vil ta bort høyfrekvent støy for å hindre
nedfolding (uønskede lave frekvenser på målingene som skyldes sampling).
Foroverkobling: En reguleringsmetode som legges til pådraget for raskere kompensering av
forstyrrelser hvor du måler forstyrrelser (kan også kombineres med matematisk modell).
Foroverkobling kombineres som regel med tilbakekoblingsregulator (PID). Eventuelle feil i
foroverkoblingen vil da kompenseres av tilbakekoblingen.
PI-regulator: Proporsjonal- og Integral-regulator. Elektronisk styreenhet som du
programmerer med en matematisk algoritme med forskjellige operasjoner. For å regulere
prosessen via pådraget.
PD-regulator: Proporsjonal- og Derivat-regulator. Elektronisk styreenhet som du
programmerer med en matematisk algoritme med forskjellige operasjoner. For å regulere
prosessen via pådraget.
3
1.3 Prosjektmål – AH
1.3.1 Prosessmål
Gruppemedlemmene skal:

Få økt kunnskap og erfaring innenfor prosjektplanlegging og prosjektstyring.

Få bedre erfaring med gruppearbeid, og sammen sørge for at prosjektgruppens
resultatmål blir oppnådd.

Kunne skrive gode rapporter og presentere innholdet.

Kunne anvende teorien fra de forskjellige delene av faget Styresystemer på et
praktisk problem.
1.3.2 Resultatmål
Prosjektgruppene skal:

Utarbeide og programmere regulator system i PLS

Regulatoren skal programmeres slik at den skal kunne brukes som P- og PI-regulator
med rykkfri over gang ved bytte av regulatortype.

Utarbeide og programmere et brukergrensesnitt ved hjelp av InTouch(PC) og et
operatørpanel av typen iX Panel TA100. Her skal prosessen kunne overvåkes og
styres etter gitte operatørspesifikasjoner

Lage et intuitivt brukergrensesnitt med mulighet for forskjellig operatør innlogging.

Kunne bruke autotuning på tank 1 til forslag for regulatorinnstillinger.

Bruke webkamera til å overvåke tankriggen.

Levere fullstendig dokumentasjon av alt utført arbeidet.

Levere alle rapporter innen leverings frist.

Sørge for at alle deltakerne er kjent med de forskjellige delene av prosjektet.

Kunne redegjøre for framgang av prosjektet til veileder ved prosjektmøter.
4
2 Teknisk del
2.1 PLS-programmer og regulatorinnstillinger tank 1- EWH/KR/RS
2.1.1 PLS-programmer
Når vi skulle slå sammen regulatorprogrammene fra gruppe 5 og gruppe 6, ble vi enige om å
begynne med å lage to felles lister for de to slavene. Dette gjorde vi for å få en god og
oversiktlig plan over hvilke minneceller og dataord som ble brukt, og for å se hvilken
informasjon vi måtte kommunisere mellom slavene og masterPLSen. I figurene under vises
listene for slave 1 og slave 2 respektivt.
Figur 2 – Liste over minneceller og dataord til slave 1
5
Figur 3 – Liste over minneceller og dataord til slave 2
Som figurene over viser, har vi en komplett oversikt over minnecellene og dataordene som
blir brukt til å sende bit-verdier og tallverdier opp og ned fra slavene. Her måtte vi også ta
hensyn til at de som jobbet med InTouch-programmet fikk den samme oversikten, slik at de
kunne sette opp taglisten riktig i OPC-serveren.
Vi ble enige om at gruppe 5, med sin regulator fra entanktprosjektet, skulle regulere tank
1via slave 1, og at gruppe 6, med sin regulator, skulle regulere tank 2 via slave 2. Vi valgte
videre å bruke masterprogrammet fra gruppe 5 som mal, og utvidet dette til å gjelde to
regulatorprogrammer i hver sin slave. Dette forenklet prosessen, da vi i utgangspunktet ikke
behøvde å endre på mye annet enn adressene og dataordene. Under ser vi at
masterprogrammet er så å si uendret fra entankprosjektet, bortsett fra endringene som er
gjort i adresseringene. I figurene som følger vises de resterende delene av
masterprogrammet. Som vi ser er disse godt dokumentert gjennom kommentarfelter. Dette
gjør programmet oversiktlig og lett å sette seg inn i både for gruppemedlemmene fra begge
gruppene, så vel som for veiledere.
6
Figur 4 – POU for slave 1 i masterprogrammet
Figur 5 – POU for slave 2 i masterprogrammet del 1
7
Figur 6 – POU for slave 2 i masterprogrammet del 2
Sett bort ifra disse endringene i master-programmet, er det ikke gjort noen endringer i
regulatorprogrammene. Disse fungerer på akkurat samme måte som i entankprosjektet,
bortsett fra at de nå styrer hver sin innløpsventil til de to tankene.
Den eneste vesentlige endringen som er gjort i slaveprogrammene er alarmprogrammet.
Dette måtte endres slik at alarmtilstander fra begge tankene ble varslet med lyssignal fra
lampen på riggen. Dette løste vi ved å endre alarmprogrammene etter mal fra gruppe 6 sitt
program, slik at de ble lik for begge tankene. Deretter la vi de modifiserte
alarmprogrammene i slave 1, der lampen styres fra.
I bildene som følger ser vi alarmprogrammet for tank 2, og hvilke funksjoner dette har. Dette
er løst på nøyaktig samme måte for tank 1 og tank 2, så det er kun tatt med bilder av det ene
programmet.
8
Figur 7 – Alarmprogram for tank 2 del 1
9
Figur 8 – Alarmprogram for tank 2 del 2
10
Figur 9 – Alarmprogram for tank 2 del 3
Vi lagde også en felles POU for alarmaksjoner, som skulle sikre at begge programmene skulle
fungere sammen og parallelt med hverandre. Her har vi blant annet lagt inn timere som
styrer blinkefrekvensen til alarmlampen ved de forskjellige alarmtilstandene i begge
tankene. Vi har også lagt inn funksjonen med fast lys på alarmlampen ved en stående
kvittert alarm. Dette programmet vises i figurene nedenfor.
11
Figur 10 – POU for alarmaksjoner del 1
Figur 11 – POU for alarmaksjoner del 2
12
Figur 12 – POU for alarmaksjoner del 3
Figur 13 – POU for alarmaksjoner del 4
Dette er en oppsummering av endringene som er gjort i PLS-programmene, og det viser at
det er nesten ingen endringer på selve slaveprogrammene. God kommunikasjon mellom
gruppene har bidratt til en smidig omstilling fra regulering av en tank, til regulering av begge
tankene samtidig.
13
2.1.2 Sprangrespons tank1, LV1 og LT1
Tank1 skal i totankprosjektet reguleres, utgangspunkt for reguleringsparametre blir utregnet
på grunnlag av FOPDT og ITAE kriteriet.
Figur 14 – Sprangrespons fra trendvindu i InTouch
14
2.1.3 Førsteordensapproksimasjon FOPDT (First order plus dead time)
Figur 15 – Prinsippskisse FOPDT
Figur 16 – Målepunkt for FOPDT
TC =
, der y er nivåendring og x er sprangendring
15
Figur 17 – ITAE tabell
Parametre for PI-regulator beregnet for forstyrrelser i utløp:
P=
0.9828
I=
25.8456
Parametre for PI-regulator beregnet for forstyrrelser i referansen:
P=
0.757
I=
15.398
16
2.1.3 Regulatorinnstillinger for tank 2
Her besluttet vi å gjøre nye utregninger for regulatorinnstillingene til tank 2. I
entankprosjektet brukte vi frekvensanalyse til å finne regulatorinnstillingene, mens vi denne
gang besluttet å bruke FOPDT, med ITAE-kriteriet. Her er det også interessant å se om det
blir noen store differanser i resultatet i forhold til frekvensanalysen, og om resultatet blir
bedre eller verre.
Først tar vi utgangspunkt i denne sprangresponsen ved sprang i referansen:
Figur 18 – Sprangrespons på tank 2
17
Her gjør vi den samme operasjonen som i forrige avsnitt, og vi bruker FOPDT-tilnærming.
Figur 19 – Målepunkt for FOPDT
TC =
Parametere for PI-regulator beregnet ved sprang i referanse:
Kp=
Ti =
7.7
4.4
Ved testing av disse parameterne, viser det seg at de fungerer bra. Både Kp og Ti er svært lik
den vi regnet ut i simnotatet i entankprosjektet. Følgelig blir innsvigningsforløpet veldig bra
med disse instillingene.
18
2.1.4 Hysterese
Innløpsventilen LV1 på tank 1 har vist seg å være litt vanskelig å regulere på grunn av
hysterese. Derfor mener vi det er viktig å skrive ett lite notat om akkurat denne
problematikken.
«Hysterese, det fenomen at en tilstandsendring som følge av en ytre påvirkning ikke
forsvinner når påvirkningen fjernes, men først etter at en motsatt rettet påvirkning har
virket med en viss styrke.» (Jakob Sandstad, https://snl.no/hysterese 06.05.2015)
For ventilen betyr det at vi ikke får reaksjon umiddelbart dersom ventilpådraget endrer
retning. Hysteresen i ventilen skyldes muligens variasjon i friksjonskrefter (statisk friksjon og
glidefriksjon).
Når ventilen står i ro vil vi få statisk friksjon som er større enn glidefriksjonen. For å få
bevegelse i ventilen trengs det litt ekstra krefter (pådrag) for å overvinne den statiske
friksjonskraften. Når vi tilfører tilstrekkelig kraft vil vi få bevegelse. Ettersom glidefriksjonen
gir mindre motstand vil vi oppleve oversving.
19
Dette resulterer i to problemer:
1. Endringen i ventilåpning tar tid.
2. Vi får for mye pådrag, dersom retningen på ventilåpningen endres.
Dette resulterer i en treg regulering av prosessen.
Friksjonskreftene tror vi delvis skyldes avleiringer og slitasje i ventilen, mistanken er på
grunnlag av forurenset vann og mistanke om lite vedlikehold.
Figur 20 – Prinsippskisse av ventil
“Hysteresis is normally caused by the force that appears every time the valve stem is going
to be reversed, ie moved in a direction opposite to the previous direction of movement.
Valve experts have described static frictional force as the amount of force needed to bend
the end-fibres of the packing material in contact with the valve stem in the new direction of
motion. Once the static frictional force has been overcome by energy provided by the
motive power of the actuator and the stem actually starts moving, the static friction force
disappears and is replaced by a sliding frictional force which is very much less than the
original static friction
Subsequent equal movements of the valve stem in the same direction will then generally be
greater as the static friction has now disappeared, and all the energy produced in the
actuator now goes directly into moving the valve stem. It only reappears again on the next
valve reversal. Any deadband (mechanical play or backlash) in the mechanisms of the valve,
actuator and positioner combination, adds to the hysteresis effect when reversing the valve.
Hysteresis and deadband increase control variance. In the case of self regulating processes
they increase the time that the controller needs to make corrections for a load disturbance or
20
setpoint change, because every time the controller has to reverse the valve, the controller
has to move the PD (controller output), through the full hysteresis range before the valve will
move in the opposite direction. As this movement of the PD is performed at the integral term
ramp rate, which gets less and hence slower, the closer the PV gets to setpoint, it can take a
very long time for the process to finally actually settle out at setpoint.”
(Michael Brown Control Engineering ,
http://www.instrumentation.co.za/regular.aspx?pklregularid=546 06.05.2015)
Det går an å måle en hystereseprosent, dette gjøres ved å kjøre sprang i referansen den ene
veien, f.eks fra 50% til 40% deretter fra 40%til 50% igjen. Hysteresen vil da vises som offset
på aktuatoren i forhold til ventilpådraget. Prosessen må selvfølgelig gjentas for å få mer
nøyaktig resultat.
I følge Michael Brown Control Engineering er hysterese inntil 1% er akseptabelt,
dersom hysteresen blir større må det gjøres tiltak, evt. skifte ventil.
I totankprosjektet fant vi ikke tid til å gjøre disse målingene, vi fant heller ingen måte å
hanskes med hysteresen på bortsett fra tiltakene nevnt tidligere.
21
2.2 IX-panel – AR, TMS, JA
2.2.1 Kravspesifikasjoner
Oppgaven ga noen spesifikke krav til hva som måtte være med på panelet. Kravene er vist i tabell 1.
Variable
Referanse til tank 1
Referanse til tank 2
Manuelt pådrag til tank 1
Manuelt pådrag til tank 2
Omstilling fra manuelt pådrag til automatisk
nivåregulering for tank 1
Omstilling fra manuelt pådrag til automatisk
nivåregulering for tank 2
Pådrag for tank 1
Pådrag for tank 2
Nivå i tank 1
Nivå i tank 2
Melding om alarmer fra tank 1
Melding om alarmer fra tank 2
Kvittering av alarmer fra tank 1
Kvittering av alarmer fra tank 2
Start/stopp pumpe
Skrives
X
X
X
X
X
Leses
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tabell 1 - Tabell som viser ønskede skrive- og leserrettigheter for operatørpanelet
Det er også slik at det skal være mulig å styre panelet fra webserveren.
22
X
2.2.2 Tags
De verdiene vi ønsker å sette og lese hos PLS-ene må legges inn som tags i iX Developer. Dette gir tag
listen vist i figur 21. Vi skriver direkte adressen på det minnet vi ønsker å lese/skrive til PLS-en..
Figur 21 – Tagliste IX-panel
I tag listen ser man også adressen og datatypen som er brukt i Master PLS-en (Melsec Q00). Dette ser
du under «Contollers». Under «Tag» feltet ser man navnet på taggen internt i programmet og
datatypen det skal behandles som.
Når vi nå har satt opp de objektene vi ønsker å benytte på panelet må vi knytte de opp mot tiltenkte
funksjoner. Vi gjør dette ved å velge hvilken tag objektet skal knyttes til og funksjonen til tagen.
23
2.2.3 Utforming og design
Siden operatørpanelet er ganske lite ble det bestemt at vi skulle lage et oversiktsbilde for de to
tankene, med bare den viktigste informasjonen. Om man ønsker å se med detaljert må man på
menylinjen nederst på skjermen velge hvilken tilleggsinformasjon som er ønskelig.
Figur 22 – Oversiktsbilde operatørpanel
Om du velger tank 1 på menylinja på oversiktsbildet vil du få opp dette vinduet. Hvor du har mulighet
til å gjøre alle innstillinger for tank 1 samt komme deg til alarmoversikten, trendvinduet for tank 1 og
hjelpe funksjonen.
Figur 23 – Operatørside for tank 1 IX-panel
24
Du har mulighet får å få opp et trendvindu for hver av tankene på IX-panelet. I Trendvinduet får du
tegnet, pådraget, referanse og nivå.
Figur 24 – Trendvindu IX-panel
Det er mulighet å få fram et hjelpvindu fra alle sider dette vil se slik ut:
Figur 25 – Hjelpvindu IX-panel
25
Det er spesifikt satt krav til hvordan alarmene skal fungere. Det er laget en alarmlampe som lyser på
alle skjermer, men du må til alarmvinduet for å kunne kvittere alarmene. Det er lagt til et alarmlys for
alarmer som blir kvittert i alarmtilstand som vil lyse til du er ute av tilstanden igjen.
Figur 26 – Alarmvindu IX-panel
26
2.3 InTouch
Når begge tankene skulle styres ble det laget ett nytt grensesnitt i intouch, bestående av de
beste elementene fra begge gruppene. Figurer for tanker, ventiler og lignende kommer fra
gruppe 5, mens felt for regulatorinnstillinger ble hentet fra gruppe 6. Virkemåte er stort sett
lik som i gruppe 5 sitt entankprosjekt.
På samme måte som i entankprosjektet skal det også være mulighet for å logge inn som tre
forskjellige operatører, som har forskjellig grad av mulighet for styring av de forskjellige
parameterne. Se entankrapport for mer detaljert informasjon om resirkulerte funksjoner.
Grensesnittet inneholder nå også mulighet for å aktivere bonusoppgaver. Gruppe 5 har laget
kameraovervåkning, som finnes i hovedmenyen. Gruppe 6 har laget autotuning av sin
regulator, som regulerer tank 2, denne aktiveres fra vinduet for regulatorinnstillinger.
For å få frem all informasjon så ryddig og oversiktlig som mulig fant vi ut at vi skulle benytte
oss av begge skjermene vi hadde til rådighet. Vi endte opp med selve prosessen og menyen
på den ene, og grafer og alarmliste på den andre.
Ved starten av totank prosjektet måtte det lages et nytt brukergrensesnitt, det skulle utvides
til to tanker istedenfor en. Vi slo sammen noen fra hver gruppe og plukket ut det beste fra
begge prosjekter, som vi satte sammen til et nytt brukergrensesnitt med to tanker.
I InTouch er det laget et passende brukergrensesnitt som skal simulere prosessen som skjer
på tankriggen. Det er satt opp et hovedvindu og flere «undervinduer» som skal åpnes etter
hvilken knapp en trykker på. Hovedvinduet inneholder pumpa, to ventiler, to tanker, tre
magnetventiler på utgangen av tank nummer 2, en ventil under tank nummer 1,
foroverkobling, nivåmålere, flowmåler, et trendvindu som grafisk viser nivået for hver av de
to tankene, referansen i tankene og ventilpådraget, en liste over alarmer, en meny med
knapper som åpner forskjellige vinduer. Øverst til høyre i vinduet på den ene skjermen kan
operatøren se hvem som er logget inn, et display med tid og dato og en knapp for å logge ut.
27
Figur 27 – Hovedvindu
I figuren vises hovedvinduet av brukergrensesnittet hvor en har mulighet til å kontrollere
prosessen. I hovedvinduet kan man klikke seg inn på forskjellige ruter for å endre
parametere, som referanse, Kp, Ti, valg mellom P-regulator og PI-regulator og valg mellom
direkte og reversert regulering.
I figuren ser vi tankene fra hovedvinduet. Her kan vi se at det er nivået i tankene som vises i
de blå søylene til venstre i tankene. Når InTouch kobles opp mot OPC Beijer og tankriggen,
vil dette nivået følge det reelle nivået i tanken. Nivået vil være ganske nøyaktig det samme
vist i InTouch som det er i tanken. Den røde streken som vises i figuren er referansen satt i
InTouch eller i IX-panelet. Det er satt inn to slidere, i form av trekantene som inneholder en
prosentverdi som viser prosentverdien for referansen satt i tankene. For brukeren med mest
tilgang vil sliderene være funksjonell og det vil da være mulig å endre referansen ved hjelp
av denne, uten å måtte klikke seg inn på parametervinduene.
28
Figur 28 – Trends i hovedvindu
I hovedvinduet er det vist tre trendvinduer. Her kan vi lese og ha full kontroll på hvordan
prosessene i tankene fungerer. Den røde linjen er for referansen, den blå er for nivået i
tanken og den grønne linjen er for ventilpådraget. Her kan vi se hvordan prosessene
oppfører seg over en gitt tidsperiode. På x-aksen vises trendvinduet over de siste 2
minuttene, dette gjør da at hver av de fire rutene som vises i figuren tilsvarer 30 sekunder.
Det er laget et eget vindu som heter Trends 1 og Trends 2 der en kan se prosessene for de to
tankene over de siste 10 minuttene.
Figur 29 – Parameterknapper
29
For å endre parameterne til prosessen er det opprettet to knapper i hovedvinduet for hver
av de to tankene, som åpner et nytt vindu der en kan velge de forskjellige verdiene for Kp, Ti
og lignende. Her har det i totank delen blitt laget to identiske knapper for
parameterinnstillingene. De er blitt navngitt som LIC1 og LIC2. Disse knappene fungerer som
forklart i entankrapporten, for gruppe 5, på side 69.
Figur 30 – Innlogging
I InTouch er det laget et verktøy for innlogging, hvor forskjellige brukere har tilgang til å sette
og lese for eksempel om regulatoren står i P- eller PI-regulering. Dette gjelder for begge
parameterknappene. I figuren kan vi klikke på knappene for parametere for så å komme inn
til valg av parametere. Man kan her lese hvilken tilstand regulatoren står i, altså om
regulatoren står i P- eller PI-regulering og om den står i auto eller manuell. Inne i
parametervinduene kan en av operatørene endre på om regulatoren skal stå i P- eller PIregulering og to av operatørene kan velge om regulatoren skal stå i manuell eller auto
regulering. I figuren kan også operatørene lese referansen og pådraget i tankene under
reguleringen.
30
Figur 31 – Parametervinduer
I figuren ser vi vinduene for parameterinnstillinger. Her kan vi sette parameterne for
regulatorene. Når dette bilde vises kan vi se at det er flere knapper i vinduene. Her kan vi
velge at regulatorene skal ha direkte eller reversert regulering. På dette bilde ser vi at begge
regulatorene står i auto med PI-regulering. Måten dette er satt opp på er forklart i
entankrapporten, for gruppe 5, på side 77.
Figur 32 – Manuellparametere
Dette er vinduet for manuellparametere. Her kan vi se de parameterne som kan endres når
regulatorene står i manuell. Ved å sette regulatorene i manuell kan en styre ventilene
manuelt slik at testing av reguleringen kan enklere gjennomføres. Ved å trykke knappen som
heter Auto vil en sette regulatoren tilbake til automatisk regulering. Når regulatorene går fra
manuell til auto vil regulatorene gå til den tidligere tilstanden den hadde før
manuellregulering ble valgt. Det er laget en funksjon i PLSen som gjør dette mulig.
31
Scriptene i det nye brukergrensesnittet er litt endret, som for eksempel for
parametervinduene. Da vi slo oss sammen med gruppe 6 fant vi ut at de hadde multiplisert
verdiene av Kp og Ti på en enklere måte. Så vi valgte derfor å bruke deres måte. Hvor de ikke
brukte script, men endret dette direkte i tagen. Dette er vist i figuren under.
For foroverkoblingen ble vi enig i å bruke det som ble gjort for gruppe 5 i entankrapporten.
Dette er knappen for foroverkobling. Denne fungerer som en knapp i likhet med
parameterknappen. Her er det også mulig å lese verdiene for Kp_FF og TD_FF. Ved å trykke
på denne knappen blir man sendt videre til vinduet for foroverkobling.
Figur 33 – Foroverkoblingsknapp
Figur 34 – Foroverkoblingsparametere
32
Her er det muligheter for å aktivere foroverkobling. Dette er kun mulig for den ene tanken,
det er for tank to. Ved å klikke på de forskjellige knappene for regulering nede til venstre i
figuren, settes den type foroverkobling som velges. Her gjelder det samme for sending av
disse verdiene som i parametervinduet. Det sendes pulser ned til PLSen som sender
tilbakemelding om type valgt foroverkobling. På dette bildet er det valgt foroverkobling av
typen Dff – regulering. Her kan du også endre parameterne i den øvre delen av vinduet.
Foroverkoblingen vil bli deaktivert enten ved å trykke på ”All Off” knappen nede til venstre i
figuren og ved å velge P- eller PI-regulering.
Det skal lages historiske trender slik at operatøren som nå logger seg inn på neste skift kan
se hvordan det har gått de siste 10 minuttene i de to tankene. Her vil man kunne se om det
har vært noen endringer i sprang eller forskjell i nivåene. Det er fullt mulig å endre hvor langt
tilbake man ønsker å se. Dette gjøres ved å trykke på trendvinduet. Det vil da åpne seg en
meny. Under ”Chart Lengths” kan man velge hvor langt tilbake man kan se i trendvinduene.
Det er laget et trendvindu for hver av tankene. I hovedvinduet ser vi at det er to knapper
som henholdsvis heter ”Trends 1” og ” Trends 2”, det er disse man trykker på for å få åpnet
vinduene for trendvisningen.
Det er også mulighet for å lagre trendvinduet. Dette gjøres ved å trykke nederst på vinduet
der det står ”save to file”. Hvis man ønsker å benytte en annen lagringsplass enn det som er
oppgitt kan man trykke på ”Filename” og sende filen dit man ønsker.
I figurene under vises de to historiske trendene, Historisk trend1 og Historisk trend2.
Figur 35 – Historisk trend 1
33
Figur 36 – Historisk trend 2
2.3.1 Sending av verdier
For at tankene skal fungere på en uforstyrret måte fra entankprosjektet sammen med
bonusoppgaven har vi valgt
Sending av verdier ned til PLS-ene foregår på forskjellige måter fra tank-1 og tank-2. Dette er
fordi at ved noen tilfeller ønsker vi kun å sende pulser og ved andre tilfeller ønsker vi å sende
faste verdier. Ved for eksempel setting av tanken bruker vi funksjonen ”toggle” som sender
verdien ”TRUE” eller ”FALSE” konstant. Ved andre tilfeller sender vi en puls som setter
verdien høy en gang, ellers holder den seg lav. Dette gjøres ved for eksempel om tanken skal
stå som P- eller PI-regulator.
Figur 37 – Pulssending av verdier. sender høy verdi en gang
34
Ved at vi sender pulser ned til PLS-en trenger vi også en tilbakemelding fra slave-enhetene
som bekrefter at verdien har blitt satt. Dermed har vi en tag som sender verdier ned til PLSene og en verdi som mottar fra PLS-ene inn til InTouch. Ved å sende verdier på denne måten
får vi en bekreftelse på at verdien har faktisk blitt satt i slave-PLS-ene. Dermed har vi full
kontroll på tilstanden til riggen.
2.3.2 IP Kamera
Når det gjelder bonusoppgaven har vi satt opp et IP kamera som skal vises både på nettsiden
og i InTouch. (For oppsett av selve IP kamera se kapittel 2.4).
For oppsett av IP kamera i InTouch har vi valgt å sette det inn i et nytt vindu som er
tilgengelig fra Hovedvinduet. I dette vinduet krever InTouch at vi setter inn en ekstra ActiveX
kontroll som kan åpne nettleseren til IP kamera.
Før vi kan sette inn IP kamera krever InTouch at vi installerer en nettleser som kan åpne
programmet til IP kameraet.
Først må vi klikke inn på Special / Configure / Wizard/ActiveX Installation.
Velg så ActiveX Control Installtion tabben øverst.
Under menyen ”Available ActiveX controls” blar vi oss ned til ”Microsoft Web Browser” og
trykker Install.
Microsoft Web Browser skal nå være i menyen ”Installed ActiveX controls”.
Vi har nå muligheten til en nettleser i InTouch.
Denne ligger inne på wizard selection / activeX Controls / Explorer. Denne setter vi i det
vinduet vi ønsker å ha IP kameraet vårt.
35
Figur 38 – Visning av IP kamera i InTouch
Det eneste som mangler for å få nettsiden til IP kameraet er vinduscriptet til IP kamera. I
script vinduet trykker du på insert / ActiveX… velg Explorer1 og navigate. I parantesen setter
settes adressen til IP kameraet som vist på figuren under. Oppsettet er nå ferdig og skal ha
tilgang til å se og styre IP kamera fra InTouch.
Figur 39 – Scriptet til IP kamera i Intouch
36
2.3.3 Alarmer
Alarmer er en advarsel at en prosess har oversteget sin normaltilstand og krever
operatørens oppmerksomhet og handling. En alarm skal bli satt når en prosessverdi
overstiger den brukerdefinerte grensen. I vårt tilfelle er det to krav til alarmer. Det skal være
en avviksalarm og to grensealarmer. Det skal gå en alarm dersom nivået avviker mer enn
25% fra referansen (25% av totalt måleområde.) Grensealarmer skal aktiveres dersom nivået
i tanken overstiger 90% eller går under 10%.
2.3.4 Definering av alarmer
For at vi skal lettere gjenkjenne alarmene kan vi definere de forskjellige alarmtypene. ved
kritisk alarm har vi to forskjellige alarmer. En når alarmen kritisk høy og kritisk lav. For å se
forskjell på disse kan vi sette alarmtilstand kritisk_HH når nivået i tanken når 90%, Kritisk_LL
når nivået er under 10% og kritisk_Avvik når avviket overstiger med 25% i forhold til
referansen. Det er også satt opp noen ekstra alarmer utenom kravet til oppgaven og disse
blir definert ved busfeil, strømbrudd, lavt_batteri osv. Se Tabellen under for å se den fulle
alarmoversikten
Tabell 1 alarmliste i InTouch
ALARM
ADRESSE
ALARMVERDI
FORKLARING
ALARM_LAV_T2
M54
10
Kritisk lavt nivå i tank 2, mindre enn 10%
ALARM_HOY_T2
M53
90
Kritisk høyt nivå i tank 2, større enn 90%
ALARM_AVVIK_T2
M55
25
Nivå avvik større enn 25% fra referansen i
tank 2
ALARM_AVVIK_T1
M52
25
Nivå avvik større enn 25% fra referansen i
tank 1
ALARM_LAV_T1
M51
10
Kritisk lavt nivå i tank 1, mindre enn 10%
ALARM_HOY_T1
M50
90
Kritisk høyt nivå i tank 1, større enn 90%
Busfeil
M0
TRUE (1)
Mistet tilkobling til slave 1 og 2
Lav_batteri_QPLS
M1
TRUE (1)
Lavt batteri i Q-PLS
Kritisk_lavt_QPLS
M2
TRUE (1)
Kritisk lavt batteri i Q-PLS
37
2.3.5 Sikkerhet
Det skal lages et vindu der operatøren må logge seg inn med eget brukernavn og passord. Til
programmet vi bruker er det opprettet tre brukernavn OPERATØR1, OPERATØR2 og
OPERATØR3 der operatør 3 har alle rettigheter mens de to andre operatørene har mer
begrenset rettighet. Passordene til de forskjellige brukerne er Op1, Op2 og Op3.
For opretting av brukere se side 84 på entankprosjektet til gruppe 5.
Tabell 2 Tabelloversikt av de tre brukerne, passord og tilgangsnivå
User name
Password
Access Level
OPERATØR1
Op1
1000
OPERATØR2
Op2
3000
OPERATØR3
Op3
9000
For en bedre beskrivelse av innloggingssiden se side 86 av entankprosjektet til gruppe 5.
38
2.3.6 Access Level
Før vi oppretter brukerkontoer må vi bestemme hva slags sikkerhet vi ønsker å bruke.
InTouch har muligheten til å begrense tilgangen til innloggede brukere avhengig av hvilket
tilgangsnivå de har. Dette er mellom 0 – 9999, hvor 0 er lavest og 9999 er høyest (tilgang til
alt.)
Tilgangsnivået er taggen som brukes til å sikre InTouch applikasjonene. Det er
hovedsystemet som en bruker kan eller kan ikke gjøre i Runtime. For eksempel kan ikke vil vi
ikke at OPERATØR1 skal se et objekt kan vi skrive følgende i en Visibility link, $AccessLevel
>=3000. Nå vil kun brukere med Access level lik 3000 eller høyere få tilgang til dette
objektet. I vårt tilfelle blir det da OP2 og OP3. For en full oversikt av hvem som har tilgang til
hva i InTouch se vedlegg nr. 1. Figurene under er et eksempel på hvordan parametervinduet
vil se ut for de tre operatørene.
Figur 40 - Parametervising for OP2 og 3
Figur 41 – Parametervising for OP1
For en mer utfyllende beskrivelse av tilgangsnivåene se side 85 på entankprosjektet til
gruppe 5.
39
40
2.4 Bonusprosjekt gruppe 5 – IP-Kamera – AR
Som en bonusoppgave i dette prosjektet har vi mulighet til å ta i bruk et IP-kamera som kan
fjernstyres over internett.
Teknisk info:





SONY –RZ30P
25 x optisk zoom
340 graders rotering
Innebygd webserver for
fjernstyring
10/100 MBs ethernet-tilkobling.
Sony-RZ30P IP-kamera
Figur 42 – IP-kamera
Kameraet er bygd inn i hjemmesiden til prosjektet i tillegg til at det ble benyttet som en del av
brukergrensesnittet i InTouch.
2.4.1 Oppsett:
Kameraet er tilkoblet nettverket via den trådløse routeren. Ved første gangs tilkobling vil kameraet
automatisk få en IP-adresse. Denne kan man finne ved å logge inn på routeren og se tilkoblete
klienter.
41
Man kan koble til kamera ved hjelp av IP-kamera programvare eller man kan bruke en nettleser. Man
vil da få valget mellom flere typer viewer hvor kompatibiliteten avhenger av typen nettleser og
datamaskinen man bruker. Under ser vi Java-viewer i bruk.
Man kan kontrollere kameraet ved bruk av panelet ved siden av.
Figur 43 – Webkameragrensesnitt i nettleser
42
For at man skal kunne nå kameraet over internett, må vi sette en port til kameraet som må portforwardes. Standardporten til kameraet er 80. Det er denne vi må endre.
Figur 44 – Innstilling av HTTP-port i webkamera
Man finner innstillingene i Settings – Network. Over ser vi at HTTP porten er endret til 3333. I
routeren er det lagt opp slik at man finner kameraet over internett ved å skrive
http://158.38.53.139:3333 i en nettleser.
43
2.5 Bonusprosjekt gruppe 6 – Autotuning
2.5.1 PLS-kode – SBD
Bonusoppgaven vår går ut på å lage ei autotuning for regulatoren vår. Autotuning fungerer som en
av- og på-regulator, hvor verdier fra svingningene måles, og deretter benyttes disse til å komme med
et forslag til Kp og Ti parametere som vil gi et gunstig innsvingningsforløp.
En av og på regulator skal gi maks pådrag dersom prosessverdien er under referansen, og minimum
pådrag dersom prosessverdien er over referansen. I vår regulator blir dette 255 dersom
prosessverdien er under referansen, og 0 dersom prosessverdien er over referansen. Programmet
sjekker for dette ved å se på fortegnet på avviket. Dersom avviket er positivt er prosessverdien under
referansen, og dersom det er negativt er prosessverdien over referansen.
I tillegg til dette ønsker vi måling på periodetid, topp- og bunnpunkt. Vi finner toppunkt med å
sammenligne aktuelt nivå med forrige nivå. Dersom forrige nivå er høyere enn aktuelt nivå, og nivået
er over referansen, er det forrige nivået et toppunkt. Dersom det forrige nivået er lavere enn det
aktuelle nivået, og nivået ligger under referansen, er det forrige nivået et bunnpunkt. Dette gjelder
bare en gang hver halvperiode, ettersom nivået vil være stigende eller synkende etter bunn- og
toppunktet. Periodetiden måles ved å telle opp hvert 0.1 sekund. Dette gir 10*periodetid, men vi
bruker denne for ei mer nøyaktig måling.
Figur 45 – Samlig av måleverdier for svigningene (autotuning)
44
Periodetiden, og begge de benyttede tellerne må nullstilles ved hver nye periode. I dette
programmet har vi valgt å definere en periode til hver gang prosessverdien kommer over referansen,
til neste gang prosessverdien kommer over referansen. Det sendes derfor en puls som markerer ny
periode hver gang avviket går fra positivt til negativt. Ved samme tidspunkt skal antall perioder som
har gått telles opp.
Figur 46 – Start av ny periode for svigninger
45
Programmet skal regne ut parametere basert på verdier fra stående svingninger. Vi kan finne stående
svingninger ved å sammenligne aktuelle verdier for periodetid, topp- og bunnpunkt, med de forrige
verdiene. Dersom aktuelle verdier og forrige verdier er like, har vi oppnådd stående svingninger, og
det er på tide å starte utregningen.
Figur 47 – Sammeligner forrje verdi med nåverdi for å se om det er stående svigninger
Ettersom vi kun sampler data ved visse samplingsintervall, blir denne sammenligningen unøyaktig.
Sammenligningen må være nøyaktig på bit-verdier, og vi risikerer da at programmet aldri finner
punktet med stående svingninger. Programmet vil da aldri gå inn i utregningsdelen. Vi har derfor
valgt en annen løsning for å gå rundt dette. Vi bruker da variabelen som teller antall perioder, og
setter ei grense på hvor mange perioder som skal kjøres før programmet starter utregningen. Vi
kunne satt denne grensen til hva som helst, men vi gjør et anslag og antar at vi har oppnådd stående
svingninger etter 7 perioder. Erfaring fra tidligere forsøk vi har gjort med autotuning viser at
systemet skal være godt innenfor stående svingninger i løpet av 7 perioder.
46
Figur 48 – Sjekker om det har gått 7 perioder siden start av autotuning
47
Vi ønsker også å se hvor stor fremgang autotuningen har, altså hvor mange prosent ferdig den er.
Dette kjører en sammenligning på antall perioder som har kjørt, og antall perioder som skal kjøres,
og svarer skrives ut som et tall i prosent, 0-100.
Figur 49 – Måler hvor langt autotuning har kommet
Etter dette skrives de 16-bits målte verdiene over til 32-bits dataord på samme måte som i
entankprosjektet figur 16. Deretter benyttes algoritmene for utregning av kritisk forsterkning (Kk) og
kritisk periodetid (Tk).
. I vårt
system er topp-til-bunn for pådrag en konstant. Og vi kan da sette telleren som en konstant.
Ettersom programmet ikke takler desimaltall må vi benytte 127 istedenfor 1.27. Konstanten blir da
32385.
. Vi benytter deretter Ziegler-Nichols tabell for å finne
forslag til Kp og Ti. Ettersom autotuning er en metode som er beregnet på PID-regulatorer, blir det
unøyaktig å benytte Ziegler-Nichols tabell for PI-regulator. Det blir da mer nøyaktig å stille inn
regulatoren som om vi skulle hatt en D-del, men D-delen settes lik 0. Vi får da algoritmene
og
.
Figur 50 – Regner ut Kp og Ti utfra målte verdier på Kk og Tk
48
De 32-bits dataordene skrives deretter over til 16-bits dataord, på samme måte som i
entankprosjektet figur 19.
Etter utregningene er ferdige skal funksjonsblokken gi et signal om at autotuningen er ferdig. Dette
gjøres enkelt ved at variabelen for at programmet er ferdig er avhengig av samme variabel som
utregningene, og skal ligge etter utregningene i koden.
Figur 51 – Sender et signal for når autotuningen er ferdig
Til slutt må denne funksjonsblokken inkluderes i resten av programmet. Dette ved at vi kaller på
funksjonsblokken som en lokal variabel i en POU, og funksjonsblokken legges til med de parameterne
vi skal bruke. Start av autotuningen skal kunne styre fra master, og autotuningen skal skru av seg selv
når den har kjørt ferdig. Veriden på minnecelle M50 styres fra master, og denne får en positiv puls
når autotuning aktiveres. Ettersom vi ønsker at autotuningen skal kjøre av seg selv etter dette, skal
variabelen for autotuning bli satt høy helt til den blir nullstilt. Dersom autotuningen skal avbrytes
mens den kjøres, settes M51 høy fra master, og variabelen for kjøring av autotuning avsluttes. Denne
variabelen skal også nullstilles når programmet har kjørt ferdig.
Figur 52 – Viser hvordan autotuningen kjøres
49
For at autotuningen ikke skal få problemer dersom den startes mens regulatoren står som manuell
regulator, må regulatortypen endres dersom autotuningen skal starte. Dette er fordi referansen
settes lik prosessverdi dersom manuell modus er valgt, og vi kan da ikke kjøre utregninger med
avviket. En enkel nullstillingsfunksjon settes da i starten av POUen for manuell modus. Ettersom
POUen for autotuning ligger etter POUen for manuell modus, skal manuell modus kobles ut av
samme knapp som autotuningen aktiveres, eller dersom autotuning allerede ligger aktiv.
Figur 53 – Sørger for at pådraget står i manuell under
autotuning
50
2.5.2 Betjening av autotuning i intouch – KS
Autotuninga betjenes fra et helt eget, lite og enkelt vindu.
For å få frem dette må du først åpne vinduet for regulatoren,
der er det nå lagt til en egen knapp.
Figur 54 – Viser hvordan du velger
autotuning i InTouch
Nå har du to valg, enten kan du starte autotuninga, eller
du kan lukke vinduet igjen.
Figur 55 – Viser hvordan forslaget til instillinger
kommer ut
Vi ville at det skulle vises en
indikering på hvor lenge det
er igjen til autotuninga er
ferdig, så det ble lagt til en utgang fra PLS som brukes
til å bestemme om vinduet skal vise verdiene
regulatoren har regnet ut, eller om det skal be deg om
å vente. Når du trykker «start» blir denne høy, og det
vises en strek som blir grønn fra venstre mot høyre
sammen med et tall som oppgir antall prosent, i
henhold til verdien «Framgang» i PLS programmet.
Figur 56 – Viser status på autotuningen
51
3 Prosjektstyring gruppe 5
3.1 Deltagere
52
3.2 Tidsbruk – KR
Her har vi timebruken gjennom hele prosjektet. Ser at vi ligger noe under helt til etter påske.
Fra påske ligger vi akkurat på estimert tidsbruk.
Ser også at vi ligger en del timer under etter uke 16. Vi begynte å få god kontroll på
Entankprosjektet, og det var rapportskriving som var i fokus.
Mener vi har estimer tidsforbruket ganske bra.
53
3.3 Prosjektstyring og samarbeid – AR & KR
Den 25/2 fikk vi utlevert prosjektoppgaven i faget «Styresystemer». Under løsning av prosjektet
jobbet vi sammen i grupper, der to grupper skulle dele på én rigg. Det var da viktig å lage en plan på
hvilken gruppe som skulle få jobbe med riggen, inndelingen ble annenhver dag. Dette fungerte veldig
bra, med tanke på at vi ikke trengte stresse med å bli ferdig med riggen i tide.
Et suksesskriterie for å løse oppgaven på en god og effektiv måte er godt samarbeid. Det første vi
gjorde var å få opprette et felles plan på «Its Learning» som vi kalte «Prosjekt 2015». Her
strukturerte vi prosjektet i de delprosjektene som hele prosjektet bestod av. Vi hadde også et system
på hva vi skulle gjøre når vi la ut det vi hadde jobbet med på» Its Learning». Det var viktig at ved
redigering av noe som var lagt ut fikk kommentarer på hvem som hadde redigert og når. På denne
måten hadde vi hele tiden god kontroll på siste gjeldene versjon.
Under arbeid av hvert enkelt delprosjekt hadde vi internmøter som gruppeleder hadde ansvar for.
Dette gjorde vi for å oppdatere hver enkelt i gruppen på framgangen i arbeidspakkene vi jobbet med.
På denne måten sørget vi for at vi jobbet mot samme mål slik at sammensying av hver enkelt
arbeidspakke gikk greit for seg.
De to første delprosjektene, Forprosjektet og Miniprosjektet gikk veldig greit. Disse delprosjektene
var ganske små og i tillegg var de ikke så kompliserte. De største utfordringene kom under
Entankprosjektet, som var det største delprosjektet. Her delte vi gruppen i tre par der hvert enkel par
hadde sin arbeidspakke, InTouch og iX-Panel, PLS og Filter. Selve arbeidet med arbeidspakkene gikk
veldig greit. De som jobbet med InTouch og PLS prøvde å jobbe parallelt, men det viste seg å være
vanskelig. Grunnen til dette kan være at vi ikke hadde noe felles mål på hvordan vi ønsket at det hele
skulle fungere sammen, noe som vi burde gjort under internmøtet. Dette resulterte i at vi hele tiden
måtte gjøre endringer for å tilpasse oss hverandre, noe som førte til at vi brukte mye unødig tid.
Under arbeidet fant vi til slutt ut av dette og satte oss ned for å bli enige på hvordan det skulle
fungere sammen. Vi ble til slutt veldig fornøyde med resultatet.
54
4 Prosjektstyring gruppe 6
4.1 Deltagere
Stian Berg Dyrnes – SBD
Emil Welde Hatletveit –EWH
Kristian Strøm – KS
Terje Magnus Sørensen – TMS
Snorre Vongraven - SV
Andreas Haugen – AH
Dato 07.04.2015
55
4.2 Tidsbruk –TMS
Vi ligger noe under det planlagte fordi det tok mye kortere tid å konstruere filteret enn planlagt, vi
nærmer oss den planlagte verdien igjen grunnen til dette er at det var noe mer arbeid med
samkjøring av programmene under totankprosjektet enn vi gjettet under forprosjektet.
Vi la også inn litt færre timer på slutten slik at vi hadde mer tid til rådighet om vi lå litt bak skjema.
Det må sies at vi har estimert bra, når vi kun fikk et avvik på ca 60 timer under hele prosjektarbeidet.
Tidsbruk
1800
1600
1400
1200
1000
800
600
400
200
0
8
9
10
11
12
13
14
Planlagte timer
15
16
17
18
19
Utført arbeid
4.3 Prosjektstyring og kvalitetssikring – SV
Prosjektet skal til enhver tid ha en leder. Lederen byttes hver uke, og ved prosjektets slutt
skal hver enkelt gruppedeltaker ha fått prøvd seg i jobben.
Lederen er ansvarlig for møteinnkalling, saksliste og gjennomføring av det ukentlige møtet.
Han vil også være ansvarlig for prosjektets framgang, og tidsfrister.
4.3.1 Statusrapportering
Møteleder skal vær uke fremlegge en statusrapport, som skal gjennomgås på prosjektmøtet.
Møteinnkallelser, møtereferat og annen relevant dokumentasjon lastes opp til felles
dropbox-mappe.
56
4.3.2 Standardiserte skjemaer
Gruppen skal bruke standardiserte skjemaer for møteinnkalling, møtereferat, og
arbeidspakkeskjema. Disse ligger tilgjengelig på It´s Learning under faget «TELE2008-A 15V
Styresystemer og reguleringsteknikk».
4.3.3 Versjonskontroll
Dokumenter og filer som blir produsert i forbindelse med prosjektet blir lagret i en felles
Dropbox-mappe. Filene skal ha beskrivende navn, og inneholde versjonsnummer eller dato.
4.3.4 Tester og sjekklister
Programmer og sjekklister skal sammenlignes mot mål og spesifikasjoner nevnt i
forprosjektrapporten. Eventuelle avvik skal dokumenteres og rettes.
57
4.4 Prosjektstyring og samarbeid – SV & KS
Rett etter vi fikk utlevert oppgaveteksten 25/2 satte gruppe 6 seg ned og leste gjennom hele
teksten grundig. Vi diskuterte ting som virket uklare, og lagde oss en teori om hvordan
prosjektet skulle utføres. I løpet av forprosjektet lagde vi også en plan for hvem som skulle
ha hovedansvaret for de forskjellige prosjektdelene.
For å forenkle arbeidet med fildeling og kommunikasjon ble det raskt opprettet flere grupper
på internett. Filer som ble delt innad i gruppen skulle legges ut på nettskytjenesten dropbox,
med fornuftige navn som gir informasjon om datoen den ble laget, og hva filen inneholder.
Inne i gruppe 6 sin mappe på dropbox ble det opprettet flere undermapper til hver
prosjektdel, bilder og lignende.
For å forenkle kommunikasjon oss imellom lagde vi en gruppe på nettsamfunnet facebook.
Den bruker vi til å holde en generell oversikt over framgangen og hvor lang de forskjellige
medlemmene har kommet.
I tillegg til dette ble det opprettet en katalog på undervisningsnettstedet itslearning for
deling av rapporter, møteinnkallinger og lignende mellom gruppen og veileder.
Gruppe 5 og 6 har sammen en rigg til rådighet i prosjektet. Vi måtte da finne en ordning for
hvem som skulle har riggen til enhver tid. Det ble bestemt at vi skulle ha riggen annenhver
dag. Dette har fungert utmerket hele prosjektet igjennom.
For å holde oversikt over adressene vi brukte i entank satte vi opp et Excel-dokument med
en tabell (se vedlegg 9 i entankrapport) over alle adressene vi skulle bruke i master, slave 1,
slave 2, samt hvilken retning informasjonen flyter og hva de ble brukt til. Slik kunne vi jobbe
med hver vår oppgave uten å behøve å mase konstant på hverandre, samtidig som at
sjansen for å få problemer med samkjøring blir minst mulig.
På tross av at vår veileder ikke har fast kontor på bygget, og at de resterende veilederne ikke
er å finne på campus hele uken, føler vi at veiledningen har vært tilstrekkelig. Vi har hele
vegen selv måtte oppsøke hjelp når det er behøvelig, og tror dette har lagt grunnlaget for et
godt samarbeide innad, og i mellom gruppene. «Å lære ved å gjøre» har vært en
gjennomgående filosofi i prosjektets gang, og gruppens hoder har ofte måtte ta tak i
problemer med samlet kraft. Vi sitter nå igjen med en dyptgående forståelse av prosjektet i
sin helhet.
58
5 Prosjektstyring totank – AR & KR
Etter entankdemonstrasjonen tirsdag 28/4 slo vi sammen gruppe 5 og 6 til en felles gruppe
på 12 personer som sammen har utarbeidet totankprosjektet. Det første vi gjorde var å
gjennomførte vi et internt møte hvor det ble bestemt hvem som skulle være ansvarlig for
hva. Vi valgte å la de ansvarlige fra InTouch, PLS og operatørpanel få fortsette i samme spor
som ved entankprosjektet for å løse problemene på en enklest mulig måte.
Arbeidet med totankprosjektdelen har gått rimelig bra siden vi startet. For det meste har det
handlet om å utvide brukergrensesnittent i InTouch og operatørpanelet til to tanker
istedenfor èn, og programmere PLS’ene i forhold til dette. Begge gruppene fikk god erfaring
med disse oppgavene i entankprosjektet, og dette har uten tvil vært en stor fordel mtp
totankprosjektet. Siden vi er 12 personer som jobber sammen om dette, har det også vært
viktig å dele inn oppgavene for at vi ikke skal sitte 11 personer og se på at en person jobber.
I tillegg til totankprosjektet har begge gruppene gjort ferdig bonusoppgaven sin. Gruppe 5
har ferdigstilt bonusoppgave 3 – ”Kameraovervåking av tankriggen via internett”, og gruppe
6 har ferdigstilt bonusoppgave 5 – (eget forslag)” Autotuning av PID-regulator”. Disse
bonusoppgavene er dokumentert i totankrapporten.
Inndeling totank (bonusoppgaver ikke inkludert)
•
PLS (GX Works) – Knut M. Røsberg, Roy K. Solvang, Stian Dyrnes & Emil Hatletveit
•
InTouch – Fredrik Løkken, Michael Mcgrory, Kristian Strøm & Snorre Vongraven
•
Operatørpanel (iX-panel) – Jørgen Aasen, Andreas Rød & Terje M Sørensen
•
Tidsskriftsartikkel – Andreas Rød (Gruppe 5) & Andreas Haugen (Gruppe 6)
59
6 Konklusjon – SV
I Totankrapporten har vi dokumentert arbeidet vi i gruppe 5, og 6 har utført i løpet av siste
del i prosjektet. Oppgaven gikk ut på at 2 grupper skulle arbeide sammen om å
implementere en ekstra tank til programmene våre. Dette gjelder både
brukergrensesnittene og styresystemet. I tillegg til dette skulle bonusoppgavene til hver av
gruppene fullføres.
Det viste seg at det tekniske aspektet av oppgaven ikke var spesielt krevende. Utfordringen
kom av gruppens størrelse. Til tross for god kommunikasjon og samarbeidsvilje, viste det seg
til slutt at vi manglet noen som hadde et overordnet ansvar for de enkelte delenes
fullførelse. Vi føler at antall deltakere var i meste laget sett i forhold til oppgavens størrelse.
På tross av noen problematiske siste timer, har vi fått utført oppgaven i henhold til kravene
satt i oppgaveteksten, og er godt fornøyd med resultatet.
Figur 57 – Oversiktsbilde kobling mellom PLS-rig og tank-rig
60
7 Litteratur – TMS
Vi brukte følgende verker under entankprosjektet.







Arnfinn Hofstad «PLS-teknikk; Mitsubishi Melsec FX0(S) og FX2N; GX Works2»
Per Hveem «Sanntidsdatateknikk; Digitale regulatorer, Forelesningsnotater»
Per Hveem, Kåre Bjørvik «Reguleringsteknikk»
Kåre Bjørvik «Dynamiske systemer»
Prosjektperm lagt ut offentlig på It's Learning.
Sebord,Edgar,Mellichamp og Doyle « Process Dynamics and Control»
InTouch HMI 9.5 Fundamentals of Aplication Development Course.
61
8 Vedlegg
1.
2.
3.
4.
5.
6.
7.
8.
Figurlister
Master PLS
Slave 1 PLS
Slave 2 PLS
Sjekkliste ved test av totank
OPC BEIJER SLAVE 1
OPC BEIJER - Slave 2
Oversiktsvindu
62
Figurliste
Figur 1 – Oversiktsbilde kobling mellom PLS-rig og tank-rig ................................................................... 1
Figur 2 – Liste over minneceller og dataord til slave 1 ............................................................................ 5
Figur 3 – Liste over minneceller og dataord til slave 2 ............................................................................ 6
Figur 4 – POU for slave 1 i masterprogrammet ....................................................................................... 7
Figur 5 – POU for slave 2 i masterprogrammet del 1 .............................................................................. 7
Figur 6 – POU for slave 2 i masterprogrammet del 2 .............................................................................. 8
Figur 7 – Alarmprogram for tank 2 del 1 ................................................................................................. 9
Figur 8 – Alarmprogram for tank 2 del 2 ............................................................................................... 10
Figur 9 – Alarmprogram for tank 2 del 3 ............................................................................................... 11
Figur 10 – POU for alarmaksjoner del 1 ................................................................................................ 12
Figur 11 – POU for alarmaksjoner del 2 ................................................................................................ 12
Figur 12 – POU for alarmaksjoner del 3 ................................................................................................ 13
Figur 13 – POU for alarmaksjoner del 4 ................................................................................................ 13
Figur 14 – Sprangrespons fra trendvindu i InTouch .............................................................................. 14
Figur 15 – Prinsippskisse FOPDT ............................................................................................................ 15
Figur 16 – Målepunkt for FOPDT ........................................................................................................... 15
Figur 17 – ITAE tabell ............................................................................................................................. 16
Figur 18 – Sprangrespons på tank 2 ...................................................................................................... 17
Figur 19 – Målepunkt for FOPDT ........................................................................................................... 18
Figur 20 – Prinsippskisse av ventil ......................................................................................................... 20
Figur 21 – Tagliste IX-panel ................................................................................................................... 23
Figur 22 – Oversiktsbilde operatørpanel ............................................................................................... 24
Figur 23 – Operatørside for tank 1 IX-panel .......................................................................................... 24
Figur 24 – Trendvindu IX-panel ............................................................................................................. 25
Figur 25 – Hjelpvindu IX-panel .............................................................................................................. 25
Figur 26 – Alarmvindu IX-panel ............................................................................................................. 26
Figur 27 – Hovedvindu........................................................................................................................... 28
Figur 28 – Trends i hovedvindu ............................................................................................................. 29
Figur 29 – Parameterknapper ............................................................................................................... 29
Figur 30 – Innlogging ............................................................................................................................. 30
Figur 31 – Parametervinduer................................................................................................................. 31
Figur 32 – Manuellparametere.............................................................................................................. 31
Figur 33 – Foroverkoblingsknapp .......................................................................................................... 32
Figur 34 – Foroverkoblingsparametere ................................................................................................. 32
Figur 35 – Historisk trend 1 ................................................................................................................... 33
Figur 36 – Historisk trend 2 ................................................................................................................... 34
Figur 37 – Pulssending av verdier. sender høy verdi en gang ............................................................... 34
Figur 38 – Visning av IP kamera i InTouch ............................................................................................. 36
Figur 39 – Scriptet til IP kamera i Intouch ............................................................................................. 36
Figur 40 - Parametervising for OP2 og 3 ............................................................................................... 39
Figur 41 – Parametervising for OP1 ...................................................................................................... 39
Figur 43 – IP-kamera.............................................................................................................................. 41
Figur 44 – Webkameragrensesnitt i nettleser ....................................................................................... 42
Figur 45 - Innstilling av HTTP-port i webkamera ................................................................................... 43
Figur 46 – Samlig av måleverdier for svigningene (autotuning) ........................................................... 44
Figur 47 – Start av ny periode for svigninger ........................................................................................ 45
63
Figur 48 – Sammeligner forrje verdi med nåverdi for å se om det er stående svigninger .................... 46
Figur 49 – Sjekker om det har gått 7 perioder siden start av autotuning ............................................. 47
Figur 50 – Måler hvor langt autotuning har kommet............................................................................ 48
Figur 51 – Regner ut Kp og Ti utfra målte verdier på Kk og Tk .............................................................. 48
Figur 52 – Sender et signal for når autotuningen er ferdig ................................................................... 49
Figur 53 – Viser hvordan autotuningen kjøres ...................................................................................... 49
Figur 54 – Sørger for at pådraget står i manuell under autotuning ...................................................... 50
Figur 55 – Viser hvordan du velger autotuning i InTouch ..................................................................... 51
Figur 56 – Viser hvordan forslaget til instillinger kommer ut................................................................ 51
Figur 57 – Viser status på autotuningen................................................................................................ 51
Figur 58 – Oversiktsbilde kobling mellom PLS-rig og tank-rig ............................................................... 60
64