- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Krisztianby: Íróasztal STAUNING 80x160 jobb mint gondoltam.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Klaus Duran: Youtube AI szinkron
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: AMD Ryzen 7 7700X vs AMD Ryzen 9 9900X Cinebench R23 & R24 Benchmarkokban mérve
- sziku69: Fűzzük össze a szavakat :)
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
Új hozzászólás Aktív témák
-
KB.Pifu
tag
sziasztok!
Tovább játszok a szimulátorral, jelenleg szeretnék egy folyamatosan növekvő/csökkenő értéket előállítani az idő függvényében. A szimulálás célja, írni egy olyan kódot, amivel a hiszterézissel tudok barátkozni. Mondjuk 120-nál kapcsol be emelkedő érték esetén, de csak 108-nál kapcsol ki a bit mikor csökken az érték.
a tervem az volt, hogy az OB38-al hívom a funkció blokkot és a program minden egyes lefutásánál növelek egy integert ( vagy csökkentek ugye ha elérte a maxot, ez az érték a tervek szerint kb 3000-ig futna, mintha egy analóg jel lenne és ezt osztom, hogy egy adott skálázásba beleférjen ami 0-200)
A gondom, hogy a lefutásonként növelt érték minden alkalommal mikor eléri a 256-t nullázódik. Kipróbáltam, hogy esetleg a kódban van-e a hiba, de az ob35 (amiben CSAK az integert növelem minden alkalommal) is újrakezdi a számlálást ha eléri a 256-t.
valami felett elsiklottam valószínű
Azt olvastam, hogy gondok lehetnek, egy Cyclic_Interrupt blokkal, ha önidejénél nagyobb idejű funkcióblokkot hívunk meg, szerintem ezzel nincs probléma, de meg szeretném nézni, hol látom, hogy egyes blokkoknak mennyi a lefutási ideje?
Köszi előre is
-
byte-by
tag
válasz
Teuton99
#4197
üzenetére
halo !
az FWRIT utasításnak a kontrol szóban meg tudod adni, hogy hova mentsen.
ha a kontrol szó utolsó digitje 1, akkor EM file-ba ment.
létrehoz egy tárterületet és oda ugyanúgy menti az adatokat , mint cf kártya esetén.
persze szimulátorra szükség lesz és pár bitet át kell kapcsolni, de hasonlóképp kiírja az adatokat.a példa egy CS1G ,és amikor átkapcsolsz szimulátorra meg is kérdezi, hogy létrehozza-e az EM tárat.
azt hiszem CJ sorozatnál NEM online módban engedélyezned kell a "memory allocation " menüben.
bár én cj1 sorozattal még nem csináltam.
byte
-
Teuton99
csendes tag
Szia Szirty!
Köszönöm szépen az instrukciókat, sikerült leprogramozni az analóg skálázást
Egy korábbi posztodban (#595) említetted, hogy már foglalkoztál CF kártyára mentéssel. Ebben az esetben szeretnék feltenni egy-két kérdést, hogy megtudjam valósítani a feladatomat.
Tehát a gép méréseket végez és minden mérés végén (egy mérés kb 1 percig tart) ki kell menetem adatokat.
Az adatok a következők:
- A mérés dátuma és időpontja
- integer értékek
- float értékek
- ID (még nem tudjuk, hogy milyen típusú de valószínűleg STRING)
Az elválasztások vesszővel történjenek és a sor végére kerüljön egy enter (carrige return), hogy a következő mérés adatai már új sorba kerüljenek (append).Az Omron doksik bújása közben ráleltem az FWRIT (701) és FREAD (700) utasításokra, tisztában vagyok azzal, hogy hogyan működnek.
Az első kérdésem az lenne, hogy string változót hogyan tudnék menteni? Próbáltam a MOV(021) utasítással, de az nem jó.
A második kérdésem, hogy van-e valamilyen opció, hogy a PC-n tudjam tesztelni a programot a kártya nélkül (gondolok itt olyanra, hogy esetleg virtuális CF káryta pl.)?Előre is köszi.
Üdv
-
Szirty
őstag
válasz
Teuton99
#4195
üzenetére
Üdv Teuton99!
Nem ismerem a modult, de a leírása alapján úgy látom,hogy van neki egy biztonsági tartománya.
4-20mA-es bemenet tehát 4mA áram esetén ugye 0 értéket ad, 20mA setén meg 4000-et (vagy 8000-et attól függően hogy állítottad be).
Ha a bemeneti áram meghaladja a 20mA-t. akkor az érték tovább nő egészen 4200-ig (8400-ig).
Ha a bemeneti áram 4mA alatt van, akkor negatív értéket kapsz. Legkevesebb -200-at (vagy -400-at).
Egy-egy összehasonlítással tehát csak azt kell figyelned, hogy kívül kerül-e a konvertált érték a 0-4000 (vagy 0-8000) tartományon.
Ha a bemenet árama 1.2mA alá esik, akkor pedig megszólal a disconnection detection bit.
-
Teuton99
csendes tag
Sziasztok!
Omron CJ1M CPU-val megvalósítandó programon dolgozom.
Több analóg bemeneti modulom van (2 db nyomástávadó és egy tömegárammérő) ezeket kellene megvizsgálnom, hogy a jel megérkezik-e (nincs-e szakadás) illetve, hogy a megadott tartományon belüli értékek.Az első feltételre már ráakadtam: Disconnection detection flag a becsületes neve és a CIO n+9 -nek a 04-07 bitjeit kell vizsgálgatni, ahol n=2000+(unit number*10). A unit number = 0, vagyis a CIO2009.04, CIO2009.05, CIO2009.06-os biteket kell figyelnem, hogy nincs-e szakadás. Eddig rendben is vagyok.
A problémám a másik feltétellel van. Ezek a nyomástávadók 4-20mA-es jelet adnak és azt kell megvizsgálnom, hogy az általuk adott jel 3,7mA felett illetve 21,4 mA alatt van-e. Itt viszont elvesztem az analóg skálázás rejtelmeiben és nem nagyon jövök rá, hogy mit kellene csinálnom.
Annyit még elárulok, hogy a nyomástávadókat a CPU-hoz tartozó CJ1W-MAD42-es analóg bemeneti és kimeneti kártyán próbáltam konfigurálni, hogy az input lower limit 0 legyen, az input upper limit pedig 1000, illetve a tömegárammérőn 3000.
Van valakinek valami ötlete, hogy mit tegyek?
-
KB.Pifu
tag
Sziasztok!
Nem örülök neki, de kénytelen vagyok füllenteni álláskeresés közben (még csak a kísérőlevélnél tartok) a szervó paraméterezési tudásomról.
Simodrive-l kapcsolatos ötleteket várnék, szívesen letölteném valahonnan a SimoCom-t is tanulmányozáscéljából, de sehol semmi. Pedig nemcsak füllenteni akarok, tényleg utána is nézni, de mire visszacsörögnek addig eltelik két hét szóval van időm.
Az a baj, hogy a program leírása nagyon száraz, nem látom benne , hogy minek tudnék valóban utánajárni.
Elég sokat foglalkoztam a hajtástechnikával, tehát a trapézgörbe, a nyomaték, gyorsulás stb.. és fizikai leírásuk mind megvan, de ez még mindig kevés, ha egy specifikált rendszert akarok megismerni, tehát mondhatjuk hogy az alapok megvannak.
Bármilyen Simodrive-l kapcsolatos ötletet, linket szívesen várok
Köszönettel
Pifu -
Teuton99
csendes tag
Szia!
Most már világos. Azt hittem, hogy a & jel valamiféle címet jelöl, de ezek szerint sokkal egyszerűbb a dolog.
Lenne még egy kérdésem: ha egy VAGY elágazás egyik foka egy szubrutin hívás, amelyben a compIndex nevű változóval dolgozom, a másik foka pedig egy MOV utasítás, ahol a compIndex változó tartalmát átmásolom a compIndexPre változóba, akkor pontosan mi a kiértékelés sorrendje?
Előbb végrehajtódik a szubrutin (ahol a compIndex értéke akár változhat is) és aztán a történik a MOV, vagy ez csak egy biztonsági mentés a szubrutin előtt?
-
KLR
csendes tag
válasz
Teuton99
#4190
üzenetére
Szia!
A PLC Stop-ból Run-ba váltás vagy feszültség bekapcsolásakor, ha már futott a program, aktiválódik a P_First_Cycle rendszerbit egy ciklus erejéig. Az adat amit az első MOV-val irsz, nem más mint nulla (nullázod az eqState regisztert).
Omronnál jelölve van a szám formátuma, & jelzi hogy decimális számról van szó, míg # jelzi hogy HEX formátumban van megadva a szám. Ez azért is fontos, mert sok helyen használ BCD formátumot (időzítők, számlálók, dátum,stb), ami mind HEX-ben van megadva. -
Teuton99
csendes tag
Sziasztok!
A munkahelyen kaptam egy Omron PLC (CJ1M egyébként) kódját. Ez az első találkozásom ezzel a gyártóval így az utasításokat nem nagyon ismerem, habár a CX Programmer Help-je azért sokat segít.
De térjünk a lényegre: a MOV utasítás ugye át teszi a source tartalmát a destination-ben megadott word-be. Namost az a kérdésem, hogy ha a source-ban &0 van, akkor ennek a tartalmát (pontosan mi is az adat) hol tudnám megnézni? Vagyis arra vagyok kíváncsi, hogy a fenti szintaktikával (&0) használt source word-öket hol tudom a programban megtalálni?
Siemensben a Go to location és a Cross reference sokat segített az ilyesmiben, de a CX Programmer nekem ahhoz még túl új terület -
n0rbert0
senior tag
Elnézést a pontatlanságért, igen azt szeretném milyen gyakran.
Most nézem, hogy kapkodásomba flexible-t írtam, de nekem WinCC (7.0, de ez lehet, hogy újabb) kell, mert egy scada rendszer lesz.
Igen azt tudom, hogy csak 8 PLC tud kezelni, valószínűleg képernyőről választható lesz a dolog, hogy épp miről szeretne adatokat az operátor.
Sajnos olyan problémám van, hogy az ügyfél sem tudja, hogy pontosan mit akar.
-
Szirty
őstag
válasz
n0rbert0
#4186
üzenetére
Üdv n0rbert0!
Azt kérdezed milyen gyorsan, de szerintem azt akarod tudni milyen gyakran!
Esetleg a válaszidő érdekel?
Nagyon nem mindegy!Egy adatlekérdezés sebességét (milyen gyorsan) az dönti el milyen a kommunikáció maximális sebessége és a kommunikációs csatorna terheltsége. Etherneten ez a sebesség nagy.
Hogy milyen gyakori lekérdezést tud megvalósítani, arra azt tudom mondani, hogy a WinCC Flexible alapértelmezés szerinti adatgyűjtési ciklus ideje 1 másodperc.
A legkisebb érték ami itt beállítható 100msEgy WinCC Flexible PC runtime-ban lévő kapcsolatok száma maximum 8. Tehát egy runtime maximum 8 PLC-vel tud kommunikálni.
-
n0rbert0
senior tag
Sziasztok!
A Cimplicity (8.1) és a WinCC Flexible (sp3 2008) milyen gyorsan képes adatokat felolvasni a PLC-ből?
Az ügyfelek 500ms alatt szeretnének mintavételezni, legalább 12 PLC-ből, PLC-k ként kb. 60 adat (digitális és analóg is).
Az adatok SQL adatbázisba lennének tárolva.Szerintetek ez megvalósítható valamelyik szoftver segítségével?
-
KLR
csendes tag
Kössz a figyelmeztetést. Nem tudom melyik profilt használják, de utána nézek.
Elméletileg nem kellene hogy problémát okozzon az FC Profil se,mert a VLT 5000-nél nincs definiálva ez a három bit, valószínű nem is használják a PLC programban.Na ez már csak a helyszinen fog kiderülni.
Most már csak kell kerítenem egy USB/MPI-t.
Üdv,
-
-
KLR
csendes tag
A vezér szó (CTW) és státusz szó (STW) megegyezik a két sorozatnál, mint ahogy a referencia érték (MRV) és az aktuális sebesség (MAV) is. Ebben a hálózatban csak a standard telegramot használják (PPO3). Ha lenne paraméter irás-olvasás az más tészta, mert nem ugyanaz a paraméter cimzési rendszer. Akkor bele kéne mászni a PLC programba is.
Persze, ez eddig elmélet, mert még nem csináltam.
Majd meglátjuk (mondta a vak is)
-
Szirty
őstag
Üdv KLR!
"Most már világos, hogy ezek a termékek valójában USB/RS232 + RS232/MPI egybeépítve"
Ezt a megoldást szerintem csak 3rdparty gyártók alkalmazzák, aminek az lehet az oka, hogy így nem kell nekik drivert írniuk, mert az ilyen megoldás a Siemens PC adapter drivert használja.
Nem csak az USB-s, de az ethernetes gateway-ek között is akad ilyen virtual soros portos megoldás.
Nem mindegyik rossz, de ezektől szerintem tartózkodni kell."Ha meg kell táp is, szerintem megoldható egy PG-s Profibus konektorral meg egy 24 VDC-s táppal."
Igen én is így csináltam.
A VLT500->FC302 cserével kapcsolatban annyit meg akartam jegyezni, hogy szerintem nem lesz elég lecserélni a GSD-t. A kettő kezelése kis mértékben eltér egymástól. Pl. a status word és control word kiosztása.
-
KLR
csendes tag
Kössz a kimerítő választ.
Ezek szerint a Siemens 6ES7972-0BB52-0XA0 a legfájdalommentesebb. Ha meg kell táp is, szerintem megoldható egy PG-s Profibus konektorral meg egy 24 VDC-s táppal.
Még furcsáltam is, amikor azt irtad hogy az MPI adapterek nem használják a soros portot, az USB/MPI kábelok zöménél a termékleírásban meg azt írja, hogy telepítés után virtuális com portként jelennek meg. Most már világos, hogy ezek a termékek valójában USB/RS232 + RS232/MPI egybeépítve, és ezek azok, amik nem mennek vagy alig TIA-val meg Step 7 5.5-tel.
Nem hittem volna, hogy ennyi szívás van még az 500 Eur adapterekkel is.
-
Szirty
őstag
Üdv KLR!
Sajnos az van, hogy ha az ember S7-et akar programozni, monitorozni annak szüksége lesz egy interface-re.
Én valamelyik USB-s megoldást ajánlom. A soros porttal működővel problémák vannak. Pl. hogy elképesztően lassú (nem is igazán az átviteli sebesség, hanem a kommunikáció kezdete, a kapcsolat fel és leépítés tart sokáig).Meg hát ugye a ma kapható számítógépeken már nincs soros port, mert a gyártók szerint olyat már senki nem használ. Ehhez képest nálunk pl. több mint 200 (kétszáz!) olyan eszköz van amihez soros port kell(ene). Ilyenkor jön a szarakodás a kina 2000Ft-os USB-RS232 átalakítókkal, aminek a 99%-a szemét és esélyünk sincs hogy rajta keresztül kommunikáljunk.
De ez egy másik történet, amivel kapcsolatban volt már itt vélemény nyilvánítás mások részéről is..Az ethernetes megoldás jobb, de ott durván is bele lehet futni pár kényelmetlenségbe.
Az egyik az IP címekkel, a fix IP-kkel való kavarodás, küzdelem a DHCP szerverrel, switch-ek hurcolása (hogy ne csak a PLC-re hanem a hálózatra is lehessen kapcsolódni egyszerre, stb. Mikor melyikbe, de előbb-utóbb valamelyik nehézségbe ezzel biztos hogy belebotlik az ember.
Ha egy wifi router vagy access point is van a mobil automatizálási hátizsák laborunkban, akkor az ethernetes megoldás jelent annyi kényelmet, hogy vezeték nélkül csatlakozva is programozhatunk, vagy hibafeltárhatunk. Főleg kiterjedtebb berendezéseknél (ahol a gép méretei tíz vagy száz méterekben mérhető) nagy előny az, ha nem kell a vezeték szabta hatótávolság miatt a rendszerint félre eső helyen lévő gép mögötti vezérlőszekrény közelében gubbasztani ahonnan nem nagyon látni mi is történik a frontvonalon.
Az MPI/Profibus ethernetes gateway-ekkel kapcsolatban arra is vigázni kell, hogy legyen hozzá natív Step7 kommunikációs driver, ami külön interface-ként épül be a set PG/PC interface listájába.Épp az IBH softec-nek van olyan MPI/DP gateway-e (ilyenből kettőt is használunk) amiben nincs natív drivere, hanem egy virtuális soros portot (na tessék megint az a soros port, amit állítólag csak az ősemberek használtak és ma már minek az) realizál. Ehhez a PG/PC interface-t PC Adapter RS232-re kell beállítani, mire a Siemens PC Adapter drivere azt hiszi, hogy ez egy PC adapter, mivel azt szimulálja.
Ehhez egy külön IBH-s programot kell futtatni, aminek meg lehet határozni melyik IP című eszközt mutassa azon a virtuális soros porton, aminek számát majd kiszopja nekünk a kisujjából.Azon kívül, hogy minden alkalommal azt kell figyelni (majd a PG/PC interface-nél be is állítani) hogy melyik COM porton szíveskedett materializálódni azzal a hátránnyal is jár, hogy nincs lehetőségünk egyszerre több PLC-vel kommunikálni melyek külön ilyen IBH gateway-en vannak, mivel az IBH szoftver egyszerre csak egyet tud kezelni a program pedig természetesen(?) nem fut több példányban.
Továbbá mivel a (korábban már tárgyalt téma) Step7 V5.5 száműzte a PC Adapter RS232-t nem is tudom hogyan lehetne ezt használni. Konkrétan ennek az IBH-s eszköznem végül van még egy olyan "kedves" tulajdonsága, hogy a kapcsolatot eldobálja.
Óriási élvezetet tud ezzel okozni pl. amikor valamit rövid dieig be akarok kapcsolni (pl. egy merker bitet). tehát be, majd rögtönk ki. No melyik lesz az a pillanat, amikor az IBH gateway eldobja a kapcsolatot. Természetesen az, amikor a bitet már átkapcsoltam ,hogy nehogy már lehetőségem legyen kikapcsolni!
és ez NEM egyszer fordult már elő.
Szóval ilyet NE! vegyél!A Helmolz netlink-nek van natív drivere. A PG/PC interface-nél külön beállítható. Viszont ez sem képes arra, hogy egyszerre több olyan PLC-vel kommunkáljunk amik külön netlink gateway-en ülnek. (ennél és az IBH-nál erre csak akkor nyílik lehetőség ha a PLC-ket profibuszon vagy MPI-n buszra fűzzük és így egy gateway-re kötünk több PLC-t).
Sajnos a netlinket egy idő után száműznünk kellett a rendszerből, mert semmilyen verziójú drivere nem volt hajlandó feltelepülni Windows 2003 szerverre (telepítéskor egy file hiányára utaló hibát dobott, annak ellenére hogy a file létezett mégpedig épp ott ahol kereste). A helmholz forgalmazójától próbáltam támogatást kérni a jelenség pontos (képekkel illusztrált) leírásával. Nem válaszoltak.Mindezekkel szemben a Siemens PC Adapter USB-t bedugom és működik.
De az sem teljesen problémamentes :-) Viszont a legkevesebb baj azzal van talán.
Azzal az a baj, hogy nem tud 12MBPS sebességet. Másrészt meg azzal, hogy 24V-os tápfeszültségét igényel a PLC MPI/DP csatlakozójából.
Addig nincs is gond, amíg közvetlenül egy PLC-nél dugom be. De ha egy ET200-nál akkor nem kap tápot azon ugyanis nincs kivezetve a tápfesz (ki tudja miért).
Külső tápfeszültség ellátási lehetősége meg (legalábbis ennek a régi példánynak) nincsen.Szóval óvatosan ezekkel az interfészekkel, nem mindegy mire dob ki az ember egy lepedőt!
-
KLR
csendes tag
Kössz a választ, ennyivel is okosabb lettem.
A cpu 315-2 DP, nincs eth.
Nézegettem a neten, német webshop-okon az adaptereket (Siemens, Deltalogic, Helmholz, IBH Softech) az USB/MPI kb 400 Eur, az ETH/MPI pedig 500 Eur tájékán vannak (a 130e forint is kb ennyi lehetett). Sajna nincs más hátra, venni kell egyet. Jövő hétre meg marad a kölcsönzés.
-
Szirty
őstag
Helló KLR!
Az RS485 "szárazon" nem jó megoldás, nem fog működni. Az MPI/DP adatpter nem egyszerű jelszint illesztő, van benne HW elég sok.
Nincs a CPU-n ethernet?
Ha nincs, akkor nem fogod megúszni az interface beszerzését (esetleg kérj kölcsön valakitől).Nekünk NetLink PRO van, annak ára 130e Ft körül volt akkoriban. Nem tudom mennyi most de neked elég a NetLink lite is, vagy egyéb USB-s adapter, ami olcsóbb lehet. Magyar forgalmazója van (ad-da kft) tőlük esetleg kérhetsz árajánlatot.
"Ami még elkeserített, hogy több helyen olvastam, hogy a TIA Portal és Step7 5.5 ami Win7 64b alatt is megy, másképp kezelik az adaptereket és nincs támogatás a virtuális COM portra, úgy hogy a régi USB/MPI adapterek nem működnek."
Ezt kicsit pontosítani kell.
Az USB/MPI kábelnek nincs köze a soros porthoz. Van azonban ún. PC adapter nevű interface, aminek van soros portos és USB-s változata is. A Step7 5.5-ben meg van PC adapter driver.
Namost a Step75.4-ben van PC adapter RS232-höz és ŐC adapter USB-hez is driver, a Step7 5.5-ben meg csak USB-s PC adapterhez van.
Ebből következően az alap csomag nem működik soros PC adapterrel. De lehet hogy utólag lehet drivert tenni rá, ezt nem tudom.
Azt viszont tudom, hogy a PC adapter USB Win7 64 bitre telepített Step7 V5.5 SP2-vel működik! -
KLR
csendes tag
Sziasztok.
Jövő héten le kell cserélnem egy Danfoss VLT5000-est egy új FC-302-re, ezért ki kell cserélnem a GSD file-t is az S7-300 HW config-ban (Profibus). Mivel nincs Siemens-es USB/ MPI kábelom, de viszont van pár USB/ RS485-ös átalakítóm (Advantech Adam 4561, Schneider Electric TSX, stb), van-e értelme megpróbálni?
Abból indulok ki, hogy a fizikai layer az MPI-n és a Profibus DP-n is RS485, a többi pedig software.
Meg őszintén, nem igazán tetszik az eredeti 6ES7972-0CB20-0XA0 adapter ára (kb 400 Eur) és nem is kapnám meg jövő héten.
Kinek mi a tapasztalata, van ettől olcsóbb, de megbízható megoldás?Valahol előbb olvastam, hogy Szirty te NetLink Pro-t használsz. Rákerestem, ez Helmholz termék, van USB és LAN-os verzió. Szerbiában nem találtam Helmholz forgalmazót. Kb mi az ára, és melyikbe érdemes invesztálni?
Ami még elkeserített, hogy több helyen olvastam, hogy a TIA Portal és Step7 5.5 ami Win7 64b alatt is megy, másképp kezelik az adaptereket és nincs támogatás a virtuális COM portra, úgy hogy a régi USB/MPI adapterek nem működnek.
Az e-Bay-en van rengeteg USB/MPI átalakító 25-250 $ (persze eredeti kinai), de szerintem 50% esély van, hogy jó lesz, de 100% hogy nem
-
Szirty
őstag
Szevasz tibi-d!
Egy "reset to factory settings"-el egybekotott "Operating system update"-re lesz szükség. Illetve ezzel érdemes próbálkozni.
Az alábbi doksiban megtalálod hogyan kell csinálni:
SIMATIC HMI HMI Device TP 177A, TP 177B, OP 177B (WinCC flexible) Operating InstructionsVan két hártánya a dolognak:
- RS232 vagy USB PPI multi master kábel kell hozzá
- A panelre töltött licenszek elvesznek -
KB.Pifu
tag
Szia!
Valahogy jobban bele kell merülnöm, mert egy elég érdekes problémába futott bele a cég.
heteken át a stancoló (műanyag lapokból üti ki megfelelő helyen a lyukat a különböző típusú csatiknak) szerszámot állandóan ki kellett szedni és babrálni.
A stancolt anyagot egy szervó hajtás pakolta be és vette ki.amióta meghalt a Lexium motor (béke poraira) és új lett berakva, azóta egyszer nem láttam kivéve a szerszámot. Ha ezt úgymond előre lehet látni és bebizonyítani, hogy bizony nem tized vagy századmm-re a végálláson áll meg (amit nem érzékel, csak az inkrementális jeladóra hagyatkozik) akkor nagyon súlyoz ezer eurókat lehetett volna spórolni.
Meg amúgy is érdekel a téma, szerintem a hajtástechnika a sava borsa a villamos szakmának
Úgyhogy ha lemegy az audit miatti fejetlenség a cégnél újra beleásom magam a körmozgás és a villamos motorok rejtelmeibeüdv Pifu
-
Szirty
őstag
válasz
KB.Pifu
#4164
üzenetére
Üdv!
Nos akkor hagyd a FESTO-t egyelőre.
Mindazonáltal egybe is bele lehet merülni annyira hogy ha semmi mással nem foglalkozol csak azzal az egyel, akkor sem érsz a végére.Nos a szervó hajtás téma is megér egy fejezetet, az biztos.
Tulajdonképpen egy frekvenciaváltó, kiegészítve egy pozicionáló vezérléssel. Az esetek többségében van egy útmérő visszacsatolás is.
Talán a leggyakrabban egyszerű pozicionálásra használják, amikor kap egy cél pozíciót és egy start jelet, mire elmegy oda egy előre megadott sebességprofil betartásával (gyorsítás, sebesség, lassítás).
De a legtöbb ennél többre is képes, mindenféle furmányos alkalmazásokra is használható.
Nálunk pl. a menj oda, gyere ide mellett ún. "maradék út pozicionálásra" is használjuk.Szinkronizálásra is alkalmas a legtöbb. Ez az egyszerű sebesség szinkrontól kezdve a pozíció szinkronon át a CAM görbét követő több tengelyes szinkronig terjedhet.
-
byte-by
tag
válasz
KB.Pifu
#4164
üzenetére
halo !
festo-plcvel 96 elötti tetra pack gépek kapcsán találkoztam, de a tetra szerint lassúak voltak meg a szoftverük sem valami baráti, ezért többet nem alkalmazták őket. nekem igazán tapasztalatom nincs velük.
a servo-k jópofa dolog. amennyi paramétert tudnak én még soha nem használtam ki.
talán mindegyik fajta közös jellemzője a servopoziciók felvétele. valamint az ehhez kapcsolódó egyéb paraméterek gyorsulás, lassulás, görbék,nyomatékok stb.ha gondolod és tudsz szerezni valamilyen szoftvert nyugodtan nézz bele.persze jobb lenne egy működö motor, de a szoftver is mutathat érdekes dolgokat.
nagyon jó,felhasználó barát és érthető a festo ujabb fejlesztésű dnci motorok és szoftvere, de személyes kedvencem az SMC.
a festo szoftvere pár éve ingyenes volt , nem tudom ez változott-e.byte
-
arma760
újonc
Sziasztok.
új volnék itt koztetek. Volna elado jo áronn egypár cuccos.
N70 PLC MOTHER -8SLOT CPL9508 HVLB-101-5AA
Allen Bradlay NX700 series.....NX POWER
NX CPU750B
NX Y32RV
NX DEVICE
NX MWLINK
NX X16D
NX X32D
Expansion unit Machine 1-0....8 in - 8 SINK OUT-24V DC
Expansion unit Machine 1-0... 16 inputs-24V DC -
KB.Pifu
tag
Szia!
Ez így igaz, csak ha nagyon új akkor sokat kell vele foglalkoznom, nekem meg limitált az erre fordítható energiám, úgymond inkább a biztosra kell hogy menjek és az elterjedteket nézegetni.
Meg egy másik téma is feljött ami fontos.
A szervómotorok, azt már tényleg csak élesben lehet megtanulni, nem?
Most teszem azt tisztában vagyok a nyomatékok, forgásmennyiségek fizikai vonzatával stb, még talán egy pidet is össze tudnék rakni sőt, ha mindent tudok akkor még a Wissim-ben is rajzolok egy jelleggörbét, de ezek még vagy már nagyon elméletiek. Év elején nagyon sok energiát fektettem a differenciális egyenletekbe és az átviteli függvényekbe. Bánni nem bánom, csak éppen hasznát még nem látni. -
Szirty
őstag
válasz
KB.Pifu
#4162
üzenetére
Üdv Pifu!
Én nem láttam még olyat, azt is csak messziről.
Valószínűleg nem túl gyakori, bár lehetnek iparágak ahol az, nem tudom. Valószínűleg főleg a FESTO saját megoldásaiban fordul elő a leggyakrabban. Az oktatásban nagyon nyomták régen.Érdemes foglalkozni vele, hiszen minden tudás és tapasztalat érték amit szerzel, no meg ki tudja merre sodor a szél.
-
Szirty
őstag
Szevasz hzs90!
Ha nincs szimulátor a gépeden, akkor sehogy.
A PLC-k hmm "világa" más mint a programozható reléké. Ez főleg az eszközök tágabb képességei és emiatt a hozzájuk való fejlesztői környezetek szükségszerűen nagyobb "volumenje" miatt van.
Neked a CX-Simulator Debugger nevű "szoftver csodára" van szükséged.
Ha csak a CX-Programmert telepítetted, netán a demo/alap verziót, akkor azért nincs olyanod. ha a CX-One csomaggal rendelkezel, akkor van.Ha van ilyened, akkor a CX-Programmer Simulation menüjéből a Work online simulator pontot választva futtathatod a szimulátort és benne a PLC programot.
A ki és bemenetek állapotát magában a programban láthatod ha minitorozod, vagy pl. a Tools menüben található Switchbox utility is alkalmas erre.Persze kérdés még, hogy milyen verzióval rendelkezel, mert az se mindegy, de nem árultad el.
(Talán nehézségbe ütközik a verzió megállapítása, vagy lényegtelennek ítélted ezt az információt közölni) -
hzs90
csendes tag
Sziasztok!
Szakdolgozatomat csinálom OMRON PLC-vel. Aki otthon van ebben a témában, CX-programmerben hogy lehet szimulálni a megírt programot? Szeretném látni a kimeneteket, hogy mindent jól csináltam-e. Futtatásnál mindig kiírja, hogy nincs csatlakoztatva az eszköz (PLC), nem tudom hogy lehetne ezt kikerülni. Nem szeretnék jelenleg venni.
Régebben programozható relékkel dolgoztam, pl Easy Pro-ban egyszerűen lehetett látni, hogy mik lesznek a kimenetek PLC csatlakoztatása nélkül. Előre is köszönöm
-
Szirty
őstag
válasz
KB.Pifu
#4157
üzenetére
Üdv!
"a kérdésem az lenne, hogyha a bytot-t integer típusú lokális változóba "mozgatjuk" akkor az integer nulladik sorszámú byte-ja mindig 0-val lesz feltöltve?"
Így van! Mivel a word nagyobb helyiértékű byte-ja van elöl (az alacsonyabb címen).
A "STEP 7 - Ladder Logic for S7-300 and S7-400"-ban említik is ezt:
Vagyis:
Amikor értéket mozgatunk eltérő hosszúságú adattípusok között, akkor a mgasabb helyiérték csonkul ha szükséges, vagy nullákkal lesz feltöltve.A táblázat pedig bemutatja mindkét esetet egy-egy példával. vagyis hogy mi történik ha hosszabbat mozgatunk rövidebbe és fordítva.
Ha megnézed, a LAD vagy FBD MOVE utasítás STL-ben egy LOAD és aegy TRANSFER utasításra fordul le. A LOAD pedig így működik:
"Description
L <address> loads the addressed byte, word, or double word into ACCU 1 after the
old contents of ACCU 1 have been saved into ACCU 2, and ACCU 1 is reset to "0"."Vagyis:
Betölti a címzett byte, word, vagy double word adatot az ACCU1 regiszterbe miután az ACCU1 korábbi tartalmát ACCU2-be másolta és az ACCU1-et törölte (nullát rakott bele).
Tehát a load előszőr átpakolja ACCU1-et ACCU2-be, majd ACCU1-be nullát rak és azután beleteszi a címzett adatot. Mindkét ACCU 32 bites, így ha 32 bitnél rövidebb adattípust töltünk be (byte, word, int) akkor az ACCU nem érintett magasabb bitjei nullák lesznek. -
KB.Pifu
tag
Szia Szirty!
Olvasva a weboldalad lopkodom az ötleteket a kis szimulátoromhoz.
Pl byte-ban tárolom a "jig-ek" ben található termék azonosítóját (ok, ng, üres, emlékezz vissza a HMI ra feltett kérdésemre, hogy ugyanaz az alakzat hogy vehet fel kettőnél több színt).Szóval amit ellestem az a byte ladderban történő összehasonlítása Integerrel a Move utasítás segítségével.
Az én értékeim csak 1, 2, 3 , szóval a megengedett tartományon belül találhatók, a kérdésem az lenne, hogyha a bytot-t integer típusú lokális változóba "mozgatjuk" akkor az integer nulladik sorszámú byte-ja mindig 0-val lesz feltöltve? -
KB.Pifu
tag
válasz
sörösló
#4152
üzenetére
szia!
Jó hogy emlékeztettél erre, el is felejtettem, hogy bizonyos létezik az a bizonyos fékellenállás és ráadásul jó okkal.
Lehet én túlreagálom a dolgot, de például nem szívesen mennék pályakezdőként olyan üzembe, ahol nagyobb a felelősség és emberélet múlhat rajta, nekem egyelőre a pneumatikus összeszerelő gépek és robotcellák a megcélzott kategória.
Ezért hoztam fel a safety témát, mert méltánytalanul elhanyagolt szerintem. Bármelyik cég túléli ha valaki véletlen összetör egy-két 150 ezer forintos munkahengert, de csak egyszer törjön el valakinek a keze vagy sérüljön meg és azt évekig emlegetni fogják.
-
Szirty
őstag
válasz
sörösló
#4152
üzenetére
Üdv!
"A Vész-Stop kör mindig soros kiépítésű, még a sokszázéves gépeken is! "
Főleg azokon. De mint szinte minden alól, ez alól is van kivétel.
Pl. vannak olyan elkerített veszélyes terek, amikbe és belőlük ki üzemszerűen járkálnak a munkadarabok, vagy rakatok. Ha nincs a szállító pályán rakat, akkor annak helyén az ember be tud sétálni. Tegyünk biztonsági fényfüggönyt! De akkor a gép saját magán alkalmaz vészleállítást, amikor jön a kész rakat és keresztezi a fénysugarat. Akkor tegyünk bypass fotocellát. A rakat üzemszerűen eltakarja mindkét bypass fotocellát, amik ha egyszerre vannak eltakarva, akkor párhuzamosan áthidalja, azaz hatástalanítja a biztonsági fényfüggönyt. A bypass fotocellák pedig úgy vannak elhelyezve, hogy a sugár egy keresztet írjon le több méteres fesztávval. Így egy ember nem tudja sem véletlenül, sem szándékosan úgy eltakarni őket, hogy az hatástalanítsa a biztonsági leállítást. Kivéve ha az ember tudja hogy működik a bypass és egyszerűen munkavédelmi kesztyűt húz a bypass fotocellákra, vagy rongyot dob a prizmákra. (A gépkezelők rendkívül találékonyak)
Vagy van olyan veszélyes tér, amiben a gépkezelő egyszerűen kénytelen dolgozni. Pl. nyomdaipari gép, ahol hatalmas papírtekercs fogy. A tekercs környéke elkerített, biztonsági ajtó, azon reteszelt biztonsági végállás, vész gomb minden oldalról, bent is, fényfüggöny, stb.
De a tekercset cserélnie kell ha kifogy. Feltesz egyet targoncával és be kell neki fűznie. Ilyenkor a mozgó gépbe fűzi be, álló gépbe nem lehet. Akkor jön a deadman switch.
Aki nem tudja annak írom le röviden hogy ez egy olyan (többnyire vezetékes) hordozható biztonsági eszköz, amin van egy több fokozatú nyomó kapcsoló. Félig kell benyomni. Ha teljesen benyomják vagy elengedik akkor szakít.
A kezelő a gépet beállító módba kapcsolja, ilyenkor lassabb minden mozgás. Kinyitja az ajtót, átmegy a fényfüggönyön és közben viszi magával a a deadman switchet és nyomja félig. Ezzel áthidalja a biztonsági rendszert párhuzamosan (és persze ideiglenesen).Vagy képzeljünk el egy gépet, amit robot szolgál ki. A robot körbe van kerítve, külön biztonsági cellában dolgozik. De van egy üzemmód, amikor a gépet ember is kiszolgálhatja. Ilyenkor a robot ki van kapcsolva. A kiszolgált gépen van egy fényfüggöny, ami védi az embert. Ha belenyúl a gépbe, akkor vészleállítás történik. Ám ha a robot szolgálja ki, akkor nem állhat meg a fényfüggönyre, így a robot üzemmód a fényfüggönyt párhuzamosan áthidalja.
Ellentétes feltételeknek kell egyszerre megfelelni, ezért (is) sok a herce-hurca ebben a témában.
-
Szirty
őstag
válasz
sörösló
#4152
üzenetére
Üdv sörösló és Pifu!
Nem akarok vitatkozni, nincs is min igazán, egyetérteni jöttem! :-)
sörösló! Azzal együtt,hogy teljesen egyetértek mindazzal amit írtál megjegyzem,hogy Pifu is elég jól összefoglalta a biztonsági vészleállítás néhány alapvetését.Kivétel mindig van, egy emelőgépet sem lehet úgy leállítani hogy hagyjuk lezuhanni a terhet, ez nyilvánvaló.
Globális statisztikai alapon mégis messze az a leggyakoribb alkalmazás, amikor a motort (esetleg a hajtásvezérlővel együtt) szelepet, miegymást egyszerűen lekapcsoljuk az energiaátvivő hálózatról.
De nem kizárólag és minden esetben. És itt jössz te :-) Nem biztos hogy erőműben célszerű a hűtőszivattyúval is így bánni, stb, stb.Ezt is az alapoknál érdemes kezdeni és nem az összetettsége csúcsán.
-
sörösló
aktív tag
válasz
KB.Pifu
#4137
üzenetére
KB.Pifu
"Gondolok olyanra, hogy Vész-stop megnyomásakor a motortól nemcsak a vezérlést, hanem a feszültséget is el kell venni."
OK! Aztán mi lesz? "Gurul a nehéz kő, ki tudja hol áll meg. Ki tudja hol áll meg, kit hogyan talál meg". Erősen alkalmazásfüggő hogy egy hajtást lehet-e szabad kifutással leálítani. Hogy parasztul fogalmazzak: - Bédobhatom-é a gyeplűt a lovak nyakába osztán majd leugrok a szekérrűl ha baj leszen? Nem egyszerű probléma ez. Nálunk működik egy flexo nyomdagép. A központi ellennyomóhenger 3 m átmérővel, 6 tonna önsúllyal forog 350 m/perc kerületi sebességgel. Na mármost képzeld el a Vész-Stop funkció két szélsőséges esetét. Az első a szabad kifutás. Ez a tömeg a két jólkent csapágyazásán kb. egy óráig még forog. Ha bekapott valakit és azért nyomtál vészstopot, akkor a valakiből még darálthús se marad mire megáll. A másik szélsőséges eset meg az, amikor valamilyen trükkel azonnal megállítod. Ebben az esetben a forgó tömeg a tehetetlenségi nyomaték miatt feltépi maga alól a tőcsavarokat és kigurul a csarnokból! Az egyetlen járható út a vezérelt leállítás. Ehhez az kell hogy a vészgomb működtetése után még legyen anyi ideig vezérlés, hogy a hajtás a leállítási folyamatot végre tudja hajtani. Van hozzá egy köbméteres fékellenállás, ezzel kb. 30 mp alatt megeteti a forgási energiát, az ellenállás persze világít mint a karácsonyfa, de megáll ésszerű időn belül.
"Vagy a vészkapcsolók NC gombokkal vannak kiépítve stb."
Az NC gombok sem lehetnek egyszerűen NC-k! Nem használható ilyen helyen úgynevezett mikrokapcsolós vagy "pattanó", rugósműködtetésű kapcsolóelem! Vészkörben csak közvetlen működésű, egyszerű nyomásra működő kapcsolóelemek használhatók.
"a vész-kör sorosan van kiépítve és közvetlenül a plc vezérli, vagy mondjuk a biztonsági relé és csak az adja a jelet plc-nek"
A Vész-Stop kör mindig soros kiépítésű, még a sokszázéves gépeken is! A Safety relék még külön is vigyáznak arra hogy ne lehessen becsapni őket. A PLC meg általában csak információt kap a független vészkörtől, hogy esemény történt! A safety PLC egy külön mise, ne merüljünk bele.
"Nagyobb teljesítményű gépeknél kétkezes indítás van, azt kötelező biztonsági relével megoldani, vagy azt vezérelheti a plc?"
A kétkezes indításnak semmi köze a teljesítményhez. Régebben csináltam időrelés vezérlést ilyesmire, de manapság már csak az erre alkalmas GYÁRI relét használnám. Ha valakinek erre nincs pénze, az ne építsen gépet! Vészköri funkciót CSAK SAFETY PLC vezérelhet!
Nem egyszerű probléma, az internet bőséges forrást tartalmaz a kockázatelemzésről. Szerintem is kissé túllihegett a probléma, egyetértek Szirty-vel. De a törvényi szabályozás szerint életed végéig felelősséggel tartozol az általad alkalmazott megoldásokért, úgyhogy meggondolandó, mihez adod a nevedet.
-
KB.Pifu
tag
válasz
byte-by
#4149
üzenetére
Üdv!
Manapság változnak az idők, mindent azonnal kell és nincs idő molyolni.
Mostanság járogatok állásinterjúkra, minden kérdés azt feszegeti , hogy programoztam-e már gépet.
Pályakezdőként is legyen minimum 3 év tapasztalat , nem is kapok munkát (legalábbis nem azokban a megyékben ahol én szeretnék)Sokan nem tudják, de az amit oktatnak az semmi, alapok, egyszerű sorrendi vezérlések maximum, ha eljutunk egyáltalán gép közelébe, anno nekem (5 éve) valami 27 éves matuzsálem Spartan3 (talán ez volt) volt gyakorló PLC-m.
Kb a logika az amit lehetett a kis relével húzogatott ledeken nézegetni.
Ez meg beugrónak nagyon kevés, gyakorlatilag semmi. Most itthon játszogatok az S7-tel és a PLCSim-mel, sajnos ez a maximum amit tehetek. -
-
byte-by
tag
halo !
" Van egy másik tényező is ami nincs rá: pénz.
Egyre inkább."egyetértek.az sincs rá.
ez egyébként nagyon komoly problémákat okozhat. az olcsóbb anyagokból előállított alkatrészek kopásállósága értelemszerűen gyengébb, ez mindenre vonatkozik, csavarokra, lemezekre,támasztékokra, csapágyakra, sínekre, olcsóbb munkahengerekre ,stb.
csak egy példa : találkoztam olyannal, hogy az építő cég bevállalta , hogy egy emúlzióban alkatrészeket öblítő gép hengereinek érzékelőit nem ellenálló kivitelű érzékelőkkel szerelték, hátha szerencséjük lesz. persze a vezetékekről egy idő után simán levált a szigetelés, akkor is ha közvetlen kapcsolat nem volt a mosóközeg és a hengerek között, csak fröccsenés és a levegőben lévő mosópára.
az érzékelők nem mindíg érzékeltek, persze a megoldást tőlem várták: legyen élvezérlés,legyen elég ha csak elmegy előtte, az alaphelyzet nem is olyan fontos , időzítők használata - a biztonság minek,stb. anyádat.sajnos ma már készülnek durva fostalicskák. tisztelet a kivételnek természetesen.
az biztos, hogy soha nem a gép a hülye, az csak azt teszi amire a tervezője képessé teszi és amire a programozója utasítja.byte
-
Szirty
őstag
válasz
byte-by
#4145
üzenetére
Helló byte-by!
"a gépépítés tényleg jó.izgalmas meg minden.de egyvalami nincs : idő"
Van egy másik tényező is ami nincs rá: pénz.
Egyre inkább.
Az elvárások maximálisak, de a szakadék szálán kell táncolni. Pl. egyszerűbb gép esetén ne legyen benne PLC, csak relés vezérlés legyen, mert az iolcsóbb. HMI nem kell, csak kapcsolók, meg visszajelző lámpák.
Hiába mondjuk előre, hogy rendben van, lehet így is, de akkor az utólagos módosítgatás a működésbe sokkal fájdalmasabb lesz, mert egyrészt van fizikai vonzata, másrészt minden ilyen módosítást egyenként utólag be kell vezetni a tervbe. Ezek miatt a módosítás nagyságrendekkel több időbe és pénzbe kerül.Vagy a PLC-s vezérlésbe a legolcsóbb szöveges HMI-t választják. De azon meg kell oldani, hogy mindent lehessen megnézni, mindent lehessen állítani, az egész föld térképét rá kellene tenni.
Ingyen legyen tegnapra, mindent tudjon!
-
byte-by
tag
válasz
KB.Pifu
#4143
üzenetére
halo !
a gépépítés tényleg jó.izgalmas meg minden.de egyvalami nincs : idő.gyakorolni se.
én dolgoztam ilyen cégnek, fura volt, hogy néha lassan indult be egy-egy projekt, majd valahogy hirtelen nagyon sürgőssé vált és tegnapra kellett a gép.
plusz a módosítások módosításának a módosítása ,mielőtt módosítanánk a módosításokat.
sok plusz kérés, stb.sokszor egy termelő sor beépülő gépállomását csináltuk meg, azt például csak vasárnap lehetett installálni , de az éjszakás műszakra már termelnie kellett.
vagy meglévő berendezést kellett bővíteni, átépíteni és erre csak szombat és vasárnap estig volt lehetőség.
hányszor, de hányszor kértem csak 15 percet, hogy lássam mi történik , hogy dolgozik a gép amit módosítani, átépíteni, stb. szeretnénk.vagy bujkáltam a dolgozók között, lábuk alatt.legjobb barátom a szünet volt, amikor a dolgozók kimentek 10-15 percre.volt olyan vasárnap, hogy épp végeztünk egy géppel, beépítettük a sorba.jó is lett.
egy másik gépet egy másik cég bővített két plusz munkahengerrel.de sem elektromos embert , sem PLC-s embert nem hoztak magukkal. kicsit elbeszéltek egymás mellett a megrendelővel.
már csak én voltam ott tőlünk, este 8 óra volt.akkor jött oda a helyi supervisor és megkérdezte be tudnám -e kötni a másik cég által beszerelt plusz alkatrészeket, illetve módosítanám-e a programot.de 22 órakor jön az első műszak, szóval működnie kellene.az elektromos kollégát visszahívtam, mert igy már sok volt, vissza is jött és bekötötte az érzékelőket és a szelepeket, amíg én rájöttem mit is akar a gép csinálni, és átírtam a programot és a HMI-t, nem volt vészes.
22-re nem de 22:30-ra működött.én szerettem ezt csinálni, kár , hogy már nincs.egyébként pl. (egy) japán érdekeltségű cégnél a biztonsági relé nem kötelező.saját elvárásai vannak, de azok ultra szigorúak. Master relé kell, de ez bármilyen lehet duplikálva. persze náluk más a leány fekvése: NPN logika, pozitív sarok földelés, 100-200v-os hálózatok, stb. persze a Master itt is hardveres kizárás, de nem kell biztonsági relé.
byte
-
Szirty
őstag
válasz
KB.Pifu
#4143
üzenetére
Üdv Pifu!
"Szerintem a legfontosabb témát sikerült kiválasztanom, mert amíg a safety nincs a helyén addig semmi sincs."
Bizonyos szempontból. Konkrétan a hatósági ellenőrök, a munkavédelem szempontjából.
Egyébként meg az a lényeg, hogy a gép termeljen. És ezt most csupa nagy betűvel. BÁRMI ÁRON!Na ezzel a kettővel kell kezdeni valamit "a életben".
-
KB.Pifu
tag
Sziasztok!
Köszönöm a segítőkészséget.
Szerintem a legfontosabb témát sikerült kiválasztanom, mert amíg a safety nincs a helyén addig semmi sincs.
Ez csak azért szomorú, mert elvégre végzett mérnök vagyok, de főiskola alatt még csak nem is esett szó a biztonsági reléről. De talán mentségemre szól, hogy azelőtt akarom bepótolni a hiányosságokat mielőtt még egyáltalán élesben kellene foglalkozni vele.Ezt szem előtt tartva, tudnátok pár olyan fontos dolgot mondani, ami mondjuk egy állásinterjún is megfelelően hangzik és még után is tudnék nézni. például a cégnél mikor unatkoztam a preventa datasheeteket nézegettem, szerintem ez elég hasznos időtöltés.
A helyzet az, hogy mindennél jobban szeretnék egy célgépépítő cégnél dolgozni, de bekerülni ilyen helyre nagyon nehéz, most karbantartásban dolgozom, ahol leginkább gépészeti kihívások fogadnak amire egyszerűen nem vagyok felkészülve. Pl múltkor két napig állt a gép mire sikerült bebizonyítani a hozzá értőnek, hogy a szerszám tized mm kopása miatt nem megfelelő a beültetés, mondjuk ezzel nincs semmi gond, leolvassuk a szerszám rajzáról méreteket és a tűrést és utánanézünk, de a bajok ott kezdődnek, hogy meg kell találni azt amiről feltételezzük, hogy elkopott.
Egy szó mint száz, napjában többször hallom, hogy tized mm és tűrés, ellenben a byte szót még senki nem vette a szájára.üdv
Pifu -
Shirchy
tag
Hali!
Sikerült szereznem egy Siemens PLC bővítő modullal HMI-vel,viszont sajnos egy kábelt sem kaptam hozzá. Asztali gépen keresztül szeretnék itthon gyakorolgatni. Programozó kábel kellene,illetve még egy ugye amivel össze tudom kötni a CPU-t a HMI-vel.
Tudnátok segíteni milyen kábelek szükségesek/megoldások vannak,hogy minél olcsóbban életet tudjak lehelni a cuccba?
Esetleg valakinek eladó kábelek,vagy itthoni kábel építős megoldás?
CPU 224 DC/DC/DC (214-1AD23-0XB0)
EM 223 DC/DC (223-1BL22-0XA0)
TD 200Előre is köszönöm!
-
Szirty
őstag
válasz
KB.Pifu
#4139
üzenetére
Üdv Pifu!
Igen a biztonsági reléről természetesen lehet (és többnyire kell is) információt visszavezetni a PLC-be, hogy az intézkedni tudjon ilyen esetben (üzenet megjelenítése, technológiai (nem safety) beavatkozások elvégzése stb.).
A dolognak egyéb folyományai is vannak. Pl. ha terepi buszos hajtásvezérlők betáplálását választja le a1 biztonsági relé, akkor az eszköz eltűnik a buszról, aminek további következményei lehetnek. Ezzel is foglalkozni kell. Amire több lehetőség is van.
-
Szirty
őstag
válasz
KB.Pifu
#4137
üzenetére
Üdv Pifu!
Ez a téma nagyon messzire vezet. Elképesztően sok előírás, ajánlás és szabvány szabályozza a dolgot.
Szinte már politika az egész- Eszméletlen pénzek vannak a dolog mögött.
Minden eszköz ami safety kb. tízszer annyiba kerül.Van néhány gyakorlati irányelv, ami ésszerű.
Pl. hogy a biztonsági kör a vezérlőtől (pl. PLC) függetlenül kell hogy letiltsa a berendezés beavatkozó szerveinek (motorok, szelepek, stb) energia ellátását.
Kivéve ha a vezérlő safety (biztonsági előírásoknak megfelel) aminek az ára kb. hússzoros.Hogy milyen géphez milyen biztonsági intézkedések szükségesek (két kezes indítás, fényfüggöny, redundás vagy szimpla vész kör, deadman switch, stb) az tervezés során az ún. kockázat elemzés során dől el.
"Nagyobb teljesítményű gépeknél kétkezes indítás van, azt kötelező biztonsági relével megoldani, vagy azt vezérelheti a plc?"
Biztonsági funkciót csak safety képes PLC láthat el. Ha a PLC nem az, akkor a kétkezes indításhoz kétkezes indításra való biztonsági relé kell (tízszeres ár, a safety PLC-s meg még többszörös).
-
KB.Pifu
tag
Sziasztok!
Mivel még sosem programoztam gépet, csak tanulok de szeretnék kérdezni.
Végzett villamosmérnök vagyok, nagyjából ismerem a szabályokat (azért nagyjából mert az oktatásból ennyire futotta, azért kérdezek mert be akarom pótolni ami elmaradt)
A biztonságot szem előtt tartva, mik a kötelező szabályok amit nem szabad megszegni.Gondolok olyanra, hogy Vész-stop megnyomásakor a motortól nemcsak a vezérlést, hanem a feszültséget is el kell venni. Vagy a vészkapcsolók NC gombokkal vannak kiépítve stb.
hasonló dogokat szeretnék tudni, gondolok én arra ,hogy a vész-kör sorosan van kiépítve és közvetlenül a plc vezérli, vagy mondjuk a biztonsági relé és csak az adja a jelet plc-nek.
Minden olyan fontos dolgot tudnom kellene ami a gépek programozásánál a biztonságot garantálja. Például addig nem indul a gép, míg van nyitott ajtó stb.
Nagyobb teljesítményű gépeknél kétkezes indítás van, azt kötelező biztonsági relével megoldani, vagy azt vezérelheti a plc?
-
Szirty
őstag
válasz
dodzylla
#4135
üzenetére
Helló dodzylla!
Jó ötletnek tűnik.
Az ilyesmit én támogatom. Akár a web oldalamon is adok neki helyet ha az a megoldás érdekel (természetesen a szerzők neveinek feltüntetésével).Viszont arra számíts, hogy ha ezt komolyan akarod csinálni és nem csak egy kósza ötlet, ami elhal az első néhány próbálkozás után, akkor nagy munka!
A tartalom tekintetében egyelőre nem tudom pontosan mire is gondolsz, de ha tudok segítek.Ajánlanám még figyelmedbe az ex prohardveres PLC fórumot, ami a googlegroups-on ébredt újra.
A jelenlévők által ott is komoly szakmai erőforrások vannak a háttérben. -
dodzylla
csendes tag
Üdv Emberek!
Múltkorjában még írtam ide OPTOVED es tanfolyamomon, elvégeztem azt is , meg leraktam egy automatika technikusit is. Sajnos igazából csak alapokra volt elég az egész, és nem sok időm volt foglalkozni vele a főiskola miatt (emiatt főleg csak olvaslak titeket). Most arra gondoltam ,hogy ebben a fórumban amúgy is hatalmas tudás lett összehalmozva, megpróbálnék egy katalogizált tudás bázist összedobni, amolyan hiba jegyzet szerűt, hátha sokaknak segítene, ha valakinek van hozzá ötlete szívesen fogadom
-
Szirty
őstag
válasz
KB.Pifu
#4133
üzenetére
Szevasz Pifu!
"Keresztbecímzésben lesz a hiba, innen legalább már erre is figyelek."
Arra bizony nagyon oda kell figyelni, mert nagyon durván lehet szívni ilyen hibával!
Segít ezt elkerülni a keresztreferencia táblázat. De nem árt érteni amit mutat. Nem bonyolult, csak elsőre riasztóValamivel barátságosabb (kevesebb fölösleges infót ad ha csak egy cím érdekel) a Go To Location funkció.
A lényege az, hogy megmondja hol fordul még elő az a cím a programban. Csak azzal a címmel foglalkozik (míg a keresztreferenciában az összes benne van).
Egy listát kapsz az előfordulásokról amiből ha választasz, akkor oda ugrik.
Az ablakban van egy opció, aminek a neve "Overlapping access to memory areas".
Ha azt is bekapcsolod, akkor minden olyan címet is beletesz a listába, ami átfedésben van a keresett címmel.
Ez rendkívül hasznos!
A probléma akkor fokozódik, ha DB címekről van szó. Azokat ugyanis el lehet érni teljes címzés nélkül is. Pl. így:
OPN DB6
L DBW4Mivel a fordító nem végez kód elemzést (nem is nagyon tehetne ilyet), nem tudja, hogy ha van egy L DBW4 az a DBW4 melyik DB blokkra vonatkozhat.
Azonban a GoTo Location ezeknek a megkeresésére is ad támogatást.
Ha csak a rövid címet adod meg, akkor felsorol minden olyan programsort, amiben az adott bit, byte word, dword címzése szerepel bármelyik DB-ben.
Hogy melyikben szerepel azt pedig megmutatja (ha tudja) ha kiválasztod az adott sort:
A probléma tovább fokozódik ha a keresett címet a program valahol indirekt módon is írja.
Az indirekt címzéssel e a keresztreferencia és így a GoTo Location sem tud semmit kezdeni, hiszen annak jellegéből adódóan a cím csak futás közben derül ki. Futás közben egy címet pedig számtalan körülmény befolyásolhat a kódtól függően, a fordító nem tudja előre hogy a lefordított kód milyen körülmények között milyen címet fog majd kiszámítani. -
Szirty
őstag
Helló skul0!
Nagyon úgy néz ki ez, mint egy olyan gyakorló feladat, aminek a megoldásához FIFO buffert kellene építeni. Ezt abból gondolom, hogy előírta a MOV használatát.
Én úgy csinálnám, hogy kijelölnék egy 3 elemű tártelütetet a buffer számára. Pl. D0-D2.
D0 lenne a FIFO teteje (bemenete) és D2 az alja (kimenete).A FIFO úgy működne, hogy ha a D1 tartalma nulla, akkor beleírnám a D0 tartalmát és a D0-t törölném (0).
Utána ha a D2 tartalma nulla, akkor beleírnám a D1-et és a D1-et törölném. EZzel kész is a 3 elemű buffer.
Amikor egy tartály kiürül, a tartály számát bedobnám a FIFO tetejére (beírnám a D0-ba). Amennyiben a buffer üres, a fenti MOVE-ok (melyek minden PLC ciklusban lefutnak) a felül beírt érték leesne az aljára. Ha nem üres, akkor a benne lévő tetejére.
Így már nincs más dolgunk, mint a FIFO aljáról kiolvasni az értéket. Ha ott 1 van, akkor az 1-es tartályt töltjük, ha 2 van akkor a 2-est, ha 3 van, akkor a 3-ast.
Érdemes minden tartályhoz egy-egy RS tárolót (KEEP) használni, amit az adot ttartály leürülése bekapcsol, a megftelés pedig kikapcsol és a FIFO tetejére akkor bedobni a tartály számát, amikor ez az RS tároló bekapcsolt.Így elkerülhető, hogy a folyadék lötyögése esetén többször is beíródjon a FIFO-ba ugyanannak a tartálynak a száma.
-
skul0
aktív tag
Üdv!
Omron cj1m plc programozásával kapcsolatban lenne egy kis útbaigazításra szükségem.
Adott 3 tartály alsó- és felső szintérzékelővel, valamint tartályonként egy-egy ki és beresztő nyílással. A tartályokból folyik ki a víz, és ha valamelyik alsó szintérzékelő jelez, a kifolyást meg kell szüntetni, és el kell kezdeni tölteni. Egyszerre csak egy tartály tölthető, ezért ha valamely tartály töltése közben egy másik kiürül, akkor azt sorba kell állítani, mert a feltöltés a kiürülés sorrendjében történik.A feladatot MOV utasítással kellene megoldanom, de nem igazán jutottam előre vele. Az alsó szintérzékelők egy számlálót léptetnek, aminek az értékét összeadva egy számmal beírom a D memóriaterületre. Ez határozza meg, hogy a MOV hova mozgasson.
Nekem viszont úgy lenne jó, hogy egy bitre léptesse be sorba a kiürülés sorrendje szerint, és ezt a bitet összehasonlítva már tudná, hogy épp melyik tartályt kell töltenie.
Hogyan lehetne ezt megoldani? -
Szirty
őstag
válasz
KB.Pifu
#4127
üzenetére
Helló Pifu!
Ilyen indokot én sem tudok (szerintem nincs is).
Ha egy merker bitet (Mxxx.y) bekapcsolsz bármelyik blokkban, az minden más blokkban bekapcsolt állapotú lesz mindenféle deklarációs trükk nélkül is. Legyen az OB, FC, vagy FB.
Természetesen csak akkor, ha más blokk nem írja azt a bitet.Ne a PLCSIM-ben keresd a hibát, az nagyon jól működik. Bár lehet benne hiba (én találtam is olyat, amikor az SFB4 IEC timer hibásan működik bizonyos PLCSIM verzióban) de sokkal nagyobb a valószínűsége annak, hogy a hibát te követted el valahol.
Ha elküldesz egy programrészletet ami reprodukálja a jelenséget, szívesen megnézem.
Nem lehet hogy keresztbe címzel? Pl. használod az M10.5-ös merker bitet és a programban valahol írod az MB10-et, MW10, MD10, MW9, MD9, MD8, MD7-et? -
KB.Pifu
tag
szia!
Köszönöm a részletes választ, idővel majd ha olyan munkám lesz én is csinálok magamnak univerzálisan használható blokkokat.
De az egész abból indult ki, hogy az itthoni programocskámban nem ment át az egyik FC-ből a másikba a merkerbit állapota és nem találtam rá rendes indokot, deklarálás után működött rendesen.
Lehetséges, hogy a PLCSim hibázik néha? Vagy mindenképpen códban kell keresni a hibát?
-
Szirty
őstag
válasz
KB.Pifu
#4125
üzenetére
Helló Pifu!
A kérdésed nagyon jó! :-)
Nem kell feltétlenül dekrlarálnod, bármelyik FB OB, vagy FC blokkban felhasználhatod bármelyik merkerbitet, byte-ot szót, vagy duplaszót.Az, hogy a programblokkok (FC és FB) paraméterezhetőek egyetlen komoly oka van: az univerzális felhasználhatóság.
Ezt nem feltétlenül kell kihasználni, ez csak egy lehetőség.
Egy berendezésre úgy is lehet programot írni, hogy semmilyen paraméter átadás nem történik.A paraméterezhetőség lényege az, hogy univerzálisan felhasználható blokkot készíthetünk vele. Pl. egy csillag-delta indítást, egy analóg hőmérséklet mérést, vagy bármit.
Ilyen esetben a blokkon belül arra kell törekedni, hogy ne legyen benne közvetlen címzés, a blokk minden információt az IN és INOUT paramétereken keresztül kapjon meg és az OUT és INOUT paramétereken keresztül adjon át a "külvilág" felé.Ha egyedi, nem univerzálisan (máshol is) felhasználható blokk készítése a cél, akkor a blokkon belül címezhető közvetlenül bármilyen merker vagy adatblokk. Ilyenkor rendszerint semmilyen blokk paramétert nem használunk (nincs IN, Out és INOUT sem).
-
KB.Pifu
tag
szia!
Köszönöm a timer-re vonatkozó tanácsot, már látom a lényegét.
De még kérdezek, mert nem világos minden.
Az hogy a merker adatterület globális az világos, de akkor minden esetben mikor két különböző blockban akarom ugyanazt a merkert használni ,definiálnom kell az In, Out, In-out részben?Csak mert én azt hittem mivel globális ezért ezzel nem kell foglalkozni.
-
Szirty
őstag
válasz
KB.Pifu
#4122
üzenetére
Hi!
"Most gondolkodtam, ha az egyik FC-ben írok egy merker bitet, amit egy másikban csak olvasok azt is in-out-ba kell tenni?"
Ha a paramétert a blokk csak írja, akkor OUT legyen. Ha csak olvassa, akkor IN legyen. Ha írja is és olvassa is (tehát fel is használja az állapotát) akkor INOUT legyen.
Hogy ez merker vagy nem merker az részlet kérdés, mivel a blokk belül nem "tudja" (és nem is érdekli) hogy te kívül a hívásnál az adott paraméterének milyen változóterületet adtál meg."A T1-nek egyetlen ciklus erejéig 1 értékűnek kellene lennie"
Az ilyen megoldást a timerrel kerülni kell (most már teis tudod) :-)
Így csináld:
A -(P)- re nincs szükség mert a timer alapból is csak egy ciklus ideig lesz TRUE (legalábbis ebben a megoldásban már igen) :-)
-
Szirty
őstag
válasz
KB.Pifu
#4121
üzenetére
Helló Pifu!
"Eddig azt hittem, elég ha a blokkban adok értéket mondjuk M1.0 -nak és azt a következő blokkban lekérdezem és minden menni fog szépen..."
Ezt teljesen jól hitted, ez így is van. Ezen a hiteden miattunk ne változtass!
Amit írtunk, az lokális változókra vonatozik (blokk interface részében a TEMP változók, alias L terület)
Az M1.0 vagyis a merker terület nem lokális, hanem globális. Azokra teljesen más szabályok vonatkoznak. -
KB.Pifu
tag
Szia!
Most gondolkodtam, ha az egyik FC-ben írok egy merker bitet, amit egy másikban csak olvasok azt is in-out-ba kell tenni?
És a másik kérdés, attól félek hogy nem sikerült maradéktalanul megérteni a program lefutásának a ciklikusságát.
Amit látsz azzal szeretném előállítani trigger jelet, ami lépteti a körasztalt a szimuláláshoz (itt csak a bytokat pakolom, ami a termékek színét jelenti a sorszámának megfelelő jigben.).A T1-nek egyetlen ciklus erejéig 1 értékűnek kellene lennie és a pozitív élfigyeléssel indítani az adatok léptetését a 3-as Network-ben.
De ehelyett nem történik semmi. Valamit nagyon félreértettem? Vagy ez a PLCSim-nek egy elvi határa lenne?
-
KB.Pifu
tag
szia!
Én a mai napig nem futottam bele hasonló hibába, eddig csak különálló egymástól gyakorlatilag független blokkokat írogattam.
Eddig azt hittem, elég ha a blokkban adok értéket mondjuk M1.0 -nak és azt a következő blokkban lekérdezem és minden menni fog szépen...
De legalább ma is tanultam valami!
-
KLR
csendes tag
Kössz a linket. A probléma a 4111 hozzászólásod előtt jelent meg nálam, de ez segített a hiba feltárásában. Előtte nem is gondolkodtam az L memóriaterület felhasználásának módján. Biztos le van írva, meg láttam is, de mivel csak alkalomadtán tudok olvasgatni / tanulgatni, elsiklottam felette. De hát a saját hibáján tanul az ember. Még jó hogy vannak segítőkész emberek, akik irányt mutatnak.
Most már világosabbá vált számomra az FC-ék és FB-ék közötti különbségek és felhasználási lehetőségek.Üdv,
-
Szirty
őstag
Üdv KLR!
Épp pár üzenettel ezelőtt írtam le kiemelve, hogy egy lokális változó értékét egy blokkban SOHA nem szabad azelőtt felhasználni hogy értéket adnánk neki a blokk lefutása előtt! :-)
Igen ha meg kell tartani a tartalmát, akkor lehet úgy is ahogy írod: in/out és kívülről mondod meg neki hova tegye valójában.
Ám ha egy blokkod sok olyan "lokális" változóval dolgozik, amik tartalmát meg kell tartani minden lefutáskor, akkor ott az FB, aminek épp ez a lényege. Olyankor nem TEMP, hanem STAT változót kell használni.Itt találsz erről egy kis infót: Az S7 PLC programozása (2. rész)
-
KLR
csendes tag
És megválaszolva a saját kérdésemet: ha meg kell őriznem az FC/FB egy belső állapotát, ki kell mentenem egy merkerbe (átdefiniálom temp-ről in_out-ra) vagy DB-be, még ha máshol nem is fogom használni.
Hozzá kell szokni ehhez a Siemens logikához.Sok szabadságot ad ez a strukturált felépítés (FC,FB,DB) a direkt cimzéses rendszerekhez képest, de ennek a szabadságnak megvannak a saját veszélyei (legalább is kezdetben)
-
KLR
csendes tag
Sziasztok. A problémám pont a lokális változók témába vág, ezért írom ennek a folytatásába.
Egy kis előtörténet: eddig nem sok szerencsém volt Siemens-hez, de mivel a következő munkát ezzel kell megoldani, beszereztem Step7 Lite + PLCSim, meg az ST-Pro1 anyagát. Neki is fogtam a tanulgatásnak, heti/napi 1-2 órát (amennyi időt tudok szánni rá). Az FC-ket lokális változókkal deklaráltam, az OB1-ben meghíváskor rendeltem hozzá fizikai címeket. Minden működött is szépen, addig még nem írtam még egy FC-ét. Ezután állandóan elejtette az egyik blokban az SR flip-flop értékét. Néztem keresztbe is, meg hosszába, minden OK volt, semmi nem aktiválja az R ágat, de mégis... Pár nap olvasgatás után (fórum, Szirty oldala, stb), megtaláltam a hiba okát. A két FC ugyanazt a temp 0.0 cimet használja, és a második FC törli az értéket. Hogy lehet kivédeni az ilyen hibákat?A lokális változók címét nem tudom megváltoztatni, automatikusan rendeli a program a változókhoz.
-
rsf
senior tag
-
Szirty
őstag
válasz
mcwizard
#4113
üzenetére
Üdv!
Erről a témáról eszembe jut még egy eset, amit szintén kegyetlenül meg lehet szívni ha nem figyelünk oda. De ennél ellentétes a helyzet, vagyis nem az van hogy azt gondoljuk jól működik és nem értjük miért nem, hanem látszólag hülyeséget csinál, mégis jól működik...
Ha lesz kedvem leírom a weblapomon egy írásban. -
Szirty
őstag
válasz
mcwizard
#4113
üzenetére
Üdv mcwizard!
Meggyűlhet.
Meglehetősen misztikus hibajelenségeket produkálhat az ilyen hiba. Pl. ha az a bit egy másik blokkban (ami így, hibásan kezeli a temp változóterületet) éppen egy előírt érték dint-jének a közepére esik.
Nem mindegy ám, hogy egy szervóhajtást 23430-ra vagy a 4217734 pozícióra küldi a program.
Vagy hogy a kemencét 699 fokra fűti vagy tol neki néha egy 2747-et.... -
-
Szirty
őstag
válasz
mcwizard
#4110
üzenetére
Üdv mcwizard!
A lokális változók a hívás végén nem törlődnek. A rendszer nem törli őket szándékosan. Ám a tartalmukat nem szabad figyelembe venni a blokkon belül azelőtt, hogy értéket adtunk volna neki.
Az ok rendkívül egyszerű: A lokális változók tartalmát más blokkok lokális változói felülírhatják ha használnak lokális változót illetve ha írják azokat. Így minden blokkban minden lokális változó tartalma lényegében határozatlan, memória szemét van benne. Egyszerűen azért, mert minden blokk ugyanazt a stack-et (memória területet) használja a saját lokális változói tárolására.
Ezért ha csak egyetlen egy blokkod van ami ír egy lokális változót, de a többi blokkban is létrehozol változókat amik így ugyanarra a címre kerülnek, ám azokat nem írod csak olvasod, akkor azt fogod tapasztalni hogy amikor az író blokk megváltoztatja a lokális változó értékét, akkor az a többi blokkban is megváltozik. Illetve az író blokk elején is az az érték van benne amit utoljára beleír.
Ha azonban nem "steril", hanem olyan programban vizsgálnád meg ugyanezt a jelenséget ahol különböző blokkok különböző célra intenzíven használnak különböző belső változókat a saját céljukra (a gyakorlatban minden program ilyen lényegében) akkor gyökeresen mást tapasztalnál.
Ha tehát arra hagyatkozol amit most tapasztaltál, annak vége igen nagy szívás lehet. Ezért nagyon fontos szabály, hogy egy blokkban lokális változót SOHA nem használunk fel azelőtt a blokk lefutásán belül, hogy annak értéket adtunk volna!
-
mcwizard
tag
Sziasztok!
Siemens S7-ben lenne egy kérésem a lokásis változókkal kapcsolatban.
A képen lévő program mindösszesen annyiból áll, hogy ha az FC1 NW3-ban, az M56.0-t 1-be billentem, akkor a "temp_0" lokális változó is 1 lesz.
A problémám az, hogy én úgy tudtam, hogy a lokális változók az FC hívás végén tölődnek. Viszont nekem látható, hogy az FC1 NW1-ben még írás előtt 1-ben maradt a "temp_0", sőt az FC2-ben is 1-be billen a"temp" változó amint az M56.0-t aktiválom.Most csak én értem félre a lokálsi változók működését, vagy ez tényleg nem rendeltetés szerű működés?
Köszönöm a válaszokat előre is.Üdv, mcwizard!
-
Szirty
őstag
válasz
KB.Pifu
#4107
üzenetére
Szevasz Pifu!
Csinálhatod úgy is, hogy lerajzolod háromszor és mindegyiknek a láthatóságát kapcsolgatod egy bittel de az nem túl szép megoldás.
Ha sok ilyen van egy screenen az körülményessé teheti a szerkesztését. Állandóan kotorászni kell az egymásra helyezett, a szerkesztőben egymást kitakaró objektumok között. vagy ha mindegyiket külön layer-re teszed az könnyíthet a helyzeten, de akkor meg a layereket kell kapcsolgatni ha módosítani kell rajtuk.Amennyiben a szimbólumod grafikus primitívekkel rajzoltad (kör, vonal, négyzet, stb) akkor én az animation / appearance segítségével oldanám meg a dolgot.
Csináltam erre egy példa projectet. Két lehetőséged van:Egy integer változó (a példában ez MW10) van hozzárendelve egy szürke hátterű és fekete keretű téglalap animation / appearance tulajdonságánál. Az integer egyes értékeihez eltérő háttérszíneket rendeltem hozzá.
Amikor az MW10 tartalma 1, akkor a téglalap színe piros lesz, ha 2 akkor narancssárga, ha 3 akkor citromsárga, ha négy akkor zöld. Minden más érték esetén a téglalap eredeti, tehát szürke színű lesz.
Itt tehát az MW10 integerbe kell a PLC programban különböző értékeket írkálni a szín megváltoztatásához.A másik lehetőség a bitenkénti színváltás (binary appearance).
Egy byte változó van létrehozva ami az MB12 merker byte-ra hivatkozik. Az animation / appearance itt binary-re van állítva ahogy a képen is látható. Ilyenkor a színek nem a változó értékéhez, hanem annak bitjeihez rendelődnek hozzá a következőképpen:
Ha az M12.1 TRUE, akkor a téglalap piros lesz, Ha M12.2 TRUE, akkor narancssárga, ha M12.3 akkor citromsárga, ha M12.4, akkor zöld.
Ennél a megoldásnál arra kell figyelni, hogy ha a megadott bitek közül nem csak egy TRUE, hanem több is, vagy a byte olyan bitje TRUE, ami nincs felsorolva, akkor a téglalap eredeti (azaz szürke) színű marad!
Amennyiben a megjelenített szimbólumod előre megrajzolt grafika, akkor is megoldható a dolog, de teljesen máshogy. Ennek a leírásától most eltekintenék, mert túl hosszú lenne ez az üzenet...
-
KB.Pifu
tag
sziasztok!
Itthon, "játékból" írogatok programkódokat és szeretnék valami "látványos" szimulációt készíteni, WinCC Flexible-lel!
Amit kitaláltam, ami az alap, hogy egy 6 állomásos körasztal lesz animálva, zöld, piros (OK, NG) termékekkel.
Ezzel nem is volna gond, egy merker el tudja dönteni
De hogy kellene megcsinálni, hogy az üres jig, mondjuk szürke legyen? mert ez ugye már 3 állapot és két merker bit kell hozzá.WinCC-ben ez hogy nézne ki? Egymás fölé kellene tenni más layerben a kettőt?
Amit akarok csinálni, mondjuk megy a körasztal, lenne kijáratás, kézi üzemmód (egy állomáson), meg ami szerintem jó ötlet a "véletlenszám" generátoromat tudnám használni,selejtgenerálásra, stb stb.
Egyrészt mert érdekel a dolog, másrészt szeretnék már valami bemutatható dolgot is elvinni állásinterjúra.
üdv
Pifu -
DP_Joci
tag
Biztos, hogy a Tia Portal-os PID tud +-100%-ban adni kimenetet? Ja és S7-1200 –ra gondoltam a megvalósítást illetően.
Valószínűleg úgy lesz, hogy 0% kimenethez tartozik a minimum fordulat 100%-hoz a max és majd a különböző anyagoknál ezek az, értékek változtathatók lesznek. Vagy mivel valószínűleg csinálok egy olyan opciót, hogy a szabályozást ki lehet kapcsolni és az így meghatározott fordulathoz kalkulálom a min és max fordulatszámokat, ha a szabályozás bekapcsolják.
üdv. -
moseras
tag
válasz
DP_Joci
#4102
üzenetére
Üdv!
Van ugye egy alapjeled, hogy mekkora legyen a rés szélessége. Ez valahonnan jön: vagy felhasználó által beállított, vagy valamitől függő. Tehát értéktartó, vagy valamit követő formában van jelen.
Aztán van a mért értéked, hogy konkrétan mennyi a rés szélessége. A PID-re ráadod az alapjelet, és a mért értéket, és a PID kimenete változni tud +/- irányba, és ez már tudja változtatni a motor fordulatszámát +/- irányba.
Tegyük fel, hogy a rés kívánt szélessége X, a PID 0-ról elkezdett növekedni, és mondjuk 45% PID kimenet (tegyük fel, hogy a PID kimenete 0-100% tartományban mozog) olyan fordulatszámot eredményezett, amely épp tudja tartani X-et. Ha ezután X-t megnöveled, akkot a PID utánamegy, és megnövekszik a fordulatszám is, ha X-t csökkented, akkor is a PID is csökken, és a fordulatszám is csökken. Tehát a PID mindkét irányba tudja a fordulatszámot változtatni.
Szerintem felesleges trükközni, a PID megfelel erre a célra, persze be kell hangolni, és figyelni kell néhány dologra, pl. hogy van e mondjuk egy minimális fordulatszám, vagy maximális fordulatszám, ami alá/fölé nem mehet.
Imi.
-
DP_Joci
tag
válasz
moseras
#4101
üzenetére
Szia Imi,
Első gondolatom nekem is ez volt, de +- irányba is kéne szabályozni a fordulatszámot.
Pontosan a PID 3 step-re gondoltam, de az csak digitálisan „kapcsolgat” előre hátra (nem biztos, annyira nem ismerem).
Lehet, hogy meg lehet oldani pid-del is, erre kéne ötlet. (2 pid használata?)
Utána volt olyan ötletem is, hogy ha eltérés van a résméretében, akkor időnként pl. 0,5-1-2 másodpercenként (ez lehetne állítható panelról) növelném vagy csökkenteném a fordulatszámot 1-2 Hz-ként pl. +- 10Hz –es tartományban.
üdv.
Új hozzászólás Aktív témák
Hirdetés
- Lenovo ThinkPad P1 Gen 3 UHD, Érintőkijelző, i7-10875H, 32GB DDR4, 256GB SSD, 27% ÁFÁS SZÁMLA, 1ÉV G
- Lenovo ThinkPad L490 FHD, TOUCH, I5-8365U CPU, 16GB DDR4, 256GB SSD, 27% ÁFÁS SZÁMLA, 1ÉV GARANCIA!
- Lenovo ThinkPad T490 FHD, I5-8365U CPU, 16GB DDR4, 256GB SSD, 27% ÁFÁS SZÁMLA, 1ÉV GARANCIA!
- 2020 M1 macbook pro 8/256GB elado/cserelheto
- Lenovo ThinkPad T480s FHD, Érintőkijelző, I5-8350U CPU, 8GB DDR4, 256GB SSD, 27% ÁFÁS SZÁMLA, 1ÉV GA
- billentyűzetek - kiárusítás - Logitech, Corsair, ASUS
- ÚJ Lenovo ThinkPad X13 Gen 5 - 13.3" WUXGA IPS - Ultra 5 135U - 16GB - 512GB - Win11 - 2,5 év gari
- Fujitsu LIFEBOOK E449 i5-8130U 8GB 256GB 14" FHD 1 év garancia
- Sima Vs.Windows Logitech Mx keys s plus és hagyományos Mx keys magyar bemutatása. Új videó linkel
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB DDR5 RTX 5060 Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: FOTC
Város: Budapest