Keresés

Hirdetés

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

  • Szirty

    őstag

    válasz KB.Pifu #3929 üzenetére

    Üdv Pifu!

    Itt csak a módszer kérdés, nem a megvalósítás.
    Ha már sorba van rendezve, akkor csak meg kell számolni mennyi egyforma van egymás után. Ha a darabszám mellé rögzíted azt is melyiket számoltad, akkor mire a végére érsz tudni fogod melyikből van a legtöbb ha így csinálod.
    Elég kettőt nyilvántartani. Az egyik az előző, a másik amit éppen számolsz. A számolás végén, ha az kevesebb mint amit rögzítettél eldobod. Ha több, akkor felülírod az előzőleg tároltat.

    De az automatizálás főleg nem ilyen feladatból áll.

  • Szirty

    őstag

    válasz KB.Pifu #3978 üzenetére

    Üdv KB.Pifu!

    "Ezzel nem egyenértékű a SLD 4 használata?"

    A program működése szempontjából teljesen egyenértékű.
    Mégis a "szószátyárabb" megoldást szoktam használni (és javasolni), mert így olvashatóbb a kód és kényelmesebb a felhasználása.
    Ha pl. nem INT típust akarok címezni, hanem DINT-et, akkor csak átírom a szorzást 4-re. Ha byte-ot, akkor kiveszem a szorzást és a Load-ot. De a pointernél mindig ott marad az SLD 3.

  • Szirty

    őstag

    válasz KB.Pifu #3995 üzenetére

    Üdv KB.Pifu!

    Tehát. Ez egy buborék algoritmus. Két ciklusból áll. A belső (LOOP) a tömb végétől at elejéig lépked végig. Ha az indexelt érték (amire a ciklusváltozó mutat) nagyobb, mint az őt követő, akkor felcseréli a kettőt.
    Ezt a ciklust egy külső ciklus tartalmazza, ami addig ismétlődik, amíg volt csere.

    A #Sort_done egy boolean, amit annak jelzésére használ, hogy a belső ciklus végigfutása során volt-e csere.
    Ha nem volt, akkor a rendezés kész és kilép (a külső ciklusnak ekkor van vége).

    A #Sort_done változót minden alkalommal a belső ciklus elején TRUE állapotba állítja be a

    SET
    S #Sort_done;

    Utasításokkal. Amikor adatcserét hajt végre a ciklusmagban, akkor a #Sort_done-t FALSE állapotúra állítja az

    SET
    R #Sort_done

    utasításokkal. Így amikor a ciklus lefut, a #Sort_done TRUE lesz ha nem volt adatcsere és FALSE lesz ha volt. Ezért a külső ciklus kilép ha a #Sort_done TRUE, mert akkor a rendezés készen van.

    Az RLO-t azért kell SET-be állítani, mert az S #Sort_done utasítás feltételes. Avagy a #Sort_done csak akkor kerül TRUE állapotba, ha az RLO is TRUE! egyébként nem nyúl hozzá. Az R #Sort_done szintén feltételes, csak akkor törli a #Sort_done-t, ha az RLO TRUE!

    Mindez kiderül az S és R utasítások leírásából is.

    Description of instruction

    "S (set bit) places a "1" in the addressed bit if RLO = 1 and the switched on master control relay MCR = 1. If MCR = 0, the addressed bit does not change."

    A bit feltétel nélkül így állítható meghatározott állapotba.
    De így is:

    SET
    = #Sort_done

    vagy

    CLR
    = #Sort_done

    Én ezt a változatot szoktam használni, mert (nekem) beszédesebb.

    "azért büszkén mondom, hogy magamtól rájöttem, m003 után az AR-t egyszerűbben is lehet növelni"

    Elárulod nekünk a módszeredet? :-)

    [ Szerkesztve ]

  • Szirty

    őstag

    válasz KB.Pifu #4004 üzenetére

    Szevasz KB.Pifu!

    "Megmondom őszintén azt hittem a SET a program lefutásában valami magasabbrendű kulcspozíciót játszik"

    Semmi gond! Majd lesz olyan ami magasabb rendű kulcspozíciót játszik, csak annak nem fogsz jelentőséget tulajdonítani. :-)
    Ez egy ilyen történet és tanulás a neve. Mindenki aki ért hozzá átesett rajta. Vagy ha az jobban hangzik: mindenki aki átesett rajta ért hozzá.
    Vagy ha az mégjobban hangzik: szívás nélkül nincs tudomány.

    Az F1 nyomkodása persze hasznos, de rendszerint az összefüggések erdejében még a help mellett is magunknak kell eligazodni. Na ebben szívesen segítünk szerintem.
    Mellesleg a help idézetet nem célzásnak szántam, hanem a mondandóm alátámasztásának.

  • soldi3r

    veterán

    válasz KB.Pifu #4007 üzenetére

    En kicsit mas teruleten dolgozom jelenleg (SMT), nalunk az elektromos hibak teszik ki az allasido 70%-at.
    De pl PLC hibank talan 1x vagy 2x volt.

    [ Szerkesztve ]

    E30 (oo=[][]=oo)

  • Szirty

    őstag

    válasz KB.Pifu #4033 üzenetére

    Helló KB.Pifu!

    Nem hiszem hogy erre a kérdésedre lehet olyan egyetemes választ adni ami egyértelműen és univerzálisan cáfolja vagy alátámasztja valamelyik megoldást.
    Egy kód megírásánál nagyon sok szerepet játszik a program írójának ismerete, beidegződései (szokásai) motivációi (pl. hogy akarja-e hogy más megértse a kódot, vagy az a célja hogy érthetetlenné tegye).

    A programozásban egyes feladatokra (főleg a komplex feladatok részleteit nézve) rengeteg alternatív és egyformán jó megoldás születhet. Persze vannak kifejezetten rosszak is.
    Néha nehéz eldönteni melyik a jobb. Meglepő lehet, de a dolog részben szubjektív is.

    Bizonyos (programozástechnikai) szempontból (ha van ilyen egyáltalán) a +AR1 P#2.0 összehasonlíthatatlanul elegánsabb mint az, hogy újra és újra kiszámoljuk a pointert a ciklusváltozó aktuális értékéből. A legtöbb feladat szempontjából azonban jelentéktelen részletkérdés és mind a kettő egyformán megfelel. Az hogy "demoscene" alkalmából fejlövés járna az utóbbihoz hasonló megoldásért szintén érthető a "demoscene" szempontjából egyértelmű.

    A cél is fontos, nem csak a megoldás ami oda vezet :-)

  • Szirty

    őstag

    válasz KB.Pifu #4039 üzenetére

    Üdv KB.Pifu!

    Ha az N alatt a táblázat indexét érted, akkor úgy, ahogy az általad idézett kódban is van, vagyis relatív ofszettel.

    A hivatkozott kódban ez a rész tartalmazza:

    Loop: T #Count //FOR INDEX = Count TO DB_length
    L W [AR1,P#0.0] //IF M(INDEX) > M(INDEX+1) THEN
    L W [AR1,P#2.0]
    <=I

    És ez is:

    L W [AR1,P#2.0] //LET M(INDEX) = M(INDEX+1)
    T W [AR1,P#0.0]

    Itt egy példa még:

    OPN DB 2
    L P#DBX 6.0
    LAR1
    L DBW [AR1,P#0.0]
    T MW 0
    L DBW [AR1,P#2.0]
    T MW 2

    Ez a DB2.DBW6 tartalmát MW0-ba rakja, a DB1.DBW8 tartalmát pedig MW2-be.

  • Szirty

    őstag

    válasz KB.Pifu #4041 üzenetére

    Üdv KB.Pifu!

    Sajnálom, de nem világos teljesen mit szeretnél. Igazából a feladat egésze nem világos, mert csak egészen apró részletekkel szolgálsz.
    Volt már szó sorbarendezésről, meg egy adathalmazban a legnagyobb érték kereséséről is. (Azt sem értettem teljesen, a legnagyobb érték kereséséhez nem szükséges sorbarendezni az adatokat).

    "Én a #counter értékét szeretném menteni, ugye ha talál pár egyforma számot akkor azt növeli, de ha ==I -ra nem talál egyenlőséget akkor jelenti azt, hogy az érték megváltozott és nullázni valamint menteni kell hogy a következő alkalommal mikor szintén 0 az RLO az össze tudjam hasonlítani."

    Itt most egy DB-ben egymást követő értékeket hasonlítasz össze egymással ha jól látom.
    És számolod hány eltérés volt az egymát követő adatokban? ha egy sem, akkor az egész DB ugyanazt az értéket tartalmazza végig. Tenni akarsz valamit, ha két egymást követő érték eltér?

  • Szirty

    őstag

    válasz KB.Pifu #4043 üzenetére

    Helló KB.Pifu!

    Nem akarok túl gyakran vak vágányra futni, így most csak rövidet írok.
    Az RLO a logikai művelet eredménye.
    Mindegyik logikai műveleté! Mindig!

    Csak nehogy most meg ezen csússzunk el.

  • Szirty

    őstag

    válasz KB.Pifu #4045 üzenetére

    Üdv KB.Pifu!

    Nekem úgy tűnik, hogy abban a kódban amit idéztél ez meg van oldva.
    Mi a gond vele?

  • Szirty

    őstag

    válasz KB.Pifu #4047 üzenetére

    Üdv KB.Pifu!

    Ha van tengernyi szabad időd leírnád a kedvemért egészen a legeslegelejéről egészen pontosan mi a feladat?
    Az az érzésem ezek a töredékinformációk durván félrevezetnek.
    Ha a kérdésben te érted mi a probléma, szerintem nem elég.
    Tudod! Nem szeretek két soros kérdésre 20 oldalas válaszokat írni, hogy aztán azt írják: "ja nem erre gondoltam!"

  • Szirty

    őstag

    válasz KB.Pifu #4049 üzenetére

    Üdv!

    Ok.
    Még az jutott eszembe, hogy az összehasonlítás eredményét nem csak ugrással lehet kiértékelni, egy bitet is kapcsolhatsz vele.
    pl.:

    L W [AR1,P#0.0]
    L W [AR1,P#2.0]
    ==I
    = M1.0

  • Szirty

    őstag

    válasz KB.Pifu #4051 üzenetére

    Szia!

    Igen, STL a Siemens S5-S7 esetében a PLC "assembly-je" avagy az alacsony szintű nyelve. Minden magasabb szintű nyelv erre fordul le. Ez azonban nem indokolja azt, hogy mindent STL-ben írj, de indokolja azt, hogy az STL-t megismerd!

    Bizonyos feladatok létrában vagy FBD-ben sokkal jobban átláthatók, sokkal gyorsabban megy vele a munka és hatékonyan lehet hibát keresni.
    Konkrétan a sok logikai feltételt tartalmazó összefüggésekhez kiváló (erre való).

    Ugyanakkor más feladatra, mint pl. számítások végzése, adatok kezelése sokszor jobb az STL vagy más, magas szintű nyelv (pl. az SCL). Ezeket is meg lehet csinálni létrában, de ott meg ez lesz nehézkes és nehezen átlátható.

    Az STL/LAD illetve STL/FBD nyelveket egy blokkon belül is váltogathatod. (TIA portálnál már nem).

    "Mondjuk letöltök a PLC-ről egy programot, amit valaha ladderban írtak, azt minden esetben vissza lehet alakítani?"

    Ha létrában írták és nem pancsoltak bele STL-ben akkor ezt meg tudod jeleníteni létrában. Ám az STL-ben készült blokkokat nem, vagy csak ritkán lehet létrában megjeleníteni (aez attól függ hogyan írták meg).

  • byte-by

    tag

    válasz KB.Pifu #4063 üzenetére

    halo !

    " melyik legyen a következő? "
    ne már.
    nem kell mindet tudni, nem is lehet. (persze biztos van olyan elvetemült alak...)

    a bináris változókon vagy I/O-kon alapuló logikai kapukat és összefüggéseket nézve nincs különbség a plc-k között.
    a memória , adatkezelésben, utasításkészletben, adatformátumban és azok felhasználásában akár nagy különbségek is lehetnek valamint a fejlesztő környezetben, hálózatokban, HMI-kben, stb.

    elkezdted a siemens? akkor ne hagyd abba.
    vagy ha azt mondod , hogy japán (vagy japán közeli ) cégnél dolgozol, akkor ásd bele magad az omron-ba.
    próbáld elérni, hogy odaengedjenek a gépekhez, laptoppal, vagy hasonló módon. esetleg egy okos módosító javaslat, ilyesmi.(nem mindenhol szeretik, de én is dolgoztam japán cégnél, ott a pozitív hozzáállás jó pont volt)

    mindegy , csak ne mindenből egy kicsit. az nem lesz jó.
    és nem holnapra fog menni, meg holnaputánra sem.

    by-te

    [ Szerkesztve ]

  • Szirty

    őstag

    válasz KB.Pifu #4063 üzenetére

    Helló Pifu!

    Nos nekem van pár ötletem.
    De az a helyzet, hogy egy megoldásnak akkor látjuk értelmét, ha ismerjük a problémát is.
    Márpedig egy feladat megoldásához nem szívesen kezd az ember ha nem látja értelmét a megoldásnak.
    Az én válaszom vonatkozásában ott lesz a baj, hogy szinte csak címszavakban tudok itt gyakorlatias feladatokat felvázolni, mert a részletes ismertetése oldalakba és órákba kerülne.

    De azért felsorolok párat ami eszembe jutott.

    - Kapcsoló óra funkció (több időre beállítható ki és bekapcsolással (nap, óra perc, esetleg havi, heti ismétlés)

    - Képzelj el egy szalagrendszert, ami úgy fest, hogy szállító szalagok egymásnak adják át a szállított anyagot. Egyik hordja a másikra. A feladat olyan üresre járatási funkció, ami felfüggeszthető, vagyis ha a kijáratási művelet alatt valamilyen okból megállítják a szalagokat, akkor újra elindítva a kijáratás folytatódik (nem marad abba és nem kezdődik elölről).

    - Legyen egy célgép, ami munkadarabokat munkál meg. Számold a munkadarabokat és jelenítsd meg HMI-n úgy, hogy látható legyen melyik órában hány darab készült. Ábrázolhatod oszlop grafikonon is. Esetleg megtoldható azzal, hogy a munkadarabok elkészítése közötti időt méri és ezeket ábrázolja. Az ilyesmit egyszerűen imádja az üzemvezetés :-)

    - Berendezéseknél gyakori a kenőanyag szivattyú és a hozzá tartozó kenőanyag áramlás vagy olajnyomás kapcsolóval ellenőrzött kenés. ha megy a szivattyú és x ideig (néhány mp) nem jön jel a nyomás (vagy áramlás) érzékelőről, akkor leáll hibával a gép. Ez ok. De készíts olyan ellenőrzést, ami ezen felül a nyomás (áramlás) érzékelő hibáját is felderíti. Ha a szivattyú x ideje áll, de a nyomás (áramlás) érzékelő érzékel, akkor érzékelő hibát kell jeleznie.

    - Készíts olyan blokkot, ami analóg bemenetről érkező (0-27648) értéket beállítható fizikai mennyiséggé skáláz. Pl. ha az analóg bemeneten egy 200 bar-os távadó van, akkor a 0-27648-at alakítsa 0-200 tartományra. Ilyesmire gyakran van szükség.

    - Valósíts meg az előző blokkal (vagy azt egészítsd ki) olyan küszöb érték kapcsolót, aminek állítható hiszterézise van. Tehát beállítasz 114 bar nyomást, az legyen a hiszterézis tartomány fele. Ha a mért érték átlépi hiszterézis tartomány tetejét, akkor kapcsoljon be egy bitet, és csak akkor kapcsolja ki, ha a mért érték a hiszterézistartomány alja alá esik.

    - Készíts üzemóra számlálót, ami valaminek a működési idejét méri. A számláló tartalma órában vagy tized órában legyen elérhető. De a számláló legyen képes a nagyon gyakori (néhány másodperces) szakaszos üzemű jel mérésére is!

    - Csinálj olyan hibajelző rendszert, ami hang és fényjelzést ad. ha hiba keletkezik, világítson egy visszajelző lámpa és szóljon egy kört. Legyen egy nyugtázó gomb, amivel a kürt elhallgattatható.
    A lámpa világítson amíg a hibajelzés meg nem szűnik. Ha a hibajelzés a nyugtázás nélkül szűnt meg, a hibamentes állapot is hallgattassa el a kürtöt. Ha van hibajelzés és a kürtöt nyugtázták (elhallgattatták) de a hiba nem szűnt meg viszont egy újabb hiba keletkezik, a kürt szólaljon meg ismét. Legyen legalább 32 egymástól független hibajelzés kezelésére alkalmas.

    - Készíts olyan programot ami egy gépen lévő mágneses reteszelésű ajtónyitó biztonsági kapcsolót kezel. A biztonsági kapcsoló ajtó nyitó elektromágneses reteszkioldását egy kimenet kapcsolja be. Amikor a kimenet aktív, a retesz kioldódik és az ajtó nyitható. Az ajtó nyitva helyzete egy bemenetre is vissza van vezetve. Az ajtó mellett van egy ajtó nyitás kérő világítós nyomógomb. A kezelő a gomb megnyomásával kéri az ajtó nyitását a géptől. A kérést a gomb lámpájának villogása jelezze. A kérés hatására a gép nem indít újabb műveleti ciklusokat (mozgásokat) de a folyamatban lévőket befejezi. Amikor minden mozgási ciklus befejeződött, a program oldja az ajtó reteszt és a gomb lámpája folyamatos fénnyel jelezze, hogy az ajtó nyitható. Az ajtó nyitása utáni becsukása törölje a nyitás kérést és engedje el a mágneses reteszt a következő kérésig (a gomb lámpája is aludjon ki)!

    [ Szerkesztve ]

  • Szirty

    őstag

    válasz KB.Pifu #4088 üzenetére

    Helló KB.Pifu!

    "mert nem sikerült minden Jig-et egyformára készíteni és szoftveresen kellett megoldani a hibák kompenzálását"

    Tipikus.
    Én is raktam már be timert laza lánc miatt, hagytam meghúzva szelepet szivárgó munkahenger tömítés miatt, stb...

  • Szirty

    őstag

    válasz KB.Pifu #4097 üzenetére

    Helló!

    Tulajdonképpen teljesen mindegy hogy a tervező vagy a gyártó baxta el vagy az amortizációból következik.
    Mind a két esetben mechanikus hiba szoftveres javításának esete forog fenn (alias következmény elhárítás... alias tüneti kezelés) :-)

  • Szirty

    őstag

    válasz KB.Pifu #4107 üzenetére

    Szevasz Pifu!

    Csinálhatod úgy is, hogy lerajzolod háromszor és mindegyiknek a láthatóságát kapcsolgatod egy bittel de az nem túl szép megoldás.
    Ha sok ilyen van egy screenen az körülményessé teheti a szerkesztését. Állandóan kotorászni kell az egymásra helyezett, a szerkesztőben egymást kitakaró objektumok között. vagy ha mindegyiket külön layer-re teszed az könnyíthet a helyzeten, de akkor meg a layereket kell kapcsolgatni ha módosítani kell rajtuk.

    Amennyiben a szimbólumod grafikus primitívekkel rajzoltad (kör, vonal, négyzet, stb) akkor én az animation / appearance segítségével oldanám meg a dolgot.
    Csináltam erre egy példa projectet. Két lehetőséged van:

    Egy integer változó (a példában ez MW10) van hozzárendelve egy szürke hátterű és fekete keretű téglalap animation / appearance tulajdonságánál. Az integer egyes értékeihez eltérő háttérszíneket rendeltem hozzá.

    Amikor az MW10 tartalma 1, akkor a téglalap színe piros lesz, ha 2 akkor narancssárga, ha 3 akkor citromsárga, ha négy akkor zöld. Minden más érték esetén a téglalap eredeti, tehát szürke színű lesz.
    Itt tehát az MW10 integerbe kell a PLC programban különböző értékeket írkálni a szín megváltoztatásához.

    A másik lehetőség a bitenkénti színváltás (binary appearance).
    Egy byte változó van létrehozva ami az MB12 merker byte-ra hivatkozik. Az animation / appearance itt binary-re van állítva ahogy a képen is látható. Ilyenkor a színek nem a változó értékéhez, hanem annak bitjeihez rendelődnek hozzá a következőképpen:
    Ha az M12.1 TRUE, akkor a téglalap piros lesz, Ha M12.2 TRUE, akkor narancssárga, ha M12.3 akkor citromsárga, ha M12.4, akkor zöld.
    Ennél a megoldásnál arra kell figyelni, hogy ha a megadott bitek közül nem csak egy TRUE, hanem több is, vagy a byte olyan bitje TRUE, ami nincs felsorolva, akkor a téglalap eredeti (azaz szürke) színű marad!

    Amennyiben a megjelenített szimbólumod előre megrajzolt grafika, akkor is megoldható a dolog, de teljesen máshogy. Ennek a leírásától most eltekintenék, mert túl hosszú lenne ez az üzenet...

    [ Szerkesztve ]

  • Szirty

    őstag

    válasz KB.Pifu #4121 üzenetére

    Helló Pifu!

    "Eddig azt hittem, elég ha a blokkban adok értéket mondjuk M1.0 -nak és azt a következő blokkban lekérdezem és minden menni fog szépen..."

    Ezt teljesen jól hitted, ez így is van. Ezen a hiteden miattunk ne változtass! :)
    Amit írtunk, az lokális változókra vonatozik (blokk interface részében a TEMP változók, alias L terület)
    Az M1.0 vagyis a merker terület nem lokális, hanem globális. Azokra teljesen más szabályok vonatkoznak.

  • Szirty

    őstag

    válasz KB.Pifu #4122 üzenetére

    Hi!

    "Most gondolkodtam, ha az egyik FC-ben írok egy merker bitet, amit egy másikban csak olvasok azt is in-out-ba kell tenni?"

    Ha a paramétert a blokk csak írja, akkor OUT legyen. Ha csak olvassa, akkor IN legyen. Ha írja is és olvassa is (tehát fel is használja az állapotát) akkor INOUT legyen.
    Hogy ez merker vagy nem merker az részlet kérdés, mivel a blokk belül nem "tudja" (és nem is érdekli) hogy te kívül a hívásnál az adott paraméterének milyen változóterületet adtál meg.

    "A T1-nek egyetlen ciklus erejéig 1 értékűnek kellene lennie"

    Az ilyen megoldást a timerrel kerülni kell (most már teis tudod) :-)
    Így csináld:

    A -(P)- re nincs szükség mert a timer alapból is csak egy ciklus ideig lesz TRUE (legalábbis ebben a megoldásban már igen) :-)

  • Szirty

    őstag

    válasz KB.Pifu #4125 üzenetére

    Helló Pifu!

    A kérdésed nagyon jó! :-)
    Nem kell feltétlenül dekrlarálnod, bármelyik FB OB, vagy FC blokkban felhasználhatod bármelyik merkerbitet, byte-ot szót, vagy duplaszót.

    Az, hogy a programblokkok (FC és FB) paraméterezhetőek egyetlen komoly oka van: az univerzális felhasználhatóság.
    Ezt nem feltétlenül kell kihasználni, ez csak egy lehetőség.
    Egy berendezésre úgy is lehet programot írni, hogy semmilyen paraméter átadás nem történik.

    A paraméterezhetőség lényege az, hogy univerzálisan felhasználható blokkot készíthetünk vele. Pl. egy csillag-delta indítást, egy analóg hőmérséklet mérést, vagy bármit.
    Ilyen esetben a blokkon belül arra kell törekedni, hogy ne legyen benne közvetlen címzés, a blokk minden információt az IN és INOUT paramétereken keresztül kapjon meg és az OUT és INOUT paramétereken keresztül adjon át a "külvilág" felé.

    Ha egyedi, nem univerzálisan (máshol is) felhasználható blokk készítése a cél, akkor a blokkon belül címezhető közvetlenül bármilyen merker vagy adatblokk. Ilyenkor rendszerint semmilyen blokk paramétert nem használunk (nincs IN, Out és INOUT sem).

  • Szirty

    őstag

    válasz KB.Pifu #4127 üzenetére

    Helló Pifu!

    Ilyen indokot én sem tudok (szerintem nincs is).
    Ha egy merker bitet (Mxxx.y) bekapcsolsz bármelyik blokkban, az minden más blokkban bekapcsolt állapotú lesz mindenféle deklarációs trükk nélkül is. Legyen az OB, FC, vagy FB.
    Természetesen csak akkor, ha más blokk nem írja azt a bitet.

    Ne a PLCSIM-ben keresd a hibát, az nagyon jól működik. Bár lehet benne hiba (én találtam is olyat, amikor az SFB4 IEC timer hibásan működik bizonyos PLCSIM verzióban) de sokkal nagyobb a valószínűsége annak, hogy a hibát te követted el valahol.

    Ha elküldesz egy programrészletet ami reprodukálja a jelenséget, szívesen megnézem.
    Nem lehet hogy keresztbe címzel? Pl. használod az M10.5-ös merker bitet és a programban valahol írod az MB10-et, MW10, MD10, MW9, MD9, MD8, MD7-et?

  • KLR

    csendes tag

    válasz KB.Pifu #4121 üzenetére

    Szia.

    Az az én álláspontom is, az a nap, amikor az ember lát v tanul valami újat, nem telt el hiába. Megvan a kis sikerélmény, ami pozitivvá teszi a mindennapi robotot.

  • Szirty

    őstag

    válasz KB.Pifu #4133 üzenetére

    Szevasz Pifu!

    "Keresztbecímzésben lesz a hiba, innen legalább már erre is figyelek."

    Arra bizony nagyon oda kell figyelni, mert nagyon durván lehet szívni ilyen hibával!
    Segít ezt elkerülni a keresztreferencia táblázat. De nem árt érteni amit mutat. Nem bonyolult, csak elsőre riasztó :)

    Valamivel barátságosabb (kevesebb fölösleges infót ad ha csak egy cím érdekel) a Go To Location funkció.
    A lényege az, hogy megmondja hol fordul még elő az a cím a programban. Csak azzal a címmel foglalkozik (míg a keresztreferenciában az összes benne van).
    Egy listát kapsz az előfordulásokról amiből ha választasz, akkor oda ugrik.
    Az ablakban van egy opció, aminek a neve "Overlapping access to memory areas".
    Ha azt is bekapcsolod, akkor minden olyan címet is beletesz a listába, ami átfedésben van a keresett címmel.
    Ez rendkívül hasznos!

    A probléma akkor fokozódik, ha DB címekről van szó. Azokat ugyanis el lehet érni teljes címzés nélkül is. Pl. így:
    OPN DB6
    L DBW4

    Mivel a fordító nem végez kód elemzést (nem is nagyon tehetne ilyet), nem tudja, hogy ha van egy L DBW4 az a DBW4 melyik DB blokkra vonatkozhat.
    Azonban a GoTo Location ezeknek a megkeresésére is ad támogatást.
    Ha csak a rövid címet adod meg, akkor felsorol minden olyan programsort, amiben az adott bit, byte word, dword címzése szerepel bármelyik DB-ben.
    Hogy melyikben szerepel azt pedig megmutatja (ha tudja) ha kiválasztod az adott sort:

    A probléma tovább fokozódik ha a keresett címet a program valahol indirekt módon is írja.
    Az indirekt címzéssel e a keresztreferencia és így a GoTo Location sem tud semmit kezdeni, hiszen annak jellegéből adódóan a cím csak futás közben derül ki. Futás közben egy címet pedig számtalan körülmény befolyásolhat a kódtól függően, a fordító nem tudja előre hogy a lefordított kód milyen körülmények között milyen címet fog majd kiszámítani.

  • Szirty

    őstag

    válasz KB.Pifu #4137 üzenetére

    Üdv Pifu!

    Ez a téma nagyon messzire vezet. Elképesztően sok előírás, ajánlás és szabvány szabályozza a dolgot.
    Szinte már politika az egész- Eszméletlen pénzek vannak a dolog mögött.
    Minden eszköz ami safety kb. tízszer annyiba kerül.

    Van néhány gyakorlati irányelv, ami ésszerű.
    Pl. hogy a biztonsági kör a vezérlőtől (pl. PLC) függetlenül kell hogy letiltsa a berendezés beavatkozó szerveinek (motorok, szelepek, stb) energia ellátását.
    Kivéve ha a vezérlő safety (biztonsági előírásoknak megfelel) aminek az ára kb. hússzoros.

    Hogy milyen géphez milyen biztonsági intézkedések szükségesek (két kezes indítás, fényfüggöny, redundás vagy szimpla vész kör, deadman switch, stb) az tervezés során az ún. kockázat elemzés során dől el.

    "Nagyobb teljesítményű gépeknél kétkezes indítás van, azt kötelező biztonsági relével megoldani, vagy azt vezérelheti a plc?"

    Biztonsági funkciót csak safety képes PLC láthat el. Ha a PLC nem az, akkor a kétkezes indításhoz kétkezes indításra való biztonsági relé kell (tízszeres ár, a safety PLC-s meg még többszörös).

  • n0rbert0

    senior tag

    válasz KB.Pifu #4139 üzenetére

    Szia!

    Így van.
    Ezeknek a reléknek általában van egy bemenete amire jelet adunk, ha megszűnt az e-stop állapot.

  • Szirty

    őstag

    válasz KB.Pifu #4139 üzenetére

    Üdv Pifu!

    Igen a biztonsági reléről természetesen lehet (és többnyire kell is) információt visszavezetni a PLC-be, hogy az intézkedni tudjon ilyen esetben (üzenet megjelenítése, technológiai (nem safety) beavatkozások elvégzése stb.).

    A dolognak egyéb folyományai is vannak. Pl. ha terepi buszos hajtásvezérlők betáplálását választja le a1 biztonsági relé, akkor az eszköz eltűnik a buszról, aminek további következményei lehetnek. Ezzel is foglalkozni kell. Amire több lehetőség is van.

  • Szirty

    őstag

    válasz KB.Pifu #4143 üzenetére

    Üdv Pifu!

    "Szerintem a legfontosabb témát sikerült kiválasztanom, mert amíg a safety nincs a helyén addig semmi sincs."

    Bizonyos szempontból. Konkrétan a hatósági ellenőrök, a munkavédelem szempontjából.
    Egyébként meg az a lényeg, hogy a gép termeljen. És ezt most csupa nagy betűvel. BÁRMI ÁRON!

    Na ezzel a kettővel kell kezdeni valamit "a életben".

  • byte-by

    tag

    válasz KB.Pifu #4143 üzenetére

    halo !

    a gépépítés tényleg jó.izgalmas meg minden.de egyvalami nincs : idő.gyakorolni se.

    én dolgoztam ilyen cégnek, fura volt, hogy néha lassan indult be egy-egy projekt, majd valahogy hirtelen nagyon sürgőssé vált és tegnapra kellett a gép.
    plusz a módosítások módosításának a módosítása ,mielőtt módosítanánk a módosításokat.
    sok plusz kérés, stb.

    sokszor egy termelő sor beépülő gépállomását csináltuk meg, azt például csak vasárnap lehetett installálni , de az éjszakás műszakra már termelnie kellett.
    vagy meglévő berendezést kellett bővíteni, átépíteni és erre csak szombat és vasárnap estig volt lehetőség.
    hányszor, de hányszor kértem csak 15 percet, hogy lássam mi történik , hogy dolgozik a gép amit módosítani, átépíteni, stb. szeretnénk.vagy bujkáltam a dolgozók között, lábuk alatt.legjobb barátom a szünet volt, amikor a dolgozók kimentek 10-15 percre.

    volt olyan vasárnap, hogy épp végeztünk egy géppel, beépítettük a sorba.jó is lett.
    egy másik gépet egy másik cég bővített két plusz munkahengerrel.de sem elektromos embert , sem PLC-s embert nem hoztak magukkal. kicsit elbeszéltek egymás mellett a megrendelővel.
    már csak én voltam ott tőlünk, este 8 óra volt.akkor jött oda a helyi supervisor és megkérdezte be tudnám -e kötni a másik cég által beszerelt plusz alkatrészeket, illetve módosítanám-e a programot.de 22 órakor jön az első műszak, szóval működnie kellene.

    az elektromos kollégát visszahívtam, mert igy már sok volt, vissza is jött és bekötötte az érzékelőket és a szelepeket, amíg én rájöttem mit is akar a gép csinálni, és átírtam a programot és a HMI-t, nem volt vészes.
    22-re nem de 22:30-ra működött.én szerettem ezt csinálni, kár , hogy már nincs.

    egyébként pl. (egy) japán érdekeltségű cégnél a biztonsági relé nem kötelező.saját elvárásai vannak, de azok ultra szigorúak. Master relé kell, de ez bármilyen lehet duplikálva. persze náluk más a leány fekvése: NPN logika, pozitív sarok földelés, 100-200v-os hálózatok, stb. persze a Master itt is hardveres kizárás, de nem kell biztonsági relé.

    byte

    [ Szerkesztve ]

  • byte-by

    tag

    válasz KB.Pifu #4148 üzenetére

    halo !

    semmiképp nem az volt a cél, hogy bárkire ráijesszünk.
    senki nem született a felvett, megszerzett, megértett tudással.
    újonc mindenki volt.
    erőfeszítésbe kerül, de megéri.
    ez az én véleményem, én is tanulom folyamatosan.

    byte

  • sörösló

    aktív tag

    válasz KB.Pifu #4137 üzenetére

    KB.Pifu

    "Gondolok olyanra, hogy Vész-stop megnyomásakor a motortól nemcsak a vezérlést, hanem a feszültséget is el kell venni."

    OK! Aztán mi lesz? "Gurul a nehéz kő, ki tudja hol áll meg. Ki tudja hol áll meg, kit hogyan talál meg". Erősen alkalmazásfüggő hogy egy hajtást lehet-e szabad kifutással leálítani. Hogy parasztul fogalmazzak: - Bédobhatom-é a gyeplűt a lovak nyakába osztán majd leugrok a szekérrűl ha baj leszen? Nem egyszerű probléma ez. Nálunk működik egy flexo nyomdagép. A központi ellennyomóhenger 3 m átmérővel, 6 tonna önsúllyal forog 350 m/perc kerületi sebességgel. Na mármost képzeld el a Vész-Stop funkció két szélsőséges esetét. Az első a szabad kifutás. Ez a tömeg a két jólkent csapágyazásán kb. egy óráig még forog. Ha bekapott valakit és azért nyomtál vészstopot, akkor a valakiből még darálthús se marad mire megáll. A másik szélsőséges eset meg az, amikor valamilyen trükkel azonnal megállítod. Ebben az esetben a forgó tömeg a tehetetlenségi nyomaték miatt feltépi maga alól a tőcsavarokat és kigurul a csarnokból! Az egyetlen járható út a vezérelt leállítás. Ehhez az kell hogy a vészgomb működtetése után még legyen anyi ideig vezérlés, hogy a hajtás a leállítási folyamatot végre tudja hajtani. Van hozzá egy köbméteres fékellenállás, ezzel kb. 30 mp alatt megeteti a forgási energiát, az ellenállás persze világít mint a karácsonyfa, de megáll ésszerű időn belül.

    "Vagy a vészkapcsolók NC gombokkal vannak kiépítve stb."

    Az NC gombok sem lehetnek egyszerűen NC-k! Nem használható ilyen helyen úgynevezett mikrokapcsolós vagy "pattanó", rugósműködtetésű kapcsolóelem! Vészkörben csak közvetlen működésű, egyszerű nyomásra működő kapcsolóelemek használhatók.

    "a vész-kör sorosan van kiépítve és közvetlenül a plc vezérli, vagy mondjuk a biztonsági relé és csak az adja a jelet plc-nek"

    A Vész-Stop kör mindig soros kiépítésű, még a sokszázéves gépeken is! A Safety relék még külön is vigyáznak arra hogy ne lehessen becsapni őket. A PLC meg általában csak információt kap a független vészkörtől, hogy esemény történt! A safety PLC egy külön mise, ne merüljünk bele.

    "Nagyobb teljesítményű gépeknél kétkezes indítás van, azt kötelező biztonsági relével megoldani, vagy azt vezérelheti a plc?"

    A kétkezes indításnak semmi köze a teljesítményhez. Régebben csináltam időrelés vezérlést ilyesmire, de manapság már csak az erre alkalmas GYÁRI relét használnám. Ha valakinek erre nincs pénze, az ne építsen gépet! Vészköri funkciót CSAK SAFETY PLC vezérelhet!

    Nem egyszerű probléma, az internet bőséges forrást tartalmaz a kockázatelemzésről. Szerintem is kissé túllihegett a probléma, egyetértek Szirty-vel. De a törvényi szabályozás szerint életed végéig felelősséggel tartozol az általad alkalmazott megoldásokért, úgyhogy meggondolandó, mihez adod a nevedet.

  • Szirty

    őstag

    válasz KB.Pifu #4157 üzenetére

    Üdv!

    "a kérdésem az lenne, hogyha a bytot-t integer típusú lokális változóba "mozgatjuk" akkor az integer nulladik sorszámú byte-ja mindig 0-val lesz feltöltve?"

    Így van! Mivel a word nagyobb helyiértékű byte-ja van elöl (az alacsonyabb címen).

    A "STEP 7 - Ladder Logic for S7-300 and S7-400"-ban említik is ezt:

    Vagyis:
    Amikor értéket mozgatunk eltérő hosszúságú adattípusok között, akkor a mgasabb helyiérték csonkul ha szükséges, vagy nullákkal lesz feltöltve.

    A táblázat pedig bemutatja mindkét esetet egy-egy példával. vagyis hogy mi történik ha hosszabbat mozgatunk rövidebbe és fordítva.
    Ha megnézed, a LAD vagy FBD MOVE utasítás STL-ben egy LOAD és aegy TRANSFER utasításra fordul le. A LOAD pedig így működik:
    "Description
    L <address> loads the addressed byte, word, or double word into ACCU 1 after the
    old contents of ACCU 1 have been saved into ACCU 2, and ACCU 1 is reset to "0"."

    Vagyis:
    Betölti a címzett byte, word, vagy double word adatot az ACCU1 regiszterbe miután az ACCU1 korábbi tartalmát ACCU2-be másolta és az ACCU1-et törölte (nullát rakott bele).
    Tehát a load előszőr átpakolja ACCU1-et ACCU2-be, majd ACCU1-be nullát rak és azután beleteszi a címzett adatot. Mindkét ACCU 32 bites, így ha 32 bitnél rövidebb adattípust töltünk be (byte, word, int) akkor az ACCU nem érintett magasabb bitjei nullák lesznek.

  • Szirty

    őstag

    válasz KB.Pifu #4162 üzenetére

    Üdv Pifu!

    Én nem láttam még olyat, azt is csak messziről.
    Valószínűleg nem túl gyakori, bár lehetnek iparágak ahol az, nem tudom. Valószínűleg főleg a FESTO saját megoldásaiban fordul elő a leggyakrabban. Az oktatásban nagyon nyomták régen.

    Érdemes foglalkozni vele, hiszen minden tudás és tapasztalat érték amit szerzel, no meg ki tudja merre sodor a szél.

  • byte-by

    tag

    válasz KB.Pifu #4164 üzenetére

    halo !

    festo-plcvel 96 elötti tetra pack gépek kapcsán találkoztam, de a tetra szerint lassúak voltak meg a szoftverük sem valami baráti, ezért többet nem alkalmazták őket. nekem igazán tapasztalatom nincs velük.

    a servo-k jópofa dolog. amennyi paramétert tudnak én még soha nem használtam ki.
    talán mindegyik fajta közös jellemzője a servopoziciók felvétele. valamint az ehhez kapcsolódó egyéb paraméterek gyorsulás, lassulás, görbék,nyomatékok stb.

    ha gondolod és tudsz szerezni valamilyen szoftvert nyugodtan nézz bele.persze jobb lenne egy működö motor, de a szoftver is mutathat érdekes dolgokat.
    nagyon jó,felhasználó barát és érthető a festo ujabb fejlesztésű dnci motorok és szoftvere, de személyes kedvencem az SMC.
    a festo szoftvere pár éve ingyenes volt , nem tudom ez változott-e.

    byte

  • Szirty

    őstag

    válasz KB.Pifu #4164 üzenetére

    Üdv!

    Nos akkor hagyd a FESTO-t egyelőre.
    Mindazonáltal egybe is bele lehet merülni annyira hogy ha semmi mással nem foglalkozol csak azzal az egyel, akkor sem érsz a végére.

    Nos a szervó hajtás téma is megér egy fejezetet, az biztos.
    Tulajdonképpen egy frekvenciaváltó, kiegészítve egy pozicionáló vezérléssel. Az esetek többségében van egy útmérő visszacsatolás is.
    Talán a leggyakrabban egyszerű pozicionálásra használják, amikor kap egy cél pozíciót és egy start jelet, mire elmegy oda egy előre megadott sebességprofil betartásával (gyorsítás, sebesség, lassítás).
    De a legtöbb ennél többre is képes, mindenféle furmányos alkalmazásokra is használható.
    Nálunk pl. a menj oda, gyere ide mellett ún. "maradék út pozicionálásra" is használjuk.

    Szinkronizálásra is alkalmas a legtöbb. Ez az egyszerű sebesség szinkrontól kezdve a pozíció szinkronon át a CAM görbét követő több tengelyes szinkronig terjedhet.

  • Szirty

    őstag

    válasz KB.Pifu #4200 üzenetére

    Üdv!

    Mutasd a kódot amit írtál!
    És azt is ahol feldolgozod az OB-ban növelt értéket!

    Valami byte mellécímzés lesz... 256 ugyanis épp a byte ábrázolási tartományának határa.

  • Szirty

    őstag

    válasz KB.Pifu #4204 üzenetére

    Helló Pifu!

    Ott rontottad el, hogy az INC utasítást használod egy integer növeléséhez és nem olvastad el hogyan működik az INC:

    Az ugyanis csak 8 bittel (byte) dolgozik és 255-ig számlálhatsz vele (utána túlcsordul és nullától újrakezdi).

    Ezért azt javaslom, hogy az alábbi utasítások helyett:
    L #Inout
    INC 1
    T #Inout

    Ezeket használd:
    L #Inout
    + 1
    T #Inout

    A + 1 is inkrementál, de 16 vagy 32 biten!

  • Szirty

    őstag

    válasz KB.Pifu #4223 üzenetére

    Szia!

    "Első megoldásomban a bit resetelése előtt figyeltem, hogy tényleg csökkenő tendenciát mutat-e az integer. De szükséges ez? Mert 1200 felett mindig 1 a bit értéke, 1080 alatt pedig mindig 0."

    Nem kell figyelni hogy a az érték milyen tendenciát mutat. Egyszerűen be kell kapcsolni (SET) a hiszterézistartomány teteje fölött és ki kell kapcsolni a hiszterézistartomány alja alatt.
    A hiszterézistartományon belül pedig nem bántjuk. Ha be van kapcsolva bekapcsolva marad, ha ki van kapcsolva kikapcsolva marad mindaddig amíg ezen a tartományon kívül nem kerül.

    "2. eset: mondjuk rögvest az érték 1195-ről indul, és csökken, akkor a bitnek 0 -nak kell lennie?"

    Nem. Mivel 1195 a hiszterézistartományon belül van a bithez nem nyúlunk.
    Az egész történet lényege két összehasonlítás és egy RS tároló. Az egyik összehasonlítás a SET a másik a RESET ágban. :-)

    Hogy mire jó?
    Képzelj el egy szint mérést. A szintet mérjük. Ha egy adott szint alá csökken a szint, elkezdjük tölteni úgy, hogy bekapcsolunk egy szivattyút. Ha a szint elég nagy, kikapcsoljuk.
    Ezt egyetlen összehasonlítással is megoldhatjuk (tehát hiszterézis nélkül) hogy ha a szint 60%-nál kisebb akkor szivattyú start, ha egyenlő vagy nagyobb, akkor szivattyú stop.
    Ezzel két baj biztosan lesz.

    1. A szint lassan csökkenve felülről közelít a 60%-hoz 60.2%...60.1% stb. Analóg mérés soha nem stabil. mindig billeg ide-oda legalább egy bitet, de inkább többet. Tudod mi fog történni, amikor a szint elkezd 59.99-60.01 között mérni...
    2. Amikor töltés közben az emelkedő szint kezdi megközelíteni a kikapcsolási 60%-ot és lötyög :-)

    Mind a két dolog következménye az, hogy a szivattyút túl gyakran és véletlenszerűen ki-be kapcsolgatja.
    Ettől függetlenül is túl gyakran kapcsolgatná.

    A gyakorlatban még a legegyszerűbb szobatermosztátnak is van hiszterézise, vagy éppen a festő kompresszor nyomáskapcsolójának

  • Szirty

    őstag

    válasz KB.Pifu #4290 üzenetére

    Üdv!

    A véleményem?
    Azt hiszem az előbb a lényeget kifejtettem ami a véleményemet illeti.
    Az általad hivatkozott példa messze ékesen bizonyítja mennyire elméleti szakemberek készítik a példafeladatokat és oktató anyagokat. Még csak ki sem próbálják azokat a dolgokat amiket leírnak a lektor meg átengedi, mert ő is elméleti síkon foglalkozik vele. Aztán jön a tanulni vágyó (illetve akik nem vágynak hanem kényszerülnek, de az ügy szempontjából ez most teljesen közömbös) ő lesz az első aki akkor vagy talán egyszer majd meg is valósítja a faxságot amit tanult és rohadtul nem fogja érteni ki mikor és mit rontott el.

    A dupla tagadás beleegyezés! :-)

  • Szirty

    őstag

    válasz KB.Pifu #4293 üzenetére

    Helló!

    Tudom én mi a helyzet. Néha azért bekerülnek, ahogy hozzánk is jöttek (pl. tanulók szakmai gyakorlatra, de végzősök is).
    Igen a cégek ma már nagyon óvatosan bánnak azzal hogy kinek milyen papírja van. Inkább az érdekli őket kinek milyen gyakorlata van és tesztelni is szokták a jelentkezőket.
    Vajon miért? :-/

    No de nézzük a jó oldalát: egy darabig még biztosan lesz munkám...

  • Szirty

    őstag

    válasz KB.Pifu #4303 üzenetére

    Üdv KB.Pifu!

    Ok.Tehát ha jól értem a kérdést akkor ez a válasz rá...
    Nem szoktam számlálót léptetni amikor egy gép elér egy állapotot és megint léptetni amikor elér egy másik állapotot és így tovább. Az adott mozgásokat meg a számláló pillanatnyi értékéhez kötni.
    Pl.: ha a számláló tartalma 1, akkor emelés szelep meghúz. Ha felért, számlálót léptetem. Ha számláló tartalma 2, akkor rögzítő szelep nyit, időtag indul. Ha időtag letelt, számlálót léptetem, ha a számláló tartalma 3 akkor... és így tovább.

    Kimondott léptetőláncot sem szoktam építeni, ami úgy működik mint a "futófény". Azaz van sok-sok merker bit, amik egymást billentik be egyéb feltételek teljesülése esetén. Amelyik bebillent az törli azt amelyik az imént bebillentette. Így lesz egy merker sor, amiben egy bit mindig 1 állapotú a többi meg 0. Az 01-es állapot "végig sétál" a láncon. ha 1-es lépés aktív, akkor akkor emelés szelep meghúz. Ha felért, láncot léptetem. Ha 2-es bit értékre 1, akkor rögzítő szelep nyit, időtag indul. Ha időtag letelt, láncot léptetem, stb, stb, stb.

    Vannak gépek amik mozgása kifejezetten lépésekre bontható. Jól definiálható állapotok vannak amik mindig azonos sorrendben követik egymást és vannak amiké egyáltalán nem bontható ilyen állapotokra vagy ezek az állapotok véletlenszerű sorrendben követik egymás (pl. a technológiai állapottól függően).

    Olyan esetekben ahol ilyen ismétlőfő lépések meghatározhatók én jelzőbiteket használok. Amikor egy művelet megtörtént, bebillentek egy jelzést és a következő műveletnek ez is feltétele (az egyéb véghelyzetekkel, időtagokkal együtt).
    Ez funkcionálisan tekinthető léptető láncnak is, mert hasonlóan működik, de a program felépítése nem léptetőláncra épül.

    Más gépeknél (ahol nincsenek előre definiálható állapotok amik egymást követik) nem is alkalmazható ilyen módszer.
    Ezért pl. kifejezetten haragszok amikor ilyet oktatnak. Illetve amikor csak ilyet oktatnak (pl. OKJ-s tanfolyamon, de egyetemen is. lásd futófény, közlekedési lámpa példaprogramok).

    Aztán a delikvens szembe találja magát pl. a kézi üzemmóddal vagy egy szabályzással, vagy olyan feladattal ahol rengeteg párhuzamos folyamat fut amik sorrendisége nem határozható meg előre, akkor csak lesnek mint hal a szatyorban...

    [ Szerkesztve ]

  • KB.Pifu

    tag

    válasz KB.Pifu #4306 üzenetére

    Nos, megint előbb írtam és azután gondolkodtam, a számláló csak összezavarná a folyamatot, mert ugye ha még a be nem fejezett léptetés közben megnyomom akkor mit gondoljon a szegény...

    Legközelebb jobban meggondolom

  • Szirty

    őstag

    válasz KB.Pifu #4306 üzenetére

    Üdv!

    Az én értelmezésemben a "kézi üzemmód" azt jelenti, hogy kézzel kapcsolok be és ki mindent.
    Tehát kiválasztom a hajtást/munkahengert és azt irányítóm. Ki/be kapcsolom két gombbal vagy előre/hátra vagy le/fel mozgatom.

    Az hogy egy automatikus folyamat állapotait léptetem nyomógombbal azt inkább félautomata módnak tekintem.

  • byte-by

    tag

    válasz KB.Pifu #4307 üzenetére

    halo !

    ha a rendben befejezett munkafolyamat is feltétele a számláló léptethetőségének, akkor nyomkodhatod, nem fog történni semmi, amíg rendben végig nem csinálta az adott léptetést.de a számláló így sem szerencsés.
    sok gépsor sajátja a "félautomata" üzem, volt szerencsém párhoz. van olyan gépsor ahol frankó távirányítóval kiválasztod az állomást , majd lépteted a folyamatot.mondjuk pont ez a gép nem volt a tervezés etalonja.
    viszont a "kézi üzem" valóban a komponensek egymástól akár független működtetéséről szól, persze a megfelelő feltétel rendszer mellett. ez bizonyosan nem szekvenciális.

    ha esetleg szekvenciáról van szó számlálót én sem használok.leginkább egy merker szót szoktam használni amibe értéket írok ha a feltétel sor igaz.egy comparátorral ez adja a következő network első feltételét, aztán ha a többi is igaz lesz ,egy másik érték íródik bele.ezzel szekventált programblokkonként 1 merker word-öt használok el.
    "félautomata" léptetéshez is használható, a befejezett hibátlan programsor fogja csak átírni a merker szót,majd újabb gombnyomás. ha közben is nyomogatják a gombot nem fog történni semmi.

    ez SZIGORÚAN szekvenciális gyártógépekre vagy állomásokra igaz.

    egyébként sajnos tényleg igaz, hogy szinte csak a léptetős programírást oktatják.visznek kis kivágógép vagy mártogatógép modellt és mindenféle léptetős munkára bírják.persze látványos meg sikerélmény annak aki még semmi ilyesmit nem csinált,de kissé csalóka.sehol egy szabályzás, PID, regiszter kezelés, stb. de legalább felhívnák a figyelmet a továbbképzés szükségességére.

    byte

  • Szirty

    őstag

    válasz KB.Pifu #4306 üzenetére

    Üdv KB.Pifu!

    "Kézi üzemmódban, a gépnél kiválasztunk egy állomást és gombnyomásra egyesével "végigléptetjük" a munkafolyamatot, ott már feltétlenül szükséges a számláló jelenléte, nem?"

    Most attól eltekintve hogy mit gondolok a kézi üzemmódról, azt tudom erre mondani, hogy feltétlenül mindenképpen ide sem szükséges számláló. (az hogy most a lépési feltétel forrása tényleg számláló (C) vagy egy inkrementált merker word tartalma, az jelen esetben mindegy).
    Pl. egyszerűen kell egy "lépés vége" merker, ami bebillen minden mozzanat végén és a léptetés gombbal lehet törölni. És ezt a merkert be kell rakni minden továbblépés feltételsorába. Ezzel ugyanúgy léptethetővé válik.

    A léptetőlánc nélküli programra van itt egy a közlekedési lámpánál valamivel komplexebb kidolgozott kommentezett feladat.
    Ha gondolod nézd át: Tolópad szimuláció S7-300/400-ra

    [ Szerkesztve ]

  • Mazsika

    őstag

    válasz KB.Pifu #4432 üzenetére

    Azok a blokkok arra szolgálnak szerintem ha S5rol akarsz atterni S7-re. Az S5-re vannak olyan blokkok amit az S7 másképp vagy másra használ. Gondolom ezek a blokkok akkor használatosak!

    [ Szerkesztve ]

    Dáccsika

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