- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Andras-G: Az internet veszélyei [2. rész] - Facebook Marketpalce
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- mefistofeles: Az elhízás nem akaratgyengeség! 2 Ahogy én csinálom.......
Új hozzászólás Aktív témák
-
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. -
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!
É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!
"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!
"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!
"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!
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!
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).
-
Szirty
őstag
válasz
n0rbert0
#3387
üzenetére
Helló n0rbert0!
Jó irányba indultál ez a módszer megfelelő lesz.
De van néhány megjegyzésem:A 3-as rung-ban a BIN(023) W6 W6 szerepel ha jól látom. Ez így a W6 BCD tartalmát (ide másoltad a timer pillanatnyi értékét (Present Value) ami BCD, ez ok. De a BIN a W6-ba teszi vissza a konverzió bináris eredményét. Még ez sem lenne baj, de BIN előtt always on flag van, tehát ezt az utasítást a PLC minden ciklusban végrehajtja, miközben az 1-es rung-ban lévő MOVE csak egy felfutó élre. Ezért ha már egyszer átkonvertálta a BCD számot binárisra, akkor, a következő ciklusban újra át akarja konvertálni de akkor ott már bináris szám van.
Sajnos néhány bináris szám értelmezhető BCD számnak is, más bináris szám pedig nem.
Ezért én a BIN-t a MOV alá tenném, hogy mindig egyszerre és egymás után hajtsa végre őket.De egyszerűsíthető is a dolog, mert nincsen szükség a MOV-ra mivel a BIN az eredményt máshol is tárolhatja nem csak ott ahonnan a forrást veszi, így a BIN egyben MOV is
A timert én elengedném a max értékig #9999
Ha nem akarsz BCD-BIN konverziókat, akkor használhatsz bináris timert is (TIMHX).
Vagy 1ms felbontású bináris timert (TIMHHX)Bár a mérés pontossága nem lesz 1ms, mert a CPU ciklus edejével szórni fog.
"A reciprok műveletet hogy lehet legegyszerűbben megoldani?"
Elosztod 1-el az értéket
Persze érdemes lebegőbontos számmal csinálni, -
Szirty
őstag
válasz
n0rbert0
#3384
üzenetére
Helló n0rbert0!
A modul képessége egy dolog.
De hiába képes a modul 8ms késleltetéssel beadni a jelet a PLC-nek ha a PLC ciklus ideje pl. 70 ms!
Akkor a PLC-nek 140 ms időre van szüksége, hogy garantáltan észrevegyen egy teljes jelperiódust.
Éspedig a PLC ciklus idejét annak feldolgozási sebessége és a rajta futó program határozza meg és ráadásul általában még csak nem is konstans!
Több üzeneten keresztül épp erre próbálom felhívni a figyelmed.
Lehet javítani valamennyit a helyzeten a bemenet közvetlen kiolvasással és megszakítás kéréssel (ha a bemenet erre képes). De ha a ciklus idő a feldolgozandó jel periódus idejével összemérhető, akkor hardveres feldolgozás szükséges, és nem másért, hanem ezért említettem a high speed countert, ami éppen ilyen. -
Szirty
őstag
válasz
n0rbert0
#3382
üzenetére
Helló n0rbert0!
100Hz-et biztonsággal csak akkor tudsz érzékelni, ha a PLC ciklus ideje 5ms-nál kisebb és akkor a bemenet késleltetését nem is számoltam.
Ha ez teljesül, akkor ok.Szóval meg kell mérned, hogy adott idő alatt hány darab impulzus jön. Pl. másodpercenként méred, akkor a kapott szám a frekvencia lesz Hz-ben.
Pl. jön 28 impulzus másodpercenként, akkor a frekvencia 28 Hz.De mérheted (elvileg) az impulzusok között eltelt időt is, akkor annak reciprokaként kapod meg a frekvenciát.
Pl. ha ezred másodpercben méred akkor kHz-ben kapod az eredményt. Mondjuk két impulzus között mérsz 20 ms-ot, akkor a frekvencia 1/20=0.05 kHz = 50 Hz.
De ilyen rövid időt nem fogsz tudni mérni szoftverből PLC-vel. -
Szirty
őstag
válasz
sörösló
#3373
üzenetére
Helló sörösló!
Pedig sok jelkábel ere 0.25-ös (pl. encoder kábel, analóg méréshez használt kábel ere).
Vagy a pneumatikában, hidraulikában használt hall elemes érzékelők gyári beépített vezetékének ere 0.1mm2 sincs. Már a 2A-es olvadóbiztit sem tudja kiköpni, a vezeték teljes hosszában füstöl és beleolvad a többi érbe :-/ -
Szirty
őstag
válasz
n0rbert0
#3375
üzenetére
Helló n0rbert0!
Nem tudom hogy van-e ilyen utasítás vagy kész funkció, de megoldható:
- HW-es gyors számláló bemenettel
- Szoftveresen ha a jel frekvenciája kicsi (<10Hz) a kitöltési ideje tényezője pedig olyan, hogy a rövidebb idejű állapot garantáltan és mindig meghaladja a PLC legnagyobb várható ciklus idejét. -
Szirty
őstag
Szevasz Onishi!
Nos az alkalmazott vezeték keresztmetszetén "át kel hogy férjen" akkora áram, amekkora a vezeték védő biztosíték (olvadó betét, vezeték védő megszakító, stb) névleges árama.
Ha nem így lenne, akkor egy zárlat tüzet okozhatna.Bemenetekhez néhány A-es védelem és 0.5 mm2 vezeték megfelel. A választott védelemnél és a keresztmetszetnél figyelembe kell venni a bemeneti modul fizikai adottságait. Pl. egy 32 pontos bemenetre valószínűleg nem lehet bekötni 32 darab másfeles vezetéket!
-
Szirty
őstag
Helló coco2!
Nem nagyon kaptál választ ahogy látom. Sajnos sokszor nehéz mindenre 100%-osan alkalmazható általános érvényű szabályt alkotni.
Annyit mondhatok, hogy az iparban a galvanikus leválasztás mind a mérésnél mind a kommunikációban alapvető és tulajdonképpen kötelező.Jó lehet hogy ha a laptop RS232 portja nem leválasztott nem lesz baj ha rádugjuk a frekiváltóra pár percre amíg foglalkozunk vele, de sokkal valószínűbb, hogy lesz. Főleg ha a laptop tápegységén nincs földelés és főleg, ha abban zavarszűrő kondikat alkalmaztak amik a bejövő fázisról és nulláról vannak a belső GND-re vezetve. Ezzel 100V körüli feszültséget hozva létre a GND-n. Egy ilyen potenciálkülönbség csatlakoztatáskor röhögve agyonverheti akár az eszköz meghajtóját, akár a laptop RS232 portját.
"Ha munkagépek környezetében mindenütt nagyon erős a földelés, akkor persze ilyen probléma aligha vetődik fel"
Ez nem teljesen van így!
Hiába van 240 mm2 rézzel bekötve a betáp és így a PEN is, meg van EPH, a gépek között kiegyenlítő áramok folyhatnak ez több tíz A is lehet, ami több V-os potenciálkülönbséget hozhat létre a földpontok között.
Ez komoly zavaró jel egy analóg mérésnél vagy kommunikációs kapcsolatnál.Gyakorlatilag minden ipari PLC be és kimenete legyen az digitális vagy analóg le van választva a PLC elektronikájától.
-
Szirty
őstag
válasz
n0rbert0
#3363
üzenetére
Üdv ismét n0rbert0!
Nem írtam, de a 100-as és 200-as CH bitjeit nem használhatod másra természetesen.
Itt egy másik megoldás ugyanarra a léptetésre:
Ha ez jobban tetszik, esetleg egyszerűbbnek tartod használd ezt.
Ugyanúgy működik. A 0.00 és a 0.01 bemenetek léptetik jobbra és balra. Itt is a 100.00-100.03 biteken jelenik meg a léptetett bit. Ez nem használ SFTR vagy más bit léptető utasítást, Nem használja csak a 100-as CH-t, (nincs 200-as control word).
Persze 100CH-ból itt is csak a 100.00-100.03 biteket használhatod fel (a többi bitet is írja, nem tudod a programban másra felhasználni). -
Szirty
őstag
válasz
n0rbert0
#3363
üzenetére
Helló n0rbert0!
Szerintem azért nem úgy működik ahogy szeretnéd, mert a léptető utasításod minden egyes PLC ciklusban lefut.
Amikor a P_1s-el kapcsolod a léptetését (W4.14-et). A P_1s 1 másodperces 50% kitöltésű impulzus sorozatot ad. Tehát fél másodpercig ON fél másodpercig OFF állapotban van. Amikor ON állapotban van (tehát fél másodpercig minden egyes lefutáskor léptet egyet az SFTR utasítás, mert a léptetés feltétele adott. Aztán fél másodpercig nem csinál semmit, majd fél másodpercig megint léptet egy csomót (hiszen fél másodperc alatt sok PLC ciklus lefut).
A megoldás az, hogy vagy "kukacos" SFTR-t használsz, ami csak egyszer fut le minden engedélyező felfutó élnél, vagy magát a léptető impulzust DIFU-zod meg, hogy csak egy PLC ciklus ideig legyen aktív.Itt egy konkrét példa erre:
A példában a 0.01-es bemenet jobbra léptet, a 0.02-es bemenet balra léptet.
A léptetett bitek a 100.00, 100.01, 100.02 és 100.03 bitek. Amikor végig ér, ugrik az elejére az iránynak megfelelően. -
Szirty
őstag
Helló Onishi!
Napjaink legjobb perverziója Win7 alatt virtuális gépen XP-t futtatni és az alatt használni a szükséges programokat.
"Olyan kérdésem lenne, hogy az S7 PLC-kbe rakható memóriakártya pontosan mire is szolgál?"
Attól függ melyik CPU és milyen memória kárty? MC, vagy MMC?
Gondolom az előbbi, mert amelyik CPU MMC-s aznem megy MMC nélkül.
Az MC-s CPU meg (bár ez CPU függő) mehet kártya nélkül is.Tehát a kérdés miatt azt kell blöffölnöm, hogy az utóbbi kártyáról beszélünk (MC).
Arra jó, hogy tárolj a PLC programot, ami alapvetően RAM-ból fut, és háttértelep védi. De a Step7 "Copy RAM to ROM" funkciójával vagy egy jól irányzott PG-be bedugott MC memóriakártyával és Step7 S7 memory card funkcióval a memória kártyára másolható a project.Ilyen esetben ha a háttértelep kimerül és a PLC feszmentes lesz, a RAM tartalma elvész a programmal és adatokkal együtt. Legközelebbi bekapcsoláskor a CPU az MC memória kártyáról szépen visszatölti RAM-ba a programot és a vezérlés működőképes marad. Természetesen a DB-k aktuális tartalma megsemmisül és az MC-ről visszatöltődött tartalommal fog dolgozni.
"Például el lehet rá menteni bizonyos mérési adatokat, amit később ki tudok olvasni?"
Adatblokkok formájában lehet.
-
Szirty
őstag
válasz
Dezsi82
#3354
üzenetére
Helló!
Szerintem az inkrementális jeladók felbontását impulzus/fordulat (pulse/revolution) értékben adják meg attól teljesen függetlenül, hogy egy fázisú, vagy két fázisú (A és B) jelet ad.
Így ha a gyári adatban szerepel mondjuk 200 p/r és a jeladó két fázisú jelet ad, akkor mindkét fázison egy teljes fordulat alatt 200 teljes periódust lehet megszámolni. Az A és a B jelek fordulatonkénti periódusainak számát nem adják össze sose.No de van (amit Dezsi82 is említett) amikor a két fázisú jelnél nem a periódusokat számolják, hanem a jelváltásokat (éleket). A két fázisú jelben egy fordulat alatt négyszer annyi jelváltás van, mint amennyi a jeladó felbontása. Így a felbontás megnégyszerezhető (quadratic count).
A sebesség mérése nem hiszem hogy gond lenne, egyszerűen meg kell számolni adott idő alatt mennyi impulzus jön. Abból kiszámolható.
-
Szirty
őstag
válasz
ebyborz
#3346
üzenetére
Helló ebyborz!
Annak alapján amit leírtál én is csak annyit tudok mondani,hogy: Akkor valami nem jó.
Ha többet szeretnél kapni, akkor előbb többet kellene adnod. Pl. hogy:- Milyen PLC? Az hogy S7-200 meg S7-300 nem elég! Milyen CPU, (CPU222, CPU315-2, stb) segít a rendelési kód is (Pl. 314-6CG03-00AB0)
- Milyen kapcsolattal próbáltad a kapcsolatot? (MPI, PPI, DP, Ethernet?)
- Pontosan milyen kábeled van? PC-Adapter MPI, PC Adapter USB, TS adapter, PC/PPI cable, vagy valamilyen CP? Pl. CP5611 esetleg valami ethernet gateway, stb? Esetleg használsz soros USB átalakítót a kapcsolathoz?
- Hogyan próbáltál meg kapcsolódni? Pontosan hogyan állítottad be a kapcsolódás paramétereit (PC/PG interface-ben).
- Miből derült ki számodra hogy nem kapcsolódik, volt-e hibaüzenet és ha volt, akkor pontosan mi?"Sem a Simatic sem a microwin szoftver nem akarja felismerni a plc-t."
Nem nagyon ismerkednek ezek. Vagy kapcsolódik hozzá vagy nem. Nem neki kell ismerni, hanem neked és annak megfelelően beállítani mindent.
-
Szirty
őstag
válasz
Szabest
#3344
üzenetére
Helló Szabest!
Itt egy példa.
Ez a DB100-ban lévő IttKeres nevű 50 elemű tömb első 29 byte-jában keresi a 7426-os számot.
Mivel mint írtam a keresés hosszát a keresés forrását adó pointer első elemében kell megadni, ami a DB módosítását kívánná, a keresés előtt a program átmásol a DB-ből annyi adatot lokális változóba, amennyiben keresni kell, elé rakja a keresés hosszát meghatározó 29-et és azután ebben a lokális változóban keres:
Nem magyarázom szénné, kérdezz ha valami nem érthető benne:
A program bekapcsolja a Q4.0 kimenetet ha megtalálta a számot és kikapcsolja ha nem találta meg.
Ha ez van a DB-ben:
A PLCSIM-en látható, hogy a 7426-ot megtalálta a 28-as táblaelemben:
Ha a 7426-ot átrakom a 29. elem utáni valamelyik címre, akkor nem találja meg, mert csak az első 29 elemet nézi át...
-
Szirty
őstag
válasz
Szabest
#3342
üzenetére
Helló Szabest!
"azt irod hogy bárhonnan tud keresni, de akkor jól látom, hogy a bármeddig adatot, hogy pl 60byte hosszan keressen, azt nem tudom megadni neki?"
A TBL_FIND SRC paramétere által adott struktúra első eleme a keresés hatásköre, azaz hogy mennyi elemen belül kell a keresést végrehajtani.
-
Szirty
őstag
válasz
Szabest
#3340
üzenetére
Helló Szabest!
Annyit tudok biztosan mondani, hogy amit szeretnél azt meg lehet csinálni a TBL_FIND függvénnyel.
Sajnos nem annyira egyszerűen, hogy megadsz neki pár paramétert és pont azt a DB-t pont úgy fogja használni ahogy te szeretnéd, kell egy kicsit gépészkedni hozzá. A feladat amit meg akarsz oldani elég specializált, ez a függvény pedig meglehetősen nagyvonalúan általános. Meg is írhatod a kereső függvényt magad is, ez a másik lehetőség. Nem nagy ördöngösség, de kell hozzá egy kis gyakorlat.
De hát éppen ez adja a szakma szépségét (szerintem)A TBL_FIND bárhonnan kezdheti a keresést és bármennyi adatot át tud nézni (már ami a DB-k és struktúrák méretének korlátain belül van).
Én a hasonló feladatot (amikor általam nem ismert blokkot kell használni) először ismerkedés céljából egy külön teszt programot készítek és szimulátorral (vagy teszt célra összeállított PLC-vel) kipróbálom hogyan működik, hogy kell használni. -
Szirty
őstag
Helló Onishi!
Igen, a "driver" benne van STEP7-ben.
Nem tudom nálad miért másmilyen. A PG/PC interface ablakon van egy Add/Remove lehetőség, ahol új adaptert lehet hozzáadni és levenni a telepített adapterekhez.
Nézd meg azt, hátha találsz valamit. Sajnos egyelőre nincs jobb tippem:
-
Szirty
őstag
válasz
byte-by
#3331
üzenetére
Üdv!
"Terminal rendben elküld minden adatot, a receiver-rel lehet valami."
Nos szerintem az, hogy karakterenként vesz, így mindig az utoljára elküldött betű marad látható, miközben a komplett szöveg átmegy, csak nincs aki elpakolj a vételi pufferből az érkezett karaktereket. :-)
Nyilván programot kell írni erre. Ráadásul valami alapszintű protokoll is kellene, mert honnan tudná a vevő, mikor nem jön több adat?
Kell valami "delimiter". Azaz határoló jel, ami lehet szünet, vagy egy adott karakter vagy karakter sorozat.
Pl. ha csak a "helló!" szöveget kell átküldeni (mindig csak ezt) akkor felállítható olyan szabály, hogy a felkiáltójel jelzi az adás végét, és a program szépen addig rakosgatja egymás után valahova a vett karaktereket, amíg az meg nem érkezik. Kezdetnek, tanulásnak megteszi, de a gyakorlatban ez nem lesz elég. -
Szirty
őstag
Üdv Onishi!
"A beállítások pedig megfelelőek. "Set PG/PC Interface" ablakban PC Adapter.MPI.1 van beállítva, a sebesség megegyezik a CPU tulajdonságaiban az Interface-nél beállított sebességgel(19,2 Kbps)."
Ez így nem hiszem hogy jó!
Tehát ez egy PC adapter RS232C porttal.
Lényeges, hogy a kommunikációnak két oldala van:
1. PLC <-> PC Adapter (ez most MPI)
2. PC Adapter <-> Számítógép (PC) (ez pedig RS232)Nem kell és nem is tanácsos a kettőt egyformára állítani.
Az 1. oldal (MPI fül) alapból 187.5 kbps ezt így is kell hagyni. (Nem 19.2 kbps!!)
A cím (address) alapból 0, ezt is így kell hagyni, ez a PC Adfapter MPI címe lesz. A PLC címe alapból mindig 2 azt is úgy kell hagyni ha csak egy PLC van az MPI buszon. Nyilvánvaló, hogy két azonos című eszköz nem lehet a buszon, és ebbe a PC Adapter is beletartozik, mivel az is egy eszköz a buszon.
A 2. oldal beállításai a Local Connection fülön van.
Ott kell beállítani, hogy a PC melyik soros portjába dugtad be a PC adaptert. csak akkor fog működni ha ez megfelelő (USB soros átalakító többnyire felejtős).
A sebesség itt alapból 19200 (Transmission rate). maradhat úgy, de van olyen PC adapter, amin külön DIP kapcsolókkal hardveresen is be kell állítani a sebességet, ilyen esetben ide azt kell beállítani, amire a kapcsolókkal az eszköz fizikailag be van állítva!
Ha nem jön össze lehet próbálgatni még a 9600-at is.
"CPU tulajdonságaiban az Interface-nél beállított sebességgel(19,2 Kbps)"
Ezt nem teljesen értem, de a CPU MPI buszának kommunikációs beállításit ne állítsd el, különben sose fogsz kapcsolódni hozzá, mivel az gyárilag 187.5 kbps-sel megy. ha te átállítod 19.2k-ra, akkor az fog történni, hogy a PC adapter a CPU-t 19.2k-val fogja megszólítani, de az nem fog rá válaszolni, mivel 187.5 kbps-en kommunikál.
Persze be lehet állítani az MPI busz sebességét alacsonyabbra akr 19.2k-ra is ha indokolt, de az egy teljesen másik történet.
-
Szirty
őstag
válasz
JAGER 10
#3323
üzenetére
Helló JAGER 10!
"A számítógépről Terminal programmal küldenék adatot a PLC felé, de az adott tartalom utolsó karakterét tárolja el D regiszterben. "Hello!" esetében a "!".
Ez mitől lehet?"A programtól, amit erre a feladatra a PLC-be írtál.
Mi nem tudjuk mi az amíg el nem árulod! -
Szirty
őstag
válasz
Szabest
#3326
üzenetére
Helló Szabest!
A fő kérdés az, hogy milyen típusú tömbben milyen típusú adatot akarsz keresni milyen módon honnantól meddig :-)
A "milyen típusú tömbben" kérdésre elvileg van válasz:
sorte fuer camera.sorteR4:Array˙[0..29] Of Int
Tehát integer típusú adatokat tartalmazó tömbben akarsz keresni ha jól értem, ami 30 elemű."milyen típusú adatot akarsz keresni" kérdésre nincs, mert egyrészt "4jegyű számokat, és mindig 4 jegyű számra szeretnék keresni benne", másrészt korábban négy darab CHAR típusú elemet emlegettél itt.
Integer tömbben integer adatot tudsz keresni, másnak nagyon nincs értelme. Az INT típus pedig nem ismer olyat, hogy "mindig 4 jegyű" szám. Az 1-999-ig nem négyjegyűek. Tulajdonképpen az INT-ben lévő érték számjegyeiről nincs is értelme beszélni, mert azok csak leírva (ASCII karakterekké vagy BCD digitekké alakítva nyer értelmet, hiszen az integert alapvetően nem is decimálisan, hanem binárisan tárolja te pedig nyilvánvalóan decimális számok számjegyeire gondolsz).
Más szóval, ha a bemenő adat (amit keresni akarsz) nem INT típusú, akkor először azzá kell alakítani. A korábbiakból úgy tűnik, hogy neked négy CHR karakter formájában jön a keresendő érték ASCII-ban kódolva vagy binárisan. Ez nekem még nem világos."milyen módon" kérdésre részben válaszoltál. De kérdés, hogy milyen eredményt szeretnél a kereséstől.
Az nyilvánvaló, hogy szeretnéd tudni, hogy benne van-e (vagy nincs benne). De érdekel-e, hogy ha benne van, akkor hol (hanyadik tömbelemben) vagy nem.
Illetve mi legyen ha nem csak egyszer van benne, hanem többször is? Vagy az nem érdekel?"honnantól meddig" ezt csak feltételezni tudom, hogy az említett tömb elejétől a végéig szeretnéd a keresést elvégezni.
Amit mellékeltél képet az hasznos, de sokkal több kérdést vet fel, mint amennyire választ ad, mivel szimbolikus címzésmódot használ és UDT-t is, vagy/vagy instance DB-t is használ. Így nem lenne rossz tudni milyen blokkban van ez és annak a blokknak pontosan hogy néz ki az interface része.
Addig biztosat annyit tudok mondani, hogy az a DB blokk, amiben az a tömb van, amiben keresni akarsz fix, már kész blokk, azaz a programot amihez a keresés kell nem most te készíted (ezt nem írtad, de a képekből úgy tűnik, hogy egy programot módosítani akarsz, nem te írtad) akkor romlik kissé a helyzet.
Mivel a TBL_FIND a keresés forrását jelentő, SRC paraméterben adott kezdőcímű E_TYPE típusú adathalmaz első elemének egy WORD típusú adatnak kell lennie (az E_TYPE által meghatározott típustól függetlenül) ami megadja az adatterület hosszát.
Ha a kérdéses DB nem módosítható, akkor ez a feltétel nyilván nem teljesíthető.Ebben az esetben azt lehet tenni, hogy létrehozol az INT tömbbel azonos elemszámú tömböt a TEMP változóterületen, ami elé teszel egy WORD változót. A WORD változóba beírod a tömb elemszámát (MOVE), majd az azt közvetlenül követő TEMP tömbbe blokk másolás BLKMOV funkcióval belemásolod a DB-ből az egész tömböt, végől az FC 86 SRC paraméterének megadod TEMP tömb előtt lévő WORD-re mutató pointert.
(Írnék erre példát, de nem akarok minden vakvágányt kidolgozni, az én időm sem végtelen... Majd ha a függő kérdések is tisztázódnak)
-
Szirty
őstag
válasz
Szabest
#3319
üzenetére
Helló Szabest!
Ha pontosabban is leírhattad volna mit szeretnél, akkor egyből arra válaszoltam volna...
Szóval igen ha DWORD-ként adod meg a keresendő patternt az FC86-nak, akkor is megkeresi.
Említettem egyébként, az adattípust az E_TYPE paramétertartalma adja meg a blokknak:
B#16#02 = BYTE
B#16#04 = WORD
B#16#05 = INT
B#16#06 = DWORD
B#16#07 = DINT
B#16#08 = REAL
Ez esetben a PATTRN is DWORD kell hogy legyen.
Viszont ha DWORD-ként adod meg a négy karaktert, akkor négy karakterenként és nem egy karakterenként fogja keresni a mintát.
Pl. ha négy karakterenként keresel, akkor nem mindegy hol kezded a keresést.
Tehát továbbra is kérdés, hogy hogyan is akarsz pontosan keresni. -
Szirty
őstag
Helló Szabest!
Valami szétcsúszott a prohardveren, mert válaszolni nem lehet, csak új üzenetet írni.
Szóval én verzióm a következő:"Kérdésem, hogy van-e ilyen gyári FC, SFC, amivel végig tudok "scanneltetni' egy DB-t hogy szerepel-e benne a beadott szám?"
Igen, van olyan, amelyikkel meg lehet csinálni. Az TI-S7 Converting Blocks / FC86 TBL_FIND meg tudja csinálni.
Ez adott mintát (sorozatot) keres egy táblázatban. A minta természetesen lehet egy elemű is.
A táblázatban és a mintában BYTE, WORD, INT, DWORD, DINT, REAL típusú elemek lehetnek.
Egy lényeges kikötés van, hogy a táblázat első elemének a táblázat hosszát (a keresés hatókörét) kell megadnia. Tehát abból tudja mennyi adatot nézzen át.
A blokk hívása így fest:
SRC: a táblázat, amiben keresni kell
PATRN: A minta amit a táblázatban keres
CMD: A keresésre vonatkozó parancs, ami B#16#01 = azonosság keresése, B#16#02 = eltérés keresése lehet
E_TYPE: Az adattípust adja meg, B#16#02 = BYTE, B#16#04 = WORD, B#16#05 = INT, B#16#06 = DWORD, B#16#07 = DINT, B#16#08 = REAL
INDX: EGy in/out paraméter. Az itt megadott számú elemnél kezdi el a táblázatban a keresést és ide teszi bele, hogy hanyadik elem felel meg a keresési kritériumnak.
RET_VAL: Itt mondja meg, hogy talált vagy nem találta a keresett mintát, illetve ha egyéb baja van W#16#0008 - Nem talált semmit, W#16#0000 - Talált.INDX értékét akkor kell figyelembe venni, ha RET_VAL értéke W#16#0000
A példában szereplő hívásnak ez a DB tartalom került átadásra:
Ahol az INTArray definíciója ez: INTArray[0..100] INT
Természetesen a keresés helye nem kell hogy tömbdefiníció legyen az FC 86-nak ANY típusú pointerrel bármit meg lehet adni, de a tábla nem tartalmazhat eltérő (vegyes) típusú adatokat.
Ez a kép működés közben készült:
A blokk az 1997-es számot kereste és találta meg a táblázat 14-es elemében.
-
Szirty
őstag
Helló TanisG!
"A Step7 jelenleg a virtuális gépen van telepítve,de ebből a környezetből (még új a gép) még nem használtam a Step7-et. Szóval kérdés, hogy mi lesz."
Többen próbálták és azt írták,hogy működik az USB-s interface. Kilát a virtuális gépről.
Nem tudom hogy magyarázat-e a külső táplálás hiánya a sikertelenségére.Illetve az biztos magyarázat lenne, de hogy ott ez lehetett-e a gond nem tudom.
Nem nehéz felismerni ha táphiánya van, mert olyankor semmilyen LED nem világít rajta :-) -
Szirty
őstag
Helló Onishi!
"Ahogy nézem, a legolcsóbb megoldás az MPI/Soros programozó kábel, soros-ethernet átalakító kombó lenne. Csak ugye a sebesség miatt nem biztos, hogy jó választás lenne."
A sebessége a HMI számára biztosan elég lesz.
A lassúsága programozáskor abban nyilvánul meg, hogy sokáig tart neki felépíteni a kapcsolatot. Tehát nyomok egy Ctrl-F7-et (monitor) és eltelik sok másodperc, mire felépíti a kapcsolatot.
Ilyen soros PC PC adaptert van a legnagyobb esélyed használtan (és így olcsón) venni egyébként, ilyet többször láttam már hirdetésben."Vagy húzni kell a mostani LAN hálózat mellé 2 jó hosszú USB kábelt is, mert a földszinti és az emeleti géppel is kell tudnia kommunikálni a PLC-nek."
Az USB-t nem lehet pár méternél messzebb vezetni.
Ezért van az a megoldás is, mint a linkjeid között, ahol UTP kábellel jel oda-vissza alakítás segítságável viszik el, de ott is max 45 méter. -
Szirty
őstag
Üdv TanisG!
Én is ilyen (6ES7972-0CB20-0XA0) PC Adapter USB-t használok. A korszerűségével nem akadt gond, megy MPI-n, profibuszon és PPI-n is problémamentesen. Lehet programozni rajta keresztül és HMI kapcsolatra is megfelelő.
Kettő probléma van vele:
1. A tápfeszültséget (24V DC) az MPI/PPI/DP csatlakozóján kapja és nem a PC felől az USB felől az 5V DC-t.
Ez akkor kellemetlen, ha nem a PLC-nél akarunk egy MPI vagy profibuszra rácsatlakozni, hanem valamilyen perifériánál (Pl. ET200-nál) Abban ugyanis nincs bekötve a +24V és így az adapter tápfesz nélkül marad, rajta meg nincs külső táp csatlakoztatási lehetőség.
Én emiatt "meghekkeltem" egy siemens PG-s (továbbmenő csatlakozóval ellátott) csatit és azon beküldök neki egy 24V-os adapterről tápot ha kell.2. Nem tudj aa 12 MBPS sebességet. Ahol tehát ilyen 12 MBPS profibusz van és más lehetőség (pl. MPI) nincs, akkor oda nem lehet vele csatlakozni. Ez elég ritka egyébként, ebbe még nem futottam bele.
A harmadik gond meg feltételes, mert nem tudom, hogy a driverei működnek-e Win7, Win8 alatt, ha netán olyat használnál.
"Használ-e valaki Helmholz kommunikációs adaptereket? Ha igen mennyire megbizható a működésük?"
Igen. Helmholz Netlink PRO-t évekig használtunk.
Megbízhatóan működik. mivel már kérdezték ezt tőlem engedelmeddel idemásolom az akkori válaszomat:"A NetLink pro nagyon hasznos kis eszköz. Gyak. a legjobb amit ebben a témában próbáltam (bár túl sokfélét nem próbáltam). Azzal meg annyi bajom volt, hogy nagyon melegszik. Mint a rezsó! 24 órás üzemre volt beállítva távfelügyeletet ez tette lehetővé az internet felől. Másik problémám az volt vele, hogy Windows server 2003-al a drivere nem működik. Nem lehet telepíteni (az újabbakat se)."
Ez több éve volt, azóta fejlesztették, talán mentes már ezek alól a problémák alól.
Sajnos (magánembernek) húzós ára van. -
Szirty
őstag
Helló Onishi!
Szóval az alábbiak:
Delock 61147 USB - Ethernet átalakító (1. Link)
LevelOne USB-0401 USB 2.0 átalakító Gigabit Ethernet-re (2. Link)
USB LAN Ethernet adapter konverter átalakító (4. Link)semmiképpen nem jók, mert ezek mindegyike egy USB-s hálózati adapter PC-hez (pontosabban Windows-hoz). Ez azt csinálja, hogy a hozzá adott szoftvert (drivert) windows-on használva a windows-ban egy virtuális hálózati adaptert realizál és a PC hálózati forgalma ezen keresztül mehet a gépbe ki és be.
Más szóval ez olyan PC-hez való hálózati "kártya" amit USB-n keresztül csatlakoztathatsz a PC-be.
Ezt PLC-vel (és semmilyen más eszközzel) nem tudod használni, hiába van az eszközön USB, mivel a hálózati forgalom megvalósítását javarészt szoftver végzi, ami csak PC-n fut.Ezeket bedugni se nagyon tudnád az USB-s PC adapterbe, mert azon B-s USB aljzat van, ezeken meg A-s USB dugó. Persze átalakítóval bedughatnád, de attól nem fog működni.
Ráadásul a PC adapter megtáplálni sem fogja az eszközt 5V-al (a PC USB-jén van 5V tápfesz, ezek az eszközök arról üzemelnek).USB WiFi adapter, 150Mbps, antennával (Link)
Ez meg ugyanaz mint a fentiek, csak nem réz, hanem vezeték nélküli adapter. Tehát olyan WiFi LAN "kártya" PC-hez, amit USB-be kell csatlakoztatni.
Ez pedig:
USB - USB Over RJ-45 (UTP) 45m. extender (3. Link)
szintén nem jó, mert ez csak annyit tesz, hogy meghosszabbítja az USB portot UTP kábel segítségével max. 45 méteresre. Szerintem ennek semmi köze az ethernethez és vagy a TCP/IP-hez, ezt csak elszeparált UTP kábelen tudod vezetni (nem kötheted routerre switch-re PC-re stb). Egyszerűen csak annyi előnye van, hogy könnyen beszerezhető, olcsó UTP kábelt használhatsz az USB megtoldásához.S7 PLC MPI-t egy PC-hez etherneten csak megfelelő gateway segítségével tudsz csatlakoztatni.
Ilyeneket gyártanak többen. Pl. Helmholz akiknek van magyar képviseletük (AD-DA kft) és még sokan mások. Ezek között a találatok között nézz szét.Megoldás lehet még egy RS232 PC adapter, amit RS232-Ethernet átalakítóra kötsz (de ezt már említettem)
Sajnos ez lassú eléggé, de a HMI minden bizonnyal elég lenne. -
-
-
Szirty
őstag
Hello coco2!
Nagyon függ a dolog a gép jellegétől és hogy mit csinál.
Van egy elméleti határ, amit a gép karbantartás igénye korlátoz (kopó elemek cseréje, hűtő, kenő folyadék csere, karbantartás, átvizsgálás stb.)
Ezt a határt technológiai körülmények is korlátozzák (pl. átállás másik termékre)
Korlátozzák továbbá a működés során fellépő működést akadályozó tényezők. Áramszünet, alapanyag hiány, meghibásodás, a soros berendezéseknél a megelőző vagy követő gépsor leállása, felakadás, torlódás, stb.Csináltam egy ábrát, ami valós. működő termelő gép üzem és állás idejét, kihasználtságát mutatja időben. Azt nem árulom el hogy pontosan milyen gép és mit csinál, de hátha így is reprezentatív lesz:
1. Két párhuzamos egyforma gépsor üzemideje az időben ábrázolva.
2. Prés gép (lágy anyaggal dolgozik) üzemideje
3. Az iménti présgép 24 órás produktuma órás bontásban. (az 1-2 órás szünet a műszakok közötti pihenő) de sokat ment a gép 3 műszakban is, amikor ilyen üzemszünet nincs)
4. Az 1-es grafikonhoz tartozó gépsor időbeni kihasználtságát mutató táblázat. Az egyes sorok az egységnyi mennyiségű termék feldolgozásához tartoznak, a feldolgozás kezdetét és az ahhoz szükséges időt is jelezve. Az utolsó oszlopban látható, hogy a feldolgozás ideje alatt milyen volt az üzemelés és állás egymáshoz viszonyított aránya.De van olyan berendezés is (Pl. kemence) amelyik 5 éve megy csaknem megállás nélkül. Csak áramszünet és gázhiány alkalmával áll meg néhányszor. A hibák kijavítása és karbantartás menet közben történik.
-
Szirty
őstag
válasz
sörösló
#3285
üzenetére
Szia sörösló!
"Nem egyszerű az élet, de a robbanásveszély miatt nem lehet "tegyük fel" tényezőkkel operálni! Vagy fehér, vagy fekete. Nincs olyan hogy ha napkeltekor megszólal a feketerigó akkor megnézzük tüsszent e a kutya és ha igen akkor minden OK."
Elnézést, kicsit el fogok térni a témától.
Erről az jut eszembe, hogy az ilyesmi nem ritka. Az igény oldalon gyakran alakul ki olyan konkrét megoldás, hogy a problémát se tudom elképzelni, amire az a megoldás.
Tehát nem csak a problémát vázolják, amit meg kell oldani, hanem magát a megoldás lépéseit is. Az utóbbival akkor szokott probléma lenni, amikor a "konstruktőr" nincs teljesen tisztában a megoldás eszközéül szolgáló berendezés működésének olyan részleteivel, amelyek ismerete elengedhetetlen a korrekt megoldáshoz.
Más szóval feltételezésekbe bocsátkozik, vagy hogy nevén nevezzük a dolgot: Blöfföl, mert fingja nincs hozzá.
Az meg nem mindig jön ki jól, amikor a kovácsnak magyarázzák hogy kell lovat patkolni.Itt nem azokról az esetekről beszélek, amikor komoly veszély van (robbanás, sérülés veszélye stb) hanem arról, amikor ilyen közvetlen veszély nincs, de a hibás megoldás azért jár negatív következményekkel. Pl. azt mondják, hogy tegyünk oda egy nyomógombot és majd a kezelő megnyomja amikor ez vagy az a helyzet kialakul.
Az ellenvéleményem az a kérdés szokott lenni, hogy mi legyen ha nem nyomja meg a gombot? Erre a válasz hogy "miért ne nyomná meg?" -
Szirty
őstag
válasz
DP_Joci
#3281
üzenetére
Szevasz!
Ez valóban kérdés. Nyilván van egy olyan hőmérséklet különbség, amire szükség lesz, hogy a kívánt érték tartható legyen.
Először szerintem közelítsd meg úgy, hogy a kazán beállított (elérendő) hőmérsékletébe nem avatkozol bele.
Legfeljebb ha a tartály hőmérséklete magasabbra vagy közel azonosra van állítva akkor lassan vagy sose éri el a beállított értéket teljesen. Nem tudom ez mekkora problémát okoz. -
Szirty
őstag
válasz
DP_Joci
#3278
üzenetére
Helló DP_Joc!
Szóval az zavart meg (csak rosszul idéztem), hogy a kazánban a hőmérsékletet szabályzó tartja, aztán meg azt kérdezed, hogy a kazán hőfokát is szabályozni kéne?
Nyilván ha kazán hőmérséklete szabályozott, akkor az nem fog túlfűteni (hibamentes állapotot feltételezve),
Mi a kérdés? :-)
-
Szirty
őstag
válasz
DP_Joci
#3276
üzenetére
Helló DP_Joci!
Nekem még nem teljesen világos mi melyik és mivel van fűtve:
"Van egy, nevezzük kazánnak, amit fűtőszállal fűtűnk"
"Esetleg a kazán hőfokát is szabályozni kéne"
Ha a "kazánt" szabályzóval ellátott fűtőszállal fűtjük és ennek hőjével fűtünk egy másik tartályt, amelyikbe bejutó hőt egy keverőszeleppel lehet állítani, akkor nem lesz semmi gond, a "kazánnal" fűtött tartályban is mérni kell és a keverőszelepet a annak megfelelően állítani tehát oda is kell egy egyszerű szabályzó.
"Tapasztalat híján azon gondolkodom, hogy a kazánban nem lehet-e hő megfutás"
Mivel a fűtőszálat hőmérsékletre kapcsolod, nem fog afölé melegedni.
-
Szirty
őstag
válasz
byte-by
#3274
üzenetére
Helló byte-by!
Esetleg javaslom ezeket:
WinCC Flexible - PC runtime
WinCC Flexible Runtime használata PC-n -
Szirty
őstag
válasz
byte-by
#3272
üzenetére
Helló byte-by!
Igen, ez a lényeg.
A HMI-nek használt PC-re telepíted a WinCC Flexible RT-t. Az ES-t nem is kell arra felrakni.
(Az ES a "szerkesztő", az RT a futtató, ami a kész projectet működteti).Az RT-s gépre egy másik gépen ES-el készített projectet akár hálózaton az RT futása közben is rátöltheted (pl. ha módosítasz valamit).
Akkor LCD- rakhatsz amekkorát akarsz (akár kivetítőt is) de az RT által kezelt képernyő felbontás korlátozott.
Ez főleg csak akkor probléma ha full screen módban akarod az RT-t használni. -
Szirty
őstag
válasz
byte-by
#3270
üzenetére
Helló byte-by!
A módszer ugyanaz. Vagy egy hálózatba hozod a PLC-ket (lehet MPI, ethernet vagy profibusz is) vagy több független hálóba, vagy egyenként rákötöd mindet egy PC-re (ez utóbbit csak végső esetben).
A PC-n pedig futtatsz valamilyen HMI vagy SCADA szoftvert. A CX supervisor is az. Ennek Siemens "megfelelője" a ProTool (régi már) WinCC (ez a SCADA) vagy WinCC Flexible.
De használhatod valamilyen más gyártó scada/HMI szoftverét is, a lényeg hogy egyrészt ismerje az összes felfűzni kívánt PLC típust és a kommunikációs módot is amivel összekötöd a PC-vel.
Óriási HMI panel (Pl. Panel PC) nagyon drága, olyat csak akkor javasolt használni, ha a megjelenítés körülményei indokolják (pl. nagyon ipari környezetbe kerül, szekrény ajtóba, vezérlő pultba stb. és fontos hogy a kijelző és maga a gép egy egység legyen.
De használhatsz ipari PC-t is, sokan gyártanak olyat, vagy irodai környezetben közönséges PC-t.Lényeges, hogy hány PLC-t akarsz vele összehozni, mert pl. a WinCC Flexible csak 8 PLC kapcsolatot tud egyszerre kezelni.
-
Szirty
őstag
Helló Onishi!
Bármilyen 24V DC (szűrt) tápegységgel táplálható, amelyik terhelhetősége elég nagy neki.
"Mire való pontosan a SIMATIC NET modul?"
Pontosan melyik? Nagyon sokféle van!
Ebben a doksiban biztos hogy megtalálod :-)"3. Csak spéci programozó kábellel lehet felprogramozni, vagy esetleg sima RS-232, vagy USB kábellel is lehet? Miben más egy programozó kábel?"
Ha a CPU-n van ethernet (azaz PN-es) akkor ethernet kábellel is programozhatod.
Ha nincs, akkor szükség van egy MPI/DP interface-re (CP) amiből rengeteg féle van.
Van olyan ami USB-s, van amelyik ethrenetes, van amelyik RS232 soros portos, stb. Az utóbbi a legolcsóbb, de a legrosszabb választás is egyben.Miért akarsz S7-300-at venni? Mihez kell?
-
Szirty
őstag
válasz
DP_Joci
#3259
üzenetére
Helló DP_Joci!
'Van egy préselési folyamat, ahol a nyomóerőről van egy analóg érték"
Ilyet csináltam már párszor S7-300-ra. Izgalmas :-)
Mennyi ideig tart a folyamat, ami alatt rögzíteni kell? Nem lehet túl gyors, mert az A/D és a PLC sem rakéta.
Ha 1-2 másodpercnél hosszabb a rögzítési idő, akkor szerintem nem lesz gond.Egy DB-be kell a PLC-vel elrakosgatni a mintákat, amit a HMI-n egy buffered trenddel meg lehet szépen jeleníteni.
A comfort panelek nyomtatási képességéről nincsen információm, de ha képes nyomtatni, akkor valószínűleg printscreen (hardcopy) formájában tudsz vele grafikont nyomtatni.
-
Szirty
őstag
válasz
DP_Joci
#3257
üzenetére
Helló DP_Joci!
Szerintem nem kell ide HW-es PWM kimenet. Egy normál kimenet is megfelelő lesz.
1200-as PID-del még nem játszottam, de szerintem cyclic interrupt OB-ba kell rakni. Ide a 100ms hívási gyakoriság bőven megfelelő lesz szerintem.
A PID PWM kimenetének ciklus ideje szerintem 1-2 másodperc lesz a megfelelő. Max kitöltés 100% is lehet,a minimális bekapcsolási idő meg legyen nagyobb mint az 50Hz periódus ideje (20ms). -
-
Szirty
őstag
válasz
DP_Joci
#3246
üzenetére
Üdv DP_Joci!
"Szóval a berendezésből egy vákuumszivattyú szívja a gázokat. A vákuumszivattyú -1barra(abszolút 0) törekszik, de ehhez a nyomáshoz kell „hozzáadni” nitrogénnel kb.200mbart (jelenlegi infóm szerint)."
Azzal nem kell foglalkozni, hogy ha a kamrában nem keletkeznek gázok (bármilyen okból) vagy nagyon kevés keletkezik, akkor ez a rendszer pocsékolni fogja a nitrogént?
-
Szirty
őstag
válasz
Dezsi82
#3244
üzenetére
Helló Dezsi82!
Amit írtam azt a fórumon, mail-ben, skype-on kérdezőkre értettem, nem a munkát megrendelőre.
Az előbbiek írásban jönnek, az utóbbiak meg személyesen, szóban (a végső egyeztetés legalább).Az ok is megvan amiért így viselkedek: A fórumozók (természetesen tisztelet a kivételnek) szeretnek semmit adni és mindent akarni. Ezt főleg az információra értem. Nem azt mondom van az az eset, amikor tényleg lehet tudni mit akar, még ha nem is írja le, de nagyon sokszor lehet bemenni az erdőbe egy feltételezés alapján és sokat fölöslegesen dolgozni a válaszon. Én azt gondolom, hogy a kérdező is küzdjön csak meg legalább egy kicsit a válaszért.
A hagyományos nyomásszabályzó egyébként azért jutott eszembe, mert ahol egy műszaki megoldásra szabad kezet kapnak, ott Ockham nem mindig borotválkozik :-)
Ilyenkor hajlamosak vagyunk egy frappánsan összetett, szakmai kihívást jelentő megoldással előállni és elvetni a sokkal megfelelőbb egyszerű standard megoldásokat.
Azt persze (épp a kevés infó miatt) nem tudhatom, hogy tényleg megfelelne-e oda amire gondoltam, de ha több megoldás is megfelel, akkor mindig válasszuk az egyszerűbbet. Hosszú távon ez megtérül. -
Szirty
őstag
válasz
Dezsi82
#3242
üzenetére
Helló Dezsi82!
Ha kell állítani... Nem tudjuk. Nem esett szó arról, hogy állítgatni kell, és amíg ezt nem írja én nem is feltételezem. Az esetek többségében célszerűbb a kérdésre és nem a kérdés mögött feltételezett kérdésre válaszolni. Legalábbis én így gondolom (sokan nem, főleg a kérdezők, de én igen. Ez van). Aki rossz kérdést tesz fel, az kapjon rossz választ. :-)
Az ilyen messzire vezethet, mert mi van HA nem tetszik neki a kék szín, az meg pont kék? Stb, stb, stb...Ha kell állítani, akkor odamegy és állítja. Ha nagyon gyakran és automatikusan vagy távolról kell állítani az más kérdés, de eddig ilyen igény nem került szóba.
-
Szirty
őstag
válasz
Dezsi82
#3221
üzenetére
Hali!
Még annyi jutott eszembe a dologgal kapcsolatban, hogy ez idő átállítgatás olykor egy csomó problémát okoz. Emiatt nem ritkán érzem úgy, hogy sokkal több problémát okoz, mint amennyit megold....
Pl. ha van időhöz (időponthoz) kötött funkció és az időállítással átlépi vagy éppenséggel visszalép az időpont elé. Vagy amikor pontos 24 órás mérést vagy regisztrálást kell megvalósítani.
Vagy S7-300/400-nál ha Time of Day interruptotot használunk és az annak beállított időpontot lépi át az átállás keletkezik egy time error, amiről ha nem gondoskodunk, jön a CPU stop stb, stb, stb :-) -
Szirty
őstag
válasz
Dezsi82
#3215
üzenetére
Helló Dezsi82!
"Omronnál nincs PWM funkcióblokk, egyszerűen csak a megfelelő CIO címre kell a szükséges értékeket beírni, és a megfelelő biteket beállítani
Ilyen funkcióblokkot nem fogsz tudni leprogramozni, mert a PWM kimenet olyan gyors kell legyen, amit a felhasználói program ciklusidejének ingadozása és mértéke nem teszi ezt lehetővé."A dologgal kapcsolatban annak teljessége érdekében meg kell jegyeznem, hogy:
Vannak szoftveres és hardveres PWM generátorok. Mindegyiknek megvan a maga előnye és felhasználási helye.Igen valóban van PULSEGEN funkcióblokk, S7-nél, ami szoftveres PWM generátor. Ez természetesen lassú, nagy időállandójú PWM előállítására használható, ami bőségesem meg szokott felellni PID controllerek teljesítmény szabályzó kimenetéhez.
Egy fűtésre használt gáz égőt amúgy sem lehetne másodpercenként több százszor ki/be kapcsolni, oda perces sebességű PWM kell. De egy PLC kimenet által vezérel SSR-es fűtés kapcsolgatására is meg szokott felelni az 1-2 másodperces ciklus idő, amihez megfelel a szoftveres (és lassú) PWM.
A felhasználói program ciklusidejének ingadozásának "pontatlanító" hatását ennél azzal küszöbölik ki, hogy timer interrupt OB-ból futtatják, ami pontos.A másik, hogy S7-nél is van hardveres PWM lehetőség. Persze CPU függő. Nem mindegyiken van.
Ahogy szerintem omronnál meg van szoftveres PWM lehetőség és akkor körbe is értünk.
-
Szirty
őstag
Helló oli83!
Igen március utolsó vasárnapján, illetve október utolsó vasárnapján kell átállni.
"Még sosem néztem, a PLC órája tényleg módosítja magát, illetve automatikusan pl. visszább áll 1 órával?"
Szóval. S7 300/400 amennyire tudom nem áll át magától időszámítások között.
Lehet azonban az időt NTP szerverrel szinkronizálni (már amennyiben a CPU profinetes):
Ezzel, ha az NTP szerver is úgy akarja követi az átállást.
Egyéb esetben programmal kell gondoskodni az átállásról.
A részletekért a Step7 által is feltelepített doksit ajánlanám: STEP 7 - Programming with STEP 7
Továbbá az SFC100 rendszerhívás tanulmányozását, ami ezzel foglalkozik (Setting the Time-of-Day and the TOD Status with SFC 100 "SET_CLKS")"Mi történik akkor, amikor 3 óráról visszaállunk 2 órára? Honnan tudja a PLC, hogy 2:59 perc után nem kell újra még egyszer vissza állnia?"
A dolog mechanizmusa rendszerint az, hogy nem a rendszer órát állítjuk át amikor elérjük az átállás időpontját, hanem azt az időd használjuk, ami rendszer órából kivon hozzáad és ezt a hozzáadott értéket módosítjuk, amikor a (nem változtatott) rendszer idő szerint arra szükség van. Így soha nem fogja a kelleténél többször átállítani az órát, mivel így azt soha nem is állítja át
Az S7-1200 már magától is megcsinálja ha kell:
-
Szirty
őstag
Helló tibi-d!
Valószínű, hogy nem megfelelő valamilyen beállítás.
Azonban mivel a beállításokról semmilyen információt nem közöltél, nem lehet megmondani melyikkel van a baj.
Szerintem nem raktad bele az I/O-kat a process image-be.
Vagy nem a megfelelő címen próbálod elérni modulon lévő I/O-kat. -
Szirty
őstag
Hi m_zoli!
"mennyi Repeater-t lehet, elhelyezni a busz-on? ( Profibus-os leírások, 3 db-ot javasolnak.)"
A repeaterek számát azok késleltetése korlátozza, aminek a megengedett mértéke meg sebesség függő.
Alacsonyabb sebességen nagyobb késleltetés is megengedhető. 1.5 Mbps-en szerintem a 4 még belefér.Egy szegmens elvisel 32 eszközt. Tehát ha más nem indokolja (a kábel hossza, topológia, stb) akkor repeater nélkül ennyit elbír.
Természetesen a repeateren keresztüli leágaztatás nem minősül T elágazásnak az említett szempontból.
Sajnos azonban a repeaterek aktív eszközök lévén a tápfeszültség igényükkel (és ebből következően tápfesz hiány esetén) okozhatnak olyan problémát amik nélkülük nem lennének -
Szirty
őstag
válasz
Krisz0627
#3203
üzenetére
Helló Krisz0627!
Küldd el a projectet. Privát üzenetben küldtem elérhetőséget.
Egyébként a leggyanúsabb nekem abból a pár soros kódrészletből amit itt írtál az a
O #iHygrostat
sor.Nagyon lényeges, hogy mi van előtte!
Ha a timer indításának egyetlen feltétele a #iHygrostat akkor O helyett A kéne és tennék elé egy CLR-t (amíg nem tudom mi van előtte). Máskülönben amikor ideér a végrehajtás, a #iHygrostat hiába FALSE állapotú, ha az RLO a korábbi sorok miatt TRUE, akkor az OR kapcsolat miatt a timer aktív lesz (bakpcsol a kimenete). -
Szirty
őstag
válasz
Krisz0627
#3201
üzenetére
Hali Krisz0627!
"Van egy SF timer ami elindul akkor is ha feltétel nincs meg."
Az a kérdés, hogy miért?
Az attól függ...- Milyen utasítások vannak a O #iHygrostat (IN tipus) sor előtt?
- Milyen utasítások vannak a = #tUebersaettigung és A #tUebersaettigung sorok között?
- Az SF "zEgsUebersaettVerz" futás szerinti sorrendben megelőzi, vagy követi-e az = #tUebersaettigung"sort?
- Írja-e valami közvetlen címzéssel a blokkon belül az L area-t?
- Van-e valahol indirekt címzés a blokkon belül, ha igen akkor hol és hogyan néz ki?
- A blokk hívása, amiben a kiemelt részlet van, milyen feltételek szerint fut le?Ez az öt sor nem elég infó a kérdés megválaszolásához!
-
Szirty
őstag
válasz
Krisz0627
#3198
üzenetére
Helló Krisz0627!
"ProTool/Lite-hoz kellene frissítés hogy tudjam egy OP27-es kijelzőt programozni.A Siemens oldalán én nem találtam."
A Lite attól Lite, hogy korlátozottak a funkciói. Nem néztem utána, de gondolom a Lite nem ismeri az OP27-et.
Ha így van, akkor nem fogsz találni hozzá olyan hivatalos ingyenes kiegészítést amitől tudni fogja, hiszen akkor ki venne drága ProTool PRO-t, ha a fél áron is megszerezhető Lite + egy ingyenes upgrade is tudja ugyanazt? -
Szirty
őstag
Helló m_zoli!
"A kérdés kell-e?, ill. javasolt alkalmazni RS 485-Repeater-t?"
Ha elegendő az 500 kbps busz sebesség, akkor a szegmens hossza 400m lehet.
Ha kell az 1.5 Mbps, akkor kell egy repeater a busz olyan pontjára, hogy egyik szegmens se legyen hosszabb 200m-nél.(A fenti T elágazás nélküli buszra vonatkozik! A T elágazás drasztikusan rontja a megengedhető távolságot)
-
Szirty
őstag
válasz
AVarice
#3186
üzenetére
Helló AVarice!
"Olvasgattam korábbi hozzászólásokban az RS232-USB átalakítós megoldásokkal. Túl sok biztató dolgot nem olvastam, ha lehet szeretném megúszni olcsóbban a dolgot."
Szerintem sajnos ránézésre, előre nem lehet megmondani egy USB-RS232 átalakítóról, hogy jó lesz-e vagy sem. Ha minden tekintetben megfelel az RS232 ajánlásainak, akkor szinte biztos hogy jó lesz de sajnos ezt előre részletes doksi vagy az adott típussal való tapasztalat hiányában nem lehet megmondani.
A jó minőségű drágább, a bóvli meg vagy olcsó vagy drága.Van kolléga aki szerint semmi értelme drágát venni, a DTR/DSR RTS/CTS jelekre nincs szükség, a galvanikus leválasztás pedig fölösleges. Ez nem minden esetben van így, a részleteket olvashattad.
Én annyit tudok mondani a saját tapasztalatomból, hogy a 2500Ft-os Aten UC232A a hulladék kategória. A bent a cégnél használt további három, (de meg nem mondom pontosan milyen, mert ráírva sincs semmi) gyakorlatilag teljesen használhatatlan (csak omronokkal megy, de pl. már az üzemanyag kutat sem lehet vele kiolvasni).
Én óvatosságra intelek, de tégy belátásod szerint.
-
Szirty
őstag
válasz
AVarice
#3184
üzenetére
Hali AVarice!
Miért nem találtál semmit? Google jó brát...
Nem meglepő módon Schneider Electric oldalain van róla doksi.
A web oldal megoldásai miatt közvetlen linket nem tudok adni a doksikra, de a fenti oldalon kattints a jobb oldali "Dokumentumok" linkre.A bekötéseket a Twido programmable controllers Hardware Reference Guide
doksiban találod.Bár hmm... kissé szerintem el van baxva:
Mindenesetre a tápfesz bekötése szerintem ennek ellenére is egyértelmű. 24V DC kell neki.
A ki és bemenetek bekötése pedig ez:
-
Szirty
őstag
válasz
isvarga
#3170
üzenetére
Helló István!
Úgy tűnik megint olyasmiről vitáztunk, amiben egy kicsit egyetértünk, egy kicsit meg nem.
De most már ezt a vitát ebben az irányban nincs értelme folytatni, mert egyre több személyes minősítő jelző kezd előkerülni. A veszekedés meg nem ide való dolog.
Bennem nincs ellenérzés a személyeddel kapcsolatban, ahogy nem is volt.De annyit megígérhetek, hogy a jövőben sem fogok szó nélkül elmenni olyan állítások mellett amik szerintem nem teljesen vagy egyáltalán nem igazak (pl.: hogy a galvanikus leválasztás teljesen fölösleges).
Én tárgyilagos próbálok maradni, ahogy eddig is tettem, ha nem kapod fel a vizet, a társalgás megmaradhat szigorúan szakmai keretek között.Addig is amíg újra össze nem akadunk, jó munkát... aztán ha majd megtörténik, akkor utána is! :-)
-
Szirty
őstag
válasz
murena2
#3174
üzenetére
Helló murena2!
használd pl. a TIM_S5TI (FC40) S5TI_TIM (FC33) IEC funkciókat.
Ezek S5T időtípust konvertálnak át Time formátumba és vissza.
A Time olyan DINT típusú adat, ami az időt ezred másodpercben tartalmazza.
Ezzel már számolhatsz ha átpakolod MOVE-val DINT típusba meg vissza TIME-ba...Esetleg írhatsz timert ami perc alapú.
Bár azt értem ugyan hogy perc alapú időt kell megadni, de azt nem írtad, hogy csak egész perc lehet, vagy töredék perc is (pl. 6.78 perc). -
Szirty
őstag
válasz
isvarga
#3170
üzenetére
Helló István!
"Szerintem neked lehetnek szövegértési problémáid ,mert szerinted azt állítottam : "Nem ismerted el, hogy bizony a soros portnak +/-12V-os jelekkel kellene dolgoznia, de az USB porton csak +5V van.""
Dehogy! Azt én állítottam!
Én csupán azt írtam, hogy a fentit nem ismerted el. És ez így is van. Ennyit a szövegértésről?"Az viszont biztos ,hogy még soha az életben nem csináltál soros port illesztést."
Látom a másodi kfázisba ért ez a "vita". Most már nem hangzanak el érvek, személyeskedünk...
A feltételezésed téves. Csináltam soros port illesztést!"A felhasználó tábor az egészhez képest nagyon kicsi.(a helyettesítő eszközöket pedig nem ár alapján csoportosítják ,hanem mire használható , milyen felületen kapcsolódik stb)"
Ez így van. Ezért is csoportosítom őket használhatóság szerint. És mint azt már írtam, a használhatatlan csoportba tartozó változatok jellemzően bírnak gyakorlatilag egytől-egyig azzal a szembeötlő tulajdonsággal, hogy olcsóak.
Nem?"Különbség : Az olcsók 10éve készültek , a drágábbak 1-2 éve"
Dehogy készültek 10 éve! Ezt meg honnan a fenéből veszed? Láttál egy olyat, amelyik 10 éves és drága volt?
"Ha használnak egyéb pint is mint például a kézfogásos adatcserét az csak a pc "bénasága" miatt van.(de van neki szoftveres megfelelője is)"
Alapvető tévedés!. Vannak eszközök használja a CTS/RTS DTR/DSR jeleket is.
Persze itt is lehet barmolni, át lehet kötni a CTS-t az RTS-be. ugyanazon az eszközön és akkor a saját jelét veszi. A legtöbbször ez működik, de nem mindig."A macsót ellenállhatatlanságáról ,fölényes stílusáról és kevés műszaki ismeretéről lehet megismerni."
Ekkor rendben van. Én sem teljesen értettem hogyan kapcsolódik ez az USB átalakítás témájához, de nem akartam szavak definícióján megakadni.
"Dc-dc konverter nem lehet benne mert nem bírják a szaggatott üzemmódot."
Ejh! Ezt komolyan gondolod? Ne süllyedjünk már ilyen szintre!
"Tehát általában szint illesztő van benne , de a 6Ft-os tranzisztorok is megteszik (persze bruttó az ár). E-néhány apróság képes akár 3,3V-ból is +-12v-ot csinálni."
:>>
Akkor viszont az lehet a baj, hogy ezeket nem teszik bele az átalakítókba (talán ugyanabból az okból: olcsóbb legyen)"Nyilván azzal sem vagy tisztába ,hogy az usb portot 100mA lehet szabadon használni. 100-500 között jelezni kell a host-nak extra igényünket.(ezt magának az eszköznek kell elvégezni)"
Jujj már ember!
Akkor a logikád szerint oda több mint 100mA kellene, de handshaking jelek meg tolnak több mint 100mA-t? Nem hiszem!:->
Amúgy sem működne az USB-s vízforraló meg kenyérpirító 100mA-el 5V-on Na jó, igaz oda kell 4 db 8 portos USB kártya ""Talán az optocsatolós jeltovábbítás fizikai megvalósítása is drágábbá teheti az eszközt nem gondolod?""
Nincs rá szükség és semmitől nem védi meg az eszközt. (ez minden kapcsolatnál így van ,először csatlakozunk és csak utána kapcsoljuk be a készüléket , én sem szoktam így csinálni)"
Nos kedves István itt fejeztem be ezt a témát!
Ekkora tévedést már nem tudok jókedvűen tolerálni! -
Szirty
őstag
válasz
isvarga
#3166
üzenetére
Helló István!
"-Az hogy ugyanazt (valljuk be) az ipari hulladékot mennyiért adják csak attól függ kinek a kedvére akarnak tenni."
Értem én hogy miről beszélsz, de azt hogy az ami drága ugyanazt tartalmazza mint ami olcsó, de a macsók azt veszik mindenre ráhúzni alapvető ostobaság.
Mint írtam ami minőségi, kidolgozott, több anyagot és munkát fektettek bele az szükségszerűen drágább lesz annál, mint amit összebarmolnak és összelapátolnak "parasztnak tanyára jó lesz az" címszóval.
Ugyanakkor a szart is lehet drágán adni, ez nem vitás.
A mai világban ami egymás sárba taposásáról és az átb@szásáról szól ez sajnos benne van.Másrészt pedig mindent annyiért adnak amennyiért megveszik és nem annyiért amennyi az értéke.
"-Miért építsenek ki olyan pin-eket amit már (kb 98-óta) egyik fejlesztő platform sem támogat?(ettől még ki lehet építve ,nem kerül semmibe ,én sosem használtam őket)"
Már miért ne támogatná a "PIN-eket" a "fejlesztői platform"? Az lehet hogy a közvetlen környezeteben ez a kijelentés helytálló, de az egész univerzumra kivetítve nekem kétségeim támadnak a helyességét illetően.
De ha már itt tartunk minek egyáltalán soros port, hiszen kilencvenhatban a soros Genius egerek kihaltak, hát ne tegyünk RS232-t a számítógépekbe, mert minek az oda? A kutya nem használja azokat.
Aztán nézd csak meg hány ipari eszköz, frekvenciaváltó, hajtásvezérlő, szervó, PLC rendelkezik RS232-vel! Ó nem, NEM 1986-os évjáratúak, hanem új fejlesztésűek! A gépemben fizikailag egy soros port van. Amellett több mint tíz virtuális COM adapter. Kezdve a Bluetooth COM-tól át a GSM modemen, az S7-LAN adapteren keresztül a MODBUS interfészen át, a az analizátor műszer programja által realizált COM port-ig.
Miért van ennyi? Talán mert semmi szükség nincsen már rájuk igaz?Visszatérve a fizikai soros port kialakítására:
Nyilván elkerülte a figyelmed (vagy nem kívántad kiemelni mert nem támasztja alá amit írsz) hogy vannak olyan megoldások amikor pl. a "teljesen fölösleges" handshaking pinek adják az eszköz tápfeszültségét, mivel az RS232 csatlakozón nincs kivezetve tápfesz.
Nem ismerted el, hogy bizony a soros portnak +/-12V-os jelekkel kellene dolgoznia, de az USB porton csak +5V van. Az olcsó szarokban ebből barmolnak közel sem szabványos jelet. A normális USB-RS232 átalakítóban meg DC/DC konverter van. Nem lehet azért (is) drágább és nem csak mert macsó?Nem reagáltál arra sem, hogy a normális ilyen átalakító izolált, az USB és az RS232 között semmilyen galvanikus kapcsolat nincsen (szintén kifejtettem ennek előnyét egy példával).
Talán az optocsatolós jeltovábbítás fizikai megvalósítása is drágábbá teheti az eszközt nem gondolod?És igen, én szeretnék egy ilyen macsó USB-RS232 átalakítót magamnak ami az általam leírt jellemzőkkel bír. Hogy ne kelljen szarakodni az üzemben a gép mellett állva azzal hogy az istennek sem akar kommunikálni vagy épp a laptopot vágja tönkre a földpotenciál különbsége.
Ha neked megfelel az olcsóbb, szerényebb képességű, hát használd egészséggel, áldásom rá. De tényleg.
De azt állítani hogy minden normálisan elkészített eszköz is ugyanaz a szar, az nettó ostobaság. -
Szirty
őstag
válasz
miclucky
#3159
üzenetére
Helló miclucky!
Szerintem lényeges lehet hogy milyen programot és hogyan módosítottál.
Nem ismerem ugyan a vezérlőt, mert mi csak Wago 750 profibuszos interfészt meg hozzá I/O modulokat használunk, vezérlőket nem. De azt gondolom (és remélem is közben) hogy nem egy "rendszertulajdonság" a jelenség amit írtál. -
Szirty
őstag
válasz
isvarga
#3152
üzenetére
Helló István!
Egyébként messze nem csak az árat nézzük, de elég jól szokta jellemezni a minőséget, azt lássuk be.
Ami olcsóbb a "kelleténél" az valószínűleg silány minőségű (vagy lopott).
Sajnos ez nem reverzibilis: ami drága az sokkal kevésbé valószínű hogy jó, mint az hogy az olcsó szar. -
Szirty
őstag
válasz
byte-by
#3153
üzenetére
Helló byte-by!
"a csatlakozáshoz nem feltétlenül értek egyet a gyári cucc használatával.én vettem egy sima 1850 forintos soros-usb átalakítót , és kifogástalanul működik.lehet kifogtam"
Szerintem egyszerűen csak nem futottál még bele olyanba amivel nem megy.
Könnyen lehet, hogy nem az eszközöd szuper, hanem csak nem mozogsz elég széles skálán ahhoz hogy belelépj a gödörbe.
Ez persze egyáltalán nem baj, de ennyiből nem szabad levonni azt a következtetést, hogy minden megy vele.Én egy ATEN UC232A szintén olcsó kategóriás USB-RS232 átalakítót használok olykor ha elkerülhetetlen.
Az összes Omron PLC-vel amivel eddig csak próbáltam, kifogástalanul működött (C120, C200H, CQM1, CP1M, CS1G, C500, C1000H).
Sajnos ez nem az átalakítót dícséri, ugyanis pl. Siemens OP7-el (és egyéb RS232-t igénylő operátor panelekkel) gyakorlatilag teljesen esélytelen. A kapcsolat vagy létre sem jön, vagy (a legalacsonyabb sebességre állítva) 10-ből 9.szer megszakad. :-/
S5 TTTY kábelt ebbe bedugni meg sem érdemes próbálni.Továbbá az ilyen átalakítóval nem használhatók azok a soros eszközök, amik az RS232-es port handshake jeleiből szeretnének tápfeszültséget csiholni maguknak.
Ilyenek pl. a külön tápfeszt. nem igénylő RS232-RS485/RS422 átalakítók.
Sok szervó drive és frekvenciaváltó emiatt nem hajlandó szóba állni a géppel ilyen USB-RS232 átalakítóval.Akinek megfelel használja, de inkább rá kell áldozni egy kicsivel többet és kevesebb meglepetés éri az embert.
-
Szirty
őstag
válasz
isvarga
#3152
üzenetére
Helló István!
Nem értem miért (ismét) ár alapján válogatod szét a termékeket.
A virtuális soros portot mindegyik ugyanúgy hozza létre a 2000Ft-os és a 22222 Ft-os is.Az bizony meglehet, de a kutya nem ott van ám elhantolva, hanem a HW-ben.
A "gyökér", semmire való bóvli 2000Ft-os USB-RS232 átalakítók meglehetősen magasról szarnak arra, hogy az RS232-nek +/- 12V DC jelszinteket kellene teljesíteni, és arra is, hogy az RS232-ben vannak ám az adatvonalakon kívül handshaking jelek is (RTS, CTS, DTR, DSR, RI). Ezeket baxnak benne kiépíteni :-/A normális, korrekt eszközben nincsenek ilyen gondok és még izolált is, ami nem kis előny tekintve hogy sok notebook adapter idétlen, de annál "divatosabb" RFI szűrőjének köszönhetően a notebook GND-jén olykor 60-150V AC is jelen van.
Az RS232 kábel csatlakoztatásakor még szikrázik is (meg persze ráz, ha nem vigyázunk). Ami még annyira nem is baj, de ha sikeröl először az egyik jel PIN-nek érintkeznie a GND előtt, az garantáltan hazavágja a vonal driverét.""Win 7-hez nem készül szoftver"
Mint fejlesztő állíthatom ,hogy minden fut rajta amit szeretnénk"Hát addig örülj, amíg csak olyanokat szeretnél, ami fut rajta! Nagy szerencse az ilyen!
Majd amikor már nem, akkor kereshetsz régi gépeket amiken még használható az XP, vagy szarakodhatsz virtuális géppel. -
Szirty
őstag
válasz
levelko
#3148
üzenetére
Hali!
processinfrmatikról jut eszembe!
Ilyen S7-LAN adaptert viszont senki ne vegyen:
Nem tudom ma hol tartanak a fejlesztésével, de nekünk van 3 db.
A PC-s drivere egy virtuális COM portot realizál Win alatt, Step7-ben pedig PC Adapter serialt erre kell beállítani.
Rendkívül lassan csatlakozik és gyakran megszakad a kapcsolat, amit igen nehéz és hosszan tartó dolog helyreállítani. Nem ritkán ki kell menni a géphez, lecsavarozni majd visszacsavarozni (lefagy és csak így lehet újraindítani).Ez egy gyors beavatkozást igénylő hibakereséses esetnél nem kicsit bosszantó.
-
Szirty
őstag
Üdv András!
"De nagyon sok laptopon már nincs. A PCMCIA-s vagy express card-os bővítő jó e ilyenre vagy elmegy a port belső cimzése és nehezebben (vagy egyáltalán nem) fog kommunikálni."
Mármint mi nincs, RS232 port?
Hát az lesz az egyik gond, amin úgy lehet segíteni,hogy vagy eleve USB-s programozó kábelt szerzel be.
Siemens S7-300/400, S7-200-hoz pl.: 6ES7 972-0CB20-0XA0 USB PC adaptert:
Omronhoz meg szerzel egy USB-RS232 átalakítót. Nem tudok ilyet jó szívvel ajánlani (omronéknak is van, az azt mondják atombiztos) mert a 1000-3000Ft-os kategóriában 99%-uk használhatatlan hulladék :-/
PCMCIA sem járható szerintem, mert ma már EXPRESS card slot van mindenben, vagy az se.
A másik gondod az lehet (ha új laptopra pályázol) hogy ezeken Win7, Win8 megy legtöbbre nem tudsz XP-t rakni, és előfordulhat lesz olyan programra szükséged ami csak XP-n megy. Akkor majd lehet virtuális géppel szarakodni.., -
Szirty
őstag
válasz
murena2
#3134
üzenetére
Helló murena2!
Először is ki kell választanod a PPO (Parameter Process data Object) típust, amit a HW configban kell beállítani.
Hogy melyiket válaszd az attól függ mit szeretnél csinálni.
A PPO két részből áll, PCD (Process data) és PCV (Parameter Characteristic Value).
A különböző PPO típusok előregyártott választékok, amikben egyik vagy mindkettő benne van.
PCV-re csak akkor van szükséged, ha a PLC-ből úgy akarsz tetszőleges frekvenciaváltó paraméterhez hozzáférni (íri vagy olvasni azt), hogy a PLC programból mondod meg melyik paraméterrel akarsz foglalkozni. Ennek módja elég bonyolult. Ha csak annyit szeretnél amennyit leírtál, akkor a PCV-re nem lesz szükséged, olyan PPO típust kell tehát válastanod, amelyikben nem szerepel a PCV.
Ezek a PPO 3, 4, 6, 7, 8.
Ezekben csak PCD van. A PCD további részekből áll: CTW, STV (parancs és állapot szó), MRV, MAC (az előírt sebesség és a visszajövő tébyleges sebesség) valamint további PCD szavak.
Ezek további PPO választékot jelentenek, amik a hozzáférhető PPO szavak számában tér el, de mindegyik tartalmazza a CTW, STV, MAV, és MRV szavakat, ezek a frekvenciaváltó vezérlésében a legfontosabbak, így az összes választható PPO típusban benne van.
Az egyéb PPO típusok, amikben további PPO szavak vannak a frekvenciaváltóban 915 és 916-os paraméterekkel beállított VLT paraméterek férhetők hozzá.
Itt tehát a hozzáférhető paramétereket a frekvenciaváltó határozza meg, a PLC nem tud tetszőleges paramétert írni vagy olvasni ezzel a módszerrel.
Pl. ha a 916.2 ("PCD Read Configuration paramétert (index:2)") a frekiváltóban "Motor Current"-re állítod, akkor a PLC-ből ha kiolvasod a PCD3-as word-öt, megkapod a pillanatnyi motor áramot.Van olyan PPO típus, amiben nincsenek egyéb PPO szavak, vagy az STW, CTW, MAV, MRV. Ez a PPO Type 3.
Ez a legegyszerűbb, ha ezt használod akkor csak a vezérlő és állapot bitekhez férsz hozzá, és a referenciához illetve az aktuális sebességhez,
paraméterek írása-olvasása a PLC programból nem lehetséges.Nem kell feltétlenül funkció blokk hozzá, közvetlenül is kezelheted a frekvenciaváltót.
Egy példa:
Ez hevenyészett példa, ezen túl a busz diagnosztikáról is gondoskodni kell, hogy ne írja olvassa ha a frekiváltó nincs jelen a buszon illetve ne legyen CPU stop ha leszakad, stb...
-
Szirty
őstag
-
Szirty
őstag
válasz
levelko
#3135
üzenetére
Helló levelko!
"Elképzelhető, hogy az A351 cím 51 perc 57 másodpercet mutat hexa-ban?"
Igen. Ahogy byte-by is írta a szám BCD-ben van ábrázolva. Azt pedig hexában látod decimálisan, vagyis helyesen
"A két reláció sorba tételét értem. A >= lenne a 7 óra, a <= pedig a 9 óra. Nyilván 7 és 9 között lenne igaz a sor eredménye. Vagy túl egyszerűen képzelem"
Így vlahogy, igen!
-
Szirty
őstag
válasz
levelko
#3130
üzenetére
Helló levelko!
byte-by megoldásánál, mivel a komparátorokkal egyezőséget vizsgál lehet olyan következmény, hogy ha átállítod az órát (pl. téli-nyári időszámítás, vagy csak siet vagy késik) és az állítás "átlépi" valamelyik összehasonlításban szereplő értéket, akkor egy ki vagy bekapcsolás kimaradhat. Hogy melyik, az attól függ a ki vagy a bekapcsolási időt léptük-e át az óraállítással.
Lehet hogy ez nem jelent problémát az adott felhasználás mellett, ezt neked kell tudni.
Ha problémát jelent, akkor azonosságra hasonlítás helyett inkább >= és <= (nagyobb vagy egyenlő és kisebb vagy egyenlő) relációkat kellene használni és SET/RESET helyett közvetlen bit érték adást, amit a két komparátor sorba kötve kapcsol ki és be.
Új hozzászólás Aktív témák
- Surface 4 - 15" 2496 x 1664 ~2k touch, i7-1185G7, 16GB RAM, SSD, jó akku, számla, 6 hó gar
- Eladó Samsung 860 EVO 2.5 1TB SATA3
- Eladó Samsung SSD 850 EVO SATA III 2.5 inch 500 GB
- E14 Gen7 14" 3K IPS Ultra 7 255H 16GB 512GB NVMe magyar vbill ujjolv IR kam gar
- Eladó HP HyperX Cloud Orbit S gaming headset
- LENOVO TABLET 10 (N4100),10.1",WUXGA, 2-IN-1 TABLET,Ceruza,LTE kártya,8GB DDR4,128GB SSD,WIN11
- Újszerű iPhone 14 Pro 128GB Asztro szürke független, 100% aksi, 1 Év garancia
- -75% Dell XPS 13 (9320) i7-1260P 16GB Ram/1TB SSD FHD+ Gari
- Lenovo ThinkPad T14s Gen 5 Intel Ultra 5 135u,16 gb DDR5 6400,garancia 2028.03.
- Samsung Galaxy S24 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest