Új hozzászólás Aktív témák
-
#9221
Professzore
csendes tag
PHM
#9219
Professzore
csendes tag
Javíts ki, ha rosszul számolok, de 1000 ohm ellenállásnál 0,02 A áram 20 V feszültségesést fog produkálni. Erre jön rá a vezeték ellenállása (pár tíz ohm), plusz a "fogyasztó" kétpólusának belső ellenállása (ehhez adatlap kell, ideálisan a végtelenhez tart, de legalábbis több nagyságrenddel nagyobb, mint a többi kétpólus belső ellenállása), ennek eredményeképp a 0-10 V bemenetre "sikerül" uszkve 19 V-ot ráereszteni. Nem biztos, hogy jó ötlet.
Szóval ha már van valami, ami tud áramot generálni és van valami, ami tud ilyen folyamatjelet fogadni, akkor azt kell használni, trükközés nélkül. Kivéve, ha a vezetékszakadásra is fel akarunk készülni, de az meg ugye külön program.
Nem rossz leírás a témában a Phoenixnél:
https://www.phoenixcontact.com/hu-hu/technologiak/ipari-jelfeldolgozas/digitalis-analog-jelillesztes -
#9218
Professzore
csendes tag
HollyBoni
#9217
Professzore
csendes tag
válasz
HollyBoni
#9217
üzenetére
Én is a common ground-ra tippeltem. Ha a tervező nem akar magával kiszúrni nagyon (vagy okosabbnak lenni mindenkinél is), akkor nem tesz dedikált GND-t (AGND) az analóg bemenetre.
A többi így kerek. 8750 Hz így a teljes fordultaszám, 60 kHz-en ez szűk 6,5-szeres mintavételezés, valószínűleg nem lesz gond vele. Ha tudsz majd szűrőzni a bemeneten, akkor fél másodperces kijelző frissítéssel nagyon stabil és egészen pontos kijelzést fogsz kapni.
Az, hogy elővetted az adatlapot, dícséretes! -
#9214
Professzore
csendes tag
HollyBoni
#9213
Professzore
csendes tag
válasz
HollyBoni
#9213
üzenetére
Direktben csak úgy fogod tudni osztani, ha sorba kötöd a két motort (0-10 V-ot tudnál párhuzamosítani). Körülményes és nem biztos, hogy az elvártak szerint fog működni.
Az FG-hez jó eséllyel HSC kell majd (vagy valami hasonló megoldás, ami az adott PLC-n implementálva van). Gépkönyvből nézd ki, hogy milyen értékek jöhetnek rajta (frekvencia), aztán nézd meg, hogy a PLC-n van-e olyan dedikált bemeneti mód, ami direktben tud, praktikusan legalább egy nagyságrenddel nagyobb frekvencián mintavételezni. Vagyis ha 1 kHz-es négyszögjel jön az FB-ről, akkor 10 kHz-től felfelé fogsz tudni látencia nélkül, értelmes felbontással mintavételezni. -
#9206
Professzore
csendes tag
HollyBoni
#9205
Professzore
csendes tag
válasz
HollyBoni
#9205
üzenetére
Miért akarsz árnyékolt kábelt? A legtöbb analóg jelforrás (már ha az áramerősséges megoldást nézzük) elég jelentős hosszakat kibír TP vagy sima vezetéken is.
Árnyékolásnál a gyártói előírásokat kell figyelembe venni, mert a bemenetet úgy tervezik (RF illesztés/szupresszió többek között). Ha valahol csinálsz ezzel egy hurkot (ami földeléssel annyira nem nehéz), akkor lesz egy több tíz (vagy száz) méteres antennád. Többet ártasz vele, mint használsz. -
#9200
Professzore
csendes tag
HollyBoni
#9196
Professzore
csendes tag
válasz
HollyBoni
#9196
üzenetére
Ez elég érdekes kérdés. Én két irányból mennék neki. Egyrészt, irányítástechnikai "szakemberként" mindenkint próbálok lebeszélni arról, hogy komoly otthoni alap rendszereket automatizáljon. Világítás, fűtés, HMV. Hajmeresztő megoldásokat láttam (dugpaneles áramkör, Arduino UNO, mindebből kettő darab, ami mindenestül szabályoz egy ház fűtést, palletes, aktívan szellőztetett égésterű kazánnal). Egy Rievtech (vagy tetszőleges másik kvázi-ipari programozható relé) ennél már sok klasszissal jobb. Abban biztos vagyok, hogy maga a folyamat, hogy újdonságot fedezel fel, tanulsz és fejlődsz, önmagában baromi jó. Ha ezt módszeresen és átgondoltan teszed, a megfelelő pontokon meg segítséget kérsz (és nem az internet "szakértő" népétől), akkor még az eredmény is jó lesz. 5-6 év üzemet ezeknek illene kibírnia. S7-1200-nak 10-et legalább. Mondjuk az már más liga.
-
#9199
Professzore
csendes tag
spkkill
#9195
Professzore
csendes tag
válasz
spkkill
#9195
üzenetére
Én rendszeresen belefutok ipari környezetben LOGO!-kba. Egy brutál előnye van (ami hátrány is egyben), hogy egy rahedli paramétert tudsz menüből állítani, nem kell hozzá szoftver. Sok alap feladatra szerintem bőven megteszi. A Riectech sem feltétlen elvetendő, bár ott azért van pár kimagasló hülyeség. Vagy nézd meg Dani legújabb filmjét az APB-ről. Én állati jól szórakoztam rajta (és most szakmai hibát sem láttam benne). :-)
-
#9198
Professzore
csendes tag
HollyBoni
#9194
Professzore
csendes tag
válasz
HollyBoni
#9194
üzenetére
Szuper, köszönöm!
A Rievtechnek is megvan a helye, a LOGO!-nak is, meg az S7-1500-nak is, nem nagyon csereszabatosak. A Sitop volt kissé overkill, nem a Riectechet szóltam le, pláne hogy van nála rosszabb is. :-D
Szóval, attól függően, hogy melyik verziót használod, alapvetően jó lesz a relés megoldás. Az például, amelyiken a zöld és a kék rövidre zárásával tudod nyitni (és a szakadással zárni) a szelepet, nagy valószínűséggel még a gyári relét sem fogja túl gyorsan tönkretenni. Pont a Riectechekben lévő relék kb. 10000 kapcsolásra vannak hitelesítve. Ha ez sima szárazkontakt a túloldalon, tehát nem lesz brutál áram vagy jelentős induktív terhelés rajta, akkor ezt tudni fogja, nem kell külön modul hozzá. Adatlapon nem találtam, érdemes megmérni.
Védelemre: mivel 24 V 6 W az 250 mA, 0,5-1 A körül biztosítanám sima olvadóbiztosítékkal (ha tudsz terhelési görbét mérni, akkor ahhoz kell igazítani a biztosíték jelleggörbét). Ha kalapsínes szerelést csinálsz, akkor pl. a Weidmüllernek van biztosítékos átmenő sorkapcsa. Vagy ha ez "sok", akkor sima autóipari késes biztosítékot beteszel értelmes érintésvédelemmel.
A PID-es szelepszabályozást nem egészen értem, de biztos van létjogosultsága. -
#9185
Professzore
csendes tag
HollyBoni
#9183
-
#9180
Professzore
csendes tag
HollyBoni
#9179
Professzore
csendes tag
válasz
HollyBoni
#9179
üzenetére
Részletesen...
Az xLogic „fentről” nézve rettenetesen fáj, nagyon erősen korlátos, de működik.
Az „alap” PLC-k és a LOGO/Rievtech között koncepcióban, rugalmasságban, kontrollban, szabványossági megfelelőségben és még rettenetesen sok mindenben fényévnyi távolság van. Viszont ez nem jelenti azt, hogy ne lehetne elképesztően sok dolgot megvalósítani velük. Legfeljebb jóval rögösebb az út (bár mondjuk könnyebb is beletanulni). Ha a rendelkezésre álló eszközkészlettel megvalósítható a célod, felesleges feljebb lépni.
PI működik ezekben, aztán az, hogy sikerül-e úgy paraméterezni, hogy az elvárt működést hozza, már más kérdés, de nem zárnám ki. Viszont azzal számolj, hogy itt félvezető-alapú kimenettel hajtott, a célra megfelelő kapcsolóelem kell majd, mert egy relét elképesztően gyorsan ki tudsz nyírni így. A „nagyjából” tartanihoz nem kell PI. Ha a hiszterézis paramétereit pontosan adod meg, akkor lehet eldönteni, hogy indokolt-e bármi más megoldás, mint a sima fel/le kapcsolgatás.
Ez az ellenállásos megoldás nem feltétlen a legjobb megoldás. Működik, de bukhatod a linearitást és egy rosszul választott ellenállásal tönkre tudod tenni a szenzort és a PLC bemenetét is. Az analóg bemeneteknél rendszerint választható a 2+1 üzemmód (0-10 V feszültség, 0-20 mA áram + 4-20 mA áram). Vezetékezésnél, méretezésnél azért figyelembe kell venni a gyártói előírásokat (szenzorra is, PLC-re is), de ezek jobbára egybevágnak többé-kevésbé.
Amivel még számolni kell, ha "feljebb" lépnél az az, hogy hirtelen el fognak tűnni az ingyenes szoftverek és szemmel láthatólag meg fog ugrani a bővítő modulok ára. Nem annyira kétségbeejtően nehéz egy 40 centis kalapsínre felpakolni 1-1,5 millió értékben cuccokat. -
#9173
Professzore
csendes tag
Tomika86
#9170
Professzore
csendes tag
válasz
Tomika86
#9170
üzenetére
Ez 4-5 sor/blokk nagyjából és teljesen felesleges külső, már megírt függvényekkel szórakozni. Beállítasz egy értelmes ciklusidőt (nem a futásra, bár arra sem feltétlen elvetendő, hanem a mérésre), csinálsz 1(-2-3) mérést, ha többet, azokat gyorsan leátlagolod, összeveted az előző ciklus eredményével. Ha ez a várható töltési/ürítési sebességhez képest számolt várható értékeken durván kívül esik, akkor eldobod a mérést, mert belelógott a kar. Ha benne van és elérte a felső/alsó kapcsolási értéket, akkor beavatkozol, ha nem, akkor méred a következőt. Ha egymás után 2-3 mérést el kell dobni, akkor nyilván valami hiba van, vagyis esélyes, hogy le kell állni. Nyilván az eldobott mérés után a várt értéket korrigálni kell.
-
#9172
Professzore
csendes tag
HollyBoni
#9168
Professzore
csendes tag
válasz
HollyBoni
#9168
üzenetére
Üdv,
Rajzold fel kérlek egy végtelenül egyszerű lapra a szabályozási köröket, kérlek!
A PID-ekkel az a baj, hogy csak lineáris bemeneti feltételekkel működnek megbízhatóan (néha még akkor sem). Vagyis ha a saját szabályozási körükre kívülről beavatozol (egyensúlyt bontasz), akkor más P/I/D konstansokra kell azonnal átállni. PLC-vel ilyen szabályozási feladatok megoldhatók (már amelyikben van ugye).
Műszakilag négy 0-20 mA analóg bemenet kell és ha jól látom, három szárazkontakt. Ezt a legegyszerűbb Siemens LOGO is tudja, még ha nem is közvetlenül meghajtva a kimeneteket. Talán még valamelyik Rievtech is. -
#9165
Professzore
csendes tag
Tomika86
#9164
Professzore
csendes tag
válasz
Tomika86
#9164
üzenetére
Ha ez bárhogy megvalósítható, egy töltési görbét (amit a PLC-n figyelsz) dobj fel ide releváns vízszintes (idő) lefolyással. Tippem szerint ez egy átlós vonal lesz kiugrásokkal benne.
Több módon lehet szűrni, de hogy melyik a jó, az pont ettől a jelleggörbétől függ.
U.i.: turbiditás szenzorokban a külső fény hatását analóg szűréssel (erősítés -- negáció -- differenciálás) módszertannal szűrik. Parádésan működik, valami hasonlót itt is lehet eszközölni. -
#9153
Professzore
csendes tag
Tomika86
#9152
Professzore
csendes tag
válasz
Tomika86
#9152
üzenetére
Nyilván vicc. Sheldon meg ebben a jelenetben különösen jó ide.
Kivételesen kevés jól dokumentált és jól kommentált kódot láttam, amelyek ráadásul még többé-kevésbé olvashatók is voltak az elfogadható változó nevezéktantól.
Egyébként az én aktuális kedvencem egy török cucc, amin konkrétan próba-szerencse alapon kellett beállítani a működési paramétereket, mert sem az elnevezésekben, sem a használati utasításban (már amit úgy adtak hozzá, hogy az az, valójában egy vicc volt) nem volt egyértelmű, hogy mi merre hány méter. Ehhez szerencsére nem kellett hozzányúlnom, bár azért a szakállamat szaggattam egy ideig, hogy milyen ún. brilliáns megoldások vannak benne (elektromosan). -
#9145
Professzore
csendes tag
spkkill
#9144
Professzore
csendes tag
válasz
spkkill
#9144
üzenetére
Nagyon leegyszerűsítve nem gyerekjáték. Valóban bármit (is) meg lehet vele csinálni, viszont az optimális használathoz nagyon kell (1) a gyorstalpalós tudáson túl jelentős önszorgalom, (2) a teljes programozói környezet (TIA) és az eszköz (PLC) lehetőségeinek ismerete, (3) a hatékonyságot, karbantarthatóságot javító programozási eljárások, megoldások ismerete.
A LOGO!-val kis túlzással egy intelligensebb goldi is elboldogul (oké, inkább egy vizsla :-D). -
#9141
Professzore
csendes tag
Professzore
csendes tag
Sziasztok,
Köszönöm a válaszokat.
Árnyalom kicsit a képet, részben reagálva a felmerült ötletekre.
Én is az 1200-at preferálom, minden nehézsége és kihívása ellenére, ugyanakkor az fontos, hogy az egész koncepció célja, hogy ne kelljen rengeteget utazni annak a pár adatnak a leolvasásáért, ami alapján kiderül, szükség van-e beavatkozásra.
Nekem most az a részben önként vállalt feladatom, hogy egy olyan prototípust rakjak össze, ami később átfordítható az új és a retrofit telepítésekbe, és egyensúlyban van a költség/megbízhatóság/kényelem háromszögben.
A kódok módosítása nem gond, azokban a már telepített szekrényekben, ahol meglévő PLC alapú vezérlés van, a PLC cseréjével a kérdés megoldottá válik. Ahol cél elektronika vezérel, ott vagy lecseréljük saját PLC alapú (egyen) rendszerre, vagy nem lesz távfelügyelet.
Alapvetően kevés adat kell, a logolás másodlagos, a cél inkább az, hogy fény derüljön trendszerű változások elemzésével arra, hogy az üzemzavaroknak van-e szisztémás okuk (vagyis a hardver vagy annak beállítása rossz-e). Mivel viszonylag egyszerű (kb. PLC gyorstalpaló tanfolyam bonyolultságú) eszközökről van szó, a kifinomult távfelügyeleti/táv-beavatkozó rendszereket eleve kizárnám (elsősorban az ár és a komplexitás miatt).
A legfontosabb információ az, hogy milyen paraméterek mentén és mikor futott hibára a rendszer. A log (ami még a legelvetemültebb esetekben is napi maximum 1500 sort tartalmaz, alapértelmezésben úgy 20-40-et) arra kell, hogy a historikus adatokból kiderüljön, hogy van-e trend, illetve van-e olyan tipikus együttállás, amely hibára futtatja a rendszert.
Az MQTT-t egyelőre jegelem. Köszönöm a tanácsokat! -
#9136
Professzore
csendes tag
Professzore
csendes tag
Sziasztok,
Kis közös gondolkodásra hívnálak benneteket, egyelőre teoretikus/pilot/PoC-szintű a dolog, de nem lenne ártalom 2-3 héten belül egy működő rendszerrel megörvendeztetni a leendő megrendelőt.
A peremfeltételek: adott több, önálló, független ipari berendezés, mind azonos elven működik: vagy érzékelőpárok küszöbértékeinek átlépésekor vagy adott idő elteltével aktiválnak egy működési szekvenciát. Az érzékelőpárokból 1-2(-3) lehet, de 3 csak kivételes (egyetlen egy ilyen gép megy most). A gépek nem köthetők vezetékes netre, elvileg áramot is szinte csak jófejségből kapnak, így az adatforgalom minimális lehet (valószínűleg egy LTE AP lesz a megoldás, de még keresem a lehetőségeket -- egyelőre nem ez a fő kérdés). Szinte minden gép évente legalább egyszer-kétszer random hibára fut, vagyis teljesen véletlenszerűen vagy a kelleténél jóval többször indul el, vagy – hiába az időzítés vagy a feltételek teljesülése – egyáltalán nem indul el. Ezt jó esetben az üzemeltetők jelzik, akkor a fenntartó autóba pattan és 1-5 órán belül már a helyszínen is van, hogy felmérje, mi van. Legtöbbször NEM derül ki a rendellenes működés oka (szenzorok épek, működnek, szoftver, vezérlés megy, beavatkozók működőképesek). Előfordul az is, hogy az üzemeltetők csak az időszakos karbantartásnál mondják, hogy "ja, volt 3 hete valami gond, de nem szóltunk és már el is felejtettük, hogy mi volt az".
Az igény: a megrendelő egy másik projekthez vett egy Rievtechet (azóta beépítettük, 2 évet kell mennie, utána ipari hulladék lesz belőle). Rövid rábeszélés után rájött, hogy a Rievtechben nagyjából az ára jó, a projekt nagysága és a fő megbízó költségviselő képessége alapján vagy LOGO vagy inkább S7-1200 lesz telepítve mindenhova (az egyik beszállítója egész jól összerakott, ellenben teljesen karbantarthatatlan megoldásokban szállít LOGO-kat; az is cél, hogy ezeket a szekrényeket teljesen kiváltsuk, mert előfordul, hogy változik a hardver és utána a jelenlegi gyakorlat szerint egy komplett új szekrényt küldenek teljes áron, a régi meg ment a kukába -- eddig egy ilyen eset volt, az is több éve). A Rievtech honlapot böngészve látta, hogy van ám itt webszerver meg minden ilyen csoda, és de jó lenne, ha...
1. látná valós időben, hogy az adott rendszer épp milyen paraméterekkel üzemel, illetve mikor futott le a legutóbbi aktiválási ciklus,
2. látná, hogy 7-14-30-akárnány napra visszamenőleg az aktiválások mikor történtek, mennyi ideig futottak, mi volt a kiváltó ok (idő vagy paraméter), és mi volt a szenzorok által rögzített érték az aktiválások kezdetekor és a befejezést követően (ez mondjuk 7 adat: kezdőidőbélyeg; ok; szenzor1kezdeti; szenzor1vég; szenzor2kezdeti; szenzor2vég, lejárati időbélyeg),
3. látná, ha rendkívüli esemény történt (táp hiánya, valamely szenzor kritikus értéke, végtelen ciklusra futó kód, időtúllépés stb.), erről remek lenne aktív értesítés is (e-mail vagy még inkább sms), ebbe nem kell adat, de a fenti 2. pont alatti logba kell a hibajelzés is.
És végül a kérdés: Mindkettő (S7-1200, LOGO) tud webszerver szolgáltatást és tud MQTT-t is. Előbbi elvileg sima feladat, bár némi nehézség a hosszú távú logolás és a felhasználói felület, viszont ha nem elérhető a PLC, akkor adathozzáférés sincs. SMS csak külön eszközzel, körülményesen. MQTT jóval rugalmasabbnak tűnik (adatforgalom is kisebb), van backup, tehát ha a PLC elfossa magát, az utolsó adat időpontja még elérhető. Cserébe kell mögé egy bróker, egy adatbázis, és egy on-line elérhető felület. Tehát praktikusan valami aggregátort kellene találnom, aki biztosít nekem erőforrást az MQTT brókerhez, az adatbázishoz meg a felhasználói felülethez, méghozzá viszonylag kis mérettől indulva, nagyon finoman skálázhatóan. 10+ éve a LOSANT-nak volt ilyen szolgáltatása, azt tesztelési célokra teljesen jól tudtam használni, pilot/PoC szintű projekt futott rajta parádésan, csak ők eléggé szintet léptek felfelé. Nem kell csicsamicsa, nem kell komoly vizualizáció. Kell viszont szinte plug-and-play egyszerűségű alkalmazhatóság (tehát ne legyen olyan, hogy itt van minden, DE egyébként kérlek még ezt, ezt, ezt meg még azt is csináld meg, hogy használni tudd). Továbbá lehetőleg egy mobilelőfizetés árának megfelelő havi előfizetési díj eszközönként.
Milyen megoldást ajánlatnátok erre, akár a "dobozon kívül"?
Amit néztem: LOSANT (skálázható, de elég magasról indul az alja is); HiveMQ (havi 100000 forintért kis túlzással én leautózok); HomeAssistant (ha jól láttam, ingyenes, alapvetően más célt szolgál, sms nincs, de ami a legnagyobb baj, hogy -- legalábbis a jelenlegi megértésem alapján -- legalább egy hardveres réteg kell a PLC és a szerver közé); EMQX (van ingyenes, pay-as-you-go megoldásuk, ami rokonszenves, ellenben kell egy futó PC-n egy futó applikáció, hogy működjön).
Köszönöm szépen előre is! -
#9113
Professzore
csendes tag
Watchdog
#9112
Professzore
csendes tag
válasz
Watchdog
#9112
üzenetére
Szia,
Köszi!
Megpróbáltam, de úgy eldobta magát tőle a TIA, hogy „öröm” volt nézni.
Pár kört futottam az elmúlt – ha jól nézem – bő 4 órában, kezdve azzal, amit mondtál (nyilván nem egyszer). A CPU nem engedi a downgrade-et (van ilyen, ismert „feature”), a 4.53-mal semmit nem tudtam előre lépni, úgyhogy most utolsó mentsvárként felhúztam rá a legújabbat (4.7). Az sem volt egyszerű. Így most zöld pipás az RS232 modul is, úgyhogy bíztató a helyzet. Éles kóddal még nem próbáltam, az most jön, remélem nem 2 órát fog tartani.
Köszönöm még egyszer! -
#9111
Professzore
csendes tag
Professzore
#9110
Professzore
csendes tag
válasz
Professzore
#9110
üzenetére
U.i.: a vonalkódolvasó él egyébként, a saját (kissé őskövület) szofverével USB-n teszi a dolgát. Kommunikációs beállítások is jók (egyeznek azzal, ami a TIA beállításokban van.
-
#9110
Professzore
csendes tag
Professzore
csendes tag
Üdv,
Kezdek erősen nyűgös lenni két nap kínlódás után.
S7-1200 1215 (6ES7 215-1AG40-0XB0, fw 4.5) plusz CM 1241(6ES7 241-1AH32-0XB0 fw 2.2), TIA 20 Basic.
Eddig bármilyen eljárást próbáltam, nem sikerült „rendre” bírnom: olyan, mintha a TIA nagyjából látná (pl. firmware-t tudtam rajta frissíteni), de kezelni már nem igazán hajlandó. Egy Keyence SR-610 vonalkódolvasó lóg rajta, a Keyence gyári mintakódján kívül még számos más módszerrel próbáltam, eredménytelenül. Már az RS-232 vonal sem „szólal meg”. Minden maximum warningokkal fordul, de a legutóbbi kódok már ennyivel sem terheltek, fel is megy a PLC-re, de azon kívül, hogy egyébként rendesen fut, nem azt csinálja, amit kellene neki.
Egyelőre ott vagyok megakadva (az egyetlen látható hibaként), hogy a Device view-nál a kommunikációs panelre tájékoztatást dob, hogy az on-line diagnosztika nem megy.
Screenshot itt: (a legutóbbit is elrontottam): https://www.dropbox.com/scl/fi/6rtmyw3n9irdo3088kst5/2025-07-31_14h49_02.png?rlkey=i9268xztrw29d6o4lyrfz062q&dl=0
Először ezt szeretném ráncba szedni (nem találtam rá működő forrást), ha egyáltalán van rá mód (és indok). Aztán kerítek egy másik RS-232 eszközt (vagy bekapcsolom a szkópot).
Minden javaslatot, tanácsot szívesen fogadok!
Üdv! -
#9109
Professzore
csendes tag
spkkill
#9108
Professzore
csendes tag
válasz
spkkill
#9108
üzenetére
Szia!
Fontos! Bármiféle rosszindulat nélkül, csak ha már szembejött, akkor gondoltam, megosztom.
Vadzsi új, 1200 G2 analóg bővítő kártya. Mi néz rajta szembe? STM32G070.
Nem vagyok nagyon meglepve, végignézném (fogom is) a lánc minden elemét. Az már eleve tetszik, hogy nem a saját belső ADC-jét használják, hanem egy dedikált eszközt (ADS8675, 10 bites, paraméterezhető, finom kis cucc, bár nem az ipar csúcsa).
Ha nem látod az e-mailt, írj majd privát üzenetet, ezen a héten káosz van, utána pihi jön, ráérek.
-
#9105
Professzore
csendes tag
spkkill
#9104
Professzore
csendes tag
válasz
spkkill
#9104
üzenetére
Üdv,
A témáknak semmi köze a gyakorlati megvalósításhoz. Ezek olyan szintű fundamentumok, minthogy egy autószerelőnek tisztában kell lennie a dízel és az otto motor közötti különbséggel. Azt láttam, hogy a nyelveknél a hibát kijavítottad, ez kafa. A PLC-s részben csak (részben az eltérő látásmódból adódó) féligazságok vannak, igazából egyik sem kritikus és nincs belőle sok. Viszont a mikrovezérlős részben írt szempontok és tények majdnem fele egyáltalán nem igaz, negyede féligazság.
Az igazán szűk keresztmetszet szerintem a terminológiában van, már amennyiben (például):
-- láthatólag a mikrovezérlőkre úgy tekintesz, mintha azok kimerülnének az előre gyártott fejlesztői panelekben (pedig nem),
-- nem ugrott be, hogy a PLC-k egy része kifejezetten mikrovezérlő-alapú (vagy azokhoz nagyon hasonló felépítésű és működésű SoC lapka az agyuk),
-- a „fától” nem láttad, hogy az Arduino nem mikrovezérlő, pláne nem nyelv, hanem egy gyártó, akinek speciel van mikrokontroller (STM32F747XI) alapú, szabványos (61131-3) nyelvekből fordító IDE-vel programozható PLC-je. -
#9097
Professzore
csendes tag
spkkill
#9096
Professzore
csendes tag
válasz
spkkill
#9096
üzenetére
Üdv,
Van egy gépük, ami HMI-s. Ha jól értettem, mindössze kettő információt olvasnak le róla, arra meg igazából egy vintage-be hajó analóg műszer is bőségesen elegendő lenne.
De. Ha meg akarják csinálni azt, amit javasoltam, ahhoz kell az érintős HMI. De a két megoldás között hardver oldalon is és kód oldalon is elég szemmel látható különbség van.
Nyilván ha nincs köztes megoldás, ami megfelel a célnak, marad a HMI. -
#9095
Professzore
csendes tag
Professzore
csendes tag
Üdv mindenkinek,
Taktikai szerű kérdésem van. HMI megoldást keresek, de végtelenül egyszerűsítve:
• egy vagy két érték kijelzése (mondjuk százalék, bár a teljes értékű három helyiérték lehet, hogy jobb lenne, tehát 888 forma, tizedes nélkül),
• lehetőleg világosban (de nem direkt napfényben, de kültéren), 2-3 méter távolságból is gond nélkül olvasható legyen, tehát a kijelzett számok legalább 3-4 centi magasak legyenek, kiváló kontraszttal,
• lehetőleg ne legyen túlgondolva adatátadás szempontjából (az analóg jelet mellőzném több okból, de egy sima RS-232 már bőven elegendő),
• elvileg nem kell mást tudnia (se szín, se tapi, se gomb, se csilivili ábrák), 10 Hz maximum frissítés bőven elég.
7 szegmenses kijelző adná magát, Siemensnél a Basic HMI árban van, bár az is tud olyat, ami borzalmasan felesleges, de ezen túl semmit nem találtam és építeni most nem feltétlen szeretnék (egyelőre 2, maximum 3 kellene).
Ha a T. megrendelő ennél érdemben többet szeretne, akkor egy alap tapizós HMI-t fogok neki ajánlani, mert ha azt szeretné, amit szerintem szeretne, ahhoz azzal egy kicsit egyszerűbb lesz a terepen paramétert állítani. Platform még nem végleges, Siemens, Omron, esetleg Wago.
Köszönöm szépen előre is a válaszokat!
U.i.: sikerült. Mindnekinek. -
#9092
Professzore
csendes tag
Professzore
csendes tag
Üdv mindenkinek,
A „suliban” vége az aktív tanításnak, projekt-időszak van, jövő héten vizsga. Meglehetősen fura körülmények között sikerült eljutnunk az FD és FBD programozás alapjainak alapjaiig nélkülözve az olyan témákat, mint a terepi buszrendszerek, szimulációs környezetek, komplex dobozok (pl. PID), failsafe rendszerek, HMI-k, debug. A 600 órásra meghirdetett tanfolyamból (a kiíráshoz képest) nagyjából a bő felét adták le, mondván, hogy „a vizsgára a többi nem kell”. Az első kérdés ebből következik: hogyan tovább?
Melyik oktatási patformot, könyveket tudjátok javasolni? (Hegamurl nyilván megvan.)
Másik oldalról felmerült, hogy ha már a Siemens most 45%-kal olcsóbban árulja azt, ami az 1200 G2 sorozatból már megvan, illetve a STEP 7 Basic V20-at is, sok szól amellett, hogy előre ugorjak és kvázi jövőbiztossá tegyem a tudásomat. Innen viszont már nincs elég információm a „jó” döntéshez.
Az eddigi tapasztalataitok alapján mennyire „múlt-biztosak” a STEP 7 verzióváltások (vagyis a meglévő eszközök visszamenőleges támogatása mennyire biztos például a V20-ban vagy V21-ben)? Ha ezzel gond lehet, futhat-e két verzió a STEP 7-ből?
Mennyire szoktak hardver oldalon bugosak lenni az új eszközök?
Van-e értelme már most felkészülni a 3-5 év múlva várható felfutásra, vagy még azért több évig, ha épp nem évtizedig velünk marad a G1?
Hálásan köszönöm előre is! -
#9091
Professzore
csendes tag
Alcsi69
#9089
Professzore
csendes tag
válasz
Alcsi69
#9089
üzenetére
Jajj, nem. Ha a nagy képet nézzük, akkor nem ugyanaz a ciklusfutás eredménye a két példa alapján (nyilván ehhez a kód többi része is kell).
Komoly különbség van a S/R logika és az első példában lévő öntartás között.
Használják az LD-t. A kb. „alapszabály” az, hogy ha van áramutas terv (és esetleg fizikai megvalósítás, amit ki kell váltani PLC-vel), és nem kell hozzá istentelenül sok funkciódoboz, akkor az LD-t sokkal egyszerűbb forráskódként megírni az áramutas tervből, mint bármi mást. -
#9090
Professzore
csendes tag
norbert1998
#9088
Professzore
csendes tag
válasz
norbert1998
#9088
üzenetére
Egyetértek.
Annyit érdemes figyelembe venni – különösen kezdőként –, hogy a PLC fő programozási „nyelvei” szabványosak, vagyis vizualizáció, logika, felépítés, működés tekintetében (legalábbis elvileg, mert nem minden implementáció követi betűre a szabványt) mindenütt ugyanaz. -
#9082
Professzore
csendes tag
Tigerclaw
#9079
Professzore
csendes tag
válasz
Tigerclaw
#9079
üzenetére
Üdv,
Először nézd meg a szerződésüket, annak is a karbantartás / garancia / átalány szakaszát (ha van egyáltalán), illetve azt a leírást, amely a hibajelentési és -kezelési protokollt tartalmazza. Ha nincs ilyen, akkor a felmondás lehetőségeit.
Ha a forráskódot nem is adták oda, a kóddokumentációt oda kellett volna adniuk (az első pontból ki kell derülnie, hogy mi volt az eredeti megállapodás; forráskódot jellemzően nem szeretnek átadni, de ez szerződéstől függ). A dokumentációból kiderül, ami esetleg az eredeti specifikáció híján nem egyértelmű, hogy a megrendeléskor milyen működést vártatok el.
A kiolvasásról és a visszafejtésről majd a tapasztaltabb kollégák írnak a lehetőségek oldaláról, az viszont fogós kérdés, hogy ha meg is találod a hibát, akkor azt egyáltalán lesz-e lehetőséged kijavítani és a javított kódot visszatölteni.
U.i.: aki meg olyan hibaüzenetekkel dolgozik, amelyek nem egyértelműek (és/vagy nincsenek), az menjen inkább péknek vagy kőművesnek, esélyes, hogy több haszna lesz. -
#9080
Professzore
csendes tag
Tigerclaw
#9077
Professzore
csendes tag
válasz
Tigerclaw
#9077
üzenetére
Szia,
Rá kellett keresnem, és mivel eddig azért egy szemmel látható időt eltöltöttem források után kutatva és még a neve sem rezgetett még csak csengettyűt sem, pláne nem harangot, valószínű, hogy Európában nem túl masszívak.
Japán eszközökre specializált kollégát meg tudok kérdezni. -
#9076
Professzore
csendes tag
gomiregi
#9070
Professzore
csendes tag
válasz
gomiregi
#9070
üzenetére
Üdv,
Miért keresel szoftvert?
Minden programozás oktatási platform vagy könyv, az említésre sem méltók kivételével azzal kezdi, hogy bármennyire is bonyolult egy feladat, minden esetben kezdd azzal, hogy a legkisebb kezelhető egységekre bontod, majd ezeknek az egységeknek az egymás közötti összefüggéseit térképezd fel.
Magával a PLC-vel és a HMI-vel, pláne a bővítő modulokkal otthon nem sokat fogsz tudni kezdeni, hacsak nincs egy halom olyan alkatrészed, amelyekből valós visszacsatolást tudsz produkálni. Mert az addig jó, hogy egy gombot megnyomsz, ez alapján a PLC aktivál egy kimenetet, de utána?! Nyilván a szimuláció sem old meg mindent, de a tanulás kezdeti fázisában bőven elég (sőt).
Nagy gépsorokat kezelő szoftvereket vizsgálni addig jó, amíg normális szakember normális konvenciók (és szabványok) szerint írta meg, megfelelően van dokumentálva és egyébként jól működik. Ha ezek a feltételek nem teljesülnek, akkor csak rossz megszokásokat fogsz megtanulni.
A tanulás során az első dolog, amihez egy sima txt szerkesztő kevés lesz, az az idődiagram, de ehhez is elég egy sima négyzethálós papír. -
#9047
Professzore
csendes tag
DasBoot
#9046
Professzore
csendes tag
válasz
DasBoot
#9046
üzenetére
Szia,
Esélyes, hogy figyelik, de használt cuccok (magyar vonatkozással) a face adok-veszek szak"csoport"jában nagyobb valószínűséggel lesznek fellelhetőt. Allen-Bradley viszonylag ritka, de azért előfordul. Nem egy fiatal cucc, úgyhogy ha találsz működőt, akkor nem kell érte eladnod a vesédet valószínűleg. -
#9039
Professzore
csendes tag
spkkill
#9038
Professzore
csendes tag
válasz
spkkill
#9038
üzenetére
Ah, "nincs az a pénz", hogy én itthon ilyet csináljak. :-D
Ezt írtam korábban: „Elsőre a cél: alapvetően tanulás, tapasztalatszerzés, alap projektek megvalósítása (vízkezelő berendezéstől kezdve automata esővízelosztáson át automatizált ipari csarnokvilágításig).”
Az utolsónak jelen állás szerint a nullánál nagyobb esélye van fizetős projektként megvalósulni, bár ehhez speciel HMI nem kell.
A FactoryIO-t megnézem, köszönöm a tippet! -
#9037
Professzore
csendes tag
spkkill
#9036
Professzore
csendes tag
válasz
spkkill
#9036
üzenetére
Nem itthoni felhasználásra vettem, hanem tapasztalatszerzésre és tanulásra. Itthonra brutális overkill, de ha kvázi "hobbi" (nevezzük inkább szimulációs) projekteken végigtolomo a szopórollert, akkor éles helyzetben nem azzal megy a drága idő, hogy megoldást keresek. A beágyazott fejlesztésben pont ez az (egyik) jelentős korlát, mert míg az a) projektnél problémamentesen implementálható és parádésan működik egy megoldás, addig b) projektnél csupán néhány (bár jelentős) alkatrész csere miatt hetek, sőt, hónapok mennek el megoldáskereséssel. Oké, hogy a PLC alapú megoldásoknál kis túlzással legóból épkítkezés szajlik, szemben a nullszériás és prototípus beágyazott fejlesztéssel, ahol meg az építőkockák és alkatrészek összerakása és egymáshoz illesztése zajlik.
Milyen részlet(ek)re vagy(tok) kíváncsi(ak)? -
#9035
Professzore
csendes tag
spkkill
#9020
Professzore
csendes tag
válasz
spkkill
#9020
üzenetére
Köszi, ez lett.
Két CPU és egy HMI ketyeg az asztalon, utóbbi még nem élesztve, de a gyári csomagolásból kivéve tápra dugva megy. TIA Portal próba fut, a nagyobb CPU firmware-e miatt már kiabál (újabb a firmware, mint amit az aktuálisan felrakott V14 Trial támogat), de ezt leszámítva hiba nélkül programozza.
Kicsit amiatt vagyok mondjuk csalódott, hogy a tizenév beágyazott fejlesztés során véghezvitt eszelős szívásokat ha ebbe tettem volna, már tartanék valahol... De utólag könnyű ugye okosnak lenni... -
#9034
Professzore
csendes tag
Primary92
#9032
Professzore
csendes tag
válasz
Primary92
#9032
üzenetére
A rugalmassága és az egyszerűsége megvan hozzá, a támogatás is nagyjából. Ha meg tudod oldani, hogy teljesen szeparált legyen a külvilágtól, akkor a legfontosabb kiberbiztonsági téma kipipálva (persze ettől még be lehet menni, de az esélye elég pici lesz).
A többi elvileg alkalmas rá, de ahogy elnézem, nem két hétvége lesz összerakni. :-)
A Loxone valóban pusztulat drága. -
#9031
Professzore
csendes tag
Primary92
#9030
Professzore
csendes tag
válasz
Primary92
#9030
üzenetére
Üdv,
Én más (embedded) fejlesztői alapvetés mentén azt mondanám, hogy aminek nyílt forráskódú az alapja (RPi az), azt vagy nem kötjük netre egyáltalán vagy az első hardveres réteg fölötti szinttől magunk írjuk meg. (Tankönyvi "hogyan ne csináljuk" példa rá a most épp a Google égisze alatt működő Nest, amelyhez korábban, még a StartUp kezdeti fázisában kis túlzással csak az nem tudott hozzáférni, aki nem akart.)
Ha nem barkácsolni akarsz és van forrás, akkor pl. a Loxone kellemes alternatív irány, de ez azért költségigény tekintetében más liga. -
#9029
Professzore
csendes tag
spkkill
#9028
Professzore
csendes tag
válasz
spkkill
#9028
üzenetére
Nem ismerem a részleteket, így nem tudok róla nyilatkozni, de az érintettnek láthatóan PTSD-s utórezgései vannak a kódra gondolva.
Nem csodálkozom rajta. Látva pár Arduinos oktatási anyagot, pár koncepciót, ami mentén közel sorozatgyártott termékek kódbázisát összerakták, hajlok rá, hogy az alapértelmezés nem az, hogy jó (és karbantartható) legyen, hanem az, hogy működjön. -
#9027
Professzore
csendes tag
spkkill
#9026
Professzore
csendes tag
válasz
spkkill
#9026
üzenetére
DB, FB lesz, az előbbi pont most szerdán lett napirendre tűzve, de széttart a csapat erősen, így nem jutottunk el odáig. A DB-t érintettük említés szinjtjén.
UDT nekem megvan az embedded vonalról.
Multi-Instance napi szinten szembe jön, de nem ebben a megközelítésben, hanem hibaként. :-D Mármint, megpróbáljuk, de nem megy. Egyszer bele kell sétálni az utcába, hogy tudjuk a megoldást.
Indirect addressing valószínűleg messze túlmutat a vizsga keretein, valószerűtlen, hogy érinteni fogjuk, persze csodák még előfordulhatnak.
Végtelenül vegyes a társaság, van, akinek fogalma sincs, hogy merre van előre (1-2 kihagyott óra neki már behozhatatlan), de olyan is van, aki már élesben tart karban (próbál meg karbantartni) több ezer blokkos működő kódokat, amiket ahány "mérnök", annyi féle kódolási konvenció mellett rakott össze, úgyhogy minden, a 61131 szerinti két- és hárombetűs előfordul. -
#9025
Professzore
csendes tag
Professzore
csendes tag
Erősen leesett az állam.
Az első iskolai alkalomkor nagyjából a bevezető "dumcsi" alatt unalmamban rákerestem a vezérlő árára (wago 750-8202), a bővítő modulokkal (8DI, 8DQ, lezáró) egy szett "ajándékba", táp nélkül bő 600 000-re jött ki.
S7-1200-ból ez 175000... Már csak a liszensz ára kell, de ez nagyjából így el is dőlt. -
#9024
Professzore
csendes tag
And
#9021
Professzore
csendes tag
Szia,
Köszönöm, hasznos volt.
EATON-ra lásd az előző hozzászólást, a Moeller itthon nyomokban sem elérhető, ahogy láttam, Mitsubishi, Honeywell oldalait rövid keresés után bezártam, túl specializáltnak tűntek (ami persze, ahogy írtam, lehet tájékozatlanság is a részemről).
Az S7-1200-ba beleásom magam. A TIA Portal V13 demóját most leszedtem, 3 hétig tudom nyúzni, utána meglátom. Így legalább kiderül, hogy a szimulációs modulja mennyire működik. -
#9023
Professzore
csendes tag
spkkill
#9020
Professzore
csendes tag
válasz
spkkill
#9020
üzenetére
Köszönöm a választ!
A Codesys, legalábbis a 2-es, amin tanulunk, tizenéves embedded fejlesztői tapasztalattal borzalmas kín. Oké, hogy szabványos megfelelés, de kilométerekre van a karbantarthatóságtól, személyre szabhatóságtól, stb. (és nem csak én sírok miatta). A V3 valószínűleg más tészta. Az irány itt sem lenne rossz, de a gyártók listáját végignézve a 90% teljesen ismeretlen, a maradék egy részét kizártam. Felmerült az EATON, mint lehetséges köztes megoldás, de a honlapjuk, a magyar is és az angol is még a normális beetetéshez szükséges információkat sem tartalmazza.
Most megnéztem az RS-nél, az alap SIEMENS HMI 100 000 körül van. Nem bagatell, de simán kifizethető. -
#9019
Professzore
csendes tag
Professzore
csendes tag
Üdv mindenkinek,
Kis ötletbörzét tartanék, engedelmetekkel. Folyamatban lévő tanfolyam kereteit kezdem (khm., kb. a 0. perctől kezdve) kini, de ettől még a látásmód és pár jó ötlet miatt nyilván maradok a végéig. Meg azért komolyan is gondolom. De...
Elgondokodtam saját úton járáson hardver tekintetében, így sok (20+) órát bíbelődtem azzal, hogy értelmes gyártók értelmes termékpalettáját összehasonlítottam egymással, de csak első lépéseken és felismeréseken vagyok túl, odáig nem jutottam el, hogy elkötelezzem magam.
Elsőre a cél: alapvetően tanulás, tapasztalatszerzés, alap projektek megvalósítása (vízkezelő berendezéstől kezdve automata esővízelosztástól kezdve automatizált ipari csarnokvilágításig). Ipari gépeket, gyártósorokat egyelőre csak érintőlegesen, ha lesz rá igény, a tapasztalat alapján gyorsan fogok tudni betanulni. Az eszköznek tehát modulárisnak, bővíthetőnek kell lennie, a nagyon nagy ipari rendszerek együttműködési/kommunikációs varázslatai nélkül. Ötven körüli nagyságrendig bővíthető ki- és bemenetek, köztük analóg is (bemenet mindenképp, valós vagy pwm analóg kimenet jó opció). Boldog lennék, ha a PLC-hez adnának szoftvert, de pár tízezer forint évente bőven belefér (több is, ha van értelme és potenciálja). HMI egyelőre nem szempont, de később az lehet.
Eddig eljutottam:
+ WAGO (PFC200-ason tanulunk): sok szempontból overkill, de mindenesetre istentelenül drága, az itthoni képviselet ilyen igénnyel kinevet, eddig "csak" három e-mailre nem válaszoltak. Egy PFC100-as szettet elvileg fél millió alatt össze tudnék rakni "szinte" mindennel, de nem vagyok meggyőződve róla, hogy jó választás.
+ Siemens: S5 és S7 egyértelműen overkill-közeli, de sokan használják és szeretik, árakat nem találtam, de félek, hogy pariban van a Wago-val, illetve az tántorít el, hogy elképesztően nagy a választék és nem magától értetődő a kiválasztási folyamat. Alternatíva lehetne a LOGO, de az külső relékkel körülményes(ebben) használható, nagyon alap és nagyon szűken bővíthető.
+ ABB: teljes overkill, itthon nagyon nem látom nyomukat. Az AC500-eCo rokonszenves lenne, pár szép megoldása van.
+ Allen-Bradley/Rockwell: mint az ABB.
+ Rievtech: nekem súlyosan "kínai" érzésem van vele kapcsolatban, ezen kívül sima relés kimeneteket kínál alap esetben, az meg sok dologra jó, de többmindenre nem, ami a listámon célként van.
+ Omron: ahogy néztem, elsősorban motormeghajtásra van kitalálva, nem nyerő.
+ LOXONE: inkább épület (otthon) automatizálás, abban erősek, de most nem ez a cél.
+ Beckhoff: A CX7000/CX8000 első blikkre tök jó lenne, de a Windows valahogy hidegrázás. Árakat nem tudok, a használt piacon egész barátságosak.
Nyilván felmerült (suliban ajánlották), hogy hát milyen nagyszerű az OpenPLC platform. Eltöltöttem pár évet Arduino közelében és mostanra oda jutottam, hogy sikítófrász közepette menekülök tőle. Attól meg, hogy egy LD-ből fordít egy arduino-szerű kódot, amit linkel meglévő arduino könyvtárakból és működő arduino kódokból, majd ezt használja, attól engem konkrétan kiver a víz. Nem tudom komolyan venni.
Itt tartok. A fő kérdés, hova, pontosabban melyik rendszer felé tovább?
A fentiekben bizonyára van sok tájékozatlanság és hiba, nyugodtan cincáljátok, pláne, ha konstruktív.
Üdv,
Prof
(Elrakom a "ha máshogy nem megy, legyen így" fiókba. 
)
Új hozzászólás Aktív témák
- Autós topik
- Samsung kuponkunyeráló
- Android programozás, Android alkalmazások készítése
- CES 2026: Látható gyűrődés nélküli hajlítható kijelzőt hozott a Samsung
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Jövedelem
- Linux felhasználók OFF topikja
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Célegyenesben a Yettel TV
- Tarr Kft. kábeltv, internet, telefon
- További aktív témák...
- Samsung S24D330 FullHD monitor, számlával!
- Csere-Beszamitás! Playstation 5 Slim Disc Edition! Lemezes
- Gamer PC-Számítógép! Csere-Beszámítás! I7 10700 / 32GB DDR4 / RX 6700XT 12GB / 512 SSD + 1TB HDD
- Samsung Galaxy A33 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- 176 - Lenovo Legion Pro 7 (16IAX10H) - Intel Core U9 275HX, RTX 5080 (ELKELT)
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest