Archief - De grote automatiseringsthread!

Sparco, echt PLC programmeren zal je toch maar leren eens je gaat werken. Ik ben begonnen als PLC programmeur met enkel wat basiskennis van ladder. Ik kon wel goed programmeren in C voor microcontrollers. Maar nu speel ik toch ook met de PLC's hoor, vooral die van Siemens. Meest gemakkelijke gerief die er bestaat, Allen Bradley begint meer en meer te komen.

Bij ons kreeg je 5 semesters STEP7 van Siemens (alleen STL) en 4 semesters PCWorX van Phoenix Contact, daarbij ook nog 3 semesters VB.NET (toegepast op automatisatie).
In het laatste jaar hadden we 6h labo per week (5h industriële automatisatie en 1h bovenliggende zaken). Verder redelijk wat theorie gezien over alle verschillende bussen e.d.

Jij hebt wel een knap pakket gekregen vroeger L0$t Pr0PhEt. Wat hielden die 3 semesters VB.NET in ?

Wij hadden vroeger op school enkel een paar uur Allen Bradley per week. Beetje programmeren in ladder. Om eerlijk te zijn echt zinloos ... Die kleine dingen kan je iedereen laten doen in ladder + ladder wordt bv op mijn werk amper tot niet gebruikt.

Verder ken ik niet te veel van PLC's naarmate ik enkel DCS programmeer.

^MystiQ zei:

Ik haat het echt zo hard om projecten over te nemen van andere personen é, ik haat dat echt keihard en vooral als het bovendien nog eens crappy gedocumenteerd blijkt te zijn ad:

Klik om te vergroten...

^MystiQ zei:

Rabsi, commentaar in een programma is de grootste bullshit die er bestaat. Als je een programma deftig geschreven hebt moet iedereen daar wijs aan geraken wat er precies geprogrammeerd is.

Klik om te vergroten...

B-ke zei:

Jij hebt wel een knap pakket gekregen vroeger L0$t Pr0PhEt. Wat hielden die 3 semesters VB.NET in ?

Klik om te vergroten...

Ja ik ben blij dat ik veel van automatisatie heb gezien want was eigenlijk het enigste wat ik graag deed.

Eerste semester VB.NET was de basis van programmeren, wat je allemaal kan met VB enz...
Vanaf het 2de semester kregen we dan toepassingen op SQL, OPC, TCP/IP, OFFICE, XML, ...

Tristan zei:

Bugge, heb jij toevallig geen goeie info liggen over EMC enzo, als je met hele dagen met drives bezig bent? Over afscherming vermogenkabels, analoge signalen enzo?

Klik om te vergroten...

Hier een algemene guide;

http://www05.abb.com/global/scot/scot201.nsf/veritydisplay/a8dc0a0e66d66118c12575d6002fd22d/$file/abb_technical%20guide%20no.3_revd.pdf

Tristan zei:

Klik om te vergroten...

Er is een verschil tussen commentaar in je programma en je project documenteren.

^MystiQ zei:

Er is een verschil tussen commentaar in je programma en je project documenteren.

Klik om te vergroten...

Ik vond het gewoon lol

Tristan zei:

Ik vond het gewoon lol

Klik om te vergroten...

Think before you speak

^MystiQ zei:

Think before you speak

Klik om te vergroten...

Oké, 'k zal in mn notitieboekje schrijven dat commentaar niet onder documentantie valt van een programma/project !

Een thread op mijn lijf geschreven!

Ben dus automation engineer voor een grote Amerikaanse machinebouwer.

Meeste kennis & training opgedaan door cursussen te volgen bij fabrikanten:
B&R cursus gevolgd (gaande van PLC tot Acopos sturingen) in Aalst
Allen Bradley RSLogix (CLX/Kinetix) motion gevolgd (in Strombeek)
Lenze sturingen (8xxx & 9xxx reeks) servo sturingen in Antwerpen

Camera inspectie heb ik ook ervaring mee. Datasensor SCS1 en Omron Xpectia camera's. Mijn amerikaanse collega's werken dan weer met Cognex. Deze camera's gebruiken we oa voor produkt controle.

