- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
Hirdetés
-
A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
it Egy felmérés szerint a legtöbb amerikai osztja azon véleményt, hogy a TikTok egy őket befolyásoló eszköz.
-
Nyár végén jön az idei THQ Nordic Digital Showcase
gp Az új bejelentések mellett újabb részleteket kapunk a Gothic Remake-ről és a Titan Quest II-ről is.
-
Egyre közelebb a Poco F6 startja
ma Újabb ár/érték csatát nyerhet a Xiaomi almárka.
Új hozzászólás Aktív témák
-
Szirty
őstag
Helló rsf!
Akkor mégiscsak van ott hiba nem? :-)
Az area length error oka rendszerint elég durva programozási hiba egyébként (indirekt címzésnél könnyű belefutni és nehéz megtalálni).
Azt jelenti, hogy a program valahol olyan (rendszerint DB) címre akar írni vagy onnan olvasni ami nem létezik.Azért nem áll STOP-ra a CPU, mert a hibán valószínűleg tüneti kezelést alkalmaztak oly módon, hogy raktak a programba egy üres OB121-et (programming error OB).
[ Szerkesztve ]
-
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!) -
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? :-) -
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. -
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) -
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ó. -
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 ]
-
Szirty
őstag
Helló rsf!
"...a legegyszerűbb és legfrappánsabb megoldását az alábbi feladatnak:"
Milyen szempontból kell egyszerűnek lennie? Illetve mit értesz pontosan egyszerűség alatt?
A legkisebb végrehajtási idő?
A legkevesebb utasítás?
A legkisebb memória felhasználás?
A legkevesebb segédváltozó?
A legkisebb (legrövidebb) network?
A legérthetőbb kód?
Milyen PLC-n fusson?
Szabad-e funkcióblokkot használni?
Szabad-e PLC specifikus vagy gyári beépített függvényt használni?
Milyen programozási nyelven kell megoldani?
Ha magas szintű nyelv is lehet, melyiknek kell "egyszerűnek" lennie? A generált kódnak vagy a forrásprogramnak?Pl. SCL-ben egy ilyen egyszerű feladat egyetlen sor. De a compiler ennél kicsit érthetetlenebb és hosszabb tárgykódot generál belőle.
Vagy írok egy funkcióblokkot aztán meghívom létrában. Ez egy "érintkező" lesz, meg egy téglalap.van annál egyszerűbb?Egy ilyen "kiírás" eredménye elég egyoldalúan bírálható el, mert mindig írhatod azt, hogy "nem arra gondoltam"...
Szóval ez magas labda.
[ Szerkesztve ]
-
Szirty
őstag
Helló rsf!
"Funkcióblokk természetesen nem ér."
Hmm. Az miért természetes?
Fel vagy lefutó élre kell kapcsolni, vagy mindegy?
Számláló használható-e? Mert hogy azzal is megoldható!
Néhány PLC tud fel vagy lefutó élre 1 scan time impulzust generáló utasítást. Az használható vagy nem?
Ha igen az már PLC specifikussá teszi! -
Szirty
őstag
Helló rsf!
Nem tudom mire megy ki a játék, de álljon itt néhány "alternatív" megoldás is:
Itt az I0.1 kapcsolja ki/be a Q0.1 kimenetet.
Itt szintén az I0.1 kapcsolja ki/be de a Q0.2 kimenetet (egy programba helyeztem a példákat ezért adtam más kimeneti címet mindegyiknek).
Az eltérés az előzőhöz képest az, hogy a második példa nem használja a -(P)- felfutó él impulzus képző utasítást.Itt I0.1 kapcsolja ki/be a Q0.3 kimenetet.
A fenti módszer STL-ben. Az I0.1 kapcsolja ki/be a Q0.4 kimenetet.
Számlálóval, AND/XOR műveletekkel, összehasonlításokkal stb stb is meg lehet valósítani, nem akartam végletekig fokozni...
-
Szirty
őstag
Helló rsf!
Lehet helyettesíteni NOT - JMP párossal.
Amire nyilván azt írod majd, hogy sok PLC-ben nincs NOT. :-)
Ha azt akarod hogy minden PLC-n alkalmazható legyen, akkor kizárólag OR, NOR, AND, NAND (OR, OR NOT, AND, AND NOT) utasításokkal operálhatsz.Az elbírálás szubjektív. Összességében lehet hogy frappánsan rövid a JMP-s megoldás, de létrában a JMP meglehetősen gusztustalan dolog és ha csak lehet nagyon messzire el kell kerülni.
[ Szerkesztve ]
-
Szirty
őstag
Helló rsf!
"Miért? Az átugrott rung-ok ilyenkor nincsenek kiértékelve ergó gyorsabb a scan."
Én tisztában vagyok vele mit csinál a JMP.
Létradiagramban azért gusztustalan, mert ellenkezik az alap koncepcióval. Lehet rakni, de kerülni kell. Rontja az olvashatóságot. Olyan mint pascal-ban a GoTo! Eretnekség :-) Egyébként általában nincs is rá szükség."JMP-t STL-ben elég sűrűn láttam"
STL-ben alap.
Azért mert STL-ben van, még ne tegyük létrába. A kettő nem függ össze, nem is értem miért hoztad fel. -
Szirty
őstag
Helló rsf!
"Pedig most kérés felém, hogy a gráf lépéseket jmp-vel csináljam meg létrában. Mert náluk az a szokás."
Pedig annál sincs szükség ugrásokra ha az ember létrában kénytelen szekvenciális programot írni.
"Kár ezen vitatkozni. Izlések és pofonok."
Én nem vitatkoztam. Tény amit írtam. :-)
-
murena2
csendes tag
Ez egy jó info. Azért mindenki tud valami marhaságot kitalálni. Már az gyanús volt hogy a prog szofverem a micrologic 1400 seria "A" van benne a rockwell honlapján meg már kint van belőle "F" is.
Melyik a legfrissebb vezrió logix 500-ból? Bár nem sokmindent lehet torrenten megtalálni belőlük.
Vettünk egy új HMI-t is az nincs benne a factorytalk view 6-ban, a legújabbat (7.1 asszem) nem találtam sehol.
Nem lehet esetleg hardver elemet hozzáadni mint a siemensbe?[ Szerkesztve ]
-
Onishi
tag
Hát ez így nekem továbbra sem működik.
Viszont beletettem próbaképp egy külön sort, hogy a léptetést egy másik bittel aktiválom, és úgy sem akar 1-es állapotba váltani a C1_up. Így valami más lehet a probléma. Elég érdekes ez a jelenség, hiába jelzi a létradiagramban a Network 5-ben, hogy aktív, valójában mégsem az:Viszont a --(CU), léptetővel engedi léptetni a számlálót, szóval azt fogom használni.
[ Szerkesztve ]
-
artiny
őstag
Koszonom a valaszod. Meg nagyon kezdo vagyok ebben,most probalom tanulni szoval meg van valami ami nem vilagos teljessen....
Ha egy negálást ---I/I---- zoldre állitom,azzal logikai 1 értéket adok neki?(szoval 0-át a negálás végett,tehat ha nincs zoldre állítva akkor logikai értéke 0,értéke:1 )
2.) ha nincs zold értékre kapcsolva(aktivalva,togglezva) akkor az értéke egy bitnek ---II--- 0,ha viszont zold akkor 1 ?
Ha létrehozok egy változót,akkor nem kell értéket adnom neki...azt menet kozben teszem azzal hogy a zöldeket állítom ki -be egy egy bitnél? -
artiny
őstag
A kepen levo kezdoertekekbol kell kiindulni.
byte-by
A pocitadlo nem valtozott (a 10es érték)
Az accum idovel valtozik...de ha felmegy 10 fole akkorsem fog a led vilagitani...bar lehet rosszul szimulaltam le,de ugyan ugy allitgattam,rajzolgattam be mindent ahogy a kepen volt.[ Szerkesztve ]
-
Shirchy
tag
Köszi!
Írtam privátban is neked!
Utánna olvasva a Jazz-nek egész jókat írnak róla,szóval lehet az lesz az itthonra megvételezett okosság.
Természetesen később nem tudom majd kikerülni a siemens-t és az omron-t sem,így azokat is meg kell majd tanulnom,de kezdésnek így ránézésre a LOGO marad szoftveresen,a JAZZ meg fizikailag gyakorolni.Jah igen azt eddig nem írtam,hogy villamosmérnöki levelezőn vagyok, ezért szeretnék gyakorlati oldalról ismerekedni a PLC-kel,mert megvallva az őszíntét... levelezőn a gyarolat nem sok mindenre jó.
Üdv
"jobb adni,mint kapni" mondta a boxoló... :P
-
artiny
őstag
koszonom a válaszokat,
igen azt hiszem AB
egy utolso ilyen feladat:
http://i.imgur.com/XE07Rve.pngKet szállíto D1,D2. Optikai szenzor S1 >> ture állapotban = foglalt
S2 >> ture állapotban = foglalt
Alkosson programot a szallitmany hosssza alapján D1 >megáll a kozepen D2 nek. A tovabbitas soran megall D.
(feltelezzuk hogy a szallitok elvannak inditva,vár a szállítmanyra es ha a felere ert a D2.nek a szallitmany .1 szallitmanyt kell venni mint ket D hez)[ Szerkesztve ]
-
Szirty
őstag
Helló rsf!
Tipikus. Valószínűleg ide mindenhol eljutnak.
Nálunk is sokszor szoftveresen oldunk meg problémákat.
Szerintük. Valójában csak a mechanikai hibák következményeit próbáljuk elfedni. Tüneti kezelés rox!Laza a lánc? Tegyünk be egy timert és kész is :-)
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Iphone 11 fehér 128 GB független
- Eredeti - Apple USB-C kábellel és Magsafe 2 - minden típus - macbook töltő - garancia
- Macbook Pro 16" - 2020 gyártás, i9 és i7, 32/512GB, 4GB Radeon, touchbar, garancia, szürke
- Macbook Pro 15" - 2019, 8 mag i9, 32/512 GB, 4GB Radeon, 90 ciklus, garancia, doboz, szürke (65)
- Macbook Pro 15" - 2018, 6 mag i7, 16/256 GB, 4GB Radeon, 83 ciklus, garancia, ezüst (02)