KOLLISJONSSIKRING AV TRAVERSKRANER

Transkript

1 KOLLISJONSSIKRING AV TRAVERSKRANER Agnes Flatmo; Ole Martin Larsen; Anders Steen Nilsen HEAU12 2. juni 2015

2 Dokumentkontroll Rapportens tittel: Antikollisjon mellom traverskraner Forfatter(e): Agnes Flatmo; Ole Martin Larsen; Anders Steen Nilsen Høgskolens veileder: Eventuelle Merknader: Vi godtar at bacheloroppgaven offentliggjøres på biblioteket Dato/Versjon /v0.14 Rapportnummer: Studieretning: HEAU12 Antall sider u/vedlegg 38 Gradering: Offisiell Oppdragsgiver: Bergen Elektrokompetanse AS Oppdragsgivers kontaktperson(er) (inklusiv kontaktinformasjon): Peter Alexandersson, Oppdragsgivers referanse: BEKAS

3 Forord Denne bacheloroppgaven har vært kjekk og krevende, arbeidsmengden har vært stor, men ikke uoverkommelig. Vi har fått stort læringsutbytte og er veldig glad for at vi fikk sjansen til å jobbe med nettopp denne oppgaven. Vi vil først og fremst takke veileder hos oppdragsgiveren vår BEKAS (Bergen Elektrokompetanse AS), Peter Alexandersson. Peter har lært oss mye dette siste semesteret. Han har tatt seg tid til å vise hvordan programmer fungerer, gitt oss gode tilbakemeldinger på løsninger som fungerer og løsninger som ikke er fullt så gode. I tillegg har Peter vært flink til å ta imot forslag fra vår side. En annen person som har hjulpet oss hos BEKAS er Lisbeth. Lisbeth hjalp oss mye i byggefasen på verkstedet. Hun var der alltid når vi trengte hjelp, i alt fra å finne verktøy og materiale til hvordan komponenter og ledere skulle merkes. Vi vil også takke Emil Cimpan, veilederen på Høgskolen i Bergen som gjennom hele prosessen har gitt oss gode råd om hvor vi skulle ha fokuset vårt. Rev: v0.14 3(39)

4 Sammendrag Vi har gjennom denne oppgaven prosjektert og levert et nytt antikollisjonssystem for traverskraner. Vi har jobbet for BEKAS og systemet er levert til Kværner Stord AS. Oppgaven er et reelt prosjekt som BEKAS har fått av Kværner og gitt videre til oss. Bachelorprosjektet inneholder alle steg som BEKAS går igjennom når de får inn oppdrag. Fra planleggingsfase ut fra kravspesifikasjonen, videre til tegning og bygging av styreskap. Helt fram til programmering, testing og igangkjøring hos kunde. Kravspesifikasjonen som ble satt av Kværner ved kontraktinngåelse har gjennom hele perioden blitt fulgt og ivaretatt. Det har blitt lagt stor vekt på en ryddig og veldokumentert prosess. Systemet er nå overlevert og igangkjørt hos Kværner med godt resultat. Rev: v0.14 4(39)

5 Dokumentkontroll... 2 Forord... 3 Sammendrag Innledning Organisering av rapporten Oppdragsgiver Problemstilling Løsningsforslag Kravspesifikasjon Krav fra Kværner Krav fra BEKAS Analyse Programvare og arbeidsplass Hardware komponenter Software komponenter Konklusjon Realisering av valgt løsning Teknisk tegning Verkstedarbeid PLS programmering HMI programmering Manual Testing Igangkjøring Klargjøring Kommunikasjon Virkemåte Posisjonsberegning Alarmer Oppsummering med diskusjon Appendiks A Litteraturliste Appendiks B Forkortelser og ordforklaringer Appendiks C Prosjektledelse og styring Appendiks D Tilbud Rev: v0.14 5(39)

6 Appendiks E Teknisk tegning Appendiks F Brukermanual Appendiks G Program master Appendiks H Program slave Appendiks I Datablad Appendiks J Sjekkliste Appendiks K Bilder Rev: v0.14 6(39)

7 1 Innledning 1.1 Organisering av rapporten Denne rapporten vil først gi ett overblikk over nåværende situasjon og problemstilling [1.3]. Deretter vil rapporten vise hva som er hovedidéen [1.4] og løsningsforslag [ ]. Kravspesifikasjonen [2] vil bli analysert [3] og vil bli fulgt av dokumentasjon om hvordan vi har gjennomført oppgaven [4], delt opp etter de forskjellige stegene, tegning [4.1], bygging [4.2] og programmering [ ]. I testing [5] og Igangkjøring [6] kan du lese om hvordan systemet blir realisert. I diskusjon og sammendrag [8] vil du få en kort oversikt over hvordan vi syns prosjektet har utartet seg. 1.2 Oppdragsgiver BEKAS Bergen Elektrokompetanse AS ble startet i april 2000 av 7 ingeniører med erfaring innen salg, engineering og tavleproduksjon. Konseptet til BEKAS som grossist, systemleverandør og tavleprodusent har gjort dem i stand, som den eneste grossist i markedet, til å levere komplette systemer til kunden. Dette omfatter da gjerne komponentvalg, prosjektering, bygging og igangsetting. BEKAS er spesielt kompetent innen EEx- materiell. BEKAS har hatt en jevn vekst siden oppstarten, og hadde i 2013 en omsetning på vel 110 mill. I dag er det 43 ansatte, samt at det er et kontor i Malaysia. [1] Kværner Kværner er et ledende konsern når det kommer til bygging av olje og gassplattformer i Norge. I Norge består Kværner hovedsakelig av Kværner Verdal og Kværner Stord. Konsernet har virksomhet i 13 land, blant annet i USA, Canada, Russland, Storbritannia, Kasakhstan, Australia og Kina. [2] Kværner Stord AS er oppdragsgiveren til BEKAS på dette prosjektet. Det er Kværner som har bestilt løsningen og BEKAS som gjennom oss som studenter skal levere. Rev: v0.14 7(39)

8 Figur 1: Kranskisse 1.3 Problemstilling Kværner Stord har en industrihall hvor det er montert tre traverskraner i to nivåer. Det er to skinneganger, en øvre og en nedre. På den øvre skinnen er det to kraner, og på den nedre er det én. De to øvre kranene kan bevege seg fritt over den nedre dersom de ikke kjører med last, og lastekrokene er oppe. Da de to øvre kranene deler skinne, kan heller ikke disse gå over hverandre. På det gamle sikkerhetssystemet hadde hver kran en tilhørende PLS (Programmerbar Logisk Styring) som sammen med pulstellere og presetbrytere beregnet posisjon og sørget for at kranene stoppet når de nærmet seg en hindring. Dette systemet er delvis satt ut av drift da radiokommunikasjonen som er brukt ikke lenger fungerer på grunn av nytt utstyr i hallen som går på samme frekvens og dermed skaper forstyrrelser. PLS-ene som er brukt er også utdaterte, og det er ønske om at disse blir byttet ut når et nytt system blir satt opp. BEKAS har fått i oppdrag av Kværner å bytte ut og oppgradere dette antikollisjonssystemet. Rev: v0.14 8(39)

9 Figur 2: Systemskisse 1.4 Løsningsforslag Kværner ønsker å få levert en løsning som er minst like god som det nåværende systemet som er satt ut av drift. Etter kravspesifikasjonene (kap 2) er det utarbeidet en hovedidé for løsningsforslag. Det vil være en PLS på hver av de tre kranene for beregning av posisjon. For å beregne posisjon vil det bli tatt i bruk roterende pulsgenerator på et løpehjul som allerede er montert på kranene. Det vil også bli tatt i bruk presetbrytere for registrering av referansepunkt. Da et liknende system har vært i bruk tidligere, ønsker oppdragsgiver å beholde sensorer og pulsgeneratorer som allerede er montert, det har da ikke vært mulig å skissere andre løsninger på disse punktene. En av kranene vil også utstyres med HMI (Human-Machine Interface) skjerm for justering av systemet og visning av status-informasjon. Her vil brukeren blant annet ha mulighet til å kalibrere posisjonene til kranene, og endre aktuelle parametere. Det gamle systemet var uten HMI og dette blir en klar forbedring, både med tanke på oversikt og brukervennlighet. Det vil bli brukt trådløs kommunikasjon for å sende og motta informasjon mellom de tre PLS-ene. Det skal programmeres en PLS som master og de to andre som slaver. Masteren vil ta seg av all beregning og gi beskjed til slavene om ønsket oppførsel. Slavene skal ha identisk program for å gjøre det lettere med tanke på service og oppgradering. Dersom flere kraner skal tas i bruk ved en seinere anledning, har man på denne måten mulighet til å utvide med en ekstra slave. Man vil da unngå å måtte skrive om hele logikken i PLS-en. Rev: v0.14 9(39)

10 2 Kravspesifikasjon Kravene til oppgaven kommer fram i tilbudet Kværner har inngått med BEKAS. I tillegg kommer det krav fra BEKAS til oss om at prosjektet skal gjennomføres etter deres standard. 2.1 Krav fra Kværner Følgende krav er inngått og gjengitt fra utformet tilbud. Tilbudet ligger i sin helhet som Appendiks D- Tilbud. Generelt: Dersom BEKAS blir tildelt denne jobben, vil vi sette 3 studenter fra Høgskolen i Bergen til å utføre oppdraget under veiledning fra BEKAS. Studentene vil lage elektriske tegninger og stykklister for systemet. Studentene vil programmere og teste PLS og HMI i BEKAS lokaler. Studentene vil lage brukermanual for systemet. Studentene vil stå for igangkjøring og testing av systemet på Kværner Stord under veiledning fra BEKAS. BEKAS står ansvarlig for systemets funksjoner som minimum tilsvarer eksisterende system. BEKAS står ansvarlig for at trådløs kommunikasjon er stabil og ikke forstyrrer radio kommunikasjon i 400 MHz båndet. Garantitid for komponenter er 12 måneder etter overlevering. Garantitid for systemløsning er 48 måneder etter overlevering. BEKAS forutsetter følgende fra Kværner Stord: Sikkerhetskurs og adgang til anlegget for 3 studenter i tillegg til prosjektansvarlig fra BEKAS. Tålmodighet ved igangkjøring og testing av systemet. For at vi skal kunne bruke prosjektet som Bachelor oppgave for studentene må vi ha en bestilling fra Kværner Stord senest i midten av desember Følgende utstyr er inkludert i tilbudet: For hver av de 3 kranene: Nytt styreskap, Rittal, 600 x 600 x 210 mm. Tilkobling mot eksternt utstyr og styreskap for kran vil bli holdt identisk til eksisterende skap. Simatic PLS type 1510SP med tilstrekkelig digital IO. Pulsteller interface til PLS for posisjonsmåling. Phoenix modul for trådløs kommunikasjon. Radiofrekvens 2.4 GHz, rekkevidde 200 meter ved fri sikt. Ekstern antenne og antennekabel for trådløs kommunikasjon. Tillegg for en av kranene: Simatic Comfort HMI panel, størrelse 7 tommer, for systemjustering og tilbakemeldinger fra alle kraner. Kværner Stord kan selv velge hvilken kran som skal utstyres med HMI panelet. Følgende utstyr er ikke inkludert i tilbudet: Pulsencoder for posisjonsmåling. Vi forutsetter at eksisterende encoder fortsatt kan brukes. Rev: v (39)

11 Endebrytere for fastpunkt referanse. Vi forutsetter at eksisterende givere kan brukes. Varsellys og horn. Kabler, med unntak av antennekabel. Tilbudet inkluderer følgende tjenester: Oppdatert dokumentasjon for styreskap. Bygging av styreskap. Programmering av PLS og HMI. Montasje på anlegget i samarbeid med Kværner Stord. Test og igangkjøring av system. Brukermanual for systemet. 2.2 Krav fra BEKAS Dette er en bestilling fra en reel kunde, og derfor stilles det like høye krav til bacheloroppgaven som det ville blitt gjort til en hvilken som helst annen jobb fra BEKAS. Fastsatte prosjektfaser skal gjennomføres i henhold til BEAKAS sin prosjektmal Intern dokumentasjon Timelister Mailkorrespondanse med kunde og internt Daglig journal Møtereferater Ekstern dokumentasjon Oversiktstegning Hovedstrømskjema Styrestrømskjema Rekkeklemmeliste Stykklister Kabellister Datablad Brukermanual o Overordnet systembeskrivelse. o Detaljert beskrivelse av sider og funksjoner på HMI. Alt av tegninger, strømskjema, stykk- og kabellister finnes i Appendiks E Teknisk tegning. Datablad finnes i Appendiks I Datablad, og brukermanualen finnes i Appendiks F Brukermanual. Rev: v (39)

12 3 Analyse Med en så konkret kravspesifikasjon og avtale som er inngått mellom BEKAS og Kværner gis det lite rom for å endre på noe underveis. Det vil av den grunn fokuseres på å utføre arbeidet med de gitte begrensninger på en korrekt og tilfredsstillende måte. Siden all software er nytt for oss, blir det en utfordring å sette seg inn i alt. Problemstillingen i oppgaven er å unngå kollisjoner mellom kraner. Dette innebærer styrestrømtegninger av systemet, programmering av PLS, bygging av styreskap og oppsett av trådløst Ethernet. I tillegg skal vi programmere HMI skjerm og lage en utfyllende brukermanual. Det kommer til å bli gitt opplæring og hjelp til dette av veileder hos BEKAS dersom det skulle være nødvendig. Teknisk tegning skal inneholde oversiktstegning, rekkeklemmelister, kabelliste, hoved- og styrestømskjema. Alle tegninger og skjemaer skal bli gjort i programvaren E3.schematic. Det skal bygges to skap til hver kran. Ett styreskap som inneholder en PLS og et mindre skap som skal bli brukt til trådløs kommunikasjon. Skapene er levert av Rittal. Når skapene har blitt ferdig bygget, begynner programmeringen av selve programmet som skal styre systemet. PLS-ene som skal brukes er Siemens Simatic 1510SP. Vi skal bruke Siemens egen programvare: Totally Integrated Automation Portal. Dette er for oss nytt, da vi tidligere kun er kjent med en eldre versjon av Siemens programvare: Step 7. Programmet skal skrives i SCL (Structured Control Language), vi har fra tidligere kun erfaring med FBD (Function Block Diagram), så her vil det bli brukt tid på opplæring av SCL. Grunnen er at eventuelt vedlikehold og service av systemet skal kunne utføres av personell som kun er kjent med SCL. Til programmering av HMI panelet skal også Siemens Totally Integrated Automation Portal brukes. Informasjonen som vises på panelet skal gi bruker et visuell bilde av hvor kranene befinner seg i forhold til hverandre. Det skal også gis en fullstendig oversikt over aktuelle alarmer med informasjon om hvor feilene ligger. Det vil være mulighet for kalibrering av kranene via instrukser på HMI i tillegg til endring av variabler. Her er det viktig at informasjonen presenteres på en ryddig og forståelsesfull måte. Det vil føre til en enkel og intuitiv opplevelse for bruker og vedlikeholdspersonell. På HMI-en vil enkelte ting være passordbeskyttet for å hindre at uautorisert personell kalibrerer eller endrer viktige parametere. PLS-ene skal kommunisere sammen via trådløst nett. De mindre skapene med trådløst aksesspunkt vil være koblet til hver sin antenne. For å unngå at det tar for mye tid når kommunikasjonen skal igangkjøres hos Kværner, blir det desto viktigere å teste kommunikasjonen godt på verkstedet hos BEKAS i forkant. En utfordring blir at annet utstyr hos Kværner kan skape støy på det nye systemet, dette er noe man ikke får testet i forkant. Det har allerede blitt avklart at det skal bli brukt et trådløs aksesspunkt fra Phoenix som opererer på 2.4 GHz båndet. Rev: v (39)

13 3.1 Programvare og arbeidsplass Arbeidsrutiner, bruk av verktøy og programvare er fastsatt av arbeidsgiver. Det vil bli brukt programmer og verktøy som BEKAS har tilgjengelig og vanligvis bruker. Programvare fra Siemens blir gitt med demolisens for et år. Programmet E3.schematic fra Zuken blir gitt med ukeslisenser som vi får hver fredag i uken før. Kontaktperson i Zuken sender hver uke ny lisens så lenge det er nødvendig. Vil i utgangspunktet arbeide mest i lokalene til BEKAS, da vi der har tilgang på utstyr og hjelp. Har fått en kontorplass hos BEKAS i åpent kontorlandskap, men da man ofte er avhengig å diskuterer løsninger vil det også bli aktuelt å jobbe fra andre steder. Under bygging og testing av systemet vil man hele tiden være hos BEKAS. Det er også mulighet å dra dit for veiledning. Dette gjelder hele perioden, uavhengig av prosjektfase. 3.2 Hardware komponenter Valg av utstyr, komponenter og programvare har i stor grad blitt bestemt av oppdragsgiver. Som beskrevet (kap 1.3) er BEKAS, i tillegg til systemleverandør, også grossist. Det har da vært helt naturlig å benytte seg av komponenter og utstyr fra leverandører som de fører. Presenterer her de viktigste komponentene i realiseringen av oppgaven. Datablad for hardware finnes i Appendiks I Datablad. Siemens Simatic PLS CPU 1510SP-1 PN CPU-en inkluderer operativsystemet og utfører brukerprogrammet. Brukerprogrammet er plassert på SIMATIC minnekortet og blir behandlet i arbeidsminnet til CPU-en. Da CPU-en bruker PROFINET opprettes kommunikasjon med PROFINET enheter, PROFINET kontrollere, HMI-enheter, programmeringsenheter og andre styringsenheter. CPU 1510SP-1 PN støtter operasjon som en IO-controller, I-enhet eller frittstående CPU. Siemens Simatic ET 200SP DI 16x24VDC ST, Digital input modul. Digital inngangsmodul men 16 innganger. Passer for tilkobling av brytere og 2-lags sensorer i samsvar med IEC 61131, type 3. Kanal-baserte konfigurerbar inngang med forsinkelse 0,05 ms til 20 ms. Rev: v (39)

14 Siemens Simatic ET 200SP DQ 16x24VDC/0.5A ST, Digital output modul. Digital utgangsmodul med 16 utganger. Utgangsspenning på 24 V, utgangsstrøm 0,5 A per kanal. Passer for magnetventiler, DC kontaktorer og indikatorlamper. Siemens Simatic ET 200SP TM Count 1x24V, Pulsteller Én kanals, 32 bits pulsteller. Omron 24V Power Supply 230 VAC til 24 VDC omformer. Phoenix Contact, FL WLAN 510x WLAN aksesspunkt, repeater eller klient. Opererer på 2,4 eller 5,0 GHz ISM båndet. Støtter WLAN standardene: a, g og n. Brukes her som masteraksesspunkt. Phoenix Contact, FL WLAN EPA WLAN aksesspunkt eller repeater. Opererer på 2,4 eller 5,0 GHz ISM båndet. Støtter WLAN standardene: a, g og n. Brukes her som slaveaksesspunkt. Leine & Linde, Incremental Rotary Decoder 560 Pulsgenerator Rev: v (39)

15 3.3 Software komponenter Programvare var også gitt av oppdragsgiver, dette er programmer som i utstrakt grad brukes i industrien. Siemens Totally Integrated Automation Portal (TIA) Denne programvaren fra Siemens optimaliserer planlegging av maskin- og prosessprosedyrer og tilbyr et standardisert og integrert betjeningskonsept. Det integrerer sømløst kontrollere, distribuert I/O, HMI, stasjoner, bevegelseskontroll og motorstyring i et program. Grunnet felles datastyring og smart bibliotek konsept fungerer dette til alle automatiseringsoppgaver. [3] Zucken E3.schematic E3.schematic brukes til å tegne og dokumentere elektriske styresystemskjemaer E3.schematic er kjernen til alle E3.series moduler og gir elektronikkingeniører en enkel løsning for å designe og dokumentere elektriske styringssystemer inkludert skjematiske diagrammer, terminalplaner og PLS'er. Dens objektorienterte arkitektur gir en helhetlig og konsistent designtilnærming som bidrar til å eliminere feil og forbedre kvaliteten. [4] 3.4 Konklusjon Ut fra valgene som har blitt tatt av oppdragsgiver angående komponenter og leverandører av disse, samt programvare som skal bli brukt under gjennomføring, kan vi ikke se at dette kunne blitt gjort på noen annen måte. Alt utstyr leveres av kjente produsenter og er utstyr som i utstrakt grad brukes i industrien. Det vil på denne måten være mulig å gjøre seg kjent med utstyr og programvare som man kan ta i bruk også ved senere anledninger. Retningslinjer for prosjektgjennomføring er satt av BEKAS og vil bidra til innsyn i hvordan dette fungerer, og gi relevant erfaring. Rev: v (39)

16 4 Realisering av valgt løsning Etter grundig gjennomgang av kravspesifikasjon og analyse av problemstilling sammen med veileder fra BEKAS, samt innhenting av all tilgjengelig dokumentasjon på systemet som skal utskiftes ble det dannet er konkret bilde av problemet som skal løses. Av tidligere dokumentasjon ble det gitt tilgang på tegninger og oversikt over allerede monterte komponenter som skal gjenbrukes. Dette er en oppgave med mange steg og utstrakt bruk av ukjent programvare, det er derfor viktig at hvert steg godkjennes av veileder før neste steg igangsettes. Dette for å forminske sjansene for følgefeil og unødvendig ekstraarbeid. Det ble også lagt vekt på at alle deltar på alle steg for maksimalt læringsutbytte. 4.1 Teknisk tegning Det har blitt lagd grundige og detaljerte styrestrømskjemaer over systemet som skal bygges i nye styreskap. Tegningene inneholder alt av informasjon som en tavlemontør trenger for å bygge skapene og vil bli gitt oppdragsgiver etter igangkjøring slik at det foreligger en skjematisk oversikt som brukes ved feilsøking og vedlikehold. Da det er en del komponenter som skal gjenbrukes fra gammelt system og allerede tilkoblede kabler er det svært viktig å sette seg inn i virkemåten, navngiving og merking av dette da det ønskes at nytt utstyr skal kunne kobles på lettest mulig måte uten å måtte forandre tidligere navn og nummer på komponenter. Det ble tegnet seks skap totalt, derav tre styreskap med PLS og tre mindre skap for trådløs kommunikasjon. Valget om å adskille komponentene for kommunikasjon i egne skap ble gjort da det er viktig at disse står nærmest mulig antennen for å unngå unødvendig signaltap. Et av de tre hovedskapene er også utstyrt med en 7 HMI skjerm i døren. Bortsett fra dette, er det brukt samme komponenter i dette skapet som i de to andre. Siden dette skapet inneholder HMI ble det valgt som master, der de to andre fungerer som slaver. Dette er noe som man ikke trenger å ta hensyn til i tegningene, men kun når det kommer til programmering av skapets PLS. De mindre skapene for kommunikasjon er også inndelt i et masterskap og to slaver, forskjellen her er modulen for trådløs dataoverføring. Masterskapet har et noe annerledes aksesspunkt en de to andre. Alle komponenter og leverandører av disse er beskrevet i detalj i tegningene, det er også kabelnummer og rekkeklemmer. Dette gir en svært god oversikt over alle skap og deres virkemåte. Alt av tegning har blitt gjort med programmet E3.schematic som er levert av Zuken. Appendiks E Teknisk tegning inneholder tegningene i sin helhet samt liste over komponenter med fabrikat som er brukt i styreskapene. 4.2 Verkstedarbeid Da tegningene var ferdige og alle komponenter var bestilt inn begynte arbeidet med bygging av de fysiske skapene. Det ble bygget seks skap, tre styreskap og tre mindre skap for kommunikasjon. Dette er en jobb som vanligvis de verkstedansatte tar seg av, men i dette tilfellet ble det gjort av oss da læringsutbyttet av å montere skap etter egne tegninger er veldig stort. Alle komponenter er montert i skap på DIN-skinner, og alt av komponenter, samt kabler, er navngitt og nummerert i henhold til tegninger. Å merke alle kabler og utstyr gir en god oversikt og gjør feilsøking enkelt. All montering og kabling med fargekoder er gjort i henhold til bransjestandard og BEKAS sin egen standart. Rev: v (39)

17 4.3 PLS programmering Etter analyse og diskusjon rundt forskjellige fremgangsmåter for implementering av logikken bak programmet ble programmeringen igangsatt. Valget om å kjøre en master og to slaver ble fulgt. Masterprogrammet tar seg av all kalkulasjon, derav blant annet posisjonsberegning, og henter informasjon fra slavene. Slavene mottar kun informasjon i tillegg til noen enkelte innstillinger som kan gjøres uten innblanding av masterprogrammet, dette gjelder kalibrering, preset og alarmer. Videre ble styringen av hver enkelt kran delt inn i fem hovedprogramgrupper bestående av ett eller flere programmer som igjen er koblet opp mot datablokker. Hele programmet er skrevet i Siemens Totally Integrated Automation Portal, og programmeringsspråket er SCL. Programmering og testing av systemets virkemåte ble gjort parallelt (kap 5). Fullstendig program for master og slave ligger i henholdsvis Appendiks G Program master, og i Appendiks H Program slave Programforklaring MASTER: Startup [OB100]: Første OB som kjøres. Denne blokken blir bare kjørt første syklus ved oppstart av PLS-en. Denne OB en starter kun opp FB30-Startup_prog Startup_prog[FB30]: Blir startet av OB100. Sjekker om variabelen bevegelse er i aktivert. Hvis den er aktivert, betyr det at kranen har vært i bevegelse under oppstart og det blir gitt alarm. Startup_DB[DB30]: DB til FB30 Main [OB1]: Denne blokken har som oppgave å starte alle andre Function Blocks. Den setter også ett SW bit til pulstelleren. ALARMER[DB90]: En DB som har alle alarmer i både int og struct. Cycle interrupt [OB30]: Blir brukt til å lage en puls som igjen blir brukt til hartbeat og kommunikasjon. Figur 3: Programoversikt Rev: v (39)

18 100 Hovedstyring: Hovedstyring_prog [FB100]: Blir brukt til å bestemme hvilke kraner som skal stoppe i hvilken retning, i tillegg til slow, ved hjelp av flagg som blir satt av FB102-Stoppsjekk_prog. Programmet sjekker også hvilke kraner som skal ha krokforrigling, dette gjøres også ved bruk av flagg satt av Krokforrigling_prog. Krokforrigling_prog [FB101]: Sender inn posisjon til kran 1 og 3 inn i FC111-Krokforrigling_funk og tar ut ett boolsk flagg som forteller om de er for nærme. Gjør deretter det samme med kran 2 og 3. Stoppsjekk_prog [FB102]: Sender parvis inn posisjon til en kran og en hindring inn i Stoppsjekk_funk, sender også inn avstand for slow, stopp og alarm som blir satt av FB103-Avstand_beregning_prog. Hindringer er alle kranene i tillegg til veggen. Ut får vi boolske verdier på stopp, slow og alarm som videre blir gitt til de rette flaggene. Det er på bakgrunn av disse flaggene som bestemmer om Hovedstyring_prog skal aktivere eller deaktivere stopp, slow og alarm. Avstand_beregning_prog [FB103]: Sender inn parvis to kraners avstandsparametere (stoppavstand, slowavstand og alarmavstand) til FC113-Avstand_beregning_funk. Sender også inn en bolsk verdi for retning og én for bevegelse. Tar ut en avstand i retur som blir satt til rett avstandsvariabel. Det er denne variabelen som blir brukt av FB102-Stoppsjekk_prog. Varsling_prog [FB110]: Aktiverer varsellys og horn for alle kranene baser på hvilke alarmer som er aktivert. Programmet tar hensyn til hvilke alarmer som er aktivert og hvilke forbikoblingsbrytere som er aktivert. Hvis ikke S1 er forbikoblet og en alarm går, skal HORN og Lyd aktiveres. Krokforrigling_funk[FC111]: En funksjon som tar inn to posisjoner og regner ut om de er for nærme ved hjelp av en avstandsvariabel som er felles for alle kraner. Stoppsjekk_funk[FC112]: Denne funksjonen tar inn to parameter, posisjon til en kran, og posisjon til en hindring. Blir kalt av FB102-Stoppsjekk_prog for å se om en kran og en hindring må stoppe. For å vite om det skal legge til forrigling, må man vite om kranen allerede er i stopp og slow derfor tas initialslow og initialstopp inn. FC113-Avstand_beregning_funk[FC113]: Denne funksjonen tar inn posisjon, alrm-, stopp- og slow-avstandene, og informasjon om bevegelse til to kraner. Dersom kranene beveger seg mot hverandre blir avstandene lagt til. Dersom kranene beveger seg fra hverandre brukes den minste avstanden. Ellers brukes den største avstanden. 200 Kalibrering: Kalibrering_prog [FB200]: Kalibreringen blir først aktivert fra HMI-skjerm. Brukeren må kjøre kranen til 1S1, og deretter til en bestemt posisjon som blir skrevet inn i HMI-skjermen. Denne posisjonen blir gitt brukt videre. Kalibreringen blir fullført når brukeren trykker på en annen knapp i HMI-Skjermen. Rev: v (39)

19 Preset_prog [FB201]: Setter kranen sin posisjon lik den én av to posisjonen som er lagret for presetbryteren som blir aktivert. 300 Kommunikasjon: Hartbeat_prog [FB301]: Sender ut en boolsk verdi som den forventer å få returnert uendret. Ved neste utsendelse av signalet, vil signalet bli negert. Slik kan det sjekkes om vi har kontinuerlig kommunikasjon ved at signalet som gis i retur vil hele tiden toggle. Når signalet toggler vil en timer bli resatt. Dersom det har gått en gitt tid uten at telleren blir resatt, vil timeren løpe ut og en alarm vil bli gitt. Kommunikasjons_prog [FB300]: Sender ut og mottar signal til og fra alle andre kraner, bestemt av en teller. Telleren blir resatt når alle kranene har sendt og mottatt data. Telleren blir inkrementert av OB30-Cycle interrupt. 400 Parameter: Parameter_felles_prog [FB401]: Holder alle fellesparameterene, og har en default-funksjon som setter alle verdier til en defaultverdi. Parameter_kran_prog [FB400]: Holder alle parameterene knyttet til kranen, og har en default-funksjon som setter alle verdier til en defaultverdi. Parameter_avstand_prog[FB402]: Holder alle avstandsparameterene for alle kranene, og har en default-funksjon som setter alle verdier til en defaultverdi. 500 Posisjon: Posisjon_prog [FB500]: Tar inn antall puls fra pulsteler og gjør om til meter Programforklaring SLAVE: Main [OB1]: Denne blokken har som oppgave å starte alle andre Function Blocks. Den setter også ett SW bit til pulstelleren. Startup [OB100]: Første OB som kjøres. Denne blokken blir bare kjørt første syklus ved oppstart av PLS-en. Denne OB en starter kun opp FB30-Startup_prog. Startup_prog [FB30]: Blir startet av OB100. Sjekker om variabelen bevegelse er i aktivert. Hvis den er aktivert, betyr det at kranen har vært i bevegelse under oppstart og det blir gitt alarm. Rev: v (39)

20 100 Hovedstyring Forriglinger_prog [FB120]: Setter alle utganger, forriglinger, horn og lys, sendt fra master. Hvis forbikoblingsbryteren er aktivert vil alle forriglinger og alarmer gå av. Hvis kommunikasjonsalarmen er aktivert, vil alle forriglinger og alarmer gå på, så lenge forbikoblingsbryteren ikke er aktivert. 200 Kalibrering Kalibrering_prog [FB200]: Kalibreringen blir først aktivert fra HMI-skjerm. Brukeren må kjøre kranen til 1S1, og deretter til en bestemt posisjon som blir skrevet inn i HMI-skjermen. Denne posisjonen blir gitt brukt videre. Kalibreringen blir fullført når brukeren trykker på en annen knapp i HMI-Skjermen. Preset_prog [FB201]: Setter kranen sin posisjon lik den én av to posisjonen som er lagret for presetbryteren som blir aktivert. 300 Kommunikasjon Hartbeat_prog [FB310]: Sender samme signal mottatt av master i retur. 400 Parameter Parameter_kran_prog [FB400]: Holder alle parameterne knyttet til kranen, og har en default-funksjon som setter alle verdier til en defaultverdi. 500 Posisjon Posisjon_prog [FB500]: Tar inn antall puls fra pulsteler og gjør om til meter. Rev: v (39)

21 4.4 HMI programmering En 7 Siemens Simatic Comfort HMI skjerm er montert i det ene styreskapet. Denne ble programmert til å gi en oversikt over kranene i systemet, hvor de befinner seg til enhver tid og hvilken tilstand de er i. Det vil si: - fri(kranen kan bevege seg fritt i begge retninger) - slow(kranen nærmer seg hindring og kan kun bevege seg sakte) - stopp(kranen har møtt hindring og kan ikke bevege seg). HMI-skjermen inneholder i tillegg til dette undermenyer for parameter, alarmer og kalibrering. Parameter: Vedlikeholdspersonell har her mulighet for å endre parameter for hver enkelt kran i tilfellet endringer av det fysiske systemet har blitt foretatt. Det er også mulighet for å endre avstander til slow og stop, samt noen alarminnstillinger. Alarmer: Oversikt over alle alarmer og deres status. Dersom en alarm er gitt og blitt kvittert ut av bruker havner den i en liste over siste alarmer. De 1000 siste alarmene lagres i HMI skjermen sin RAM og vil ikke bli påvirket av strømbrudd. Kalibrering: Bruker har mulighet til å kalibrere hver enkelt kran. 4.5 Manual Det har blitt skrevet en detaljert manual som leveres sammen med igangkjøring av systemet hos kunde. Dette for å beskrive virkemåte av programmet og bruk av HMI skjermens funksjoner. Manualen ligger som Appendiks F Brukermanual. Rev: v (39)

22 5 Testing Under store deler av programmeringsperioden ble også testing av systemet utført. Ved å kjøre disse stegene parallelt var det enklere å luke ut feil på tidlige tidspunkt. Teststasjon ble satt opp på eget område på BEKAS sitt verksted. Her ble det brukt pulsgeneratorer og diverse knapper og brytere for best mulig og kunne simulere systemet som er montert hos Kværner. Dersom feil ble oppdaget ble dette korrigert i systemets program og testet på nytt til tilfredsstillende resultat ble oppnådd. Når det gjelder toleranse og nøyaktighet er det helt fastsatte verdier som skal gi forrigling og alarmer. Noen av disse parameterne kan endres av bruker dersom nødvendig, verdiene som er blir satt vil til enhver tid være det som bestemmer nøyaktigheten på systemet. Det ble laget detaljerte sjekklister for en systematisk gjennomgang av programmets funksjoner, og for å kunne fange opp alle feil på en effektiv måte. Disse sjekklistene ligger som Appendiks J Sjekkliste. Hovedsteg innen testing. 1. Stoppfunksjoner Her testes kommunikasjonen mellom alle PLS-er. PLS-ene gir riktig slow og stopp signal til alle kraner. At dette vises både i watch-table (en oversiktstabell over valgte variabler med verdi i PLS-programmet) og på HMI og at systemet fungerer som det skal ved kommunikasjonsbrudd. At systemet oppfører seg som det skal dersom forbikoblingsbryter aktiveres. 2. Kalibrering Preset Her testes kalibreringsprogrammet. Passer på at kalibrert kran får oppdaterte verdier uten at det går ut over andre kraners verdier. Tester at endebrytere fungerer som de skal. 3. Oppstart Parameter beholder sin verdi Her testes det at alle parameter for alle kraner beholdes ved strømbrudd. 4. Alarm For nærme Her testes det at alarm blir gitt dersom kranene befinner seg nærmere hindring enn tillatt. Alarm deaktiveres når problemet løses og kvitteres ut via HMI-skjerm. Både horn, lys og alarm på HMI vises korrekt. 5. Alarm Kommunikasjon Her testes det at riktig alarm blir gitt ved alle typer kommunikasjonsbrudd. Horn, lys og alarm på HMI vises korrekt og tilbakestilles ved ny oppnådd kommunikasjon. 6. Alarm Bevegelse under oppstart Her testes det at sikkerhetssystemet oppdager bevegelse av kraner under strømbrudd. Gir korrekt alarm og beskjed om rekalibrering. Rev: v (39)

23 6 Igangkjøring I forkant av igangkjøring ble styreskapene sendt til kunde for montering. Kværner brukte sine egne ansatte til denne delen av jobben. Da skapene var montert reiste vi til Stord og Kværner for å sette systemet i drift. Til dette arbeidet ble det avsatt tre dager. 6.1 Klargjøring Før vi begynte å teste måtte alle kablene kobles fra de gamle styreskapene, og inn til de nye. Dette tok litt lengre tid enn antatt grunnet manglende markering av ledere. 6.2 Kommunikasjon Kommunikasjonen var det første som ble igangkjørt. Første problemet vi støttet på her var at to av kommunikasjonsskapene så ut som om de ikke fikk spenning. En koblingsfeil var årsaken til problemet og raskt fikset. Et litt større problem var at vi fikk alt for mange kommunikasjonsalarmer. Første løsningsforslaget var å slå opp tiden master skulle vente på kommunikasjon før den slo alarm. Grunnen til at dette ikke løste problemet helt var at i tillegg til denne tidsinnstillingen, var det også en kommunikasjonsalarm i hver slave. Når denne tidsforsinkelsen ble økt, forsvant problemet. 6.3 Virkemåte Under igangkjøring av forriglingene ble det informert om endringer i virkemåten til kranene. Det var ikke nødvendig at kranene stoppet mot veggen, grunnen til dette var at kranene allerede hadde en innebygd styring som tok seg av dette. De øverste kranene skulle heller ikke stoppes når de kom nærme hverandre, dette var fordi kranene skulle kunne kjøres helt inntil hverandre og kjøres parallelt for å løfte ekstra stor last. Rev: v (39)

24 6.4 Posisjonsberegning Det ble problemer med posisjonsmålingen. I ett forsøk på å lokalisere feilen, ble det tatt lasermålinger i tillegg til målingene som kranene selv gjør ved hjelp av pulsgeneratoren. På kran 1 fant vi ut ved hjelp av Excel at posisjonen var veldig nøyaktig så lenge kranen ble kjørt i en retning, og at feilen oppstår når vi kjører motsatt retning. Retningen som er nøyaktig er samme retning som kranen kjører når den kalibreres. Motsatt retning gir en lineær målefeil DIfferanse k1-k3 k1-laser k3-laser Figur 4: Måledifferanse Figur 5: Pulsgenerator, side En av grunnene kan ha vært en løs arm og et slitt hjul. I figur 5 ser vi hjulet fra siden. Dette er ett av kranens hjul. Oppå hjulet hviler pulsgeneratoren, denne holdes på plass av en stålarm. Stålarmen henger igjen fast til selve kranen i en hengsel. Rev: v (39)

25 Figur 6: Pulsgenerator ovenfra og forfra På figur 6 ser vi hjulet og pulsgeneratoren fra oven og rett på. Det slitte hjulet er overdrevet skissert, men det ble anslått ca. en millimeter slitasje på hjulet. Denne slitasjen gjorde at armen pulsgeneratoren var koblet fast på beveget seg fra side til side. En side når man kjørte i en retning og en side når man kjørte i motsatt retning. Rev: v (39)

26 Utregning for feilrate per meter. Uttrykt matematisk som målefeil i cm per meter ( l l ). O = 2πr O 2π 0,2m O 1,3 m O = 2π r O 2π 0,1cm O 0,628cm l l l l = O O 2π 0,1cm 2π 0,2m l l 0,5 cm m 0,5% Dette vil altså resultere i en halv centimeter feil per meter, eller 0,5%. Dette problemet skal utbedres av Kværner. Det vil bli sveiset på støttearmer om holder pulsgeneratoren til fast posisjon. 6.5 Alarmer Etter at kommunikasjonsalarmene ble fikset, fungerte alarmene som de skulle. Et problem var at kunden ikke var fornøyd med hornets og varsellysets virkemåte. Det var ønsket at hornet og lyset skulle gå av etter en gitt tid. Dette ble løst ved at vi implementerte en timer som gjorde at hornet og lyset gikk av etter en gitt stund, denne tiden la vi inn som ett parameter som kan stilles i HMI-skjermen. Rev: v (39)

27 7 Oppsummering med diskusjon Oppgaven var helt fra starten tydelig angående hvordan systemet skulle fungere og hvilke hjelpemidler og programmer vi hadde tilgjengelig. Alle krav var satt og jobben ble da å tilpasse seg dette på best mulig måte. Det ble lagt en tydelig plan tidlig i prosjektfasen, en plan som ble forsøkt holdt så godt som mulig gjennom hele perioden. Det har vært et omfattende arbeid å realisere dette prosjektet. Arbeidet startet med teknisk tegning, det krevde en del tid da dette var en ny teknikk og et nytt program som tok tid å sette seg inn i. Resultatet ble imidlertid bra og førte til en god oversikt over koblingene da bygging av styreskapene skulle igangsettes. Under byggingen ble det klart et det måtte foretas enkelte små endringer i tegningene, da noen komponenter ikke kunne kobles på den måten det først ble antatt. Programmering av PLS-en var det mest omfattende elementet i denne oppgaven. Det ble lagd en plan for hvordan det var ønskelig at den skulle programmeres, men flere endringer ble gjort underveis for å få systemet til å fungere optimalt. Det ble fokusert på å lage en logikk som ville gjøre det enkelt å gjøre endringer og enkelt å legge til en ny kran dersom dette skulle bli aktuelt. Programmeringen og testing gikk hele tiden parallelt og dette fungerte veldig bra. Selv om systemet var testet grundig kom det opp en del småendringer som ble gjort under igangkjøring hos Kværner. Slik vi ser det kunne ikke dette blitt unngått da det alltid vil være forskjeller og nye problemer å ta hensyn til ute i industrien, noe som man vanskelig kan forutse. Kommunikasjonen mellom oss og Kværner har gjennom hele perioden gått via BEKAS. Da bortsett fra den siste perioden på tre dager hvor igangkjøringen tok sted. Dette har ført til at enkelte ønsker fra Kværner ikke ble ivaretatt under programmeringen, rett og slett fordi det ikke hadde blitt opplyst om. Det var også noe nye informasjon om virkemåte av traverskranenes egne innebygde sikkerhetssystem som først ble opplyst om under igangkjøring. Dersom kommunikasjonen hadde gått direkte til oss, og ikke via BEKAS, ville muligens noen av disse opplysningene kommet bedre fram tidligere i prosessen. Det ville igjen ført til en enklere programmeringsjobb da ønsket virkemåte ville vært bedre dokumentert, og programmet kunne blitt skrevet på en enklere måte. På den andre siden har vår oppdragsgiver hele tiden vært BEKAS og det har vært naturlig at kommunikasjonen har gått via dem. En mulig løsning på dette var om vi tidlig i fasen hadde dratt til Kværner, hatt en grundig gjennomgang av gammelt utdatert system, sett kranene i aksjon og blitt enige om hva de ønsker med det nye antikollisjonsystemet. Da dette ikke ble gjort var resultatet at PLS-programmet måtte skrives noe om under igangkjøring for å ivareta Kværners behov for systemet. Så dersom prosjektet skulle blitt gjort på nytt ville vi absolutt besøkt Kværner tidligere, det ville løst mange småproblemer og unødvendig mange spørsmål. Det endelige systemet er derimot tilfredsstillende i forhold til funksjonalitet, brukervennlighet og kvalitet. Et av målene var at det nye systemet skulle være bedre enn det som hadde vært der tidligere. Dette har vi oppnådd blant annet ved hjelp av HMI-skjermen hvor brukeren enkelt kan kalibrere, få oversikt over alarmer, endre parametere med mer. Dette gjør at brukeren selv kan tilpasse systemet etter egne behov. Kværner har fått ett nytt og velfungerende antikollisjonssystem. Vi er veldig fornøyd med læringsutbytte og ett godt utført arbeid. Rev: v (39)

28 Appendiks A Litteraturliste [1] «BEKAS.no,» [Internett]. Available: [Funnet 19 Januar 2015]. [2] «Kvarner.no,» [Internett]. Available: [Funnet Mai 2015]. [3] «Siemens Totally Integrated Automation Portal (TIA),» [Internett]. Available: [Funnet 21 mai 2015]. [4] «Zucken E3.schematic,» [Internett]. Available: [Funnet 21 mai 2015]. Rev: v (39)

29 Appendiks B Forkortelser og ordforklaringer Her skal relevante forkortelser og ordforklaringer komme i alfabetisk rekkefølge. Husk at forklaring på forkortelser tas med i dokumentet første gang en forkortelse brukes, eks: Orthogonal Frequency Division Multiplexing (OFDM). BEKAS HMI PLS SCL FBD OB FB DB FC SW HW Watch-table Bergen Elektrokompetanse AS Human-Machine Interface Programmerbar Logisk Styring Structured Control Language Function Block Diagram Organization Block Function Block Data Block Function Software Hardware En oversiktstabell over valgte variabler med verdi i PLS-programmet Rev: v (39)

30 Appendiks C Prosjektledelse og styring Medlemmene på bachelorprosjektet er Anders Steen Nilsen, Agnes Flatmo og Ole Martin Larsen. Vi har valgt å likestille oppgaven oss imellom, da vi anser alle oppgaver som like viktige og kunnskapsgivende. Hvis det skulle vise seg etter en stund at vi må dele opp ansvarsområdene for å få tid til å bli ferdige blir det gjort da. Prosjektansvarlig og veileder fra BEKAS er Peter Alexandersson. Veileder ved HIB er Emil Cimpan. C.1 Fremdriftsplan Kravspesifikasjon Engineering elektrisk anlegg Innkjøp av utstyr Bygging av styreskap Programmering av PLS og HMI Test av utstyr og program på vårt verksted Bruker manual Installasjon og test av anlegget hos kunden Overlevering av anlegg og dokumentasjon Fakturering Rev: v (39)

31 Appendiks D Tilbud Blir kun lagt ved i elektronisk utgave. Rev: v (39)

32 Appendiks E Teknisk tegning Master Rev: v (39)

33 Appendiks F Blir kun lagt ved i elektronisk utgave. Teknisk Tegning Slave Rev: v (39)

34 Appendiks G Brukermanual Blir kun lagt ved i elektronisk utgave. Rev: v (39)

35 Appendiks H Program master Rev: v (39)

36 Appendiks I Program slave Rev: v (39)

37 Appendiks J Datablad Blir kun lagt ved i elektronisk utgave. Rev: v (39)

38 Appendiks K Sjekkliste Rev: v (39)

39 Appendiks L Bilder Rev: v (39)