Styring : for teknisk fagskole, linje for elektro, fordypningsområde automatisering 8241204582 [PDF]

Zitiervorschau

Trym Staal Eggen

Styring For teknisk fagskole, linje for elektro, fordypningsområde automatisering

NB Rana Depotbiblioteket

o

Vette Viten as

© Vett & Viten AS 2000 ISBN: 82-412-0458-2

Utgitt med støtte fra Kirke-, undervisnings- og forskningsdepartementet. Boka er beregnet for elever i teknisk fagskole, linje for elektro, fordypningsområde automatisering. Det må ikke kopieres fra denne boka i strid med åndsverkloven eller avtaler om kopiering inngått med Kopinor, interesseorgan for rettighetshavere til åndsverk. Kopiering i strid med lov eller avtale kan medføre erstatningsansvar og inndragning, og kan straffes med bøter eller fengsel.

Utforming/sats: Jan Hugo Strand Printed in Norway 2000 by Preutz Grafisk as, Larvik Utgiver: Vett & Viten AS Postboks 203, 1379 Nesbru Telefon adm: 66 84 90 40 Telefon ordrekontor: 66 98 39 80 Telefax: 66 84 55 90 http:Wwww.vettviten.no e-post: [email protected]

Forord Boken tar sikte på å gi en grunnleggende innføring i styresystemer. Temaet er så stort at det er nødvendig å begrense seg både i bredde og dybde. Derfor har vært nødt til å treffe valg og gjøre prioriter­ inger. Slike valg kan selvsagt diskuteres, og det finnes ingen fasitsvar. Det er helt umulig for en bok av begrenset størrelse å kunne gi detaljerte svar på alle spørsmål man vil komme på når man setter seg inn i materien. Det henvises til de hyllemeter med manu­ aler som leverandørene utstyrer sine kunder med. Det anbefales snarest å begynne og gjøre seg fortrolig med manualene og bruken av disse. Det er først tatt med et kapittel om tradisjonelle relékoplede sys­ temer, men i hovedsak er boken bygget opp omkring Programmer­ bare Logiske Styringer - PLS. Det finnes mange leverandører av PLS, og hver har gjerne et større eller mindre spekter av produkter. Det finnes heller ingen standard. Det har derfor vært nødvendig å treffe valg. Valget har falt på Siemens S7, som programmeres under Windows. Det som blir vist av metoder, kunne generelt like gjerne vært vist på andre merker, som Allen-Bradley, ABB eller andre. Boken ville ikke sett veldig annerledes ut om den hadde vært bygd opp om PLS fra en annen leverandør. Distribuert I/O er et område i sterk utvikling og som sannsynligvis bare vil bli viktigere og viktigere. Det er derfor tatt med et større kapittel om PROFIBUS. Mange kan mene at dette kapitlet kan være uhensiktsmessig stort og tungt. Mange vil ikke ha bruk for detaljerte kunnskaper om PROFIBUS, men det er hovedsakelig tatt med for spesielt interesserte.

Hvert hovedkapittel er avsluttet med noen kontrolloppgaver, og siste kapittel består utelukkende av programmeringsoppgaver.

Ris og ros samt forslag til forbedringer tas imot med takk på email HYPERLINK mailto:[email protected] [email protected]. Til slutt vil jeg rette en takk til Bjørnar Larsen for tips og råd i star­ ten.

Haute-Loire, Frankrike, juli 2000 Trym Staal Eggen

5

o

INNHOLDSFORTEGNELSE

Innholdsfortegnelse I

Relékoplede styresystemer 8 1.1 Arbeidsforhold for kontaktorer og reléer 8 1.1.1 Sekvensdiagram 10 1.2 Reléer 11 1.2.1 Oppbygning og virkemåte 11 1.2.2 Det magnetiske kretsløpet 12 1.2.3 Klebing 12 1.3 Kontakter og kontaktfunksjoner 14 1.4 Statiske kontaktorer og reléer 14 1.5 Reléer med forsinket inn- og utkopling 16 1.5.1 Faste forsinkelser 16 1.5.2 Forsinket utkopling (frafallsforsinket) 17 1.5.3 Forsinket innkopling 17 1.5.4 Forsinket innkopling og utkopling 18 1.5.5 Hurtig innkopling 19 1.5.6 Reléer med flere spoler 19 1.5.7 Forsinket innkopling og normal utkopling 20 1.5.8 Forsinkelser ved både ved inn- og utkopling 20 1.5.9 Tidsreléer - regulerbare forsinkelser 21 1.5.10 Praktisk bruk av tidsreléer 23 1.6 Impulsreléer (fjernbrytere) 31 1.7 Elektroniske reléer 31 1.8 Logikkreléer 32 1.9 Fordeler og ulemper ved å bruke relékoplede styresystemer 32 1.9.1 Fordeler 33 1.9.2 Ulemper 33 1.10 Kontrollspørsmål 33

2

PLS - en introduksjon 35 2.1 Bakgrunn og historikk 35 2.2 Kontrollspørsmål 36

3

Definere og strukturere styringsoppgaven 37 3.1 Planlegging av et prosjekt 37 3.2 Dele prosessen inn i frittstående deler 38 3.3 Beskrive de enkelte prosessdelene 40 3.4 Sikkerhetskrav 43

3.5 Definere operatørpaneler og andre betjeningsorganer 45 3.6 Lage konfigureringsdiagram 46 3.7 Kontrollspørsmål 47 4

Montere og kople opp PLS 49

4.1 4.2 4.3 4.4 4.5 5

Hva vi må vite før vi begynner 49 Installering av PLS 50 Elektrisk oppkopling av PLS 50 Tilkopling av programmeringsenhet eller PC 50 Kontrollspørsmål 50

Programmeringsverktøy 51 5.1 Ulike typer 51 5.2 Programmeringsverktøyet STEP 7 52 5.3 Bruk av programmeringsverktøyet STEP 7 52 5.4 STEP 7-objekter 53 7

Innholdsfortegnelse

5.5 Lage en ny prosjektstruktur 54 5.6 Kontrollspørsmål 54 6

Konfigurere og tilordne parametre 55 Hva det vil si å konfigurere og tilordne parametre? 55 Hvordan man konfigurerer og tilordner parametre 55 Start med å nullstille CPU-hukommelse 55 Hvordan konfigurere og tilordne parametre 56 Tilordne parametre 58 Kontrollspørsmål 60

6.1 6.2 6.3 6.4 6.5 6.6

7 Programmere logikkblokker med STEP 7 61 7.1 Prosedyre for programmering av blokker 61 7.2 Hvordan lage de nødvendige blokkene 62 7.3 Programmering 62

7.4 7.5 7.6 7.7 8

Nedlasting (downloading) og testing av brukerprogrammet Grunnleggende prosedyrer for nedlasting og testing 77 Hvordan nedlaste brukerprogrammet til PLS 77

8.1 8.2 8.3 8.4 8.5 9

STL-programmering 63 LAD-programmering 68 FBD-programmering 71 Kontrollspørsmål 75

Testing 79 VAT-blokk 84 Kontrollspørsmål 87

Mer komplekse program

89

9.1 Generelt 89 9.2 Nettverk, titler og kommentarer 89 9.3 S- og R-funksjoner 92 9.4 Timere (tidsfunksjoner) 94 9.4.1 SD-timer (Start-on Delay) 94 9.4.2 SP-timer (Start Pulse) 96 9.4.3 SE-timer (Start Extended Pulse) 96 9.4.4 SS-timer (Start Retentive On-Delay Timer) 97 9.4.5 SF-timer (Start Off-Delay Timer) 97 9.5 Tellere 97 9.5.1 Opp-teller S-CU 98 9.5.2 Ned-teller S_CD 99 9.5.3 Opp/ned-teller S_CUD 99 9.6 Markører eller flagg (bit memory) 100 9.7 Blokktyper 102 9.7.1 Organisasjonsblokker (OB) og Interrupt 102 9.7.2 Tidsinterrupt-OB (Time-of-Day Interrupt) (OB10 til OB17) 104 9.7.3 Maskinvareinterrupt 104 9.7.4 Funksjon (FC) 106 9.7.5 Funksjonsblokker (FB) 106 9.7.6 Systemfunksjoner (SFC) 106 9.7.7 Systemfunksjonsblokker (SFB) 106 9.8 Datablokker 107 9.8.1 Felles datablokker 107 9.8.2 Instansdatablokker 108 9.9 Symbolsk adressering - tilordningsliste 109 9.10 Kryssreferanseliste 117 9.11 Sammenlikninger 119 9.12 Typer av sammenlikninger 120 9.12.1 Likhet (==) 120 8

77

INNHOLDSFORTEGNELSE

9.12.2 Ulikhet () 120 9.12.3 Større enn (>) 120 9.12.4 Større enn eller lik (>=) 120 9.12.5 Mindre enn ( Station -> SIMATIC 300 Station eller Insert -> Station -> SIMATIC 400 Station for å opprette en stasjon.

Stasjonen gis automatisk et navn som SIMATIC 300 Station(l) eller SIMATIC 400 Station(2). Dersom vi ønsker det, kan vi endre navn­ et til noe mer logisk eller forståelig.

56

KONFIGURERE OG TILORDNE PARAMETRE

Figur 41 En sammensetning av S7-400 Når stasjonen er opprettet, må den konfigureres i henhold til den maskinvare som stasjonen virkelig er satt sammen av. Ved å dobbeltklikke på «Hardware»-ikonet i høyre halvdel av prosjektvinduet på figur 42 får vi opp konfigureringsvinduet på figur 43.

Figur 42 Klar til å åpne konfigureringsvindu I konfigureringsvinduet som er vist på figur 43, er det nettopp hent­ et et monteringsskap (rack) fra maskinvaremenyen til høyre. Monteringsskapet hentes på vanlig Windows-måte, enten ved at det ønskede skap dobbeltklikkes eller ved at det holdes og trekkes med musen.

57

Kapittel 6

Nå som vi har monteringsskapet, må vi fylle det opp med modul­ er. Modulene er først og fremst strømforsyning, prosessor, I/Omoduler og eventuelle kommunikasjonsmoduler. HW

fHiNdwiiin

RF1 H

Btandci «nlASIMATIC 410 Slrtmn |l| "|

88 j M?£k1ÉN3II3N

Cfl?

ER1 fA2 UR2 URI

I

mæraææzr m

ubi

Figur 43 Korrfigureringsvindu med monteringsskap (rack) Når vi vet hvordan en PLS er satt sammen, er det vår jobb å bygge opp en konfigurasjon som er lik den fysiske virkeligheten. Gjør vi ikke det, får vi problemer med å få PLS-en i drift.

Dersom vi leser på modulen helt til venstre, er det strømforsyning. Alle modulene, inklusive monteringsskapet, har påstemplet et bestillingsnummer. Bestillingsnummeret hjelper oss også med å finne frem i jungelen av valgmuligheter i menyen. Et aktuelt nummer på strømforsyningen kan være 6ES7 405-0RA00-0AA0, og vi finner et valg med dette nummeret i folderen PS-400. Vi kan plassere modulen inn i posisjon nummer 1 i monteringsskapet ved enten å trekke den dit, eller vi kan merke posisjonen for så å dobbeltklikke på modulen i menyfolderen.

6.5 Tilordne parametre Når vi skal tilordne parametre til en modul, er det ikke nødvendig å sette opp bryterinnstillinger eller gjøre noe fysisk på modulen. Konfigureringen gjøres ved å sette inn parametre i STEP 7 via dia­ logbokser. For å kunne starte å tilordne parametre til en modul:

1. Vis stasjonens konfigurasjon med monteringsskinner. 2. Dobbeltklikk på den modulen der vi vil endre parametre.

Nå åpner det seg en dialogboks som inneholder modulens egen­ skaper. I dialogboksen kan parametre som styrer modulens egen­ skaper endres eller skrives inn. 58

Konfigurere og tilordne parametre

For eksempel har det vært nevnt at vi kan sette en markørbyte til å bli pulserende flagg med ulike frekvenser. La oss se på dette som et eksempel på tilordning av parametre. Se figur 44. For å tilordne parametre til en modul, høyreklikker vi på den aktuelle modulen i vinduet nederst i vinduet HW Config. Da dukker det opp en dialogboks, hvor vi velger Object Properties.

Figur 44 Tilordne parametre til prosessormodulen

Nå dukker bildet på figur 45 opp, og her er det mye å velge mell­ om - det er hele 9 ark. Det er mange parametre vi kan stille på for å tilpasse modulen til spesielle ønsker og behov. Hvis vi ser på arket som heter General, så kan vi der blant annet stille inn nettverksadresse for modulen. La oss gå til arket som heter Cycle/Clock Memory.

I dette vinduet bestemmes blant annet hvor lang tid det aksepteres at prosessoren bruker på å kjøre gjennom programmet. I vårt tilfelle er fabrikkinnstillingene maksimalt 250 ms og minimalt 0. Kanskje vi har en applikasjon med et program og en utrustning som gjør at 250 ms rett og slett er for kort tid. Eller kanskje vi har en situasjon der det stilles absolutte krav om at syklusen ikke tar over eksemp­ elvis 100 ms. Skulle programgjennomløpet ta lenger tid enn mak­ simalt tillatt, går prosessoren i stopptilstand. Årsaken kan for eksempel være feil i programmet eller maskinvaren. Videre kan vi stille inn en korteste syklus, for eksempel 20 ms. Der­ som prosessoren skulle klare å komme rundt raskere enn minste­ kravet vi har satt, vil den vente med neste gjennomløp slik at nytt gjennomløp starter med minst 20 ms intervall.

Dersom vi klikker på sjekkboksen Clock Memory, vil vi aktivere en markørbyte til å «blinke» med faste frekvenser. I utgangspunktet er

59

Kapittel 6

det byte 0, men vi kan fritt velge en annen i feltet nederst midt på vinduet. Den byte som blir brukt, kan ikke brukes til mellomlagringer eller annet!

Figur 45 Vindu for tilordning av parametre

6.6 Kontrollspørsmål 1. Hva vil det si å konfigurere et prosjekt? 2. Må vi alltid konfigurere prosjektet? 3. Må konfigurasjonen i programmet være lik den fysiske virke­ lighet? 4. Hvilken interesse har vi av det som måtte være påstemplet hver modul når vi skal konfigurere prosjektet? 5. Hva vil det si å tilordne parametre? 6. Trenger vi alltid å tilordne parametre? 7. Hva forstår du med Scan Cycle Monitoring Time? 8. Hva skjer dersom Scan Cycle Monitoring Time overskrides? 9. Hvordan kan vi enkelt skaffe et signal som blinker fast med en viss frekvens, for eksempel til en blinkende varsellampe?

60

PROGRAMMERE LOGIKKBLOKKER MED STEP 7

Kapittel 7

Programmere logikkblokker med STEP 7 7.1 Prosedyre for programmering av blokker Dersom vi vet hvilke funksjoner som skal legges inn i brukerpro­ grammet, er det relativt lett å skrive programmet som skal lastes ned i prosessoren.

Brukerprogrammet kan bestå av kun én enkelt blokk, organisasjonsblokk 1 (OB1). Vi kan legge programlogikken inn i OB1, men det er ikke vanlig metode. OB1 er, som navnet antyder, en blokk som har som oppgave å organisere programflyten. OB1 er ment brukt til å bestemme rekkefølgen på utførelsen av andre blokker der selve programmet ligger. I OB1 kan vi, i det enkleste praktiske tilfellet av et program, legge et kall på en funksjon. Vi kan tenke oss at all programlogikken ligger i funksjonen som kalles opp. OB1 inneholder da intet annet enn det ene oppkallet. Funksjonen kan normalt være en funksjon FC1. I FC1 ligger den logikken vi som programmerer har bestemt at PLS-en skal utføre.

Figur 46 Enkelt program med to blokker - OB1 og FC1

En OB er et grensesnitt mellom prosessorens operativsystem og brukerprogrammet. Organisasjonsblokken bestemmer når bruker­ programmet skal utføres. En funksjon (FC) er en minneløs blokk som kan overføre para­ metre. En FC kan med fordel brukes til å utføre hyppig gjentatte oppgaver. Når vi skal programmere blokker, begynner vi med å etablere blokkene og bestemme hvilken av de tre programmeringsmetodene som skal brukes: instruksjonsliste, bryterdiagram eller funksjonsplan. Når en blokk er etablert, har vi en tom blokk som kan kalles opp av OB1 eller andre blokker. Men vi har ikke lagt noe logikk inn i den, så den kan selvsagt ikke utføre noe som helst. Dersom den kalles opp, vil den bare returnere til det punktet der den ble kalt opp fra uten å ha gjort annet enn å bruke litt tid for prosessoren. Derfor må vi skrive selve brukerprogrammet inn i funksjonen. I redigerings-

61

Kapittel 7

programmet (editoren) deklarerer vi variabler og skriver inn pro­ grammet. Brukerprogrammet er normalt delt opp og lagt inn i nett­ verk (network), men et kort og ukomplisert program kan legges inn i bare ett nettverk. Prosedyre for programmering av blokker

Etablere blokker: • Etablere FC1 og bestemme programmeringsmetode: STL, LAD eller FBD.

Programmere blokker: • Starte redigeringsprogram (editor), deklarere variabler og skrive program inn i nettverk. Lagre og laste ned blokker: • Lagre blokker på harddisk og laste dem ned (download) til prosessor.

Tabell 9 Prosedyre for programmering av blokker

7.2 Hvordan lage de nødvendige blokkene I tabellen nedenfor er beskrevet trinn for trinn hvordan programblokker lages. Prosedyre

Resultat

Åpne prosjektet i SIMATIC Manager med menykommandoen File —* Open -* Project...

Prosjektvinduet for det aktuelle prosjektet åpnes.

o

Apne boksene for prosjektet helt ned til nederste nivå ved å klikke på «+» og velg så boksen «Blocks».

Vi ser OB1 som er lagret i boksen «Blocks».

Velg menykommando Insert -» S7 Block -» FC. Nå vises en dialogboks, der vi velger den ønskede programmeringsmetode (STL, LAD eller FBD) og bekrefter med å klikke på «OK».

FC1 og OB1 vises i prosjektvinduet på SIMATIC Manager.

Tabell 10 Prosedyre for å lage blokker

7.3 Programmering I begynnelsen skrives programmet offline på PC-en, uten at vi trenger å ha noen fysisk forbindelse mellom PC og PLS. Det er først når vi har et program som vi forventer har en mulighet til å virke, eller at vi overhodet ser behovet for å prøve produktet, at vi prøv­ er å laste programmet ned til prosessoren. Vi har i dag avanserte testfunksjoner for å sikre at programmet er så feilfritt som mulig før det overføres til PLS-en. Når programmet er ferdig skrevet, over­ føres det via programmeringsgrensesnittet til PLS-en.

62

Programmere logikkblokker med STEP 7

Vi må velge om vi ønsker å bruke instruksjonsliste, bryterdiagram eller funksjonsplan. Noen ganger kan vi være tvunget til å velge instruksjonsliste, fordi det er den kraftigste metoden. Det er ikke alt vi kan klare å utføre med de andre to metodene.

7.4 STL-programmering STL står for Statement List, og på norsk kalles det ofte for instruk­ sjonsliste. Metoden går i korthet ut på å skrive programmet i en for­ enklet tekstform som en slags høynivåprogrammering. Instruk­ sjonene følges av adresser.

I STEP 7 er det STL-programmering som er den kraftigste variant­ en. Ved å velge STL-programmering oppnås optimal utnyttelse av minne og optimal prosessorhastighet. Sagt på en annen måte vil STL-programmering gi den mest kompakte kompilerte koden. Dessuten er ikke alle muligheter i STEP 7 overhodet tilstede i LADog FBD-programmering. Derfor er det bare et spørsmål om tid før vi tvinges til å ta i bruk STL-programmering dersom vi programm­ erer mye og prøver å løse varierte problemer.

Vi kan tenke oss at vi nettopp har opprettet følgende prosjekt, med programblokkene OB1 og FC1. OB1 og FC1 er kun opprettet, og ingenting annet er gjort med dem. Følgelig er de tomme.

Ete

Edit

[ns«t

PLC

Vww

Opbon®

Wndow

-|g|x|

Help

D|i*|P|g| x|^|e| Aj 3|% System DaHa

O 0B1

-HlSIMATIC 300 Stahon (1]

a

[g CPU312IFM

É tT| S7 Programfl)

E

S ource Fiies ea Biocks

Press Fl lor hdp.

Figur 47 SIMATIC Manager-vindu med nyopprettet FC1

63

Kapittel 7

Brukerprogrammet som inneholder alle logiske funksjoner, legges for mindre programmer normalt i FC1. For å åpne FC1 for å komme i gang med programmeringen, dobbeltklikker vi på ikonet FC1 i det store vinduet til høyre. Da åpnes vinduet i figur 48.

Figur 48 Tom FC1 åpnet for programmering i første nettverk Siden vi her skal programmere i STL, bør vi forsikre oss om at STL er valgt som programmeringsmetode. Det gjøres ved å velge View på nedtrekksmenyen øverst på siden, og klikke på valget STL. Den metoden som er valgt, vil være markert med en hake. Dersom STL er valgt, gjør det ikke noe fra eller til om vi likevel klikker på STL som valg.

Når vi har åpnet FC1 og valgt programmeringsmetode STL, er tiden kommet for å skrive inn brukerprogrammet. Nå klikker vi en gang med venstre museknapp i det rektangulære feltet under det grå feltet som er merket «Comment:». Det kan hende rektangelet ikke vises, men da må vi likevel klikke på det stedet der rektangel­ et vises på figur 48.

For å begynne med noe enkelt, kan vi tenke oss at vi ønsker at de to inngangene 1124.0 og 1124.1 begge må være logisk «1» for at utgang Q124.0 skal gå til logisk «1». Alle andre kombinasjoner på inngang­ ene vil føre til at Q124.0 går til logisk «0». Dette vil gi følgende sannhetstabell:

64

Programmere

logikkblokker med

Inngang 1124.0

1124.1

Q124.0

0

0

0

0

1

0

1

0

0

1

1

1

STEP 7

Tabell 11 Sannhetstabell 1

Dette tilsvarer en OG-funksjon (AND function), og kan realiseres ved følgende lille STL-program: A A =

I 124.0 I 124.1 Q 124.0

Det engelske navnet på funksjonen forklarer hvorfor de to første linjene starter på «A». De tre linjene skrives ganske enkelt inn i rektangelet. Det er viktig å huske på minst ett mellomrom mellom «A» og «I» i de to første programlinjene. Hver linje avsluttes med ENTER-tasten. Vi trenger ikke å ta hensyn til små eller store bok­ staver, og dersom vi bruker små bokstaver, vil de ferdige linjene fremstå med store bokstaver så snart ENTER-tasten er trykket og redigeringsprogrammet (editoren) har godkjent linjen. Følgelig kunne linjen vært skrevet som følger:

a il24.0 a H24.1 =ql24.0

Programmeringsvinduet vil nå se ut som på figur 49.

Figur 49 To-inngangs OG-port 65

Kapittel 7

Tenk nå at vi ønsker at utgang Q124.0 skal gå til logisk «1» dersom minst en av inngangene 1124.0 eller 1124.1 er logisk «1». Bare der­ som begge innganger er logisk «0», så vil Q124.0 gå til logisk «0». Dette gir følgende sannhetstabell:

Inngang 1124.0

1124.1

Q124.0

0

0

0

0

1

1

1

0

1

1

1

1

Tabell 12 Sannhetstabell 2

Dette tilsvarer en ELLER-funksjon og vil se slik ut når den er skrev­ et inn i editeringsvinduet: O I 124.0 O I 124.1 = Q 124.0 Vi kan også for eksempel tenke oss den endringen at vi ønsker at inngang 1124.1 skal være logisk «0» for at ELLER-funksjonens utgang skal bli logisk «1». Da blir sannhetstabellen seende slik ut: Inngang 1124.0

1124.1

Q124.0

0

0

1

0

1

0

1

0

1

1

1

1

Tabell 13 Sannhetstabell 3

O I ON I = Q

124.0 124.1 124.0

Dette blir det samme som en ELLER-port med en av inngangene INVERTERT. Det kan også ses på som to brytere i serie der den ene er en normalt lukket hvilebryter.

Nå er det noe vesentlig vi har glemt for at programmet skal kunne virke. Brukerprogrammet ligger i funksjon FC1. Men FC1 gjør ingen verdens ting før den blir kalt opp! For at FC1 skal kjøres, må OB1 kalle den opp. OB1 er en organisasjonsblokk, og den kjøres en gang for hver gang prosessoren gjennomløper programminnet. OB1 opprettes automatisk når prosjektet opprettes, men den er tom helt til vi skriver noe inn i den. For at FC1 skal kjøre, må den kalles opp fra OB1. Vi må da åpne OB1 for editering akkurat som FC1, og skrive inn kallet. OB1 vil nå i sin enkleste form bli seende ut som på figur 50.

66

Programmere logikkblokker med STEP 7

Figur 50 OB1 med kallet av FC1 OB1 blir seende lik ut enten vi velger STL-, LAD- eller FBD-programmering. Dersom vi laster prosjektet ned i prosessoren og kjører det, vil pro­ gramflyten være som vist på figur 51.

Figur 51 Programflyt for OB1 med FC1

Programstrukturen på figur 51 er noe av det enkleste vi kan ha. Her kjøres OB1 en gang for hvert gjennomløp av minnet. Organisasjonsblokken OB1 blir automatisk generert av SIMATIC Manager. OB1 kjøres av prosessoren for hvert gjennomløp av programminnet, enten vi har lagt noen instruksjoner inn i den eller ikke.

67

Kapittel 7

I vårt tilfelle er det første (og eneste) som skjer i OB1, at FC1 blir kalt opp. Så kjører FC1 og utfører det den skal i henhold til brukerpro­ grammet. Når FC1 er kjørt ferdig, returnerer prosessoren til det punkt der OB1 ble forlatt. Derfra vil prosessoren gå videre nedover i OB1 og utføre neste instruksjon dersom det finnes flere instruk­ sjoner å utføre. Siden det ikke er skrevet mer kode inn i OB1 enn dette ene kallet, returnerer prosessoren til begynnelsen av OB1, og forløpet gjentas.

7.5 LAD-programmering LAD-programmering, også kalt kontaktplan eller bryterdiagram, går ut på at programmet «tegnes» som et system av brytere. Vi kan forestille oss at vi har en imaginær spenning på venstre side av arket eller skjermen. På høyre side av arket eller skjermen har vi manipulerbare funksjoner som vil slås på hvis de får spenning fra venstre. Mellom den imaginære spenningskilden til venstre og en av funksjonene til høyre er det et mer eller mindre komplisert nett­ verk av kontakter. Kontaktnettverket kan være alt fra en kontakt og til et ubegrenset antall kontakter i et komplisert nettverk. Den manipulerbare funksjonen blir slått på når den blir spenningssatt via en eller flere veier gjennom kontaktnettverket. I grafisk form vil programmet ofte kunne minne om en stige slik det fremstår på arket eller skjermen, og derfor kalles metoden gjerne stigediagram (ladder). Metoden vil ofte falle naturlig for elektrikere, som er vant til å tenke i form av kontaktorer og brytere.

For å komme i gang med LAD-programmering, velger vi LAD i stedet for STL i «View»-menyen.

Figur 52 viser hvordan OG-funksjonen som er beskrevet i kapitlet om STL-programmering, vil fremstå i vinduet til redigeringsprogrammet (editoren). Vi ser at begge de to bryterne må være lukket for at utgangen til høyre i editoren skal kunne «få spenning» fra venstre side og dermed gå til logisk «1». Er en eller begge de to bryterne åpen, forblir utgangen Q124.0 logisk «0». Dersom funksjonsmenyen til høyre i bildet ikke er vist, kan den vises ved å klikke på knappen som er vist på figuren. Funksjons­ menyen kan dras ut i høyre kant av skjermen slik det er vist på figur 52, eller den kan trekkes ut og plasseres på skermen som et lite vindu. Videre er noen av de mest vanlige funksjonene vist på verktøylinjen ved siden av funksjonsmenyknappen. Når vi ønsker å starte programmeringen, plasseres markøren i programmeringsfeltet, akkurat som i STL-programmering. For å legge inn den første kontakten, som skal være normalt åpen, kan vi klikke på knappen for normalt åpen kontakt på verktøylinjen. Som et alternativ kan vi åpne den øverste boksen «bit logic» i funksjons­ menyen til høyre. Derfra kan vi enten med musen «trekke» kon­ takten ut i programmeringsvinduet eller dobbeltklikke på kontaktsymbolet.

68

PROGRAMMERE LOGIKKBLOKKER MED STEP 7

Figur 52 OG-funksjon i LAD-programmering Den neste kontakten plasseres så til høyre for den første kontakten. I dette tilfelle vil kontakt nummer to plasseres riktig av seg selv hvis vi klikker to ganger (ikke dobbeltklikker, men rolig klikker to ganger) på kontaktsymbolet på verktøylinjen. Ellers kan vi manuelt plassere markøren før vi klikker, eller vi kan hente kontaktfunksjonen fra menyvinduet ved å plassere markøren og så dobbelt­ klikke eller bare «holde og dra» kontaktfunksjonen til ønsket posi­ sjon. Figuren viser OG-funksjonen på LAD-form. Inngang 1124.0 er gjort ferdig, mens den andre kontakten og utgangen ikke er tilegnet noen adresser enda. For å adressere kontakten og utgangen plasseres markøren på de røde spørsmålstegnene, og så skrives adressen der. Vi kan også flytte rundt på nettverket med TAB-tasten. Figur 53 viser hvordan ELLER-funksjonen vil se ved LAD-programmering. At det her dreier seg om en ELLER-funksjon vil vi se ved å studere programmet. Her kan vi tenke oss at det er en spenn­ ing på venstre side av vinduet. Denne tenkte «spenningen» prøver å drive en «strøm» over til høyre side av vinduet, gjennom det nett­ verket som befinner seg mellom de to «potensialene». Vi ser av figuren at en eventuell «strøm» må gå gjennom utgangen Q124.0. «Strømmen» ville aktivere Q124.0. For at «strømmen» skal kunne komme til Q124.0, må den finne vei enten gjennom 1124.0 ELLER

69

KAPITTEL 7

1124.1. Vi ser at det holder med at en av de to «kontaktene» lukkes - altså 1124.0 ELLER 1124.1. Om begge lukkes samtidig, vil det selv­ sagt også gjøre samme nytten! Men skulle begge innganger være åpne «uaktivert», blir det ingen «strøm», og følgelig ingen aktiver­ ing av utgangen.

Figur 53 EEEER-funksjon i EAD-programmering

Her er det sannsynligvis mest lettvint og hensiktsmessig å legge inn den øverste kontakten, 1124.0, først, for så å legge inn utgangen. Så kan markøren plasseres til venstre for 1124.0, og så klikkes ikonet «Open Branch» (det fjerde ikonet til venstre for funksjonsmenyikonet) på verktøylinjen. Så klikkes det ønskede kontaktikonet før grenen fullføres med «Close Branch»-ikonet på verktøylinjen. Husk å legge inn adressene! Skulle vi ønske å ha en av inngangene invertert, velger vi «Normally Closed Contact» i stedet for «Normally Open Contact». Da blir programmet seende ut som på figur 54. Fortsatt søker den tenkte «spenningen» på venstre side å drive «strøm» gjennom og aktivere utgangen Q124.0 på høyre side. Ser vi på den øverste grenen, 1124.0, er det en normalt åpen kontakt som må aktiveres for å lukke seg. Altså må den fysiske inngangen 1124.0 til PLS-en ha logisk signaltilstand «1» for at det skal komme «strøm» til Q124.0 gjenn­ om den øvre grenen.

70

5

Programmere logikkblokker

med

STEP 7

Ser vi på den nedre grenen, er det en normalt lukket hvilekontakt. Det betyr at når inngang 1124.1 har logisk tilstand «0», og altså ikke er aktivert, så er det «forbindelse» fra «spenningen» på venstre side og til utgangen Q124.0 på høyre side gjennom den nedre grenen. Når den fysiske inngang 1124.1 blir aktivert av logisk signaltilstand «1», så blir den nedre grenen brutt ved at «kontakten» åpner. Dette er verd å merke seg!

Figur 54 ELEER-funksjon med en «hvilekontakt» realisert i EAD-programmering

7.6 FBD-programmering FBD-programmering kalles på norsk gjerne funksjonsplan- eller logikkplanprogrammering. Metoden går ut på å sette sammen log­ iske komponenter som blant annet OG- og ELLER-porter i redigeringsprogrammet (editoren). Metoden faller gjerne naturlig for folk med digitalteknisk bakgrunn og forståelse, og for folk som er mate­ matisk orientert. Vi kan se på de enkle eksemplene fra STL- og LAD-kapitlene og se hvordan de tilsvarende løsningene blir i FBD-programmering. Praktisk sett foregår programmeringen mye på samme måte som LAD-programmering, ved at vi henter funksjonene fra funksjons­ menyen til høyre. Vi kan enten «trekke» dem til ønsket posisjon

71

Kapittel 7

eller sette markøren på ønsket posisjon for så å dobbeltklikke på funksjonen. Noen få av de mest brukte funksjonene ligger fast på verktøylinjen. Der finner vi OG-port, ELLER-port, tilordning (eng­ elsk: assignment) for utgang fra funksjonen samt et par andre vi vil komme tilbake til.

Nå skal vi først se på den enkle OG-funksjonen, og hvordan den kan programmeres med FBD-metoden. Når vi har åpnet den tomme FC1, må vi gå inn i «View»-menyen og velge FBD. Vi kan begynne med å sette markøren i det tomme «programrektanglet». Så klikker vi på knappen for OG-port på verktøylinjen. Dermed dukker det opp en OG-port i rektangelet som vi må tilordne inn- og utganger for, som vist på figur 55.

Figur 55 OG-port uten tilordnede inn- og utganger

Her er det vår jobb å tilordne innganger og utganger. Vi kan begynne med inngangene: vi setter markøren på de røde spørsmålstegnene og skriver inn adressene, som på figur 56. For å tilordne utgangen, setter vi markøren på utgangen til høyre på porten og klikker på tilordningsknappen. Da får vi en blokk hengt på utgangen, der vi kan skrive inn utgangsadressen Q124.0.

Hvordan vil dette programmet virke når det kommer i drift i pro­ sessoren?

72

Programmere logikkblokker med STEP 7

Figur 56 OG-porten med inn- og utganger tilordnet

Inn på OG-porten går de to inngangene 1124.0 og 1124.1. Er begge inngangene høye, eller logisk «1», så blir utgangen av OG-porten, og dermed utgangen Q124.0, logisk «1». Alle de tre andre kom­ binasjonene vil gi utgang lik logisk «0».

Dersom vi ønsker at utgangen skal være logisk «0» bare hvis begge innganger er logisk «0» og logisk «1» i ethvert tilfelle der minst en av inngangene er logisk «1», så bruker vi en ELLER-port i stedet for OG-porten. I programmeringsvinduet blir ELLER-porten seende ut som på figur 57. Skulle vi ønske å gi betingelsen at den nederste inngangen 1124.1 skal være logisk «0» for å kunne aktivere utgangen fra ELLER-port­ en, kan inngangen INVERTERES. Vi husker at vi i STL-programmeringen da skrev ON 1124.1

(Or Not Input 124.1 = Eller Ikke Inngang 124.1)

I LAD-programmeringen brukte vi normalt lukket hvilekontakt i stedet for normalt åpen arbeidskontakt i diagrammet for å gi som betingelse at et binært signal skal ha logisk tilstand «0».

73

Kapittel 7

Figur 57 ELLER-port i FBD

Når vi skal bruke BOOLSK algebra i portform, markeres en invertering gjeme som en liten ring på signallederen umiddelbart inntil en inn- eller utgang. Figur 58 viser ELLER-porten med inn­ gang 1124.1 invertert.

Hvis vi tar utgangspunkt i ELLER-porten på figur 57, så kan pro­ grammet modifiseres til ELLER-port med en invertert utgang ved følgende prosedyre (se også trinnene på figur 58):

1. Sett markøren på den inngangen som skal inverteres. 2. Klikk på INVERTER-ikonet på verktøylinjen. Dersom vi skulle ønske å fjerne inverteringen igjen, så gjøres det på nøyaktig samme måte; vi plasserer markøren på rett sted og klikk­ er på INVERTER-knappen.

74

Programmere logikkblokker med STEP 7

Figur 58 INVERTERING av en av ELEER-portens innganger

7.7 Kontrollspørsmål 1. Vis en to-inngangs OG-funksjon slik den er realisert på hver av de tre programmeringsformene. 2. Vis en tre-inngangs ELLER-port på hver av de tre programmer­ ingsformene. 3. Hva er en INVERTERING? 4. Hvordan er en INVERTERING vist i hver av de tre program­ meringsformene? 5. Hva er en OB, og hvordan brukes den? 6. Hvilken logikkblokk MÅ være med i brukerprogrammet? 7. Er det teknisk mulig å nøye seg med bare OB1 i brukerpro­ grammet? 8. Er det «god skikk og bruk» å nøye seg med bare OB1?

75

Nedlasting (downloading) og testing av brukerprogrammet

Kapittel

8

Nedlasting (downloading) og testing av bruker­ programmet 8.1 Grunnleggende prosedyrer for nedlasting og testing Nå har vi sett eksempler på hvordan vi kan skrive noen meget enkle programmer. Det vi hittil har sett er så enkelt at det bare danner en innledning til teknikken.

Når vi har skrevet programmet, er tiden kommet for å laste det ned (engelsk: download) i prosessorens programminne og teste det ut før vi kan sette programmet i drift. Det er tidligere beskrevet hvordan programmeringsenheten koples opp mot prosessoren. Det forutsettes her at forbindelsen er i orden og at vi har kontakt (online).

Vi kan enten laste ned hele programmet eller enkeltblokker. Men vi kan bare teste en blokk av gangen. Nedlasting og testing kan kort beskrives ved følgende punkter:

• • -

Last ned programmet til prosessoren Test STL-, LAD- eller FBD-blokken: Åpne blokken ONLINE Definer innstillingene for testvinduet Definer triggebetingelsene Velg testmiljø Start og avslutt testen

8.2 Hvordan nedlaste bruker­ programmet til PLS Før vi kan laste ned programmet eller delblokker av programmet, må følgende være oppfylt:

77

Kapittel 8

• Vi må ha en ONLINE-forbindelse mellom programmeringsenheten og prosessoren. • Programmet som skal lastes ned, må være kompilert uten feil. • Prosessoren må være i STOP- eller RUN-P-tilstand. Hva vil det si at programmet er kompilert uten feil? Å kompilere betyr, enkelt sagt, å oversette programmet til en kode prosessoren forstår. Når vi editerer programmet, enten i STL-, LAD- eller FBDmodus, så foregår det på en engelskbasert eller intuitiv måte som mennesker relativt enkelt kan klare å forstå. Programmet slik det fremstår på PC-skjermen er imidlertid uforståelig for prosessoren. Derfor må programmet oversettes (kompileres) før det kan lastes ned.

Har vi programmert feilfritt, vil kompileringen fullføres uten feil. Når vi her sier «feilfritt», betyr ikke det nødvendigvis at pro­ grammet vil gjøre den tiltenkte jobben feilfritt! Hvis vi behersker det norske språk 100 % perfekt, kan vi fortelle en historie skriftlig eller muntlig uten en eneste språklig feil. Innholdet i historien kan derimot være løgn og bedrag fra ende til annen! Vi kan som pro­ grammerere ha tenkt feil og gjort grove feil. Men dersom vi ikke har forbrutt oss mot reglene for hvordan koden skal se ut, vil vi få kom­ pilert programmet feilfritt. Da gjenstår det å se under testingen om programmet virker som vi har tenkt oss det.

Nå er det en ting som er viktig å huske dersom vi laster ned indiv­ iduelle blokker for uttesting. Blokkene kalles opp av organisasjonsblokker, i utgangspunktet OB1. Når OB1 kaller på en blokk, er det meget viktig at den oppkalte blokken eksisterer i programminnet! Studer figur 59 og prøv å tenk hva som vil skje når FC2 kalles opp!

Figur 59 Programstruktur med manglende blokk

I tilfellet på figur 59 vil OB1 prøve å finne FC2, som ikke er lastet ned i programminnet. Følgelig eksisterer ikke FC2 for prosessoren. Prosessoren prøver å gjøre noe vi som programmerer har bedt den om, men som er umulig. Vi får en feil som vil stoppe prosessoren! Ellers er det også klart at for å teste en blokk, så må det eksistere kall til blokken. Se figur 60. Nå har vi situasjonen at FC2 eksisterer i programminnet. Men vi har glemt å skrive inn noe kall for den, og følgelig blir FC2 aldri kjørt!

Figur 60 Blokken FC2 eksis­ terer, men blir aldri kalt opp!

For å laste ned programblokkene, se figur 61. Vi kan enten laste ned programmet i sin helhet, eller vi kan velge hvilke blokker som skal lastes ned.

.

78

For å velge hvilke programblokker som skal lastes ned, åpnes pro­ sjektet helt ned til det viste nivå. Merk OB1 og FC1 ved å holde SHIFT-knappen nede og venstreklikk begge to. Begge blokker vil da bli blå av farve som vist. Klikk så på nedlastingsknappen.

Nedlasting (downloading) og

testing av brukerprogrammet

For å kunne se på det nedlastede programmet i prosessoren, må vi skifte til ONLINE-modus. Det gjøres ved å klikke på ONLINEknappen på verktøylinjen (se figur 61). Nå vil det sannsynligvis komme opp en dialogboks, der vi bør velge «Complete Restart», så klikke «OK» og «Close».

Nå har prosessoren startet opp helt fra bunnen av, som om den skulle bli slått på fra strømløs tilstand. Det er nemlig forskjell på bare å skifte fra STOP-tilstand til RUN-tilstand og fullstendig restart. Forskjellene er mer omtalt under kapitlet Blokktyper.

8.3 Testing Før et brukerprogram kan tas i bruk, må det testes ut. Vi har en del ulike metoder for å teste programmer. Normalt må vi laste pro­ grammet ned i prosessoren for å teste det ut. I og med at vi over­ hodet har klart å kompilere og nedlaste programmet, er det sann­ synligvis programteknisk korrekt, så vi kan si at vi har fått en delvis test på programmet. Men det er ikke dermed sagt at programmet vil gjøre sin jobb slik vi har tenkt oss det! Som det tidligere er nevnt, kan vi fortelle mange rare løgner på et perfekt norsk språk!

79

Kapittel 8

Normalt er testing og utvikling av programmet en fortløpende og langvarig prosess. Utvikling av et brukerprogram blir fort en lang­ varig og stor jobb, ofte med flere personer i samarbeid. Program­ strukturen vil gjerne være logisk inndelt i blokker som logisk gjen­ speiler den fysiske prosessen som skal styres. Og programmeringsjobben vil gjerne være fordelt på de personene som gjør jobben. Det er ikke slik at vi bare skriver programmet og så setter oss ned og tester det til slutt.

Enten vi har en gruppe programmerere som har delt jobben mell­ om seg eller om hele jobben blir utført av en person, består veien mot det endelige resultat av mange kortere og lengre etapper, og hver etappe består igjen av mange små skritt. Det kompliserte slutt­ produktet består egentlig bare av mange små biter, som hver for seg ikke er så veldig vanskelige å få oversikten over. Testingen bør som oftest deles inn i små deler. Hver gang vi har en liten del ferdig utviklet, bør den lille funksjonen testes for seg så godt det lar seg gjøre. Det er langt lettere å teste en liten enhet med kanskje bare et par I/O og en eller to logiske byggestener enn det er å vente til alle brikkene er ferdig satt sammen til et stort og uov­ ersiktlig byggverk. Selvsagt må hele det store systemet testes i sin helhet til slutt, men først når alle brikkene er testet for seg.

Vi må også huske på forsiktighetsregler ved programtest. Ofte er en PLS der for å styre farlige maskiner med mye energi. Det kan være varme, elektrisitet eller farlige bevegelige deler som sager, bor eller hammere. Vi må passe nøye på hva vi gjør så ikke økonomiske verdier eller, enda verre, liv og helse settes i fare. Når vi har skrevet en liten programblokk som vi vil teste, lastes blokken ned i prosessoren. Så må vi ha et kall, gjerne fra OB1 for å kunne kjøre blokken syklisk. Vi må også ha med tilhørende data­ blokker hvis det er relevant.

Det er mange lure «knep» vi kan bruke, og vi vil lære oss våre egne arbeidsmetoder etterhvert som vi får erfaring. Hvis vi ser på pro­ grammet nedenfor, er det ikke så mange linjer. Men skulle vi prøve å kjøre det i en test, så kan det fort bli litt av en jobb å sjekke ut eventuelle feil. En måte å gjøre det lettere, er å begynne i det små og bare kjøre litt av programmet først. Network 1 :

Comment: A M 0.5 A I 124.3 AN M 2.1 = Q 124.0 BE //Midlertidig BE. Programmet kjøres kun hit!

80

Nedlasting (downloading)

og testing av brukerprogrammet

Network 2 : Comment:

AN Q 124.0 = Q 124.6

Network 3 : Comment: A Q 124.0 CU C 0 BLD 101 NOP 0 NOP 0 A T 0 R C 0 L C 0 T MW 1 NOP 0 NOP 0

Network 4 : Comment:

L L ==I L SD = BE

MW 15

1

S5T#20S T 0 M 2.1

Hvis vi setter inn en midlertidig BE (Block End) tidlig i programm­ et, så vil prosessoren bare kjøre programmet så langt. Så prøvekjør­ er vi programmet og ser at alt går bra så langt, før vi flytter BE-kommandoen ørlite nedover til det første hensiktsmessige sted og prøvekjører på nytt.

Her kunne vi starte med å sette den midlertidige BE-kommandoen på slutten av første nettverk. Men vi kan også, dersom det er hen­ siktsmessig, sette BE-kommando midt i et nettverk, som nedenfor.

81

Kapittel 8

Network 3 : Comment:

A Q 124.0 CU C 0 BLD 101

/ /BE-kommando satt inn midt i nettverket

NOP 0 NOP 0 A T 0 R C 0 L C 0 T MW 1 NOP 0 NOP 0 Det er også mulig å hindre en programlinje i å kjøres ved å «kom­ mentere» den bort. A kommentere bort en linje er det samme som å slette linjen, da den ikke vil oppfattes av prosessoren. Men det er antagelig lurere å la linjen stå som en kommentar, fordi det er lett­ ere å fjerne kommentarmerket enn å huske hvor linjen stod og nøy­ aktig hvordan den så ut.

Kommentarmerket består av to skråstreker (engelsk: slash) «/ /». Network 3 :

Comment:

//

A Q 124.0 CU C 0 BLD 101

Denne linjen er «kommentert» bort og vil ikke kjøres

NOP 0 NOP 0 A T 0 R C 0 L C 0 T MW 1 NOP 0 NOP 0 Skulle det være vanskelig, kostbart eller farlig å teste programmet på vanlig måte, finnes det et tilleggsverktøy tilgjengelig for å simul­ ere. Vi kan kjøpe programpakken PLC Simulation, som er et verktøy som lar oss simulere at vi har tilkoplet en PLS mot programmeringsdatamaskinen. Når PLC Simulation er startet, kan vi på en helt realistisk måte og uten bruk av S7 maskinvare late som om vi laster ned programmet med alle blokker og konfigurering. Så kan vi «starte» PLS-en og teste programmet vårt på en naturtro

82

Nedlasting (downloading)

og testing av brukerprogrammet

måte. Skulle programmet inneholde feil som ville gi problemer for en ekte PLS, så ville vi få de samme problemene med vår simulerte prosessor. SIMAIII

[l)P Sy*h>m 2

ål E>*

p|i»lBy|g|

L1**

H !Sl SIMATIC 40CI11 E H CPU 4174

II» E

i: V>iRinMiz^NtepASZpiP_!>y±_1)

r°~

Hon M eicck:

Asm Fl togOlHeto.

Figur 62 PLC Simulator

Og ingenting vil eksplodere, gå i stykker eller løpe løpsk dersom vi har tenkt feil et eller annet sted! Selv om programmet har latt seg kompilere og nedlaste, er det hell­ er ikke sikkert at det lar seg kjøre. Vi har sett at dersom OB1 skulle inneholde oppkall av blokker som ikke er lastet ned, vil prosessor­ en ikke klare å håndtere situasjonen, og prosessoren går i stå. Vi har i SIMATIC Manager avanserte testverktøy som hjelper oss å teste ut og drive feilsøkning på program. Vi kan bare teste en pro­ gramblokk om gangen. For å teste programmet, må vi alltid velge følgende innstillinger først: • Definere triggevilkår • Velge testmiljø • Definere innstillinger for testvindu Hva betyr disse valgene?

83

Kapittel 8

Triggevilkår betyr valgte betingelser for at blokken skal kalles opp. Vi har tre hovedvalg: Test environment innebærer to valgmuligheter: «Process» og «Laboratory».

Tester vi i STL, kan vi i testvinduet velge de statusfelter vi ønsker å se på. Tester vi i LAD eller FBD, kan vi i testvinduet velge hvordan signalflyten i nettverkene i blokken skal vises. Vi kan velge farve og linjetykkelse for to ulike tilfelle:

• «Status ikke oppfylt», som gjelder dersom betingelsene langs «strømbanen» ikke er oppfylt - åpen krets eller brutt linje. • «Status oppfylt», som gjelder dersom betingelsene langs en «strømbane» er oppfylt - lukket krets eller heltrukken linje.

8.4 VAT-blokk Når vi tester ut et brukerprogram, kan det være veldig greit å kunne se hva som skjer med inn- og utganger, markører, datablokker og andre minneområder. Vi kan opprette en VAT-blokk (Variable Table) for dette formål. I VAT-blokken kan vi sette alle de variablene vi ønsker å overvåke. Dersom programmet ikke reagerer som vi forventer, kan det være kjekt å se hvor logikken svikter.

Vi kan også tvinge (force) variabler til å innta ønsket verdi for så å se hva som skjer. I stedet for å overfylle en tank for å få aktivere en nivåsensor, kan vi tvinge inngangen i VAT-blokken. Figur 63 viser et eksempel på en VAT-blokk. Vi tenker oss at et pro­ gram blant annet inneholder de følgende to linjene:

L T

MB 1 DB10.DBB

5

//Henter innholdet av BYTEMARKØR 1 og //legger det inn i BYTE 5 i DB10.

Dette eksempelet er veldig enkelt, men disse to linjene er en meget liten del av et større hele. Vi ønsker å teste ut disse to linjene isolert før vi setter dem inn i en større sammenheng. Da må vi gjøre den jobben som andre programdeler normalt skal gjøre, som i første omgang å legge data inn i MB 1. VAT-blokken opprettes som andre blokker. Så er det opp til oss å velge hvilke adresser som skal overvåkes i og eventuelt manipuler­ es (force) fra VAT-blokken. Her legger vi inn MB 1, som vi skal manipulere. Så legger vi inn DB10.DBB 5, som er dit dataene skal. De ledige linjene er kun for å gjøre det mer oversiktlig, siden vi har godt med plass.

84

Nedlasting (downloading)

og testing av brukerprogrammet

Når vi har satt programmet med de to linjene i drift i PLS-en, kan vi se verdiene på dataene ved å åpne VAT-blokken. For å se verdi­ ene i adresseområdene, klikker vi på «brillesymbolet». Nå vil vi sannsynligvis ikke se stort av interesse, da vi ikke har noen ytre påvirkning. Men øyeblikksverdiene vil da vises i kolonnen «Monitor Value».

Figur 63 VAT-blokk

For å teste om dataene virkelig vil bli flyttet fra MB 1 til DB10.DBB 5, kan vi legge et tall inn i DB1. Tallet legges inn i kolonnen «Modify Value». Men det er ikke nok bare å skrive verdien inn, den må aktiveres ved å klikke på knappen «Activate Modify Values».

Når knappen «Activate Modify Values» er klikket på, vil den inn­ skrevne verdien blir overført til MB 1. Umiddelbart vil programm­ et, dersom alt er gjort riktig, lese verdien av MB 1 og overføre verdi­ en til MB10.MBB 5.

Nedenfor er vist et utdrag av et program som leser av en analog inngang og foretar en beregning før resultatet blir overført til en analog utgang. L L *R T

IW 0 //Leser inn verdien på analoginngang IWO 3.140000e+000 //Laster inn verdien 3.14 (pi) //Multipliserer QW 0 //Overfører resultatet til analogutgang QWO

85

Kapittel 8

VAT-blokken på neste side viser hvordan vi kan overvåke hva som skjer med verdiene. Her er det ikke snakk om å tvinge verdier, siden det er fysiske verdier som skal behandles.

Men vi kunne tenke oss at vi hadde problemer med å påtrykke inn­ gangsverdien på inngangskortet, eller at vi trengte å teste beregn­ ingen. Da kunne vi gjøre modifikasjonen som er vist nedenfor:

//

L L

IW 0 MW 10

L 3.140000e+000 *R T QW 0

//Kommentert bort for test / /Midlertidig erstatning for test //Laster inn verdien 3.14 (pi) / /Multipliserer / / Overfører resultatet til analogutgang

QWO Her er analoginngangen midlertidig kommentert bort og erstattet med et midlertidig markørord, MW 10. Nå kan vi innlemme MW 10 i VAT-blokken og tvinge kjente verdier inn i prosessen.

Dersom vi ønsker å overvåke programmet i drift, kan dette også gjøres uten VAT-blokken. Ved å klikke på «Online»-knappen over SIMATIC Manager-vinduet og så åpne ønsket blokk, vil vi få et bilde som likner det vi ser på figur 64.

Figur 64 Online-visning av programstatus

86

Nedlasting (downloading) og testing av brukerprogrammet

Fordelen ved å overvåke programflyten som vist på figur 64, er at vi kan se på nesten alt som skjer. Og vi kan se tallene i arbeid på sine logiske plasser i programmet.

Ulempen med å se på programblokken i «Online»-modus, er at det kan være vanskelig å velge ut bare to eller tre verdier og se på dem samtidig. Variablene kan jo være langt fra hverandre i pro­ gramblokken.

8.5 Kontrollspørsmål 1. Hva vil det si å nedlaste brukerprogrammet? 2. Hva kan skje hvis vi setter inn et kall i OB1 før vi har lastet ned blokken det kalles på? 3. Og hva skjer hvis den nye blokken kommer på plass før kallet skrives inn i OB1? 4. Hva er PLC Simulation? 5. Hva er en VAT-blokk? 6. Hva vil det si å tvinge (force) en variabel? 7. Prøv ut de enkle eksemplene fra teksten ovenfor til å prøve ut VAT-blokken.

87

Mer

Kapittel

komplekse program

9

Mer komplekse program 9.1 Generelt De programmene som er vist i de foregående kapitler, er svært enkle og har lite med praktisk bruk av PLS å gjøre. Det er i samtlige tilfeller kun vist en enkel logisk funksjon med et par innganger og en utgang. I praksis vil et program se langt større og mer kom­ plisert ut, og programblokkene vil inneholde langt flere funksjoner og langt flere nettverk (network). Vi vil ofte ha en blokkstruktur med flere blokker enn bare OB1 og FC1, og vi vil vanligvis bruke langt mer I/O enn bare to innganger og en utgang. De to logiske OG- og ELLER-funksjonene er nok noen av de van­ ligste og mest brukte funksjonene, men det betyr ikke på noen måte at de er de eneste. Det finnes mange funksjoner og kombinasjonsformer, og det er helt umulig å forsøke på noe i nærheten av en full­ stendig gjennomgang. Vi må bare begrense oss, men allikevel ganske raskt komme inn på noen av de vanligste mer og mindre kompliserte funksjonene, hvorav her raskt kan nevnes tellere, tids­ funksjoner (timere), sammenliknere (komparatorer) og SR-funksjoner. Vi vil også raskt få bruk for markører, som noen ganger har vært beskrevet som «innvendige utganger». Markører er interne minneområder som brukerprogrammet kan benytte. Markørene er ordn­ et i dobbeltord (double word), ord (word), byte og bit, og vi kan bruke den inndelingen vi trenger.

9.2 Nettverk, titler og kommentarer Det er allerede nevnt at et program i praksis normalt vil inneholde mer enn ett nettverk (engelsk: network). Men hva er egentlig et nett­ verk i denne sammenheng? Se figur 65 der det er lagt til litt i STLprogrammet.

Nå er programmet utvidet til å omfatte to nettverk. I tillegg til det opprinnelige (Network 1), har vi et nytt nettverk som inneholder en OG-funksjon med tre innganger. Legg merke til at utgangen fra Network 1 blir avspurt som den første inngangen på Network 2. For å opprette et nytt nettverk, klikker vi på «New Network»knappen på verktøylinjen. Da åpnes det et nytt nettverk nedenfor det nettverket vi er på. Ønsker vi å sette inn et nytt nettverk helt

89

Kapittel 9

Figur 65 To nettverk, titler og kommentarer

først i programmet, må vi venstreklikke på programtittelen øverst (Demonstrasjonsprogram) før vi klikker på «New Network»knappen. Vi ser at resultatet av Network 2 setter to «utganger», nemlig Q124.1 og Ml.l. Ml.l er en markør, også kalt et flagg. Markøren er en minnecelle som settes til logisk «1», og som kan brukes på andre steder i programmet.

Legg også merke til at programmet og Network 1 er gitt titler og mer utfyllende kommentarer. Dette programmet er fortsatt så lite at det kan synes unødvendig, men programmet skal ikke vokse mye før det blir vanskelig å holde oversikten. Og selv om vi har over­ sikten og vi synes vi kjenner programmet godt etter selv å ha utviklet og skrevet det, er ting ikke så innlysende hvis vi kommer tilbake en god stund senere for å vedlikeholde, feilsøke eller vid­ ereutvikle programmet. Skulle utenforstående komme inn i stedet for programmereren, ble saken neppe lettere.

90

MER KOMPLEKSE PROGRAM

Figur 66 Utvidet program med titler og kommentarer på LAD-form

For å gjøre programmet lettere å jobbe med i fremtiden, bør det for­ synes med logiske og konsise titler og gode, mer utfyllende kommentarer. Og det er en god vane å begynne med en gang. Så fort vi har opprettet en programblokk, bør vi gi den en fornuftig tittel og kommentar. Og nettverkene bør få forklarende titler og kommentarer etterhvert som de skrives ferdig.

For å vise hvordan det utvidede programmet med titler og kommentarer vil se ut i LAD-form, henvises det til figur 66.

Det nederste nettverket bestemmer tilstanden på to «utganger», nemlig Q124.1 og markøren Ml.l. For å få til avgreningen, settes markøren på utgangen Q124.1 før vi klikker på «Open Branch»knappen. Så setter vi inn det gyldige valget vi måtte ønske i den nyopprettede grenen.

91

KAPITTEL 9

Figur 67 viser hvordan det utvidede programmet vil se ut på FBDform. ^.lALi/Mt/f UD O File

|IIG pr.HV.JMAI II: Jt.KJ Sl.Hion 11 |\l l'IJ

Insert

EdU

PLC

Debug

—....... -.. -........ -.. -------FC1 : Demonstrasjonspr __________

Dette program er skrev PLS-prograjmnerlng. Opj

MCI

Optens Window Help r; _ > _j _ _ MBS "

View

■ (Jtllinc > ]

. .........

£LC Ré$JtCr$ LAD

Cbl*1

STJ.

Cbl*2 Chl*3

Network 1 : Første OG-

Dette er den første OC Syrrtbofefiepiesettatkn Cttl+Q &

Sjjmfcol Information

*/ Coflyneni

1124.0 —

CbUShifbQ

Cbl+5hift*K

•"'"Warnhqr ■ A-r

1124.1 —

Zoom In

CbUNum*

ZoomQut

CbkNum-

Zoom Fadof .-------------------Network 2

:

Title:

T_ootoai

Comment:

Stetus Bar

&

Q124.O — 1124.2

Q124.1

1124.3 — Ml. 1

Figur 67 Utvidet program med titler og kommentarer på FBD-form Av praktiske grunner er verktøylinjen usynliggjort her. Den kan lett hentes frem igjen ved å velge View —* Toolbar på menylinjen, som vist på figur 67.

9.3 S- og R-funksjoner Studer de to programlinjene nedenfor og tenk at de står i et pro­ gram som løper syklisk, og at de gjentas et stor antall ganger hvert eneste sekund. Først undersøkes tilstanden på 1124.0. Er inngangen «1», blir resultatet av operasjonen (RLO) lik «1». Da settes i neste linje utgang Q124.0. Utgangen forblir nå høy «1» til neste gang disse to linjene utføres. Men linjene utføres meget snart sett med menneskelig tidsperspektiv - i løpet av små brøkdeler av et sekund. Er inngangen fortsatt lik «1», forblir utgangen også uendr­ et. Men skulle inngang 1124.0 ha blitt lav «0», blir resultatet av den logiske operasjonen (RLO) lik «0», og utgangen vil gå til «0» ved første gjennomløp.

92

Mer komplekse program

La oss anta at inngangen er tilkoplet startknappen til en motor, mens utgangen er PLS-utgangen som holder motorens hovedstrømsrelé. For at motoren skal gå, må vi enten holde bryteren inne eller den må være stabil. A =

I Q

124.0 124.0

La oss anta at vi ønsker å bruke pulsbryter for å starte motoren. Pulsbryteren vil bare gi «1» på inngangen så lenge noen holder den inne. Da ville motoren bare gå så lenge vi holdt knappen inne. Dette ville være riktig hvis vi hadde et krav om en «dødmannsknapp» på en farlig maskin. Men i andre tilfelle ville vi ha et problem.

Vi kunne bruke en S-utgang (Set), som vil sette utgangen varig høy. A S

I Q

124.0 124.0

Dersom dette er hele programmet, har vi ingen god måte å slå utgangen av på! Utgangen ville her forbli høy «til evig tid» eller til vi slår av prosessoren eller får strømstans eller annen teknisk svikt.

For å slå utgangen av igjen, trenger vi en R-utgang (Reset):

AN R

I Q

124.1 124.0

Disse to linjene vil slå av (Reset) utgangen så snart 1124.1 går lav legg merke til inverteringen! Inngangen er da sannsynligvis forsynt med en stoppbryter som er normalt lukket. Ser vi SR-funksjonen under ett, blir den slik:

A S AN R

I Q I Q

124.0 124.0 124.1 124.0

Dette er det vi kaller en SR-funksjon, som tillater oss å starte og stoppe motorer og annet utstyr med pulsbrytere. Hvilken av bryterne vil bestemme hvis begge aktiveres på likt? Eller, for å si med et faguttrykk: Hvilken av bryterne har dominans? Ser vi på rekkefølgen, er det R-funksjonen som utføres sist, og det er den som får bestemme. For å gi S-dominans, byttes rekkefølgen slik at S-funksjonen kommer sist av de to. Da snakker vi om RSfunksjon.

93

Kapittel 9

9.4 Timere (tidsfunksjoner) Vi vet at vi kan trykke på en bryter som er tilkoplet en inngang, og derved aktivere en eller annen hendelse, som at en utgang slås på. Vi er vel vant til å tenke på at hendelsen finner sted umiddelbart etter at årsaken til hendelsen finner sted. Men det kan jo hende at vi ønsker at hendelsen skal utsettes en viss tid. For eksempel ved et lysregulert gangfelt kjenner vel alle seg igjen når vi sier at vi stopper opp, trykker på knappen og venter en tid før bilene får rødt lys, hvorpå vi får «grønn mann» og kan gå.

For å realisere slike ventetider, har vi timere til rådighet. Vi har ulike typer av timere, og vi vil se litt på timere og bruken av dem her.

9.4.1 SD-timer (Start-on Delay) Figur 68 viser en SD-timer. Som navnet antyder, går timeren TO fra «0» til «1» når RLO har vært lik «1» i den spesifiserte tiden. På figur 68 vil dette si at dersom vi får en stigende flanke på 10.0, så vil timeren gå høy etter 2 sekunder, dersom 10.0 holder seg høy så lenge som 2 sekunder. Timeren TO blir siden, i neste nettverk (Network 2), brukt til å bestemme tilstanden på utgangen Q0.0. TO kan brukes igjen så mange ganger vi ønsker i programmet.

Skulle 10.0 gå tilbake til «0» igjen før de 2 sekundene er gått, vil T0 ikke gå høy. Dersom 10.0 går tilbake til «1» igjen, vil timeren starte nye 2 sekunders ventetid før den eventuelt går høy. Studer figur 69 for å se hvordan SD-timeren vil virke. Som det frem­ går, vil timeren ikke reagere ved en puls på inngangen som er av kortere varighet enn den programmerte ventetiden. Neste gang inngangen går høy, begynner ny ventetid. Når inngangen går lav igjen, uansett for hvor kort tid, går timeren også lav. Så må vi gjenn­ om full ventetid på nytt før timeren igjen kan gå høy.

Ventetiden skrives inn avhengig av hvilke tidsenheter det er hen­ siktsmessig å operere med. Vi kan sette inn ventetiden som følger: S5T#aH_bbM_ccS_dddms der a er antall timer, bb er antall minutter, cc er antall sekunder og ddd er antall millisekunder. Den lengst mulige ventetid er 9990 sekunder, som skulle tilsvare 2 timer 46 minutter og 30 sekunder. Denne tiden skulle skrives:

S5T#2H_46M_30S

Skulle man ønske 2 minutters ventetid, blir det: S5T#2M

94

MER KOMPLEKSE PROGRAM

Figur 68 SD-timer

Figur 69 Tidsdiagram for SD-timer

I STL-programmering skrives SD-timeren slik: A L SD

I 0.0 S5T#2S T 0

//Aktiverende inngang //Ventetid, her 2 sekunder //Nummer på timeren

95

Kapittel 9

9.4.2 SP-timer (Start Pulse) SP-timeren går høy når inngangen går høy og forblir høy så lenge inngangen forblir høy, men ikke lenger enn den programmerte tiden. A L SP

I 0.0 S5T#500MS T 0

/ /Aktiverende inngang / /Ventetid, her 500 millisekunder //Nummer på timeren

SP-timeren kan forstås ved å se på tidsdiagrammet på figur 70.

Figur 70 Tidsdiagram for SP-timer

9.4.3 SE-timer (Start Extended Pulse) Hvis vi ønsker å sikre enn viss pulsbredde på et signal, kan vi bruke SE-timeren med tidsdiagram vist på figur 71. På STL-form ser den slik ut: A L SE

I 0.0 S5T#2M T 0

/ / Aktiverende inngang / /Ventetid, her 2 minutter //Nummer på timeren

SE-timeren går til logisk «1» og blir logisk «1» for den programm­ erte tiden, uansett hva som skjer på den aktiverende inngangen. Det eneste som trengs, er en positiv flanke på inngangen, og timer­ en går høy og blir høy i den programmerte tiden. Det spiller ingen rolle om inngangen forblir høy eller faller raskt tilbake til «0».

Figur 71 Tidsdiagram for SE-timer

96

Mer

komplekse program

9.4.4 SS-timer (Start Retentive On-Delay Timer) Denne timeren reagerer på en stigende flanke på inngangen, uan­ sett hvor kort eller hvor lenge inngangen blir værende høy. Når timeren har løpt sin programmerte tid, går den til logisk «1». Skulle det komme flere enn en stigende flanke i løpet av den pro­ grammerte ventetid, vil timeren restartes for hver stigende flanke. Tidsdiagram er vist på figur 72.

Figur 72 Tidsdiagram for SS-timer

9.4.5 SF-timer (Start Off-Delay Timer) SF-timer vil være høy så lenge inngangen er høy eller så lenge timeren løper. Timeren starter ved en negativ flanke på inngangen. Tidsdiagrammet på figur 73 gir hjelp til å forstå SF-timeren.

Figur 73 Tidsdiagram for SF-timer

9.5 Tellere Vi kan ofte ha behov for tellere. Det kan være at vi har behov for å telle antall starter en motor har bak seg siden siste gang den ble vedlikeholdt, noe vi har i blandekarprogrammet i denne boken. Det kan være at vi trenger å telle antall skruer som puttes i en pakke før pakkingen regnes som ferdig. La oss tenke oss at vi selger skruene i pakker å 200 stykker.

97

Kapittel 9

Det vil antagelig lønne seg, særlig i begynnelsen, å programmere tellere i funksjonsplan. Vi kan når som helst gå over til instruksjonslisteform.

9.5.1 Opp-teller S_CU Vi kunne bruke en teller som den som er skissert på figur 74, som teller oppover.

Telleren må gis et tellernummer, som på figuren er CIO. Det er naturlig å begynne på Cl for den første telleren som settes inn i et brukerprogram. Antall tellere vi kan bruke, avhenger av prosessor­ en vi bruker.

En stigende flanke på inngang S vil gjøre at telleren mates med den forutinnstilte verdien på PV-inngangen (Preset Value). Når det kommer en stigende flanke på CU-inngangen (Count Up) økes tellerverdien med 1 så lenge tellerverdien er mindre enn 999. En stig­ ende flanke på R-inngangen (Reset) nullstiller telleren. Utgang Q er logisk «1» dersom tellerverdien er større enn 0. Er tell­ erverdien lik 0, blir utgang Q logisk «0».

Tellerverdien i øyeblikket, for eksempel hvor mange skruer som er pakket, er i heltallsformat på utgangen CV (Counter Value) og i BCD-format på CV_BCD (Counter Value_Binary Coded Decimal). Begge tellerverdieutganger er 16-bits ord. C10

Figur 74 Opp-teller S_CU

På figur 74 er tallet 901 satt som forhåndsinnstilt tellerverdi. Der­ som det kommer en stigende flanke (går fra «0» til «1») på 1124.0, så lastes den forhåndsinnstilte verdien inn i telleren. Dersom det kommer en positiv flanke inn på 1124.0, så øker tellerverdien med 1 dersom den er mindre enn 901. Kommer det en positiv flanke på 1124.3, så nullstilles tellerverdien, og CV og CV_BCD går tilbake til 0. Så lenge tellerverdien er ulik 0, vil utgangen Q124.0 være lik «1».

98

Mer

komplekse program

9.5.2 Ned-teller S_CD

Figur 75 Ned-teller S_CD Nedovertelleren er vist på figur 75. En stigende flanke på inngang S setter tellerverdien CV lik den forhåndsinnstilte verdien PV. En stigende flanke på inngangen CD vil dekrementere tellerverdi­ en med 1, så sant tellerverdien er større enn 0. Telleren nullstilles ved en stigende flanke på inngangen R.

Så lenge tellerverdien er større enn 0, vil utgangen Q være «1».

9.5.3 Opp/ned-teller S_CUD Den siste telleren vi nevner her, er S_CUD. S_CUD har en inngang, CU, for å teller oppover og en annen inngang, CD, for å telle ned­ over. Telleren er vist på figur 76.

Figur 76 Opp/ned-teller S_CUD

99

Kapittel 9

9.6 Markører eller flagg (bit memory) Begrepet markør har så vidt kommet frem i denne boken. Hva er egentlig markører og hva brukes de til? Markører er områder av prosessorens minne. Hvor stort minneområde av markører vi har til rådighet, bestemmes av prosessoren. Markører brukes til å mellomlagre data for prosessoren. Markører kalles av enkelte for «interne utganger», da de skrives til og avles­ es på samme måte som annen I/O. Det kan være at resultatet av en beregning ikke skal gå til noen utgang, men at det finnes andre deler av programmet som trenger å kjenne resultatet. Nedenfor følger et enkelt eksempel på bruk av en bitmarkør. A A =

1124.0 1124.1 M1.0

A =

M1.0 Q124.0

//Her avleses markøren //og her bestemmer markøren utgangen Q124.0

AN R

M1.0 Q124.1

//Markøren brukes der vi trenger den

//Her lagres resultatet av den logiske / /operasjonen for senere bruk.

Vi har et spesielt tilfelle av markør. Vi husker konfigurering og til­ ordning av parametre, som er en forberedende del av programm­ eringen, der vi tilpasser programmet til den fysiske sammenset­ ningen av PLS-en. Vi kan tilordne parametre til prosessoren og andre moduler, for å endre funksjon i forhold til fabrikkinnstillinger (default settings).

For prosessorens del kan vi velge å ta i bruk klokkeminne (clock memory). Velger vi denne funksjonen, vil den valgte byte av bitminnet, normalt byte 0 dersom vi ikke spesifiserer annet, pulsere med følgende frekvenser: Bit

7

6

5

4

3

2

1

0

Periodetid (s):

2

1,6

1

0,8

0,5

0,4

0,2

0,1

Frekvens (Hz):

0,5

0,625 1

2,5

5

10

1,25 2

Tabell 14

Dette kan være praktisk dersom vi har bruk for signaler som puls­ erer med faste og kjente frekvenser. Disse 8 bitene pulserer med de frekvenser som er angitt i tabellen ovenfor. Tenk om vi for eksempel programmerer et lyskryss. Når fotgjeng­ erne har grønt lys, og like før de skal få rødt lys, ønsker vi å få den «grønne mannen» til å blinke for å varsle fotgjengerne om at tiden

100

Mer komplekse

program

snart er ute, og at det er på tide å komme ut av veibanen. Hvis vi ønsker at «mannen» skal blinke med en frekvens på 0,5 Hz (2 sek­ unders periodetid), bruker vi bitminnecelle MO.7, som FC2 på figur 77. Studer FC2, og legg merke til hvordan titler og kommentarer er brukt til å dokumentere funksjonen. Her er det lagt opp til at utgangen som aktiverer den «grønne mannen» skal kunne settes på to måter: fast lys ved at biten Ml.l er satt et annet sted i brukerprogrammet, eller ved at den pulserende biten MO.7 slippes gjennom ved at M1.0 er satt.

Hva ville skje hvis både Ml.l og M1.0 er satt på en gang? Ville lyset blinke, være fast på eller slukket?

Figur 77 Valg mellom fast eller blinkende lys

Hva skal vi gjøre hvis vi finner ut at en frekvens på 0,5 Hz er for lavfrekvent? Hva vil skje hvis vi bytter ut MO.7 med eksempelvis M0.5? Tabellen sier at M0.5 pulserer med en periodetid på 1 sekund, eller frekvens på 1 Hz, som er dobbelt så raskt som MO.7. Følgelig vil lyset nå blinke dobbelt så raskt når programmet kommer i drift.

101

Kapittel 9

Den raskest pulserende av de 8 bitene i klokkeminnet er bit M0.0, som i følge tabellen pulserer med periodetiden 0,1 sekund eller 10 Hz. Denne frekvensen ville neppe være egnet i vårt lille lyskrysseksempel, men den kan helt klart finne andre anvendelser.

Vi må være oppmerksom på at dersom vi ved parametertilordningen velger å ta i bruk klokkeminnet, så kan den valgte byte (normalt byte 0) IKKE benyttes til mellomlagring av beregnede verdier. Det burde synes opplagt at vi ikke kan lagre og forvente å gjenfinne verdier i celler som pulserer! Ellers er det også meget viktig å holde orden på hvilke minneceller som brukes til hva. I lyskryssprogrammet har vi brukt M1.0 til å slippe gjennom den pulserende biten. Vi kan nå ikke bruke M1.0 til noe annet! Tenk om vi lot en helt annen del av brukerprogrammet benytte M1.0 til noe helt annet uten tanke på den «grønne man­ nen». Det skal ikke mye fantasi til for å forestille seg at det kunne føre til kaos for begge funksjoner, både den «grønne mannen» og for «rivalen». Markører trenger slett ikke bare å være enkeltbiter. Vi kan velge sammensetning avhengig av hva slags data vi jobber med: enkeltbit M, byte MB å 8 bit, word MW å 16 bit og double word MD å 32 bit.

Når vi kommer til behandling av analogverdier, trenger vi mer enn binære signaler.

9.7 Blokktyper Logikkblokker er de blokkene i et brukerprogram som inneholder de kommandoene som skal utføres under drift av programmet. Vi har følgende typer av logikkblokker:

9.7.1 Organisasjonsblokker (OB) og Interrupt Organisasjonsblokker (OB) danner grensesnittet mellom bruker­ programmet og prosessorens operativsystem. Organisasjonsblokkene kalles opp av operativsystemet.

Vanligvis kjører prosessoren programmet i syklisk modus. Syklisk modus betyr at prosessorens operativsystem gjennomløper en programsløyfe (loop) mange ganger hvert eneste sekund.

Den mest sentrale OB er OB1. For hver gang programsløyfen gjenn­ omløpes, kalles OB1 opp. OB1 kalles opp enten vi vil eller ikke, og OB1 opprettes automatisk i «blokkbeholderen» i det øyeblikk vi oppretter et STEP 7-program. Hva programmereren har skrevet inn i OB1, er av avgjørende betydning for hva som videre skjer. Har vi glemt å editere OB1 og sette noe inn der, vil intet skje!

102

Mer komplekse

program

I OB1 setter vi vanligvis inn kall på funksjonsblokker (FB-er og SFB-er) og funksjoner (FC-er og SFC-er). OB1 er den sanntids-OB som har lavest prioritet. Bortsett fra OB90, så kan alle andre OB-er avbryte prosesseringen av OB1. OB1 kan kalles opp av hvilken som helst av følgende hendelser:

• Ferdig med oppstart • Ferdig med å utføre OB1 (i foregående gjennomløp)

Når OB1 er ferdig gjennomført, vil operativsystemet skrive prosessutgangstabellen (PIO) til periferiutgangsenheten samt sende all fellesdata. Før OB1 restartes, vil operativsystemet oppdatere prosessinngangstabellen (PII), og operativsystemet vil også motta all fellesdata for prosessoren. I tillegg til syklisk programprosessering, har vi også interruptprosessering som går ut på at deler av brukerprogrammet bare kjøres hvis spesielle hendelser finner sted. Programflyten avviker da fra den sykliske programflyten.

Vi kan sammenlikne interruptprossesering med det som skjer hvis vi er opptatt med et dagligdags og lite tidskritisk gjøremål som å tørke støv i stuen, når telefonen plutselig ringer. Støvtørkingen kan vi ta opp igjen på et senere tidspunkt uten noe problem. Telefonen er langt mer tidskritisk enn støvtørkingen og må besvares omgå­ ende, ellers er det for sent. Derfor legger vi fra oss støvkluten og tar telefonen. Så snart samtalen er avsluttet, kan vi ta kluten opp og fortsette der vi slapp. Et annet eksempel er det som fort kan skje om vi går på gaten og er skjødesløs nok til å lese i en avis samtidig. Så sklir vi plutselig på is. Da vil vi øyeblikkelig få annet å stå i med enn avisen! Vi vil prøve å holde oss på bena. Så snart vi er stø igjen, kan vi (om vi fortsatt tør) ta opp avisen igjen der vi slapp. Interruptprosessering er gjerne brukt for funksjoner som er tidskritiske. Nå vil programsyklusen i en moderne PLS normalt være rask, selv ved store programmer. Men det kan være situasjoner som stiller særlig strenge krav til presisjon og reaksjonstid. Da er det greit om prosessoren kan programmeres til å «føle» at det er en mer presserende oppgave å utføre og umiddelbart legge fra seg alt annet for å ta det som haster, før den fortsetter der den slapp.

Disse programdelene er skrevet inn i de organisasjonsblokkene som skal startes av operativsystemet som en følge av den respek­ tive hendelsen.

103

Kapittel 9

9.7.2 Tidsinterrupt-OB (Time-of-Day Interrupt) (OBIO til OBI7) I STEP 7 kan vi ha opptil 8 OB-er som enten startes en gang eller periodisk. De kan programmeres til å prosesseres med følgende intervall:

* • • * • • •

Engang Hvert minutt Hver time Daglig Ukentlig Månedlig Årlig

For å starte et tidsinterrupt, må interruptet settes opp og aktiveres. Det er tre startmuligheter:

• Automatisk start, hvis interruptet er satt og aktivert. • Sette interruptet med STEP 7 og aktivere det ved å kalle SFC30 «ACT_TINT» fra programmet. • Sette interruptet ved å kalle SFC28 «SET_TINT» og aktivere ved å kalle SFC30 «ACT_TINT fra programmet.

Intervall

Beskrivelse

Ikke aktivert

Interruptet utføres ikke selv om det er lastet ned i prosessoren. Det kan aktiveres ved å kalle SFC30.

Aktivert en gang

Interruptet kanselleres så snart det har kjørt en gang som spesifisert.

Programmet kan bruke SFC28 og SFC30 til å nullstille og deaktivere OB. Periodisk aktivert

Når interruptet finner sted, vil prosessor­ en beregne neste starttid basert på aktuell tid og periodetid.

Tabell 15

9.7.3 Maskinvareinterrupt I STEP 7 finnes det opptil 8 uavhengige maskinvareinterrupt (hardware interrupt), og hver av dem har sin egen OB, fra OB40 til OB47. Ved parametertilordning spesifiserer vi for hver signalmodul hva som vil utløse maskinvareinterrupt:

• Hvilke kanaler som utløser et maskinvareinterrupt, og under hvilke forhold det vil skje. • Hvilke maskinvareinterrupt-OB-er som er tilordnet de individu­ elle grupper av kanaler. I utgangspunktet er alle maskinvarein­ terrupt prosessert av OB40.

104

Mer komplekse program

Når et maskinvareinterrupt er blitt utløst av modulen, vil opera­ tivsystemet identifisere modulens plassering i kabinettet samt til­ hørende OB. Om interruptet utføres eller ikke, kommer an på pri­ oritet - hvilken av to aktiviteter som er gitt høyest viktighet av operativsystemet. Vanligvis vil operativsystemet fra før holde på med utførelse av det ordinære sykliske programmet. Men det kunne også hende at det allerede var et interrupt under utførelse. Alle interrupt har, naturlig nok, høyere prioritet enn normal programutførelse. Er operativsystemet opptatt med utførelse av det sykliske pro­ grammet, vil operativsystemet med lynets hurtighet «slippe det som det har i hendene» og øyeblikkelig utføre interruptet. Når interruptet er utført, vil operativsystemet ta fatt på det den holdt på med uten annen skade enn den forsinkelse interruptet har forår­ saket.

Om operativsystemet allerede var i ferd med å utføre et annet inter­ rupt, er det prioritet som avgjør hva som skjer. Har det nye inter­ ruptet større prioritet enn det allerede påbegynte, vil operativsys­ temet midlertidig måtte legge vekk det allerede påbegynte inter­ ruptet for å ta seg av det sist utløste interruptet.

Dersom det finner sted en hendelse som utløser et maskinvarein­ terrupt på samme modul som det allerede er et identifisert og ikke fullført interrupt, gjelder følgende: • Hvis hendelsen finner sted på samme kanal som det interruptet som allerede er under utførelse, så vil det siste interruptet gå tapt. Den utløsende hendelsen er stigende flanke på en kanal på en digital inngangsenhet. Interrupt-OB er OB40. • Dersom hendelsen finner sted på en annen kanal på samme modul, kan ikke interruptet utløses enda. Men interruptet går ikke tapt av den grunn. Det nye interruptet vil utløses så snart det aktive interruptet er godkjent (gjelder kun S7-400). For S7300 vil maskinvareinterruptet gå tapt dersom hendelsen er over før det aktive interruptet er godkjent.

Figur 78 Tapte interrupt

Dersom et maskinvareinterrupt blir utløst mens dets OB er opptatt med å utføre et maskinvareinterrupt fra en annen modul, vil det siste interruptet bli registrert og utført så snart den aktuelle OB er ledig.

105

Kapittel 9

Maskinvareinterrupt kan koples ut, forsinkes og gjeninnkoples med SFC 39 til SFC 42.

Vi kan tilordne parametre for maskinvareinterrupt for en modul ikke bare med STEP 7, men også med SFC 55 til SFC 57.

9.7.4 Funksjon (FC) En funksjon (FC) er, i følge standarden IEC 1131-3, en logisk blokk uten statiske data. At blokken ikke har statiske data, betyr at det ikke lagres data i tilknytning til blokken. Blokken lagrer ingenting, og neste gang blokken kalles opp, er det intet ved blokken som for­ teller om hva som skjedde sist den ble kjørt. Blokken er altså ikke tilordnet noen instansdatablokk. En funksjon gjør det mulig å over­ føre parametre i brukerprogrammet. Dette betyr at funksjoner er velegnet for å programmere oppgaver som skal gjentas ofte, som beregninger.

9.7.5 Funksjonsblokker (FB) En funksjonsblokk (FB) er, i følge standarden IEC 1131-3, en logikkblokk med statiske data, noe som gjør at blokken kan huske informasjon fra forrige gang den ble kjørt. Dette innebærer at en FB kan være tilordnet en instansdatablokk. En funksjonsblokk gjør det mulig å overføre parametre i brukerprogrammet. Dette betyr at funksjonsblokker er velegnet for programmering av komplekse funksjoner som gjentas ofte, som eksempelvis kontrollsystemer og valg av operasjonsmodi.

9.7.6 Systemfunksjoner (SFC) En systemfunksjon (SFC) er en funksjon som er en integrert del av prosessorens operativsystem. En SFC kan bli kalt opp fra bruker­ programmet når det er behov. Siden en SFC er en integrert del av operativsystemet, kan den ikke programmeres av brukeren.

9.7.7 Systemfunksjonsblokker (SFB) En systemfunksjonsblokk (SFB) er også en funksjonsblokk som er en integrert del av prosessorens operativsystem, og kan kalles opp fra brukerprogrammet ved behov. Vi kan som brukere ikke pro­ grammere en SFB.

Logikkblokkene (OB, FB og FC) i brukerprogrammet kan alle nedlastes til S7-prosessoren. De er enten skrevet av programmereren, eller de blir generert under kompilering av kildefiler. Lenger bak i boken finnes det illustrerende eksempler på alle disse programblokkene og bruken av disse.

106

MER KOMPLEKSE PROGRAM

9.8 Datablokker Datablokker er blokker som brukes av logikkblokkene i brukerpro­ grammet når det er behov for å lagre verdier.

I motsetning til de midlertidige dataene i logikkblokkene, blir ikke data i datablokkene slettet når logikkblokken er ferdig eksekvert. Datablokken kan også lukkes, og dataene finnes der intakt neste gang datablokken åpnes igjen. Størrelsen på minnekapasiteten som kreves for en datablokk avhenger av hvilken prosessortype vi har med å gjøre. For CPU 314 kan det eksempelvis være snakk om opp til 8 kilobyte, eller 8192 bytes.

Avhengig av datablokkenes tilknytningsform til logikkblokkene, har vi to ulike typer av datablokker, nemlig felles datablokker og instansdatablokker.

9.8.1 Felles datablokker Datablokker som kan aksesseres og brukes av alle logikkblokker i brukerprogrammet, kalles felles datablokker. Hver eneste funksjonsblokk (FB), funksjon (FC) eller organisasjonsblokk (OB) kan skrive data til eller lese data fra disse datablokkene. Vi kan opprette felles datablokker på følgende måter: • Selv spesifisere strukturen for datablokken. Dette betyr at vi definerer og editerer rekkefølge på variabler, deres symboler og deres datatyper individuelt • Opprette en datablokk med en tilordnet brukerdefinert datatype (User-defined Data Type - UDT). Strukturen på den aktuelle UDT definerer strukturen på datablokken.

Figur 79 viser et enkelt eksempel på en liten datablokk, DB1. Data­ blokken opprettes på samme måte som andre blokker og editeres relativt lett slik vi vil ha den. DB1 inneholder først to binære variabler. Kommentarene til høyre antyder at de er tenkt brukt til å lagre tilstanden på en ventil og fyllingsnivå i en tank. Så følger en analogverdi. Her er det valgt å bruke en heltallsverdi (INT). Analogverdien tar to byte, i dette til­ felle byte 2 og byte 3 i datablokken. Vi kan fritt velge formater og utforming av datablokken.

Datablokken kan åpnes av en hvilken som helst programblokk i systemet, og de tre variablene kan skrives til og avleses fra hvilken som helst programblokk. For eksempel kan vi tenke oss at det et sted i en logikkblokk er følg­ ende programlinjer: A =

«Full» DB1.DBX

0.1

/ / Avleser nivåbryter i tanken //Skriver tilstanden på nivåbryter til Minne2

107

Kapittel 9

Figur 79 Enkel DB

Nå er informasjonen om tanken er full eller ikke lagret i cellen Minne2 i DB1. Informasjonen ligger der fritt tilgjengelig for alle andre deler av programsystemet, og informasjonen endrer seg ikke før ny verdi skrives fra en eller annen del av programsystemet.

Dersom tanken er full, er det kanskje ønskelig å drenere den. Da kan vi tenke oss at vi har følgende linjer et sted i brukerprogramm­ et: A S

DB1.DBX «Drener»

0.1

//Sjekker hva som ligger i Minne2 //Starter dreneringspumpe

9.8.2 Instansdatablokker Instansdatablokker er datablokker som er tilordnet en bestemt funksjonsblokk (FB). Instansdatablokkene inneholder de lokale data for den aktuelle funksjonsblokken.

Hvis andre funksjonsblokker blir kalt opp innenfor en funksjons­ blokk som har statiske variabler deklarert, vil instansdatablokken til den oppkallende funksjonsblokken også inneholde de lokale data for de oppkalte funksjonsblokkene.

108

MER KOMPLEKSE PROGRAM

Datablokkene i brukerprogrammet kan lastes ned til prosessoren. De opprettes enten i redigeringsprogrammet (editoren) eller de skapes under kompileringen av kildekoden. Bruken av datablokker vises utfyllende lenger bak i boken.

9.9 Symbolsk adressering tilordningsliste Se på programkoden på figur 80. Dette programmet er ikke så stort, men vi må vel likevel kunne innse at det her er fort gjort å miste oversikten, når vi ikke ser kommentarer, og når vi bare har adress­ er som 1124.0, Q124.1 og MO.O å forholde oss til. Disse adressene er nokså intetsigende og gir lite hjelp til å holde oversikt eller til å sette seg inn i programmet. Til og med for den som har skrevet pro­ grammet, er det forbløffende hvor fort vi får en slik avstand til den jobben vi har gjort at det er vanskelig å komme inn i programmet igjen. Da måtte det være lettere om adressene hadde navn som ga litt hint om hva som skjulte seg bakom koden.

Figur 80 Er denne programkoden selvinstruerende? Dersom vi nå ser på figur 81, må det vel være lettere å sette seg inn i og finne ut av programkoden slik den ser ut her. Det er nøyaktig

109

Kapittel 9

samme program som på figur 80, men vi har visning av symbolsk adressering i stedet for visning av absolutt adressering. Det er lett å gjette seg til omtrent hva adressen «Start» er; det er startknappen. «Stjerne» er utgangen som holder stjernereléet. Slik kunne vi gå videre og tenke oss at all I/O og alle flagg i et program er tilegnet slike logiske symbolnavn. Er vi flinke nok til å velge de rette navn, hjelper dette voldsomt på lesbarheten til programmet.

Figur 81 Symboler er mer forståelige enn de absolutte adressene Det kan også velges mellom visning av absolutt adressering, sym­ bolsk adressering og kombinasjoner. Figur 82 viser en kombina­ sjonsløsning der også kommentarer blir tatt med. Kommentarene kan være lange forklaringer. Men det gjelder å prøve å finne kom­ promissløsninger som gjør at vi ikke «drukner» budskapet i tekst.

Det samme programmet med symbolsk adressevisning er vist på figur 83, men nå på LAD-form.

110

Mer komplekse

\FF.1 -]

o *

1

1

I

Q- fJe £dh jrwcrt

8

I^IAO/Sll /FRO - [YO-vendertSIMATir. 30(1 Slation (l)\CPU31?IFM\

1

A AN AN 3

RFII HEEEI^I

3

FCl : Title ■ilHwjik

program

St j ernekoblmg

"Start" "Stjerne" "Trekant" M 1.0

1124.0 Q124.0 Q124.1

— Startknapp — Utgang til stjernerele — Utgang til Trekantrele

"Stopp" "Trekant"

1124.1 Q124.1

— Stoppknapp - Normalt lukket — Utgang til Trekantrele

M 1.0 M 1.0 "Stjerne" S5T#4S T 1

Q124.0

-- Utgang til stjernerele

1124.1

— Stoppknapp - Normalt lukket

Q124.1

-- Utgang til Trekantrele

A( O o

R

A =

D 3D

Network 2 : Trekantkoblxng A S A R A —

T 1 M 1.1 "Stopp” M 1.1 M 1.1 "Trekant"

Figur 82 Visning av både symbolsk og absolutt adressering {*>i| AO/STI /FRO - [YD-venrlerXSIMATIC 3(10 Slatkm (I)VFP(131 ?IFM\ O Die

£«

Intert

£LC

fiebuo

¥«ew

Qpions

tørriow

XFC.1 - ]

WREJ

tfelp

FCl : Title:

Network 2 : Trekantkobling Ml. 1

TI

"Trekant

sr

S

Q

Stopp R

Figur 83 LAD-form og symbolsk adressering

1 1 1

KAPITTEL 9

Vi kan også velge å bruke både symbolsk adressering og symbolinformasjon, som på figur 84.

Figur 84 LAD-program med symbolsk adressering og symbolirtformasjon

Mange vil hevde at en optimal løsning kan være som på figur 85, der det er brukt absolutt adressering, men der symbolinformasjon er vist under hvert nettverk. Men hvordan vi foretrekker å jobbe, er noe vi må føle oss frem til. Det er imidlertid viktig å være klar over hvilke alternativer som finnes. Det blir fort unødvendig tungvint å jobbe dersom vi ikke kjenner til at det finnes alternativer til absolutte adresser.

112

MER KOMPLEKSE PROGRAM

Figur 85 LAD-program med absolutt adressering og symbolirtformasjon optimal løsning?

Hvordan tar vi i bruk symbolske adresser? Vi kan tilordne symbolske navn til adresser i et ferdig program, eller når vi innser at det begynner å bli vanskelig å holde oversikt­ en. Men det er antagelig det beste om vi kan ha tilordningslisten (symbol table) klar før vi begynner å programmere for alvor. Da bør vi ha gått gjennom og strukturert oppgaven på papiret før vi i det hele tatt skrur på en PC og starter STEP 7. Vi bør ha gått gjennom all I/O og satt opp en liste med alle adresser og de symboler vi har bestemt oss for. Vi bør også ha tenkt ut noen korte og konsise, men samtidig utfyllende, kommentarer til adressene. En vakker dag, og gjerne før vi aner det, kan vi komme til å innse at denne struktureringsjobben er en god fremtidsinvestering!

113

Kapittel 9

Figur 86 Prosedyre for å åpne symboleditoren

Figur 86 viser hvordan vi åpner symboleditoren (editor = redigeringsprogram). Selve symboleditoren er vist på figur 87. På figuren er det allerede lagt inn symboler for tre adresser, to innganger og en utgang. Det er også valgt å skrive korte kommentarer for hvert symbol, men kommentarene er her bare på ett ord hver. Vi kan hoppe over kommentarene dersom vi ikke ønsker å bruke kommentarer.

Legg også merke til den tredje kolonnen. Alle disse tre adressene er binære adresser, derfor er de angitt som BOOL (Boolean = Boolsk). Vi skal senere stifte nærmere bekjentskap med andre datatyper.

Hvis vi har gjort ferdig symbollisten før vi tar fatt på selve pro­ grammeringen, kan vi sette symbolene rett inn i programmet. Det kan være lurt å ha en papirutskrift av symbollisten før programm­ eringen påbegynnes. Vi vil fort finne ut at det er vanskelig å huske alle navnene vi har brukt, og vi kan klø oss i hodet og lure på om vi i et heisprogram har kalt HIT-knappen for HIT eller KOM!

Vi kan programmere med automatisk innsetting direkte fra sym­ bollisten enten vi bruker STL-, LAD- eller FBD-programmering. Men mange ville mene at det ikke er særlig lettvint og brukervenn­ lig i STL-form. Velger vi å programmere i STL og ønsker å bruke innsetting av symboler, er det som nevnt nesten umulig uten en papirutskrift av

1 14

Mer

komplekse program

Figur 87 Symboleditoren

symbollisten ved siden av seg. Så kan vi skrive programlinjene inn i nettverkene på følgende måte: A «Start» AN «Stopp» = «Hovedrele»

For hver gang vi trykker ENTER-tasten for å avslutte en linje, just­ erer linjene seg automatisk, slik at resultatet blir slik: A AN =

«Start» «Stopp» «Hovedrele»

Vi må her være meget nøyaktig! Vi må være nøyaktig med små og store bokstaver. Skulle vi skrive noe feil, får vi feilmelding i form av at linjen blir rød. Tenk om vi er usikker på noe så banalt som om vi har skrevet STOPP, Stopp, eller om vi har brukt den engelske Stop, med bare en «p». Disse forskjellene kan synes små, men resultatet av den minste feil vil være nådeløse feilmeldinger! Vi kan også skrive inn de symbolske adressene selv om vi ikke har valgt symbolsk visning (Symbolic Representation) i editoren. Så snart linjen avsluttes med ENTER-tasten, vil den absolutte adress­ en vises i stedet for det korresponderende symbolet vi nettopp skrev inn.

115

Kapittel 9

Figur 88 Åpning av symbolliste ved FBD-programmering

Figur 88 viser hvordan vi åpner symbollisten når vi driver FBDprogrammering. Nå åpner listen seg som på figur 89. Nå kan vi sette markøren på det ønskede symbolet og velge det ved å trykke på «OK».

Figur 89 Symbolliste - sett markør på ønsket symbol og trykk «OK»

116

Mer komplekse program

9.10 Kryssreferanseliste «Kan jeg bruke utgang 146.5? Eller er den allerede brukt? Hva var det nå jeg gjorde i forrige uke? Nei, dette er vanskelig, jeg har jo hundrevis av inn- og utganger å holde styr på!»

Tankene ovenfor kan bli virkelige før vi aner ordet av det! Prosjekt­ er vil ofte vokse i størrelse og kompleksitet som kreftsvulster, og det skal ikke mange nettverkene til før vi får problemer med å «holde orden på kortene»! Når vi trenger å ta i bruk en adresse, enten det er en inngang, utgang, markør, teller, timer eller en programblokk, er det viktig å holde rede på om det er fritt frem. Trenger vi for eksempel en bitmarkør for å huske en eller annen hendelse, og kunnskapen om denne hendelsen skal brukes til å foreta visse valg i programmet, er det viktig å bruke en markør som ikke alt er i bruk. Vi vil fort kunne få stygge overraskelser! Og vi vil også fort finne ut at programmet ikke skal bli stort før vi kan få problemer hvis vi baserer oss på bare hukommelsen!

Studer linjene nedenfor, som representerer noen få enkle nettverk fra en programblokk:

Network 1 : A I A I = M

124.0 124.1 1.0

Network 2 : A M O I S Q

1.0 124.2 124.0

Network 3 : A I A Q = M

124.3 124.0 1.1

//Markør M1.0 første gang

//Markør M1.0 annen gang

//Markør Ml.l første gang

Det er ikke mange linjene, og det er bare brukt 4 binære innganger, 1 binær utgang og to bitmarkører. Prøv nå å tenke om vi skulle pro­ grammere videre og trengte å ta i bruk en ny bitmarkør. Skulle det være en helt ny logisk oppgave i programmet, kunne vi ikke bruke verken M1.0 eller Ml.l. Dersom programmet ett sted trenger å sette en av dem til «1», mens den et annet sted forsøkes satt til «0», er det lett å tenke seg at ikke begge «brukere» av markøren kan få sin vilje. Begge «brukere» av markøren er i utgangspunktet like viktige, så det er lett å innse at det er helt uakseptabelt å la dem dele på markøren - det fører garantert til funksjonsmessige feil før eller siden - helst før! Men, er vi helt sikre på å klare å ta i bruk en helt ny markør, og at vi ikke lager en «spaghetti» som ender opp i et eneste rot?

117

Kapittel 9

Nei, det ville raskt bli vanskelig nok om vi programmerte fortløp­ ende og i samme programblokk. Er vi i samme blokk, er det tross alt forholdsvis enkelt å hoppe frem og tilbake, selv om det også blir stressende nok når blokken vokser. Enda verre blir det når vi pro­ grammerer nye programblokker, og kanskje vi er kommet tilbake for å videreutvikle eller endre et gammelt program. Eller kanskje vi er kommet inn for å feilsøke eller videreutvikle et gammelt prgram som andre har utviklet og som vi kanskje aldri selv har sett før. Et enkelt hjelpemiddel er en kryssreferanseliste, som enkelt kan genereres og skrives ut. Når programmet vokser, bør vi absolutt ha en ny versjon av kryssreferanseliste på papirutskrift! Har vi en opp­ datert kryssreferanseliste og sørger for å være nøye med å alltid holde den oppdatert, kan vi spare oss selv og andre for mye trøbbel. For å generere en kryssreferanseliste i STEP 7 på en grei måte, velg­ er vi fra SIMATIC Manager menyvalg Options -* Reference Data “* Filter and Display. I boksen som nå kommer opp, klikker vi på «OK».

Nå kommer Filter-boksen på figur 90 opp.

Figur 90 Filter-boksen

I Filter-boksen velges arket Cross References dersom det ikke alle­ rede ligger øverst. Her velger vi i avkrysningsboksene hva slags adresser som skal tas med i kryssreferanselisten. I vårt lille tilfelle har vi kun brukt noen ganske få innganger, utganger og bitmarkører. Tellere (Counters) og timere er overhodet ikke bruk, så vi treng­ er ikke å velge slike komponenter.

118

Mer

komplekse program

Dersom vi bare trenger en kryssreferanseliste til hjelp med å velge for eksempel bitmarkører, er det bare tull å generere og skrive ut på papir en komplett liste med all I/O, tellere, timere og blokker.

Med de tre valg som er gjort på figur 90, vil vi få en kryssrefer­ anseliste som ser ut omtrent som tabellen nedenfor: Block

Type

Language

Details

1124.0

FC2

R

STL

Nw 1 Ln 2 Inst A

1124.1

FC2

R

STL

Nw 1 Ln 2 Inst A

1124.2

FC2

R

STL

Nw 2 Ln 2 Inst O

1124.3

FC2

R

STL

Nw 3 Ln 1 Inst A

M1.0

FC2

R

STL

Nw 1 Ln 3 Inst -

M1.0

FC2

W

STL

Nw 2 Ln 1 Inst A

Ml.l

FC2

W

STL

Nw 3 Ln 3 Inst -

Q124.0

FC2

R

STL

Nw 3 Ln 2 Inst A

Q124.0

FC2

W

STL

Nw 2 Ln 3 Inst S

Address

Symbol

Tabell 16

Vi ser for eksempel at M1.0 er brukt to ganger. Begge gangene M1.0 er brukt er i programblokken FC2, første gang i nettverk 1, linje 3, der dens tilstand bestemmes (Inst=). Neste gang er i nettverk 2, linje 1 der den avleses i en OG-funksjon.

Dersom vi nå var ute etter et ledig markørbit, kunne vi lett se av kryssreferanselisten at vi ikke kunne bruke M1.0 eller Ml.l. De fleste er imidlertid ledige, og det første vi kan bruke, er Ml.2. Vi ser her bevisst bort fra MBO, som vi alt har nevnt kan brukes til blinkfrekvenser.

9.11 Sammenlikninger Noen ganger trenger vi å sammenlikne verdier for a avgjøre hva som skal gjøres. Kanskje vi vil sjekke om en transportør har trans­ portert nok enheter til å ha fylt opp en lasteplass. Funksjonene sammenlikner to digitale verdier. Den ene verdien er lagret i akkumulator 1 mens den andre er i akkumulator 2. Resul­ tatet av sammenlikningen kan være «0» eller «1», og det lagres blant annet i registeret RLO (Result of Logic Operation). Resultatet kan siden brukes i logiske operasjoner. Tabellen nedenfor viser en oversikt over sammenlikningsfunksjonene. Sammenlikningsfunksjon

Sammenlikning av datatyper

INT

DINT

REAL

Likhet

==I

==D

==R

Ulikhet

I

D

R

Større enn

>1

>D

>R

Større enn eller lik

>=I

>=D

>=R

Mindre enn