Szabad szoftver eszközökkel programozható PLC

Ipari automatizálási projekthez keresek PLC-t.

Annyit kell tudnia, hogy jeleket beolvas (érzékelők), logika szerint kimeneteket állít elő (pl jelzőlámpák), illetve egy (beágyazott ipari kivitelű) PC felé továbbítja a bejövő jeleket, és onnan is kaphat jeleket.

Ez a létra logika dolog nekem nem szimpatikus, én programban tudok gondolkodni, és abban szeretném megoldani a feladatot. Ahogy egy mikrovezérlőre programozik az ember, úgy szeretném programozni viszont masszív ipari minőségű PLC-szerű eszközt szeretnék.

Szívem szerint valamilyen szabad szoftveres eszközökkel programozható PLC-t használnék. Például ha lenne olyan, aminek például 8 bites AVR a lelke, és arra vannak a perifériák felépítve, azzal már teljesen elégedett is volnék. Tudom, hogy kicsit outdated 8 bites vezérlőre programozni, de kiforrott, ismerem, és számomra pont elég lenne a tudása.

Persze szóba jöhet más processzor is, a lényeg, hogy szabad eszközökkel programozható legyen. (Ez nem technikai megkötés, hanem csak a mániám miatt.)

Létezik például ilyen: https://www.industrialshields.com/industrial-plc-based-on-arduino-origi…

Ez a tudása alapján teljesen jó lenne, van is ilyenem otthon, működik meg minden. Viszont nem teljesen professzionális külsőre, és nem is érzem megbízhatónak egy valódi ipari alkalmazáshoz.

Van valakinek tapasztalata valódi ipari minőségű mikrovezérlőként programozható vezérlővel?

Hozzászólások

Ha megbízható kell, ne nézd át árát, valamint létradiagramm helyett ott a structured text sok CoDeSys fejlesztőeszközű PLC-nél. Sokban hasonlít a Pascalra, de nem teljes a szabadság, a PLC lelkivilágát is jó tudni hozzá és a kódodban nem lehetnek túl számításigényes dolgok mert pl beriaszt a watchdog timer. De kijátszható.

Konkrét típust tudsz mondani?

El tudom képzelni, hogy maradok a PLC jellegű programozásnál, de azt mindenképpen szeretném, ha Linux alapú PC-s programmal tudna kommunikálni. Mert a PC-re Linux van tervben.

Még az is jó volna, ha a PC hoszt, amire rá van kötve felül tudná írni a programját automatikusan, nem kellene hozzá odamenni egy technikusnak.

Sosem dolgoztam még PLC-vel, azért kérdezek ilyen láma dolgokat, hogy ezek működnek-e, illetve milyen eszközökkel működnek?

Wagonak voltak/vannak embedded linux alapú PLC-jei, meg a Boschnak is:
https://www.cnx-software.com/2018/03/07/wago-pfc200-plc-runs-embedded-l…
https://www.cnx-software.com/2017/03/23/bosch-rexroth-indracontrol-xm22…

Meg talán a siemens is jött ki valami Quark alapú cuccal, bár na azt az Intel tervei miatt már nem vennék :D.

Amit jó pár éve éve próbáltam: Siemens logot lehetett Linux alól programozni, (bár az inkább programozható relé mint PLC). Valami Java alapú csoda volt, a kódja nem volt obfuszkálva. Eredetileg RHEL supported only volt, azt hiszem talán nem találta a hálókártyámat ezért kicsit meg kellett buherálni a revengelt java kódot.

A Siemens cucc azért jó, mert a legtöbb helyen ezek vannak, és a megrendelők tuti megbíznak benne, ha ilyet látnak. És ha tönkremegy, akkor senki nem fog rám mutogatni, hogy azt a szart te találtad ki :-).

Végülis lehet, hogy megelégszem ennyivel, ha technikailag meg tudom valósítani a Linux-> PLC kommunikációt egy kis hekkeléssel. Ez a minimum szint, amit tudnia kell.

Passz.
Ha nem akarsz szívni, akkor vagy vendor lock, vagy Raspberry (méretű teljes értékű számítógép) . Nekünk Eaton eszközöket mutattak, azok egymással könnyen beszélgettek, de soros és Ethernet kapcsolaton tudnak PC-vel is kommunikálni. Az, hogy milyen OS fut rajtuk, hótmindegy, ha nem tudsz közvetlenül hozzáférni.

Ugyan overkillnek érzem egy PLC helyére egy Linuxos ARM számítógép berakását, de azért végiggondolni érdemes lehet ezt az utat is.

Van olyan Linux alapú "PLC", amivel van tapasztalatod? Ezt úgy kell elképzelni, hogy egy RPI-t betesznek egy dobozba, és az RPI GPIO kivezetéseire építik rá azokat a szintillesztő, stb áramköröket, amiket egy PLC-re szokás?

Van konkrét oka, ami miatt fázol a létradiagramtól, vagy csak puszta "nem szimpi" van benned?
Én mindenképp plcben gondolkodnék, modbus támogatással, és egy hozzá linuxon is vígan kerregő "frontend"-ben, a választott programnyelven. (bármilyenen). Én épp egy hasonlót csinálok most, Mitsubishi PLC, ethernet, modbus, a monitoron meg majd egy Go-ban írt program lesz látható.
Nemrégiben nyitottam is egy topicot, hogy sima usb csatlakozással a fórumozók mit javasolnak, egyből rá lettem terelve a modbusra. Köszönet érte!
Jelenleg USB-n megy C#-ban írt kezelő programmal, winfoson, de zavart, hogy nincs linux. Most majd lesz a fent említett módon.
Ha kell erről több infó, privátban várlak!

A létra csak pusztán "nem szimpi". Szóval végülis meggyőzhető lehetek. Pár kérdésem van, ezekhez szerintem nem kell privizni, mert közérdekű lehet PLC noobok számára:

Programozás:

* A létra programnak van szöveges változata, amit értelmesen lehet verziókezelni?
* Milyen módon kerül fel a program a PLC-re? (Milyen hosztról milyen programmal, milyen csatlakozáson keresztül? Lehet-e emberi beavatkozás nélkül programozni a hozzá csatlakozó PC-ről?)

Modbus:

* A modbus-hoz milyen HW kell a PC oldalon? Jól értem, hogy rendes TCP Etherneten?
* És milyen szoftver kell a PC oldalon? Jól értem, hogy a szabad modbus libek működnek?
* hogy programozok Modbust a PLC-n? Kimenetnek és bemenetnek választhatok ModBus-os jeleket, amik periodikusan fognak frissülni automatikusan?

Ezekhez tényleg nem kell.

Programozás:
1. Van szöveges változata, /nah az meg nekem nem szimpi:)/ de azért itt messze más programozásra kell felkészülni. Csak nyomokban hasonlít a napjaink programnyelveihez, és ha verziókezelni akarsz akkor ne akarj. Plc-s világban nincsenek akkora programok amelyeket ne lehetne áttekinteni tapasztalt szemnek viszonylag könnyen. Persze lehet git-ezni, meg svn-ezni, de nem látom igazán értelmét, mert a tapasztalatom szerint nagyon kevés újra használható kódot tartalmaz egy plc program. Ha módosítani kell rajta akkor az sokszor "jelentős mértékű" a végrehajtot művelet / folyamat szempontjából. Plc programozás nem olyan, mint a compiler-es, meg manage-elt kódos csodanyelvek. Inkább az interpreteres nyelvek felé tudnék asszociálni, a végrehajtás módja miatt, de kb ennyi is ami közös.

2. Elsősorban az adott plchez van egy, két, három, a gyártó által biztosított fejlesztőkörnyezet. Ezzel kerül fel a program a plcre. Mishubishi (FX3) esetén én usbzek, vagy serial a régebbi típusoknál. (FX3 alatt).
Deltával volt dolgom, ott egy sima nyomtató USB kábele megtette a dolgát, igaz az a HMIbe volt dugva, a PLC meg passthrough kapta a saját kódját RS485-ön.
Szóval a lényeg, adott gyártó adott plc típusához megvan, hogy érdemes csatlakozni hozzá. Úgy érdemes, nem máshogy.

Ami általában jellemző az a serial valamilyen formája. RS232, 485, 422. Gyártója válogatja, ( a csatlakozó fizikai formája tud érdekes lenni..Unitronicsnál pl a telefon csatlkaozó)

