hovedoppgave ved institutt for maskin og...
TRANSCRIPT
-
Hovedoppgave ved institutt for
maskin og marin
System for automatisk flushing og
trykktesting av hydraulikkrør.
- Undersøkelse av gjennomførbarhet og produksjon av prototype.
Utdanning/kull/klasse: 11HUVT
Innleveringsdato: 28.05.14
Antall ord: 13 084
Antall sider uten vedlegg: 83
Veileder: Boris Balakin
Vi bekrefter at arbeidet er selvstendig utarbeidet, og at referanser/kildehenvisninger til alle
kilder som er brukt i arbeidet er oppgitt, jfr. Forskrift om studier og eksamen ved Høgskolen i
Bergen, § 6-1.
-
2
HØGSKOLEN I BERGEN
Avdeling for Ingeniørutdanning
TITTELSIDE FOR BACHELOROPPGAVE
Rapportens tittel:
System for automatisk flushing og trykktesting av
hydraulikkrør. – Undersøkelse av gjennomførbarhet og produksjon av prototype.
Dato:28.05.14
Rapportnummer:M94
Forfatter(e):
Erik Hjertholm, Robin Sørensen
Robin Sørensen
Antall sider u/vedlegg: 80
Antall sider vedlegg: 80
Studieretning: Undervannsteknologi Antall elektroniske dokumenter: 22
Veileder ved HiB: Boris Balakin Gradering: Ingen
Merknader:
Oppdragsgiver: NTOS AS avdeling Askøy Oppdragsgivers referanse: Ivar Spjeld
Oppdragsgivers kontaktperson: Ivar Spjeld Telefon: 98285550
Sammendrag:
Oppgaven gikk ut på å undersøke om det er gjennomførbart å lage et system som automatisk kan
trykkteste og flushe hydraulikkrør.
Systemet ble simulert på forskjellige måter for å bekrefte gjennomførbarhet med godt resultat.
Det ble bygget en prototype med alle hydrauliske komponenter og styring. Denne ble testet og
fungerte som planlagt etter å ha eliminert utfordringer med denne type systemer.
Utfordringer med bygging og testing ble løst underveis, og resultatet er et system som med små
modifikasjoner kan tas i bruk til det formål den er tenkt.
Høgskolen i Bergen, Avdeling for ingeniørudanning
Postadresse: Postboks 7030, 5020 BERGEN Besøksadresse: Nygårdsgaten 112, Bergen
Tlf. 55 58 75 00 Fax 55 58 77 90 E-post: [email protected]
Hjemmeside: http://www.hib.no
mailto:[email protected]://www.hib.no/
-
3
FORORD
Dette er en avsluttende rapport fra arbeid med hovedoppgave ved
instituttet for maskin og marin ved Høgskolen i Bergen. Hovedoppgaven har
gått ut på å lage et system for automatisk flushing og trykktesting av
hydrauliske rør. Oppgaven er gitt av NTOS AS, og store deler av arbeidet har
foregått hos dem.
Det har vært en veldig krevende oppgave og den har vært mye mer
omfattende enn det vi hadde trodd på forhånd. Samtidig har vi lært utrolig
mye, da mye av det vi har jobbet med har vært ukjent terreng som vi i stor
grad har måttet finne ut av selv. I tillegg til dette er oppgaven meget
flerfaglig bygget opp, hvilket har gjort den veldig interessant.
Vi vil rette en stor takk til alle som har gitt oss hjelp og veiledning. Av disse
kan vi nevne alle i NTOS AS avdeling Askøy, samt Simon Møllerstrøm på
avdelingen på Ågotnes for hjelp med det hydrauliske systemet. På NTOS
avdeling Askøy har vi blitt tatt meget godt hånd om med eget kontor,
mulighet til å jobbe etter normal arbeidstid, lunsj osv. Alexander Furre har
hjulpet oss å velge PLS-system. Geir Jonny Andersen har gitt oss tips i
forbindelse med Omron sitt PLS-system, Kurt Hjertholm har delt sin erfaring
med ABB. Lars Barstad hjalp oss å finne komponenter i forbindelse med
styring og vår veileder Boris Balakin har hjulpet oss med selve skrivingen av
oppgaven.
I tillegg til dette vil vi rette en spesielt stor takk Herbert Heldal ved Bergen
Maritime Videregående, for utlån av PLS og tilhørende komponenter. Dette
forenklet gjennomførelsen av oppgaven i stor grad.
Oppgaven er skrevet med tanke på at leser har en viss teknisk forståelse,
for å kunne skjønne hvordan alt fungerer. En dypere kjennskap til elektro,
instrumentering, automasjon, programmering, hydraulikk og montering vil
kreves dersom man skal bygge systemet selv.
ERIK HJERTHOLM ROBIN SØRENSEN
-
4
INNHOLDSFORTEGNELSE
FORORD 3
SAMMENDRAG 7
1. INNLEDNING 8
1.1 BAKGRUNN 8
1.2 PROBLEMSTILLING 8
1.3 KRAVSPESIFIKASJON OG DESIGN 9
1.4 MARKED FOR TRYKKTESTING 10
1.4.1 ØKONOMISK PÅVIRKNING 10
2. METODE 11
2.1 TRYKKTESTING 11
2.2 FLUSHING 12
2.2.1 REYNOLDS TALL 13
2.2.3 TURBULENT FLOW 13
2.3 SYSTEM 14
GENERELT 14
2.3.1 HYDRAULISK SYSTEM 14
2.3.2 SENSORER 17
2.3.3 VENTILER 21
2.3.4 PLS 23
2.3.5 HMI 26
2.3.6 RS232 26
2.4 PROGRAMVARE 27
2.4.1 CX-PROGRAMMER 27
2.4.2 NB-DESIGNER 34
2.5 FYSISK SIMULERING 38
3. RESULTATER 40
-
5
3.1 SIMULERING I CX-PROGRAMMER 40
3.2 SIMULERING I NB-DESIGNER 40
3.3 SIMULERINGSRIGG 41
3.4 BYGGING AV PROTOTYPE 42
3.5 FERDIG LADDERPROGRAMMERING 44
3.5.1 STARTSEKVENS 47
3.5.2 TRYKKTESTINGSSEKVENS 49
3.5.3 FLUSHESEKVENS 55
3.5.4 LOGGING 58
3.5.5 MATEMATISKE FUNKSJONER 59
3.6 DESIGN AV HMI-BILDER 61
3.7 RESULTATER AV TESTER 67
4. DISKUSJON 69
4.1 TILDELING AV OPPGAVE. 69
4.2 PLS 70
4.2.1 SIEMENS 70
4.2.2 ABB 70
4.2.3 MITSUBISHI 71
4.2.4 MOELLER 71
4.2.5 OMRON 71
4.3 FYSISK SIMULERING 72
4.4 PROGRAMMERING 73
4.5 HMI 73
4.6 SAMMENKOBLING AV HMI OG PLS 74
4.7 HYDRAULIKK 74
4.8 SAMMENKOBLING AV PLS OG SENSORER/AKTUATORER 75
4.9 TESTING 75
-
6
4.10 VIDERE ARBEID 77
5. KONKLUSJON 78
6. REFERANSELISTE FEIL! BOKMERKE ER IKKE DEFINERT.
7. FIGURLISTE 79
-
7
SAMMENDRAG
Denne oppgaven har gått ut på å lage et automatisk system for flushing og trykktesting av
hydraulikkrør. Oppgaven er gitt av NTOS AS avdeling Askøy, og et slikt system vil være med å
effektivisere deres produksjon.
Både NTOS AS og vi, har gjort undersøkelser på om det finnes et tilsvarende produkt på
markedet i dag.
Vi stod fritt til å løse oppgaven slik vi ville, og valgte å gjøre dette ved å kombinere utvalgte
aktuerte hydrauliske komponenter med en programmerbar logisk styring (PLS). Det ble brukt
mye tid på å finne ut hvilket system som ville tilfredsstille kravene i dette prosjektet, og vi
kom frem til et som har fungert meget bra.
Det ble laget utkast til løsning, som ble godkjent før vi fortsatte. Under hele prosjektet har vi
hatt en god dialog med oppdragsgiver for å sikre at vi hadde skjønt problemstillingen, at vi
fokuserte på det som var viktig og at vi brukte reelle verdier.
For å være sikker på at vi ville klare å gjennomføre prosjektet, gjorde vi simuleringer der
dette var mulig. På denne måten kunne vi gjøre prosjektet stegvis, og vi kunne utsette
innkjøp av kostbare komponenter til vi var sikker på gjennomføringen.
Når det hydrauliske systemet var koblet sammen med styringen og vi begynte å kjøre tester,
fikk vi uventede resultater og vi måtte begynne å feilsøke. Dette var meget tidkrevende,
men ved å forhøre oss med forskjellige personer som har god kompetanse innen
trykktesting, fant vi til slutt ut hva som forårsaket de uventede målingene og vi fikk eliminert
dette.
Resultatet av oppgaven er en konklusjon på at det ønskede systemet er mulig å produsere,
og en fungerende prototype som med små modifikasjoner kan tas i bruk på den måten som
var tiltenkt, er laget.
-
8
1. INNLEDNING
Dette kapitelet omhandler erfaringen vi hadde fra tidligere som var grunnlag for å kunne
gjøre denne oppgaven. I tillegg beskrives problemstillingen, og bakgrunnen for denne.
1.1 BAKGRUNN
Erik Hjertholm har gått teknologilinjen som videregående skole. Dette er en kombinasjon av
studiespesialisering med fordypning i realfag, teknikk og industriell produksjon, elektronikk,
elektro og automasjon. Mellom videregående skole og høyskole har han jobbet som
rørlegger, elektriker, tømrer, entreprenør og nanotekniker med mer. Han har hatt
sommerjobb i OneSubsea avdeling Horsøy og Sandsli, og praksisperiode hos NTOS AS
avdeling Ågotnes og OneSubsea avdeling Sandsli.
Robin Sørensen har en bakgrunn fra teknikk og industriell produksjon VG1 og automatisering
ved Bergen Maritime videregående skole VG2 + VG3. Automatisering er en to-årig linje der
lære om PLS, regulering og prosesskontroll er en viktig del av utdanningen. Utenom skolen
har han hatt sommerjobber hos NTOS AS og FMC Technologies siden VG1, der hoveddelen
av arbeidet har omhandlet vedlikehold og drift av hydrauliske systemer.
1.2 PROBLEMSTILLING
NTOS AS har utleie, produksjon og vedlikehold av hydrauliske systemer som hovedgeskjeft.
De er to avdelinger, NTOS Askøy som hovedsaklig driver med produksjon av HPU-er og
ventilpaneler, og NTOS Ågotnes som driver med testing, utleie og vedlikehold, i tillegg til
produksjon av HPU-er. I de fleste tilfeller, er det kundespesifikke krav til trykktest og flushing
av rør på nyproduserte systemer.
For at de skal kunne selge eller leie ut nytt hydraulisk utstyr, må de trykkteste og flushe
utstyret, og da alle de hydrauliske rørene som inngår i systemet.
De aller fleste systemene NTOS AS produserer er kundetilpassede, dermed unike. Det finnes
da ingen standard på hvordan hvert av rørene til disse systemene skal bøyes. Når et rør er
bøyd etter mål, må dette monteres i enheten som bygges for at målene til det neste røret
skal bli korrekt. Man kan alternativt bestille rør til hvert enkelt system, men det krever at
NTOS AS leverer detaljerte 3D-modeller til fabrikant. Disse modellene er meget kostbare å
modelere, og når hvert system krever sin unike modell, vil denne metoden ikke lønne seg.
Figur 1 NTOS sin logo
-
9
På Askøy bygges systemene ferdig, deretter sendes de til Ågotnes hvor alle rørene må
demonteres, merkes og testes. Deretter monteres enhetene sammen igjen etter godkjent
testing. Denne prosessen er mye mer tidkrevende enn den trenger å være, og vår oppgave
har vært å se om det er mulig å lage et system som på en rask og effektiv måte kan
trykkteste og flushe disse hydraulikkrørene fortløpende etter bøying. På denne måten vil
enheten være klar for kunde, straks de er ferdigprodusert på Askøy.
Både NTOS AS og vi, har gjort undersøkelser på om det finnes et tilsvarende produkt på
markedet i dag, men har ikke funnet noe som kan automatisere prosessen på samme måte.
Førsteprioritet i oppgaven ble dermed å vise at en slik løsning er gjennomførbar, og at
systemet lar seg bygge. Dersom tiden tillater det, er det også ønskelig at vi lager en
prototype. Både den hydrauliske biten og styring til dette.
1.3 KRAVSPESIFIKASJON OG DESIGN
I møte med NTOS kom det fram at de hadde ingen krav til hvordan selve designet på
testriggen skulle være. De var mer opptatt av å se om prosjektet i det hele tatt lot seg gjøre,
så alt av design var opp til oss selv å bestemme. Vi ble derimot enig om hvilke krav som
stiltes til selve funksjonaliteten av systemet. Enkelte av kravene var nødvendig for at
systemet i det hele tatt skulle fungere til formålet det var ment for, mens andre krav ville
være praktiske, men hadde en lavere prioritet. Vi delte kravene inn i tre kategorier for å se
hva som først skulle prioriteres: Skal ha, Bør ha og Kan ha.
Kravspesifikasjoner
Skal ha Bør ha Kan ha
Flushe og trykkteste Se pen ut Avstenging/testrom på unit
Automatikk Brukervennlig Flushe akkumulatorer, sjalteventil
Datafangst Servicevennlig Kjøler for oljen
Må måle flow HMI Touch Frekvensstyrt pumpe
Isolere/stabilisere trykk
Måle temperatur
Partikkelteller
Tabell 1 Kravspesifikasjoner for systemet
-
10
1.4 MARKED FOR TRYKKTESTING OG FLUSHING
Stort sett alt av nye hydrauliske systemer og komponenter trykktestes. Dette gjelder ikke
bare offshore-industrien, men også for alle andre industrier i Norge som opererer med
hydraulikk. Her inngår f. eks mobilkraner, lastebiler, gravemaskiner, skipsutstyr etc.
NTOS har tidligere undersøkt om det eksisterer lignende automatiserte løsninger på
markedet i dag, men har per dags dato ikke funnet noen som kan levere et slikt system. I
forbindelse med vår bacheloroppgave kontaktet de også Advantec, som er en bedrift NTOS
har et tett samarbeid med, og presenterte vår oppgave. De var meget interessert i et slikt
system, dersom det lot seg gjøre.
1.4.1 ØKONOMISK PÅVIRKNING
Som beskrevet i problemstillingen tar den nødvendige testingen og sertifiseringen av
hydraulikkrørene til et nytt system mye tid. Et konkret eksempel som ble nevnt var en HPU
(Hydraulic Power Unit) som skulle leveres til OneSubsea. Etter at enheten var ferdig bygget
på avd. Askøy, ble den sendt til avd. Ågotnes for trykktesting, flushing og sertifisering. Her
ble hvert rør merket, demontert, testet og påmontert igjen. Denne prosessen tok to
personer en uke å utføre.
NTOS regner en internkostnad på 350kr i timen, så denne spesifikke jobben kostet bedriften
ca. 26000 kr å utføre. Generelt regner de med at et system som kan trykkteste og flushe
rørene fortløpende under produksjonsprosessen, vil nærmest eliminere tiden brukt på
testing og sertifisering. Dette fører til at den totale produksjonstiden av enhetene vil
reduseres med rundt 10%, som i det lange løp vil representere betydelig
kostnadsbesparelse.
De ser også på muligheten til å kunne kommersialisere et slikt system for salg, ettersom det
ikke eksisterer lignende løsninger i dagens marked.
I dette kapitelet har vi gått gjennom hvilken bakgrunn vi som gjør oppgaven har, hva som
er grunnen til at vi har fått oppgaven og hvilken effekt denne vil ha for oppdragsgiver.
-
11
2. METODE
I denne delen av oppgaven går vi gjennom det teoretiske man må ha kjennskap til for å
forstå hvordan oppgaven er gjort. Det er en kombinasjon av informasjon om komponenter
og forklaring av metoder vi har brukt. Denne delen kan man hoppe over dersom man har
kjennskap til temaene nevnt i forordet.
2.1 TRYKKTESTING
Hydraulisk utstyr blir ofte utsatt for store trykk. Det er derfor viktig å vite at komponentene
vil tåle dette høye trykket, da det ofte er snakk om store mengder energi som kan føre til
material- eller personskader ved en feil. Det hender av og til at det er meget små sprekker
eller hull i materialet som brukes. Mer vanlig er det med feilmontering av
sammenkoblingskomponenten (fitting) på røret. I tillegg vil rør som bøyes få en mindre
veggtykkelse langs ytre radius. På grunn av disse faktorene er det viktig at rørene blir testet
før de blir tas i bruk, for å avdekke eventuelle feil.
Måten testene ofte foregår på, er at det bygges opp et trykk som typisk er 1,5 ganger
arbeidstrykket utstyret er designet for. Dette er dersom utstyret er nytt. Deretter er det en
viss holdetid hvor man overvåker trykkfallet. For at testen skal bli godkjent, er det vanlig at
trykkfallet må være under en gitt prosent i løpet av en gitt tid. Andre typer krav finnes også.
Grunnen til at dette tillates og det ikke er slik at trykket må være konstant hele tiden, er at
et trykksatt system vil bruke en viss tid på å stabilisere seg. Det er flere variabler som spiller
inn, blant annet temperatur og mekanisk utvidelse av systemet. Når olje pumpes gjennom et
hydraulisk system, er det vanlig at denne blir varm på grunn av friksjon i komponenter som
trykkreduksjonsventiler osv. Når man stenger inne trykket og det ikke lenger er noe
strømning, vil temperaturen synke naturlig til den når omgivelsestemperatur.
Avhengig av stivheten på det man tester, vil man også ha varierende grad av utvidelse i
systemet. Disse faktorene regnes med når holdetiden fastsettes fordi de vil inntre selv om
det ikke er lekkasje i systemet. Dersom kravet ikke blir godkjent, er sjansen stor for at noe
må strammes, eller at det faktisk er en feil på komponenten.
Da væsker i svært liten grad lar seg komprimere, fyller man ofte det som skal testes med
væske, såkalt hydrostatisk testing. Dette har blant annet med sikkerhet å gjøre, da det
utløses meget lite energi dersom testobjektet sprekker, sammenlignet med for eksempel
luft eller gass. Har man et helt stivt rør, som testes med vann, vil trykket falle drastisk om
man plutselig fjerner bare en liten del av vannet. Til sammenligning komprimerer luft seg én
gang per bar man øker trykket. Det vil si at hvis et luftfylt rør med 200 bars trykk sprekker, vil
200 ganger rørets volum bli frigitt. Et rør trykksatt med luft, er i praksis akkurat det samme
som en akkumulator, som lagrer energi.
-
12
2.2 FLUSHING
Flushing er en prosess hvor man renser rør, slanger eller annet lignende utstyr ved å
sirkulere væske gjennom dem. Man kobler sammen pumpe og testobjekt i en sløyfe hvor det
også er et eller flere filter, som vil fange opp urenheter. Denne prosessen kjører man helt til
ønsket renhet er oppnådd.
Figur 2 Prinsipp for flushing
Renheten i væsken betegnes med standarder hvor noen av de mest brukte er [NAS1638]1 og
[ISO4406-1999]2. Disse standarder angir hvor mange partikler av en viss størrelse man vil
finne i en gitt mengde vann, med et dimensjonløst tall (klasse). Vi har brukt [NAS1638], da
dette er den vanligste i offshoreindustrien. Når det gjelder denne standarden er det
forskjellige krav for tillatt antall partikler i forskjellige størrelsesorden i en og samme NAS-
klasse, men alle kravene må tilfredsstilles for at man skal kunne si at en væske har en renhet
tilsvarende den aktuelle klassen. Under er et skjema som viser minstekravene for de
forskjellige NAS-klassene.
Figur 3 Oversikt over NAS-klasser
-
13
2.2.1 REYNOLDS TALL
Reynolds tall (Re) er dimensjonsløst, og beskriver blant annet om et fluid strømmer laminært
eller turbulent. Områder på skalaen for Reynolds tall brukes for å beskrive de forskjellige
typer strømminger.
Laminær Re < 2300
Transient 2300 < Re < 4000
Turbulent Re > 40003
Figur 5 Illustrasjon mellom forskjellen på laminer og turbulent strømning. Pilene illustrerer bevegelsen til fluidpartiklene.
2.2.2 TURBULENT FLOW
Ved flushing ønsker man turbulent strømning da en slik strømning vil rive med seg mye mer
av det som måtte være av urenheter festet på innsiden i røret eller slangen, enn dersom
strømningen var laminær. Dersom en kunde ønsker sertifikat på utførelsen av flushingen, vil
det at strømningen har vært turbulent, være en av tingene de ønsker å se i tillegg til at
ønsket renhet er oppnådd. Om man oppnår turbulent strømning eller ikke avhenger av flere
faktorer, blant annet strømningshastighet, viskositet og diameter på røret som skal testes.
Derfor er det vanlig at man må regne seg frem til en minimums hastighet. Denne vil være
spesifikk for hvert system. Ved å kjøre pumpen med maksimal strømming, vil vi sikre at man
er i det turbulente området, gitt at pumpen er spesifisert korrekt. Dette vil i tillegg gjøre
styringen enklere.
Re Reynolds tall
ρ Densistet
V Snitthastighet
D Diameter
µ Dynamisk viskositet
Figur 4 Formel for
Reynolds tall
-
14
2.3 SYSTEM
GENERELT
Vårt system er designet slik at man kan koble til det man ønsker å teste med hurtigkoblinger,
deretter velger man på et touchpanel om man vil trykkteste og flushe, bare trykkteste eller
bare flushe. Man velger hvilken standard testen, og eller flushingen skal utføres etter, og
trykker så på start. Etter dette blir røret testet og eller flushet etter krav, for så å bli tømt
ved bruk av ren luft. Under hele prosessen vil man kunne se på touchpanelet hvilket steg i
prosessen man er på, og en lampe vil lyse grønt når det er klart for neste test.
2.3.1 HYDRAULISK SYSTEM
Under er forenklet prinsipp for hva som skjer med de forskjellige komponentene i trinnene
ved en trykktest og flushing. Dette er etter alle nødvendige valg er gjort på HMI-et.
1: Ventil 8 er åpen, og 3-veisventil 5 er åpen mot tank.
2: Pumpen startes og kjører en gitt tid for å sørge for at det er olje i hele systemet.
3: Stengeventil 8 lukkes.
4: Pådraget på pumpen settes til testtrykk og stoppes når ønsket trykk er oppnådd.
5: Systemet får hvile en gitt tid for stabilisering.
6: Etter en gitt tid, eller etter et gitt trykkfall, startes pumpen og kjører til trykket
igjen er lik set-trykk.
7: Logging starter og går helt til testen enten blir godkjent eller prosessen blir
stoppet av en timeout. Da er det mest sannsynlig en lekkasje.
8: Dersom trykktest blir godkjent, åpner stengeventil 8, og pumpen starter igjen.
Flushingen er nå begynt og denne gangen går pumpen til oljens renhet er under set-
nivået, eller til systemet stoppes av en timeout. Da er det sannsynlig at filteret må
byttes.
9: Dersom flushingen blir godkjent stopper pumpen og 3-veisventil 5 åpnes mot
spilltank.
10: Luftventilen 4 åpner i en gitt tid slik at det meste av oljen i slanger og testobjekt
fjernes.
11: Et grønt lys skrus på for å signalisere at prosessen er ferdig, og man får opp en
melding på HMI-et.
-
15
-
16
2.3.1.1 FITTINGS
Komponenter til hydrauliske systemer (pumper, ventiler, sylindere etc.) trenger en måte å
kobles sammen på. I de fleste tilfeller brukes rør eller slanger til å føre oljen til de ulike
komponentene. Hver komponent har inngang- og utgangsporter som er dimensjonert i
forhold til hvor stor den anbefalte oljestrømmen er.
Det finnes en rekke ulike standardiserte metoder på hvordan hydraulikkrør, slanger og
komponenter skal kobles sammen. Disse standardene har gjerne ulike formål. Noen er laget
for å være så tett så mulig mens andre er servicevennlig, skal tåle høye trykk etc. Eksempler
på mye brukte fitting-typer er: BSP, NPT, A-LOK, JIC, EO-2 med flere.
Fitting er en samlebetegnelse på komponenter som blant annet
- Kobler sammen to porter med ulik eller lik størrelse.
- Forgrener hydraulikkretsen ved bruk av T-stykker.
- Kobler sammen to forskjellige typer, for eksempel BSP
og A-LOK.
- Forandrer orienteringen på komponenter, for
eksempel ved å bruke en 90O vinkel.
Vi har i hovedsak brukt Parker EO-2 og BSP på vårt system.
Grunnen til dette er at NTOS lagerfører Parker fittings, og det var da et naturlig valg å bruke
disse.
Figur 6 Hydraulisk koblingsskjema for systemet
Figur 7 Diverse fittings
Figur 9 BSP fittings Figur 8 Parker EO-2 fittings
-
17
2.3.2 SENSORER
Her har vi forklart prinsippene for de forskjellige sensorene vi har brukt i dette prosjektet. Vi
har ikke gjort noe vurdering i forbindelse med valg av disse, men fikk dem utlevert av NTOS.
2.3.2.1 FLOWMETER
Flow kan måles på mange forskjellige måter. Det finnes flere måleprinsipper i blant annet
kategoriene mekanisk, trykkbasert, termisk, elektromagnetisk og ultrasonisk. Flowmeteret vi
bruker, SCFT-060-22-074, er et turbinflowmeter. Dette kommer under kategorien mekanisk.
Måleprinsippet går ut på at når oljen strømmer gjennom turbinmeteret, vil en propell
(turbin rotor) begynne å rotere. Denne rotasjonen er proporsjonal med oljemengden som
strømmer gjennom, og man vil måle volumstrøm. En magnetisk sensor registrerer
rotasjonshastigheten til propellen, og i en signalomformer blir dette omgjort til et 4-20 mA
signal.
Figur 10 Prinsippet for et turbinmeter
Sensoren vi bruker har følgende data:
Flowmeter - Parker SCFT-060-22-07 Måleelement Turbinmeter
Supply Voltage 24 VDC
Range 3 - 60 l/min
Output 4 - 20 mA
Max Arbeidstrykk 420 bar
Tabell 2 Utdrag av spesifikasjoner for flowmeteret
-
18
2.3.2.2 TEMPERATUR
Det finnes flere forskjellige prinsipper for å måle temperatur. Deriblant termoelement,
termistor, bimetall og resistanstermometer. Sensoren vi har brukt i vårt system, Parker SCT-
150-14-005 har et resistanstermometer av typen PT1000. Dette er en liten bit med platina,
som har en motstand på 1000 Ω ved 0 grader celsius. Motstanden endrer seg tilnærmet
lineært med temperaturendringer, og det er denne motstanden sensoren måler. En
signalomformer i sensoren omgjør denne endringen til et 4-20 mA signal, og en intern
motstand på 250 Ω gjør at man kan få signalet som 1-5 V dersom man ønsker dette.
Tilsvarende kan man få PT100 som har en motstand på 100 Ω ved 0 grader og PT500 som
har 500 Ω ved 0 grader. Fordelen med å bruke et PT1000 element er at man får høyere
sensitivitet, samt bedre respons og repeterbarhet.
Figur 11 Temperatursensor, Parker SCTSD
Sensoren vi bruker har følgende data:
Temperatursensor - Parker SCT-150-14-00 Måleelement PT1000
Supply Voltage 24 VDC
Range -15…+125 o C
Output 4 - 20 mA / 1 - 5 V
Max Arbeidstrykk 630 bar
Tabell 3 Utdrag av spesifikasjoner for temperatursensoren
-
19
2.3.2.3 TRYKKSENSOR
Noen av de vanligste måleprinsippene for trykk er membran, bourbonrør, piezoelektrisk og
piezoresistiv. Det er også ulike måter å presentere trykket på. De to mest brukte metodene
er absolutt trykk som er trykket målt i forhold til
vakuum, og relativt trykk (gauge) som måler trykket i
forhold til atmosfæretrykket. SI-enheten til trykk er
pascal (Pa). I industrien blir MPa, bar og psi brukt. 1 bar
= 105 Pa = 14,50 psi.
Figur 12 Forskjellen på absolutt trykk og relativt
trykk vist grafisk
Sensoren vi bruker til å måle trykket i systemet, er en Parker SCP-400-14-176, denne har et
piezoresistivt måleelement, og måler relativt trykk i bar. Et piezoresistivt element kan bestå
av en halvleder eller metall, som endrer motstand når det blir utsatt for en mekanisk
deformasjon. Når dette elementet i sensoren blir utsatt for et hydraulisk trykk vil det få en
liten deformering, som da fører til en endring i resistansen. På samme måte som i
temperatursensoren måles denne endringen, og blir omgjort til et signal på 4-20 mA.
Denne sensoren har også mulighet for å gi I/O signaler (kontakter som aktiveres, enten
normal open eller normal closed), dersom trykket går over eller under en satt verdi. Dette er
dog ikke en funksjon vi benytter oss av.
Denne sensoren har følgende data:
Trykksensor - Parker SCPSD-400-14-17 Måleelement Piezoresistant
Supply Voltage 24 VDC
Range 0 - 400 bar
Output 4 - 20 mA
Max Arbeidstrykk 400 bar
Tabell 4 Utdrag av spesifikasjoner for trykksensoren
Figur 13 Parker
SCPSD trykksensor
-
20
2.3.2.4 PARTIKKELTELLER
Partikkeltellere er instrumenter som detekterer og teller antall partikler i mediet man
overvåker. I motsetning til de andre sensorene beskrevet over, er det færre måleprinsipper
for partikkeldeteksjon. Det er hovedsaklig tre prinsipper som brukes, og disse er light
blocking (obscuration), light scattering og direct imaging.7
icountPD123221008 er sensoren vi har brukt til å overvåke renheten i oljen. Den benytter
seg av en kombinasjon av light scattering og direct imaging. Enkelt forklart er det en laser
som lyser gjennom oljen, og en fotocelle i motsatt ende som detekterer skyggen av
partikkelen og hvordan lyset har spredt seg. Ved hjelp av en algoritme regner enheten ut
gjennomsnittlig diameter på hver partikkel som passerer. Disse blir så klassifisert i henhold
til tabellverdier for NAS-klasse (figur 3) eller ISO-klasse, og blir representert i form av et 4-20
mA signal.
Denne sensoren har følgende data:
Partikkelteller - Parker icountPD 12322100 Supply Voltage 24 VDC
Signal Supply 12 VDC
Output 4 - 20 mA
Arbeidstrykk 2 - 420 bar
Tabell 5 Utdrag av spesifikasjoner for partikkeltelleren
Figur 14 Prinsippet light scattering
-
21
2.3.3 VENTILER
En ventil er en innretning som regulerer, styrer eller kontrollerer strømningen til et fluid. De
kommer i alle slags “farger og fasonger”, og konstruksjonen varierer veldig avhengig av
bruksformål. Vi bruker i hovedsak tre ulike typer; tilbakeslagsventil, 3-veis ventil og
seteventil.
2.3.3.1 TILBAKESLAGSVENTILER
En tilbakeslagsventil, er en enkel konstruksjon som sørger for at oljen bare kan passere en
vei. Tilbakeslagsventilene som er montert i vårt system er mye brukt, og er bygget opp av en
fjærbelastet kule som hviler mot en myk tetning. Når trykket mot kulen overstiger
fjærkraften, blir kulen løftet fra tetningsflaten, og ventilen åpner for gjennomstrømming.
Dersom oljen prøver å passere andre veien, vil det føre til at kulen blir trykket hardere mot
tetningsflaten, og man får da ingen gjennomstrømning.
Figur 15 Prinsippet for en tilbakeslagsventil
I vårt system bruker vi tilbakeslagsventiler for å sørge for at trykket ikke evakuerer ut på
trykksiden av systemet under trykktesten, samt hindre at det slipper olje inn til luftventilen.
Figur 16 En typisk tilbakeslagsventil
-
22
2.3.3.2 3-VEIS VENTIL
En 3-veis ventil er en ventil som har et fast løp, og to variable løp. Avhengig av hvordan
ventilen opereres, er løpet åpent fra det faste løpet til et av de to variable. Den vanligste
formen for 3-veis ventiler er 3-veis kuleventil.
Figur 17 Treveis kuleventil forklart grafisk
2.3.3.3 SETEVENTILER
Prinsippet for en seteventil er at man har et sete (3) som presses mot en tettningsflate.
Ventilen på bildet er en med stigende spindel, men den vi bruker er aktuert med en
elektromagnet (coil). Vi bruker en seteventil for å stenge inne trykket på retursiden av
systemet.
Figur 18 Prinsippet for en seteventil
-
23
2.3.4 PLS
En PLS (programmerbar logisk styring) er en av de vanligste metodene industrien bruker for
styring av systemer, prosesser etc. Der man før måtte bruke store mengder reléer, kan man
nå klare seg med én PLS. En PLS får gjerne digitale og eller analoge inputs, og gir output ut
ifra gitte regler som man programmerer, basert på inputene. Disse outputs fungerer ofte
som styrestrøm for annet elektrisk utstyr som kontaktorer, motorer osv. Når en PLS skal
programmeres, brukes forskjellige språk avhengig produsent og modell. En vanlig metode
innen programmering er ladder-programmering. Dette er en av metodene som brukes av
Omron, systemet vi har valgt.
Figur 19 Slik ser en typisk PLS ut
2.3.4.1 FORKLARING AV MINNET I EN PLS
Når man jobber med programmering av PLS-er, er det veldig ofte slik at man må manipulere
input-verdier. For at dette skal være mulig, må man ha et sted å mellomlagre disse verdiene.
Dette skjer i minnet til PLS-en.
Minnet i en Omron PLS er bygget opp av flere deler som har forskjellige egenskaper. Hver
del har et gitt antall “WORD” som igjen er delt opp i 16 bit. En bit kan bare ha 2 verdier, 1
eller 0. Mens et WORD som består av 16 bits, kan da ha 216 = 65536 forskjellige verdier. Hver
enkelt bit og WORD har sin unike adresse og er henholdsvis på formen AX.XX for bits og AX
for WORD. Her er A navnet på minneområdet og X et tall. For eksempel inneholder WORD-et
A1 alle bit-ene fra A1.00 til A1.15. Adressen A1.16 finnes da altså ikke. Refererer man til A1 i
en funksjon, får man da den heksadesimale verdien de 16 binære sifrene i A1 representerer.
Man kan referere til verdien i et helt WORD, samtidig som man en annen plass refererer til
et enkelt bit i det samme WORD-et.
-
24
Figur 20 Skjermbilde av minnet til PLS-en I CX-programmer
I vårt prosjekt har vi for det meste brukt bits til å registrere verdier som enten er sanne eller
usanne, såkalte boolske verdier som for eksempel om sekvens kjører eller ikke. WORD er
brukt der vi har lagret analoge verdier, for eksempel input fra sensorer.
2.3.4.2 FORSKJELLIGE TYPER VERDIER
Når man programmerer for å gjøre forskjellige operasjoner med et tall, må man definere hva
slags tall det er man jobber med. Til dette er det forskjellige kategorier som begrenser hva
man kan bruke av input. Disse kategoriene er standard innen de fleste
programmeringsspråk, men hvor store tall de kan inneholde, kan variere.
2.3.4.2.1 INTEGER
En 16-bit integer, som denne PLS-en støtter, kan være negativ eller positiv, og verdiene fra -
32768 til 32767. En integer kan ikke ha desimaler.9
2.3.4.2.2 UNSIGNED INTEGER
En 16-bit unsignet integer kan bare være positiv, og går fra verdien 0 til 65535. En unsigned
integer kan ikke ha desimaler.10
2.3.4.2.3 FLOAT
Float er et tall med desimaler, som kan gå fra -3,4028235 x 1038 til 3,4028235 x 1038. 11
-
25
2.3.4.3 OMRON CJ2M
Valget av PLS havnet på Omron sin CJ2M12. Denne er en del av Omron sin modulære PLS-
serie. Her står man fritt til å velge hvilke tilleggsmoduler man vil ha, alt ettersom hva man
trenger. Man kan blant annet velge mellom forskjelle strømforsyninger 24VDC og 230 VAC,
kommunikasjonsmoduler Profibus, DeviceNet, Ethernet/IP etc. digitale Input- og
outputmoduler med forskjellig antall innganger/utganger, analoge input- og outputmoduler.
Tabell med oversikt over hvilke komponenter PLS-systemet vår bruker:
Enhet Modul Funksjoner
PLS CJ2M-CPU11 USB, RS-232, Compact Flash Minnekort
Strømforsyning CJ1W-PA202 230 VAC, 2.8A
Digital Input CJ1W-ID211 16 x Inputs, 24 V
Digital Output CJ1W-OD211 16 x Outputs, 24 V
Analog Input/Output CJ1W-MAD42 4 x Inputs, 2 x Outputs, 1-5 V/0-5 V/0-10 V/-10-10 V/4-20 mA
Tabell 6 Oversikt over PLS og tilhørende moduler13
Figur 21 Omron modulær-PLS CJ2M-CPU11
-
26
2.3.5 HMI
HMI står for Human Machine Interface, og er enkelt forklart “koblingen” mellom menneske
og maskin. Det er i praksis det man bruker for å styre en maskin eller gi den en kommando. I
en bil vil dette for eksempel være ratt, pedaler og
girstang.
Når det er snakk om automasjon, er et HMI gjerne
noe som skal skru av og på motorer, starte og
stoppe sekvenser osv. Det kan gjerne være et panel
med knapper, men i vårt tilfelle er det en skjerm
med berøringsfunksjon. Dette gir en veldig stor grad
av fleksibilitet da man har mange funksjoner som
ikke er mulig å få til med knapper og man kan gi
bruker av systemet tilbakemelding på en veldig
effektiv måte. Modellen av HMI vi har brukt heter
NBQ5-TW01B14 og er en del av kompaktserien til
Omron.
2.3.6 RS-232
RS-232 er en standard for overføring av data som første gang ble laget i 1962. Siden har den
hatt mange revisjoner og brukes fremdeles i store deler av industrien både på grunn av at
den er godt innarbeidet, men også fordi den er stabil. RS-232 benytter DB9-kontakten.
Denne kabelen var originalt ment til å være mellom telefonmodem og teleprintere, men
brukes i dag i en mengde forskjellige applikasjoner. Anbefalt maks lengde er 15 meter, og
konfigurasjon av hvordan pinnene er koblet sammen varierer. For at kommunikasjonen skal
fungere mellom den aktuelle PLS og HMI vi har valgt, må den være slik som på illustrasjonen
under. PLS-siden er til høyre.
Figur 22 NBQ5-TW01B
Figur 23 DB9 kontakt
-
27
Figur 24 Konfigurasjon for kommunikasjon mellom PLS og HMI15
2.4 PROGRAMVARE
For å kunne programmere PLS-en trenger man tilhørende programvare. Her har ofte hver
leverandør utviklet sin egen software, som man må kjøpe utenom selve PLS-en. Det finnes
dog enkelte PLS-er der man kan gjøre en veldig enkel programmering på selve PLS-en,
eksempelvis Möeller sin Easy-serie.
2.4.1 CX-PROGRAMMER
Vårt valg av PLS havnet som sagt på Omron.
De har utviklet et program som heter CX-
programmer. Inntrykket vi har fått av dette
programmet er at det er et kraftig verktøy,
som man kan lage ganske avanserte
programmer med, samtidig som det er
veldig brukervennlig og har mange smarte
løsninger. Man er ikke begrenset til et fast
programmeringsspråk, men kan velge
mellom blant annet Ladder Diagram (LD),
Structured Text (ST) og Sequential Function
Chart (SFT). Ladder Diagram blir gjerne sett
på som det enkleste av disse tre språkene.
Det er også godt egnet til å lage
sekvensprogrammer, så vi fant det hensiktsmessig å skrive vårt program i dette språket.
Figur 25 Skjermbilde CX-programmer
-
28
2.4.1.1 LADDER DIAGRAM
Figur 26 Ladder diagram
Ladder diagram er en vanlig måte å programmere en PLS på. Enkelt forklart fungerer det slik
at det er et signal som ”vil” fra venstre til høyre i hvert trinn i det som ligner på en stige,
derav navnet. Dette skjer bare dersom det er kontakt hele veien fra venstre til høyre i det
aktuelle trinnet. Det er i hovedsak to forskjellige typer komponenter man kan bruke i
programmeringen. Enten åpner eller stenger en komponent for signalet, eller så aktiveres en
funksjon når signalet når frem til denne. Man kan si de enten er i kategorien ”bryter” eller
”lampe”. Rekkefølgen på trinnene har ingenting å si, da signalet hele tiden er på, på venstre
side av ”stigen”.
Det som kanskje ikke er så lett å forstå med dette, er at komponentene i kategorien ”lampe”
kan gjøre flere ting. De kan enten aktivere en fysisk utgang, slik at en lampe lyser, eller en
motor starter, eller så kan den aktivere et bit i minnet på PLS-en. Denne bit-en kan igjen
være koblet til en bryter som da vil lukke. Ved å bruke kombinasjoner av komponenter i
disse to kategoriene, kan man bygge opp kraftige funksjoner som tar et input signal,
prosesserer dette og gir et ønske output basert på input signalet. Funksjonene hver for seg
er ikke spesielt kompliserte å forstå, men å forstå helheten i et ferdig program kan være
utfordrende for personer som ikke har kjennskap til ladder programmering.
BESKRIVELSE AV KOMPONENTER
Her vil vi gå litt nærmere inn på virkemåten til hver av funksjonene vi har brukt. Dette er for
å bedre kunne forstå koden i programmet vi har laget for styring av systemet.
NORMALY OPEN:
Kan ses på som en ”bryter”. Denne vil slippe gjennom signalet når den blir
aktivert. Tilsvarende når korresponderende bit i minnet er ”1”.
NORMALY CLOSED:
Kan også ses på som en ”bryter”, men denne er invertert. Det vil si at den
slipper gjennom signalet når den ikke er aktivert.
-
29
COIL:
Kan ses på som et ”lys”. Når alle kriteriene for at ”bryterne” skal slippe
gjennom signalet, kommer signalet fram til coilen, og den aktiveres. Dette kan
for eksempel være et lys som blir aktivert, eller en motor som blir startet.
Coilen står alltid som siste ledd i en ”signalkrets”.
EKSEMPEL:
Figur 27 Eksempel på normaly open, normaly closed og coil
Dette er en enkel funksjon for å starte en motor. Hvis man tenker seg at Bryter_1 og
Bryter_2 ” er lysbrytere, vil Motor starte når Bryter_1 blir slått på, og Bryter_2 er slått av.
Slår man eksempelvis på Bryter_2 brytes signalet, ettersom denne er invertert. Motoren vil
da stoppe, selv om begge bryterne står ”fysisk på”.
GENERELL FORKLARING AV EN FUNKSJONSBLOKK
I stedet for coiler som bare har funksjonen av eller på (1/0), kan man bruke
funksjonsblokker. Disse har en mer avansert funksjon, og kan blant annet brukes til å
behandle analoge signaler, tallmanipulasjon, nedtellinger etc. De spesifikke
funksjonsblokkene vi har brukt i programmet er beskrevet under.
SET:
Når Bryter _1 blir aktivert, aktiverer denne funksjonen et spesifisert bit i minnet. Eventuelt
aktiverer den en utgang. I dette eksempelet aktiverer funksjonen en utgang som koblet til
motor. Dersom denne allerede er aktivert skjer det ingenting.
Figur 28 Eksempel for SET funksjonen
-
30
RSET:
Rset eller Reset gjør det motsatte av Set. Når Bryter_2 blir aktivert, deaktiverer denne et
spesifisert bit i minnet. I dette eksempelet vil den da slå av Motor dersom denne er aktivert.
Figur 29 Eksempel for RSET funksjonen
MOV:
Når Bryter_1 blir aktivert, vil denne funksjonen flytte den gitte verdien til et bestemt minne.
I dette eksempelet vil den flytte det heksadesimale tallet FFFF til minnet D0. Man kan også
sette denne funksjonen til å flytte verdien fra analoge innganger.
Figur 30 Eksempel på MOV funksjonen
TIM:
Tim eller timer er en funksjonsblokk som starter en nedtelling når den blir aktivert. Den
teller ned 0.1s i forhold til set verdien. Når nedtellingen er ferdig, vil den aktivere en bit med
samme adresse som timeren har. I dette eksempelet vil timeren bli aktivert når Bryter_1 blir
aktivert. Etter 5 sekunder vil timeren bli aktivert.
Figur 31 Eksempel på TIM funksjonen
-
31
CNT:
CNT eller ”counter” er en funksjon som teller hvor mange ganger et bit i minnet har blitt
aktivert. Når antallet aktiveringer er lik det man har har som settverdi, aktiveres funksjonen.
Den har også en input som resetter counteren. I dette eksempelet vil counteren aktiveres
når Bryter _1 har blitt aktivert tre ganger, og reset når Bryter_2 blir aktivert.
Figur 32 Eksempel på CNT funksjonen
BSET:
Bset eller block set kopierer et WORD man har satt til området i minnet man definerer. I
dette eksempelet vil funksjonen sette minnet fra D1 til D10 til den heksadesimale verdien
FF. I vårt program brukes denne funksjonen til å sette hele minneområdet som er reservert
for logging til 0. Dette må gjøres for at ikke verdier fra forrige logging skal ligge igjen i
minnet.
Figur 33 Eksempel på BSET funksjonen
FLT:
FLT eller ”16 bit to floating point” konverterer en 16 bit binær verdi til floating point data.
Som nevnt tidligere er dette verdier som kan inneholde desimalverdier. I dette eksempelet
vil funksjonen konvertere den heksadesimale verdien F til 15,000000, og plassere denne
verdien i minnet D0. I vårt program bruker vi dette for å kunne regne ut trykkfallet, ettersom
dette er nøyaktige verdier som inneholder desimaler.
Figur 34 Eksempel på FLT funksjonen
-
32
>:
> eller ”greater than” ser om verdien i en adresse i minnet er større enn det man har satt.
Når dette er tilfellet vil den aktiveres. I dette eksempelet vil Motor bli slått av når Trykket er
større enn 400.
Figur 35 Eksempel på > funksjonen
F
>F eller ”floating point greater then” har samme funksjon som ”greater than”, bare at denne
funksjonen ser på forskjellen til verdiene i floating point. Altså kan den sammenligne tall
med med desimalverdier.
/F
/F eller ”floating point divide” dividerer to verdier av typen floating point. I dette eksempelet
vil funksjonen dele 15 på 2 og flytte resultatet 7,5 til minnet D1 når Bryter_1 blir aktivert.
Figur 36 Eksempel på /F funksjonen
+
+ eller ”signed binary add” legger til en spesifisert verdi til et bestemt minne.
-
- eller "signed binary subtract” trekker fra en spesifisert verdi fra et bestemt minne.
-
33
*
* eller ”signed binary multiply” multipliserer en et bestemt minne med en spesifisert verdi.
@WSFT
@WSFT eller ”Word shift register” flytter WORD fra et bestemt minne nedover i et register
(minneområde) man har definert, hver gang funksjonen blir aktivert. Når registeret er fylt
opp vil den nederste (eldste) verdien bli overskrevet. Dette kan enkelt sammenlignes med at
man har et rør fylt med klinkekuler. Når man putter inn en ny klinkekule vil hele rekken flytte
seg et hakk, og den første klinkekulen man puttet inn vil falle ut i andre enden. Denne
funksjonen bruker vi i vårt program for logging, og kunne kontinuerlig overvåke trykkfallet
de siste X minutter.
FWRIT
FWRIT eller ”data file write” er en funksjon som brukes for å lagre data i bestemte filformat
til compact flash minnekortet i PLS-en. Her er det en rekke parametere man må bestemme:
filtype, antall linjeskift, overskriving/skrive videre på samme fil, hvor filen skal lagres, hvor
mange linjer i minnet som skal lagres, filnavn og hvor i minnet den skal lagre data fra. For
nærmere beskrivelse av disse parametrene, se
http://www.myomron.com/index.php?action=kb&article=1564. I dette eksempelet har vi
satt verdien i minnet D100 til F og verdien i D50 til 5C50. Funksjonen vil da lagre en .CSV fil til
minnekortet med filnavnet ”P”, med verdiene i minnet fra D0 til D14 (F16 = 1510).
Figur 37 Eksempel på FWRIT funksjonen
http://www.myomron.com/index.php?action=kb&article=1564
-
34
EKSEMPEL:
Her er et lite eksempel på hvordan man kan kombinere ulike funksjonsblokker for å få en
logisk funksjon.
Figur 38 Eksempel på programmering med funksjonsblokker
Dette er et enkelt program for styring av en motor. Når man aktiverer Bryter_1 vil timeren
starte å telle ned. Etter fem sekunder, vil T0001 (det bit-et timeren er tildelt til å aktivere) bli
aktivert. Motoren vil da starte og gå, helt til man aktiverer Bryter_2 som slår av motoren.16
2.4.2 NB-DESIGNER
HMI-et vi har brukt, krever programmet NB-
designer for å konfigureres. I dette programmet
designes alle menyer og vinduer, og det bygges opp
en logisk sammenheng mellom disse. Resulatet kan
minne om oppsettet i en vanlig DVD-meny. Man kan
også importere grafikk fra andre kilder. I tillegg
bestemmer man hvordan styringen av PLS-en skal
foregå. HMI-et kan redigere både bits og words
direkte i minnet på PLS-en. På denne måten får man
registrert hvilke valg som er gjort av operatør, og
PLS-en velger hvilken del av koden som skal kjøres,
og ikke minst hvordan. Samtidig leser HMI-et
nøkkeltall og presenterer disse på skjermen.
Et flytskjema over hvordan sammenhengen mellom
de forskjellige skjermene er bygget opp, er på neste side. Her er navigeringen bygget opp slik
at man alltid kan gå tilbake oppover, men ikke sideveis. Dette sikrer blant annet at valgt
meny alltid korresponderer med de valgene som er gjort.
Figur 39 Skjermbilde NB-designer
-
35
2.4.2.2 Grafikk
Figur 40 Flytskjema HMI bilder
-
36
2.4.2.1 GRAFIKK
Når man designer det grafiske til knapper og komponenter, er det vanlig å lage to versjoner.
Et hovedbilde og et bilde for når komponenten er aktivert. Dette for at de som bruker
systemet skal få tilbakemelding på valgene man foretar seg. Dette kan også utnyttes til å vise
forskjellige statuser avhengig av hvor langt man har kommet i et program. De aller fleste
komponentene har en grafisk komponent, og størrelsen på denne avgjøre også
triggerområdet på displayet.
2.4.2.2 KOMPONENTER BRUKT I VÅRT PROSJEKT
Under følger beskrivelse av hver enkel komponent som er benyttet i
programmeringen av HMI-et.
SCREEN
De forskjellige menyene har sin egen “screen”. Disse har sitt eget nummer som kan
refereres til i andre komponenter for å bytte mellom skjermer. I NB-designer er det
ferdiglagde skjermer som numerisk tastatur, men utenom dette har vi designet alle skjermer
selv.
BIT LAMP
En bit lamp kan sammenlignes med en lampe og viser en av sine to grafiske
versjoner (states) avhengig av om den valgte addressen har verdien 1 eller 0.
Denne har også funksjoner som blinking til alarmer osv. Denne komponenten
er passiv og forandrer ingenting i PLS-en.
BIT SWITCH
En bit switch er det nærmeste man kommer en knapp og setter en addresse
i HMI-et eller PLS-en til å være 0 eller 1 alt ettersom hvilke innstillinger man
velger. Den kan; alltid sette en addresse til å være 1 eller 0, bytte mellom de
verdiene eller fungere som pulsbryter.
Figure 1 Grafiske versjoner Figur 41 Grafiske versjoner
-
37
FUNCTION KEY
Denne har flere funksjoner som å starte kalibrering, men brukes i dette
prosjektet bare til å bytte mellom skjermer (screens).
COMMAND BUTTON
En command button kan gjøre forskjellige matematiske funksjoner med
numerisk input og words i PLS-en. Det vi bruker den til er å sette ikke-boolske
verdier til spesifiserte plasseringer i minnet. Hadde verdien vært boolsk,
hadde man brukt en bitswitch.
MULTI FUNCTION
En multifunction har en liste med kommandoer som den utfører i listens
rekkefølge. Den kan både sette eller resete enkle bit samt sette ikke-
boolske verdier til valgte words. Denne er kort forklart en kombinasjon av
en eller flere bit switch og eller command buttons.
NUMBER DISPLAY
Dette er en passiv komponent som viser den numeriske verdien i et spesifisert
word.
NUMBER INPUT
Denne komponenten er aktiv, og setter verdier direkte til en spesifisert
plassering i minnet samtidig som den viser verdien som er satt. Den
aktiverer det numeriske tastaturet automatisk når man trykker på den, og
sender valgt verdi til minnet når man trykker enter. Man har mulighet til å
begrense maks og minimumsverdier, og gir en feilmelding dersom man velger et tall utenfor
dette området. Denne kan sende verdier til ett word men vise verdien til et annet dersom
dette er ønskelig.
DIRECT SCREEN
Dette er et område med definert størrelse som viser en spesifisert skjerm
(screen) når, og bare når et valgt bit har verdien 1. Dette er ekvivalent
med en popup-skjerm.
-
38
INDIRECT SCREEN
Denne fungerer på samme måte som en direct screen, men den viser skjerm
nummer x avhengig av hvilken verdi en spesifisert adresse har. Dette gjør at
man har muligheten til å vise mange forskjellige vinduer, som forskjellige
typer feilmeldinger, med bare én komponent.
17
2.5 FYSISK SIMULERING
Vi har simulert systemet fysisk og forklaringen på hvordan dette er gjort beskrives i dette
kapitlet. Komponentene vi skulle bruke oppfører seg på fire forskjellige måter med tanke på
hvordan de fungere elektrisk. Under er en liste med alle komponentene i systemet og
hvilken metode vi brukte for å simulere dem.
Komponenter som skal være av eller på (24 VDC). Simulert ved hjelp av 24 volts LED-lys i
forskjellige farger. Disse er koblet direkte til den digitale outputmodulen.
Indikatorlys Sterkstrøm til motor Stengeventil 3-veis ventil Luftventil
Inngangssignal av eller på (24 VDC). Simulert med pulsbrytere. Disse er koblet direkte til
den digitale inputmodulen.
Alle brytere
Analoge utgangssignaler (0 – 10 VDC). Simulert med analogt voltmeter. Denne er koblet
direkte til den analoge outputmodulen.
Styring av motor
Analoge inputsignaler (0-10 VDC). Simulert med potensiometre. Koblingene her er vist på
koblingsskjema under. Signalet fra potensiometeret er koblet til den analoge
inputmodulen.
Temperatursensor Flowmeter Trykksensor Partikkelteller
-
39
Figur 42 Koblingsskjema simulering av sensorer
Som koblingsskjemaet viser, er alle sensorer simulert ved hjelp av fire spenningsdelere
koblet i parallell. En spenningsdeler fungerer slik at spenningen over komponentene fordeler
seg avhengig av størrelsen på forholdet mellom motstandene i spenningsdeleren. Dersom
den ene motstanden er dobbel så stor som den andre, er spenningen over denne dobbelt så
stor. Den ene mostanden er fast, mens den andre er variabel. Dette er de forskjellige
potensiometerne som skal representere sensorene. Størrelsen på disse er beregnet slik at
spenningen målt over potensiometerne, som er signalet til PLS-en, går fra 0 til 10 Volt når
forsyninsspenningen i kretsen er 24 Volt. Formelen for spenningen over potensiometeret er
som følger, når man vet at den faste motstanden er 14 kΩ;
Potensiometerne går fra 0 til 10 kΩ og spenningen over dem vil være 0 Volt når motstanden
er 0, og 10 Volt når de er stilt på 10 kΩ. Grunnen til at man kan koble disse i parallell, er at
spenningen i en parallellkobling vil være lik i alle grenene. Bare strømmen vil variere.
I dette kapitelet har vi gått gjennom alle de teoretiske aspektene av oppgaven. Det er de
fleste tilfeller begrenset til tema som er relevant for denne oppgaven, men i noen tilfeller
er flere ting tatt med for å skape en større forståelse, dersom man ikke kjenner til
fagområdene fra før.
-
40
3. RESULTATER
Her tar vi for oss det vi har opparbeidet av resultater i løpet av prosjektet.
3.1 SIMULERING I CX-PROGRAMMER
Ved å kjøre simuleringer internt i CX-programmer kunne vi bekrefte at vi hadde skjønt
hvordan forskjellige instruksjoner fungerer. Dette gjorde vi ved å manuelt sette forskjellige
trigger-bit i minnet til 1 eller 0. Disse skulle senere bli aktivert av sensorer eller HMI-et, men
ved å gjøre det på denne måten kunne vi se hvordan de forskjellige instruksjonene ville
oppføre seg, gitt at kommunikasjon mellom HMI og PLS samt alle sensorer, fungerte. I tillegg
til dette lærte vi mye om hvordan minnet i PLS-en fungerer.
3.2 SIMULERING I NB-DESIGNER
I NB-designer kan man kjøre en såkalt “offline test”. Da legger programmet sammen alle de
grafiske elementene som er lagt inn, og man får bilde av et virtuelt HMI på skjermen hvor
man kan trykke på det som er av knapper og
triggerområder. Dette oppleves likt som om det var den
virkelige skjermen. På samme måte som i CX-
programmer, fikk vi bekreftet at vi hadde forstått de
forskjellige funksjonene, og at de var definert korrekt.
Da vi i begynnelsen ikke hadde opprettet
kommunikasjon mellom HMI og PLS, simulerte vi de
funksjonene som skulle gjøre ting i minnet til PLS-en
ved å bruke HMI-et sitt interne minne, og vise status på
dette med forskjellige “bit lamp” og “number display”. I
tillegg til dette fikk vi bekreftet at navigeringen mellom forskjellige menyer fungerte og at
riktig bilde kom opp til riktig tid. Her kjørte vi også brukeropplevelsestester ved å la blant
annet medstudenter, som ikke nødvendigvis kjenner til trykktesting, starte en test med
verdier som vi gav dem. Dette førte til en del endringer i design og funksjon, og på denne
måten sørget vi for at valg og navigering er blitt så intuitiv som mulig.
Figur 43 Virtuelt HMI
-
41
3.3 SIMULERINGSRIGG
Når vi hadde bygget ferdig den fysiske
simuleringsriggen, og hadde det viktigste av
programmeringen i PLS-en klar, koblet vi denne til
sine respektive inn- og utganger på input- og
outputmodulen. Nå kunne vi se at signalet faktisk
kom helt ut til ventilen, eller at nivået fra de
forskjellige sensorene faktisk ble registrert korrekt i
PLS-en og kunne trigge neste steg i programmet. Nå
kunne vi også se, og få en følelse av, hvordan
forsinkelsen mellom de forskjellige trinnene var.
Dette var mye lettere når vi kunne se lysene gå på
og av, da man ikke nødvendigvis har noe forhold til
hvor lenge et visst antall millisekunder varer.
Figur 44 Ferdig bygget simuleringsrigg
-
42
3.4 BYGGING AV PROTOTYPE
Under er et bilde av hvordan konfigurasjonen av komponenter i prototypen ble til slutt.
Under dette er et skjema av den samme konfigurasjonen der komponentene er navnsatt.
Figur 45 Prototype på trestøtte
-
43
Figur 46 Skjemtaisk fremstilling av prototypen.
1 Inntak hydraulikk 11 3-veisventil
2 Flowmeter 12 T-stykke
3 Temperatursensor 13 Partikkelteller
4 Én-veisventil 14 Flowregulator
5 T-stykke 15 Én-veisventil
6 Aktuert luftventil 16 T-stykke
7 Lufttrykkregulator 17 Aktuert seteventil
8 Inntak luft 18 Manuell kuleventil
9 Trykksensor 19 Retur hydraulikk
10 Manometer 20 Uttak spillolje
Tabell 7 Oversikt over komponenter.
-
44
3.5 FERDIG LADDERPROGRAMMERING
Etter vi var ferdig med byggingen av prototypen, og hadde fått alle sensorer og ventil koblet
til PLS-en, begynte vi å teste hvordan riggen responderte på programmet vi hadde laget til
simuleringsriggen. Vi oppdaget fort hva som måtte endres på, og fikk gjort en del
optimalisering av blant annet timere.
Den ferdige koden er delt inn i 5 seksjoner.
1. Startsekvens: Denne tar for seg alle betingelser for start og stopp.
2. Trykktestingssekvens: Dette er logikken på hvordan trykktestsekvensen skal
foregå.
3. Flushesekvens: Dette er logikken på hvordan flushesekvensen skal foregå.
4. Betingelser for logging, blant annet filnavn.
5. Matematiske funksjoner: Manipulerer tallene man får fra HMI-et, slik at
koden kan forstå disse verdiene.
På neste side er et flytskjema som viser den elementære logikken i programmeringen. I
koden er det kommentert underveis i de gule feltene.
Selve programmefilen finner man vedlagt som ”Hovedprogram system.cxp”.
-
45
-
46
-
47
3.5.1 STARTSEKVENS
-
48
-
49
3.5.2 TRYKKTESTINGSSEKVENS
-
50
-
51
-
52
-
53
-
54
-
55
3.5.3 FLUSHESEKVENS
-
56
-
57
-
58
3.5.4 LOGGING
-
59
3.5.5 MATEMATISKE FUNKSJONER
-
60
-
61
3.6 DESIGN AV HMI-BILDER
Under er ferdig design av HMI-bilder. De taller meste er laget I programmet photoshop, men
med elementer fra NB-designer sitt bibliotek av grafikk. Alle bildene er ikke helt slik som
man vil se dem på HMI-et, da dette bare skjer under selve prosessen, og dermed ikke lar seg
avbilde på samme mate.
-
62
-
63
-
64
-
65
-
66
-
67
3.7 RESULTATER AV TESTER
Under er graf fra fire representative logginger av flere tester vi gjorde. Disse er
forklart/diskutert i kapittelet Diskusjon.
Figur 47 Resultat nummer 1
Figur 48 Resultat fra test nummer 2
-
68
Figur 49 Resultat nummer 3
Figur 50 Resultat nummer 4
-
69
4. DISKUSJON
Vi har valgt å beskrive hele prosessen med løsingen av oppgaven da vi ikke har gjort
noe lignende før, og ikke nødvendigvis har gjort ting på den måten som er standard.
Derfor ønsker vi å få med hvordan vi har valgt å gjøre de forskjellige delene.
4.1 TILDELING AV OPPGAVE.
Vi kontaktet NTOS AS med forespørsel på problemstilling til bacheloroppgave, og fikk to
alternativer. De var henholdsvis å lage en multifunksjons test- og analysebenk for
hydrauliske systemer og å lage en automatisk trykktestings og flusherigg for hydraulikkrør. Vi
valgte først analysebenken, da den virket mest åpen og interessant. I midten av januar
hadde vi et møte vår eksterne veileder, for å få en kravspesifikasjon til oppgaven. Her ble
oppgavene forklart nærmere, og da oppgaven med å lage en rigg for flushing og trykktest
faktisk løste et reelt problem, valgte vi denne. Den oppgaven vi opprinnelig hadde valgt, var
mer i kategorien “kjekt å ha”.
Ekstern veileder foreslo enten å bygge om en eksisterende hydraulisk rigg som de hadde
stående på lager, eller integrere vårt system med en enhet som skulle bygges i forbindelse
med en fagoppgave. Vi undersøkte disse to, men kom senere frem til at det var bedre å lage
en “stand-alone” enhet, som kunne kobles til en standard HPU. Denne måtte da tilfredsstille
krav til oljemengde, trykk og styring.
Det ble laget et utkast til systemet i Autocad og vi presenterte dette. Vi diskuterte rundt
hver komponent og kom frem til en løsning som tilfredsstilte kravene. Det ble laget en
generell liste over hva vi ville trenge, og NTOS AS bestilte de spesifikke komponentene.
Figure 2 Rigg til fagoppgave Figur 52 testrigg til fagoppgave Figur 51 Hydraulisk testrigg, som ikke lenger er i bruk
-
70
4.2 PLS
Når vi hadde fått klarert hvilke komponenter som skulle brukes, og hvordan systemet måtte
være, begynte vi å fokusere på PLS. Når vi bestemte oss for å gjøre denne oppgaven, kunne
vi såpass mye om automatisering fra før, at vi visste vi ville trenge assistanse. Vi undersøkte
om det var mulig å få til et samarbeid med instituttet for elektro, men på grunn av at
Høgskolen skulle flytte til nytt campus, lot ikke dette seg gjøre.
Dette førte til at planleggingen av oppgaven tok mye mer tid enn vi hadde trodd. Vi visste
det fantes mange leverandører av PLS-er, men vi hadde veldig begrenset erfaring med dem
fra før og var veldig usikre på om de forskjellige systemene ville egne seg for vårt prosjekt.
Vi laget ganske raskt en kravspesifikasjon som beskrev erfaringen vi hadde fra før, hele
systemet, og hva vi ville trenge av en PLS. Denne brukte vi til å sende til leverandører, samt
de vi kjente i industrien for å få råd.
For å kunne gå for et system, og for at prosjektet skulle være gjennomførbart, hadde vi i
tillegg en del ikke-tekniske krav som alle måtte innfris;
Vi måtte ha mulighet til å bruke, eller lære oss, programmeringsspråket til det
aktuelle systemet.
Vi måtte ha mulighet for support.
Kostnad av lisens på programvare måtte være under et visst nivå.
Pris på selve produktene måtte være kurante.
4.2.1 SIEMENS
Vi sendte en mail til Siemens med kravspesifikasjonen hvor vi
spurte etter noen som kunne hjelpe oss å finne aktuelle
komponenter for å løse oppgaven. Til svar fikk vi at det ikke
var noen på subseaavdelingen som hadde kapasitet til å
hjelpe oss. Vi sendte svar tilbake at oppgaven ikke var spesifikk
for subsea, og at vi i første omgang bare trengte å finne komponentene. Nesten to uker
senere fikk vi svar igjen hvor de skrev at de dessverre ikke hadde tid til å hjelpe oss. Av
denne korrespondansen skjønte vi at det ville bli veldig vanskelig å få den hjelpen vi trengte,
skulle vi velge Siemens. Når vi i tillegg fant ut at lisens på nødvendig programvare for
Siemens sitt utstyr er meget kostbart, ble vi enige om at dette alternativet ikke var aktuelt.
4.2.2 ABB
Når det gjelder ABB, snakket vi med Kurt Hjertholm, som akkurat
hadde skrevet hovedoppgave med deres system på linjen for
automasjon ved Høgskolen i Bergen. Vi forklarte ham hvilket
teknisk nivå vi da lå på når det kom til programmering av PLS-er,
og spurte om det ville være praktisk mulig med dette systemet,
Figur 53 Siemens logo
Figur 54 ABB logo
-
71
at vi ville ha mulighet til å lære oss det nødvendige. Han mente det ville være nødvendig
med et spesifikt kurs, som han også hadde tatt, for at det skulle gå. Vi tok kontakt med ABB,
forklarte situasjonen, og spurte om det var mulig å få dette kurset dersom vi valgte å bruke
deres utstyr i oppgaven. Dette viste seg å i utgangspunktet være forbeholdt studenter som
skrev oppgave for dem. Dette grunnet begrenset læremateriell, modeller osv. Kurset kostet i
tillegg kr 15.000,- per person, og selv om vi hadde fått dette sponset, ville det ta for lang tid
før det var ledig kapasitet, og vi ville måttet reise til Oslo for å ta delta på det. Et annet
minus var at systemet for dokumentasjon på deler og komponenter var lite oversiktlig og det
var utfordrende å finne ut hva man trengte i det.
4.2.3 MITSUBISHI
For råd om Mitsubishi henvendte vi oss til Geir Omar Berland
ved HIB. Han uttrykte at det vi spesifiserte vanligvis tar minst ett
semester å lære, og at det ville kreve for mye assistanse for å
gjennomføre med den vanlige serien av PLS-er som Mitsubishi
produserer. Imidlertid nevnte han at vi kunne bruke en enklere
serie som heter Mitsubishi Alpha. Vi prøvde oss litt frem i
programvaren som hører til dette systemet, men fant fort ut at
dette var for enkelt og ikke hadde de funksjonene vi ville
trenge.
4.2.4 MOELLER
Også her opplevde vi at funksjonene i tilhørende programvare
var for enkle for det vi ville trenge.
4.2.5 OMRON
Fremdeles litt i villrede når det gjaldt valg av system, ringte
vi til en annen bekjent vi visste jobbet med automasjon.
Etter å ha hørt beskrivelsen av prosjektet og hvilke
utfordringer vi hadde, mente han Omron var det beste
systemet for oss. Dette ble bekreftet etter å ha snakket
med en slektning som viste seg å ha lang erfaring med dette systemet. Han viste
eksempelprogrammer og fortalte om systemet de har for support, priser osv.
Vi kontaktet Omron og spurte om et møte med selger for å finne komponenter osv. Dette
ble ordnet ganske kjapt, og vi fikk laget en liste med deler vi trengte. Han ordnet i tillegg
med programvare, kompendium og rabatt på 50%.
Omron har et meget effektivt system for support, hvor man kan søke i tidligere spurte
spørsmål, eller man kan stille nye. Dette fungerte meget bra, og det var ikke uvanlig å få svar
i løpet av timer etter å ha sendt et spørsmål. Som oftest var det også eksempelfiler med i
svaret, hvilket var til stor nytte.
Figur 55 Mitsubishi logo
Figur 56 Möeller logo
Figur 57 Omron logo
-
72
Når vi hadde bestemt oss for hvilket system vi skulle bruke, tok vi kontakt med en tidligere
lærer av Robin, ved Bergen Maritime Videregående, for å høre hva han hadde å si om det.
Det viste seg at han hadde nesten alle delene som hadde med PLS å gjøre tilgjengelig, og lot
oss låne det vi trengte. Dette var utrolig nyttig for oss, da vi kunne begynne å jobbe med en
gang, og få et bilde av om prosjektet lot seg gjennomføre eller ikke, før eventuelt innkjøp av
komponentene.
4.3 FYSISK SIMULERING
Da vi ikke har laget systemer som dette før, ville vi gjerne vite om det faktisk var mulig før vi
ba NTOS bestille de valgte hydrauliske komponentene. Disse er nemlig ganske kostbare.
Dette gjorde vi ved å lage en simulering av systemet ved hjelp av komponenter som
potensiometere og lys. Ved å gjøre dette, kunne vi i tillegg se fysisk hvordan systemet
responderte på programmeringen, med tanke på timing osv. For at simuleringen skulle være
til hjelp, var det viktig at PLS-en ville “oppleve” det så likt som mulig når vi koblet til de
faktiske komponentene. Slik ble de erfaringene vi hadde gjort oss under simuleringen, også
nyttige når vi skulle styre det faktiske systemet.
Vi bestilte det vi trengte av komponenter, og bygget simuleringsriggen. Dette ble mange
ledninger og komponenter som skulle holdes styr på, og det var viktig å jobbe systematisk
for å holde systemet oversiktlig. Dette var blant annet viktig med tanke på feilsøking.
Figur 59 Deler til simuleringsrigg Figur 58 Bygging av simuleringsrigg
-
73
4.4 PROGRAMMERING
Når vi hadde bygget ferdig simuleringen, begynte vi å finne ut hvordan den logiske styringen
måtte være. Vi hadde laget en oppskrift på hvordan sekvensene for trykktest og flushing
måtte være og nå måtte vi finne ut hvilke spesifikke funksjoner (instruksjoner) vi måtte lære
oss for å programmere dette i PLS-en. Dette var en meget tidkrevende prosess som varte
resten av prosjektet, da vi stadig så flere og flere ting vi kunne legge til for optimalisere
programmet. Mye av tiden gikk med på å lese i manualer som fulgte med programmet, se på
lignende prosjekter tilgjengelig på Internett og testing av det vi hadde funnet ut. I tillegg til
dette opprettet vi en felles bruker på diverse forum for automatisering hvor vi også fikk litt
tips. På disse måtte vi være meget spesifikke for å få svar på det vi lurte på, og vi brukte stort
sett bare supportfunksjonen til Omron videre.
Når vi hadde laget et program som hadde alle hovedfunksjonene, viste vi dette til Ivar, og
fikk godkjenning til å fortsette, og vi bestillte da de resterende delene vi trengte, som blant
annet var HMI-et.
4.5 HMI
Da det var et designkrav om at man skal kunne velge forskjellige standarder for testing og
flushing, trengte vi en mulighet for å gi forskjellige input til PLS-en avhengig av hvilke valg
som ble gjort. Dette kunne vi gjort med pulsbrytere, men da det er totalt 11 forskjellige
kombinasjoner av program som kan kjøres, og det er opptil 4 numeriske verdier som må
tastes inn av den som bruker systemet, trengte vi noe litt mer fleksibelt. Valget falt på et
såkalt touch-HMI. HMI står for Human Machine Interface og er, som navnet tilsier,
grensesnittet mellom maskin og menneske. Den modellen vi valgte, har touchskjerm slik at
man slipper mus, tastatur eller lignende.
Når vi fikk denne, begynte vi å designe alle de forskjellige menyene, og den logiske
oppbyggingen av disse. Dette krevde til sammen 104 funksjoner på de forskjellige menyene.
Figur 61 Kobling mellom PLS og simuleringsrigg Figur 60 Lodding av komponenter
-
74
Vi la stor vekt på at alt skulle oppleves intuitivt, og at det skulle være så idiotsikkert som
mulig. Blant annet måtte det sikres at man ikke kunne gjøre to valg samtidig, altså at om
man hadde gjort et valg, så ville det deaktivere de andre alternativene i PLS-minnet. Dette
krevde mye testing for å være sikker på at ble oppfylt, da det er mange valgkombinasjoner
man kan foreta seg, og det ikke er noe automatikk i denne prosessen. Uansett hva man
hadde valgt, gjorde vi det slik at man får et sammendrag av de valgene man har gjort før
man starter selve prosessen. Dette sammendraget blir automatisk generert ut ifra hva som
faktisk har blitt aktivert i PLS-en, hvilket sikrer at man ikke kan gjøre noe feil.
4.6 SAMMENKOBLING AV HMI OG PLS
PLS-en og HMI-et kan kobles sammen på flere måter, men den måten vi hadde tilgjengelig
var via RS232. Det er en forholdsvis enkel konfigurering, både i CX-programmer og NB-
designer, når det gjelder hvilke innstillinger for tilkobling man velger. Likevel fikk vi ikke
kontakt mellom enhetene. Vi trodde det at bare vi hadde en RS-232 med riktig kjønn i hver
ende, ville vi få kontakt.
Det skulle derimot vise seg at det krevdes en helt spesiell konfigurasjon med blant annet
sammenkobling av noen av pinnene fra PLS-siden for at det skulle fungere. Dette er et av
mange eksempler på enkle ting som vi brukte lang tid på å finne ut av da vi ikke hadde
erfaringen med det fra før.
4.7 HYDRAULIKK
Når vi begynte å se at vi snart ville trenge de faktiske hydrauliske komponentene for å
komme videre, dro vi ut på NTOS på Askøy for å begynne byggingen av selve systemet. Det
begynte med at vi fikk utlevert komponentene som var kommet, i en eske. Så var det å
identifisere hva som var hva, hvilke type koblinger de forskjellige hadde, spenning osv.
Deretter koblet vi alle delene sammen i sløyfen som vi hadde planlagt, og koblet sammen
slangene som senere skulle tilsluttes testobjektet. Deretter bygget vi to støtter så det skulle
være lettere å jobbe med riggen under testing osv.
Figur 62 Modifisering av RS-232 kabel
-
75
4.8 SAMMENKOBLING AV PLS OG SENSORER/AKTUATORER
Nå begynte riggen å ta form, og det var på tide å koble alle komponentene direkte til PLS-en
istedet for å bruke simuleringsriggen. Dette gjorde vi stegvis, og testet én og én sensor eller
akutator av gangen. Det var veldig nyttig at vi hadde hatt simuleringsriggen, men det var
likevel ikke helt smertefritt å foreta denne tilkoblingen. Blant annet hadde vi fått datablad på
en nyere modell av partikkeltelleren vi hadde fått utlevert. Denne hadde en annerledes
konfigurasjon på lederne, og det tok nesten en hel dag å prøve å finne ut av dette, og å
skaffe det korrekte databladet. Et annet problem vi hadde var at, i tillegg til å velge 4-20mA i
CX-programmer, var det to små brytere inne i inputmodulen som måtte vippes over for at
den skulle måle strøm i stedet for spenning. Enda en enkel ting som en med erfaring straks
hadde funnet ut av.
4.9 TESTING
Når vi var sikre på at alt var koblet riktig, begynte vi å kjøre olje i systemet ved hjelp av en
testpumpe, og sjekket hvilke utslag vi fikk fra sensorene. Når alt så ut til å fungere, begynte
vi å kjøre trykktester med logging.
Her var det vi virkelig møtte utfordringer. Vi kjørte flere tester for å sjekke at vi hadde
konsekvente målinger. Dette fikk vi ikke. Derimot fikk vi forskjellig trykkfall avhengig om
oljen var kald eller varm. Se figur 47 og 48. Jo flere tester vi gjorde jo varmere ble oljen,
blant annet på grunn av friksjon i ventilen på testpumpen. Etter å ha gjort en del tester, kom
vi til den konklusjonen at de testene som ble gjort med kald olje, hadde et lavere trykkfall og
dermed ble fortere godkjent enn de som var varme. Dette trodde vi først at var en lekkasje i
en av ventilene, som var temperaturavhengig. Vi gikk ut ifra, og ble fortalt at hydraulikkolje
skulle være lite utsatt for forandringer i tetthet på grunn av variasjoner i temperatur, men at
viskositeten gjerne forandret seg. Etter litt undersøkelse skulle det vise seg at dette faktisk
var motsatt.
Teorien vi da hadde, var at viskositeten var blitt såpass lav ved høy temperatur at det førte
til lekkasje. Dette sjekket vi ved å koble fra tur- og returslangene fra testpumpen etter
trykket var bygget opp. Ved å gjøre dette blir systemet helt isolert da det er brukt
hurtigkoblinger mellom systemet og testpumpen. Disse er i utgangspunktet helt tette, men
vi la i tillegg papir under alle punkter hvor det kunne lekke ut olje for å dobbeltsjekke dette.
Deretter kjørte vi flere tester for å se om problemet ble eliminert. Vi konstaterte at det ikke
var noen lekkasje, men fikk likevel de samme resultatene. Dette fant vi ikke årsaken til der
og da. Så vi begynte å se på en annen ting vi ikke klarte å forklare; Når vi kjørte trykktester
med kald olje, falt trykket først som normalt, før det begynte å stige mot slutten av testene.
En av teoriene på disse resultatene, var at systemet, som for det meste består av metall,
trakk seg sammen annerledes enn det oljen gjorde når temperaturen sank. Selv om vi trodde
at denne effekten hadde lite å si, visste vi at vi hadde et meget lite volum i testen vår, og at
små forandringer ville føre til store variasjoner i trykket. For å se om det var hold i denne
teorien, ville vi kjøre en test der vi fremprovoserte denne effekten. Dette gjorde vi ved å
bytte ut slangen med et stålrør som var så kort som mulig. Dette gjorde at volumet i
-
76
systemet ble enda mindre, og alt ville bestå av metall. Dersom det var noe med
sammentrekningen i stålet som var årsaken, skulle vi nå fått en større trykkoppbygging ved
de samme forholdene som før. Dette skjedde ikke. Derimot fikk vi omtrent det samme
resultatet. Se figur 49.
Forklaringen på disse målingene fikk vi etter å ha konsultert Simon Møllerstrøm ved NTOS
sin avdeling på Ågotnes. Han arbeider blant annet med trykktesting, og kunne klare opp i
misforståelsen vi hadde om tetthet og viskositet gitt av temperatur. Han kunne fortelle at en
tommelfingerregel er at 1 grad Celsius tilsvarer en trykkdifferanse på 10bar. Når vi visste
dette, gikk vi straks i gang for å finne ut hva som kan ha forstyrret temperaturen. Med tanke
på at vi fikk omtrent samme trykkoppbygging, til omtrent samme tid, måtte det være noe
som skjedde hver gang programmet ble kjørt. Vi kjørte en kald test og kjente rundt om på
systemet etter varmekilder. Kort tid etter testen var i gang, fant vi ut hvor varmen kom fra.
Seteventilen som vi brukte til å stenge inne trykket under testen, er en “normally open”
aktuert ventil. Dette betyr, som beskrevet tidligere i oppgaven, at ventilen er åpen helt til
den får en spenning. Altså må elektromagneten i aktuatoren “holde” ventilen stengt under
hele testen. Denne aktuatoren er på 20 Watt og utvikler dermed mye varme når den står på
over lengre tid. Dette stemmer overens med de målingene vi gjorde. Ved en kald test sank
trykket helt til aktuatoren ble så varm at den begynte å varme opp oljen. Da steg trykket
igjen. Grunnen til at vi ikke fikk en oppbygging ved varme tester, er at da er olje allerede
varm, og det eneste aktuatoren da gjør er å hindre temperaturen på oljen å synke så mye
som den ellers ville gjort.
Disse konklusjonene bekreftet vi ved å koble ut seteventilen, og heller bruke en manuell
kuleventil. Se figur 50. Etter å ha gjort dette fikk vi “normale” kurver for trykkfall ved både
varme og kalde tester.
Vi har ikke kjørt faktiske flushinger, altså med filter, til oljen har nådd en viss renhet.
Grunnen til dette er at prinsippene i forbindelse med styring er bekreftet at fungerer, og det
eneste vi hadde fått ut av en slik test er hvor lang tid en slik flushing ville brukt på å bli
godkjent. I tillegg hadde ikke den pumpen som var tilgjengelig stor nok flow til å kjøre en
skikkelig flushing.
Figur 63 Seteventilen med actuator, som var
grunnen til de unormale loggingene
-
77
4.10 VIDERE ARBEID
Vi har gjort alle tester med en testpumpe, da det var denne som var tilgjengelig. For at
systemet både skal kunne trykkteste og flushe, må denne byttes ut med en som kan levere
en større mengde olje. Det kreves en viss mengde programmering for å tilpasse systemet til
den nye pumpen, men det er for det meste bare spesifikke tallverdier som må forandres.
For at systemet skal kunne tas i bruk vil det være en fase med intern testing der operatører
vil gjøre seg opp en mening om noe må forandres eller ikke. Når dette er gjort, er neste steg
en eventuell kommersialisering hvor det må hentes inn kompetanse innen elektro og
automatisering som kan sørge for at alt blir gjort etter alle direktiver og at alle godkjenninger
som kreves for å selge produktet er i orden. Praktiske ting som å montere systemet i et skap
som lett lar seg transportere samt optimalisering av flow, er også noe som bør gjøres.
I dette kapittelet har vi tatt for oss på hvilken måte vi har valgt å løse de forskjellige
utfordringer som har kommet. Denne delen har fått mye plass da store deler av oppgaven,
for oss, har gått ut på å komme frem til de forskjellige løsningene.
Figur 64 Testpumpen vi brukte under prosjektet
-
78
5. KONKLUSJON
Her har vi skrevet om hvorvidt oppgaven svarer på problemstilling, samt noen tanker vi
har gjort oss opp om et slikt system generelt.
Ønskede resultater fra denne oppgaven var som følger;
Gi et svar på hvor gjennomførbart det er å lage et automatisk system for flushing og
trykktesting.
Gjøre det som må til for å sikre gjennomførbarhet under hele prosjektet.
Lage en prototype, med en hovedvekt på å ha et utkast til automatiseringsdelen,
men også den hydrauliske.
Av resultater har vi følgende.
Det er absolutt gjennomførbart å lage et system for automatisk flushing og
trykktesting av hydraulikkrør.
Vi har gjort alt stegvis for å sikre oss at prosjektet lot seg gjennomføre, ved å først
undersøke de teoretiske aspektene, simulere det som kunne simuleres, for så å ta
med oss erfaring fra de foregående fasene når vi bygget selve systemet.
Vi har laget en fungerende prototype, både med tanke på styring, og det
hydrauliske.
Vi kan konkludere med at det gjennomførbart å bygge systemet slik vi har gjort, og at dette
har potensial for å spare mye tid og dermed penger i prosessen det er å bygge nye
hydrauliske systemer.
Det er utfordringer i forbindelse med trykktesting av denne typen da volumet av væske er
såpass lite, og forstyrrelser da vil gi store utslag på målinger. Dette løses ved å sikre stabile
temperaturforhold med riktig valg av komponenter, og ellers ha gode rutiner ved testing.
Dette inkluderer ting som å sørge for at ytterdører er lukket osv.
I tillegg til dette jobber NTOS med å opprette en egen standard som vil være mer
hensiktsmessig for testing av korte hydraulikkrør. Denne vil ha et lavere krav om holdetid,
men likevel oppdage en eventuell lekkasje. Dette er noe vi stiller oss bak med den erfaringen
vi har fått i løpet av alle testene.
-
79
6. FIGURLISTE
Figur 1 NTOS sin logo ................................................................................................................. 8
Figur 2 Prinsipp for flushing ..................................................................................................... 12
Figur 3 Oversikt over NAS-klasser ........................................................................................... 12
Figur 5 Illustrasjon mellom forskjellen på laminer og turbulent strømning. Pilene illustrerer
bevegelsen til fluidpartiklene. ......................................................................................... 13
Figur 4 Formel for Reynolds tall .............................................................................................. 13
Figur 6 Hydraulisk koblingsskjema for systemet ..................................................................... 16
Figur 7 Diverse fittings ............................................................................................................. 16
Figur 8 Parker EO-2 fittings ...................................................................................................... 16
Figur 9 BSP fittings ................................................................................................................... 16
Figur 10 Prinsippet for et turbinmeter .................................................................................... 17
Figur 11 Temperatursensor, Parker SCTSD ............................................................................. 18
Figur 12 Forskjellen på absolutt trykk og relativt trykk vist grafisk ......................................... 19
Figur 13 Parker SCPSD trykksensor.......................................................................................... 19
Figur 14 Prinsippet light scattering.......................................................................................... 20
Figur 15 Prinsippet for en tilbakeslagsventil ........................................................................... 21
Figur 16 En typisk tilbakeslagsventil ........................................................................................ 21
Figur 17 Treveis kuleventil forklart grafisk .............................................................................. 22
Figur 18 Prinsippet for en seteventil ...................