- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Graphics: Hello Moto! - Kipróbáltam a Motorola Moto G55 5G-t. (videó is)
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- MasterDeeJay: Kínai DDR5 második felvonás - Puskill PSK-D5M4800BH-16G
- Magga: PLEX: multimédia az egész lakásban
- bambano: Bambanő háza tája
- eBay-es kütyük kis pénzért
- Viber: ingyen telefonálás a mobilodon
- GoodSpeed: POCO X6 PRO 5G 12/512 GB vs Samsung Galaxy S24 FE 8/256GB
Új hozzászólás Aktív témák
-
sörösló
aktív tag
válasz
liderces
#2898
üzenetére
"Mit szólnátok a Mitsubishi gyártmányaihoz FX sorozat, van neki kisebb változata, 220V-ról üzemelő,"
Ettől kapok sikongató lábrázást! Plc, 230V, triacos kimenet. Volt egy TSX Quantum a cégnél, még most is csuromvizesen ébredek, ha álmodom róla. Érzékelők illesztése vagy 230V-os példányok beszerzése. Általános 24V DC vezérlések, aztán szórakozottságból belemarkolsz a vezérlésbe, elfeledve hogy ez nem 24V! Nem fehérembernek való ez!
-
moseras
tag
válasz
liderces
#2898
üzenetére
Üdv!
Az FX1N sorozat belső reléi helyett külső reléket javaslok használni, vagy induktív terheléshez le kell varisztorozni. Továbbá a 4xPT100 (azt hiszem FX2N-4AD-PT típus) modul használatát sem javaslom.
Az alpha2 sorozat viszont jó, a hozzá való AL2-2PT-ADP modullal együtt.
Imi.
-
liderces
csendes tag
válasz
byte-by
#2896
üzenetére
Köszönöm mindenkinek az észrevételeket! Az a felállás hogy lakás felujjitásban is vagyok és kerülnöm kell a nagy kiadásokat.
Hát ugy van hogy egy "igazi" gépet szerettem volna. Mint a nagyok csak a leg kisebbet. Nézegettem a kis reléket is de árban mindennel drágábbak mintha egy valahonnan lebontott rendes PLC-t nézek. Omront egyszer régen pár éve már ajánlották, akkor nem került megvételre, mert nem volt célom csak ugy programozgassam? Az nem kihivás pár lámpát villogtatni. Meg meló váltás miatt akkoriban feledésbe merült.Viszont most aktuális a feladat is és az elszántság is megint, lenne egy konkrét célom vele. Mit szólnátok a Mitsubishi gyártmányaihoz FX sorozat, van neki kisebb változata, 220V-ról üzemelő, 10-15 körül beszerezhető, kábelt rendelek hozzá EBAY-ről. Szoftverem megvan elvileg, pár lépést már tettem benne. -
Szirty
őstag
válasz
byte-by
#2896
üzenetére
Hali!
Omron CP1E-t én is tudom ajánlani. Kapuhoz annyira nem, de tanulni kiváló, mert könnyen tanulható, az Omron doksik megfogalmazása angolul gyengén tudók számára is jól érthető, sok ábrával magyaráz.
A CX-Programmer pedig hatékony és könnyen használható.
Nem kell hozzá külön drága programozó kábel, egy közönséges A-B-s USB kábel megfelel: -
byte-by
tag
válasz
liderces
#2889
üzenetére
halo liderces !
a plc valóban erős túlzás egy ilyen művelethez, de ha nem gond az ár, vagy céges a dolog és azért gondolod mert így tudsz közelebb kerülni hozzá és esetleg gyakorolni, akkor mehet.
a Netec által említett ZEN programozható relé jó választás lehet és költséghatékony esetleg erre a feladatra, viszont a plc programozás konkrét folyamata ebből nem tanulható meg.
ha mindenképp erre apellálsz akkor az omron cp1(E) szériájának a legkisebb compact vezérlőjét ajánlom.
árban-tudásban még mindig sok az efféle projekthez, de , mint mondtam ha a majdani gyakorlás a cél és ezért gondolkodsz ebben , akkor jó lehet.ugyanazzal az utasítás készlettel rendelkezik, mint a moduláris , vagy nagy teljesítményű plc-k.
persze ebben az esetben szükséged lesz a CX-programmer szoftverre.byte-by
-
Szirty
őstag
Hali!
Más PLC fórumokon is kering a kérdés, elnézést ha valaki már belebotlott...
Kérdés lekérdezhető-e Simatic WinCC Flexible 2008 RT-ből futás közben (és ha igen miképpen) az az információ, amit a projectről WinCC Flexible ES-ben a project Properties ablakában a Compiler build number mutat?
-
liderces
csendes tag
Hát izlések és pofonok. A gyári vezérlő nem megbizható még javítás után sem. Ujjat venni vagy akár helyetesítő tipust meg drágább mint egy plc-vel megoldani. Még lehetne PIC-et programozni de ahhoz panelt kiegészítőket építeni sem egyszerü. PLC-ben adott minden csak a progit kell egyszer megszenvedni.
Monitorozást bővitést ugy gondoltam hogy most elsőre csak nyitás zárás lenne a cél később ha tényleg ott lakunk ráérek beleprogramozni kiskapu funkciót és egyéb kiegészítőket.
PLC-nek tudni kell bemeneten fogadni számolni impulzusokat és ezeket megjegyezni majd a müködtető gombok hatására oda vissza számolva hajtani a reléket amik motorokat mozgatnak. -
Dezsi82
tag
Szia
csak azt hittem hogy foglalkozott a forumlatogatok egyike a koltsegcsokkentes miatt kialakitott masik rendszerhez hasonlo plc programozasaval, de ezek szerint itg nincs ilyen
Én foglalkoztam/foglalkozok, ilyesmivel, épp most cserélünk le egy UniOP rendszert egy Delta rendszerre.
Ettől függetlenül nem hiszem, hogy többlet információt tudnék adni mint amit Szirty adott. Ami szerintem a rendelkezésre álló infók alapján a maximum.
Az általad használt vezérlőt én sem ismerem, így azzal kapcsolatos infót nem tudok adni, de a PLC, az PLC. Nyílván vannak egyedi tulajdonságai, de ha a netről letöltött adatlapok. és szoftverek alapján elindulsz, és elakadsz, szerintem itt fognak tudni segítséget nyújtani. Ha nem is típusspecifikust, de egy általános segítséget biztosan.
Én sem ismertem korábban a Delta PLCt, mégis sikerült két nap alatt felprogramozni a rendszert. Tehát ha típusspecifikus kérdés van (címzés, ilyesmi) akkor azt Neked kell valószínű kiszenvedni, de ha PLC programozás a kérdés, akkor tuti van itt segítség.
Ha a feladat teljes kidolgozása a kérdés, akkor nekem írhatsz privit, és tudunk árajánlatot küldeni. Akár tanfolyamra is. -
d3kk
senior tag
rendben.. csak azt hittem hogy foglalkozott a forumlatogatok egyike a koltsegcsokkentes miatt kialakitott masik rendszerhez hasonlo plc programozasaval, de ezek szerint itg nincs ilyen..
azert nagyon koszonom az instrukciokat, ha lesze mar elorelepes akkor meg visszatekintek
-
Szirty
őstag
Helló d3kk!
Talán ha valaki ismeri ezt a rendszert, majd ír valami neked megfelelő tippet.
Ha egy másik rendszer működését akarod lemásolni, akkor két dolog elengedhetetlen ehhez:
- A másik rendszer működésének a pontos ismerete, mivel anélkül esélyed sincs olyat építeni ami ugyanúgy működik
- A te "másolat" rendszered tulajdonságainak meg kell egyeznie a másolandó rendszer tulajdonságaival lehetőleg pontosan (eltérés esetén a másolat is eltérhet).Az üzeneteidből nem úgy tűnik, hogy ezek a feltételek teljesülnek.
Így ránézésre a "termosztát" ami egy bizonyos (beállított) hőmérsékletnél egy digitális jelet kapcsol ki vagy be nem biztos hogy elég lesz ahhoz amit leírtál..."adot homersekleteknel be ill ki kell kapcsolja a szivattyukat kulon kulon illetv szbalyoznia kell a keveroszelep allasat"
-
d3kk
senior tag
most kaptam az infot hogy a digitalis homero dolog megoldva szoval vegyuk igy hogy van 2 digitalis kimenettel rendelkezo homersekleti sensorunk.
a rendszer amit ki szeretnenk alakitani aza Siemens Albatros 2.3 2 keveroszelepes futesikort helyettesitene, mert ezutobbi kb 160k-t kostal.. ennek a "replicajat" kellene kialakitani mert plchez kb minden megvan.. mar "csak" a beprogramozas van hatra
szoval a siemens rendszeret kellene supercad el megcsinalni a plcre.. vagy vmi nagyon hasonlot
adot homersekleteknel be ill ki kell kapcsolja a szivattyukat kulon kulon illetv szbalyoznia kell a keveroszelep allasat
-
d3kk
senior tag
analog bemenet tenyleg nincs.. ez megoldható valahogy? bővitőmodul egyelore nem all rendelkezesre de van ra opcio. olyan homerseklet szenzort lehet szerezni ami digitalis jelet kepes alkotni az adott homersekleti ertekbol? vagy at lehet alakitani?
ui. van olyan egysegunk keznel ami analog jelet kepes digitalisra alakitani..
azzal megoldhato?
megnezem a tipusat az converternek
-
Szirty
őstag
válasz
liderces
#2877
üzenetére
Helló liderces!
"Nem kötekednék de szeretném kivesézni miért nem való ilyen célra a PLC?"
Mert nem költség hatékony. Nincs értelme a legtöbb esetben ilyesminek, senkin nem akarja PC-n monitorozni vagy gyakran módosítani a kapunyitója vezérlő programját.
A kpaut nyitni akarja meg zárni, tovább a dolog nem érdekli.
Persze lehet kivétel, pl. TeEz egy minimál mikrovezérlőnek is nagyon egyszerű feladat. PLC-t használni ide olyan mint ágyúval lőni verébre. Nagy pazarlás. Tanulni persze lehet belőle valamennyit, de őszintén szólva a feladat olyan mértékben egyszerű, hogy nem túl sokat.
Én nem mondom hogy ne csináld, de vállalkozást ne építs ilyen projectre.
-
d3kk
senior tag
Üdv, mindenkinek!
Nekem egy olyan helyzet áll fent hogy:
van egy PLC egység itthoni fűtésrendszer szabályozásra ( sr-22mrac )
namost: egy kétkörös fűtéskört (padlófűtéskör és egy radiátor fűtéskör) kellene szabályozni vele
szabályozandó eszközök:
- 2 db keringető szivattyú
- 2 db Siemens ssb31 el. szelepmozg.szabályozó:
- 2db analóg hőmérséklet szenzor, amely méri a szelepmozgatómotor által mozgatott háromjáratu keverőszelep kimenő ágának hőmérsékletétezeknek kellene a hőmérséklet alapú vezérlését megoldani..
a plc-hez a supercad2005 nevezetű programot adják.
namármost
az a helyzet hogy a hőmérsékletet (mostmégcsak ) analóg hőmérővel tudjuk megoldani.minden nemű segítséget szívesen fogadok
-
liderces
csendes tag
Nem kötekednék de szeretném kivesézni miért nem való ilyen célra a PLC? Sajna a kapunyitó gyári agya nem megbizható ha most meg is javittatom jó ha egy évet kibir megint elromlik és megbizhatatlan!
Igen szeretném tanulni is, de még nem vettem meg csak felmérem a terepet. Viszont ipari és bármikor ujratölthetem bele a progit amit gépen szerkeszthetek kényem kedvem szerint.
mondjuk ha lenne egy Mitsubishi fx sorozato PLC esetleg akad hozzá kábel is de progit nem találok, ill egyet levadásztam de abban is kellene segítség hogy lehet elindulni a program megírásában. -
-
liderces
csendes tag
Sziasztok! Épített e már itt valaki PLC-vel kapunyitót? Omron Siemens Mitsubishi melyik jobb? Tudnátok e segíteni egy mitsubishi fx sorozatu PLC kapunyitó programjának megírásában vagy esetleg ha valaki megírná menyiért vállalná?
Rég óta érdekelt de most adott a feladat és szeretném megtanulni a programozását.
Keresek ehhez a géphez (Mitsubishi FX programozó kábelt szoftvert tanácsot stb. köszönettel üdv -
DP_Joci
tag
Sziasztok,
Win7 alatt VM VirtualBoxot használok, az USB-s átalakítóval semmi probléma csak telepíteni kellett egy extension packot.
Ingyenes szoftver, ha segítség kell, akkor megpróbálok.Kérdés: Próbált már valaki virtuális gépet átvinni másik gépre? Elméletileg menni kéne a dolognak.
üdv.
Józsi -
Dezsi82
tag
Hali!
Az előnyeit én is a mindennapi, éles használatban élvezem a VMnek.
Az hogy ne menjenek az általad apróságoknak titulált dolgok, nemcsak erőforrás kérdése, hanem kompatibilitásé is. Futottam bele olyanba, hogy egy feltelepített fejlesztőkörnyezet után a korábban feltelepített nem működött, mert mondjuk mindkettő felrakott egy sql szervert, és a kettő nem bírt egymással.
Persze, ha arról van szó, hogy karbantartásra kell egy gép, és gyorsan, azonnal rá kell nézni a vezérlésre, akkor azon ne legyen semmi más. Gyorsan bekapcsolod, fut rajta az a néhány cél szoftver, ami kell. De ha mondjuk egy napon mész 4 céghez, 4 különböző helyre, és mondjuk, PLChez, PChez, robothoz, nagyon jól jön, hogy amikor az erőforrásokat arra az egy szoftverre tudott összpontosítani. És nem mellékesen működik. Nekem meg éri az az 5 perc, amíg előkészülök. Nekem sincs ultrabutál gépem, egyedül a memóriára áldoztam, 8 GB van benne. Sosem hibernálok, mindig kikapcsolok.
Ezért javaslom, hogy valaki versenypályán megy, vezessen forma1-s autót. Ha valaki rallizik, vezessen ralli autót. Autópályán lemarad, de elmegy mindenhova. -
Szirty
őstag
válasz
Dezsi82
#2869
üzenetére
Helló Dezsi82!
Természetesen az összes ellenszenvem a virtuális géppel kapcsolatban a mindennapi "éles" használatra vonatkozik.
Kétségtelenül előny, hogy lehet gyentelni egy VM-et ritkán használt, más szoftverekkel együtt nem működő programokat havonta/évente egyszer-egyszer használni, vagy szoftvert kipróbálni. Arra tökéletes."- Több fejlesztő környezetet használsz és nem akarod hogy az összes környezet összes kis kommunikációs, sql, meg minden egyéb kis kütyüje fusson olyankor is, amikor nem is használod."
Ne viccelj ez meg milyen érv? Azt akarod,hogy a virtualizálás állandó jelleggel két pofára GByte számra zabálja a RAM, ot és felezze a a CPU teljesítményt, mert nem akarod, hogy néhány service elhasználjon 10% CPU időt meg pár-tíz MB memóriát?
Milliókat költünk pár forint megspórolására...
Persze akarhatod, magánügy, nem akarlak meggyőzni semmiről én csak azért írom le miét nem akarom. (Az ellentétek ütköztetése segíthet másoknak eldönteni ők mit vagy mit ne akarjanak)Nyilván megvan az előnye és emiatt a létjogosultsága a VM-nek is. De azért azt merész lenne kijelenteni hogy ezzel együtt nincs hátránya és hogy mindig probléma mentes.
Számomra két alapvető hátránya teszi problémássá a a mindennapi használatát.
Az egyik a mértéktelen erőforrás igénye, és teljesen mindegy hány csillió teraHertzes a CPU (és ezen az erőforrás zabáló VM-en futtatunk erőforrás zabáló szoftvert (.NET-es alkalmazás rulez)). Persze a sebesség még ha mérhető is, van annyira szubjektív, hogy talán ami neked "nem lassú" azt én állni látom, benne van ez is.Mindenesetre szarul nézett ki, amikor baj volt egy géppel és terepen bekapcsoltuk a gépet, a BIOS szokásos fél perces parádéja után feltápászkodott a Win 1-2 perc alatt, aztán az egész boot műveletet megismételtük további 2-3 perc alatt a virtuális gépen, majd további fél perc mire betöltődik a fejlesztői környzet, aztán egy 20-30 másodperc "kiböngészni" a projectet és annak betöltődésekor nézni a homok órát, miközben a fél műszak, a művezető, az üzemvezető meg a karbantartók kérdezgetik hogy na mi a baj, mit csinálsz...
Persze tudom jöhetnek az ellen érvek: Pl. hogy vegyünk gyorsabb gépet. Vagy a notebookban van akku, nem kell leállítani amikor kivisszük (akku van, csak épp egy percet sem bír már szegény).
Vagy hiberbnáljuk, ne bootoljunk, akkor gyorsabban lesz üzemkész. Sajnos van hogy a "sztázisból" bal lábbal ébred a windows és nem jut eszébe hogy hálózat is volt még mielőtt elaludt. Így lehet újra bootolni, ami a leállással együtt, meg a hibernációból való ébredéssel együtt a fenti folyamatra rádob még pár percet. Ezt persze nem mindig csinálja, de ilyenkor (amikor sietni kellene) valószínű :-/Mivel a sok kicsi sokra megy a végén mit látnak? Azt, hogy áll a gépsor, én meg negyed óráig állok tétlenül a gép előtt...
Mióta natív XP megy és nincs VM a gyakran használt fejlesztői rendszer alatt, azóta sokkal hatékonyabb a munka. Ezért javaslom mindenkinek hogy ha teheti kerülje a VM használatát."...és nem szeretnéd, hogy elrontsa a korábbi szoftvert és újra kelljen telepíteni, akkor csak csinálsz egy snapshotot, és bármikor vissza tudsz állni."
A host gépen végrehajtott image mentéssel megoldható.
-
Dezsi82
tag
Hali!
Én azért tudok jópár érvet még a virtuális gép mellé:
- Több fejlesztő környezetet használsz és nem akarod hogy az összes környezet összes kis kommunikációs, sql, meg minden egyéb kis kütyüje fusson olyankor is, amikor nem is használod. De futottam bele olyanba is, hogy egyszerűen a két környezet ütötte egymást
- Ha van egy új verziójú szoftvered, de mondjuk ugyanattól a gyártótól van egy régi szoftvered, vele egy régi projekt, és az új már nem kompatibilis a régi projekttel (Sajnos tudok ilyet). És nem akarod a megrendelőnek azt mondani, hogy bocsi, azzal a géppel már nem tudok foglalkozni, mert már új szoftverem van.
- Van egy programcsomag, amit fel akarsz telepíteni, és nem tudod, hogy stabil-e, azt csinálja amit neked kell, és nem szeretnéd, hogy elrontsa a korábbi szoftvert és újra kelljen telepíteni, akkor csak csinálsz egy snapshotot, és bármikor vissza tudsz állni.
- Vagy új laptop. Feltelepíted a 20 szoftvercsomagot, vagy csak rámásolod a virtuális gépeket az új laptopra.Tény ha rosszul vannak beállítva a gép paraméterek, vagy gyenge a host gép, akkor lassabb és szívás. De nekem mondjuk az én laptopomon fut egyszerre 3 virtuális gép, és nem mondanám lassabbnak. Az is igaz, hogy amíg elindul a virtuális gép, azt meg kell várni. Ha jól be van állítva, akkor nincs vele semmi gond.
És egyre kevésbé mondanám ritkaságnak, hogy az XP felmegy új laptopra. -
#2868
Szirty
őstag
Csakénvagyok
#2865
Szirty
őstag
válasz
Csakénvagyok
#2865
üzenetére
Helló Csakénvagyok!
Ahh. Szóval a telepítőnek kevés a felbontás, nem a Step7-nek (az megy akár 800x600-ban is).
A virtuális gépen használni akkor érdemes, ha nincs mód megszabadulni a Win7-től (pl. mert a géphez nincsenek már driverek XP alá). Valamilyen szinten használható, de összehasonlíthatatlanul kényelmetlenebb, lassabb, körülményesebb és nem ritkán szívás.
Ettől neked még megfelelhet, próba szerencse. -
Dezsi82
tag
válasz
Csakénvagyok
#2865
üzenetére
Szia!
Én használok virtuális gépen USB-MPI átalakatítot minden gond nélkül. Bedugod, feltelepíted a virtuális gépre és megy. Nincs vele semmi kunszt. Teljesen kényelmes, nem rosszabb mint ha sima gépre dugnád. Macerásabb lenne, ha a hostra lenne telepítve a driver, de elvileg még az is megoldható. -
#2865
Csakénvagyok
őstag
Szirty
#2864
Csakénvagyok
őstag
Felbontási problémám nem csak nekem volt, íme itt egy példa, ahonnan a megoldást is vettem. És igen, a Step7re értem.
Arra gondoltam hogy a Win7+VirtualXP+USB-MPI átalakító combó csak bajokat szülhet, de kétlem hogy lehetséges-e azon a gépen rendszercsere, úgyszintén MPI adaptert is csak ezt tudom beszerezni. Ezért is keresnék valami leírást, esetleg valaki aki ezt így már próbálta és sikerült is. Lényegében ritkán használnám, és nem is sürgős dolgokra.
Szerk: Feljebb természetesen Win7et akartam írni, elírás volt a Win8
-
#2864
Szirty
őstag
Csakénvagyok
#2862
Szirty
őstag
válasz
Csakénvagyok
#2862
üzenetére
Helló Csakénvagyok!
"Azt szeretném kérdezni hogy valakinek sikerült már Virtuális XPről csatlakozni S7-300as procikhoz"
Igen. De etherneten keresztül (TCP/IP). Egy darabig mi is Win7+VM+XP+Step7 felállással próbálkoztunk.
Úgy-ahogy működik a dolog, de rettentő kényelmetlen és nyögve nyelős. Ekkor kialakult és azóta azt javaslom mindenkinek, hogy aki nem szopni akar, hanem hatékonyan dolgozni az nem hogy Win8-at, de Win7-et sem használ ilyen célra (egyelőre).
Aki meg akar, annak jó étvágyat...
Gyanítom,hogy az USB-s megoldás csak akkor fog menni, ha a virtuális gép hajlandó/képes korrekten átvenni a host rendszertől az USB kezelést."nagyobb rezolciót kért volna az S7, de igazán nem a felbontással volt a gond."
Még nem találkoztam olyannal, hogy a felbontással kapcsolatban bármi megjegyzése lett volna (Már ha "S7" alatt a Simatic Manager-t és a Step7-et érted, mert az S7 az maga a PLC).
-
sörösló
aktív tag
Jó kis enkóder...Jó drága! Mi is tele vagyunk ilyenekkel. Az igazi nagy élmény az, amikor a gyártó visszaír az ajánlatkérésre hogy forduljunk bizalommal a gépgyártóhoz (már ha még van), mert az általunk keresett tipust csak nekik gyártották. Eddig még nem volt ebből gond mert régi patinás német cégtől vannak a gépeink, de bele se merek gondolni hogy mi lenne ha egyszer csak nem lenne (akármilyen drágán is).
-
#2862
Csakénvagyok
őstag
Csakénvagyok
őstag
Sziasztok.
Windows 8 gazdarendszeren WinXp virtuális gépre telepítettem az S7et és egy MPI-USB convertert (6SE7-972-0CB20-0XA0). A gond az hogy Step7ből nem tudok S3xx procira csatlakozni. Csak driver telepítés után néztem meg hogy a HWconfiguration-ban van 3 ismeretlen eszköz. Azt szeretném kérdezni hogy valakinek sikerült már Virtuális XPről csatlakozni S7-300as procikhoz és van-e valahol egy részletesebb leírás ezt hogyan kéne megoldani. Mivel már telepítésnél belefutottam egy olyan problémába hogy nagyobb rezol
ciót kért volna az S7, de igazán nem a felbontással volt a gond. Ezt így oldottam meg -
Szirty
őstag
válasz
sörösló
#2860
üzenetére
Hali sörösló!
"Láttam már csúnya géptörést a refpont hibás érzékelője miatt."
Ó hogyne! A keresés és nem találás ilyesmibe gyakran torkollik...
Jobb esetben tényleg elsettenkedik ütközésig aztán jön a szervó hiba (overload, tracking error, stb.).
Sajnos volt már, hogy az ütközést az energia lánc valósította meg. Az meg ugye nem erős, de okos volt, engedett.
No meg játszott már ütközősdit profibuszos abszolút encoder is...
-
sörösló
aktív tag
"Szerencsétlen keresi a refpontot bőszen, de az már régen messze jár..."
Az jó ha csak keresi de más gond nem adódik. Láttam már csúnya géptörést a refpont hibás érzékelője miatt. Igaz, kínai volt a lelkem, és a hardveres végállást kifelejtették a projektből. Utána ráraktam, a kínai szervizes meg amikor arra járt, nem győzött csodálkozni hogy mi az istencsudája az a plusz végálláskapcsoló. Hülye német szokás, Kínában nem ismerik. Persze azóta... Ki tudja?
-
Szirty
őstag
válasz
sörösló
#2858
üzenetére
Hali sörösló!
"Néhány kolléga szerint CNC gépeknél az abszolút útadó az egyetlen járható megoldás"
Meg kell jegyeznem, hogy az abszolút jeladó valóban bír határozottan pozitív előnyökkel. Ugyanakkor a fentebb vázolt problémát az sem kerüli meg, de más jelleget ad neki
Nálunk sok szervó működik abszolút jeladóval (Nem CNC). Azoknak is mindenképpen kell referencia pont, legfeljebb ritkábban látogatják.
Ezért előfordul, hogy a refpont érzékelőjét leszerelik és elhasználják másik géphez, mert épp nincs induktív érzékelő a raktárban és az meg pont olyan. Természetesen ezután így is marad, a gép megy tovább, üzemszerű működése közben a refpont közelébe se szagol.
Míg nem aztán ahogy telik-múlik az idő és fluktuálódik a kezelő személyzet megtalálják a "referencia menet" funkciót, mert épp valami baj van és úgy vélek ez kell az üdvösséghez (vagy ennél prózaibb ok alakul ki: szervó drive csere történik).
Szerencsétlen keresi a refpontot bőszen, de az már régen messze jár...(van olyan szervóhajtás, amit 3 éve nem állítottak refpontra)
-
sörösló
aktív tag
válasz
Dezsi82
#2857
üzenetére
A nálunk működő rakatolóautomaták szervói resolveres jeladókkal működnek. Elmennek egy induktív érzékelőig, aztán tovább a resolver következő nullaátmenetéig. Ez a referenciapont. Ezt a módszert a német szerelő magyarázta el, de konkrét eljárást nem ismertetett. Az egyik gép lelke a jó öreg S5 hihetetlenül bonyolult szervovezérlője, amihez a csak a kizárólagosan használható programozókészülék töbszázezer, a használatához szükséges tanfolyam szintén. A másik egy S7 300 családba tartozó CPU, ami egyedi, technológiai CPU, felvértezve a háromtengelyes szevo vezérléséhez szükséges dolgokkal. A szoftveres hozzáféréshez a fullra töltött SIEMENS FiELD PG mellett még egy + párszázezres kiegészítő program kellene. de valszeg azzal sem mennénk semmire probléma esetén. Néhány kolléga szerint CNC gépeknél az abszolút útadó az egyetlen járható megoldás. Ez sem az ócsó kategória, úgyhogy az élet nem egyszerű
-
-
Tomika86
senior tag
Helló!
Szeretnék jobban belemenni a PLC-kbe, nem programot szeretnék írni, hanem egyszer csak rácsatlakozni és kiolvasni. Vagy ha van másik program akkor azt rátölteni.
A munkahelyemen a magyar gyártmányú gépekben OMRON PLC-k vannak, az olaszokban Siemens S7 -- Step 7 már nagyjából megvan. Itthon van is egy amihez kábelem is van, ezzel tudtam már gyakorolni. Most pedig PLC tanfolyamon is részt veszek, de még nagyon az elején vagyunk.
Köszi a segítséget!
-
Szirty
őstag
válasz
Tomika86
#2853
üzenetére
Helló Tomika86!
Igen a kijelzőt lehúzod és onnan is programozható.
Ha nincsenek elállítva a soros port paraméterei, akkor mást nem is kell tenned csak rádugni.Máskülönben szerintem inkább egy CPM1-CIF01kell...
Továbbá ha jól sejtem mindkét megoldáshoz egy ilyen kábel:
-
Szirty
őstag
válasz
Dezsi82
#2851
üzenetére
Helló Dezsi82!
A szervó hajtásokra jellemző (már amiket ismerek) hogy a refpoontnak nem kell a nulla pontnak is lennie egyben (sőt a legtöbbször nem az).
Durván fogalmazva úgy fest, hogy elballag a refpont érzékelőhöz, ott valamilyen módszerrel (pl. a "hiszterézis kereséssel") felveszi a referencia pontot és a koordináta rendszer nulla pontját ehhez viszonyítva állítja be (többnyire egy előre megadott paraméter alapján.
Több egyforma gépen ennek a paraméternek a beállításával (ha volna ilyen) elvileg teljesen azonos helyre lehetne hozni a hajtás nulla pontja.Sajnos igen a paraméter meghatározásához mérni kell. Mégpedig legalább olyan pontosan, amilyen pontosan be kell állítani egyformára.
A mérésről semmi elképzelésem nincs, nyilván kell egy bázis amihez képest mérünk. De hogy milyen mérési módszer adna ilyen pontosságot nem tudom, nem vagyok gépész.
De abból, hogy a szervó képes mérni a saját mozgását ekkora pontossággal, azt feltételezem, hogy ilyen pontos mérés lehetséges és kivitelezhető.
(Vannak pl. 1um pontosságú optikai távolságmérők) -
Dezsi82
tag
Szia!
Köszi a gondolatébresztőt, nekem is ezek jutottak még eszembe.
A Z impulzusos megoldás lenne talán az elérhető legjobb megoldás. De sajnos valamelyik jóeszű kitalálta, hogy a 10 gépükön ugyanott legyen a nulla pont a munkadarabhoz képest, így ez sajnos ugrott (azt még talán megoldanánk, hogy a szervó egy induktív érzékelő kapcsolása után keresse az alaphelyzetet).
Tehát ha az egyik gépen beírják, hogy 10 mm, akkor ha a másik gépen is ugyanazt írják be, akkor ugyanolyan munkadarab jön le a két gépen.
Na de aztán megnéztem azt a szakit, aki a 10 gépen 3 mikronon belül elhelyezi ugyanoda a szenzort. Vagy ha azt mondom, hogy na, felvettem a nullát 3 mikron pontossággal, leellenőrizhetitek, hogy tényleg 3 mikronon belül van-e, akkor mit csinálnak? Mivel mérik le? Honnan tudják, hogy ez most aztán 3 mikronon belül van? Hoznak egy érdességmérőt? 
Amikkel én találkoztam CNC-k azok mikrokapcsolóval, vagy tükrös optikai résszenzorral működtek. Szerintem a jel+Z impulzussal oldják meg. De nekik talán nem is kell nagyon pontos refpont, hiszen a program a munkadarab nullától indul, az meg úgyis a munkadarabon van, azt meg úgyis be kell mérni. Bár sokat nem dolgoztam CNCkkel. -
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?
-
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á. -
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 -
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.
-
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!
-
kovimre
tag
Sziasztok!
Lenne eladó új AL2-24MR-D kütyüm, ha érdekel valakit! Privátban a többit!
-
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 -
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 -
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.
-
-
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
-
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 -
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. -
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.
-
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
-
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!
-
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
-
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. -
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
-
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. -
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... -
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 .
-
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
-
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)
-
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 -
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
-
-
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)...
-
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) -
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
-
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
-
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... -
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
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). -
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
#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.
-
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
#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
Hát ugy van hogy egy "igazi" gépet szerettem volna. Mint a nagyok csak a leg kisebbet. Nézegettem a kis reléket is de árban mindennel drágábbak mintha egy valahonnan lebontott rendes PLC-t nézek. Omront egyszer régen pár éve már ajánlották, akkor nem került megvételre, mert nem volt célom csak ugy programozgassam? Az nem kihivás pár lámpát villogtatni. 
Új hozzászólás Aktív témák
Hirdetés
- Így lehet neked Teljes Magyar Logitech Craft Billentyűzet
- Csere-Beszámítás! Samsung Odysseg G5! 32COL / 2560X1440P Monitor.
- MacBook felváráslás!! MacBook, MacBook Air, MacBook Pro
- Csere-Beszámítás! Számítógép játékra! R5 3600 / RX 570 8GB / 16GB DDR4 / 500GB SSD + 1TB HDD
- Telefon felvásárlás!! Samsung Galaxy A14/Samsung Galaxy A34/Samsung Galaxy A54
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest