Keresés

Új hozzászólás Aktív témák

  • Dezsi82

    tag

    válasz isvarga #3229 üzenetére

    Szia!
    Igazából nem konkrét probléma, oli kérdésére válaszoltam egy ilyen hangos kérdéssel. :)
    Egyébként én is úgy csinálnám, hogy lenne egy bit, hogy tavaszi, vagy téli időszámítás. Ha téli időszámítás van, és hajnali három után március utolsó vasárnapján, akkor visszaáll az óra egy órával korábbra és bebillen a téli időszámítás bitje. Visszafele fordítva.
    Azoknál az alkalmazásoknál, ahol az időpont fontos tényező (műszakváltás, könyvelési dátum, stb) ott mi mindig időszinkronizálást használunk, így az órának 24 órán belül kell csak pontosnak lennie.
    Nekem egy illető a controller egyik lábára javasolta rákötni az elem feszültségét, és akkor lehet mindenféle riasztást vagy egyebet eszközölni, de eddig ezt nem alkalmaztuk.
    Úgyhogy bocs, de ezen a téren nem tudok megosztani tapasztalati dolgot.

  • Dezsi82

    tag

    válasz isvarga #3226 üzenetére

    Hali!
    Köszi az infót (habár számomra újdonságot nem rejtett a válasz).
    Mi többnyire külső IC-t használunk, bár azt hiszem igazából csak megszokásból. De ha jól rémlik, akkor valaki annak idején ezt is ajánlotta. Ha jól emlékszem akkor pontosabb.
    Sok fel nem tett kérdésre válaszoltál, csak a nyitottra nem. :D

  • Szirty

    őstag

    válasz isvarga #3170 üzenetére

    Helló István!

    Úgy tűnik megint olyasmiről vitáztunk, amiben egy kicsit egyetértünk, egy kicsit meg nem.
    De most már ezt a vitát ebben az irányban nincs értelme folytatni, mert egyre több személyes minősítő jelző kezd előkerülni. A veszekedés meg nem ide való dolog.
    Bennem nincs ellenérzés a személyeddel kapcsolatban, ahogy nem is volt.

    De annyit megígérhetek, hogy a jövőben sem fogok szó nélkül elmenni olyan állítások mellett amik szerintem nem teljesen vagy egyáltalán nem igazak (pl.: hogy a galvanikus leválasztás teljesen fölösleges).
    Én tárgyilagos próbálok maradni, ahogy eddig is tettem, ha nem kapod fel a vizet, a társalgás megmaradhat szigorúan szakmai keretek között.

    Addig is amíg újra össze nem akadunk, jó munkát... aztán ha majd megtörténik, akkor utána is! :-)

  • Szirty

    őstag

    válasz isvarga #3170 üzenetére

    Helló István!

    "Szerintem neked lehetnek szövegértési problémáid ,mert szerinted azt állítottam : "Nem ismerted el, hogy bizony a soros portnak +/-12V-os jelekkel kellene dolgoznia, de az USB porton csak +5V van.""

    Dehogy! Azt én állítottam!
    Én csupán azt írtam, hogy a fentit nem ismerted el. És ez így is van. Ennyit a szövegértésről?

    "Az viszont biztos ,hogy még soha az életben nem csináltál soros port illesztést."

    Látom a másodi kfázisba ért ez a "vita". Most már nem hangzanak el érvek, személyeskedünk...
    A feltételezésed téves. Csináltam soros port illesztést!

    "A felhasználó tábor az egészhez képest nagyon kicsi.(a helyettesítő eszközöket pedig nem ár alapján csoportosítják ,hanem mire használható , milyen felületen kapcsolódik stb)"

    Ez így van. Ezért is csoportosítom őket használhatóság szerint. És mint azt már írtam, a használhatatlan csoportba tartozó változatok jellemzően bírnak gyakorlatilag egytől-egyig azzal a szembeötlő tulajdonsággal, hogy olcsóak.
    Nem? :)

    "Különbség : Az olcsók 10éve készültek , a drágábbak 1-2 éve"

    Dehogy készültek 10 éve! Ezt meg honnan a fenéből veszed? Láttál egy olyat, amelyik 10 éves és drága volt?

    "Ha használnak egyéb pint is mint például a kézfogásos adatcserét az csak a pc "bénasága" miatt van.(de van neki szoftveres megfelelője is)"

    Alapvető tévedés!. Vannak eszközök használja a CTS/RTS DTR/DSR jeleket is.
    Persze itt is lehet barmolni, át lehet kötni a CTS-t az RTS-be. ugyanazon az eszközön és akkor a saját jelét veszi. A legtöbbször ez működik, de nem mindig.

    "A macsót ellenállhatatlanságáról ,fölényes stílusáról és kevés műszaki ismeretéről lehet megismerni."

    Ekkor rendben van. Én sem teljesen értettem hogyan kapcsolódik ez az USB átalakítás témájához, de nem akartam szavak definícióján megakadni.

    "Dc-dc konverter nem lehet benne mert nem bírják a szaggatott üzemmódot."

    Ejh! Ezt komolyan gondolod? Ne süllyedjünk már ilyen szintre!

    "Tehát általában szint illesztő van benne , de a 6Ft-os tranzisztorok is megteszik (persze bruttó az ár). E-néhány apróság képes akár 3,3V-ból is +-12v-ot csinálni."

    :>>
    Akkor viszont az lehet a baj, hogy ezeket nem teszik bele az átalakítókba (talán ugyanabból az okból: olcsóbb legyen)

    "Nyilván azzal sem vagy tisztába ,hogy az usb portot 100mA lehet szabadon használni. 100-500 között jelezni kell a host-nak extra igényünket.(ezt magának az eszköznek kell elvégezni)"

    Jujj már ember!
    Akkor a logikád szerint oda több mint 100mA kellene, de handshaking jelek meg tolnak több mint 100mA-t? Nem hiszem!:->
    Amúgy sem működne az USB-s vízforraló meg kenyérpirító 100mA-el 5V-on :) Na jó, igaz oda kell 4 db 8 portos USB kártya :)

    ""Talán az optocsatolós jeltovábbítás fizikai megvalósítása is drágábbá teheti az eszközt nem gondolod?""

    Nincs rá szükség és semmitől nem védi meg az eszközt. (ez minden kapcsolatnál így van ,először csatlakozunk és csak utána kapcsoljuk be a készüléket , én sem szoktam így csinálni)"

    Nos kedves István itt fejeztem be ezt a témát!
    Ekkora tévedést már nem tudok jókedvűen tolerálni!

  • Szirty

    őstag

    válasz isvarga #3166 üzenetére

    Helló István!

    "-Az hogy ugyanazt (valljuk be) az ipari hulladékot mennyiért adják csak attól függ kinek a kedvére akarnak tenni."

    Értem én hogy miről beszélsz, de azt hogy az ami drága ugyanazt tartalmazza mint ami olcsó, de a macsók azt veszik mindenre ráhúzni alapvető ostobaság.
    Mint írtam ami minőségi, kidolgozott, több anyagot és munkát fektettek bele az szükségszerűen drágább lesz annál, mint amit összebarmolnak és összelapátolnak "parasztnak tanyára jó lesz az" címszóval.
    Ugyanakkor a szart is lehet drágán adni, ez nem vitás.
    A mai világban ami egymás sárba taposásáról és az átb@szásáról szól ez sajnos benne van.

    Másrészt pedig mindent annyiért adnak amennyiért megveszik és nem annyiért amennyi az értéke.

    "-Miért építsenek ki olyan pin-eket amit már (kb 98-óta) egyik fejlesztő platform sem támogat?(ettől még ki lehet építve ,nem kerül semmibe ,én sosem használtam őket)"

    Már miért ne támogatná a "PIN-eket" a "fejlesztői platform"? Az lehet hogy a közvetlen környezeteben ez a kijelentés helytálló, de az egész univerzumra kivetítve nekem kétségeim támadnak a helyességét illetően.
    De ha már itt tartunk minek egyáltalán soros port, hiszen kilencvenhatban a soros Genius egerek kihaltak, hát ne tegyünk RS232-t a számítógépekbe, mert minek az oda? A kutya nem használja azokat.
    Aztán nézd csak meg hány ipari eszköz, frekvenciaváltó, hajtásvezérlő, szervó, PLC rendelkezik RS232-vel! Ó nem, NEM 1986-os évjáratúak, hanem új fejlesztésűek! A gépemben fizikailag egy soros port van. Amellett több mint tíz virtuális COM adapter. Kezdve a Bluetooth COM-tól át a GSM modemen, az S7-LAN adapteren keresztül a MODBUS interfészen át, a az analizátor műszer programja által realizált COM port-ig.
    Miért van ennyi? Talán mert semmi szükség nincsen már rájuk igaz?

    Visszatérve a fizikai soros port kialakítására:
    Nyilván elkerülte a figyelmed (vagy nem kívántad kiemelni mert nem támasztja alá amit írsz) hogy vannak olyan megoldások amikor pl. a "teljesen fölösleges" handshaking pinek adják az eszköz tápfeszültségét, mivel az RS232 csatlakozón nincs kivezetve tápfesz.
    Nem ismerted el, hogy bizony a soros portnak +/-12V-os jelekkel kellene dolgoznia, de az USB porton csak +5V van. Az olcsó szarokban ebből barmolnak közel sem szabványos jelet. A normális USB-RS232 átalakítóban meg DC/DC konverter van. Nem lehet azért (is) drágább és nem csak mert macsó?

    Nem reagáltál arra sem, hogy a normális ilyen átalakító izolált, az USB és az RS232 között semmilyen galvanikus kapcsolat nincsen (szintén kifejtettem ennek előnyét egy példával).
    Talán az optocsatolós jeltovábbítás fizikai megvalósítása is drágábbá teheti az eszközt nem gondolod?

    És igen, én szeretnék egy ilyen macsó USB-RS232 átalakítót magamnak ami az általam leírt jellemzőkkel bír. Hogy ne kelljen szarakodni az üzemben a gép mellett állva azzal hogy az istennek sem akar kommunikálni vagy épp a laptopot vágja tönkre a földpotenciál különbsége.

    Ha neked megfelel az olcsóbb, szerényebb képességű, hát használd egészséggel, áldásom rá. De tényleg.
    De azt állítani hogy minden normálisan elkészített eszköz is ugyanaz a szar, az nettó ostobaság.

  • Szirty

    őstag

    válasz isvarga #3164 üzenetére

    Helló István!

    Ha feltételezem hogy elolvastad amit írtam neked, akkor nem értem ez a válaszod hogy jött össze.
    Ha feltételezem hogy nem olvastad el, akkor nem értem miért írtál.

  • Szirty

    őstag

    válasz isvarga #3152 üzenetére

    Helló István!

    Egyébként messze nem csak az árat nézzük, de elég jól szokta jellemezni a minőséget, azt lássuk be.
    Ami olcsóbb a "kelleténél" az valószínűleg silány minőségű (vagy lopott).
    Sajnos ez nem reverzibilis: ami drága az sokkal kevésbé valószínű hogy jó, mint az hogy az olcsó szar.

  • Szirty

    őstag

    válasz isvarga #3152 üzenetére

    Helló István!

    Nem értem miért (ismét) ár alapján válogatod szét a termékeket.
    A virtuális soros portot mindegyik ugyanúgy hozza létre a 2000Ft-os és a 22222 Ft-os is.

    Az bizony meglehet, de a kutya nem ott van ám elhantolva, hanem a HW-ben.
    A "gyökér", semmire való bóvli 2000Ft-os USB-RS232 átalakítók meglehetősen magasról szarnak arra, hogy az RS232-nek +/- 12V DC jelszinteket kellene teljesíteni, és arra is, hogy az RS232-ben vannak ám az adatvonalakon kívül handshaking jelek is (RTS, CTS, DTR, DSR, RI). Ezeket baxnak benne kiépíteni :-/

    A normális, korrekt eszközben nincsenek ilyen gondok és még izolált is, ami nem kis előny tekintve hogy sok notebook adapter idétlen, de annál "divatosabb" RFI szűrőjének köszönhetően a notebook GND-jén olykor 60-150V AC is jelen van.
    Az RS232 kábel csatlakoztatásakor még szikrázik is (meg persze ráz, ha nem vigyázunk). Ami még annyira nem is baj, de ha sikeröl először az egyik jel PIN-nek érintkeznie a GND előtt, az garantáltan hazavágja a vonal driverét.

    ""Win 7-hez nem készül szoftver"
    Mint fejlesztő állíthatom ,hogy minden fut rajta amit szeretnénk"

    Hát addig örülj, amíg csak olyanokat szeretnél, ami fut rajta! Nagy szerencse az ilyen!
    Majd amikor már nem, akkor kereshetsz régi gépeket amiken még használható az XP, vagy szarakodhatsz virtuális géppel.

  • Szirty

    őstag

    válasz isvarga #2962 üzenetére

    Hali isvarga!

    Veled értek egyet. Venni kell bővítő modult a 200-ashoz és nem ilyen megoldásokhoz folyamodni.
    A tárolós megoldás ugrott be elsőre nekem is, de ahelyett inkább elleneztem ezt a kimenet sokszorozást, ezért nem írtam le.

    Ennek is van egy pár hátránya.
    Pl. szint illesztésről kell gondoskodni, a 4094 max 20V-ot visel el, kell egy külön tápegység is az egészhez.
    A PLC elejti az összes kimenetét ha pl. egy hiba miatt STOP állapotba kerül. Ezzel a megoldással azonban úgy maradnak a relék ahogy voltak.
    Fogalmam sincs, hogy ez a megoldás mihez kell (hiába kérdezem, Csakénvagyok nem hajlandó válaszolni) de ha otthoni fényjátékhoz karácsonyra, akkor ez nem gond, de ha valamilyen ipari berendezést kell vele vezérelni, akkor probléma lehet, erre is gondolni kell.
    A kimenetek kapcsolási sebessége is tizedelődni fog, ha a PLC 30ms ciklus idővel fut, akkor egy ilyen multiplexelt kimenet kapcsolása akár 240ms késést is szenvedhet. De mivel nem árulta el mire kell megint csak nem lehet tudni ez a tulajdonság jelent-e akadályt.

  • d3kk

    senior tag

    válasz isvarga #2891 üzenetére

    A anpi időzitő leirásának lenkje nem működik (ill a programé sem)

    mondjuk a lényeg a fűtésvezérlő :)

  • d3kk

    senior tag

    válasz isvarga #2891 üzenetére

    1000 Köszönet!! :R
    Én nem vagyok otthon de már elküldtem az illetékesnek, és írok ha van fejelmény!

  • 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...

  • 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 #2814 üzenetére

    Hali!

    "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.)"

    JUJJ!

  • 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)

  • isvarga

    csendes tag

    válasz isvarga #2812 üzenetére

    Na persze nekem van olyan megrendelőm ,hogy programozásnak hívja amikor 2 paramétert beállít .

  • 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)

  • 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).

  • 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.

  • 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 :)

  • Szirty

    őstag

    válasz isvarga #2798 üzenetére

    Hali isvarga!

    "Az adott alkalmazások időbeni garantált lefutására gondoltam .(nálam is adott felhasználástól függ )"

    Én pont azt szerettem volna kiemelni, hogy a PLC MINDIG determinisztikus. Ez nem függ semmitől, az alkalmazástól meg pláne nem.
    Egy ciklus garantáltan véget ér egy megadott időn belül (ált. max. 100ms körüli értéket szoktak megengedni, de nagyobb PLC-knél ezt lehet állítani is).

    Ha mégsem képes lefutni (hogy képes-e vagy sem az a kódtól függ, mert lássuk be: egy végtelen ciklusra annyira nem jellemző hogy meghatározott időn belül lefutna) akkor a rendszert biztonságosan leállítja (vagy egyéb olyan akciót hajt végre, amivel a probléma biztonságosan kezelhető).

  • Szirty

    őstag

    válasz isvarga #2795 üzenetére

    Hali isvarga!

    Nocsak. Egy mikrovezérlős PLC fejlesztési projecttel már találkoztam a HE oldalain.
    Gratulálok, ez szép munka!

    Pár megjegyzést teszek (elvégre ezt kérted).
    A hivatkozott oldalon van egy ilyen megjegyzés "(érdekes idáig azt hittem a PLC-garantál valami futás teljesítményt az egyes program elemekre )"

    Igen a PLC determinisztikus. Vagyis garantált hogy egy programciklust véges és ismert időn belül befejez (vagy végrehajtja, vagy ha az nem lehetséges, akkor jelzést ad).
    (Már ha erre gondoltál)

    Pár kérdés, ami eszembe jut:
    A ki és bemenetek galvanikusan le vannak választva? Ez rendkívül fontos az üzembiztonság szempontjából. (az ipari PLC-k ilyenek).

    Amennyire látom az eszközt közvetlenül a mikrovezérlő nyelvén lehet programozni, vagyis nincs semmilyen szoftver környezet, oprendszer benne.
    Ez nagyobb rendszerek hatákony fejlesztésénél, ami erre az eszközre épül, komoly akadály lesz. Bár lehet nem is arra szántad.
    Emiatt a készülék inkább célvezérlő, mint univerzális ipari PLC.

    Mindenképpen derék amit létrehoztál!

Új hozzászólás Aktív témák

Hirdetés