"Lehet-e emberi beavatkozás nélkül programozni a hozzá csatlakozó PC-ről?"...ez nem értelmezett a számomra, semmilyen programozás szempontjából, nem csak plc esetében. De ha arra gondoltál, hogy automatizálni a plc progamjának frissítéseit, akkor ugyanaz a tanács mint a verziókezelésnél. Iparban nagyon vékony jég az ilyen jellegű automatizálás.
Nyilván meg lehetne oldani, de ha a frissítés közben valami balul sül el...s nincs ott az ember...meg nem is nagyon van értelme automatizálni. Frissítés után tesztelni kell, hogy minden rendben van-e. Azt nem tudod automatizálni...tehát az azt megelőző lépést sincs értelme akkor.

Modbus:

Nem kell HW a pc oldalon. Illetve 100% hogy rendelkezel vele alapból. Vagy eth kell, vagy serial, szinte kizárt hogy bármely alaplapon ma ne lenne legalább az egyik.
Fogsz egy modbus libet a választott programnyelven és kódolsz. Igen.

PLC oldaláról a modbus már nem triviális. vannak plc-k amik alapból tudják/ értik a modbus protokolt. Vannak amelyek meg nem, és kell hozzá bővítő kártya, hogy legyen modbus-od. Programozni a plc oldaláról ezt nem kell, esetleg pár beállítást kell eszközölni, ami természetesen mint mindig, gyártó függő lesz.

"Kimenetnek és bemenetnek választhatok ModBus-os jeleket, amik periodikusan fognak frissülni automatikusan?" Ismét zavarban vagyok, és itt megfejteni se tudom mire gondoltál.
Talán arra, hogy monitorozni szeretnéd a plc ki és bemeneteit? Természetesen lehetséges modbussal is monitorozni, igazából a PC-s program fog erről gondoskodni. Ha nem erre gondoltál, akkor fejtsd ki bővebben légyszíves.

remélem hasznos volt.

> lehet git-ezni, meg svn-ezni, de nem látom igazán értelmét, mert a tapasztalatom szerint nagyon kevés újra használható kódot tartalmaz egy plc program.

Azért hasznos verziókezelni, mert így a változásokat vissza tudom követni. Előfordul, hogy ügyfelek rákérdeznek, hogy mikor változtattunk utoljára, és miért is? Az ilyen jellegű kérdésekre a verziókezelő túrásával tudok válaszolni. Egy bináris formátumú programnak még két verzióját összehasonlítani sem egyszerű, nemhogy visszakeresni, hogy a múltban mi hogy működött.

> ha arra gondoltál, hogy automatizálni a plc progamjának frissítéseit, akkor ugyanaz a tanács mint a verziókezelésnél. Iparban nagyon vékony jég az ilyen jellegű automatizálás.

Nem feltétlenül arra kell gondolni, hogy éles környezetben használnám ezt, de például arra jó lenne, hogy ha egy prototípus össze van rakva egy laborban, ahol gépészek dolgoznak rajta, akkor a szoftver frissítéséhez nem kellene odamennem, vagy a gépészeket flesselésre bírni, hanem csak rátöltik az új programot a PC-re (vagy rátöltöm távolról), és már működik is. Egy csomó autózást meg lehet ilyenekkel spórolni.

Ebben is van valami!

Az ügyfelek mivel fizetnek mint a katonatiszt amikor változtatni kell a kódon, így emlékeznek is alaposan :)

Az olyan jellegű kérdésekre kizárólag a dokumentáció adja a választ, nem a verziókezelő, higgy nekem.
Persze nem kötekedés, ha az éppen futó katyvaszról le lenne egy max két sorban írva, hogy "mi történt a múlt hét óta..." akkor egyszerűbb lenne az életed.

Prototípusnál nyilván más a helyzet. Akkor egy "tímvjúer" is megteszi, ne bonyolítsd túl.

Simán lehet olyan is, hogy az az ember már ott sincs, aki annó kérte, és az sincs ott, aki programozta. És csak hozzá kell nyúlni, hogy mondjuk plusz egy biztonsági szenzort is kezeljen a PLC. Ha verziókezelőben van a program, akkor akár az utódom is meg tudja nézni, hogy mit mókoltam 5 éve én. Látja hogyan fejlődött ki a végleges megoldás, illetve mielőtt kiautózna a helyszínre meg tudja nézni, hogy mire számítson, nagyjából mit kell beletennie. Sőt, akár bele is teheti.

