Új hozzászólás Aktív témák
-
Szirty
őstag
Szevasz moseras!
"1. A létra ágainak(jól fogalmaztam ???) jobb oldalán csak 1 kimenet lehet ? (tehát, ha egy új kimenet kell, ahhoz új network-ot kell készítenem ?)"
Azt sajna kapásból nem tudom, hogy az IEC erre mit mond, de általában nem. Egy network létra jobb oldalán jóformán bármennyi kimenet (coil) lehet (persze az átláthatóság és ésszerűség határán belül). Pl. így:
De az IEC eléggé "minimál" követelményeket fogalmaz meg, szerintem minden megvalósítás ami megfelel neki, egyúttal jelentősen túl is szárnyalja."2. Bonyolultabb hálózat esetén úgy érzem, hogy nem akarok az első ágon kimenetet definiálni, csak egy belső változót, és ezzel folytatni egy új network-ben. Ezt hogy tudom megcsinálni ? Erre való a Marker ?"
Pontosan, bár egyes esetekben nem így hívják. Nevezhetjük "belső változónak" is, ami olyan bit, aminek nincs közvetlen köze sem bemenethez, sem kimenethez, csak egy memóriarekesz. Omronnál pl. ilyen a HR terület (is), illetve az az I/O terület is, emihez nem tartozik fizikai I/O cím. (Ezek tényleges mennyisége ugyanis kiépítéstől függ, de a teljes I/O terület minden bitje megvan akkor is, ha nincs kihasználva).
"3. A "kontakt-ok" lehetnek output-ok is ? Tehát képes egy kimenetet bemeneti változóként kezelni ?"
Igen, természetesen ez egy alapvető tulajdonság. ha van egy Out, arra a programban akárhányszor lehet hivatkozni mint "érintkező" attól függetlenül, hogy az belső változó, vagy fizikai kimenet.
"4. Ha beteszek egy "TOF"-ot mondjuk 3sec-re, akkor addig amíg ez le nem jár, addig a PLC nem kerül be új ciklusba ? (mondjuk ez érdekes lenne)"
A PLC mindig végrehajtja a teljes user programot minden PLC ciklusban, a timerektől függetlenül. Ez alól csak akkor van kivétel ha vezérlés átadó utasítást használsz (amivel átugorhatsz részeket egyes PLC ciklusokban) és akkor, amikor a program vagy a HW hibás (ilyenkor a PLC STOP állapotba kerülhat, ilyenkor a programvégrehajtás szünetel).
A Watchdog nem is engedné, hogy a PLC ledekkoljon egy utasításnál, mert ha egy PLC ciklus túl hosszúra nyúlik (általában 100ms, de rendszerint ez az idő állítható) akkor intézkedés történik (egy STOP mode ilyenkor az eredmény)."5. Analóg jelet hogy lehet létrával kezelni ? Egy konstanshoz kellene hasonlítanom, és az alapján dönteni..."
Összehasonlító utasítással
De hát lehet összeadni, kivonni, stb, műveleteket végezni létrában is. Bár nem mindig szerencsés iylenkor a létra, de egy-két műveletnél nem gond.
A többi pontra a köv. üzenetben válaszolok, (tartok tőle hogy túl nagy lesz)...
-
Szirty
őstag
Szevasz moseras!
"6. Nyomógomb élkezelést (egy nyomásra a kimenet BE, egy másikra pedig KI) hogy lehet létrában megoldani ?"
A konkrét megoldás függ az adott PLC-től is. Többféleképpen is megoldható, de az elv kb. az, hogy létre kell hozni a nyomógombra egy le vagy felfutó impulzust. Vagyis olyan belső változó bitet, ami egy PLC ciklus ideig aktív lesz, amikor a gomb 0->1 vagy 1->0 állapot átmenetet produkál. Ezután ezzel a bittel invertálni kell egy másik bitet. Ez utóbbi lesz az, amit a gomb egyszer be, aztán ki kapcsol.
"7. Melyik nyelv a "jó" megoldás a problémákra az 5 közül ? Gondolom ez feladattól függ, de általánosságban mikor jó a létra, mikor jó az ST ?"
Persze hogy a feladattól függ, hiszen mindegyiket egy-egy feladatra találták ki.
Ugyanakkor igen nagy az átfedés is, hiszen az alacsonyabb szintű nyelvekkel megoldható a magasabb szintűben írt feladat. A nagyfokú átfedés miatt benne van a válaszban a melyiket szeretem/ismerem dolog is.
De pl. az olyan folyamatok, amik nagyon jól, egymástól elhatárolható állapotokból (lépésekből) áll, azokra valamelyik szekvenciális nyelv a legjobb. Különösen ha a folyamat bonyolult elágazásokból és ágak egyesülésekből álló lépéshalmaz.
A létra elég alacsony szintű, de elsősorban a logikai kapcsolatok hálózatára van kihegyezve, ebben hatékony (mint az FBD, de a kettő közötti különbség jóformán csak a megjelenítésben van). Összetettebb számításokhoz a létra vagy FBD már elég körülményes tud lenni. Az ilyen program hamar átláthatatlan lesz. Amit létrában 6-7 oldal kiszámoltatni, utasítás listában pár sorban is elférhet.
Pl. létrában egy pozícionálással foglalkozó programot írni lehet ugyan, de nem biztos hogy az a legjobb megoldás. Viszont jó megoldás ha a pozícionálás részleteivel foglalkozó program pl utasításlistában van írva, ami egy külön blokk és azt létrából hívjuk. Vagyis a blokknak létrából mondjuk meg mikor mit csináljon, de a végrehajtás részleteit (hogy azt hogyan csinálja amit csinál) a blokkon belül STL-ben írjuk meg.
Mivel az utasítás lista a legalacsonyabb szintű nyelv, ez áll legközelebb a HW-hez. Éppen ezért ez az a nyelv, ami leginkább eltér az egyes gyártmányoknál."8. C, C++-os múltamnmal nekem egyébként az ST tetszik, de a létrát is meg szeretném érteni jól."
Ez a múlt mindenképp hasznos lesz!
De a létra kicsit más gondolkodást igényel.[ Szerkesztve ]
-
Szirty
őstag
Helló moseras!
"csak a meglévő coil-al akar párhuzamosan rakni egy másikat, de az elé nem enged befűzni semmit."
Akkor ez nyilvánvalóan a használt programfejlesztői környezet egyik sajátossága (korlátja).
"6. "FB"-ben, ahogy a képen is látható nem tudok visszacsatoló vonalat rajzolni egérrel, címkézni kell, ez így nem szép"
Ez pedig egy másik korlátja lehet.
Úgy néz ki hogy ez a Wago stuff még nem forrta ki magát eléggé."a Q102 (gázkazán)-t az egyik be a másik pedig kibillenti, pedig működnie kellene. Itt akkor egy sorban egy kimenetre koncentráljak, és ahhoz tegyem oda a bemeneteket, mert akkor azt már más nem bántaná
"Nos alapszabálynak mondható, hogy egy programba nem szabad több közönséges out (coil) utasítást rakni ugyanarr a abitre. Ezért pl. az Omron fordítója szól is.
Lerakáskor:
Fordításkor pedig:
WARNING: Duplicated output - OUT 1.01 at rung 0 (6, 0)
WARNING: Duplicated output - OUT 1.01 at rung 1 (6, 0)Ez a warning kikapcsolható ebben az esetben, mert néha előfordul, hogy szükség van ilyesmire.
De a te esetedben a kimenet két helyről való "kapcsolása" nem a várt hatást hozza, mert a kimeneti bit állapota az utolsó out utasítás előtti feltétel logika eredményét fogja felvenni."Itt akkor egy sorban egy kimenetre koncentráljak, és ahhoz tegyem oda a bemeneteket, mert akkor azt már más nem bántaná
"Igen!
"8. Úgy látom, hogy nem mindegy a network-ok sorrendje. Pl. a képen első a garázs, második a lakás. Ha megfordítanám, akkor a lakás elindulhat a garázzsal együtt
"Néha a sorrend tnyleg nem mindegy. De ebben az esetben kizártnak tartom, hogy a felcserélés után máshogy működjön. Vagy valami nagyon elromlott valahol...
"9. Mi alapján nevezzem el az "M"-eket ? Mitől lesz egy "M" M100.3 vagy M110.4 ? Ezt elég fontosnak gondolom, mert az a jó, ha ránézek, és azonnal tudom (nagyjából), hogy mi is akar az ott lenni..."
Nos az M-eket úgy kell elképzelni, hogy azok egy jól körülhatárolható memóriaterületen kapnak helyet. Az M-ek száma egyben ennek a területnek a címei is.
Az M-ek tehát végülis memória címek.
Minden PLC-ben ezeknek az M-eknek a száma előre rögzített. Ezekkel gazdálkodhatsz.
Elérhetőek többféle címzésmóddal is, ezekre figyelni kell. Gondolom a wago-nál is így van, de nem ismerem, így nem biztos.
De leírom, hogy az általam ismert PLC-knél ez hogy van.
Van egy ún. szimbólum tábla. Ez egy lista, vagy táblázat ha úgy tetszik. Arra való, hogy az említett M-ekhez szimbólum nevet és megjegyzést lehessen hozzárendelni. De nem csak az M-ekhez, hanem a kimenetekhez, bemenetekhez és egyéb memóriaterületek elemeihez is.
Egy program írása azzal szokott kezdődni, hogy ebbe a szimból táblába beírjuk melyik ki és bemenet milyen funkcióval bír (amit ugye a HW huzalozás határoz meg).
A program írása közben pedig, amikor szükség van egy belső változóra, akkor a szimbólum táblába felveszünk egy új elemet egy még eddig nem használt belső változóra (ez esetben M-re) és odaírjuk a dumát mire használjuk. Ez egyrészt sokat segít a program átláthatóságának a megtartásában, másrészt könnyű áttekinteni azt is, melyik memóriaterületeket használtuk már fel.
Gondolom nem kell mondani, hogy egy már felhasznált bit más célra történő újrahasznosítása milyen következményekkel járhatBizonyos programfejlesztők megengedik a szimbolikus címzést is. Amikor az "érintkezőhöz" vagy kimenethez nem annak címét kell leírni (Q4.0, M6.5, I1.1 stb) hanem a szimbolikus nevét ("kazan" "keringeteto szivattyu" stb). Ezeket a szimbólum táblában kell megadni.
Más szóval: Itt nem úgy van mint pl. egy magas szintű nyelvben, hogy deklarálok egy változót, aminek a változódeklarációs részben megadom a nevét és a típusát, aztán a fordító majd azt csinál vele amit akar (avagy helyet foglal neki és majd tudja milyen címen van).
Itt úgy van, hogy te kinézel magadnak egy memóricímet és egy megjegyzést/nevet fűzöl hozzá, majd használod amire akarod.
Ha egyszer már felhasználtad máshol, akkor így jártál -
Szirty
őstag
Hali moseras!
"1. Jól gondolom e a vizualizáció működését ?"
Igen ez így működhet. Nem vagyok jártas a MODBUS-os megoldásokban, de a vizualizáció alapvetően arra épít, hogy egy HMI (ami adott esetben lehet PC is természetesen, vagy valamilyen cél készülék kijelzővel, gombokkal). A PLC változóit kérdezgeti le (olvassa) és írja is.
A vizualizáció lényege pedig az, hogy a vezérelt berendezést ismerve a HMI (vizualizációs eszköz) a lekérdezett adatok alapján meg tudja jeleníteni a folyamat állapotát. Továbbá beállításokat is lehetővé tesz. Adatokat ogolhat stb, amit te is szeretnél."2. Milyen "gyári" megoldások vannak erre, egyáltalán van-e PLC független vizualizációs tervező/futtató környezet sok-sok előre rajzolt objektummal, aminek én csak megadom, hogy melyik PLC változó a bemenete vagy kimenete, stb ?"
Van ilyen igen. A legtöbb PLC gyártó gyárt HMI eszközöket is és ezekhez készít HMI szoftvereket természetesen.
A HMI-nél egyel "magasabban" álló rendszer a SCADA.
A SCADA közelebb áll a vállalatirányítási rendszerhez mint a gyártó berendezések vezérléséhez, de a lényeg azonos. Rengeteg HMI szoftver létezik, melyek nagy része gyártó specifikus, de sok gyártó ilyen eszközei más gyártók PLC-ivel is tud kommunikálni.
Pl. Siemens OP-k vagy az Omron NS terminálok 5-10 fajta más PLC-t is ismernek.
A SCADA más tészta. Amennyire én látom sokkal több független SCADA fejlesztő van mint HMI fejlesztő. A SCADA sokkal kevésbé gyártóspecifikus, mert általában külön driver modulok végzik az adott PLC-hez való illesztést (nem ritkán OPC alapokon)."3. Érdemes e egy ilyen vizualizáló SW fejlesztésébe belefogni ?"
Véleményem szerint ha csak néhány változó kijelzése a feladat, vagy teljesen az adott feladathoz illesztett cél megjelenítő szoftver megírása a cél, akkor érdemes, de egy teljesen általános, sokmindenre kiterjedő tudással rendelkező rendszer kifejlesztése túl nagy feladat és egy lesz a sok tucatból, mert sok ilyen van...
"4. Ha naplózni is szeretném a változók alakulását a vizualizáló gépen (SQL alapon, a lekérdező cgi scripteket meg tudjuk írni), akkor erre milyen lehetőségeim vannak ?"
Egy HMI is tud ilyet, de egy SCADA esetében ez teljesen alap szolgáltatás. Nem probléma.Az hogy mibe tud logolni (SQL) azt meg kell nézni a kiválasztás előtt.
-
Szirty
őstag
Szevasz moseras!
"Konkrétan meg lehet e azt csinálni, hogy egy nyomógomb (mint bemenet) egy kimenetet egyszer bekapcsol, egyszer kikapcsol, egyszer inverzbe rak, egyszer pedig a kimenet követi a nyomógomb állapotát, és mindezt attól függően, hogy a művelettípust leíró PLC változómat hogy állítottam be a HMI-ből ?"
Igen, de ez nem változó típus kérdése, mert ezt már le kell programozni. De természetesen megoldható.
"- tegyük fel, hogy van olyan PLC-m, illetve HMI-m, amiben van RTC. A user azt szeretné, hogy egy "valami" változó reggel 6-ig egy X értéket vegyen fel, 6-12 között egy Y-t, stb. Ehhez milyen HMI "elem" van (van-e ilyen egyáltalán), illetve ilyenkor az RTC értékét a HMI-SW olvassa ki saját magából, és az alapján küldi el a PLC-nek, vagy a PLC olvassa ki a sajátját(ezt a verziót most nem tudom elképzelni, hogy ez hogyan is működhet) ?"
Ó igen a klasszikus probléma, amikor a rendszerben több valós idejű óra is van és időtől függő műveleteket akarunk végezni.
Ebben a tekintetben siemens oldalról tudok kiindulni. A legjobb ilyenkor, ha kinevezzük valamelyik eszköz óráját "master"-nek és a többit ehhez szinkronizáljuk.
Ezzel elérhető, hogy minden óra egyszerre járjon, innentől bármelyik adatait felhasználhatjuk. Én mindig a PLC óráját használom mérvadónak, mert az kikapcsoláskor is ketyeg, a HMI-nél meg ez attól függ milyen fajta. (Bizonyos típusoknál nincs backup áramforrás ehhez.)
Az időre való kapcsolást többféleképpen is meg lehet oldani. Mindegyikhez kell programozni. A legegyszerűbb összehasonlító műveleteket használni, de néhány PLC-ben vannak idő kezelésével foglalkozó funkciók. Pl. S7-nél van time interrupt.
Sajnos ilyenkor foglalkozni kell a téli/nyári időszámítással és azzal is,hogy mi van akkor, ha a felhasználó állít az órán. Ezt meg lehetővé kell tenni, hiszen az óra késhet vagy siethet is."tudok-e olyan változókat létrehozni (és ezt HMI-ből állítani), amely azt írja le, hogy az adott műveletet melyik bemenettel és/vagy kimenettel kell végrehajtani ?"
Igen. Programozással. Pont nem rég volt egy ilyen feladatom. HMI-ről állíthatóan kellett eldönteni hogy egy adott bemenetnek mi legyen a funkciója.
Erre is több programozási megoldás létezik. Az egyszerűbb, de kevésbé hatékony, az, hogy sok elágazással és összehasonlítással döntjük el mit is kell csinálnia egy kiemnetnek (az össze selképzelhető kombinációra kell egy ág). A hatékonyabb megoldás az indirekt címzés. Ez sokkal nehezebb és a megoldás nagyban függ az adott PLC képességeitől és ezen képességek ismeretétől a programozó szempontjából. -
Szirty
őstag
Hali moseras!
"De milyen modult kell mellérakni, ha a beavatkozóm egy időalapú jobbra/balra forgást végző szelep ? Egyszerűen az %-ot időre konvertálom, és annak megfelelően nyitom/zárom a szelepet ?
A másik, hogy ha egy kétállapotú (relé) beavatkozóm van, akkor mit csinálok a PID-el ?"A válasz az, hogy nem folyamatos szabályzót (continuous controller) kell használni, hanem léptető vezérlőt (stepping controller).
Az annyival több, hogy tartalmaz egy PWM vezérlőt is, aminek már nem "analóg" kimenete van, ahnem lét digitális.
Az egyik a beavatkozó jel növelésére, a másik a csökkentésére szologál. -
Szirty
őstag
Hali moseras!
"Mondtad, hogy használtok ilyen WAGO-s profibus I/O-kat. Mit csinál olyankor a PLC, ha ezek az I/O-k nem válaszolnak ?
Megáll minden, vagy csak az amivel kapcsolatos a távoli I/O ?"Olyankor lép életbe a "B" terv
S7-nél úgy működik a dolog, hogy van egy ún HW config, ahol szépen meg kell adni minden eszközt, ami a buszon van. A profibus token ring rendszerű, vagyis a master minden konfigurált slave-nek egymás után minden busz ciklusban küld egy jelzést, amire a slave-nek válaszolnia kell. Ha valamelyik eszköz leválik a buszról (nem válaszol) azt a master azonnal észleli. Ilyenkor két eset lehetséges:
1. Létezik erre az esetre hibakezelő blokk. Ilyenkor azt végrehajtja. Abba lehet programot írni, hogy mit tegyen a rendszer ilyenkor. Le lehet benne kérdezni melyik eszköz szakadt le, le lehet programozni mit csináljon ilyenkor a gép. stb.
2. Nem létezik a hibakezelő blokk, így azt nem tudja meghívni, a CPU STOP állapotba kerül és a teljes berendezés azonnal megáll.Persze lehet üres hibakezelő blokkot is beletenni. Néha ez is megfelelő. Ilyenkor a smmit hívja meg hiba esetén. vagyis semmit nem tesz a hiba miatt, de nem is áll le (STOP).
Az a modul amelyik leszakadt, ilyenkor rendszerint azonnal kikapcsolja a kimeneteit.
A berendezést vezérlő program ilyenkor esetleg nem megfelelően is működhet, mert ha a leszakadt modulon bemenetek is voltak, akkor azok nulla állapotúnak látszanak és a program is ennek megfelelően fog működni. vagyis ha nem írunk hibakezelést az esetre (B tervet) akkor a program nem fogja "tudni" hogy bizonyos bemenetek nem azért nulla állapotúak mert az adott bemenet fizikailag is nulla állapotú, hanem mert kommunikációs hiba van. Sokszor ez nem mindegy"Illetve milyen változót kell a HMI-re kitenni, hogy a user is lásson ebből valamit ?"
S7-nél az említett hibakezelő blokk (OB) a megoldás erre, amibe írni kell egy programot ami ad megfelelő jelzést ami aztán meg is jeleníthető (akár szövegesen is).
Vagy meg kell hívni az SFC51-et (Reading a System Status List or Partial List with SFC 51 "RDSYSST"). EZzel le lehet kérdezni az összes buszon lévő összes eszköz jelenlétét:
A hibakezelő blokkal kapcsolatban firkáltam már. Itt találod.
[ Szerkesztve ]
-
Szirty
őstag
Hali moseras!
"A WATCHDOG-ot pedig a kommunikáció nullázza. A WAGO-nál nem találok ilyent."
belenéztem a HW configba mit lehet WAGO-nál állítani.
Van watchdog, 10ms időalappal. Beállítható hogy mit csináljon ha a belső busz (k-bus) megszakad vagy hibás.
Nem tudom kipróbálni mi történik WAGO kimenettel ha leáll a profibusz, mert csak beépítve van egyelőre ilyenünk és én még nem foglalkoztam vele, pár új gépben van beépítve..."Azt szeretném, hogy a user a HMI-n kap egy táblázatot nevekkel, ott átírhatja ezeket, majd ezek visszakerülnek a RETAIN memóriába. Ha elmegy a táp, akkor is ezeket megőrzi, és legközelebb már ezekkel indul el."
Az általam ismert HMI-knél ez máshogy működik: Alapvetően minden változó a PLC-ben van, a HMI-ben csak hivatkozik rájuk az ember. Ha egy értéket kell kijelezni vagy állapotot megjeleníteni változó alapján, a HMI ciklikusan újra és újra lekérdezi a PLC-ből az érintett változó állapotát. Kivétel ez alól siemens OP-knál és egyéb HMI-knél a receptek kezelése. A recept adatrekordjait a HMI tárolja. Külön funkcióhívásokkal lehet ezeket az adatokat a PLC és a HMI között mozgatni.
-
DP_Joci
tag
Szia,
Meg kell próbálni a bemenetet frissíteni sűrűbben.PL. siemens-nél OB35-ben perifériálisan ( L PIW0 ) meghívod az aktuális bájtot, wordöt az OB35 ciklusidejének megfelelően. Ha az OB35 ciklus ideje 10ms akkor ennyi időnként "számlálhatsz" az aktuális bemenettel.
Azt meg kell nézni, hogy a Wago –nak van-e ilyen lehetősége.
-
Szirty
őstag
Hali!
"Lehetnek független taszkok, akkor abba kell a "kritikus" bemenetem beolvasását belerakni."
Csak arra kell vigyázni, hogy ilyenkor a fizikai bemenetet kell olvasni (erre külön módszer van ugye), mert a hagyományos input olvasás nem a fizikai bemenetet olvassa, hanem a "process image" táblát, ami akkor is csak normál PLC ciklusonként frissül, ha egy bemenetet 10 gyorsabban olvasunk (hagyományosan).
-
Szirty
őstag
Hali moseras!
"Hogy direktben hogy lehet portot olvasni, azt még nem tudom."
Az teljesen típusfüggő!
Rendszerint speciális utasítás vagy speciális memóriaterület elérésével lehetséges (esetleg sehogy némyelyik típusnál).Omron CS1 esetén pl. IO REFRESH (IORF) avagy FUN(097)
S7-300/400-nál PIW olvasás -
Szirty
őstag
Hali moseras!
"Ez így jól hangzik, de mi van akkor, ha el kell indítanom valamit 17:40:28-kor, és az RTC-t olvasó taszk mondjuk 17:40:27 legvégén olvasott be értéket"
Ha te végzed az idő bekövetkeztének a figyelését, akkor ezt a problémát elkerülheted, ha az idő összehasonlítását (beállított és az óra) nem egyenlőségre vizsgálod, hanem nagyobb relációra és erre teszel egy él figyelést.
Vagyis ha az RTC-ből olvasott idő nagyobb mint a beállított, akkor bebillentesz egy bitet. Ezt a bitet figyeli a programod, hogy mikor változik 0-ról 1-re.
Ennél csak arra kell figyelni, hogy ha állítják az RTC-t, átállás van téli nyári időszámításra, vagy a beállított időt állítják úgy, hogy az állítás következtében teljesül a feltétel, akkor is "jelezni" fog.Ha az idő figyelését a rendszerre bízod, akkor nyilván rajta múlik hogyan kezeli az ilyen esetet. Mint pl. S7-nél vannak timer interruptok (beállított időpontban meghív egy blokkot).
"Ha van n darab taszkom, amik egy közös GLOBAL területen lévő változót írnak/olvasnak (mint pl. az előbb), akkor mi a megoldása annak, hogy az olvasó taszk csak akkor nyúljon bele, ha az író taszk már végzett az írással"
Ez nagyon rendszerfüggő.
De szerintem nem kell ezzel as problémával számolni, mivel a több taszk ellenére is csak egy dolgot képes elvégezni egy időben. Tehát amikor éppen ír, akkor biztos hogy nem fog olvasni, és viszont.
Ha az írás/olvasás több adatot érint amely hosszabb idő és elvileg megszakítható, akkor csak onnan kapsz választ a kérdésedre ha megnézed az adott rendszer timing dolgait. S7-hez van ilyen, nem tudom wagohoz van-e. Ebben le van írva hogy minek mekkora a prioritása és mi mit képes félbeszakítani és mit nem.Szerintem két taszk nem egymástól teljesen függetlenül aszinkron módon fut.
Nekem akkor volt ilyen jellegű problémám, amikor operátorpanellel kellett kommunikálni (PLC JOB-ok futtatása a panelen). De ott voltak szemafor jellegű jelzések, amivel lehett koordinálni nikor ki írjon. -
Szirty
őstag
Szevasz moseras!
"Gondolom ez egy FLASH alapú eszköz, ha én ezt folyamatos naplózásra használnám, akkor ez nem fog behalni 100k-200k írás után ?"
S7-nél alapból nincs kifejezetten olyan, hogy file rendszer.
A háttértárat inkább memóriaként kezeli nem file-szerűen.
A programot FLASH memóriában tárolja. Legalábbis az újabb típusok, a régebbiek háttértelepes RAM-ban, de most maradjunk a FLASH-es verziónál.
Szerintem úgy megy, hogy amikor elindul a PLC, akkor mindent betölt a FLASH-ból RAM-ba (aminek nincs háttértelepes tápja) és üzem közben csak a RAM-ot használja. Abba írja az adatokat és abból is olvassa. Amikor elmegy atápfesz, akkor a RAM teljes tartalmát kiírja FLASH memóriába. Persze úgy, hogy a CPU értesül a tápfesz megszünéséről, de ő maga pufferről néhányszáz ms ideig még üzemel, amennyi idő alatt iztonságosan kírja a RAM tartalmat.
Ha tényleg így van, akkor ebből az következik, hogy teljesen mindegy hogy programból milyen gyakorisággal írsz adatokat."A másik kérdésem, hogy ha otthonról frissítem a PLC progiját (router-en VPN+dyndns beállítva), és mondjuk a feltöltés közepén beüt valami krakk, akkor mi lesz a PLC-vel ?"
S7-nél ez úgy megy, hogy a feltöltés alatt lévő blokk semmilyen szerepet nem kap mindaddig, amíg a feltöltés teljes egészében és sikeresen be nem fejeződött. Amíg ez meg nem történik, a régi változat fut, ami feltöltés előtt is benne volt.
Ezért ha a feltöltés megszakad vagy adathiba következik be, a feltöltött adatok nem jutnak szerephez.[ Szerkesztve ]
-
Szirty
őstag
Hali moseras!
"Van egy SysLibFile.Lib, benne open(), close(), seek(), delete(), meg minden egyéb FUNCTION-ban."
Jut eszembe: Omron CS1G-nél használtam ilyet. Ott van file szintű hozzáférés és éppen logra használtam.
Valószínű, hogy ott minden írás ténylegesen a flash-re ment. Tehát hosszú távon tönkreteszi. De ha nem ms-enként kell bele írni, akkor 10 év is eltelhet mire probléma jelentkezik. Az említett gép minden munkafolyamat közben méréseket végzett és ezek eredményeit írta ki CSV file-ba CompactFlash kártyára. 10-20 mp-enként írt egy-egy adatcsomagot. Kb 8 éve megy, amennyire tudom nem kellett még CF kártyát cserélni (nem is lenne egyszerű, mert néhány MB-os a mérete).Nyilván egy 2GB-os flash memóriát nem tud 512k RAM-ban tárolni, hogy ne a flasht cseszegesse íráskor.
De azt megteheti, hogy úgy működik mint a write cache memória: Olvasni a flash-ről olvas (vagy a RAM-ból ha változott már) de írni a RAM-ba ír. Így a RAM csak a változásokat tartalmazza, nem az egész filerendszert. Ha meg nagyon nagy mennyiségű adatot ír, akkor úgy sincs mit tenni, ki kell írni üzem közben is néha."Hopp, itt egy kérdésem lenne: van olyan speciális pufferes modul bármilyen PLC-hez, ami annyit pufferel, hogy 2-3 SMS-t is el tudjon küldeni ilyenkor ?"
Ezt így konkrétan nem tudom, de könnyen megoldható a dolog egy aksival. :]
-
moseras
tag
Sziasztok
"Szükségem lenne egy újraindítható timer-re."
Magamnak válaszolok:
A TIME() függvényt kell használni, ezzel a PLC indulása óta eltelt időt kapom meg msec-ben. Erre lehet már timer-t építeni, pl. így:
FUNCTION_BLOCK TP_X
VAR_INPUT
IN : BOOL;
PT : TIME;
END_VAR
VAR_OUTPUT
Q : BOOL;
ET : TIME;
END_VAR
VAR
edge : BOOL;
start : TIME;
tx: TIME;
END_VAR
(*
version 1.2 19. oct. 2008
programmer hugo
tested by oscat
retriggerable edge triggered pulse similar to TP but with a retrigger function
if the pt input is 0 then output is always low.
*)
(* @END_DECLARATION := '0' *)
(* read system_time *)
tx := DWORD_TO_TIME(T_PLC_MS());
(* rising edge trigger *)
IF in AND NOT edge THEN
start := Tx;
IF pt > t#0ms THEN Q := TRUE; END_IF;
END_IF;
edge := in;
IF q THEN
et := Tx - start;
IF et >= PT THEN
Q := FALSE;
et := t#0ms;
END_IF;
END_IF;
(* revision history
hm 4. aug 2006 rev 1.0
original version
hm 17. sep 2007 rev 1.1
replaced time() with T_PLC_MS() for compatibility reasons
hm 19. oct. 2008 rev 1.2
renamed to TP_R to TP_X for compatibility reasons
*)
END_FUNCTION_BLOCKForrás:
[link]Imi.
-
moseras
tag
Sziasztok
Ha valakit érdekel, megkérdeztem a WAGO PLC-ben lévő FLASH-t:
Igen, filerendszer van benne, a 750-841-ben 1.5M a flash mérete. Lehet használni változók mentésére és/vagy naplózásra. A magyar forgalmazók szerint a németek sem tudtak egyértelmű választ adni arra, hogy mekkora az max. írásszám, javasolt a minél ritkább írás. Mióta forgalmazás van, azóta 1db PLC-ben szállt el a FLASH, a sok naplózás miatt, de az nem 841 volt, hanem valami más.
Imi.
-
Atok79
csendes tag
-
Szirty
őstag
Helló!
"Ha van 30 millió min. kapcsolásszámú relém (ez 7.5 év 8 másodpercre), akkor azzal kapcsolhatom őket probléma nélkül ?"
Hát nem tudom. Ha a relé érintkezők átmeneti ellenállása akár csak egy kicsit is megváltozik, az eléggé meg fogja hamisítani a mérést.
Hacsak nem úgy csinálod, hogy egy áramgenerátorral az összes Pt100-at sorbakötve konstans áramot adsz nekik és a hőmérők kivezetés párjait Pt100-anként kapcsolgatod relével az A/D-re. Így a reléken nem folyik át az áramgenerátor árama és csak feszt kapcsolgatnak, aminek eredményeképp az átmeneti ellenállás sokkal kevésbé befolyásolja a mérést. Nem tudom érdemes-e ilyesmivel kísérletezni. Az amatőr megoldások rendszerint megbosszulják magukat az iparban..."A másik kérdésem, hogy Pt100 helyett "NTC 20k"-t alkalmazni (0,5C pontossagra van szukseg 0-+30 tartomanyban) helyes e ? És melyik olcsóbb ?"
NTC szerintem sokkal olcsóbb.
Ilyen pontossághoz én Pt100-at használnék. Annak ismert (szabványos) a jelleggörbéje. Ezért könnyebb linearizálni. Az NTC esetében nem tudom ugyanez hogy menne. Esetleg jó sok méréssel fel lehet venni a görbéjét és annak alapján linearizálni. De kérdés marad mennyire egyformák ezek. Ha nem, akkor több mérés esetén mindegyiknél egyenként fel kell venni a görbét és megcsinálni a linearizálást, továbbá ha esetleg tönkre megy és cserélni kell... -
And
veterán
Pt100 vs NTC kérdéskör: én is úgy tudtam, hogy az NTC-k nincsenek szabványosítva. A Testo oldalán viszont ebben a pdf-ben azt írják, hogy a jelleggörbék és a tűrések szabványosak. Sőt, a -25...+75°C tartományban használatos 'alapkivitelű' NTC-k pontossága 0,2°C, amely még az A-osztályú Pt100 érzékelőknél is jobb. Aztán a 2. oldalon meg már ezt említik: "Az NTC mérési adat
felvevõkre/felfogókra nem vonatkozik szabvány.". Szóval érdekes..
Nem is tudom, hogy használnak-e tömegesen NTC-t az iparban. Én már kénytelen voltam 1-2 alkalommal egyedileg lekalibráltatni (szerencsére cégen belül) tizenvalahány darabot, és lineáris interpolációval közelíteni a köztes értékeket. Az nem ipari alkalmazás volt, és az ellenségemnek se kívánom ezt a módszert
, de az adott áramkörbe muszáj volt NTC-t tenni. Tény, hogy vannak szabványos jelleggörbék, melyek az adott típus 25°C-ra vonatkozó (egyébként sajnos sok százalék alaptűrésű) értékére szorzószámokat adnak meg, amelyekkel kiszámítható az adott fajta ellenállása egy bizonyos hőmérsékleten. Itt látható egy ilyen, Epcos-gyártmányú NTC-khez kiadott szorzótábla: [link]. Ahhoz képest, hogy direkt ismert típusú (és ezzel elvileg megadott karakterisztikájú) példányokat szereztem be, a kalibrálás szerint a mért adatok jelentős eltérést adtak az adatlap alapján kiszorzott elméleti értékekhez viszonyítva. Tehát hiába az elméleti pontosság meg az adott karakterisztika, szerintem is jobban jársz, ha a Pt100-nál maradsz. A Pt100 nem olcsó, de azt a tökölődést senki sem fogja megfizetni, amit az NTC-ket választva kellene megcsinálnod. -
-
#718
adamtoth91
csendes tag
moseras
#717
adamtoth91
csendes tag
Hát ezek télleg nem olcsók. Köszi a segítséget de olcsóbban szeretném megúszni. Találtam egy laptopot ami van LPT port és most erre keresem a megoldásokat. Egy programot keresek amejjel tudok vezérelni 8 darab relét. Ennyi nekem pont elég lenne csak nem találok sehol se ilyen programot. A két gép összekötését interneten keresztül hár félig megoldottam. Már csak egy progi kellene amivel billentyűzeten keresztül tudom kapcsolgatni a reléket. Ezek a dolgok amiket írtok túl bonyolultak nekem. Fogalmam simcs hogy hogy kell használni őket és most nem nagyon futja rájuk. Mindenféleképpen LPT porton keresztül szeretném megoldani. Ha nem jön össze akkor halgatok rátok és megpróbálok összehozni egy olyan rencert amit ti mondtatok.
[ Szerkesztve ]
-
Szirty
őstag
Hali moseras!
"Ráteszed őket a PID (illetve ami épp kell) blokk bemenetére. Nem ismerem a te rendszeredet, de nyilván van PI(D) blokk, aminek van P, I, D bemenete"Lehet hogy félreértettem valamit, de kell ide PID?
Egyszerűen csak összes kell hasonlítani a "fenéknyomás mérő" által szolgáltatott jelet (ami nyilván arányos a tartály ill. kút szintjével) egy előre megadott értékkel és kész... -
Szirty
őstag
Hali moseras!
"Ezt a gyakorlatban hogy szokták ? Ha a tartályban B felett van a szint, akkor nem engedik a szivattyút működtetni, függetlenül a kút vízének szintjétől ?"
Hát ez nagyon függ attól, hogy tulajdonképpen mi is a berendezés célja. Mert a feladat kiírásban erről nem tettek említést (csak azt írták le mit csináljon a program, ami vezérli).
Ha pl. a berendezés célja az, hogy mindig legyen víz a tartályban, akkor nyilván meg kellene állítani a szivattyút ha a tartály szintje "B" vagy magasabb
De ha az a célja, hogy a kútban ne lehegyen túl sok víz ("A" fölött) akkor nem kell leállítani a szivattyút. Viszont ilyenkor is kérdés marad, hogy az általam felvetett esetben mi történik
-
moseras
tag
válasz
moseras
#1039
üzenetére
Üdv!
A probléma megoldódott, ha valakit érdekel:
1. az S3 paraméternek nem volt kezdeti értéke
2. a D8030 és D8031 nem használható közvetlenül a PID_M funkcióhoz (át kell tenni őket másik regiszterekbe)Mindez úgy oldódott meg, hogy a MITSUBISHI support az itteni hozzászólás után megkeresett email-ben, és néhány levélváltás után elkérték a projektfile-t, és ki is javították.
Köszönet érte.
Imi.
-
#2759
Royality20
csendes tag
moseras
#2758
-
miclucky
tag
válasz
moseras
#3167
üzenetére
hali, köszi,de
amikor bővítettem a programot és deklaráltam a váltózót(kat), nem adtam hozzá M-es címet(address mező üresen hagyva),csak IW-t, igaz egyiknél bepipáltam a Retain-t .....és csinálta a hülyeségeket. Lehet ha nem adok meg address-nek semmit, akkor is hozzárendel egy M-es változót?
vagy olvastam ilyesmit, hogy Diagnostic Address: %MB .
(próbáltam a reset original-t, de nem segített)Az összes M-es változót feljebb címeztem 200-al(MX0.1 ->MX200.1) és jó lett.
Lucky
-
sörösló
aktív tag
válasz
moseras
#3284
üzenetére
Csak egy megjegyzés: Épületgépészek mondják, hogy a víz-víz hőcserélőknél a 20 C° különbség az ideális. Mindenképpen javasolnék ez esetben épületgépész konzíliumot! Nem vicc! Ez egy külön szakma, megvannak a maga szabályai és speciális szakmai ismereteket kíván. Ugyanúgy mint a PLC programozás. Esetünkben az épgép szakinak kell megmondania hogy mit szeretne, mi meg megmondjuk hogy ez hogyan lehetséges.
"Biztosan van beépített védelme, így ha a szivattyú valami miatt leáll, a kazán akkor sem fog felrobbanni."
Biztosan??? Gázkazánnál egyszerű, de vegyinél az előremenő vízágban visszahűtést kell alkalmazni! Fel kell készíteni a rendszert arra az esetre, ha megszűnik hirtelen az áramszolgáltatás!
"Keverőszeleppel az előremenőt szokták azonos értéken tartani"
Meg a vegyikazánoknál az előremenő és a visszatérő ág közötti hőfokkülönbséget szintén az említett 20 fokos lépcsővel. Ha túl nagy a különbség, megrepedhet a kazántest. Ha pufferre dolgozik, az csak tovább bonyolítja a dolgokat. Nem egyszerű az élet, de a robbanásveszély miatt nem lehet "tegyük fel" tényezőkkel operálni! Vagy fehér, vagy fekete. Nincs olyan hogy ha napkeltekor megszólal a feketerigó akkor megnézzük tüsszent e a kutya és ha igen akkor minden OK.
[ Szerkesztve ]
-
-
sörösló
aktív tag
válasz
moseras
#3576
üzenetére
Én nem gondolnám hogy ez olyan nagy probléma. Sok-sok automata mintavevőt telepítettünk terménytárolókba. A szekrényt nyáron süti a nap, télen kint van a mínuszokban, ráadásul nincs is a legtöbbje állandóan bekapcsolva. Van benne egy LOGO meg két frekiváltó, relék, mágneskapcsolók,tápegység meg minden. A körülmények szabadtériek, tehát elég mostohák, ennek ellenére nagyon ritka a meghibásodás. Van egy desztillálóberendezés vezérlésem is hasonló körülmények között. Hétvégén kikapcs, hétfőn reggel a -20 fokban bekapcs és vígan teszi a dolgát.
Szintén LOGO, kb. 7 éve csináltam, azóta sincs semmi baja. Vagy kissé túlmisztifikált ez a hőmérsékletdolog, vagy a LOGO ennyire jó
![ Szerkesztve ]
-
-
#3811
mediumgecso
őstag
moseras
#3809
-
#3821
Hasaggymeg
veterán
moseras
#3818
Hasaggymeg
veterán
válasz
moseras
#3818
üzenetére
Mi most azzal küszködünk,hogy egy pàr perces, esetleg óràs àramszünet is hazavàgja öket,söt,még làtszólag ez nélkül is megàll óràjuk vagy elveszítik ip címüket.El sem lehet indítani as óràt bennük,màr a német gyàrtóhoz küldtünk kettöt és vàrjuk visszajelzésüket.
...ez mind akkor kezdödött mikor a lemerült szünetmentes tàpokat anyagi megfontolàsból kiiktattuk."Végy egy kerékpárt,nem fogod megbánni...feltéve ha életben maradsz."Samuel Langhorne Clemens link: https://cdn.rios.hu/dl/upc/2024-02/02/91209_d2j2gi0v6zwls7lx_1000006503.jpg
"
, de az adott áramkörbe muszáj volt NTC-t tenni. Tény, hogy vannak szabványos jelleggörbék, melyek az adott típus 25°C-ra vonatkozó (egyébként sajnos sok százalék alaptűrésű) értékére szorzószámokat adnak meg, amelyekkel kiszámítható az adott fajta ellenállása egy bizonyos hőmérsékleten. Itt látható egy ilyen, Epcos-gyártmányú NTC-khez kiadott szorzótábla: 
!
