Hirdetés
-
Egyre nagyobb a balhé a Helldivers II körül
gp Úgy tűnik, hogy egyre több sötét felhő kezd gyűlni a játék körül a Sony döntése miatt.
-
Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
ma Részletes anyag került fel az internetre a Sony idei középkategóriás telefonjáról, három helyett két hátlapi kamera várható.
-
A virágcsokor mellé hardvert is ajándékozhatunk anyák napján
ph A héten desktop PC-k, monitorok, gamer kiegészítők és házak vannak a kirakatban.
Új hozzászólás Aktív témák
-
rsf
senior tag
Bocsi rosszul emlékeztem a hibára.
A képen jól látszik, hogy a CPU error-ban van, de a diagnostic bufferben lévő hibák a dátumok alapján már több mint 2hónapja álltak fennt valószínűleg egy áramszünet miatt.Több terepi I/O nem volt elérhető.
Szóval ezek a hibák nem indokolnák az error státuszt, gondolom.
Jelenleg nincs hiba, hiába update-elem nem frissül a buffer. Eddig úgy tapasztaltam, hogy ha itt error-t látok akkor az SF led világít.De most nem tudom biztosan, mert ez a PLC nincs a közelben én is csak táveléréssel érem el. Lehet, hogy egy restart elég lenne neki, de nem akarok kockáztatni. Amikor ott hagytuk még nem volt error.Nem régóta foglalkozok siemens-el és nagy csalódás volt. De amúgy a progi elég nagy és sok indirekt címzés van benne.Köszi.
“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“
-
Szirty
őstag
Helló rsf!
A diag buffer úgy működik, hogy bizonyos hibáknál van incoming meg otgoing esemény. Tehát amikor a hiba keletkezik, meg amikor megszűnik.
Pl. egy rack leválása a terepi buszról ilyen incoming esemény, a visszacsatlakozása pedig outgoing esemény.
Az ilyen hibáknál a beérkező esemény létrehozza a hibaállapotot, a kimenő esemény meg megszünteti azt.
Ebben az esetben tehát a BF LED hibát fog jelezni az állomás leszakadásakor és a hibajelzés megszűnik amikor sikerül neki újracsatlakozni.
Ez akkor is így van, ha a két esemény között napok vagy hónapok vagy akár évek telnek el (de újraindításkor az esemény újra létrejön).
Vannak azonban olyan hibajelzések is, amelyeket programozási hibák okoznak. Az ilyennek nincs incoming meg outgoing eseménye. Ilyen pl. egy BCD konverziós hiba vagy a mellékelt képen látható I/O access error is.
Ilyen hibánál az SF LED hibát jelez. Ha csak egyetlen egyszer volt hozzáférési hiba akkor a LED egy idő múlva kialszik. Ezzel ad esélyt arra,hogy a hibát észrevedd (különben csak 1 ms-ra villanna fel egyszer.
Ha azonban a hiba minden egyes PLC ciklusban megismétlődik, annak két következménye van:
Egyrészt az SF LED folyamatosan hibát fog jelezni, másrészt a diag bufferben minden egyes hiba bejegyzésre kerül.Na most a periféria leválása a buszról és az I/O access error nem ritkán járnak kézen fogva, mert a programban a hibakezelés trehányul van megvalósítva (vagy sehogy, lásd üres hibakezelő OB, hogy ne legyen CPU STOP).
A te eseted szerintem éppen ilyen.Működik szépen a program távoli IO-k rendben működnek, a PLC program minden ciklusban írja és olvassa ezeket a távoli IO-kat a saját címűkön. Egyszercsak leszakad a távoli I/O, erre kerül egy üzenet a diag bufferbe, hogy ez és ez az I/O leszakadt. Mivel a programozó frappánsan rakott egy üres OB*t, hogy emiatt ne legyen CPU stop, a program rója tovább a köröket és egyszer csak oda ér, ahol ezeket a leszakadt I/O-kat olvassa vagy írja.
Erre mi történik? Hát nem más, mint I/O access error, hiszen olyan periféria címekhez szeretne hozzáférni, amik a leválás miatt pillanatnyilag nem is léteznek. Ettől lenne ugye egy CPU STOP, de a fejlesztő egy második huszárvágással valószínűleg erre is rakott egy üres OB-t ezért ettől sem lesz CPU stop. Lesz azonban egy I/O access error bejegyzés a diag bufferben, de nem baj, mert a program fut tovább. Aztán egyszer szeretné elérni a másik leszakadt perifériát aminek az eredménye újyabb access error, és újabb bejegyzés a diag bufferben.
Amikor a PLC újrakezdi a ciklust az egész kezdődik elölről és a diag buffert telefossa I/O access errorokkal.
Másodpercenként belerak pár százat ami jól látszik a mellékelt képen mert az időbéjegek között 2-20ms különbség van.
Igen ám, de a diag buffer hossza sem végtelen, ezért amikor az megtelik a legrégebbi üzenetet kiejti.
No és mi volt az az üzenet, hát az, amikor a távoli I/O leszakadt és elkezdődött az access error áradat.Aztán szépen visszacsatlakoznak a távoli IO-k, ezért elérhetővé válik az összes periféria és immáron a program hozzáférési kísérlete is iskeres lesz így nem kerül be több bejegyzés a diag bufferbe.
Tehát ha a CPU error státusban van de a diag bufferben hónapokkal azelőtti bejegyzések vannak, akkor valószínűleg van egy hiba ami azóta is fennál, de már nem látod a diag bufferben mi is az a hiba, mert 300 másik hiba miatt telefirkálta a diag buffert és a régi üzenet elveszett.
"Nem régóta foglalkozok siemens-el és nagy csalódás volt."
Az ismerkedést nem hatalmas programmal kell kezdeni ahol terepi busz van, ezer analóg mérés, hajtásvezérlők operátor panelek, stb. Hanem alacsonyabban és lépésről lépésre. Akkor lesz siker élmény és még az is kiderülhet, hogy nem is olyan rossz ez. Összetett és sokat tud, csütörtökre ezt nem lehet megtanulni :-)
Kitartás! Sok sok kitartás (nagyon sok kitartás!) -
rsf
senior tag
Ez minden PLC-nél igy van, hogy a legrégebbi üzenetek kiesnek a diag bufferből ezért mindig a legujabb marad csak benne. De pont ezt nem értem. Szóval már 2hónapja nincs hiba mert a legfrissebb hiba is 2hónapos és mégis errorban van a CPU. Most nem akarok PLC hitvitákba belemenni , de nekem a Siemens nem jön be igazán bár van ami tetszik benne. A fenti progi nagy részét én irtam már egy éve megy, de kb. 4hónapja van ez a hiba. Van egy kollegám aki a fő siemens-es, Ő azt mondta, hogy lehet olyan hiba amit nem rak be a hiba bufferbe. Nem tudom, hogy igy van-e, ezért kérdeztelek meg téged mint a fő Gurut.
Köszi[ Szerkesztve ]
“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“
-
Szirty
őstag
Helló rsf!
"Ez minden PLC-nél igy van, hogy a legrégebbi üzenetek kiesnek a diag bufferből ezért mindig a legújabb marad csak benne. De pont ezt nem értem."
Én meg pont ezt magyaráztam a szokottnál is hosszabban. És emiatt lekéstem egy vonatot, amiért csak a következővel (1 óra várakozás) tudtam elmenni, de az 15 percet késett majd 10 percet dekkolt az állomáson 40 fokban. Vettem IC pót+helyjegyet a meleg miatt, amúgy nem szoktam) erre kiderült hogy szar a klíma a kocsiban, máshova átülni nem lehetett a helyfoglalás miatt. Az ablak az ilyenben nem nyitható, lincshangulat stb. :-)
Patakokban szakadt a víz a tökömön is, csucsogósra áztam, ittam a vizet tonna számra (ameddig kitartott) Eközben hívogattak a cégtől, mert interbus hiba, meg oracle szerver beszart, meg áramszünet volt. De a T-Mobile lefedettsége oly kiváló, hogy a robogó vonatból intézett VPN-es távoli asztal kapcsolaton át indított VNC csatlakozáskor a képernyő 20 másodperc alatt épült fel.
Az IC pótjegy árát a végállomáson kifizették volna, csakhogy még legalább egy másik vonatban is hibás volt a klíma, ezért az ü.félzolgálat előtt álló sort kilométerekben lehetett mérni a várható várakozási időt meg órákban.
Persze 40 fokban, persze mindezt épp azért, mert vettem 600-ért egy pótjegyet hogy klímás vonatban ne égjek szénné.
De mivel eközben újra hívogatni kezdtek egy másik probléma miatt ott kellett hagyni a sort, úgyhogy a 600 Ft-os szauna jegyet bent hagytam a MÁV-nál. Laptoppal kellett volna elvonulni egy csendes sarokba hogy a neten keresztül próbáljak segíteni nekik, de milllióan voltak és közben majd be hugyoztam (a tonna víz ami bement akkor már kifele akart jönni). Szerencsére itt most csak 35 fok van a szobában :-)Mindezt nem tudom miért írtam le, talán mert (szerintem9 vicces.De természetesen (komolyan) nem okollak a késés miatt én néztem be az időt. Kicsit elragadott a hév a válaszolásnál olykor előfordul, de ezt mindig meg is bánom, mert a részletesen és hosszan leírt üzenetre vagy semmi válasz nem jön vagy olyan aminek nincs köze ahhoz amit leírtam. Vagy van köze de pont azt kérdezik újra ami miatt írtam.
Van az úgy, hogy összeszaladnak a dolgok.Szóval hogy miért van még error LED miközben a bufferben nincs error? Hát mert a régi hiba ami az éppen aktuális hibajelzést létrehozta még mindig aktív, de a nagyon sok másik az arra vonatkozó üzenetet már kimosta a bufferből ezért nem láthatod. Ezt gondolom.
Újraindítani meg nem akarod, pedig akkor kiderülhetne, hiszen a fennáló hiba (incoming event) restartkor újra bejegyzésre kerül. Jó nyilván egy ipari gépet nem mindig lehet csak úgy újraindítgatni bármikor, de ki lehet várni az alkalmat. Csak idő (és olykor pénz) kérdése...."Most nem akarok PLC hitvitákba belemenni "
Én holnap sem.
Nem szeretem a hitvitákat. A józan és gyakorlatias érveket viszont kedvelem.
Engem nem nagyon kötnek érzelmi szálak a tárgyakhoz. Pusztán használati értékük van számomra.
Ha valamire azt mondod hogy elképesztően jó vagy azt hogy használhatatlan, nem elég.
Ha tudok segítek neked is, hiszen ez a fórum is erről szól valahol. Hiába mondja valaki, hogy "szar ez a szar" azon én nem tudok segíteni. Tudom, nem írtál ilyet nem is rád gondoltam. De ez mindennapos.És ne hidd hogy én nem találkozok olyan problémákkal amiket nem értek! Tudnék mesélni :-)
Még egy szakma blogot is megérne egy ilyen (másoktól is származó) gyűjtemény, de kinek van ideje meg kedve ilyeneket írni? :-) -
sörösló
aktív tag
Nincs is ezzel semmi baj, amíg ép a drót, vagy jó érvégnyomót használtak a szerelésnél. Múltkor döbbentem meg, amikor a qrva drága Weidmüller fogóval nyomott 0,25-ős érvégből simán kihúztam a vezetéket! Az én Conta-Clip fogóm ha egyszer megharap valamit, akkor az meg van harapva. Igaz, ezelőtt tizenakárhány évvel 30 rugóba fájt, de azóta is teszi a dolgát. Én az ilyen vékony cuccokhoz félvezetővédő betétet szoktam használni. Az garantáltan kiugrik, ha túlépted az értékét. Igaz árban nem egy kategória. Amúgy meg kapja be a Festo, a Mecman, a Bosch meg mindenki, ha egy 5 rugóba kerülő helyzetérzékelőhöz nem telik egy becsületes vezetékre. Ilyenkor mindig eszembe jutnak a régi svájci kimetszőink. Azokban 2.5-nél vékonyabb drótot nem használtak a vázkábelezéshez, de nem is volt velük vezetékszakadási probléma! Igaz, azóta felment a réz ára rendesen.
-
rsf
senior tag
Hali,
ha este irtad volna csak a választ akkor sem történt volna semmi. Sajnálom a történteket majd iszunk rá egy sört valamikor valahol.
Azért nem akarom ujraindítani a PLC-t, mert cirka 13óra repülőútnyira van.
Nincs még nagy tapasztalatom Siemens-ben, de a folyamatosan fennálló hibát eddig mindig a diag bufferben látható közeli időpontból láttam.Valamint abból, hogyha rányomok az update gombra akkor frissül a hiba ideje. Jelen esetben ez nincs így.
De majd valamikor értekezhetnénk a normális hibakezelésről, nem csak üres OB-k.
Üdv.“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“
-
Szirty
őstag
Helló rsf!
"Valamint abból, hogyha rányomok az update gombra akkor frissül a hiba ideje."
No várj. A diag buffer bejegyzéseinek időbélyegzője a bejegyzés keletkezésének időpontját mutatja. Ezért az utólag nem változhat meg.
Az Update gomb arra való, hogy a megnyomásakor a Step7 újraolvassa a PLC-ből a buffer tartalmat, hogy az eközben keletkezett olyan bejegyzések is megjelenjenek a listában amik közben érkeztek és amik nbem okoztak üzemmód váltást a CPU-ban.
A diag buffer ablak tartalma automatikusan frissül ha a CPU (vagy CP) üzemmódot vált az új bejegyzés miatt.
Ha nem vált üzemmódot (pl. fut tovább) akkor nem frissül magától, na ilyenkor jön jól az update gomb.Az SF LED "úgymaradásával" kapcsolatban még futnom kell egy kört, úgy fest hülyeséget írtam, pl. area length error-nál ha van OB121, nem teljesen úgy viselkedik mint írtam. Úgy néz ki CPU mód váltásig úgy marad és jelzi hogy hiba volt.
"De majd valamikor értekezhetnénk a normális hibakezelésről, nem csak üres OB-k."
Örülök, hogy nem bántottalak meg ezzel a hibakezelés dologgal, nem is volt ilyen szándékom.
Annyit tudok "enyhíteni" rajta, hogy 100%-os hibakezelés is nagyon ritka. :-)
Ennek két oka van: Egyik, hogy soha nincs rá elég idő. A program érdemi részének korrekt kidolgozására sincs, nem hogy a hibakezelésre.
A másik, hogy a hibakezeléssel nem lehet azonnali látványos eredményeket elérni. Az inkább hosszú távú befektetés. -
Szirty
őstag
Helló rsf!
"de a folyamatosan fennálló hibát eddig mindig a diag bufferben látható közeli időpontból láttam."
Utána néztem a dolognak.
Az SF LED viselkedése CPU és FW függő.
Pl. a PLCSIM-ben egy prog. error bekapcsolja az SF LED-et és úgy is marad akkor is, ha több progr error már nem történik. Az SF LED a program újraindításáig (stop->start) világítani fog, jelezve hogy volt hiba.
A programming error ugyanis (ahogy korábban írtam) olyan amihez csak incoming event tartozik, outgoing nem. Tehát csak keletkezik, de nem szűnik meg (synchronous error).
Míg pl. a dp station error meg asynchronous error és van outgoing eventje, ami szépen kikapcsolja a LED-et (ha másik hiba nem aktív mellette).
Ez így működik néhány (talán régebbi) CPU-nál is.Kipróbákltam egy CPU 314C-2DP-n (314-6CG03-0AB0 FW V2.6.6). Ennél ha a CPU nem fut rá több programming error-ra, akkor az SF LED magától kialszik kb 2 mp után.
A Siemens álláspontja ezzel kapcsolatban az, hogy nem a hibajelző LED kioltásával kell foglalkozni, hanem megfelelő hibakezeléssel meg kell akadályozni hogy a hiba bekövetkezzen.
Az álláspont szerint tehát a LED azért világít, mert a programmal probléma van, amit ki kell javítani. -
rsf
senior tag
Akkor most szerinted mi a hiba? Mert az I/O hiba megszünt két hónapja. Tehát szerinted vmi programming error volt ami bekapcsolta a ledet majd volt utánna pár I/O acess error ami már megszünt de ez van a bufferben a programming error meg kiesett?
Igazából nem tudom, hogy melyik led világít, csak az error látható a diag.bufferben. A PLCSIM-ben én nem nagyon bíznék többször csinált teljesen mást mint a hús-vér PLC.
Üdv.“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“
-
Szirty
őstag
Helló rsf!
Én most már komolyan nem értem mit nem értesz.
Van értelme hogy ugyanazt megint leírjam?"Tehát szerinted vmi programming error volt ami bekapcsolta a ledet majd volt utánna pár I/O acess error ami már megszünt de ez van a bufferben a programming error meg kiesett?"
A programming error az a hibák egy csoportja, ilyen au I/O access error is, meg a BCD conversion error is, meg még egy csomó.
1. Leszakadt egy vagy több DP eszköz! Ettől keletkezett egy azaz egy darab bejegyzés a diag bufferben (ezt nem látod benne, mert ami utána jött az kisöpörte)
2. A lesazakadt eszközt a program írni és olvasni akarta minden PLC ciklusban, ezért minden hozzáférési kísérlet okozott egy programming errort, egészen pontosan egy I/O access error-t méghozzá ezrével. Emiatt a diag buffer korábbi (DP eszköz leszakadt) üzenete törlődött a diag bufferből.
3. A DP eszközök visszatértek, ami okozott egy újabb bejegyzést a diag bufferben, ez látható az általad közölt diag buffer tetején, mivel ezzel a perifériák elérhetővé váltak, nem jött több I/O access error, mert az I/O hozzáférés immáron sikeres volt.
Az SF LED az I/O access error miatt nem alszik ki.
A diag bufferben meg azért vannak több hónapos üzenetek, mert a diag buffer nem a fennálló (pillanatnyilag is aktív) hibák listáját mutatja, hanem egy log, ami a hibaeseményeket naplózza. -
Szirty
őstag
Helló rsf!
"A PLCSIM-ben én nem nagyon bíznék többször csinált teljesen mást mint a hús-vér PLC."
Nos vannak benne hibák, néhányba én is belefutottam már. De ezzel együtt is igen hasznos kisebb programrészletek tesztelésére megfelelő.
(Le kell szedni az újabbat abban kevesebb szerencsétlenség van) -
sörösló
aktív tag
Reménytelen, csak sokára fogja megérteni hogy nincs mit érteni. Mert ez Siemens ( AB, Modicon, Eaton, Omron stb.) Többé-kevésbé mindegyik szerencsétlen-tök(él)etlen a maga módján. A kicsik a feljesztési lehetőségek korlátozott módja miatt, a nagyok meg pl. Siemens azért mert megengedheti magának: - Ez van öcsisajt! A mienk ilyen, kicsit sótlan tán, a kóla se mindig hideg, de ez van. Eszed, vagy máshol kérsz egy szendvicset? Nem vagyok egy nagy PLC guru mint Szirty, de minden igényt kielégítő, minden szempontból tökéletes fejlesztőrendszert még nem láttam. Lehetnek persze elvakult hívői egy-egy gyártónak, de ez szerintem a rutinos megszokás miatt van. Sokat gyűrte, megszokta - olyan mint az asszony. Kicsit ráncos, kicsit háklis, de összecsiszolódtunk.
A hibakezelés meg egy alapvető nyűg, pedig szerintem a jó hibakezelés a program legfontosabb része a megbízhatóság szempontjából. Nem véletlen, hogy a safety modulok alapvető hibakezelési rutinjait nem a felhasználó írja, az már gyárilag bennük van! Nem bízható ugyanis a véletlenre, ki mit talál ki hirtelen felindulásból.
Apró kis programhibák meg sokszor okoznak többhetes fejtörést, aztán amikor rájön az emberfia, veri a fejét a falba: - Ezt nem vettem észre? Vagy az a német mérnök aki írta, egy ilyen egyszerű dologra nem figyelt?[ Szerkesztve ]
-
Szirty
őstag
válasz
sörösló
#3413
üzenetére
Üdv sörösló!
Címszavakban reagálnék:
- Nem biztos hogy el van baszva csak mert mi másképp csináltuk volna
- Ahogy az sem feltétlen biztos hogy nincs elbaszva ha úgy csinálták, vagy mi csináltuk :->
- Az elvakultság sosem hasznos (de olykor látványos)
- Bizonyos dolgoknak lehet több megoldása
- Más dolgoknak nincs jó megoldása (ez mindig akkor van, amikor kompromisszumot kell kötni)
- A motiváció jelentően meghatározhatja a dolgok szubjektív megítélését
- Ha valami sokoldalú, akkor szükségszerűen bonyolult lesz
- Az univerzális dolgok annál haszontalanabbak minél univerzálisabbak
- Az alacsony szintű hibakezelésre a megrendelő szarik. Csak működjön határidőre
- A safety modulok gyári hibakezelésének "könnyű" dolga van, olyan korlátokat állítanak ahol a felhasználó alig tehet valamit
- A beüzemelés közben hirtelen kitalálás többnyire "fentről jön" ami ha nem jön be azt sújtja aki lent van
- Egy visszatérő apró de bosszantó hiba akkor egyszerű, amikor már tudjuk mi okozta :-)A siemens rendszere bonyolult, mert sok lehetőség rejlik benne. Emiatt lehet gyűlölni, de megismerni is lehet.
Csak egy eszköz, ami a megfelelő kézben sokmindenre képes.[ Szerkesztve ]
-
rsf
senior tag
Bocsi ha hülyeséget irtam.Tehát ha leszakad egy eszköz akkor annak I/O-i nem érhetőek el(ez természetes) de ezt a hibát a siemens, program hibának veszi mintha egy nemlétező cimre hivatkoználés ez SF hiba. Ezt a diag. bufferes dolgot ki kell próbálnom élőben. Mert itt van egy kis nézetkülönbség közöttünk. Most nincs a közelemben siemens PLC (csak kb. 5 másfajta
) De ha minden igaz lassan lesz egy. Nekem az a tapasztalatom, hogy ha leszakad egy DP akkor a BF led világít nem az SF majd ha visszaáll a kapcsolat akkor az el is alszik és lesz róla egy bejegyzés a bufferben. A diag buffer egy log amiben a megtörtént hibák vannak időrendi sorrendben és x mennyiségben. Szóval az az én problémám, hogy én még nem láttam olyat , hogy világít a piros és a logban több hónapos a legutóbbi hiba. Én eddig úgy tudtam, hogyha világit az SF led akkor egy jelenleg is fennáló hiba van.De akkor ezek szerint rosszul tudtam.
Üdv.“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“
-
rsf
senior tag
-
Szirty
őstag
Helló rsf!
"Irigylem azokat akik olyan szerencsések voltak, hogy siemens PLC-vel találkoztak először az életükben."
Nem tudom számít-e, én pl. Omron PLC-vel találkoztam először.
Omron C120, C500, C200H, C1000, CQM1, CQM1H, CPM1, CJ1, CP1E sorrendben kb. Utána Siemens S5 jött, amivel a mai napig nem vagyunk nagy haverok, de ezt elsősorban a STEP5-nek "köszönheti". -
Szirty
őstag
Helló rsf!
"Nekem az a tapasztalatom, hogy ha leszakad egy DP akkor a BF led világít nem az SF majd ha visszaáll a kapcsolat akkor az el is alszik és lesz róla egy bejegyzés a bufferben."
Ha leszakad egy eszköz, akkor az SF LED világít, a BF led pedig villog!
A bufferben nem egy, hanem két bejegyzés lesz. 1. amikor leszakad és egy maikor visszatér! (incoming event, outgoung event, asynchronous error, lásd korábban)
Mindkét LED elalszik a kapcsolat visszaállásakor, feltéve, hogy egyéb hiba nem keletkezett közben. Pontosan ilyen egyéb hiba az, amikor a program hibakezelés híján nem foglalkozik azzal hogy egy eszköz leszakad és írni vagy olvasni akarja a hozzá tartozó, de abban a pillanatban nem elérhető címet! A második hiba az első következményeként jön létre."Szóval az az én problémám, hogy én még nem láttam olyat , hogy világít a piros és a logban több hónapos a legutóbbi hiba. Én eddig úgy tudtam, hogyha világit az SF led akkor egy jelenleg is fennáló hiba van."
Nem. Ez nem is lenne lehetséges már ha logikusan végig gondolod.
Mert hogyan lehetne egy periféria cím elérésének sikertelensége fennálló hiba?
Fut a program megpróbálja pl. írni, nem sikerül, ez egy hiba. Ez nem áll fenn, ez csak egy "pillanatnyi" trigger esemény. Hogy a legközelebbi kísérlet milyen eredménnyel jár, azt előre nem lehet tudni csak amikor újra megpróbálja.
Nyilvánvaló okokból a rendszer nem fogja nyilvántartani az összes címet egyenként, hogy mikor melyiket sikerült legutóbb tévesen írnia vagy olvasnia a programnak, hogy ennek alapján jelezze ki hogy a legutóbbi kísérlet minden egyes címnél sikeres volt-e vagy sem.Egyszerűen bekapcsolja az SF LED-et 3 másopdpercre. Egyes CPU-knál meg a következő restartig. Jelezve ezzel hogy a programban hiba van. Ezzel a hibajelző LED ellátta a feladatát.
Azon vitatkozhatunk estig, hogy melyik jobb. Ha úgy marad vagy az hogy 3 másodpercig világít.Mind a két megoldás logikus érvekkel indokolható. -
rsf
senior tag
OK köszi és bocsi az eddigiekért.
A jó pap is holtig tanul nem még én.
Most jött az infó:
A Siemens parkolópálya AB vel kell foglalkoznom. Hát igy hogy fogok elmélyedni benne?
Üdv.“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“
-
sörösló
aktív tag
"Na ez a lényeg: Siemens.Vagy megszoksz vagy megszöksz."
Ez egyetlen gyártónál sincs másképp!
"Irigylem azokat akik olyan szerencsések voltak, hogy siemens PLC-vel találkoztak először az életükben."
Ne irigykedj, nincs miért. Én is S5-tel futottam össze autodidakta módon először. Két napig sírtam mire rájöttem a számlálókezelésének rejtelmeire, aztán véletlen szerencse folytán hozájutottam egy kézikönyvhöz, amiből 2 perc alatt kiolvastam amit tudnom kellett volna. Akkoriban persze nem nagyon volt még ilyen szuper internet.
Szóval nyugodj bele hogy minden szisztémának vannak veleszületett fogyatékosságai.
Legkönnyebb azoknak, akik egy fejlesztőkörnyezetet használnak, megszokták, kiismerték. Nekik az az egy az etalon. Na de egy szervizeléssel, esetleg egy cégnél gépjavítással-üzemeltetéssel foglalkozó (Én)
embernek nem lehetnek kedvencei! Azt kell szeretnie amit a főnökség megvett.Ha kíváncsi vagy egy elrettentő példára: - Most érkezett egy gépezet a céghez, aki megvette annak már régen egy faágon kellene aszalódni. Node mostmár nincs más hátra mint előre, üzemelnie kell! Az elektromos dokumentáció felibe-harmadába van meg, a gép negyedrészét a helyszínen alakították át, ezekről zéró információ van. A fő vezérlést egy Klaschka nevű PLC végzi, soha nem hallottam róla. Elsőnek lépett a német piacra PLC-vel, a progamozószoftver az S5 legrosszabb verzióit is felülmúlja. Természetesen DOS alapú, előkerült hát újra a régi jó öreg PG 740! Még jó hogy nosztalgikus alkatok vagyunk és nem dobtuk ki. Jó az öreg a háznál! És akkor most mondjam hogy nem szeretem a Klaschkát? Kit érdekel! PLC az PLC. Mit lehet rajta nem érteni?
[ Szerkesztve ]
-
DP_Joci
tag
Sziasztok,
Ki honnan szokott a megjelenítőkhöz grafikus szimbólumokat használni?
pl. kézi funkcióhoz egy kéz alak, amit persze meg is lehetne rajzolni, de ha valahol megvan, akkor elég lenne csak beilleszteni.
Vagy ha mindenképpen rajzolni kell, akkor mivel érdemes, ami egyszerű (pl. autocad-ot nem használom napi szinten, de még havi szinten sem).
köszi
J. -
Onishi
tag
Szevasztok!
Csak úgy kíváncsiságból kérdezném tőletek, (tapasztalt rókáktól :-)), hogy előfordult-e már veletek olyan, hogy egy plc program írása során kifutottatok az adott plc "tárhelyéből"?
Gondolok itt mondjuk merkerekre, számlálókra, DB-kre stb. hogy pl. többre lett volna szükség, mint amennyit az adott cpu tud kezelni. Mit csináltok olyankor? Egyáltalán elő szokott fordulni az iparban olyan nagy program? -
Szirty
őstag
Üdv Onishi!
Én eddig csak kétszer futottam bele ilyenbe. Egyszer egy Siemens LOGO-nál, ott az volt a gond, hogy túl nagy feladatot kapott a régi változat (első darabok közül) pedig nem volt bővében az erőforrásoknak. Elfogytak a belső változók.
A második eset egy Omron C120 volt, ahol a program memória fogyott el az évek során történt bővítgetések miatt.
Mind a két esetben a program egyszerűsítésével lett megoldva a probléma.Nagyon ritka egyébként. Gyakoribb, hogy a feldolgozási sebesség "fogy el". Tehát túl nagyra nő a ciklus idő. Ilyenkor is lehet megoldás a program egyszerűsítése, de olyankor sokszor jobb a PLC-t cserélni.
Itt egy konkrét példa a gyakorlatból:
Siemens S7-300 CPU 319-3 PN/DP
2 db Profibusz hálózat, A profibuszokon 40 db SEW szinkron servó, 22 db frekvenciaváltó.
1 db Interbus hálózat, azon 800 db digitális ki és bemenet.
1 db ethernet hálózat, azon 2 db operátor panel és a többi PLC +1 Oracle szerverA teljes program STL-be visszafordítva 109764 programsor, a DB blokkok és UDT-k STL forrása 96505 sor.
A CPU-ban 8 MB memória van. Ebből 7717752 byte szabad. (8%-os kihasználtság)
Work memory total: 1433600 ebből 942026 byte szabad (34%-os kihasználtság)
A ciklus idő 17ms (min 14, max 21) -
byte-by
tag
Halo Onishi!
én omron CJ1M PLC-vel jártam így. a gépgyártó kivitelező a legolcsóbb CPU-t választotta a gép építéséhez.
ez esetben a CPU11-et.
én mondtam, hogy kevés lesz, mivel HMI-t is akar a megrendelő, és ki tudja még milyen módosításokat majd.
de nem konzultáltak velem , az alkatrészbeszerzés közben. ez rossz döntés volt.a megrendelő természetesen egy csomó módosítást akart, a fájl kiírástól a HMI bővítésen keresztűl sok mindent.
a következő a CPU12 verzió a CJ1M-ből az már kétszer annyi program memóriával rendelkezik, mint a CPU11.
csak egy kis pluszt kellett volna, amit így sem lehetett elkerülni.esetünkben CPU csere volt szükséges.a program kompatibilis, ezért nem volt gond,de erre sem lett volna szükség , ha jobban átgondolják a dolgot.
szóval érdemes kicsit előre tervezni, gondolkodni.byte-by
-
-
byte-by
tag
halo w3dzz !
a kérdés jó lett volna pontosabban, mit szeretnél.
mindazonáltal a az alkalmazás(gyors gombbal : ctrl+shift+w ) egy monitor módot hoz létre.
a referencia aktív lesz,de a bemeneteket Neked kell izgatnod, és persze minden mást is. de működik minden, a memóriatáblázat, esetleges analóg csatornák konverziója, stb.
force-olni tudod ( force on, force off) a bemeneteket, kimeneteket, változókat, stb.
a memóriákat is online-ba tudod kapcsolni és értéket tudsz megadni, ami hatással lesz a programra.
ehhez a memóriatáblázatot meg kell nyitni és ott a monitor módot bekapcsolni.ha mást szeretnél ne felejtsd el a force-olt bitet force off-olni.
lehetőség van a force-olások feloldására, vagyis a bitnek az lesz az alapértéke.ez a menüben a "cancel" illetve a "cancel all forces".utóbbi esetben minden force feloldódik.FONTOS ! a cancel nem egyenlő a force off-al.tehát ha force on volt egy biten és az 1-ben van, Te utána cancel-t nyomsz rá, vagy cancel all forces-t ,akkor a bit megtartja a force on-olt értékét és 1-ben marad.
az lesz az alapértéke, amíg nem változtatsz rajta. ez fordítva is igaz, ha force off-oltál valamit , cancel esetén csak a force tényét törlöd, a bit marad 0 .figyelmet kell fordítani arra, hogy az adott bitnek minden blokkban ahol szerepel változik az értéke ha force-olod.
a beállítások elvesznek ha kilépsz a szimulátorból.
néhány CPU-t nem lehet szimulálni , mert kapcsolatot igényelnek, ezért lett volna jó, ha leírod konkrétan mit szeretnél, illetve valami problémába ütköztél-e.
byte-by
-
Szirty
őstag
válasz
byte-by
#3433
üzenetére
Helló byte-by!
"FONTOS ! a cancel nem egyenlő a force off-al.tehát ha force on volt egy biten és az 1-ben van, Te utána cancel-t nyomsz rá, vagy cancel all forces-t ,akkor a bit megtartja a force on-olt értékét és 1-ben marad.
az lesz az alapértéke, amíg nem változtatsz rajta. ez fordítva is igaz, ha force off-oltál valamit , cancel esetén csak a force tényét törlöd, a bit marad 0 ."Szeretnék pár dolgot kiegészítésként hozzáfűzni.
Kétféleképpen lehet bitet egy bizonyos állapotba helyezni, annak egyik módja a force ON és force OFF, a másik az ON és az OFF.
Egy bit állapotának megváltoztatására azért van kétféle lehetőség, hogy feloldható legyen az alábbi ellentmondás:Pl. egy bemenet bitjének állapotát a fizikai bemenet tényleges állapota minden ciklusban felülírja ezért nincs látható hatása egy ON vagy OFF átbillentésnek. Ugyanez a helyzet akkor is, ha egy bit nem bemenet hanem olyan, amit a program minden ciklusban ír. Töröl vagy beállít. De ha egy RS tároló bitjét billentjük át (KEEP), amit a program éppen nem ír (sem a SET sem pedig a RESET ágának feltétele nem teljesül) akkor azt ON vagy OFF funkció probléma nélkül átbillenti és a bit úgy is marad, amíg a program másként nem "akarja".
Ellenben a force kényszeríti a bitet az általunk kívánt állapotba. A Force OFF törli, attól teljesen függetlenül,hogy bemenet vagy nem, és hogy a programban mi milyen állapotba írja. Az a bit 0 lesz ha törik, ha szakad.
A Force ON ugyanezt teszi csak 1 állapotot ír bele.
A Force cancel ezt a kényszerítést oldja fel, kiadása után a bit állapota úgy változik, ahogy a program akarja. De emiatt nem mondanám, hogy továbbra is úgy marad az a bit.Tehát a különbség a kettő között az hogy vagy fixen lebetonozzuk vagy csak belerugunk egyet.
-
byte-by
tag
szia Szirty !
" Szeretnék pár dolgot kiegészítésként hozzáfűzni..............."
egyről beszélünk.
azért mondtam, hogy egyről beszélünk, mert pont a FORCE -ra hívtam fel a figyelmet, hogy ez a szimulátor esetén ( és aktív program esetén is pl. egy működő gép, de ott lefut a program) statikus módon megváltoztatja pl. egy bit értékét, amit a CANCEL nem töröl ,csak a kényszerítés tényét, szimulátor esetén, nem lefutó programban.szimulátorban is lefuthat a program ha a feltételek adottak , de ha a szekvencia elakad egy olyan network elött ahol kényszerített bit van ( vagy csak egy network-öt tesztelünk, vagy memória írást, comparátort, MOVE utasítást, stb. ) és amelyre CANCEL-t nyomtak, akkor az úgy marad amilyen állapotba kényszerítették, de erről nem igazán lesz információ.
a probléma , ha ekkor másik SECTION-ba váltunk, mert ez a bit ott is a kényszerített állapotában lesz, különösebb jelzés nélkül.
szóval valami ilyesmire gondoltam, hogy ha semmi nem kezeli, akkor az úgy marad, legalább is amíg a szimuláció tart, vagy amíg konkrétan nem változtatnak rajta.
byte-by
-
byte-by
tag
halo w3dzz !
nekem címezted a kérdést, ami megtisztelő, de Szirty sokkal jobban képben van, a pointerekkel kapcsolatban meg pláne.
mindazonáltal (omron PLC esetében), ha TTIM (087) timert választasz az a reset-elésig megtartja az értékét.
tehát, hogy mennyi maradt még azt tudni fogod , mert visszaszámol.egy memóriába bemásolhatod, resetelés elött.ugyanezt az értéket ,amikor leállítod a timert, kivonhatod a beállított értékből, majd bemásolva szintén egy memóriába,regisztrálhatod mennyi telt el, aztán akár resetelheted.
az indító feltételek mindkét esetben ha újra elindul , akkor borítja a dolgot.
a timerek típusánál érdemes válogatni.a "sima" TIM / (H), a bemenet leállítása után, felveszi a beállított értéket, tehát neked nem annyira jó, ámbár ha egy regiszterbe másolod az eredményt leállításkor (vagy a leállítás feltételével) , akkor szintén elmentheted a kívánt értékeket.persze vigyázni kell a , hogy a ciklus futása ne befolyásolja az újra írásokat vagy indításokat, csak amikor szükség van rá.nem tudom mit szeretnél a pointerekkel kapcsolatban, de én nem igazán használom őket.
byte-by
[ Szerkesztve ]
-
byte-by
tag
halo !
" az indító feltételek mindkét esetben ha újra elindul , akkor borítja a dolgot. "
közben eszembe jutott megemlíteni, mivel a feltételek leállítása mást-mást idéz elő:
TIM esetében a feltétel leállítása törléssel jár, és beállítódik az alapérték. tehát ujrainduláskor előről kezdi.TTIM estében addig lehet ujra és ujra indítani , amíg le nem jár , aztán ha 1-be került akkor resetelni kell, csak akkor fog ujra indulni. természetesen közben is lehet resetelni, ekkor az alapérték állítódik be.
rsf kérdése jogos, de remélem a timer feltételére gondoltál...
ha nem ,... akkor így jártam..byte-by
[ Szerkesztve ]
-
Szirty
őstag
Helló w3dzz!
Szerintem az a legegyszerűbb, hogy a timerrel "párhuzamosan" teszel egy MOVE-ot is, ami a timer PV (present value) értékét folyamatosan mozgatja egy változóba.
A MOVE legyen a timer "előtt". Amint a move feltétele a timer feltételével együtt megszűnik abbahagyja a másolást és a célváltozóban "befagy" a timer akkori értéke amikor a feltétele megszűnt.Indirekt címzés ide nem kell. Vagy nem tudom miért említetted.
[ Szerkesztve ]
-
w3dzz
csendes tag
Szia!
Olyasmit szeretnék megcsinálni, hogy pl van 15db word változó egymás után és egy ciklusváltozó ami valamilyen esemény hatására növekszik. Ezeket a wordoket az esemény bekövetkeztekor kirakná a kimenetre és, hogy ne kelljen ilyen estben 15 komparálást csinálni.
MOV(021) DR0, IR1 100
DR0, IR1 tartalmát összeadja abból lenne egy cím és azt az értéket ami ezen a címen van írja a 100-as wordbe?
Vagy esetleg pl. az 50-es word-re hogyan lehet rámutatni a DR0, IR1-el?
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Mesterséges intelligencia topik
- E-roller topik
- Hobby elektronika
- Nothing Phone (1) - nem semmi (2)
- Ingatlanos topic!
- iPhone topik
- Vigneau interaktív lokálblogja
- Diabetes - Cukorbetegség
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- További aktív témák...
- Lenovo Legion 7, 16,0"WQXGA, Ryzen 9 6900HX, 32 GB DDR5, RX6850M XT 12 GB, 1TB SSD, 1,5+ év garancia
- Corsair RM850e 850W Gold Moduláris Tápegység
- Samsung Odyssey Neo G9 Super Ultrawide Gamer Monitor!49"/Mini LED/5120x1440/240hz/1ms/+Ajándék
- Apple Macbook Pro 16" 2019 i7-9th 6Magos 32/512 -75% Touch Bar HUN Radeon Pro 5300M 4GB 3K Retina
- Apple Mac mini M2 2023 8GB 256GB + Xiaomi Mi Desktop 27"-os FullHD monitor egyben
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen