Új hozzászólás Aktív témák

• #483 Szirty őstag moseras #481

  Új Válasz 2008-10-03 20:42:12 #483

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Szirty

  őstag

  válasz moseras #481 üzenetére

  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.

• #482 Szirty őstag moseras #481

  Új Válasz 2008-10-03 20:29:28 #482

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Szirty

  őstag

  válasz moseras #481 üzenetére

  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)...

Új hozzászólás Aktív témák