Ha a program csak egy zárt eszközön belül elérhető, akkor az egész folyamat azzal kezdődik, hogy össze kell bányásznia a fejlesztő eszközöket valahonnét. De honnét? Láttam már olyat is, hogy egy régi rendszerbe kellett belenyúlni, amihez a fejlesztőeszközöket réges-régen letörölte mindenki a gépéről. (Igaz, nem PLC-ről van szó.) De semmi baja, csak épp egy dolgot kellene beleheggeszteni.

(Nyilván ha én csinálom a melót, akkor ezek mind dokumentálva, és archiválva lesznek a későbbi karbantarthatóság céljából. De ezeket az archívumokat karbantartani is költség.)

Ha ugyanez mondjuk egy AVR csippen lenne, és el lenne téve a programja (verziókezelőben, ami nem plusz költség, mert ezeket úgyis archiválni kell programozóként), akkor a mai eszközökkel simán újra lehetne forgatni a programot, és működne. Oké, az AVR GCC-ben is voltak inkompatibilis változtatások, de többnyire van "legacy" header, vagy ha nincs, akkor dokumentált, hogy hogy kell upgradelni a kódot. Pár óra alatt életre lehet lehellni egy 10 éves kódot is.

Ebben a műfajban, hogy egy szakértő kimegy és felprogramozza az sem tetszik nekem, hogy sok esetben nem készül doksi, nincs mentés sehol, stb. Ha tönkremegy a cucc, akkor újra kell programoztatni, mert senki nem tudja, hogy hol van a program lementve. Vagy ha van mentés, akkor az a legújabb-e? Legalábbis ezt láttam amikor rákérdeztem itt-ott. Lehet, hogy van ahol másképpen megy ez. Nyilván az hogy ott van egy verziókezelőben, hogy milyen dátummal mi változott, az még önmagában nem dokumentáció, de a semminél több. Ha értelmes a commit message, és írunk mellé egy minimál doksit, akkor már vissza lehet követni. Nekem legalábbis eddig ez a tapasztalatom, hogy kiigazodok többéves logok alapján is olyan dolgokban, amikre alapból egyáltalán nem emlékszem vissza.

A PLC létra vs program témához leírom, hogy hogyan szoktam mikrovezérlős rendszereken dolgozni:

* Írok egy HAL réteget az adott vezérlő+perifériák kombinációhoz. Csak ebben használok vezérlő specifikus kódokat
* A program többi része platformfüggetlen standard C vagy C++
* A HAL réteget megcsinálom szimulátorban is PC-re. Ehhez néha csinálok GUI-t is.
* Tesztkörnyezetbe is belefordítom a kódot, így a logikához tudok auto teszteket is csinálni
* A program PC-s beszélgetőpartnere, és a mikrovezérlő programja egy verziókezelőben van, együtt verziózódik.

Ez a módszertan elég kényelmes és hatékony nekem. Nem tudom, hogy hasonlót meg lehet-e a létrával csinálni? Van olyan keretrendszer, amivel létrát lehet szimulálni, tesztelni PC-n?

A PLC-k esetén a keretrendszert elsődlegesen a gyártó adja. Ez a többségében szimulátort is tartalmaz. Mivel a legtöbb gyártó keretrendszere alapértelmezetten valamilyen bináris formában tárolja a projektadatokat, így a verziókezelés zömében a bináris fájlok mentésére korlátozódhat.

Duplan off, de erdekelhet:
Van egy LinuxCNC nevu progi ami elsodlegesen CNC vezerlot csinal egy Linuxos gepbol, de lehet hasznalni PLC-szeruen is. Gyakorlatilag pineket definialhatsz, kothetsz ossze, es irhatsz hozzajuk drivert ha sajat hardware. Szukseg eseten megy soft es hard realtime kernelekkel is, utobbi egy kisse regi. Adnak hozza hagyomanyorzok szamara olyan modult is, ami letrat eszik.

Ezen kivul van olyan SBC, aminek van ipari kivitelu valtozata is, rendes levalasztassal, es van LinuxCNC port hozza. (valamilyen Beaglebone varians remlik, de utana kellene neznem, ezzel nincs tapasztalatom)

Persze lehet, hogy neked overkill.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin