Usein kysyttyä

PLC on lyhenne sanoista Programmable Logic Controller. Se on kontrolleri, joka toimii ikään kuin koneen aivoina: se tekee ylemmän tason päätöksiä ja ohjaa tuotantolaitteen toimintoja.

Teollisuudessa PLC:t huolehtivat esimerkiksi liikkeenohjauksesta ja prosessien valvonnasta. Yksi PLC voi toimia koko järjestelmän keskuskontrollerina, ja sen alaisuudessa voi olla useita muita PLC:itä. PLC-kontrollereita voidaan hyödyntää lähes missä tahansa teollisuuden ohjelmointitarpeessa.

Ei mitään ja kaikki! Perusajatus on sama: ohjelmoidaan koneita ja prosesseja ohjaava logiikka. Erot ovat enemmänkin pintapuolisia. Useimmiten valmistajilla on omat ohjelmointityökalunsa, joiden käyttöliittymä sekä ohjelmointikielten syntaksi (eli se, miten komennot pitää kirjoittaa, jotta kone ne ymmärtäisi) tapaavat poiketa toisistaan.



Kun peruslogiikan ymmärtää, valmistajan vaihto on yleensä vain uuden työkalun opettelua.

Teknisesti yleensä kyllä, mutta käytännössä se harvemmin kannattaa. Ongelmana on, että vanhat ohjelmat eivät yleensä istu nätisti uusittavan projektin vaatimuksiin.



Käytetään esimerkkinä vaikka vanhaa tuotantolaitosta, jossa ei haluta vaihtaa varsinaista konetta, mutta sen ohjelma alkaa olla tiensä päässä. Jos ohjelma siirretään sellaisenaan, peritään samalla kaikki, mitä laitteen elinkaaren aikana on korjailtu ja muuteltu tai poistettu käytöstä. Usein jopa turhia koodin pätkiä. Ja mikäli matkan varrella ilmenee tarpeita lisätä nykypäivän vaatimuksia, vanha koodi ei yleensä siihen kovin siististi taivu – ja se kasvattaa lisäksi hintalappua.

Puhtaalta pöydältä aloittaminen on pitkässä juoksussa myös se kaikkein kustannustehokkain vaihtoehto.

On siis kaikkien etu, ettei yritetä käyttää vanhaa ohjelmaa, vaan selvitetään, mitä toiminnoilta halutaan ja luodaan uusi nykystandardien mukaan. Kuvaus tai video laitteesta käynnissä kertoo vanhan (ja todennäköisesti vanhentuneen) koodin sijaan nopeasti, mitä meidän pitää saada aikaan.

Tämä on täysin tapauskohtaista. Mitä tarkemmin tavoitteet ja tarpeet saadaan tunnistettua ja määriteltyä heti alussa, sitä realistisempi aikataulu saadaan.



Matkan varrella tulee luonnollisesti yleensä kaikenlaisia oivalluksia ja lisäyksiä: paras lähtökohta onkin tehdä kunnollinen etukäteisarvio, mutta jättää suunnitelmaan joustoa muutoksille.

Tämä on melkoisen laaja kysymys, joka kuuluu enemmän varsinaisen konerakentamisen puolelle.



Esimerkiksi fyysisesti voi olla puristumisvaaraa, ja sen turvallisuusmäärittelyä ohjaa konedirektiivi. Nykyaikaisissa koneissa on kahdennetut turvapiirit ja turvalogiikat, ja ne toimivat erillään varsinaisesta tuotanto-ohjelmasta. Näihin piireihin kytketään esimerkiksi ovien turvakytkimet ja hätäpysäyttimet. Kun ovi avataan tai turvalaite aktivoituu, kone saatetaan turvalliseen tilaan asettamalla turvapaineet tai katkaisemalla ohjausjännitteet ja paineilma kokonaan.

Virheenkäsittely puolestaan tarkoittaa sitä, että ohjelma tunnistaa poikkeustilanteet ja reagoi niihin määritellyllä tavalla, esimerkiksi hälyttämällä ja/tai pysäyttämällä prosessit. Hyvällä suunnittelulla ja järjestelmällisellä lähestymisellä saadaan myös ohjelma toipumaan poikkeustilanteista oikein – riippumatta siitä mitä ja missä järjestyksessä käyttäjä laitteen ääressä tekee. Ohjelmanhan ei pidä edes sallia käyttäjän suorittavan vääriä toimenpiteitä.

PLC-ohjelmoinnissa käytetään useita erikoistuneita kieliä, joista suurin osa perustuu IEC 61131-3 -standardiin. Näitä kolmea käytämme yleisimmin.

 

Ladder Diagram (LD)

Tunnetaan myös "tikaslogiikkana". Tämä graafinen kieli kehitettiin aikanaan niin, että mm. sähköasentajien ja automaatioinsinöörien oli helppo ymmärtää sen rakenne, koska se muistuttaa sähköpiirikaavioita. Sopii erityisen hyvin relelogiikan ja ohjausten toteutukseen. Vaikkapa Omronilla LD on yleinen.

Function Block Diagram (FBD)

Toinen graafinen kieli, jossa ohjelma rakentuu toiminnoista kertovista lohkoista. Soveltuu hyvin prosessiohjaukseen ja PID-säätöön (PID-säädöllä ohjataan tiettyä prosessia, esimerkiksi uunin lämpötilaa, pysymään halutussa arvossa). FBD on käytössä esimerkiksi Siemensillä. 

Structured Text (ST)

Tekstipohjainen, perinteisiä ohjelmointikieliä muistuttava kieli. ST on hyvin samankaltainen eri valmistajilla, joten kun kirjoitamme sitä ns. function blockien sisään, voimme kopioida kyseisen koodin helposti suoraan toisen valmistajan ohjemointiympäristöön. Tämä säästää valtavasti aikaa ja näin ollen kustannuksia.

Hirveän monella tavalla! Puhdas IT-puoli ja teollisuusautomaatio kulkevat koko ajan enemmän limittäin.

Yleisiä ovat EtherCATin ja Profinetin kaltaiset teollisuusväylät sekä vanhemmista järjestelmistä tuttu Profibus. Lisäksi yhteys voi olla kovajohdotettu, eli suoraan inputien ja outputien kautta kulkevilla signaaleilla tai jänniteviesteillä toteutettu liitäntä.



Nykyään käytetään paljon myös Ethernetin yli toimivia teollisuusprotokollia (esim. OPC UA) ja yleisiä IP-pohjaisia ratkaisuja laitteiden välillä. Ennen tarvittiin usein erillisiä väliohjelmistoja tai PC-yhteyksiä, mutta nykyiset PLC:t voivat tallentaa ja lukea tietoa suoraan esimerkiksi tietokannoista.

Tähänkin pätee sama vastaus kuin kysymykseen valmistajien välisistä eroista: ei mitenkään – ja samalla kaikin tavoin! 



Ominaista on, että käytetään jo mainittua Ladderia, jota ei juuri muualla näe. Muiden ohjelmointikielten tavoin myös PLC-kielet eroavat toisistaan syntaksin ja esitystavan osalta, mutta kun osaa ajatella, miten laitteenohjaus kannattaa rakentaa tehokkaasti ja järjestelmällisesti, voi soveltaa taitojaan melkein missä tahansa ohjelmointiympäristössä.

Tätä meiltä kysytään usein!



Valmistajakohtaiset pienet erot oppii nopeasti, kun perusymmärrys laitteen toiminnasta ja ohjelmoinnista on hallussa. Tärkeintä on osaaminen itse logiikan ja prosessin rakentamisessa eikä niinkään se, onko juuri tietyn valmistajan parissa tullut työskenneltyä aiemmin.

Eri valmistajilla on omat ohjelmointikäskynsä ja toimintatapansa, mutta jälleen palaamme siihen, että perusajatus on sama kuin muussakin ohjelmoinnissa: luodaan ohjelma, jota laite suorittaa.

Robottiohjelmoinnin erikoisuus on kuitenkin se, että teollisuusrobotin täytyy hallita liikkeitään kolmiulotteisessa avaruudessa. Meidän ohjelmoijien pitää siis ymmärtää koordinaatistoa ja matematiikkaa, koska robotti laskee jatkuvasti, missä asennossa tai kohdassa tilaa se on ja mihin pitää seuraavaksi liikkua.

Ohjelma myös suoritetaan hieman eri tavalla eli jo hiukan etukäteen, jotta kontrollerilla on aikaa laskea robon liikkeet. Esimerkiksi kuusiakselinen robotti ohjaa kuutta servomoottoria samanaikaisesti. Jokaisen moottorin liike vaikuttaa kokonaisuuteen, ja yhteisvaikutuksesta syntyy robotin tarkka liikerata. Yksinkertaiseltakin vaikuttavan liikkeen takana on aivan valtava laskentamäärä!

Ei kovin suoraan, koska valmistajilla on omat ohjelmointiympäristönsä. Parasta on hyödyntää aiempaa kokemusta ja ajattelumallia, sillä se, miten prosessi kannattaa rakentaa, pätee merkistä riippumatta. Varsinainen ohjelma tehdään kuitenkin aina ko. valmistajan omassa ympäristössä

Useimmilla robottivalmistajilla on tähän omat ohjelmointityökalunsa tai maksullisia lisäosia.

Esimerkiksi KUKA:n työkalulla voidaan määrittää virtuaaliset rajat robolle siihen avaruuteen, jossa se hyörii. Vaikka ohjelma antaisi robotille käskyn liikkua "kieltoalueelle", se pysähtyy rajan kohdalle eikä ylitä sitä.

Oleellinen turvatoiminto on myös törmäystunnistus. Eri valmistajilla on eri tapoja toteuttaa se, mutta lähes kaikilla se liittyy servoakselien virta-arvoihin, joita robo seuraa. Kun raja-arvot ylittyvät, voidaan joillakin valmistajilla ohjelmaan rakentaa oma protokolla törmäksen jälkeen. "Tilttiin" menemisen sijaan alkaakin keskeytysohjelma: robotti esimerkiksi pysähtyy, palaa takaisin ja lähettää tiedon PLC:lle.



Ihmisten kanssa toimivissa yhteistyöroboteissa ei välttämättä tarvita suojarakenteita. Niiden liikkeista tehdään lähtökohtaisesti paljon hitaampia, jotta mahdollinen törmäystilanne on ihmiselle vaaraton. Hidas vauhti vaikuttaa tuottavuuteen, mutta jos prosessissa ei ole kiirettä, ei se ole ongelma.

Ensin ohjelma on saatava rullaamaan. Sen jälkeen... tuijotamme! Seuraamme robotin sykliä, ja havainnoinnin perusteella aletaan hienosäätää liikenopeuksia ja kiihtyvyyksiä.



Optimoinnilla saadaan karsittua turhat vaiheet pois ja hiottua prosessista mahdollisimman sujuva. Jos robotti esimerkiksi odottaa pitkään jonkin muun laitteen suoritusta, sen ei kannata ajaa sata lasissa odottelemaan, vaan hitaampi vauhti riittää. 

Robottivalmistajalla on omat kielensä, joiden syntaksit tosin muistuttavat toisiaan. Esimerkiksi KUKA käyttää KRL:ää, joka on monella tapaa samankaltainen kuin PLC:ssä käytetty Structured Text. Se on helppo omaksua, vaikka siinä on valmistajalle tyypillisiä nyansseja. Yasakawan roboteissa kieli on taas täysin omanlaisensa.



Kun ymmärtää robottiohjelmoinnin perusperiaatteet, uusi kielikin on helppo oppia.

Kuten jo aiemmin totesimme, se on muuten melko samantyyppistä kuin muukin ohjelmointi, mutta liikkumista ja koordinaatiston käyttöä ei juuri muissa kielissä ole. 



Yleisiä liikekäskyjä roboteille ovat mm.

• joint-liike, jossa robotti laskee itse akseliensa asemat, kunhan se päätyy siihen, että työkalu on halutussa pisteessä ja asennossa. Tätä käytetään paljon vapaassa tilassa, sillä ohjelmoija ei sitä juuri pysty etukäteen määrittelemään: eli käsky on sama, mutta robotti laskee itse, miten siihen pisteeseen optimaalisimmin pääsee. 
• lineaariliike: robon täytyy pyrkiä pitämään työkalupisteensä täysin oikeassa kulmassa suoraa janaa liikuttaessa, esimerkiksi kun tarttuja täytyy pitää kohtisuorassa. 
• ympyräliike eli liike kaarella tai ympyrän muotoisella radalla. 

Lisäksi robottiohjelmoinnissa hyödynnetään paljon koordinaatistojen laskentaa. Esimerkiksi kun robotti laittaa laatikoita lavalle, ei joka laatikon paikkaa opeteta erikseen. Sen sijaan määritellään koordinaatisto ja lasketaan siirtymät X-, Y- ja Z-suunnissa, jolloin robotti ajaa laskettuihin pisteisiin.

Robotti juttelee muille joko teollisuusväylän tai kovajohdotetun I/O:n avulla. Väyläratkaisulla voidaan siirtää muutakin kuin “nollia ja ykkösiä”, eli vaikkapa haettavan kappaleen koordinaatit ja orientaatio konenäköjärjestelmältä.

Aika usein kysytään, olemmeko tehneet juuri tietyn valmistajan roboteilla töitä. Merkin vaihtuminen ei nollaa osaamista: kun hallitsee robottien ja automaation perusperiaatteet, uutta on lähinnä, miten juuri tämä valmistaja toteuttaa komennot ja asetukset.

Alkuun huomiona, että Tricycle Software vastaa automaatioprojekteissa nimenomaan ohjelmoinnista ja ohjelmistokehityksestä, joten vastaamme kysymykseen lähinnä siitä näkökulmasta.

Projekti alkaa mahdollisimman kattavalla kartoituksella. Tavoitteena on varmistaa, ettei toimittajalla ja tilaajalla ole eri käsitystä siitä, mitä ollaan tekemässä. Suurin osa automaatioprojektien sudenkuopista syntyy juuri väärinymmärryksistä ja siitä, ettei esimerkiksi todellisia kustannuksia ole huomioitu kartoitusvaiheessa.

Kartoitusvaiheessa pyritään käymään mahdollisimman tarkasti läpi, mitä järjestelmän on tarkoitus tehdä ja millaisissa tilanteissa sitä käytetään. Mitä paremmin tilaaja pystyy avaamaan todellisia käyttötilanteita, sitä paremmin kokonaisuus voidaan suunnitella. Tässä vaiheessa mitään ei kannata pitää itsestään selvänä!

Kun projektin suunta on selvä, ohjelmointityö alkaa. Projektin aikana pidetään sopivin välein (mieluummin useammin kuin harvemmin; sitä parempi lopputulos) katselmointeja, joissa käydään läpi mitä on tehty ja miten toteutus etenee. 

Kun järjestelmä tai kone alkaa olla toiminnassa, seuraava tärkeä vaihe on käyttäjätestaus. On tärkeää, että juuri ne henkilöt, jotka tulevat käyttämään konetta, pääsevät testaamaan sitä. Ohjelmistokehittäjä ei itse ole koskaan paras testaaja, koska hän on ajatellut laitetta käytettävän tietyllä tavalla. Joku toinen saattaa yllättää aivan toisenlaisella ajattelumallilla.

Testit pyritään tekemään niin, ettei käyttäjille kerrota liikaa järjestelmän toiminnasta etukäteen. Näin nähdään paremmin, kuinka intuitiivinen käyttöliittymä oikeasti on ilman erillistä perehdytystä. Testien perusteella järjestelmää voidaan vielä muokata niin, ettei “vääränlainen” käyttö ole edes mahdollisia.



Ennen laitteen siirtämistä tilaajan tuotantotiloihin sen on läpäistävä FAT, Factory Acceptance Test. Sitä ennen teemme epävirallisempia testejä, jotta saadaan selville, mitä tilaaja on oikeasti vailla. SAT eli lopullinen hyväksyntä tapahtuu asiakkaan tuotantotiloissa käyttöönottovaiheessa.

Automaatio poistaa raskaita ja yksitoikkoisia työtehtäviä. Suomessa tuotanto on kallista, eikä halpamaiden kanssa pystytä kilpailemaan työvoimakustannuksilla. Keskeinen keino pysyä kilpailukykyisenä on automaatio.



Aikoinaan esitettiin väite, että automaatio vie työpaikkoja. Niinhän se tekee, mutta jalostaen ihmisten kapasiteettia sellaisiin tehtäviin, joissa he ovat parhaimmillaan. Samalla automaatio on luonut uudenlaisia työpaikkoja esimerkiksi laitteiden valmistukseen ja huoltoon liittyen.

Automaatio ei ole enää pelkkää paineilmasylinterien liikuttamista: nykymaailmassa automaatiojärjestelmien on käytännössä aina pystyttävä integroitumaan muihin järjestelmiin.

Kunnossapitojärjestelmä auttaa siirtymään reagoivasta huollosta ennakoivaan huoltoon: sen avulla voidaan esimerkiksi vaihtaa kuluvia osia ennen niiden rikkoitumista. Yllätysseisakit saadaan minimoitua, kun huoltoseisakit voidaan suunnitella dataan perustuen etukäteen.



Kunnossapitojärjestelmä voi olla kokonaan laitteiston ulkopuolinen järjestelmä. Se voi myös olla osa automaatiojärjestelmää, jossa ohjelmisto kerää tietoa koneen toiminnasta, analysoi sitä ja antaa käyttäjälle tai kunnossapidolle ennakoivaa tietoa esimerkiksi komponenttien kulumisesta.

Suurin riski on se, ettei projektin alussa tehdä riittävän kattavaa kartoitusta. Tällöin tilaajalla ja toimittajalla ei ole yhteistä käsitystä siitä, mitä ollaan tekemässä.

Toisena mainittakoon viestintä projektin aikana. Jos projektissa ilmenee haasteita, niistä on tärkeää kertoa avoimesti ja riittävän ajoissa. Rehellinen ja avoin kommunikaatio pienentää projektin riskejä huomattavasti!

Lisää onnistuneesta automaatioprojektista ja sen riskeistä tässä artikkelissa.

Tricyclen Jere on paitsi koodari myös koneinsinööri. Taustalla on siis mekaaninen ymmärrys koneista ja siitä, mitä automaatio tarvitsee toimiakseen sekä ohjelmiston että mekaniikan näkökulmasta.

Tavaramerkkimme on käyttäjälähtöinen ohjelmointi ja käyttöliittymien intuitiivisuus. Tätä ei voi toistaa liikaa: softaa ei edes pidä pystyä käyttämään väärin!

Tarjouksen tekemiseen tarvitaan mahdollisimman tarkka kuva siitä, mitä järjestelmän pitäisi tehdä.



Yksi kriittinen vaihe, jota tilaaja ei välttämättä tule ajatelleeksi, on testaus ja siihen tarvittava materiaali: Jos projektiin kuuluu testaus materiaalin avulla, on tärkeää varata riittävästi koeajomateriaalia. Monesti on haastavaa hamottaa, kuinka paljon materiaalia tarvitaan kunnolliseen testaukseen. Järjestelmää pitäisi pystyä ajamaan tarvittaessa jopa useiden tuntien ajan, jotta sen toiminta voidaan testata luotettavasti ennen varsinaista koeajoa.

Projektin aloitusaikataulu on täysin tapauskohtaista. Jos työkuormaa ei ole valtavasti, uuden projektin voi yleensä aloittaa melko nopeasti.

Useimmiten kyllä, viimeistään käyttöönoton yhteydessä.



Mahdollisuuksien mukaan pyritään luomaan myös etäyhteydet järjestelmään. Näin voimme tarvittaessa reagoida tilanteisiin nopeasti koneen elinkaaren alkuvaiheessa ja auttaa ilman matkustusviivettä.

Kyllä vaan: tukea voidaan antaa etänä tai paikan päällä.

Varsinkin tilanteissa, joissa kattavia testiajoja ei ole voitu tehdä etukäteen, tuotannossa voi tulla vastaan havaintoja, jotka edellyttävät järjestelmän kehittämistä. Tällöin tuki on välttämätöntä, jotta laite saadaan toimimaan halutulla tavalla.

Ja kun käy niin, että asiakas haluaa myöhemmin jonkin modifikaation järjestelmään, on luontevaa tilata työ alkuperäisen ohjelmiston laatineelta toimittajalta.

GMP eli Good Manufacturin Practice   tarkoittaa hyviä tuotantotapoja koskevia laatukäytäntöjä ja toimintamallia, joita sovelletaan erityisesti lääkkeiden, elintarvikkeiden ja muiden tarkasti säädeltyjen tuotteiden valmistuksessa. 

GMP-ympäristössä ohjelmiston tärkeä tehtävä on estää käyttäjää tekemästä virheitä, jotka voisivat vaarantaa tuotannon jäljitettävyyden tai laadun. Käytännössä tämä tarkoittaa esimerkiksi sitä, että järjestelmä ei salli erän käynnistämistä ilman tarvittavia materiaalitietoja eikä hyväksy väärää materiaalia tuotantoon. Näin vältetään tilanteet, jotka johtaisivat poikkeamaraportteihin, erien hylkäämiseen tai pahimmillaan tuotteiden takaisinvetoon.

Ohjelmistokehityksessä GMP näkyy erityisesti jäljitettävyytenä ja hallittuna muutoshallintana. Kaikki ohjelmistomuutokset dokumentoidaan, versioidaan ja testataan ennen käyttöönottoa. Muutoksista jää selkeä kehityshistoria, eikä tuotantojärjestelmään tehdä mitään omin päin.

Lisää GMP:stä tässä artikkelissa!

Kyllä, voit myös tarvittaessa pyytää konsultointiapua.

Pääosin kyllä. Suojaamme omat vakio-ohjelmakirjastomme, mutta muuten projektiin tehty kehitystyö jää asiakkaalle. Ohjelmistoa voi kehittää eteenpäin kuka vain ja asiakkaalla on mahdollisuus valita seuraava ohjelmistokehittäjä vapaasti, jos laitteeseen tehdään modifikaatioita. Meidän vastuullamme on tuottaa sellainen ohjelmisto, että valinta kohdistuu meihin myös uudelleen.