Hirdetés
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Egyre nagyobb a balhé a Helldivers II körül
gp Úgy tűnik, hogy egyre több sötét felhő kezd gyűlni a játék körül a Sony döntése miatt.
-
Mindent megtudtunk az új Nokia 3210-ről
ma Részletes képek, specifikációk és euróban megadott ár is van a legendás modell újraélesztett verziójához.
Új hozzászólás Aktív témák
-
Szirty
őstag
válasz
isvarga
#2800
üzenetére
Helló István!
"Úgy emlékszem 1-100ms között írta az értéket ,csak akkor ezek szerint állítható )
Talán akkor ez a legnagyobb különbség a 2 megközelítésben.(bár számomra ez mosolyogtató érték)"1-100ms nem vicces, hanem egy rendkívül jó gyakorlati érték.
Te a mikrovezérlők irányából jösz és furcsa, mert ott nano meg mikroszekundumok vannak.
Nálunk 20ms ciklus idővel közepes teljesítményű S7 PLC-vel teljes gyártósor üzemel.
Rajta profibuszon: 27 pozícionáló szervóhajtás, két Fanuc robot, 10 decentralizált frekvenciaváltó, 5 további frekvenciaváltó.
Ugyanezen a PLC-n profineten egy Cognex alakzat felismerő kamera és egy operátor panel.
Ugyanezen a PLC-n egy Interbus interfész, amin 800 db digitális I/O pont dolgozik.
A PLC ethernet hálózaton kapcsolatban áll több más PLC-vel (a gyártás más gyártósorait vezérlik) és Oracle szerverrel, ami a termékkövetést intézi.
Ilyen egy közepes testhez álló feladat egy PLC számára ipari környezetben.
Tehát buszos eszközök százai, szervók, hajtások, (buszos mind) lézeres távoslág mérők, nyomás távadók, szintmérők, mérleg modulok, stb, stb, stb..."3 fórumot találtam ahol foglalkoznak a témával (2 aktív) ,végig olvastam a beszélgetéseket ."
Az általam ismert és aktív PLC-s fórumok az alábbiak:
Hobby Elektronika
Ez a fórum
PLC fórum
És PLC levelező lista"Egy plc használata semmivel sem egyszerűbb ,mint mondjuk a mikró számítógépek. Az egyetlen előnyét abban tudnám megfogalmazni ,hogy "konyhakész" termékek ,és ha az én céljaimra megfeleltek volna biztos abba az irányba indulok."
A PLC-k célorientált, a feladatra specializált eszközök annak megfelelő programozási lehetőségekkel és tudással. Ennélfogva ilyen feladatra nagyon hatékonyak (az általános célúaknál hatékonyabbak)."Az én véleményem szerint a megfelelő eszközt a megfelelő munkára ."
A legnagyobb mértékben egyetértek
[ Szerkesztve ]
-
isvarga
csendes tag
Szia !
Azért a közepes mennyiségű perifériákhoz írnék néhány sort.
Robotok - szinte mind tanítható vezérlés alapján működik - a PLC maxi azt tudhatja mi a státusza
Szervók - amiket én ismerek mind rendelkezik alapvető 1-bemenetes mozgási parancsokkal, ha nem így működik akkor van neki fölérendelt mozgásvezérlője. a PLC itt is csak tájékozódási paraméterekkel működik.
Frekiváltók - Legtöbbjük sokkal több funkcióra képes ,mint amit az elnevezése mond . Itt elképzelhetőnek tartom ,hogy a bekapcsoláson kívül tud a PLC fordulatszámot változtatni .
A többi a saját menüjében van.
Alakzat felismerő kamera - a PLC - vel való kapcsolata kimerül abban ,hogy jelentenek egymásnak.
I-O lábak - robotok , tengelyvezérlők ,tanítható motorvezérlők mind gondoskodnak a saját bemeneteikről ,ezt nem írnám a PLC csúcsteljesítményéhez.
Ethernet - A PLC-nek külön perifériája van erre a feladatra (mint a pic-nek az ENC28J60 ,idáig nem akartam ezzel foglalkozni ,de olyan egyszerű ,hogy vétek lenne kihagyni , és a legjobb kommunikációs forma. Már emiatt is érdemes volt "idetévednem")Tehát a PLC adatgyűjtő ,ellenőrző , informatikai folyamatokat végez . A részfeladatokat rábízza az alegységekre.
Itt jön be a képbe az én kicsikém. Ha például szeretnék 1db léptető motort paraméterezhető módon Működtetni PLC-vel , akkor kell :
1db PLC
1db arra alkalmas motormeghajtóez 2x
1db PLC-HMI
1db normál motormeghajtóez 3x annyiba kerül mintha vennék
1db PLCminit-kijelzővel
1db normál motormeghajtót
és ez 2db tengelyt tud ,úgy ,hogy nem csak lépteti ,hanem a tengelyek pozícióit is ismeri.
A PLC verzióban nincs gyorsulás -sem számolt lassulás ,tehát egy sokkal lassabb ,rugalmatlanabb eszközt kapok.
A pozíció szervón ezeket a paramétereket ,előre be lehet állítani ,(máshogy is megy de ne bonyolódjunk bele) de nem minden hajtásnál csinálja jól.Tehát önmaga képes 1 ilyen rendszert alkotni .
Egy kis videó 1 egyszerű alkalmazás bemutatására.(ez egy sorozat stancoló gép imitáció - gravírozó gépből alakítva)[link]Varga István
-
Szirty
őstag
válasz
isvarga
#2802
üzenetére
Hali isvarga!
Látom a válaszodból, hogy nem igazán fogadod el amit írtam.
Én terepi buszos szorvókat említettem, nem egy bemenete van, amivel megmondod hogy A vagy B pontba menjen, hanem profibuszos kapcsolat van és sok száz bit a szervó és a PLC közötti kommunikáció.
Aktuális pozíció, aktuáli ssebesség, felfutó rámpa, lefutó rámpa, előírt sebesség, paraméter készlet, státus szó (32 bit) vezérlő szó (32 bit) üzemmód, célpozíció, stb, stb, stb. Ez szorozva annyival, amennyi szervóhajtás van a rendszerben.Az említett (példaként hivatkozott, valóságban is működő) rendszer PLC programja százezer sor (az adat struktúra definíciók és adatblokkok tartalma nélkül, csak a program kód). Ezzel próbáltam szemléltetni egy közepes bonyolultságú PLC vezérlésű alkalmazást.
Sajnálom ha nem sikerült."A PLC verzióban nincs gyorsulás -sem számolt lassulás ,tehát egy sokkal lassabb ,rugalmatlanabb eszközt kapok."
Tévedés! A lényeg ennek éppen az ellenkezője.
Meg kellene nézed és meg is ismerned egy ilyen rendszert ahhoz, hogy korrekt véleményed lehessen róla.
[ Szerkesztve ]
-
isvarga
csendes tag
Szia!
Nekem a közepes méretű példádról az jutott eszembe ,hogy van aki például a megapixel alapján dönti el melyik telefont vegye.
Alapvetően félrevezető ezt a sok perifériát a PLC csúcsteljesítményének betudni.
Attól ,hogy kommunikál vele , attól még az alegységek végzik a melót.""A PLC verzióban nincs gyorsulás -sem számolt lassulás ,tehát egy sokkal lassabb ,rugalmatlanabb eszközt kapok."
Tévedés! A lényeg ennek éppen az ellenkezője."
A példa csak egy alapvető problémának a bemutatása a "közepes méretű" PLC rendszerhez nincs köze. (aki ismeri a léptetőmotor vezérlőket az tudja miről van szó)
Én a kommersz árkategóriában mozgok , mert nekem itt kell megoldást mutatnom.
Az itt található eszközöket használják leginkább.20-éves koromban dolgoztam egy nagyon nagy üzemben , mint gépkezelő . Mindenből az akkori legjobb volt beépítve ,de ha elakadt a palack a függő úton (4m magasba kb) akkor a dolgozó térítette jobb belátásra egy hosszú csővel , tudom csapkodtam én is eleget . Közben művelődtem is ,egy nagy led panelre kiírt ,a teljesítmény fokozására buzdító mondatok olvasásával. Micsoda csúcsteljesítmény !
Varga István
-
Szirty
őstag
válasz
isvarga
#2804
üzenetére
Helló István!
Reméltem hogy nem lesz rá szükség, de akkor az egyértelműség kedvéért leírom mi volt a célom a példával és mi nem.
Nem volt célom vele a PLC népszerűsítése, az eredményeid lekicsinylése és nem volt célom magamat dicsőíteni sem. Igyekeztem úgy fogalmazni, hogy ez a vád ne merüljön fel, és azt hiszen nem is merült fel.Egyszerűen csak leírtam címszavakban egy közepes méretű (bonyolultságú) PLC-s vezérlés műszaki tartalmát, hogy világos legyen mire használnak az iparban PLC-t.
Azért, mert korábbi üzenetekben tettél néhány olyan kijelentést, amiből arra következtettem, hogy nem ismersz ilyen rendszereket kellő mélységben ahhoz, hogy tárgyilagosan nyilatkozz róluk.
Nem volt bántó szándék sem mögötte."(aki ismeri a léptetőmotor vezérlőket az tudja miről van szó)"
Használtam már léptetőmotort PLC-s rendszerben. Külön vezérlő van hozzá (FM353 volt).
Nem hinném hogy ettől rugalmatlanabb lassabb lenne. Különösképpen azért sem, mert ennek a megoldásnak pontosan az a lényege, hogy a lehető legrugalmasabb és legsokoldalúbb legyen, de az alkalmazhatóságát ez ne rontsa. (nem egyszerű ezt megvalósítani, a két dolog hatása ugyanis éppen ellentétes egymással). -
byte-by
tag
válasz
isvarga
#2804
üzenetére
halo!
látom a pro-kontra érveket.
A PLC alapvetően a relés kapcsolási rendszerek kiváltására jött létre, de magában hordozta a sokkal bővebb lehetőségeket.a kezdetektől nagyon sokat fejlődött.
Én magam Szirty-vel ellentétben inkább OMRON-ban vagyok járatos(abb), bár kérdeztem már tőle egy-két dolgot.
a fejlett PLC vezérlések azon az igazságon túl, hogy ellenőriz és felügyel nagyon komoly potenciálokkal rendelkezik.
az én meglátásom szerint sokszor rosszul választják a PLC típusait a megoldandó feladatokhoz, mivel sokszor a választott vezérlő sokkal, de sokkal többet tud , mint amire szükség van.
az Általad ,előző bejegyzésben megjelölt tevékenységekhez valóban elég bitekkel kommunikáló digitális ki-és bemenetek.
de, mi is használunk olyan ID rendszereket , strukturált text formában megírt funkció blokkokat amelyeket a PLC minden ciklusban újra és újra comparál és kiértékel, azon kívül, hogy tengelyeket vezérel, és kommunikál más eszközökkel, folyamatosan változó (és változtatható) paramétereket használ a felhasználó igénye szerint, szabályoz,stb.
nem mondanám a PLC-re , hogy rugalmatlan.
egy gép-gépsor teljes átépítése, fejlesztése, módosítása, állomásokkal, vezérlőkkel, hajtásokkal való bővítése, új termékek, új paraméterek bevezetése esetén tapasztalható a PLC rugalmassága.ebben az esetben egy jól átlátható, logikus fejlesztő környezet nagyon fontos szerepet játszik.
a termelési és/vagy tervező mérnökök fantáziája végtelen.mi is használunk microvezérlőket, de csak állomások fix szegmenseinél.
ár-teljesítmény arányuk igazolja használatukat.viszont a felhasználó igénye által ,tetszés szerint (program szerint behatárolható) változtatható paraméterekkel rendelkező, a változtatásokat azonnal aktualizáló (és felügyelő) , komplex rendszerek esetén PLC-t használunk.
az Általad leírt vicces "vascsővel" javított probléma pedig leginkább tervezési probléma, és módosításokkal megoldható lett volna.(egy tejfeldolgozó üzemben rugdosással orvosoltak egy hasonló problémát, de mondtuk, hogy inkább szóljanak, mert van megoldás, csak időt kell szánni rá, és utána nem kell többet rugdosni , ami mindenkinek jó.)
ha valaki időt és energiát fektet bele, a PLC azt is "elárulja" mi a hiba, hol a probléma, sőt , mit kell tenni, vagy csak megteszi amit kell.csak program kérdése.
nem tudom a micro-val ez megtehető-e.annyit még hozzá tennék, amit egy régi PLC-s kolléga mondott, és amivel tökéletesen egyetértek:
"soha nem a gép a hülye"
ha a CPU-n kívüli eszközök rendben vannak,pontosan azt teszi amire a programozó utasítja.byte-by
-
Szirty
őstag
válasz
byte-by
#2806
üzenetére
Hali!
"ha valaki időt és energiát fektet bele, a PLC azt is "elárulja" mi a hiba, hol a probléma, sőt , mit kell tenni, vagy csak megteszi amit kell.csak program kérdése.
nem tudom a micro-val ez megtehető-e."Sajnos nem jutott eszembe megemlíteni a fejlesztői környezet és a diagnosztizálhatóság (hibakeresés) fontosságát. Szerencsére Te megtetted.
István!
Ennek hiánya mérhetetlenül aláássa a rugalmasságot és a hatékonyságot.
Pl. futásközben a vezérelt gép működése közben módosítható program, a belső állapotok, változók, memóriatartalmak megfigyelhetősége működés közben olyan tulajdonságok, amik fontosak egy PLC-ben.
Nem tudom ilyesmi mennyire lenne megvalósítható egy PIC-es vezérlésben... -
isvarga
csendes tag
válasz
byte-by
#2806
üzenetére
Szia !
Egyetértek abban amit a rugalmasságról írsz . Egy ilyen méretű alkalmazásnál tényleg erre van szükség , és úgy ahogy leírtad . A legtöbb alkalmazásomban nekem is szét kell darabolnom a feladatot ,hogy megvalósítható legyen .Ez teljesen velejárója a méretnövekedésnek . A részfeladatokra bontva sokkal könnyebben lehet variálni is .
A paramétereket a program futásától függően lehetséges változtatni , de az igazi megoldás az ha ezt is külön alkalmazásba tesszük .(pic)
A futtatás közbeni program módosításnak pic-ben sincsen akadálya ,hiszen így működnek a bootloaderek is.(azért a tempóból vissza kell venni)
A fejlesztői környezet átláthatósága fontos szerintem is.(bár szokás kérdése is)A
"ha valaki időt és energiát fektet bele, a PLC azt is "elárulja" mi a hiba, hol a probléma, sőt , mit kell tenni, vagy csak megteszi amit kell.csak program kérdése."
mondatot amikor elolvastam az jutott eszembe " Ilyet eddig csak sci-fi -be láttam". (nem gúnyolódásképpen írtam , csak ez jutott eszembe) . Csak remélni merem ,hogy ezek után kifejted bővebben is ,mert nagyon érdekelne a dolog.
A saját fejlesztésemnek azért mertem PLC nevet adni mert (biztos nem százas) alapvetően képes ezekre a rugalmasságra .
A nyelvet meg lehet csinálni rajzos változatra is .(a logikai leíró részek még hiányoznak a nyelvből -nem éreztem fontosnak - és megoldható máshogy)Az egész úgy kezdődött ,hogy egy készülékhez kellett programot csinálnom ,de úgy ,hogy egyszerűen változtatható legyen az igények szerint. (a program átvevőjének meg kellett tanítanom a működését is . Elmondása szerint a C-64nél programozott utoljára ,ezt a nyelvet fél óra alatt megértette)
Gyakorlatilag az egész az MPASM -ra épül .(keresztassembler)
Megfejelve azokkal a megoldásokkal ami az évek során rám ragadt.A csöves eset csak példa arra ,hogy a teljesítmény önmagába nem elég.....
Varga István
-
isvarga
csendes tag
Szia !
A fentebb említett mondaton kívül azt mondanám ,hogy igen .
Persze lehet ,mást értek diagnosztika alatt.
Alapvető kimenet-bemenet teszteléssel , program teszteléssel (a plc program lépésenkénti végrehajtása) már most is bír .(mármint készüléken)
Ha pedig az MPLAB diagnosztikai rendszerét nézem magasan túl is szárnyalja azokat. az elvárásokat amit említettél. Hibakereső - vagy szimulációs módban is.
(figyelni kell a programozónk paramétereire )Varga István
-
Szirty
őstag
válasz
isvarga
#2808
üzenetére
Üdv István!
"Csak remélni merem ,hogy ezek után kifejted bővebben is ,mert nagyon érdekelne a dolog."
Én ezt már kifejtettem, szerintem ilyesmire gondolt:
Gyakorlati tanácsok gépek programozáshoz és tervezéshez
A hibakezelő OB-k
Hibakezelés: az OB86 (Rack Failure) -
Szirty
őstag
válasz
isvarga
#2809
üzenetére
Üdv istván!
Mivel egyre egyértelműbb, hogy álláspontjaink ennél jobban már nem fognak közeledni egymáshoz, összefoglalom a magam részéről a témát:
A mikrovezérlőnek és a PLC-nek is megvan a maga létjogosultsága (én az utóbbira próbáltam rávilágítani, de az előbbivel is tisztában vagyok).
Mind a kettő hatékony a maga területén.
Ahova jó választás egy mikrovezérlő, oda botorság PLC-t rakni, ám egy mikrovezérlőt PLC-s feladatra használni semmivel sem kevésbé ostobaság.
Ugyanakkor tudom, hogy a két terület között a határ nem penge éles, van átfedés. De ha mindkét terület közepéből veszünk mintát (nem véletlenül emlegettem közepes PLC feladatot végig) akkor teljesen egyértelmű, hogy nagy különbség van a kétféle megoldás szintje között (és itt nem minőségi szintről van szó).Ha te olyan eszközt akarsz építeni, ami minden tekintetben (HW és szoftveres szempontból egyaránt) megfelel olyan feladatoknak amire a PLC, akkor te egy ugyanolyan PLC-t fogsz építeni, ami ellen jelen pillanatban tiltakozol. (talán jó példa erre az Unitronics)
Miért? Mert az évek során a fejlesztések abba az irányba vittek és jelenleg általánosságban az a megoldás a leghatékonyabb ipari folyamatok irányítására. A vitát megelőzve, amit ebben a mondatomban sejtek sietve kijelentem, hogy: nem azt írtam, hogy mással lehetetlen megoldani!Valószínűleg egyedül otthon NYÁK-olgatva nincs esélyed utolérni a fejlesztésben olyan gyártókat, akik évtizedekig, sok tagú mérnök csapattal a háttérben dollármilliókért fejlesztették ki mai PLC-iket. Bár látom, hogy igazából nem is ez a cél (igaz amit írsz az nem mindig van összhangban azzal amit látok, vagy én értek félre néha valamit)...
-
-
isvarga
csendes tag
Alapvetően szerintem nincsenek messze az álláspontjaink .
Alapvetően a hiány pótlására készült a fejlesztés .
Nem áll szándékomban másolni továbbra sem ,bár sok mindent ugyanúgy alkalmazok.
A 100miliós fejlesztési összegekre , sok száz mérnök munkájára , viszont csak "mennyiségi gigantománia" jelzőt tudok használni.)"Valószínűleg egyedül otthon NYÁK-olgatva.........."
Nem egyedül fejlesztek ,nem is értek az elektroninához. (annyira nem,hogy egy ilyet meg tudjak csinálni)
A nyákokat is csináltatom olyan helyeken ahol a többiek ......(600 furat egy 75x100-as nyákon)
A fejlesztés összege ,legnagyobb részben a munkabérek és azok járulékaiból áll.
Mellettem olyan "emberek" állnak akik nem elégednek már meg ,a menüből választható fogásokkal.(ingyen dolgozunk, szinte főállásban)
Kínosan ügyelek arra ,hogy csak a valós műszaki tartalmat állítsak.
Maximálisan figyelek az elvégzett munka minőségére is ,és itt a szellemi részére gondolok most.
Nem véletlen ,hogy 1 éve csak tesztelek .
Most a dizájn legjava is bevetésre fog kerülni ,ha minden igaz .
Rozsdamentes dobozolás ,fém gombokkal (több verzió) ilyen nem jön "csájnából).De ami a legfontosabb hiszünk benne ......
Varga István
-
vopi86
csendes tag
Sziasztok!
Régebben kértem Tőletek segítséget Omron témában.. mindenre választ kaptam, amit utólag is köszönök...
Most Siemens S1200-as PLC-vel és HMI-vel lenne egy kis feladat...
Ezekből az eszközökből állna a rendszerünk:
1db POWER SUPPLY S7-1200 PM1207
1db CPU 1214C 14DI/ 10DO/2AI
3db DIGITAL INPUT SM1221, 16DI, 24V DC
1db DIGITAL OUTPUT SM1222, 16 DO, 24V DC
1db DIGITAL OUTPUT SM1222, 16 DO, RELAY
1db ANALOG INPUT SM1231, 4AI
1db COMPACT SWITCH MODUL CSM 1277
1db SIMATIC KTP400 BASIC MONO PNTehát ebbe benne van a HMI, A PLC és a bövítőmodulok is.
Szoftvernek a TIA Portal 11-et kaptam.Az lenne a kérdésem, hogy hogyan tudom feléleszteni ezt a rendszert,
miután fikiailag össze lett szerelve minden, ethernet kábellel rácsatlakozok
a switchre és elindítom a TIA Portált... Innentől szeretnék egy kis segítséget..
Köszi előre is!
Üdv.
vopi
-
Szirty
őstag
válasz
isvarga
#2812
üzenetére
Hali!
"Az én fejemmel ennek semmi köze nincs a programozáshoz (fölkészülni minden eshetőségre)"
Ilyen hibakezelésekből szokott állni nem kevés program jelentős része! Amelyikben ilyen egyáltalán nincs, az régen rossz.
Sok-sok óra fejlesztés megy rá ilyesmire.
Ha egy berendezés hibás működési állapotainak program által történő felismerésének megvalósítása nem programozás, akkor nem tudom mi. (Bár itt mi is inkább favágásnak hívjuk).
De ha szigorúan vesszük a programozás az én értelmezésem szerint valamilyen programnyelven program írása (utasítások egymásután helyezése, ami egy adott algoritmus megvalósítását célozza).
A hibás állapotok észlelése, kezelése, üzenetek megjelenítése is ezen a "programozás"-nak nevezett tevékenység által valósul meg.A paraméter állításokat programozásnak nevező megrendelő esete nem tudom hogy kapcsolódik a témához (így nem tudom példaként vagy ellenpéldaként értelmezni)
-
byte-by
tag
válasz
isvarga
#2814
üzenetére
Üdvölet !
"A
"ha valaki időt és energiát fektet bele, a PLC azt is "elárulja" mi a hiba, hol a probléma, sőt , mit kell tenni, vagy csak megteszi amit kell.csak program kérdése."
mondatot amikor elolvastam az jutott eszembe " Ilyet eddig csak sci-fi -be láttam". (nem gúnyolódásképpen írtam , csak ez jutott eszembe) . Csak remélni merem ,hogy ezek után kifejted bővebben is ,mert nagyon érdekelne a dolog. "
nos, a sci-fi elkezdődött amikor Walter Brattain úr 1947-ben összerakott egy tranzisztort.
Nobel díjat érdemelt.egyébként Szirty leírt pár detektálható, dokumentálható, követhető diagnosztikai lehetőséget.
a sci-fi-hez visszatérve ,azt hiszem Luke Skywalker tökön csókolta volna magát , ha R2-D2-ban lett volna OB121.
na,de.egy ki lazulás.
egy raklap egyszerű példa.
betonkeverő. nem az otthoni , amivel járdát csinálunk a nyári konyhától a budiig, hanem sok köbméteres pontos recept szerint dolgozó komplex rendszer.90-es évek.még azt hittük, hogy a gyomorfekélyt a stressz okozza.
szóval keveri a betont, méricskéli az összetevőket, bla-bla, de a cement nem jön.
zárt rendszer , látni semmit.adagolóban bőven.kezelő a szemközti kocsmában.
mi legyen.a legjobb az egészben, hogy lecserélték a relé-mágneskapcsoló rendszert PLC-re.
nem kell tenni semmit.
fizika óráról tudjuk, hogy a tapadási-surlódási erők változásai képesek akár a finom cement szemeket egymáshoz kötni és szépen egy tölcsér oldalához tapasztani.
a vezérlő , a megfelelő szenzorokkal, leellenőrzi a komponensek útját.innen jön,onnan jön. amonnan nem jön.ezt archiválja, vagyis "elárulja" a problémát.(de nem az okát) egy NT szériás HMI-n.
A kezelő bácsi iszik még egy sört.
A vezérlő a cement ágat külön leellenőrzi.anyag? van.motor?rendben.csiga? átjön a cucc.töltőcső?nem jön.aha.(itt "mondaná" meg, a HMI-n, hol kéne megnézni a rendszert)
ezt régen úgy oldották meg, hogy egy marha nagy kalapáccsal oldalba ütötték a töltőcsövet , ezáltal lazítottak a cementszemeken amik szépen lezúdultak a csőben.(itt "javasolná" ,a HMI-n,mit kéne csinálni.)
a bevált dolgokon ne változtassunk,kalapács helyett egy ipari vibrációs eszköz is megteszi.(itt "tette meg" amit kellett.)
a cucc megindult és a keverés továbbment.
a kezelő a harmadik sör után visszajött , a szállító megtelt , az élet megy tovább.
persze azért csodálkozik, miket írogat a HMI, és szépen kitörli a listázott hiba üzeneteket.szóval valami ilyesmi.persze a dolog ennél sokkal bonyolultabb,de a végén ilyesmi történik.
egy folyamat minden lépését le lehet ellenőrizni, detektálni, megfigyelni, javaslatot adni és szükség esetén, ha igény és kiépített lehetőség van rá , beavatkozni.
mint, mondtam csak program kérdése, ha valaki időt és energiát fektet bele.ez minden automatizáció alapja: az embert ki kell zárni.
ő a leggyengébb láncszem.gondolom ez még a PIC vezérlők világában is igaz.
byte-by
-
isvarga
csendes tag
válasz
byte-by
#2818
üzenetére
Szia !
Egyébként az űrszekerekre gondoltam , a kapitány belebeszél a levegőbe, a számítógép meg megmondja hány éves a buszvezető .Egyébként továbbra is azt állítom ,hogy az adott területen szerzett tapasztalat a legfontosabb egy gép működtető programnál. Ha nem tudom hova kell rakni a szenzort akkor a vezérlő sem tudja .(ugye itt alapvetően a bemenetek-kimenetek kezeléséről van szó csupán) Olyan ez mint amikor a HMI megszólítja Janit , "már megint sörözni voltál te tróger " a HMI -nek dunsztja sincs mit ír ki ,csak aki ezt megcsinálta.
Egyébként a láttam olyan PLC leírást ahol 1:1 assembly utasítások is voltak a parancsok között .Ha egy szóba kellene kifejeznem a 2 rendszer közti elvi különbséget ,akkor a "semmi" a legjobb kifejezés.(az OB hibakódok megvizsgálása után)
(persze vannak dolgok amiket én nem használok a saját fejlesztésemben ilyen ,olyan okok miatt)Az ,hogy kitaláltak maguknak saját elnevezéseket , kommunikációt , csak a saját piac védelme miatt van .
Ha beleegyeztek továbblépnék.
Van ez a profibus kommunikáció : (idáig én csak rs485-nek ismertem aztán modbusnak) , de ebből találtam 3 félét is.
Ha írnátok néhány sort róla ,azt megköszönném.●POFIBUS-FMS (Fieldbus Message Specification)
● RS485 vagy száloptika
● a DP előfutára
● Kommunikáció cella szinten (PLC - PC)●PROFIBUS-DP (Decentralized Periphery)
● RS485 vagy száloptika
● gyors, hatékony adatátvitel
● legelterjedtebb - gépsorok, robotika, NC gépek stb.●PROFIBUS-PA (Process Automation)
● busztáplálású, Manchester kódolás (MBP)
● legközelebb van a folyamathoz
● érzékelők, aktuátorok
● legelterjedtebb - gépsorok, robotika, NC gépek stbSajnos a profinet-ről érdemben nem találtam semmit .
[ Szerkesztve ]
-
Szirty
őstag
válasz
isvarga
#2819
üzenetére
Üdv István!
"Egyébként a láttam olyan PLC leírást ahol 1:1 assembly utasítások is voltak a parancsok között."
A legtöbb PLC-nek (illetve fejlesztői környezetnek) van több szintű nyelve. alacsonyabb, magasabb. pl. Siemens S7-nek is van assembly-szerű nyelve (ami szintén célorientált).
"Olyan ez mint amikor a HMI megszólítja Janit , "már megint sörözni voltál te tróger " a HMI -nek dunsztja sincs mit ír ki ,csak aki ezt megcsinálta."
Az a cikk, aminek a linkjét idéztem amikor először emlegettél sci-fi-t (és ezek szerint nem olvastad el) a hibakezeléssel kapcsolatban pont ezt a témát feszegeti.
"Az ,hogy kitaláltak maguknak saját elnevezéseket , kommunikációt , csak a saját piac védelme miatt van."
Ezt nagyon rosszul látod! Ez csak részben igaz.
Avagy: nem azért találnak ki saját megoldásokat, hogy a saját piacukat védjék, hanem mert a dolog egyértelműen megkívánja, hogy dolgokat kitaláljanak (fejlesszenek).
És miután kifejlesztik (sok idő és pénz) már persze hogy védik!
Emberbaráti jóindulatból nem lehet megélni. Ezért gondolom nem fogsz te sem évekig heti 40 órában fejleszteni egy összetett kommunikációs módszert, majd azt teljesen ingyen mindenki rendelkezésére bocsátani."Van ez a profibus kommunikáció : (idáig én csak rs485-nek ismertem aztán modbusnak)"
A modbusnak semmi köze a Profibuszhoz. Azt egy másik cég fejlesztette ki (Schneider a Modicon PLC-ihez).
Az RS485-nem és a profibusznak meg annyi köze van egymáshoz, hogy az előbbi egy fizikai hordozó "réteg", míg a másik protokoll.
A profibus DP nagyon univerzális (ezért szükségszerűen nagyon összetett is) terepi busz kommunikációs protokoll ipari vezérlések, folyamatirányítás számára. Ez az RS485 vagy fizikai réteget használja (vagy száloptikát). (a ProfiNET pedig ennek az ethernetes implementációja). Ciklikus, Master-Slave alapú, token-ring szerű, fél duplex kommunikáció jellemzi. Megengedi a multi-master módot.A Profibus PA azt hiszem csak a fizikai hordozóban tér el. Itt két busz-szerű vezeték van, ami az eszközök tápellátását is biztosítja. A vezeték speciális, kialakítása olyan, hogy az eszközöket egyszerű bárhova ráfűzni a vezeték megbontása nélkül (vámpírcsatlakozós megoldás). Robotoknál NC gépeknél nem hiszem hogy gyakori az előfordulása. Inkább process automation (folyamatirányítás) a fő csapásiránya (arra lett kitalálva a fizikai kialakítása). tehát nagyobb távolságra lévő műszerek, távadók buszra fűzése pl.
ha jól emlékszem a megengedett max. adatátviteli sebessége jóval alacsonyabb mint DP esetében...A profibusz több céghez kötődik, tulajdonképpen ipari szabvány, amit a PI (Profinet-Profibus) konzorcium koordinál.
Sok infó van róla a neten. mellesleg a profinet.com cím is oda visz... -
Szirty
őstag
válasz
DP_Joci
#2821
üzenetére
Helló DP_Joci!
.fwx-et? Sajnos nem, semmiképpen.
Az sajnos már bináris és csak a futtató környezet számára szükséges adatok szerepelnek benne, a szerkesztő számára elengedhetetlen infók nem.
Ebből a szempontból olyasmi mint a bináris .exe, amiből már nem lehet visszanyerni az eredeti forrásprogramot. -
Szabest
tag
Sziasztok!
Szeretnék egy kis segítségek kérni:
van egy WINCCExplorerben futó projektem, ami azt csinálja, (tudomásom szerint) hogy a számítógép indulásakor elindul, mármint a projekt, és azon belül van Globál szkriptek vannak megirva amik automatice elindulnak. Felveszi a PC a kapcsolatot vagy 25 Távoli PLC-vel ip alapon, majd azok változóit figyelgetve minden szkript archivál bizonyos atadokat cvs-be! Namár most annyira nem értek a használatához a WinCC-nek. Ezért kérdésem volna hogy ha esetleg átküldöm privátba valakinek( Szirty??
) akkor rá tudna-e pillantani, hogy pl, hogy lehet leállítani(szkript törlés nélkül) 1-1 rögzítést, illetve valamiért azt csinálja, hogy ha újraindítom a PC-t, vele együtt ugye a Wincc-t is, akkor a rögzítés megy flottul, egy idejig, s majd minden szó nélkül megáll pár nap mulva. Ez vajon mitól lehet, mert eddig éveken átt flottul működött.Köszi a figyelmet!
Szabi
-
Dezsi82
tag
válasz
Szabest
#2823
üzenetére
Szia!
A WinCC-t én sem nagyon ismerem, de gondolom az ő scriptjei is VBA alapú, így aztán elvileg kell lennie egy ilyen utasításnak: WriteLine. Ez írja a tartalmat a fájlba. Ha jól sejtem, akkor ha kikeresed a megfelelő sort, és elé teszel egy komment jelet (') akkor nem fogja naplózni. -
vopi86
csendes tag
Sziasztok!
Régebben kértem Tőletek segítséget Omron témában.. mindenre választ kaptam, amit utólag is köszönök...
Most Siemens S1200-as PLC-vel és HMI-vel lenne egy kis feladat...
Ezekből az eszközökből állna a rendszerünk:
1db POWER SUPPLY S7-1200 PM1207
1db CPU 1214C 14DI/ 10DO/2AI
3db DIGITAL INPUT SM1221, 16DI, 24V DC
1db DIGITAL OUTPUT SM1222, 16 DO, 24V DC
1db DIGITAL OUTPUT SM1222, 16 DO, RELAY
1db ANALOG INPUT SM1231, 4AI
1db COMPACT SWITCH MODUL CSM 1277
1db SIMATIC KTP400 BASIC MONO PNTehát ebbe benne van a HMI, A PLC és a bövítőmodulok is.
Szoftvernek a TIA Portal 11-et kaptam.Az lenne a kérdésem, hogy hogyan tudom feléleszteni ezt a rendszert,
miután fikiailag össze lett szerelve minden, ethernet kábellel rácsatlakozok
a switchre és elindítom a TIA Portált... Innentől szeretnék egy kis segítséget..Köszi előre is!
Üdv.
vopi -
vsversus
csendes tag
Sziasztok!
Csatlakozni szeretnék az előttem szólóhoz, akarom mondani előttem íróhoz
Siemens S7-1200 as PLC-ről szeretnék információkat, anyagokat ismereteket gyűjteni, tapasztalatokról érdeklődni.
( Rendelkezésemre álló eszközök: Siemens S7-1200 SM1214C DC/DC/DC Cpu ; SM1223 DC/DC modul; CSM 1277 Kompakt Switch kártya(Ethernet Switch); KTP600 PN érintőképernyővel; TIA Portal 11 Szoftverrel).
Jómagamról annyit, hogy egy műszaki főiskola munkatársaként nemrég kaptam meg azt a feladatot, hogy derítsem fel, ismerjem meg e típust és keltsek életre hasonló rendszereket. Mivel eddig más területen dolgoztam, ( igaz némi ismereteim vannak a PLC-kről az automatizálási múltamból), mégis nem mondhatom magam profinak a témában és ezt ki is merem mondani.
Így szívesen fogadnék én is segítséget a témában.Talán egy hajszálnyival előrébb járok már az elemek összecsatlakoztatásánál
De azért az alapoktól kezdve minden érdekelSzívesen fogadnék például egyszerűbb S7 1200 program/projekt példákat amiket tanulmányozhatnék.
Én ezt az anyagot találtam S7 1200 as PLC-kről, és hasznos is volt a számomra, talán másoknak is segít
http://www.sze.hu/~hodossy/PLC/PLC%20II/S7-1200-as%20PLC%20csal%E1d.pdf
Bármilyen anyagot, vagy infót szívesen fogadok. Még az ismerkedésnél tartok, de én is szívesen segítek amiben tudok. Köszönöm!
Sándor
-
bodnarg
csendes tag
Sziasztok!
A következő problémára keresnék valami korrekt megoldást, hátha találkozott már valaki hasonló problémával. A adott egy S7 314C 2 DP kompakt CPU, ami egy analóg csatornán nyomás méréseket végez. A nyomás adatok egy légrugóból származnak, aminek a dugattyúja két holtpont között alternáló mozgást végez, ezért a nyomás egy minimum illetve maximum érték között változik. A rendszerben kialakuló maximális, minimális, illetve átlagos nyomást kellene meghatározni. A feladat hogy az átlagos nyomás 7 bar legyen. Amennyiben 6,5 bar alá csökken akkor rátölt a rendszer, amennyiben 7,2 fölé megy akkor pedig leereszt egy szelep a fölös nyomásból.
Van egy elképzelésem ami szerint ANY töbött lehetne feltölteni ciklusonként egy adattal, és a mondjuk 100 mérést kielemezni. Az lenne a kérdésem van e valakinek erre vonatkozó tapasztalata, hogy lehet ilyen jellegű feladatot "egyszerűen" és hatékonyan megoldani? Esetleg találkozott a siemens fórumában/supportjában valami hasonlóval, esetleg van valami kis minta progija. Találtam két standard fc-t FC25 MAx, illetve FC27 MIN ami valami hasonlót tud, de ha jól láttam akkor csak 3 értéket tud.Köszi: BG
BG
-
Szirty
őstag
válasz
bodnarg
#2828
üzenetére
Helló bodnarg!
A maximum és a minimum meghatározása elég egyszerű. Két változóra van szükség és minden mérési ciklusban a mért eredményre.
Nézzük a MAX-ot.Kell egy változó, amiben az addig mért legnagyobb értéked lesz majd (MAX). Ebbe kezdetben nullát töltesz. Amikor mérsz egyet megvizsgálod, hogy mért érték nagyobb-e mint MAX. Ha nem, akkor nem bántod, ha nagyobb, akkor a mért értéket beleteszed MAX-ba. Ezzel kész is. Ez akár milliárd mérés közül is tárolja az addigi maximumot. Egészen addig, amíg le nem nullázod újra (vagy feltétel nélkül bele nem töltöd a mért értéket).
A minimum meghatározása ugyanez, csak kisebbre hasonlítasz.Az átlag rafináltabb. Több módszer is van, nemrég volt szó róla a PLC levelező listán is. Szerintem olvasd el ott mit hoztak ki belőle.
-
Dezsi82
tag
válasz
bodnarg
#2828
üzenetére
Szia!
A minimum és maximum meghatározására kaptál egy jó útbaigazítást.
Anélkül, hogy a linkeket elolvastam volna, az átlagra én a következőket javaslom.
Egyszerű megoldás
4 db memóriérték kell.
- Átlag
- Pillanatnyi átlag
- Elemek száma
- Max elemek száma (esetleg lehet konstans is)Mert hát Neked nem kellenek (ha jól sejtem) az adott értékek, csak az átlag.
Az elv a következő:
-Jön a mért érték
-Ha az elemek száma nagyobb, mint a max elemek száma, akkor
átlag = pillanatnyi átlag,
pillanatnyi átlag =mért érték,
elemek száma = 0
- Pillanatnyi átlag = ((Pillanatnyi átlag*Elemek száma)+mért érték)/(Elemek száma+1)
- Elemek száma=elemek száma + 1Így ha mondjuk ha a max elemek száma 100, és minden ciklusban veszel mintát, akkor az átlagod 100 ciklusonként frissül és, az utolsó 100 ciklus átlagát adja ki.
Ha Neked nem ez, hanem mozgó átlag kell(a kérdésed alapján sejtve ezt szeretnéd), akkor a tárolást a standard libraryban található FC85 FIFO-val csinálnám. Az átlagolás már macerásabb, nincs rá standard blokk(amennyire tudom). Vagy egyesével összeadod, ami 100 mérésnél elég favágó módszer.
Vagy marad a pointer és ciklus használata. -
Dezsi82
tag
válasz
Dezsi82
#2830
üzenetére
Szia!
Közben rájöttem, h a FIFO kiolvassa a tárolóból, az ATT meg beleteszi.
De mivel nemsokára nekünk is kell egy ilyen alkalmazás, meg is írtam a függvényt.
Az FC1 függvény csinálj a lényeget. Kell neki egy DB szám. Ez itt most a DB1. Ebbe kell hogy legyen egy integer, utána meg egy real tömb. A tömb méretét ha átállítod, akkor az adatok is tovább mennek bele.Más nem lehet a DBben!!
Vár még agy real adatot, egy bemenetet a naplózásra, és egy segédmerker kell még neki. A kimeneten jön az átlag, a min és a max.
Ha nem felfutóra szeretnéd, hanem minden ciklusban, akkor ki kell szedni az FC1 ben azt a a sort, hogy AN felfutó_seged
Itt a projekt[ Szerkesztve ]
-
bodnarg
csendes tag
Hello Szirty!
Köszönöm a választ de sajnos nem voltam net közelben hogy reagáljak rá. A min és max ot már megcsináltam saját kútfőből úgy ahogy te is írtad. csak kíváncsi lettem volna hogy va e erre valami előre megírt funkció amiről nem tudok. Megnéztem a levelező listát az átlag számítással kapcsolatosan, és találtam néhány hasznos információkatm illetve linkeket. A siemens support oldalaira, ami közül néhányat magamtól is megtaláltam. Bár volt olyan amit elsőre nem tudtam megfejteni, hogyan működik.
Megpróbáltam a levelező listán általad megadott bejövő integerek átlagolását végő forrás kódot, de első nekifutásből hibüzenetek jöttek a fordítás során. időhiány miatt még nem kezdtem el megnézni mi nem tetszik a compiler-nek.Beillesztek néhány linket azokról az infókról amiket én találtam
http://www.automation.siemens.com/forum/guests/PostShow.aspx?PostID=280458&language=en&PageIndex=6
http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&objid=19345299&caller=view
Üdv.: BG
BG
-
-
Szirty
őstag
válasz
bodnarg
#2834
üzenetére
Helló bodnarg!
"mivel 8 jelet kell átlagoljak, előggé feltornázta ciklus időt"
Csinálj egy ring buffert, amibe egy mutatóval írsz, (Amikor a mutató eléri a buffer végét, az elejére állítod, így a címzés megy körbe-körbe)
Amikor mérsz egyet, akkor a mérési eredményt hozzáadod egy változóhoz, kiolvasod a ring buffer mutatója által mutaott elemét, amit kivonsz az iménti változóból, majd lépteted a buffer mutatóját, utána oda beírod a mért értéket.
Az átlagot ezután úgy kapod meg, hogy a változód tartalmát elosztod a ring buffer méretével.Előnye, hogy minden méréskor csak 3-4 műveletre van szükség és nem kell annyi amennyi elemű a buffer. vagyis sokkal kevésbé erőforrás igényes.
-
kovecses
aktív tag
Telemechanic PLC-hez keresek "SR1 CBL01" programozó kábelt!
Aki tud ilyet megfizethető áron, az kérem jelezze:
Tóth Levente
toth-levi67@freemail.hu
+36209720783 -
Dezsi82
tag
válasz
bodnarg
#2834
üzenetére
Szia bodnarg!
Sokat gyorsíthatsz rajta szerintem ha nem hívod meg a függvény elején az SFC24-t. Ez csak annyit csinál, hogy lekérdezi mekkora a db, és kiszámolja a buffer méretét.
Egyszerűen töröld ki a függvény hívást, és írd be fixen az SFC24 kimeneti változójába fixen az értéket. Vagy átírod a temp változót bemenetire (természetesen ennél a változatnál is ki kell törölni az SFC24 hívást).
Én egy hasonló módszerrel keresek ki 4 db 100 elemű tömbből adatokat, ebből 2 float. Nem volt gondom a ciklusidővel. Tény, hogy nem is hívom meg minden ciklusban az SFC24-t
Üdv -
kovimre
tag
Sziasztok!
Lenne eladó új AL2-24MR-D kütyüm, ha érdekel valakit! Privátban a többit!
-
Mec
aktív tag
Sziasztok! Érdeklődnék S7-1200assal kapcsolatban, itt találkoztam először a VARIANT adattípussal. Már sokfelé nézelődtem, de sehol sem találok a felépítéséről semmit. Egy olyan feladat lenne, ahol a DataBlock írás (WRIT_DBL) és olvasás (READ_DBL) forrás és cél paraméterét VARIANT típusban kell megadni, ezen belül szeretném a forrás és cél DB számot programból változtatni. Van erre lehetőség? Köszi!
mecsystem.uw.hu
-
Szirty
őstag
Üdv Mec!
"Már sokfelé nézelődtem, de sehol sem találok a felépítéséről semmit."
Az S7-1200 Programmable controller System Manual-ban le van írva.
A fenti angol, ha német jobban fekszik, akkor ezt töltsd le.
-
hpcleaner
csendes tag
Sziasztok!
A tanácsotokat szeretném kérni, bizonyára ismeritek a Zelio Logic vezérlőt.
A következő feladatot kellene megoldanom:
Egy bemeneti impulzus indít egy számlálót ,mely egy beállítható értékről számol vissza 0-ig. Ha a visszaszámlálás alatt újabb impulzus érkezik, akkor a számláló aktuális értéke x értékkel megnő s újra számol vissza.. A kimenet bekapcsol indításkor, s lekapcsol mikor 0-ra visszaszámol. A mindenkori számláló állást kijelző mutatja.
Ha szerintetek ezzel a berendezéssel ezt nem lehet megcsinálni, akkor milyet keressek?
Előre is köszönöm: Hpcleaner -
Dezsi82
tag
Sziasztok!
A következőben szeretnék tanácsot kérni. Van egy működő gép, amit át kellene alakítanunk. Ebben van egy szervó tengely, aminek egy nulla pontot kellene kreálnunk. De hát elég pontosan, ami 3 mikrométeres pontosságot jelent.
Amit én jelenleg a legpontosabbnak ismerek, az egy induktív szenzoros hiszterézis közepét mérő módszer. Ennek az elvi pontossága nullás, de a gyakorlatban sosem használtam ilyen pontos mérésre, ezért nem tudom a gyakorlati értéket.
Ha valakinek van tapasztalata ilyen pontosságú nullpont felvétellel, megköszönném, ha megosztaná. -
Szirty
őstag
válasz
Dezsi82
#2848
üzenetére
Hali Dezsi82!
Én sajnos csak elméleti fejtegetésbe tudok menni, ezért valószínűleg nem szolgálok válasszal a kérdésedre, de érdekes probléma.
Ha a szervó inkrementális encoderrel dolgozik, és az encodernek az "A" és "B" jelén kívül van "Z" is (ami körülfordulásonként egy impulzus) akkor a pontos refpontot ad az, ha a refpont ind. érzékelő valahol két "Z" között van. és a refpont az adja, hogy elérte ind. érzékelőt és onnantól első "Z".
Sajnos mivel a refpont felvétel ált. a drive magánügye, ha ilyen lehetőséggel nem vértezték fel, akkor ez máris füstbe ment.
Szokott lenni sok (de legalábbis több) reftravel mode. Akkor ahogy mondtad az lehet a legjobb ha elmegy ind. érzékelőig, megjegyzi hol érte el, túlmegy, megjegyzi hol hagyta el és a kettő különbségének a fele lesz a refpont.Amúgy fogalmam sincs, ilyen pontosság még nem kellett nekünk (igaz ált. a szervó utak nálunk 10 méterekben mérhető).
A CNC-k hogy/mivel csinálják ezt?
A PLC-k célorientált, a feladatra specializált eszközök annak megfelelő programozási lehetőségekkel és tudással. Ennélfogva ilyen feladatra nagyon hatékonyak (az általános célúaknál hatékonyabbak).
) akkor rá tudna-e pillantani, hogy pl, hogy lehet leállítani(szkript törlés nélkül) 1-1 rögzítést, illetve valamiért azt csinálja, hogy ha újraindítom a PC-t, vele együtt ugye a Wincc-t is, akkor a rögzítés megy flottul, egy idejig, s majd minden szó nélkül megáll pár nap mulva. Ez vajon mitól lehet, mert eddig éveken átt flottul működött.
Új hozzászólás Aktív témák
- Lenovo Legion 7, 16,0"WQXGA, Ryzen 9 6900HX, 32 GB DDR5, RX6850M XT 12 GB, 1TB SSD, 1,5+ év garancia
- Corsair RM850e 850W Gold Moduláris Tápegység
- Samsung Odyssey Neo G9 Super Ultrawide Gamer Monitor!49"/Mini LED/5120x1440/240hz/1ms/+Ajándék
- Apple Macbook Pro 16" 2019 i7-9th 6Magos 32/512 -75% Touch Bar HUN Radeon Pro 5300M 4GB 3K Retina
- Apple Mac mini M2 2023 8GB 256GB + Xiaomi Mi Desktop 27"-os FullHD monitor egyben
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen