Programmerbare Logiske Styringer Denne siden er basert på Tony R. Kuphaldts flotte arbied på https://www.ibiblio.org/kuphaldt/socratic/sinst/
Noe er oversatt til norsk, enkelte emner er lagt til og reseten er på orinalspråket.

Programmerbare Logiske Styringer

Alle styresystemer kan deles opp i tre deler: inngangsenheter (Sensorer og Følere), styreenheter, og utgangsenheter (pådragsorganer. Inngangsenhetene føler på hva som skjer i prosessen, styreenheten finner ut hva som skal gjøres med det, og utgangsenhetene manipulerer prosessen til ønsket resultat.

En programmerbar logisk styring eller en PLS er en universal styringsenhet. Den kan brukes til mange ulike typer styringsoppgaver. Det at den er programmerbar gjør den nyttig for bruken som kan tilpasse den til akkurat sitt behov. En PID sløyferegulator er et eksempel på en spesialbygget styrefunksjon som bare kan brukes som en sløyferegulator.

PLS-er ble i sin tid lansert som en erstatning for relestyringer. I systemer for styring av/på styring av motorer og andre boolske utganger fikk en mindre systemfeil og lengre levetid. At PLS-en er omprogrammerbar gjorde også at det var lettere å implementere forandringer en med relestyringer. For å få ny funksjon med relestyringer er det nødvendig å koble om. Da PLS-er er som datamaskiner ble det også mulig å koble de sammen i nettverk, noe som muliggjør overvåkning fra operatørstasjoner på fjerne lokasjoner og av flere stasjoner.

At PLS-en var ment å overta for relestyringer er lett å se når en bruker det mest valige progarmeringsspråket for PLS-er Ladeder Diagram. PLS programmer skrevet i ladder diagram ligner på styrestrømsskjemaer for elektriske koblinger. I Norge er det valing at disse er horisontale. Slik at vi må snu de 90$^{\circ}$ for å kunne se de på samme måte. Når en programmerer i ladder "tegner" styrestrømsskjema (med amerikanske symboler). Denne måten å programmere på ble utviklet for å gjøre det enkelt for industielektriekkere å tilpasse seg den nye teknologien. Ladder diagram har klare begrensninger som et programmeringsspråk, men det er lett å lære og diagnostisere. Dette gjør at det fremdeles brukes mye.

Typisk utstyr som tilkobles en PLS er trykkbyrtere, prosessbrytere, sensorer, analoge transmittere (4-20mA), thermoelementer, termistorer og strekklapper. Til en PLS sine utganger kobles lyx, solenoider, reler, motorstyringer, analoge pådragsorganer og buzzere. PLS-en ble originalt utviklet for å styre digitale (av/på) signaler så som transportbånd, batch sekvenser og monteringslinjer, kan moderne PLS-er like gjerne behandle analogesignaler. Nå kan en PLS like gjerne styre en PID sløyfe som et transportbånd.

PLS eksempler

En PLS er i prinsippet ikke noe annet en en spesialbygget industridatamaskin. Det vil si at den er bygget for å tåle tøffere omgivelser. De har også et operativsystem som er langt mer politlig. PLS-er har som regel ikke HDD, kjølevifter eller andre beveglige deler. Dette er et designvalg som skal gjøre PLS-en mer robust i utsatte industrielle miljøer. Typiske ellementer som en finner i industrielle miljøer er: ekstreme temperaturer, vibarsjoner, luftfuktighet og parikler (strøv, fibre og/eller ulike gasser.).

Store PLS systemer består av et modulsystem. Modulene kan være IO-moduler, kommunikasjonsmoduler, sikkerhets-PLS-er. Slike systemer er fleksible og kan tilpasses etter behov. De har også den fordelen enkeltfeil kan fikses med å bytten en modul og ikke hele systemet.

Mindre PLS systemer består av en enhet, som inneholder alle funksjoner: CPU, I/O, kommunikasjon. Et slikt system et typisk billigere men er begrenset i I/O kapasitet, og hele enheten må byttes ved en feil.

I bildene som følger vises flere eksempler på PLS systemer fra industrien, noen store systemer og noen mindre systemer. Disse bildene viser på ingen måte hele utvalget av PLS som finnes, men er et representativt utvalg (for USA) av vanlige PLS merker brukt i industrien (2010)

Det første bildet er av en Siemens (Texas Instruments) 505 serie PLS. Den er installert i styreskap til et vannrenseanlegg. Dette er et eksempel på en modulær pls, med individuelle: prosessor, I/O og kommunikkasjonsmoduler som plugges i et rack. Bildet viser tre rack, to er fylt opp med med kort, det tredje er bare delvis fylt.

$\displaystyle \includegraphics[width=16cm]{plc_001.eps}$

Strømforsyningen og prosessorkortet til hvert av rackene er plassert til venstre, andre kort kan tilkobles resten av plassene. Inngangsenheter som bryere og sensorer kobles ved hjelp av ledninger til terminaler på inngangskort og utgangsutstyr som lamper, solenoider, og motorstyringer tilkobles terminalene på utgangskort.

En av fordelene med en modulær PLS oppbyggning er at I/O kortene kan byttes ut som enønsker, på den måtne kan en få akkurat den I/O konfigurasjonen en ønsker. Det kan f.eks. være at du har et styresytem som skal overvåke mange sensore, da installerer Inngangskort som alle sensorene kan tilkobles. Dersom en ønsker å bytte type sensor, f.eks. fra en 24 VDC sesnor til en for 230 VAC, kan en bare bytte ut en av kortene.

Denne PLS-en brukes til å styre rensesekvensen av innløpsfiltrene til et kommunalt anlegg for rensing av avløpsvann. Filtrene løftes opp av elektriske motorer, og grovavfall slik som plastikposror o.l. skrapes av og transporteres til et anlegg for søppelhåndtering. PLS-en holder orden på kjøring opp/ned av filtre, vannivå, trykk systemet og forbikoblinger som er innkoblet av operatører. Ved programmering av et slikt system bentyttes timere, tellere, sekvenser og andre funksjoner for å sørge for kontinuerlig drift av anlegget.

Neste bilde viser en Allen-Bradley (Rockwall) PLC-5 PLS, som styrer en naturgass kompressor. I bilde vises to to enheter med ulike IO-kort.

$\displaystyle \includegraphics[width=16cm]{plc_002.eps}$

Akkurat som den forige PLS-en Siemens 505 er Allen-Bradley PLS-5 modulær og konfigrurerbar. IO-kort kan byttes ut etter ønsker og den kan omprogrammeres etter egne behov.

I dette oppsettet har PLS-en som oppgave å følge med på noen av variablene til gasskompressoren. Når det er nødvendig gjøres justeringer som er nødvendig for å holde systemet produktivt og sikkert. Den automatiske styringen som er mulig med en PLS sørger for sikker og effektiv oppstart, nedstengning og håntering av nødstilfeller. Nettverks og dataloggings kapasiteten til PLS-en sørger for at disse dataene kan sjekkes av egnet personel. I akkurat denne kompressoren overføres data fra staten Washington der kompressoren er, til staten Utah der operatørene sitter. Operatørene i Utah kan følge med på driftsegenskapene til kompressoren og gi nødvendige kommandoer over digitale nettverk.

Både Simens (tidligere Texas Instruments) 505 og Allen-Bradley (Rockwell) PLC-5 PLS systemene blir annsett som gammeldagse. De er begge over 20 år gamle. Det er ikke uvanlig å finne foreldete PLS systemer i daglig drift. På grunn av de solide og politlige designet kan de være i drift i flere tiår uten problemer.

En nyere modell fra Allen-Bradley er SLC 500 serien, som også er modulbasert. Kortene til SLC 500 serien er mer kompakte. SLC 500 enheten i dette bildet har 7 kortplasser for CPU og IO-kort. Disse blir nummerert 0 til 6.

$\displaystyle \includegraphics[width=16cm]{plc_017.eps}$

De tre første kortplassene i denne SLC 500 enheten (0,1 og 2) har en CPU, AI og DI kort. På plass 3 og 4 er det plass til reservekort. Modul 5 og 6 er hhv. DO- og AO kort.

Kort i slike systemer har typisk led indikatorer som forteller om status til kortet. CPU kortet har indikatorer for "RUN" modus, "FLT"(fault) status, bruk av "Force" for å tvinge variabler av en programmerer under testing og kommunikasjons indikator (RS-232). Hver at de digitale kortene har indikatorer for hvert IO-bit og analogkortene har indikasjon av power.

En ni-korts SLC 500 vises i neste bilde. Denne styrer et vannbehandlingssystem med høy rensningsgrad for biologiske legemiddel produksjon. Som du ser er ikke alle plassene opptatt i dette systemet heller.

$\displaystyle \includegraphics[height=16cm]{plc_018.eps}$

Noen av inngangene til denne PLS-en er vannivåbrytere, trykkbrytere, flowmålere ledningsevnemålere (for å måle renheten av vannet, jo renere vannet er jo mindre leder det.) Utgangene til PLS-en styrer start og stopp av pumper og ventiler for kontrollere vennrensing og lagring.

Siemens S7-300 som er en mer moderne PLS fra Siemens. Det er en annen type modulær PLS, istedenfor kort som plugges i brukes individuelle moduler som kan plugges sammen.

$\displaystyle \includegraphics[width=16cm]{plc_003.eps}$

En moderne PLS produsert av Allen-Bardley er ControlLogix 5000 systemet, som vises i neste bilde. Den brukes til å styre en prosess for produksjon av frokostblanding. Dette systemet følger et mer trasisjonelt system med individuelle kort som plugges i et rack med fast størrelse.

$\displaystyle \includegraphics[width=16cm]{plc_004.eps}$

Siemens S7 og Rockwell ControlLogix er eksempler på modulære PLS systemer som kan tilpasses store installasjoner. Det finnes andre PLS-er som er mye billigere. Et eksempel er Koyo Click serien med PLS-er. En prosessormodul med 6 DI(Digiale Innganger) og 6 DO(Digitale Utganger) vises på bildet.(Denne kostet 69 USD i 2010, med gratis programmeringsverktøy.).

$\displaystyle \includegraphics[width=10cm]{plc_005.eps}$

Dette er et semi-modulært PLS system, en prosessormodul med et minumum av IO-er, som det er mulig å utvide med flere moduler som plugges i siden, omtrent på samme måte som Siemens S7-300 serien.

Andre semi-modulære PLS-er bruker IO-kort for å utvide grunnmodulen. Koyo DirectLogic DL06 er et eksempel på denne type PLS. Bildet viser DL06 som det settes et kort for termoelementer i en av de 4 ledige plassene.

$\displaystyle \includegraphics[width=10cm]{plc_007.eps}$

Dette bildet viser en PLS grunnmodul med 20 DI og 16 DO kanaler. Kotet som settes i er for analoge signaler fra thermoelementer. Det kan kobles 4 thermoelementer til kortet.

Noen billige kompakt PLS-er har ikke mulighet for utvidelse med IO-moduler. Denne General Electric Series One PLS (bruk til å overvåke et mini vannkraftverk) er et eksempel på dette.

$\displaystyle \includegraphics[width=10cm]{plc_006.eps}$

Ulempen med et kompakt PLS er at en defekt IO ikke kan byttes ut sepparat. Hele PLS-en må byttes. I et modulært system kan hver IO-modul byttes ved feil. En annen ulempe er at brukeren er låst til IO-konfigurasjonen som PLS har. Det er ingen mulighet for tilpassning til bruken. På grunn av dette brukes som oftest kompakt PLS-er på mindre automatiserte anlegg der en ikke forventer behov for utvidelse.

Inngangs- og utgangs tilkoblinger IO-er

Alle PLS-er må kunne motta og forstå signaler fra den virklige verden, f.eks. byrtere og enkodere. Den må også kunne kontrollere enheter som solenoider, ventiler og motorer. Dette kalls for PLS-ens IO-kapasitet. En kompakt PLS har en bestemt IO-kapasitet, mens en modulær PLS har mulighet for å konfigurere IO-kapasiteten.

$\displaystyle \includegraphics{plc_075.eps}$

Det er mange fordeler med å bruke IO-moduler istedenfor en kompakt PLS. Den visktigste er at devekte IO-kort kan byttes uten å måtte bytte hele PLS-en. Det er også mulig å velge IO-kort alt etter behovet i styringssystemet. Typisk trenger styringsoppgaver som flytter på "ting" mange digitale inn- og utganger, mens en i prosessanlegg trenger flere analoge inn og -utganger. Noen PLS-systemer har også muligheten for hot-swappable moduler, det vil si at de kan byttes uten å ta strømmen fra PLS-systemet. Vær obs på at dette bare kan gjøres på systemer som er laget for det, ellers kan du ødlegge PLS-systemet.

Noen PLS-er har mulighet for tilkobling av eksterne moduler uten prosessorer, dette gjør det mulig å utvide IO-kapasiteten . Disse kobles sammen til et digitalt nettverk med en kommunikasjonskabel. Dette gjør at en kan ha stor fysisk avstand mellom PLS og IO-er på et anlegg. Slike eksterne IO-enheter kalles normalt for en RIO (Remote IO) .

$\displaystyle \includegraphics{plc_008.eps}$

Et alternativ til et styresystem med remote IO er å koble sammen flere PLS-er. En kan da programmere PLS-ene til å dele på IO-er, for på den måten å utvide IO-kapasiteten. Dette er en dyr metode, men detn gir mulighet for videre drift selv om det skulle være feil på nettverket.

IO-tilkoblinger for en PLS kommer i to ulike kategorier digitale og analoge disse beskrives i de neste kaptittelene.

Digitale IO-er

Et digitalt singal for en PLS, er et signal som kan ha to tilstander av og . Disse bruker datatypen BOOL i internt i PLS-en. Trykkbrytere, temperaturbrytere, trykknappbrytere, endebrytere og nærhetssensorer er eksempler på digitale signalkilder for en PLS. For at PLS-en skal lese signaler fra denne type sensorer må den ha en digitale innganger. Digitale innganger på en PLS vil ha en lysdiode som indikerer om en inngang er aktivert eller ikke. Det vil også være en annen LED som er en del av en optokobler. Optokobleren lager et galvansik skille mellom sensorkretsen og mikroprosessorkretsen inne i PLS-en. Et slikt system gjør at en PLS er mindre følsom fra spenningstransienter. Optokobleren aktiver et bit inn minnet til PLS-en. Dette minnet brukes av PLS programmet til å avgjøre om en sensor er aktivert eller ikke.

$\displaystyle \includegraphics{plc_073.eps}$

Det interne koblingskjemaet for en inngangmodul viser de viktigste komponentene for en inngang. Hver inngang har samme kretsen som skriver til hvert sitt bit i PLS-ens minne. Digitale inngangmoduler har vanligvis 4, 8, 16 eller 32 innganger.

Signallamper, magnetventiler og motorstartere er alle eksempler på digitale styringselementer. Omtrent på samme måte som digitale innganger kobler PLS-en seg til digitale styringselementt ved hjelp av digitale utgangsmoduler. Digitale utgangsmoduler bruker ofte samme type galvansik skille som inngangmoduler, ved hjelp av en optokobler. Alternativt brukes også elektromekaniske releer.

$\displaystyle \includegraphics{plc_074.eps}$

Som ved den digitaleinngangsmodule vises et koblingsskjema en av flere utganger. Hver utgang har sitt tilhørende bit i minnet som vil aktivere utgangen. Digitale ugangsmoduler har typisk 4, 8, 16, eller 32 utganger.

Et viktig konsept å beherske når en jobber med digitale inn- og utganger er forskjellen mellom current-sourcing og current-sinking. Begrepene "sourcing" og "sinking" refererer til retningen til strømmen inn eller ut av terminalen for styresignal. En enhet som sender strøm ut av styreterminalen sies å sourcing, mens utstrm som tar imont strøm sies å være sinking.

Tegningen nedenfor illustrerer PLS utgang som er current sourcing for en lampe som er currentsinking.

$\displaystyle \includegraphics{plc_009.eps}$

Om det tilkoblede utstyret polaritetsuavhengig, er det like gylding om en har sourcing eller sinking DI-modul. Bildet viser et eksempel med en endebryter.

$\displaystyle \includegraphics{plc_010.eps}$

$\displaystyle \includegraphics{plc_011.eps}$

Legg merke til polariteten på fellesterminalen på begge moduelene. Modulen som er sinking har fellesterminalen koblet til minus, mens modulen som er sourcing er koblet til +.

Noen digitale sensorer har en bestempt polaritet, f.eks. nærhetssensorer med transistorutgang. En sourcing nærhetssensor kan bare kobles til en sinking PLS inngang, og visa versa.

$\displaystyle \includegraphics{plc_012.eps}$

I alle tilfellene sender enheten som er sourcing ut strøm fra signalterminalen til sinking enheten som mottar signal på sin signalterminal.

Her vises to bilder av en DI module(1746-IB8) til Allen-Bradley modell SLC 500 PLS. På det dene bilder er dekselset lukket. På det andre er dekselet åpen og vi ser terminalene sammen med en forklaring på funksjonen til hver terminal. Her ser vi at modulen har 8 digitale innganger, nummerert fra IN0 til IN7, og to tilkoblinger for COM. Vi ser også at dette er en DC-SINK modul.

$\displaystyle \includegraphics[height=4in]{plc_013.eps} \hskip 30pt \includegraphics[height=4in]{plc_014.eps}$

En standard funksjon som nesten alle digitale innganger har er et indikatorlys som viser når inngangen er aktiv. På 1746-IB8 modulen til Allen-Bradley SLC 500 PLS systemen ser vi disse samlet på toppen av modulen i to rekker.

Et bilde av DI terminalene til en annen PLS (Koyo model DL06) viser en annen merking.

$\displaystyle \includegraphics[width=16cm]{plc_015.eps}$

Her er hver utgang gitt et bokstavnummer kombinasjon som starter med Y ellerfult av nummere på utgangen. Det er også C terminaler, dette er fellesterminaler for samlinger på fireutganger på denne PLS-en. Selv som det kan virke litt tungvint å ha flere fellesterminaler, så gjør dette PLS-en mer fleksibler for flere driftsspenninger og det muliggjør bruk av interne styrespenninger fra utstyr.

Elektriske polaritet er ikke noe en trenger å tenke på ved bruk av digitale innganger for AC, siden polariteten snus hver periode uansett. En må likevell tenke på om fellesterminalen skal kobles til nøytral eller en av faselederene. Denne informasjonen vil en finne i leverandør manualen for den aktuelle modulen.

Neste bilde viser en digital utgangsmodul for AC fra Allen-Bradly. Her brukes triacer på utgangen istedenfor transistorer som er vanlig for DC type utganger.

$\displaystyle \includegraphics[height=4in]{plc_021.eps}$

Denne 8 kanals modulen har to sett med TRIACer som får spenning fra hver sine fellesterminaler VAC1 og VAC2, den andre siden av lasten kobles til motsatt faseleder eller nøytral.

Heldigvis leverer leverandørene manualer som illurtrerer hvordan digitale inn og utganger skal kobles til feltutstyret. Det er viktig at du alltid setter deg inn i disse manualene.

Analog I/O

Når PLS-ene kom på markedet på markedet, var prosessorhastigheten og minnet så begrenset at det ikke var mulig å støtte annet en digitale styringsfunksjoner. Derfor ble de også bare laget med digitale IO-er. Moderne PLS-er har nok prosessorkrat og minne til å støtte måling, prossesering og styring av analoge signaler.

En PLS jobber digitalt internt. For å ta imot og sende ut analoge singaler er det nødvendig med en omformer mellom digitale og analoge signaler. I alle analoge inngangmoduler er det en ADC, eller Analog til Digital Converter som skal konvertere det eletriske signalet på inngangen til et binert tall. Det motsatte trengs på en analog utgangsmodul, der brukes en , DAC, eller Digital til Analog Converter som konverterter binære tall til analoge elektriske signaler.

Analog IO finnes for mange ulike typer analoge signaler, noen som brukes masse er:

Bildene viser to analoge IO-kort til en Allen-Bradley SLC 500. Det er et analogt inngangskort(AI) og et analogt utgangskfort(AO). Merkelappen i dekselet indikerer hvordan modulene skal kobles.

$\displaystyle \includegraphics[height=6in]{plc_019.eps} \hskip 30pt \includegraphics[height=6in]{plc_020.eps}$

Network I/O

Many different digital network standards exist for PLCs to communicate with, from PLC to PLC and between PLCs and field devices. One of the earliest digital protocols developed for PLC communication was Modbus, originally for the Modicon brand of PLC. Modbus was adopted by other PLC and industrial device manufacturers as a de facto standard1.1, and remains perhaps the most universal digital protocol available for industrial digital devices today.

Another digital network standard developed by a particular manufacturer and later adopted as a de facto standard is Profibus, originally developed by Siemens.

For more information on networking standards used in PLC systems, refer to the “Digital electronic instrumentation” chapter, specifically sections on specific network standards such as Modbus and Profibus.

.

Det kan se ut som alle PLS-er har sin egen standard for programmering, men det finnes en international standard for PLS progarmmering som de fleste PLS produsenter i det minste forsøker å følge. Dette er IEC 61131-3, som vi vil bruke her.

En kan trøste seg med at selv som detaljene fra et PLS programmeringsverktøy til et annet, er prinseppene i det store å hele det samme. Det er mye større forskjelle i generelle programmeringsspråk( som C/C++, BASIC, FORTRAN, Pascal, Java, bl.a. )en mellom prgrammeringsverktøy fra ulike PLS leverandører, på tross av dette behersker programmere flere språk. Tony har programmert mange ulike PLS-er (Allen-Bradley, Siemens, SquareD, Koyo, Fanuc, Moore Products APACA AND QUADLOG og Modicon) med ulike typer av PLS innfor mange av merkene, og han kan fortelle at forskjellene i det store og hele er ubetydlige. Etter å ha lært en type PLS er det enkelt å gå over til en annen PLS. Selv om du programmerer en PLS som ikke følger IEC 61131-3 kan du følge prinsippene i dette kapittelet. De grunnleggende prinsippene er universelle.

IEC-61131-3 standarden spesifiserer fem forskjellige programmeringsspråk for industrielle styringer:

Ikke alle programmeringsspråk støttes av alle PLS-er, men omtrent alle støtter Ladder Diagram (LD), som vil være fokus i denne boken.

Sammenhengen mellom IO-status og virtuelle brytere

Et konsept som krever litt tilvenning når en lærer å programmere PLS er sammenhengen mellom IO-ene og statusen på variabler og andre elementer i programmet. Dette gjelder spesielt for Ladder diagram (LD), der programmet ligner et elektriske skjema. Det er viktig å gjøre den mentale koblingen mellom virklige byrere og sensorer i anlegget og de tenkte byrerene og relespolene en finner i PLS-programmet.

En grunnleggende regel en må tenke på når en leser et ladder program er at hver kontakt i programmet aktiveres ved at den leser "1" i det tilhørende minnebit, og at den deaktiveres når den leser "0" i det tilhørdne minnebit.. For en NO kontakt vil det si at den er lukket nå tilhørdne minnebit er "1" For en NO kontakt vil det si at den er lukket når tilhørende minnebit er "0". Om et bit har tilstanden "0" vil det si at tilhørdne kontakt er i sin normale posisjon, mens en bitstatus på "1" vil få kontakten til å aktivere og gå i sin aktive tilstand.

En annen viktig regel når en leser PLS programmer er at programmeringsgrensesnittet tilbyr farge merkeing for å markere virtuel status av hvert program element. En farget kontakt(-$\vert$ $\vert$-) er lukket, mens en ikke farget (-$\vert$ $\vert$-) er åpen. Om bryteren har en skråstrek (-$\vert/\vert$-) eller ikke (-$\vert\:\vert$-) marker hvilken normale status brytern har, så marker farge om den er lukket eller ikke.

Tabellen nedenfor viser hvordan to typer kontakter et PLS ladder program forholder seg til ulike bitstatuser. Det brukes rød for å vise når en virtuell kontakt leder.

$\displaystyle \includegraphics{plc_065.eps}$

Akkurat som en trykkbryter aktiveres av høyt trykk, og en nivåbryter aktiveres av høyt nivå, og en temperaturbyter aktiveres av høy temperatur, så vil en PLS sine virtuelle brytere aktiveres av et høyt bit status. Med en bryte sin aktiverte tilstand mener vi det motsatte av den normale tilstand.

Illustrasjonen nedenfor viser en kompakt PLS med to av de digitale inngangene aktivert, noe som gjør at de tilhørende bit i inngangsregisteret er høye (TRUE eller "1"). De kontaktene som er farget i PLS programmeringsverktøyet viser virtuelle kontakter som vil sende signalet videre ved de statuser som vises i inngangsregisteret.

$\displaystyle \includegraphics{plc_064.eps}$

Husk at en farget kontakt er en lukket kontakt. De kontaktene som er farget er enten NC kontakter med "0" bit status, eller NO kontakter med "1" bit status. Det er kombinasjonen av bit status og type kontakt (NO/NC) som avgjør om den virtuelle kontakten vil være åpen (ikke farget) eller lukket (farget).

Min erfaring som lærer er at hovedproblemet elever har med å forstå PLS ladderprogrammer, er at de prøver å simplifisere ved å relatere vituelle kontakter i pls programmet med kontakter ute i anlegget. Det som skjer er at kontakter i anlegget sender spenning til inngange som igjen styrer status til den virtuelle kontakten i PLS programmet. Typiske feil som elever gjøre er:

Oppsummering av grunnleggende regler når en leser et PLS ladder program:

Dette er meget viktige regler å ha klart for seg når en skal forstå PLS ladder programmer.

Fargemerking av en coil [—( )] i ladder PLS programmer følger lignende regler. En coil vil være "på" (farget) når alle brytere og funksjoner før den er farget. En coil som er farget vil skrive "1" til tilhørende bit i minnet, mens en coil som ikke er farget sender en "0" til det tilhørende minnebit. Om disse minnebitene har en kobling mot fysike digitale utganger vil disse bli aktivert

For å se nærmere på disse grunnleggende konseptene, se nærmere på en PLS styring for å aktivere et varsellys for høyt trykk i en væsketank. PLSen sin oppgave er å aktivere varsellyset når trykket i tanken overstiger 18 BAR, og holde det aktivt selv om det faller under 18 BAR igjen. På denne måten vil operatørene varsles med både nåværende feil og feil som har vært.

230 Volt AC forsyningen (L1 og L2) forsyner PLS-en med driftsspenning, den gir også signalpotensial for inngangsbyterene og driftsspenning for varsellampen. To brytere er koblet til inngangen på denne PLS-en: en NO trykknappbryter, som virker som resetbryter for alarmen, og en NO trykkbryter som gir signal om høyt trykk i prosesstanken.

$\displaystyle \includegraphics{plc_055.eps}$

Resetknappen kobles til den digitale inngangen X1 på PLS-en, mens trykkbryteren kobles til den digitale inngangen X4. Varsellampen kobles til den digitale utgangen Y5. Røde indikatorlys ved siden av hver inngang indikerer status den den respektive inngangen. Rød bakgrunn på brytere i PLS programmet representerer en bryter som sender signalet videre.

Når ingen trykker på resetkanppen vil den være i sin normale posisjon, som for denne bryteren er åpen (NO). Det samme gjelder for trykkbyteren. Når trykket er under 18 BAR vil bryteren være i sin normale posisjon som er åpen (NO). Siden ingen av bryterne leder, vil heller ingen av de digitale inngangene på PLS-en være aktive. Dette betyr at de virtuelle bryterne i PLS programmet også vil være i sin normal posisjon. Da vil alle NO brytere stoppe signalet og alle NC brytere sende signalet videre. Derfor ser en på bildet at X4 og Y5 ikke er merket med rødt, mens X1 er merket rødt. Brytere som er merket rødt betyr at de sender de sender signalet videre og utganger som er merket rødt beytr at de er aktive.

Om trykket i prosesstanken overstiger 18 BAR aktiveres trykkbrteren og NO-kontaktsettet lukkes.

If the process vessel experiences a high pressure ($>$ 270 PSI), the pressure switch will actuate, closing its normally-open contact. This will energize input X4 on the PLC, which will “close” the virtual contact X4 in the ladder program. This sends virtual power to the virtual “coil” Y5, which in turn latches itself on through virtual contact Y51.2 and also energizes the real discrete output Y5 to energize the warning lamp:

$\displaystyle \includegraphics{plc_056.eps}$

If now the process pressure falls below 270 PSI, the pressure switch will return to its normal state (open), thus de-energizing discrete input X4 on the PLC. Because of the latching contact Y5 in the PLC's program, however, output Y5 remains on to keep the warning lamp in its energized state:

$\displaystyle \includegraphics{plc_057.eps}$

Thus, the Y5 contact performs a seal-in function to keep the Y5 bit set (1) even after the high-pressure condition clears. This is precisely the same concept as the “seal-in” auxiliary contact on a hard-wired motor starter circuit, where the electromechanical contactor keeps itself energized after the “Start” pushbutton switch has been released.

The only way for a human operator to re-set the warning lamp is to press the pushbutton. This will have the effect of energizing input X1 on the PLC, thus opening virtual contact X1 (normally-closed) in the program, thus interrupting virtual power to the virtual coil Y5, thus powering down the warning lamp and un-latching virtual power in the program:

$\displaystyle \includegraphics{plc_058.eps}$

Memory maps and I/O addressing

A wise PLC programmer once told me that the first thing any aspiring programmer should learn about the PLC they intend to program is how the digital memory of that PLC is organized. This is sage advice for any programmer, especially on systems where memory is limited, and/or where I/O has a fixed association with certain locations in the system's memory. Virtually every microprocessor-based control system comes with a published memory map showing the organization of its limited memory: how much is available for certain functions, which addresses are linked to which I/O points, how different locations in memory are to be referenced by the programmer.

Discrete input and output channels on a PLC correspond to individual bits in the PLC's memory array. Similarly, analog input and output channels on a PLC correspond to multi-bit words (contiguous blocks of bits) in the PLC's memory. The association between I/O points and memory locations is by no means standardized between different PLC manufacturers, or even between different PLC models designed by the same manufacturer. This makes it difficult to write a general tutorial on PLC addressing, and so my ultimate advice is to consult the engineering references for the PLC system you intend to program.

The most common brand of PLC in use in the United States at the time of this writing (2010) is Allen-Bradley (Rockwell), which happens to use a unique form of I/O addressing1.3 students tend to find confusing. For these two reasons (popularity and confusion), I will focus on Allen-Bradley addressing conventions for the bulk of this section.

The following table shows a partial memory map for an Allen-Bradley SLC 500 PLC1.4:

$\displaystyle \vbox{\offinterlineskip
\halign{\strut
\vrule \quad\hfil  ...

Note that Allen-Bradley's use of the word “file” differs from personal computer parlance. In the SLC 500 controller, a “file” is a block of random-access memory used to store a particular type of data. By contrast, a “file” in a personal computer is a contiguous collection of data bits with collective meaning (e.g. a word processing file or a spreadsheet file), usually stored on the computer's hard disk drive. Within each of the Allen-Bradley PLC's “files” are multiple “elements,” each element consisting of a set of bits (8, 16, 24, or 32) representing data. Elements are addressed by number following the colon after the file designator, and individual bits within each element addressed by a number following a slash mark. For example, the first bit (bit 0) of the second element in file 3 (Binary) would be addressed as B3:2/0.

In Allen-Bradley PLCs such as the SLC 500 and PLC-5 models, files 0, 1, and 2 are exclusively reserved for discrete outputs, discrete inputs, and status bits, respectively. Thus, the letter designators O, I, and S (file types) are redundant to the numbers 0, 1, and 2 (file numbers). Other file types such as B (binary), T (timers), C (counters), and others have their own default file numbers (3, 4, and 5, respectively), but may also be used in some of the user-defined file numbers (10 and above). For example, file 7 in an Allen-Bradley controller is reserved for data of the “integer” type (N), but integer data may also be stored in any file numbered 10 or greater at the user's discretion. Thus, file numbers and file type letters for data types other than output (O), input (I), and status (S) always appear together. You would not typically see an integer word addressed as N:30 (integer word 30 in the PLC's memory) for example, but rather as N7:30 (integer word 30 in file 7 of the PLC's memory) to distinguish it from other integer word 30's that may exist in other files of the PLC's memory.

This file-based addressing notation bears further explanation. When an address appears in a PLC program, special characters are used to separate (or “delimit”) different fields from each other. The general scheme for Allen-Bradley SLC 500 PLCs is shown here:

$\displaystyle \includegraphics{plc_062.eps}$

Not all file types need to distinguish individual words and bits. Integer files (N), for example, consist of one 16-bit word for each element. For instance, N7:5 would be the 16-bit integer word number five held in file seven. A discrete input file type (I), though, needs to be addressed as individual bits because each separate I/O point refers to a single bit. Thus, I:3/7 would be bit number seven residing in input element three. The “slash” symbol is necessary when addressing discrete I/O bits because we do not wish to refer to all sixteen bits in a word when we just mean a single input or output point on the PLC. Integer numbers, by contrast, are collections of 16 bits each in the SLC 500 memory map, and so are usually addressed as entire words rather than bit-by-bit1.5.

Certain file types such as timers are more complex. Each timer “element1.6” consists of two different 16-bit words (one for the timer's accumulated value, the other for the timer's target value) in addition to no less than three bits declaring the status of the timer (an “Enabled” bit, a “Timing” bit, and a “Done” bit). Thus, we must make use of both the decimal-point and slash separator symbols when referring to data within a timer. Suppose we declared a timer in our PLC program with the address T4:2, which would be timer number two contained in timer file four. If we wished to address that timer's current value, we would do so as T4:2.ACC (the “Accumulator” word of timer number two in file four). The “Done” bit of that same timer would be addressed as T4:2/DN (the “Done” bit of timer number two in file four)1.7.

A hallmark of the SLC 500's addressing scheme common to many legacy PLC systems is that the address labels for input and output bits explicitly reference the physical locations of the I/O channels. For instance, if an 8-channel discrete input card were plugged into slot 4 of an Allen-Bradley SLC 500 PLC, and you wished to specify the second bit (bit 1 out of a 0 to 7 range), you would address it with the following label: I:4/1. Addressing the seventh bit (bit number 6) on a discrete output card plugged into slot 3 would require the label O:3/6. In either case, the numerical structure of that label tells you exactly where the real-world input signal connects to the PLC.

To illustrate the relationship between physical I/O and bits in the PLC's memory, consider this example of an Allen-Bradley SLC 500 PLC, showing one of its discrete input channels energized (the switch being used as a “Start” switch for an electric motor):

$\displaystyle \includegraphics{plc_016.eps}$

If an input or output card possesses more than 16 bits – as in the case of the 32-bit discrete output card shown in slot 3 of the example SLC 500 rack – the addressing scheme further subdivides each element into words and bits (each “word” being 16 bits in length). Thus, the address for bit number 27 of a 32-bit input module plugged into slot 3 would be I:3.1/11 (since bit 27 is equivalent to bit 11 of word 1 – word 0 addressing bits 0 through 15 and word 1 addressing bits 16 through 31):

$\displaystyle \includegraphics{plc_059.eps}$

A close-up photograph of a 32-bit DC input card for an Allen-Bradley SLC 500 PLC system shows this multi-word addressing:

$\displaystyle \includegraphics[width=4in]{plc_063.eps}$

The first sixteen input points on this card (the left-hand LED group numbered 0 through 15) are addressed I:X.0/0 through I:X.0/15, with “X” referring to the slot number the card is plugged into. The next sixteen input points (the right-hand LED group numbered 16 through 31) are addressed I:X.1/0 through I:X.1/15.

Legacy PLC systems typically reference each one of the I/O channels by labels such as “I:1/3” (or equivalent1.8) indicating the actual location of the input channel terminal on the PLC unit. The IEC 61131-3 programming standard refers to this channel-based addressing of I/O data points as direct addressing. A synonym for direct addressing is absolute addressing.

Addressing I/O bits directly by their card, slot, and/or terminal labels may seem simple and elegant, but it becomes very cumbersome for large PLC systems and complex programs. Every time a technician or programmer views the program, they must “translate” each of these I/O labels to some real-world device (e.g. “Input I:1/3 is actually the Start pushbutton for the middle tank mixer motor”) in order to understand the function of that bit. A later effort to enhance the clarity of PLC programming was the concept of addressing variables in a PLC's memory by arbitrary names rather than fixed codes. The IEC 61131-3 programming standard refers to this as symbolic addressing in contrast to “direct” (channel-based) addressing, allowing programmers arbitrarily name I/O channels in ways that are meaningful to the system as a whole. To use our simple motor “Start” switch example, it is now possible for the programmer to designate input I:1/3 (an example of a direct address) as “Motor_start_switch” (an example of a symbolic address) within the program, thus greatly enhancing the readability of the PLC program. Initial implementations of this concept maintained direct addresses for I/O data points, with symbolic names appearing as supplements to the absolute addresses.

The modern trend in PLC addressing is to avoid the use of direct addresses such as I:1/3 altogether, so they do not appear anywhere in the programming code. The Allen-Bradley “Logix” series of programmable logic controllers is the most prominent example of this new convention at the time of this writing. Each I/O point, regardless of type or physical location, is assigned a tag name which is meaningful in a real-world sense, and these tag names (or symbols as they are alternatively called) are referenced to absolute I/O channel locations by a database file. An important requirement of tag names is that they contain no space characters between words (e.g. instead of “Motor start switch”, a tag name should use hyphens or underscore marks as spacing characters: “Motor_start_switch”), since spaces are generally assumed by computer programming languages to be delimiters (separators between different variables).

Having introduced Allen-Bradley's addressing notation for SLC 500 model PLCs, I will now abandon it in favor of the modern convention of symbolic addressing throughout the rest of this chapter, so as to avoid making the programming examples brand- or model-specific. Each data point within my PLC programs will bear its own tag name rather than a direct (channel-based) address label.

Ladder Diagram (LD) programming

In the United States, the most common language used to program PLCs is Ladder Diagram (LD), also known as Relay Ladder Logic (RLL). This is a graphical language showing the logical relationships between inputs and outputs as though they were contacts and coils in a hard-wired electromechanical relay circuit. This language was invented for the express purpose of making PLC programming feel “natural” to electricians familiar with relay-based logic and control circuits. While Ladder Diagram programming has many shortcomings, it remains extremely popular and so will be the primary focus of this chapter.

Every Ladder Diagram program is arranged to resemble an electrical diagram, making this a graphical (rather than text-based) programming language. Ladder diagrams are to be thought of as virtual circuits, where virtual “power” flows through virtual “contacts” (when closed) to energize virtual “relay coils” to perform logical functions. None of the contacts or coils seen in a Ladder Diagram PLC program are real; rather, they act on bits in the PLC's memory, the logical inter-relationships between those bits expressed in the form of a diagram resembling a circuit.

The following computer screenshot shows a typical Ladder Diagram program1.9 being edited on a personal computer:

$\displaystyle \includegraphics[width=6in]{plc_022.eps}$

Contacts appear just as they would in an electrical relay logic diagram – as short vertical line segments separated by a horizontal space. Normally-open contacts are empty within the space between the line segments, while normally-closed contacts have a diagonal line crossing through that space. Coils are somewhat different, appearing as either circles or pairs of parentheses. Other instructions appear as rectangular boxes.

Each horizontal line is referred to as a rung, just as each horizontal step on a stepladder is called a “rung.” A common feature among Ladder Diagram program editors, as seen on this screenshot, is the ability to color-highlight those virtual “components” in the virtual “circuit” ready to “conduct” virtual “power.” In this particular editor, the color used to indicate “conduction” is light blue. Another form of status indication seen in this PLC program is the values of certain variables in the PLC's memory, shown in red text.

For example, you can see coil T2 energized at the upper-right corner of the screen (filled with light blue coloring), while coil T3 is not. Correspondingly, each normally-open T2 contact appears colored, indicating its “closed” status, while each normally-closed T2 contact is uncolored. By contrast, each normally-open T3 contact is uncolored (since coil T3 is unpowered) while each normally-closed T3 contact is shown colored to indicate its conductive status. Likewise, the current count values of timers T2 and T3 are shown as 193 and 0, respectively. The output value of the math instruction box happens to be 2400, also shown in red text.

Color-highlighting of Ladder Diagram components only works, of course, when the computer running the program editing software is connected to the PLC and the PLC is in the “run” mode (and the “show status” feature of the editing software is enabled). Otherwise, the Ladder Diagram is nothing more than black symbols on a white background. Not only is status highlighting very useful in de-bugging PLC programs, but it also serves an invaluable diagnostic purpose when a technician analyzes a PLC program to check the status of real-world input and output devices connected to the PLC. This is especially true when the program's status is viewed remotely over a computer network, allowing maintenance staff to investigate system problems without even being near the PLC!

Contacts and coils

The most elementary objects in Ladder Diagram programming are contacts and coils, intended to mimic the contacts and coils of electromechanical relays. Contacts and coils are discrete programming elements, dealing with Boolean (1 and 0; on and off; true and false) variable states. Each contact in a Ladder Diagram PLC program represents the reading of a single bit in memory, while each coil represents the writing of a single bit in memory.

Discrete input signals to the PLC from real-world switches are read by a Ladder Diagram program by contacts referenced to those input channels. In legacy PLC systems, each discrete input channel has a specific address which must be applied to the contact(s) within that program. In modern PLC systems, each discrete input channel has a tag name created by the programmer which is applied to the contact(s) within the program. Similarly, discrete output channels – referenced by coil symbols in the Ladder Diagram – must also bear some form of address or tag name label.

To illustrate, we will imagine the construction and programming of a redundant flame-sensing system to monitor the status of a burner flame using three sensors. The purpose of this system will be to indicate a “lit” burner if at least two out of the three sensors indicate flame. If only one sensor indicates flame (or if no sensors indicate flame), the system will declare the burner to be un-lit. The burner's status will be visibly indicated by a lamp that human operators can readily see inside the control room area.

Our system's wiring is shown in the following diagram:

$\displaystyle \includegraphics{plc_023.eps}$

Each flame sensor outputs a DC voltage signal indicating the detection of flame at the burner, either on (24 volts DC) or off (0 volts DC). These three discrete DC voltage signals are sensed by the first three channels of the PLC's discrete input card. The indicator lamp is a 120 volt light bulb, and so must be powered by an AC discrete output card, shown here in the PLC's last slot.

To make the ladder program more readable, we will assign tag names (symbolic addresses) to each input and output bit in the PLC, describing its real-world device in an easily-interpreted format1.10. We will tag the first three discrete input channels as IN_sensor_A, IN_sensor_B, and IN_sensor_C, and the output as OUT_burner_lit.

A ladder program to determine if at least two out of the three sensors detect flame is shown here, with the tag names referencing each contact and coil:

$\displaystyle \includegraphics{plc_024.eps}$

Series-connected contacts in a Ladder Diagram perform the logical AND function, while parallel contacts perform the logical OR function. Thus, this two-out-of-three flame-sensing program could be verbally described as:

$\displaystyle \hbox{\lq\lq Burner is lit if either \texttt{A} \textit{and} \texttt{B...
...extit{and} \texttt{C}, \textit{or} either \texttt{A} \textit{and} \texttt{C}''}$

An alternate way to express this is to use the notation of Boolean algebra, where multiplication represents the AND function and addition represents the OR function:

$\displaystyle \hbox{Burner\_lit} = AB + BC + AC$

Yet another way to represent this logical relationship is to use logic gate symbols:

$\displaystyle \includegraphics{plc_078.eps}$

To illustrate how this program would work, we will consider a case where flame sensors B and C detect flame, but sensor A does not1.11. This represents a two-out-of-three-good condition, and so we would expect the PLC to turn on the “Burner lit” indicator light as programmed. From the perspective of the PLC's rack, we would see the indicator LEDs for sensors B and C lit up on the discrete input card, as well as the indicator LED for the lamp's output channel:

$\displaystyle \includegraphics{plc_025.eps}$

Those two energized input channels “set” bits (1 status) in the PLC's memory representing the status of flame sensors B and C. Flame sensor A's bit will be “clear” (0 status) because its corresponding input channel is de-energized. The fact that the output channel LED is energized (and the “Burner lit” indicator lamp is energized) tells us the PLC program has “set” that corresponding bit in the PLC's output memory register to a “1” state.

A display of input and output register bits shows the “set” and “reset” states for the PLC at this moment in time:

$\displaystyle \includegraphics{plc_061.eps}$

Examining the Ladder Diagram program with status indication enabled, we see how only the middle contact pair is passing “virtual power” to the output coil:

$\displaystyle \includegraphics{plc_026.eps}$

Recall that the purpose of a contact in a PLC program is to read the status of a bit in the PLC's memory. These six “virtual contacts” read the three input bits corresponding to the three flame sensors. Each normally-open “contact” will “close” when its corresponding bit has a value of 1, and will “open” (go to its normal state) when its corresponding bit has a value of 0. Thus, we see here that the two contacts corresponding to sensor A appear without highlighting (representing no “conductivity” in the virtual relay circuit) because the bit for that input is reset (0). The two contacts corresponding to sensor B and the two contacts corresponding to sensor C all appear highlighted (representing “conductivity” in the virtual circuit) because their bits are both set (1).

Recall also that the purpose of a coil in a PLC program is to write the status of a bit in the PLC's memory. Here, the “energized” coil sets the bit for the PLC output 0 to a “1” state, thus activating the real-world output and sending electrical power to the “Burner lit” lamp.

Note that the color highlighting does not indicate a virtual contact is conducting virtual power, but merely that it is able to conduct power. Color highlighting around a virtual coil, however, does indicate the presence of virtual “power” at that coil.

Contacts and relays are not just useful for implementing simple logic functions, but they may also perform latching functions as well. A very common application of this in industrial PLC systems is a latching start/stop program for controlling electric motors by means of momentary-contact pushbutton switches. As before, this functionality will be illustrated by means of an hypothetical example circuit and program:

$\displaystyle \includegraphics{plc_027.eps}$

In this system, two pushbutton switches are connected to discrete inputs on a PLC, and the PLC in turn energizes the coil of a motor contactor relay by means of one of its discrete outputs1.12. An overload contact is wired directly in series with the contactor coil to provide motor overcurrent protection, even in the event of a PLC failure where the discrete output channel remains energized1.13.

The ladder program for this motor control system would look like this:

$\displaystyle \includegraphics{plc_028.eps}$

Pressing the “Start” pushbutton energizes discrete input channel 6 on the PLC, which “closes” the virtual contact in the PLC program labeled IN_switch_Start. The normally-closed virtual contact for input channel 7 (the “Stop” pushbutton) is already closed by default when the “Stop” button is not being pressed, and so the virtual coil will receive “power” when the “Start” pushbutton is pressed and the “Stop” pushbutton is not.

Note the seal-in contact bearing the exact same label as the coil: OUT_contactor. At first it may seem strange to have both a contact and a coil in a PLC program labeled identically1.14, since contacts are most commonly associated with inputs and coils with outputs, but this makes perfect sense if you realize the true meaning of contacts and coils in a PLC program: as read and write operations on bits in the PLC's memory. The coil labeled OUT_contactor writes the status of that bit, while the contact labeled OUT_contactor reads the status of that same bit. The purpose of this contact, of course, is to latch the motor in the “on” state after a human operator has released his or her finger from the “Start” pushbutton.

This programming technique is known as feedback, where an output variable of a function (in this case, the feedback variable is OUT_contactor) is also an input to that same function. The path of feedback is implicit rather than explicit in Ladder Diagram programming, with the only indication of feedback being the common name shared by coil and contact. Other graphical programming languages (such as Function Block) have the ability to show feedback paths as connecting lines between function outputs and inputs, but this capacity does not exist in Ladder Diagram.

A step-by-step sequence showing the operation and status of this simple program illustrates how the seal-in contact functions, through a start-up and shut-down cycle of the motor:

$\displaystyle \includegraphics{plc_029.eps}$

This sequence helps illustrate the order of evaluation or scan order of a Ladder Diagram program. The PLC reads a Ladder Diagram from left to right, top to bottom, in the same general order as a human being reads sentences and paragraphs written in English. However, according to the IEC 61131-3 standard, a PLC program must evaluate (read) all inputs (contacts) to a function before determining the status of a function's output (coil or coils). In other words, the PLC does not make any decision on how to set the state of a coil until all contacts providing power to that coil have been read. Once a coil's status has been written to memory, any contacts bearing the same tag name will update with that status on subsequent rungs in the program.

Step 5 in the previous sequence is particularly illustrative. When the human operator presses the “Stop” pushbutton, the input channel for IN_switch_Stop becomes activated, which “opens” the normally-closed virtual contact IN_switch_Stop. Upon the next scan of this program rung, the PLC evaluates all input contacts (IN_switch_Start, IN_switch_Stop, and OUT_contactor) to check their status before deciding what status to write to the OUT_contactor coil. Seeing that the IN_switch_Stop contact has been forced open by the activation of its respective discrete input channel, the PLC writes a “0” (or “False”) state to the OUT_contactor coil. However, the OUT_contactor feedback contact does not update until the next scan, which is why you still see it color-highlighted during step 5.

A potential problem with this system as it is designed is that the human operator loses control of the motor in the event of an “open” wiring failure in either pushbutton switch circuit. For instance, if a wire fell off a screw contact for the “Start” pushbutton switch circuit, the motor could not be started if it was already stopped. Similarly, if a wire fell off a screw contact for the “Stop” pushbutton switch circuit, the motor could not be stopped if it was already running. In either case, a broken wire connection acts the same as the pushbutton switch's “normal” status, which is to keep the motor in its present state. In some applications, this failure mode would not be a severe problem. In many applications, though, it is quite dangerous to have a running motor that cannot be stopped. For this reason, it is customary to design motor start/stop systems a bit differently from what has been shown here.

In order to build a “fail-stop” motor control system with our PLC, we must first re-wire the pushbutton switch to use its normally-closed (NC) contact:

$\displaystyle \includegraphics{plc_030.eps}$

This keeps discrete input channel 7 activated when the pushbutton is unpressed. When the operator presses the “Stop” pushbutton, the switch's contact will be forced open, and input channel 7 will de-energize. If a wire happens to fall off a screw terminal in the “Stop” switch circuit, input channel 7 will de-energize just the same as if someone pressed the “Stop” pushbutton, which will automatically shut off the motor.

In order for the PLC program to work properly with this new switch wiring, the virtual contact for IN_switch_Stop must be changed from a normally-closed (NC) to a normally-open (NO):

$\displaystyle \includegraphics{plc_031.eps}$

As before, the IN_switch_Stop virtual contact is in the “closed” state when no one presses the “Stop” switch, enabling the motor to start any time the “Start” switch is pressed. Similarly, the IN_switch_Stop virtual contact will open any time someone presses the “Stop” switch, thus stopping virtual “power” from flowing to the OUT_contactor coil.

Although this is a very common way to build PLC-controlled motor start/stop systems – with an NC pushbutton switch and an NO “Stop” virtual contact – students new to PLC programming often find this logical reversal confusing1.15. Perhaps the most common reason for this confusion is a mis-understanding of the “normal” concept for switch contacts, be they real or virtual. The IN_switch_Stop virtual contact is programmed to be normally-open (NO), but yet it is typically found in the closed state. Recall that the “normal” status of any switch is its status while in a resting condition of no stimulation, not necessarily its status while the process is in a “normal” operating mode. The “normally-open” virtual contact IN_switch_Stop is typically found in the closed state because its corresponding input channel is typically found energized, owing to the normally-closed pushbutton switch contact, which passes real electrical power to the input channel while no one presses the switch. Just because a switch is configured as normally-open does not necessarily mean it will be typically found in the open state! The status of any switch contact, whether real or virtual, is a function of its configuration (NO versus NC) and the stimulus applied to it.

Another concern surrounding real-world wiring problems is what this system will do if the motor contactor coil circuit opens for any reason. An open circuit may develop as a result of a wire falling off a screw terminal, or it may occur because the thermal overload contact tripped open due to an over-temperature event. The problem with our motor start/stop system as designed is that it is not “aware” of the contactor's real status. In other words, the PLC “thinks” the contactor will be energized any time discrete output channel 2 is energized, but that may not actually be the case if there is an open fault in the contactor's coil circuit.

This may lead to a dangerous condition if the open fault in the contactor's coil circuit is later cleared. Imagine an operator pressing the “Start” switch but noticing the motor does not actually start. Wondering why this may be, he or she goes to look at the overload relay to see if it is tripped. If it is tripped, and the operator presses the “Reset” button on the overload assembly, the motor will immediately start because the PLC's discrete output has remained energized all the time following the pressing of the “Start” switch. Having the motor start up as soon as the thermal overload is reset may come as a surprise to operations personnel, and this could be quite dangerous if anyone happens to be near the motor-powered machinery when it starts.

What would be safer is a motor control system that refuses to “latch” on unless the contactor actually energizes when the “Start” switch is pressed. For this to be possible, the PLC must have some way of sensing the contactor's status.

In order to make the PLC “aware” of the contactor's real status, we may connect the auxiliary switch contact to one of the unused discrete input channels on the PLC, like this:

$\displaystyle \includegraphics{plc_032.eps}$

Now, the PLC is able to sense the real-time status of the contactor via input channel 5.

We may modify the PLC program to recognize this status by assigning a new tag name to this input (IN_contactor_aux) and using a normally-open virtual contact of this name as the seal-in contact instead of the OUT_contactor bit:

$\displaystyle \includegraphics{plc_033.eps}$

Now, if the contactor fails to energize for any reason when the operator presses the “Start” switch, the PLC's output will fail to latch when the “Start” switch is released. When the open fault in the contactor's coil circuit is cleared, the motor will not immediately start up, but rather wait until the operator presses the “Start” switch again, which is a much safer operating characteristic than before.

A special class of virtual “coil” used in PLC ladder programming that bears mentioning is the “latching” coil. These usually come in two forms: a set coil and a reset coil. Unlike a regular “output” coil that positively writes to a bit in the PLC's memory with every scan of the program, “set” and “reset” coils only write to a bit in memory when energized by virtual power. Otherwise, the bit is allowed to retain its last value.

A very simple motor start/stop program could be written with just two input contacts and two of these latching coils (both bearing the same tag name, writing to the same bit in memory):

$\displaystyle \includegraphics{plc_034.eps}$

Note the use of a normally-open (NO) pushbutton switch contact (again!), with no auxiliary contact providing status indication of the contactor to the PLC. This is a very minimal program, shown for the strict purpose of illustrating the use of “set” and “reset” latching coils in Ladder Diagram PLC programming.

“Set” and “Reset” coils1.16 are examples of what is known in the world of PLC programming as retentive instructions. A “retentive” instruction retains its value after being virtually “de-energized” in the Ladder Diagram “circuit.” A standard output coil is non-retentive, which means it does not “latch” when de-energized. The concept of retentive and non-retentive instructions will appear again as we explore PLC programming, especially in the area of timers.

Ordinarily, we try to avoid multiple coils bearing the same label in a PLC Ladder Diagram program. With each coil representing a “write” instruction, multiple coils bearing the same name represents multiple “write” operations to the same bit in the PLC's memory. Here, with latching coils, there is no conflict because each of the coils only writes to the OUT_contactor bit when its respective contact is energized. So long as only one of the pushbutton switches is actuated at a time, there is no conflict between the identically-named coils.

This raises the question: what would happen if both pushbutton switches were simultaneously pressed? What would happen if both “Set” and “Reset” coils were “energized” at the same time? The result is that the OUT_contactor bit would first be “set” (written to a value of 1) then “reset” (written to a value of 0) in that order as the two rungs of the program were scanned from top to bottom. PLCs typically do not typically update their discrete I/O registers while scanning the Ladder Diagram program (this operation takes place either before or after each program scan), so the real discrete output channel status will be whatever the last write operation told it to be, in this case “reset” (0, or off).

Even if the discrete output is not “confused” due to the conflicting write operations of the “Set” and “Reset” coils, other rungs of the program written between the “Set” and “Reset” rungs might be. Consider for example a case where there were other program rungs following the “Set” and “Reset” rungs reading the status of the OUT_contactor bit for some purpose. Those other rungs would indeed become “confused” because they would see the OUT_contactor bit in the “set” state while the actual discrete output of the PLC (and any rungs following the “Reset” rung) would see the OUT_contactor bit in the “reset” state:

$\displaystyle \includegraphics{plc_035.eps}$

Multiple (non-retentive) output coils with the same memory address are almost always a programming faux pax for this reason, but even retentive coils which are designed to be used in matched pairs can cause trouble if the implications of simultaneous energization are not anticipated. Multiple contacts with identical addresses are no problem whatsoever, because multiple “read” operations to the same bit in memory will never cause a conflict.

The IEC 61131-3 PLC programming standard specifies transition-sensing contacts as well as the more customary “static” contacts. A transition-sensing contact will “actuate” only for a duration of one program scan, even if its corresponding bit remains active. Two types of transition-sensing Ladder Diagram contacts are defined in the IEC standard: one for positive transitions and another for negative transitions. The following example shows a wiring diagram, Ladder Diagram program, and a timing diagram demonstrating how each type of transition-sensing contact functions when stimulated by a real (electrical) input signal to a discrete channel:

$\displaystyle \includegraphics{plc_036.eps}$

When the pushbutton switch is pressed and the discrete input energized, the first test lamp will blink “on” for exactly one scan of the PLC's program, then return to its off state. The positive-transition contact (with the letter “P” inside) activates the coil OUT_test1 only during the scan it sees the status of IN_test transition from “false” to “true,” even though the input remains energized for many scans after that transition. Conversely, when the pushbutton switch is released and the discrete input de-energizes, the second test lamp will blink “on” for exactly one scan of the PLC's program then return to its off state. The negative-transition contact (with the letter “N” inside) activates the coil OUT_test2 only during the scan it sees the status of IN_test transition from “true” to “false,” even though the input remains de-energized for many scans after that transition:

It should be noted that the duration of a single PLC program scan is typically very short: measured in milliseconds. If this program were actually tested in a real PLC, you would probably not be able to see either test lamp light up, since each pulse is so short-lived. Transitional contacts are typically used any time it is desired to execute an instruction just one time following a “triggering” event, as opposed to executing that instruction over and over again so long as the event status is maintained “true.”

Contacts and coils represent only the most basic of instructions in the Ladder Diagram PLC programming language. Many other instructions exist, which will be discussed in the following subsections.

Counters

A counter is a PLC instruction that either increments (counts up) or decrements (counts down) an integer number value when prompted by the transition of a bit from 0 to 1 (“false” to “true”). Counter instructions come in three basic types: up counters, down counters, and up/down counters. Both “up” and “down” counter instructions have single inputs for triggering counts, whereas “up/down” counters have two trigger inputs: one to make the counter increment and one to make the counter decrement.

To illustrate the use of a counter instruction, we will analyze a PLC-based system designed to count objects as they pass down a conveyor belt:

$\displaystyle \includegraphics{plc_037.eps}$

In this system, a continuous (unbroken) light beam causes the light sensor to close its output contact, energizing discrete channel IN4. When an object on the conveyor belt interrupts the light beam from source to sensor, the sensor's contact opens, interrupting power to input IN4. A pushbutton switch connected to activate discrete input IN5 when pressed will serve as a manual “reset” of the count value. An indicator lamp connected to one of the discrete output channels will serve as an indicator of when the object count value has exceeded some pre-set limit.

We will now analyze a simple Ladder Diagram program designed to increment a counter instruction each time the light beam breaks:

$\displaystyle \includegraphics{plc_038.eps}$

This particular counter instruction (CTU) is an incrementing counter, which means it counts “up” with each off-to-on transition input to its “CU” input. The normally-closed virtual contact (IN_sensor_object) is typically held in the “open” state when the light beam is continuous, by virtue of the fact the sensor holds that discrete input channel energized while the beam is continuous. When the beam is broken by a passing object on the conveyor belt, the input channel de-energizes, causing the virtual contact IN_sensor_object to “close” and send virtual power to the “CU” input of the counter instruction. This increments the counter just as the leading edge of the object breaks the beam. The second input of the counter instruction box (“R”) is the reset input, receiving virtual power from the contact IN_switch_reset whenever the reset pushbutton is pressed. If this input is activated, the counter immediately resets its current value (CV) to zero.

Status indication is shown in this Ladder Diagram program, with the counter's preset value (PV) of 25 and the counter's current value (CV) of 0 shown highlighted in blue. The preset value is something programmed into the counter instruction before the system put into service, and it serves as a threshold for activating the counter's output (Q), which in this case turns on the count indicator lamp (the OUT_counts_reached coil). According to the IEC 61131-3 programming standard, this counter output should activate whenever the current value is equal to or greater than the preset value (Q is active if CV $\geq$ PV).

This is the status of the same program after thirty objects have passed by the sensor on the conveyor belt. As you can see, the current value of the counter has increased to 30, exceeding the preset value and activating the discrete output:

$\displaystyle \includegraphics{plc_039.eps}$

If all we did not care about maintaining an accurate total count of objects past 25 – but merely wished the program to indicate when 25 objects had passed by – we could also use a down counter instruction preset to a value of 25, which turns on an output coil when the count reaches zero:

$\displaystyle \includegraphics{plc_042.eps}$

Here, a “load” input causes the counter's current value to equal the preset value (25) when activated. With each sensor pulse received, the counter instruction decrements. When it reaches zero, the Q output activates.

A potential problem in either version of this object-counting system is that the PLC cannot discriminate between forward and reverse motion on the conveyor belt. If, for instance, the conveyor belt were ever reversed in direction, the sensor would continue to count objects that had already passed by before (in the forward direction) as those objects retreated on the belt. This would be a problem because the system would “think” more objects had passed along the belt (indicating greater production) than actually did.

One solution to this problem is to use an up/down counter, capable of both incrementing (counting up) and decrementing (counting down), and equip this counter with two light-beam sensors capable of determining direction of travel. If two light beams are oriented parallel to each other, closer than the width of the narrowest object passing along the conveyor belt, we will have enough information to determine direction of object travel:

$\displaystyle \includegraphics{plc_040.eps}$

This is called quadrature signal timing, because the two pulse waveforms are approximately 90$^{o}$ (one-quarter of a period) apart in phase. We can use these two phase-shifted signals to increment or decrement an up/down counter instruction, depending on which pulse leads and which pulse lags.

A Ladder Diagram PLC program designed to interpret the quadrature pulse signals is shown here, making use of negative-transition contacts as well as standard contacts:

$\displaystyle \includegraphics{plc_041.eps}$

The counter will increment (count up) when sensor B de-energizes only if sensor A is already in the de-energized state (i.e. light beam A breaks before B). The counter will decrement (count down) when sensor A de-energizes only if sensor B is already in the de-energized state (i.e. light beam B breaks before A).

Note that the up/down counter has both a “reset” (R) input and a “load” input (“LD”) to force the current value. Activating the reset input forces the counter's current value (CV) to zero, just as we saw with the “up” counter instruction. Activating the load input forces the counter's current value to the preset value (PV), just as we saw with the “down” counter instruction. In the case of an up/down counter, there are two Q outputs: a QU (output up) to indicate when the current value is equal to or greater than the preset value, and a QD (output down) to indicate when the current value is equal to or less than zero.

Note how the current value (CV) of each counter shown is associated with a tag name of its own, in this case parts_counted. The integer number of a counter's current value (CV) is a variable in the PLC's memory just like boolean values such as IN_sensor_A and IN_switch_reset, and may be associated with a tag name or symbolic address just the same1.17. This allows other instructions in a PLC program to read (and sometimes write!) values from and to that memory location.

Timers

A timer is a PLC instruction measuring the amount of time elapsed following an event. Timer instructions come in two basic types: on-delay timers and off-delay timers. Both “on-delay” and “off-delay” timer instructions have single inputs triggering the timed function.

An “on-delay” timer activates an output only when the input has been active for a minimum amount of time. Take for instance this PLC program, designed to sound an audio alarm siren prior to starting a conveyor belt. To start the conveyor belt motor, the operator must press and hold the “Start” pushbutton for 10 seconds, during which time the siren sounds, warning people to clear away from the conveyor belt that is about to start. Only after this 10-second start delay does the motor actually start (and latch “on”):

$\displaystyle \includegraphics{plc_043.eps}$

Similar to an “up” counter, the on-delay timer's elapsed time (ET) value increments once per second until the preset time (PT) is reached, at which time its output (Q) activates. In this program, the preset time value is 10 seconds, which means the Q output will not activate until the “Start” switch has been depressed for 10 seconds. The alarm siren output, which is not activated by the timer, energizes immediately when the “Start” pushbutton is pressed.

An important detail regarding this particular timer's operation is that it be non-retentive. This means the timer instruction should not retain its elapsed time value when the input is de-activated. Instead, the elapsed time value should reset back to zero every time the input de-activates. This ensures the timer resets itself when the operator releases the “Start” pushbutton. A retentive on-delay timer, by contrast, maintains its elapsed time value even when the input is de-activated. This makes it useful for keeping “running total” times for some event.

Most PLCs provide retentive and non-retentive versions of on-delay timer instructions, such that the programmer may choose the proper form of on-delay timer for any particular application. The IEC 61131-3 programming standard, however, addresses the issue of retentive versus non-retentive timers a bit differently. According to the IEC 61131-3 standard, a timer instruction may be specified with an additional enable input (EN) that causes the timer instruction to behave non-retentively when activated, and retentively when de-activated. The general concept of the enable (EN) input is that the instruction behaves “normally” so long as the enable input is active (in this case, non-retentive timing action is considered “normal” according to the IEC 61131-3 standard), but the instruction “freezes” all execution whenever the enable input de-activates. This “freezing” of operation has the effect of retaining the current time (CT) value even if the input signal de-activates.

For example, if we wished to add a retentive timer to our conveyor control system to record total run time for the conveyor motor, we could do so using an “enabled” IEC 61131-3 timer instruction like this:

$\displaystyle \includegraphics{plc_045.eps}$

When the motor's contactor bit (OUT_contactor) is active, the timer is enabled and allowed to time. However, when that bit de-activates (becomes “false”), the timer instruction as a whole is disabled, causing it to “freeze” and retain its current time (CT) value1.18. This allows the motor to be started and stopped, with the timer maintaining a tally of total motor run time.

If we wished to give the operator the ability to manually reset the total run time value to zero, we could hard-wire an additional switch to the PLC's discrete input card and add “reset” contacts to the program like this:

$\displaystyle \includegraphics{plc_044.eps}$

Whenever the “Reset” switch is pressed, the timer is enabled (EN) but the timing input (IN) is disabled, forcing the timer to (non-retentively) reset its current time (CT) value to zero.

The other major type of PLC timer instruction is the off-delay timer. This timer instruction differs from the on-delay type in that the timing function begins as soon as the instruction is de-activated, not when it is activated. An application for an off-delay timer is a cooling fan motor control for a large industrial engine. In this system, the PLC starts an electric cooling fan as soon as the engine is detected as rotating, and keeps that fan running for two minutes following the engine's shut-down to dissipate residual heat:

$\displaystyle \includegraphics{plc_046.eps}$

When the input (IN) to this timer instruction is activated, the output (Q) immediately activates (with no time delay at all) to turn on the cooling fan motor contactor. This provides the engine with cooling as soon as it begins to rotate (as detected by the speed switch connected to the PLC's discrete input). When the engine stops rotating, the speed switch returns to its normally-open position, de-activating the timer's input signal which starts the timing sequence. The Q output remains active while the timer counts from 0 seconds to 120 seconds. As soon as it reaches 120 seconds, the output de-activates (shutting off the cooling fan motor) and the elapsed time value remains at 120 seconds until the input re-activates, at which time it resets back to zero.

The following timing diagrams compare and contrast on-delay with off-delay timers:

$\displaystyle \includegraphics{plc_047.eps}$

While it is common to find on-delay PLC instructions offered in both retentive and non-retentive forms within the instruction sets of nearly every PLC manufacturer and model, it is almost unheard of to find retentive off-delay timer instructions. Typically, off-delay timers are non-retentive only1.19.

Data comparison instructions

As we have seen with counter and timers, some PLC instructions generate digital values other than simple Boolean (on/off) signals. Counters have current value (CV) registers and timers have elapsed time (ET) registers, both of which are typically integer number values. Many other PLC instructions are designed to receive and manipulate non-Boolean values such as these to perform useful control functions.

The IEC 61131-3 standard specifies a variety of data comparison instructions for comparing two non-Boolean values, and generating Boolean outputs. The basic comparative operations of “less than” ($<$), “greater than” ($>$), “less than or equal to” ($\leq$), “greater than or equal to” ($\geq$), “equal to” (=), and “not equal to” ($\neq$) may be found as a series of “box” instructions in the IEC standard:

$\displaystyle \includegraphics{plc_048.eps}$

The Q output for each instruction “box” activates whenever the evaluated comparison function is “true” and the enable input (EN) is active. If the enable input remains active but the comparison function is false, the Q output de-activates. If the enable input de-de-activates, the Q output retains its last state.

A practical application for a comparative function is something called alternating motor control, where the run-times of two redundant electric motors1.20 are monitored, with the PLC determining which motor to turn on next based on which motor has run the least:

$\displaystyle \includegraphics{plc_049.eps}$

In this program, two retentive on-delay timers keep track of each electric motor's total run time, storing the run time values in two registers in the PLC's memory: Motor_A_runtime and Motor_B_runtime. These two integer values are input to the “greater than” instruction box for comparison. If motor A has run longer than motor B, motor B will be the one enabled to start up next time the “start” switch is pressed. If motor A has run less time or the same amount of time as motor B (the scenario shown by the blue-highlighted status indications), motor A will be the one enabled to start. The two series-connected virtual contacts OUT_motor_A and OUT_motor_B ensure the comparison between motor run times is not made until both motors are stopped. If the comparison were continually made, a situation might arise where both motors would start if someone happened to press the Start pushbutton with one motor is already running.

Math instructions

The IEC 61131-3 standard specifies several dedicated ladder instructions for performing arithmetic calculations. Some of them are shown here:

$\displaystyle \includegraphics{plc_052.eps}$

As with the data comparison instructions, each of these math instructions must be enabled by an “energized” signal to the enable (EN) input. Input and output values are linked to each math instruction by tag name.

An example showing the use of such instructions is shown here, converting a temperature measurement in units of degrees Fahrenheit to units of degrees Celsius. In this particular case, the program inputs a temperature measurement of 138 $^{o}$F and calculates the equivalent temperature of 58.89 $^{o}$C:

$\displaystyle \includegraphics{plc_053.eps}$

Note how two separate math instructions were required to perform this simple calculation, as well as a dedicated variable (X) used to store the intermediate calculation between the subtraction and the division “boxes.”

Although not specified in the IEC 61131-3 standard, many programmable logic controllers support Ladder Diagram math instructions allowing the direct entry of arbitrary equations. Rockwell (Allen-Bradley) Logix5000 programming, for example, has the “Compute” (CPT) function, which allows any typed expression to be computed in a single instruction as opposed to using several dedicated math instructions such as “Add,” “Subtract,” etc. General-purpose math instructions dramatically shorten the length of a ladder program compared to the use of dedicated math instructions for any applications requiring non-trivial calculations.

For example, the same Fahrenheit-to-Celsius temperature conversion program implemented in Logix5000 programming only requires a single math instruction and no declarations of intermediate variables:

$\displaystyle \includegraphics{plc_054.eps}$

Sequencers

Many industrial processes require control actions to take place in certain, predefined sequences. Batch processes are perhaps the most striking example of this, where materials for making a batch must be loaded into the process vessels, parameters such as temperature and pressure controlled during the batch processing, and then discharge of the product monitored and controlled. Before the advent of reliable programmable logic devices, this form of sequenced control was usually managed by an electromechanical device known as a drum sequencer. This device worked on the principle of a rotating cylinder (drum) equipped with tabs to actuate switches as the drum rotated into certain positions. If the drum rotated at a constant speed (turned by a clock motor), those switches would actuate according to a timed schedule1.21.

The following photograph shows a drum sequencer with 30 switches. Numbered tabs on the circumference of the drum mark the drum's rotary position in one of 24 increments. With this number of switches and tabs, the drum can control up to thirty discrete (on/off) devices over a series of twenty-four sequenced steps:

$\displaystyle \includegraphics[width=16cm]{plc_050.eps}$

A typical application for a sequencer is to control a Clean In Place (CIP) system for a food processing vessel, where a process vessel must undergo a cleaning cycle to purge it of any biological matter between food processing cycles. The steps required to clean the vessel are well-defined and must always occur in the same sequence in order to ensure hygienic conditions. An example timing chart is shown here:

$\displaystyle \includegraphics{plc_051.eps}$

In this example, there are nine discrete outputs – one for each of the nine final control elements (pumps and valves) – and seventeen steps to the sequence, each one of them timed. In this particular sequence, the only input is the discrete signal to commence the CIP cycle. From the initiation of the CIP to its conclusion two and a half hours (150 minutes) later, the sequencer simply steps through the programmed routine.

Another practical application for a sequencer is to implement a Burner Management System (BMS), also called a flame safety system. Here, the sequencer manages the safe start-up of a combustion burner: beginning by “purging” the combustion chamber with fresh air to sweep out any residual fuel vapors, waiting for the command to light the fire, energizing a spark ignition system on command, and then continuously monitoring for presence of good flame and proper fuel supply pressure once the burner is lit.

In a general sense, the operation of a drum sequencer is that of a state machine: the output of the system depends on the condition of the machine's internal state (the drum position), not just the conditions of the input signals. Digital computers are very adept at implementing state functions, and so the general function of a drum sequencer should be (and is) easy to implement in a PLC. Other PLC functions we have seen (“latches” and timers in particular) are similar, in that the PLC's output at any given time is a function of both its present input condition(s) and its past input condition(s). Sequencing functions expand upon this concept to define a much larger number of possible states (“positions” of a “drum”), some of which may even be timed.

Unfortunately, despite the utility of drum sequence functions and their ease of implementation in digital form, there seems to be very little standardization between PLC manufacturers regarding sequencing instructions. Sadly, the IEC 61131-3 standard (at least at the time of this writing, in 2009) does not specifically define a sequencing function suitable for Ladder Diagram programming. PLC manufacturers are left to invent sequencing instructions of their own design. What follows here is an exploration of some different sequencer instructions offered by PLC manufacturers.

Koyo “drum” instructions

The drum instruction offered in Koyo PLCs is a model of simplicity itself. This instruction is practically self-explanatory, as shown in the following example:

$\displaystyle \includegraphics{plc_066.eps}$

The three-by-three grid of squares represent steps in the sequence and bit states for each step. Rows represent steps, while columns represent output bits written by the drum instruction. In this particular example, a three-step sequence proceeds at the command of a single input (X001), and the drum instruction's advance from one step to the next proceeds strictly on the basis of elapsed time (a time base orientation). When the input is active, the drum proceeds through its timed sequence. When the input is inactive, the drum halts wherever it left off, and resumes timing as soon as the input becomes active again.

Being based on time, each step in the drum instruction has a set time duration for completion. The first step in this particular example has a duration of 10 seconds, the second step 15 seconds, and the third step 18 seconds. At the first step, only output bit Y001 is set. In the second step, only output bit Y002 is set. In the third step, output bits Y002 and Y003 are set (1), while bit Y001 is reset (0). The colored versus uncolored boxes reveal which output bits are set and reset with each step. The current step number is held in memory register DS1, while the elapsed time (in seconds) is stored in timer register TD1. A “complete” bit is set at the conclusion of the three-step sequence.

Koyo drum instructions may be expanded to include more than three steps and more than three output bits, with each of those step times independently adjustable and each of the output bits arbitrarily assigned to any writable bit addresses in the PLC's memory.

This next example of a Koyo drum instruction shows how it may be set up to trigger on events rather than on elapsed times. This orientation is called an event base:

$\displaystyle \includegraphics{plc_067.eps}$

Here, a three-step sequence proceeds when enabled by a single input (X001), with the drum instruction's advance from one step to the next proceeding only as the different event condition bits become set. When the input is active, the drum proceeds through its sequence when each event condition is met. When the input is inactive, the drum halts wherever it left off regardless of the event bit states.

For example, during the first step (when only output bit Y001 is set), the drum instruction waits for the first condition input bit X002 to become set (1) before proceeding to step 2, with time being irrelevant. When this happens, the drum immediately advances to step 2 and waits for input bit X003 to be set, and so forth. If all three event conditions were met simultaneously (X002, X003, and X004 all set to 1), the drum would skip through all steps as fast as it could (one step per PLC program scan) with no appreciable time elapsed for each step. Conversely, the drum instruction will wait as long as it must for the right condition to be met before advancing, whether that event takes place in milliseconds or in days.

Allen-Bradley sequencer instructions

Rockwell (Allen-Bradley) PLCs use a more sophisticated set of instructions to implement sequences. The closest equivalent to Koyo's drum instruction is the Allen-Bradley SQO (Sequencer Output) instruction, shown here:

$\displaystyle \includegraphics{plc_068.eps}$

You will notice there are no colored squares inside the SQO instruction box to specify when certain bits are set or reset throughout the sequence, in contrast to the simplicity of the Koyo PLC's drum instruction. Instead, the Allen-Bradley SQO instruction is told to read a set of 16-bit words beginning at a location in the PLC's memory arbitrarily specified by the programmer, one word at a time. It steps to the next word in that set of words with each new position (step) value. This means Allen-Bradley sequencer instructions rely on the programmer already having pre-loaded an area of the PLC's memory with the necessary 1's and 0's defining the sequence. This makes the Allen-Bradley sequencer instruction more challenging for a human programmer to interpret because the bit states are not explicitly shown inside the SQO instruction box, but it also makes the sequencer far more flexible in that these bits are not fixed parameters of the SQO instruction and therefore may be dynamically altered as the PLC runs. With the Koyo drum instruction, the assigned output states are part of the instruction itself, and are therefore fixed once the program is downloaded to the PLC (i.e. they cannot be altered without editing and re-loading the PLC's program). With the Allen-Bradley, the on-or-off bit states for the sequence may be freely altered1.22 during run-time. This is a very useful feature in recipe-control applications, where the recipe is subject to change at the whim of production personnel, and they would rather not have to rely on a technician or an engineer to re-program the PLC for each new recipe.

The “Length” parameter tells the SQO instruction how many words will be read (i.e. how many steps are in the entire sequence). The sequencer advances to each new position when its enabling input transitions from inactive to active (from “false” to “true”), just like a count-up (CTU) instruction increments its accumulator value with each new false-to-true transition of the input. Here we see another important difference between the Allen-Bradley SQO instruction and the Koyo drum instruction: the Allen-Bradley instruction is fundamentally event-driven, and does not proceed on its own like the Koyo drum instruction is able to when configured for a time base.

Sequencer instructions in Allen-Bradley PLCs use a notation called indexed addressing to specify the locations in memory for the set of 16-bit words it will read. In the example shown above, we see the “File” parameter specified as #B3:0. The “#” symbol tells the instruction that this is a starting location in memory for the first 16-bit word, when the instruction's position value is zero. As the position value increments, the SQO instruction reads 16-bit words from successive addresses in the PLC's memory. If B3:0 is the word referenced at position 0, then B3:1 will be the memory address read at position 1, B3:2 will be the memory address read at position 2, etc. Thus, the “position” value causes the SQO instruction to “point” or “index” to successive memory locations.

The bits read from each indexed word in the sequence are compared against a static mask1.23 specifying which bits in the indexed word are relevant. At each position, only these bits are written to the destination address.

As with most other Allen-Bradley instructions, the sequencer requires the human programmer to declare a special area in memory reserved for the instruction's internal use. The “R6” file exists just for this purpose, each element in that file holding bit and integer values associated with a sequencer instruction (e.g. the “enable” and “done” bits, the array length, the current position, etc.).

To illustrate, let us examine a set of bits held in the B3 file of an Allen-Bradley SLC 500 PLC, showing how each row (element) of this data file would be read by an SQO instruction as it stepped through its positions:

$\displaystyle \includegraphics{plc_070.eps}$

The sequencer's position number is added to the file reference address as an offset. Thus, if the data file is specified in the SQO instruction box as #B3:0, then B3:1 will be the row of bits read when the sequencer's position value is 1, B3:2 will be the row of bits read when the position value is 2, and so on.

The mask value specified in the SQO instruction tells the instruction which bits out of each row will be copied to the destination address. A mask value of FFFFh (FFFF in hexadecimal format) means all 16 bits of each B3 word will be read and written to the destination. A mask value of 0001h means only the first (least-significant) bit will be read and written, with the rest being ignored.

Let's see what would happen with an SQO instruction having a mask value of 000Fh, starting from file index #B3:0, and writing to a destination that is output register O:0.0, given the bit array values in file B3 shown above:

$\displaystyle \includegraphics{plc_071.eps}$

When this SQO instruction is at position 2, it reads the bit values 0010 from B3:2 and writes only those four bits to O:0.0. The “X” symbols shown in the illustration mean that all the other bits in that output register are untouched – the SQO instruction does not write to those bits because they are “masked off” from being written. You may think of the mask's zero bits inhibiting source bits from being written to the destination word in the same sense that masking tape prevents paint from being applied to a surface.

The following Allen-Bradley SLC 500 PLC program shows how a pair of SQO instructions plus an on-delay timer instruction may be used to duplicate the exact same functionality as the “time base” Koyo drum instruction presented earlier:

$\displaystyle \includegraphics{plc_069.eps}$

The first SQO instruction reads bits in the B3 file array, sending only the three least-significant of them to the output register O:0.0 (as specified by the 0007h mask value). The second SQO instruction reads integer number values from elements of the N7 integer file and places them into the “preset” register of timer T4:0, so as to dynamically update the timer's preset value with each step of the sequence. The timer, in turn, counts off each of the time delays and then enables both sequencers to advance to the next position when the specified time has elapsed. Here we see a tremendous benefit of the SQO instruction's indexed memory addressing: the fact that the SQO instruction reads its bits from arbitrarily-specified memory addresses means we may use SQO instructions to sequence any type of data existing in the PLC's memory! We are not limited to turning on and off individual bits as we are with the Koyo drum instruction, but rather are free to index whole integer numbers, ASCII characters, or any other forms of binary data resident in the PLC's memory.

Data file windows appear on the computer screen showing the bit array held in the B3 file as well as the timer values held in the N7 file. In this live screenshot, we see both sequencer instructions at position 2, with the second SQO instruction having loaded a value of 15 seconds from register N7:2 to the timer's preset register T4:0.PRE.

Note how the enabling contact address for the second SQO instruction is the “enable” bit of the first instruction, ensuring both instructions are enabled simultaneously. This keeps the two separate sequencers synchronized (on the same step).

Event-based transitions may be implemented in Allen-Bradley PLCs using a complementary sequencing instruction called SQC (Sequencer Compare). The SQC instruction is set up very similar to the SQO instruction, with an indexed file reference address to read from, a reserved memory structure for internal use, a set length, and a position value. The purpose of the SQC instruction is to read a data register and compare it against another data register, setting a “found” (FD) bit if the two match. Thus, the SQC instruction is ideally suited for detecting when certain conditions have been met, and thus may be used to enable an SQO instruction to proceed to the next step in its sequence.

The following program example shows an Allen-Bradley MicroLogix 1100 PLC programmed with both an SQO and an SQC instruction:

$\displaystyle \includegraphics{plc_072.eps}$

The three-position SQO (Sequencer Output) instruction reads data from B3:1, B3:2, and B3:3, writing the four least-significant of those bits to output register O:0.0. The three-position SQC (Sequencer Compare) instruction reads data from B3:6, B3:7, and B3:8, comparing the four least-significant of those bits against input bits in register I:0.0. When the four input bit conditions match the selected bits in the B3 file, the SQC instruction's FD bit is set, causing both the SQO instruction and the SQC instruction to advance to the next step.

Lastly, Allen-Bradley PLCs offer a third sequencing instruction called Sequencer Load (SQL), which performs the opposite function as the Sequencer Output (SQO). An SQL instruction takes data from a designated source and writes it into an indexed register according to a position count value, rather than reading data from an indexed register and sending it to a designated destination as does the SQO instruction. SQL instructions are useful for reading data from a live process and storing it in different registers within the PLC's memory at different times, such as when a PLC is used for datalogging (recording process data).

PID regulator i PLS programmer

PID regulatoren i Codesys aktiveres ved å laste inn biblioteket Util som ligger under Application_Common_Util.

Dette er en enkel PID regulator som fungerer etter formelen.

$\displaystyle \ensuremath{Y=KP\cdot(e+\frac{1}{TN}\int edt+TV\frac{\delta e}{\delta t})+Y_{OFFSET}}
$

Her er et lite eksempel på en temperaturregulering med regulatoren. Prøv på din egen PC om du får dette til å virke.

For å gjøre regulatoren lett å ta i bruk har vi på Gand lagt inn en strukt som enkelt senere kan refereres til. En må da ha Gand funksjonsbiblioteket.

Variablene rundt regulatoren vil da se ut som i Figur.

Prøv å tilpass programmet du nettopp har laget til bruke denne strukten, og de tilhørende symbolene i HMI-en.

Structured Text (ST) programming

(Will be addressed in future versions of this book)

Instruction List (IL) programming

(Will be addressed in future versions of this book)

Function Block Diagram (FBD) programming

(Will be addressed in future versions of this book)

Sequential Function Chart (SFC) programmering

Mål for læringen er at eleven skal:

En sekvensiell styring betyr en rekke aktiviteter som skjer i en bestemt rekkefølge. Som eksempel på sekvensstyring kan vi ta for oss en vaskemaskin:

Sekvensen kan være slik:

For å beskrive en sekvens med symboler finnes det en internasjonal standard med betegnelsen ISO 61131-3. Denne beskriver både overgangene mellom aktivitetene og hva som skal skje i de ulike aktivitetstrinn og kalles Sekvensielt Funksjons Kart (SFC)

SFC ”språket” egner seg godt for overordnet styring.

Sekvensielt funksjonskart

For å beskrive en sekvensiel styring brukes et sekvensielt funksjonskart. Dette kan beskrive de sekvensielle sidene av et kontroll program.

SFC viser:

SFC elementer

SFC elementer brukes til å strukturere et sekvensprogram. Dette gjøres ved å beskrive styringssekvensen ved hjelp av:

Image SFC13

Vi kan dele en sekvensstyring i to deler:

  1. Sekvensdelen som bestemmer i hvilken rekkefølge sekvensen skal gå.
  2. Kontrolldelen som bestemmer hva som skal gjøres i hver del.

SFC Steg typer.

Det finnes to typer steg i SFC

Init steget er det steget som programmet vil stå i når det starter opp, eller der det vil gå til om en resetter sekvensen.

Init steget har følgende egenskaper:

Et steg har to tilhørende variabler som vi kan bruke til å monitorere og synkronisere sekvensen.

For at disse variablene skal være tilgjengeligge må vi bruke IEC steg. Det hender at dette ikke stemmer, vi kan da tvinge et steg til å være IEC ved å legge steget inn som følgende variabel i POU-en .

VAR

        Stegnavn: SFCSTEPTYPE;

END_VAR

Eksempel: Dette programmet vil stå i INIT til INIT.t er blitt større en 5s, da vil overgangsbetingelsen være TRUE og programmet gå videre til STEP. Image SFC14

SFC transition

Det som avgjør når en går fra et steg til et annet er overgangbetingelser (transitions). For å gå til neste steg må overgangsbetingelsen være TRUE.

Betingelser for transition:

I Codesys har vi to typer tranitions: Eksempel

I dette programmer står nå i steget Yellow1 og venter på overgangsbetingelsen YellowDone. Men dette er ikke en vanlig overgangsbetingelse. Det kan en se på firkantet over overgangs betingelse. Denne har et grønt hjørne. Dette hjørnet markerer at det er et eksternt program som kjøres. Når variablen YellowDone blir TRUE i dette programmet er også overgangsbetingelsen aktiv og vi går videre til neste steg Red1. Image SFCTransitioneksempel

En ser at transitions programmet YellowDone består av en linje: YellowDone := Yellow1.t > t#3s Det vil si at overgangsbetingelsen vil være TRUE når timeren Yellow1.t er større en 3s.

SFC Actions

Actions brukes til å bestemme hva som skal skje i hvert trinn. En action kan være en variabel som settes TRUE eller det kan være et eget program som kjøres. Image SFC15

Egenskaper ved actions

Action Qualifiers according to IEC 61131-3          
Qualifier Betydning Forklaring          
N Non-stored Actionen er aktiv så lenge steget er aktivt.          
R0 overriding Reset Actinen blir deaktivert          
S0 Set (Stored) Actionen blir aktiv og forblir aktiv til den resettes med R0. Den vilforble aktiv selv om sekvensen går over til et nytt trinn          
L time Limited Actionen blir aktiv med en gang og er aktiv til sekvensen går til neste trinn, eller til gitt tid er gått          
D time Delayed Actionen blir aktiv          
P Pulse Utfører actionen to ganger en gang når steget aktiveres og en gang når det deaktiveres.          
SD Stored and time Delayed Actionen aktiveres etter gitt tid er gått, og vil være aktiv til den resettes.          
DS Delayed and Stored Actionen aktiveres etter gitt tid er gått, men bare om trinnet fortsatt er aktivt. Den vil være aktiv til den resettes.          
SL Stored and time Limited Actionen aktiveres så snart trinnet er aktivt, og vil være aktivt til gitt tid er gått eller den resettes.          
Eksempel Her er det eksempel på SFC sine store styrker. En prosess har blitt stående fast i steget Speed2.

Hva er galt?

Image SFC_stoppet_maskin
Hastighen holdes ikke konstant. SFC gir over oversikt over hvor programmet er og hva det venter på. Dette letter feilsøking på maskiner som bruker SFC.

Oppgave til elever


Image SFC_EnkeltTrefikkLys
Eksempel
Kombinering av språk ved hjelp av actionblokker

Image SFC_KombinasjonavSpråk
Dette er et eksempel på hvordan actions kan være programmer og at en står fritt til å velge hvilket program en ønsker å programere det i.

Alternative og parallelle sekvenser.

I SFC kan vi ha en linær sekvens der alle stegene kommer etterhverandre og til slutt og oppe til starten igjen.

Vi kan også ha alternative og parallelle sekvenser. I alternative vil et seg etterfølges av to eller flere transitions, det bare en vei kan velges. Mens i parallelle vil en transittion etterfølges av to eller flere steg.

Eksempel på sekvensstyring:

Funksjonstabell for lysanlegget

Human-Machine Interfaces

Programmable logic controllers are built to input various signal types (discrete, analog), execute control algorithms on those signals, and then output signals in response to control processes. By itself, a PLC generally lacks the capability of displaying those signal values and algorithm variables to human operators. A technician or engineer with access to a personal computer and the requisite software for editing the PLC's program may connect to the PLC and view the program's status “online” to monitor signal values and variable states, but this is not a practical way for operations personnel to monitor what the PLC is doing on a regular basis. In order for operators to monitor and adjust parameters inside the PLC's memory, we need a different sort of interface allowing certain variables to be read and written without compromising the integrity of the PLC by exposing too much information or allowing any unqualified person to alter the program itself.

One solution to this problem is a dedicated computer display programmed to provide selective access to certain variable's in the PLC's memory, generally referred to as Human1.24-Machine Interface, or HMI.

HMIs may take the form of general-purpose (“personal”) computers running special graphic software to interface with a PLC, or as special-purpose computers designed to be mounted in sheet metal panel fronts to perform no task but the operator-PLC interface. This first photograph shows an example of an ordinary personal computer (PC) with HMI software running on it:

$\displaystyle \includegraphics[width=3in]{hmi_01.eps}$

The display shown here happens to be for monitoring a vacuum swing adsorption (VSA) process for purifying oxygen extracted from ambient air. Somewhere, a PLC (or collection of PLCs) is monitoring and controlling this VSA process, with the HMI software acting as a “window” into the PLC's memory to display pertinent variables in an easy-to-interpret form for operations personnel. The personal computer running this HMI software connects to the PLC(s) via digital network cables such as Ethernet.

This next photograph shows an example of a special-purpose HMI panel designed and built expressly to be used in industrial operating environments:

$\displaystyle \includegraphics[width=4in]{hmi_02.eps}$

These HMI panels are really nothing more than “hardened” personal computers built ruggedly and in a compact format to facilitate their use in industrial environments. Most industrial HMI panels come equipped with touch-sensitive screens, allowing operators to press their fingertips on displayed objects to change screens, view details on portions of the process, etc.

$\displaystyle \includegraphics{plc_076.eps}$

Technicians and/or engineers program HMI displays to read and write data via a digital network to one or more PLCs. Graphical objects arrayed on the display screen of an HMI often mimic real-world indicators and switches, in order to provide a familiar interface for operations personnel. A “pushbutton” object on the face of an HMI panel, for example, would be configured to write one bit of data to the PLC, in a manner similar to a real-world switch writing one bit of data to the PLC's input register.

Modern HMI panels and software are almost exclusively tag-based, with each graphic object on the screen associated with at least one data tag name, which in turn is associated to data points (bits, or words) in the PLC by way of a tag name database file resident in the HMI. Graphic objects on the HMI screen either accept (read) data from the PLC to present useful information to the operator, send (write) data to the PLC from operator input, or both. The task of programming an HMI unit consists of building a tag name database and then drawing screens to illustrate the process to as good a level of detail as operators will need to run it.

An example screenshot of a tag name database table for a modern HMI is shown here:

$\displaystyle \includegraphics[width=6in]{digital_72.eps}$

The tag name database is accessed and edited using the same software to create graphic images in the HMI. In this particular example you can see several tag names (e.g. START_PUSHBUTTON, MOTOR_RUN_TIMER, ERROR_MESSAGE, MOTOR_SPEED) associated with data points within the PLC's memory (in this example, the PLC addresses are shown in Modbus register format). In many cases the tag name editor will be able to display corresponding PLC memory points in the same manner as they appear in the PLC programming editor software (e.g. I:5/10, SM0.4, C11, etc.).

An important detail to note in this tag name database display is the read/write attributes of each tag. Note in particular how four of the tags shown are read-only: this means the HMI only has permission to read the values of those four tags from the PLC's memory, and not to write (alter) those values. The reason for this in the case of these four tags is that those tags refer to PLC input data points. The START_PUSHBUTTON tag, for instance, refers to a discrete input in the PLC energized by a real pushbutton switch. As such, this data point gets its state from the energization of the discrete input terminal. If the HMI were to be given write permission for this data point, there would likely be a conflict. Suppose input terminal on the PLC were energized (setting the START_PUSHBUTTON bit to a “1” state) and the HMI simultaneously attempted to write a “0” state to the same tag. One of these two data sources would win, and other would lose, possibly resulting in unexpected behavior from the PLC program. For this reason, data points in the PLC linked to real-world inputs should always be limited as “read-only” permission in the HMI's database, so the HMI cannot possibly generate a conflict.

The potential for data conflict also exists for some of the other points in the database, however. A good example of this is the MOTOR_RUN bit, which is the bit within the PLC program telling the real-world motor to run. Presumably, this bit gets its data from a coil in the PLC's Ladder Diagram program. However, since it also appears in the HMI database with read/write permission, the potential exists for the HMI to over-write (i.e. conflict) that same bit in the PLC's memory. Suppose someone programmed a toggling “pushbutton” screen object in the HMI linked to this tag: pushing this virtual “button” on the HMI screen would attempt to set the bit (1), and pushing it again would attempt to reset the bit (0). If this same bit is being written to by a coil in the PLC's program, however, there exists the distinct possibility that the HMI's “pushbutton” object and the PLC's coil will conflict, one trying to tell the bit to be a “0” while the other tries to tell that bit to be a “1”. This situation is quite similar to the problem experienced when multiple coils in a Ladder Diagram program are addressed to the same bit.

The general rule to follow here is never allow more than one element to write to any data point. In my experience teaching PLC and HMI programming, this is one of the more common errors students make when first learning to program HMIs: they will try to have both the HMI and the PLC writing to the same memory locations, with weird results.

One of the lessons you will learn when programming large, complex systems is that it is very beneficial to define all the necessary tag names before beginning to lay out graphics in an HMI. The same goes for PLC programming: it makes the whole project go faster with less confusion if you take the time to define all the necessary I/O points (and tag names, if the PLC programming software supports tag names in the programming environment) before you begin to create any code specifying how those inputs and outputs will relate to each other.

Maintaining a consistent convention for tag names is important, too. For example, you may wish to begin the tag name of every hard-wired I/O point as either INPUT or OUTPUT (e.g. INPUT_PRESSURE_SWITCH_HIGH, OUTPUT_SHAKER_MOTOR_RUN, etc.). The reason for maintaining a strict naming convention is not obvious at first, since the whole point of tag names is to give the programmer the freedom to assign arbitrary names to data points in the system. However, you will find that most tag name editors list the tags in alphabetical order, which means a naming convention organized in this way will present all the input tags contiguously (adjacent) in the list, all the output tags contiguously in the list, and so on.

Another way to leverage the alphabetical listing of tag names to your advantage is to begin each tag name with a word describing its association to a major piece of equipment. Take for instance this example of a process with several data points defined in a PLC control system and displayed in an HMI:

$\displaystyle \includegraphics{hmi_03.eps}$

If we list all these tags in alphabetical order, the association is immediately obvious:

As you can see from this tag name list, all the tags directly associated with the heat exchanger are located in one contiguous group, and all the tags directly associated with the reactor are located in the next contiguous group. In this way, judicious naming of tags serves to group them in hierarchical fashion, making them easy for the programmer to locate at any future time in the tag name database.

You will note that all the tag names shown here lack space characters between words (e.g. instead of “Reactor bed temp”, a tag name should use hyphens or underscore marks as spacing characters: “Reactor_bed_temp”), since spaces are generally assumed by computer programming languages to be delimiters (separators between different variable names).

Like programmable logic controllers themselves, the capabilities of HMIs have been steadily increasing while their price decreases. Modern HMIs support graphic trending, data archival, advanced alarming, and even web server ability allowing other computers to easily access certain data over wide-area networks. The ability of HMIs to log data over long periods of time relieves the PLC of having to do this task, which is very memory-intensive. This way, the PLC merely “serves” current data to the HMI, and the HMI is able to keep a record of current and past data using its vastly larger memory reserves1.25.

Some modern HMI panels even have a PLC built inside the unit, providing control and monitoring in the same device. Such panels provide terminal strip connection points for discrete and even analog I/O, allowing all control and interface functions to be located in a single panel-mount unit.

How to teach yourself PLC programming

First and foremost, you need to get your very own PLC to work with. Computer programming of any kind is not a spectator sport, and can only be learned by significant investment of time and effort at the keyboard. In many ways, learning to program is like learning a new spoken or written language: there is new vocabulary and new grammatical rules to master, and many ways to make mistakes.

Fortunately, many low-cost PLCs exist on the market for individuals to purchase. My own personal favorites are the “CLICK” PLC models manufactured by Koyo and marketed through Automation Direct, and also the Allen-Bradley MicroLogix series of PLC (especially the 1000 and 1100 models).

The first document you should read once you get your PLC is something called a Getting Started guide. Every PLC manufacturer publishes a document with this name (or something similar such as Quick Start or Getting Results). This manual will step you through all the basic procedures for entering a simple program into your PLC and getting it to run. It is generally far easier to learn programming by copying and adapting a worked example than it is to start from a “blank page” on your own, just as it is easiest to learn a spoken or written language by practicing sentences spoken in that language by other people before constructing your own sentences from scratch.

In order to work with your PLC, you will need a convenient way to simulate different input conditions coming from discrete (switch) devices. Any set of hand-operated switches will do, my recommendation being household light switches (very inexpensive and rugged). Attaching an array of these switches to a wooden board along with the PLC and interconnecting terminal blocks forms what is often called a PLC trainer. The following photograph shows one such trainer1.26, using an Allen-Bradley MicroLogix 1000 PLC:

$\displaystyle \includegraphics[width=16cm]{plc_060.eps}$

Another example of a student-built PLC trainer is this unit, housed inside of an attaché case. Not only does this trainer contain an Allen-Bradley MicroLogix 1100 PLC along with input switches and output indicator lights, but it also includes an HMI touch-screen panel on a fold-down bracket:

$\displaystyle \includegraphics[width=16cm]{plc_077.eps}$

The educational value of building your own PLC trainer is difficult to overstate when learning about PLCs. Learning how to build properly-functioning I/O circuits is every bit as important to a working technician as learning how to develop PLC programs. Additionally, the experience gained in general wiring layout and fabrication are valuable skills for any instrumentation practitioner.

Once you have learned the basic steps for entering, running, and saving a PLC program, you are ready to begin building your knowledge of the language's vocabulary and grammar. In computer programming (of all types), there are different functions of the language one must become familiar with in order to do useful tasks. A great way to learn how to use these functions is to create your own “demonstration” programs illustrating the use of each function.

For example, if you open up the pages of almost any computer programming book, somewhere near the beginning you will find a demonstration program called “Hello World!” The purpose of a “Hello World!” program is to do nothing more than display the words Hello World! on the computer screen. It is an entirely useless program to run, but it is highly useful for gaining teaching the programmer the basics of program construction and text message functionality.

By the same token, you may learn the basics of each programming function by writing simple “Hello World”-type programs illustrating each one of those functions. These demonstration programs will not serve any useful purpose (other than to help you learn), and should be kept as simple as possible in order to minimize confusion.

For example, every PLC provides instructions to perform the following tasks:

Just as every spoken or written language has verbs, nouns, adjectives, and adverbs to describe actions and things, every PLC programming language has specific functions to perform useful tasks. The details of how to perform each function will vary somewhat between PLC manufacturers and models, but the overall functions are quite similar. The reference manuals provided for your PLC will describe in detail how to use each function. Your task is to write simple demonstration programs for each function, allowing you to directly explore how each function works, and to gain an understanding of each function by observing its behavior and also by making (inevitable) mistakes.

After writing each demonstration program, you should add a lot of comments to it, so you will be able to understand what you did later when you go back to your demonstration program for reference. These comments should cover the following points:

Years ago when I was teaching myself how to program using the C language, I wrote a set of “tutorial” programs demonstrating common programming functions and techniques. The following is a partial list of these tutorial programs, which I still keep to this day:

Each one of these tutorial programs is heavily commented, to explain to myself in my own words how they work and what they are doing. Not only did they help me learn how to write programs in C, but they also serve as a handy reference for me any time in the future I need to refresh my knowledge. The act of writing tutorial programs is akin to journaling as a way to work through complex problems in life – in a way, it is like having a conversation with yourself.

Review of fundamental principles

Shown here is a partial listing of principles applied in the subject matter of this chapter, given for the purpose of expanding the reader's view of this chapter's concepts and of their general inter-relationships with concepts elsewhere in the book. Your abilities as a problem-solver and as a life-long learner will be greatly enhanced by mastering the applications of these principles to a wide variety of topics, the more varied the better.

References

“1758 PLC-5 Programmable Controllers Addressing Reference Manual”, Publication 5000-6.4.4, Allen-Bradley Company, Inc., Milwaukee, WI, 1995.

“Allen-Bradley I/O Modules Wiring Diagrams”, Publication CIG-WD001A-EN-P, Rockwell Automation, Inc., Milwaukee, WI, 2005.

IEC 61131-3, “International Standard, Programmable Controllers – Part 3: Programming Languages”, Edition 2.0, International Electrotechnical Commission, Geneva, Switzerland, 2003.

“Logix5000 Controllers I/O and Tag Data”, Publication 1756-PM004B-EN-P, Rockwell Automation, Inc., Milwaukee, WI, 2008.

“Programming with STEP 7”, Siemens AG, Nürnberg, Germany, 2006.

“S7-200 Programmable Controller System Manual”, Order Number 6ES7298-8FA24-8BH0, Edition 09/2007, Siemens AG, Nürnberg, Germany, 2007.

“SLC 500 Family of Programmable Controllers Addressing Reference Manual”, Publication 5000-6.4.23, Allen-Bradley Company, Inc., Milwaukee, WI, 1995.

“SLC 500 Modular Hardware Style User Manual”, Publication 1747-UM011E-EN-P, Rockwell Automation, Inc., Milwaukee, WI, 2004.

]