Naast PLC sturingen, doe ik ook robot programmatie: Fanuc robotics (system integrator cursus) gevolgd te Mechelen. Een domein apart eigenlijk, maar meer en meer machinebouwers krijgen de vraag om robots te integreren met hun machine. (voor onze markt is het voornamenlijk om loonkosten te drukken.) Voor de geïnteresseerden: we werken met de Fanuc M20 robot en R30i controller. Sturen deze aan via Ethernet/IP vanuit een Powerpanel PLC. Oa een Datasensor inspectiecamera geeft ons het resultaat terug van de controle. PLC verwerkt data/stuurt acties uit naar machine onderdelen en commandeert ook oa. de robot. Data wordt uitgewisseld over OPC naar een centrale server. Bv dit machinepark gelegen in Indiana/VS wordt via een VPN verbinding gemonitored in België


We werken dus hoofdzakelijk met B&R PLC's (bernecker & rainer) voor de machines die in België geproduceerd worden. Echter doen wij ook ondersteuning en ontwikkeling voor machines gebouwd in Amerika. Vandaar de nood om oa. Rockwell te kennen.

Programmeren gebeurt bij ons in structured text (of een afgeleide: automation basic) & C.
Ladder wordt bij ons vermeden: ganse pagina's van spaghetti bekijken; moeilijker overzicht; het duurt ook langer om een deftige sequentie te schrijven...Kortom, wie wil tekenen, die moet maar met ladder aan de slag gaan.
Wie echt wil programmeren, die schrijft zijn code. (dat is ons motto althans :applause: )

Het boeiende vooral is dat je effectief ziet wat je programmeert. Zaken zien bewegen gaande van een simpele motor tot een 6-assige robot!

ABCDEFGHIJKLMNO zei:

Programmeren gebeurt bij ons in structured text (of een afgeleide: automation basic) & C.
Ladder wordt bij ons vermeden: ganse pagina's van spaghetti bekijken; moeilijker overzicht; het duurt ook langer om een deftige sequentie te schrijven...Kortom, wie wil tekenen, die moet maar met ladder aan de slag gaan.
Wie echt wil programmeren, die schrijft zijn code. (dat is ons motto althans :applause: )

Klik om te vergroten...

Niet echt akkoord. Voor beginelingen en support is dat een hell (support kijkt enkel pas na oplevering en kent dus het programma bij het begin van een call niet). Voor data zaken en berekeningen is STL aangeraden. Maar simpelweg motorke aansturen met domweg enkel fotocellen is veel duidelijker voor problemen later om dat in ladder te zetten (dat en ladder is altijd om te zetten naar stl omgekeerd niet). Kan mij ook niet inbeelden dat je even efficient schrijft in stl dan hij dat omzet van ladder (moet ge eens bekijken, hij werkt zelf veel steviger op de accu, duidelijkheid is iets ander ma bon)

Ben zelf wel voorstander van stl

Ik ben op de sukkel met een bepaald ding, het werkt maar laat ons zeggen dat het werkt in 90% van de keren dat er een doos passeert. Met andere woorden, naar mijn normen werkt het niet. Maar ik slaag er voorlopig niet in om het probleem te vinden ad:

ABCDEFGHIJKLMNO zei:

Het boeiende vooral is dat je effectief ziet wat je programmeert. Zaken zien bewegen gaande van een simpele motor tot een 6-assige robot!

Klik om te vergroten...

Dat bedoel je nu toch niet specifiek voor STL veronderstel ik?


EDIT: Eureka! Ik denk dat ik het probleem gevonden heb!

^MystiQ zei:

Er is een verschil tussen commentaar in je programma en je project documenteren.

Klik om te vergroten...

als uw programma deftig gecomentarieerd is hebt ge nauwelijks extra documentatie nodig.

En als dat toch nodig is zit er iets serieus mis in uw programmeerstijl

je hebt toch nog altijd den FDS waar alles in moet staan bij oplevering?

Fds is documentatie over de werking van uw installatie en dat is altijd nodig. Maar als er daarnaast nog veel documentatie nodig is om het programma zelf te kunnen begrijpen klopt er iets niet.

Enkel de standaard blokken moeten gedocumenteerd zijn. Als ge voor de rest nen deftige structuur houd is extra documentatie niet nodig

Voorbeeld van slecht: compleet programma in 5 fc's. Stuk of 10 motoren, 15 kleppen, wat regelaars en bijhorende metingen.

Heeft me zelfs met fds een week gekost om alles uit te zoeken.

Daarna met onze interne blokken en algemene plc structuur opnieuw geprogrammeerd op 2 dagen (incl scada beelden in iFIX. 3 uur fat en 1 dag io testen en in dienstname

Falc.be. Ik heb een programma onder mijn neus gehad van een automatische kraan die profielen uit rekken haalt. En dit alles in één functie geprogrammeerd. Encoders uitlezen, motoren aansturen, sensoren binnen lezen, logica programmeren, fouten generen, timers en noem maar op, stond allemaal in één functie. Ik heb er welgeteld 10 minuten naar gekeken en gezegd dat ik er zelfs niet aan begin. Ik wil werken, en ik ga echte uitdagingen maar dat soort dingen zijn geen uitdagingen meer voor mij. Dat is gewoon de stront van een ander opkuisen en hoe minder ik daar moet deel van uitmaken hoe liever. Ofwel schrijf ik zoiets opnieuw ofwel moeten ze maar een andere duts gaan zoeken die er wel zijn tijd in steekt. Bovendien winnen we er meer geld aan als we zo een dingen opnieuw kunnen doen.

Bovendien heb ik niet de indruk dat je al onder grote stress van nijpende deadlines gestaan hebt? Want ik blijf het herhalen, commentaar is het laatste maar dan ook het allerlaatste die up to date gehouden wordt. Is dat spijtig? Ja dat is spijtig maar dat valt nu eenmaal vrij veel voor. En het fenomeen die ik dan vaststel is dat techniekers zeggen "ja maar ja, dat staat hier wel zo in de commentaar". Vooral in het buitenland is dat dan nog eens extra moeilijk. Daarom proberen wij commentaarvrij te programmeren behalve als de klant erom vraagt. Als er geen commentaar is moeten ze nog een inspanning doen om het ook effectief te begrijpen. En dat bespaart ons dan weer een hele hoop telefoonwerk omdat ze zich niet vastpinnen op commentaar.

Enkel bij encoderberekeningen en dergelijke meer kan zoiets wel interessant zijn omdat ze dan zien vanwaar de berekening komt met het aantal getelde pulsen. Maar verder van de rest heeft commentaar weinig zin vind ik.

Trouwens, projectdocumentatie dat is voor mij:
- Een handleiding van uw installatie
- Uw layouts van motoren, sensoren en dergelijke meer
- Een layout van uw netwerkoverzicht
- De belangrijkste grafcets van uw project
- Datasheets van encoders enz.
- ..

Softwarecommentaar is daar wat mij betreft maar een heel klein deeltje van ..

Over stress kan ik goed meespreken. Kijk er zijn nog eens zovele takken binnen automatisatie en wij zitten duidelijk niet binnen dezelfde tak.

Je hebt machine bouw die vaak hun eigen plc sturingen in een blackbox hebben zitten. Om eerlijk te zijn heb ik daar weinig ervaring mee tot nu toe.

Mijn werk ligt meer in de programmering van complete installaties met bijhorende scada structuren. Ik zorg voor de software. Hw is doorgaans niet mijn problem. Hoewel ik wel meezoek naar fouten. Het bedrijf waar ik werk levert dan ook vornamelijk software. Kasten gebeurd in onderaanneming
Zo heb ik reeds 3 complete waterzuiveringen gedaan. Slibafvalverwerking en 5 grote pompstations met ieders 4 pompen van 500 kw. Maw ik zorg voor de regeling van de waterdruk in een vrij groot gebied. Dat brengt stress met zich mee

Ik heb al talloze weekenden opgegeven omdat ik te weing tijd kreeg of werk had voor 2 man

Echter. Er bestaat een fds. Pnid's en io lijsten. Van mijn kant is er een map met beschriving van de standaardblokken en plc structuur en de support was er meteen mee weg

Ook heb een een scada structuur opgebouwd met 6 iFIX serverparen en meer dan 20 clients. Zoiets draaiende houden is ook serieus stresserend

Effe klein vraagje, wat is de interessantse cursus voor servomotoren te programmeren (denk hierbij aan voornamelijk siemens, maar ook mogelijk SEW of Danfoss)? (andere zijn ook altijd welkom natuurlijk)

Wat bedoel je precies met servomotoren programmeren? Ge bedoelt waarschijnlijk meer het parametreren van een servomotor?