Új hozzászólás Aktív témák
-
Szirty
őstag
válasz
#95092224
#827
üzenetére
Hali topsli!
Nem igazán világos milyen PLC-vel akarsz kommunikálni milyen HW megoldással.
"(újabb típusú) PLC" mit takar?Ha a PLC gyári, akkor annak mindig van valamilyen konkrét, kész kommunikációs lehetősége (soknak több is). Ezek valamelyikét érdemes felhasználni.
Ilyenkor viszont a kommunikáció részletei adottak (nem te határozod meg őket). -
And
veterán
válasz
#95092224
#827
üzenetére
"Erre tippeltem HW alapnak (jó? / rossz?)"
Az biztos, hogy nem digitális I/O-modulokon cserélnék adatokat egy számítógéppel. Persze ez nyilván attól is függ, hogy miféle és mennyi adatot szeretnénk továbbitani, és melyik irányba. (Pl. egyetlen kontaktus kedvéért lehet, hogy nem bonyolítanám túl én sem, és a PC-re valami egyszerű porton / hardveren keresztül vinném). A digitális I/O nem erre való, a különféle - szokásosan - soros kommunikációs vonalakat meg épp adatcserére találták ki
. Sok PLC-n már alapban is van valamilyen adatport, vagy olcsón bővíthetőek ilyesmivel. Ezek némelyike hardveresen egyszerűen (interfészen keresztül, de akár közvetlenül is) összehozható egy számítógéppel. Ilyen lehet pl. az RS232, RS422/RS485-alapú protokollok (pl. modbus), vagy mostanában az ethernet (pl. modbus over TCP/IP), hogy a különféle gyártók háziszabványait ne is említsem. Modbus TCP-vel pl. viszonylag egyszerűen megoldható a PLC memóriacímeinek (regisztereinek) közvetlen irása, olvasása, és az egy 'számítógépesnek' sem olyan emészthetetlen. Azt persze nem említetted, hogy miféle PLC lenne az alany, esetleg már adott, vagy még csak most kell kiépíteni a rendszert. -
Szirty
őstag
válasz
#95092224
#830
üzenetére
Hali topsli!
"Vegyünk alapul egy siemens s7-est, amibe semmi ilyen nincs beépítve."
Milyen S7? 200? 300/400?
Amennyire én tudom minden S7-ben alapból van valamilyen kommunikációs lehetőség (PPI/MPI/Profibus)."Ami modbus/profibus van is benne, az más célra már használatban van."
Ha van benne profibus, azt használhatod kommunikációra amellett is, hogy már használatban van. A profibus-nál nem okoz problémát ha rákötsz még egy PC-t is.
-
Szirty
őstag
válasz
#95092224
#874
üzenetére
Hali topsli!
"Általánosságban érdekelne tapasztalat PLC részegységeket illetően, hogy mennyire általános, illetve ritka dolog egy részegységnél, hogy az egyébként egyenáramú tápkábelt nem megadott polaritással, hanem akár fordított polaritással is be lehet kötni."
Erre általános választ lehet csak adni: van amelyik elviseli, mert van benne védelem. Azaz nem megy tönkre fordított polaritással, de nme is működik. Van amelyik azonnal elszáll és van amelyik zavartalanul működik tetszőleges polaritással.
Pl. a kapcsoló üzemű tápegységek egy része képes AC DC forrásról üzemelni. Ezeknél DC táplálás esetén mindegy a polaritás, működik.
Vagy egy izzólámoának is mindegy
Vannak induktív érzékelők amelyeknél az dönti el hogy PnP vagy NpN kimenetű lesz e, hogy milyen polaritással kötjük rá a tápfeszt.
Az ilyen tulajdonság mindig szerepel az adatlapon vagy a techspec-ben. Ha nincs jelölve hogy polaritásvédett vagy hogy megy AC forrásról illetve fordított polaritásról, akkor nem is szabad megpróbálni azt.Összességében úgy gondolom, az eszközök túlnyomó többsége nem bolond biztos ilyen szempontból...
(Végig se merem gondolni mi ihlette ezt a kérdést :> ) -
Szirty
őstag
válasz
#95092224
#876
üzenetére
Hali topsli!
"Annyi a gond, hogy a bemenetre kell egy diódahíd. Ha az egész dobozolás alapvetően műanyag, vagy legalábbis kettős szigetelésű, és nincs galván kapcsolat a házzal még akkor se, ha fém, akkor a betáp GND-nek nem muszáj feltétlenül 0 volt potenciálnak lennie."
Pedig az viszont elég általános, hogy a GND 0V-ra van kötve.
Igen a tápfesz bemenet oldalánál lévő diódahíd, ami visszafordítja a fordított tápfeszt nem jó ha a kimenetek nem leválasztottak, hiszen a kimenetek GND-je közös a bemenő tápfesz GND-jével, ahogy írtad is.
Én sem javaslom ezt a megoldást.
De jó kompromisszum lehet egy soros védődióda a tápellátás + oldalán. Nem fog ugyan működni fordított fesszel, de legalább nem megy tönkre. -
Szirty
őstag
válasz
#95092224
#900
üzenetére
Helló topsli
"Az általánosat úgy értem, hogy magyarországi gyakorlatban (úgy egészében statisztikai átlag szintjén) mennyire komoly probléma, hogy valamilyen régi / olcsó / mit-tudom-én-miért-nem-jó típusú plc-t akarnak összekötni számítógéppel, és nem csak nincsen rá kiépített lehetőség, hanem szakember se tud rá javaslatot tenni."
Régi 10-20 évvel ezelőtti (tehát 10-20 éve kifutott) vezérlésekkel bizony előfordul ilyen probléma. A PC-vezérlő közötti kapcsolat főként azért szokott nehéz lenni, mert a hozzá szükséges szoftver már nehezen elérhető és ha meg is van, nem biztos hogy a mai PC-ken egyszerű elindítani 1992-es DOS-os szoftvert hogy még kommunikáljon is RS232-n.
Pláne hogy mai notebookokon már RS232 sincs, Windows alatt indított DOS session USB-s RS232-vel rendszerint szinte teljesen esélytelen, natív DOS-nak nem túl nagy barátja az USB..."Sőt, talán management szintjén is felvetődhet a probléma, hogy elmaradott a termelési logisztika. Az a probléma pld hamarabb kezdi majd el csípni a főnök szemét."
Ez teljesen általános. A menedzsmentet nem érdeklik a műszaki problémák részéletei. A műszaki problémákat meg kell oldani, lehetőleg ingyem és azonnal! "Ti azért vagytok" kb ez a hozzáállás.
Sokszor nehezen értik meg, hogy egy motorvédőt visszakapcsolni nem ugyanaz a probléma (műszakilag) mint pótolni egy PLC elveszett programját, amiről nincs mentés...
Az is nehezen szokott menni, hogy a műszaki problémák gyors és hatáékony megoldásához elengedhetetlen körülmépnyeket biztosítsák. (megfelelő szoftverek, eszzközök és anyagok). Azt szeretik ha megdrótozzuk és hadmenjen!Visszatérve a régi gépek problémájára:
Nem csak az a probléma, hogy 20 éves PLC-hez nincs szoftver vagy éppen kábel. Ha ezek vannak is, az akkor is gyakran gond, hogy a géphez nincs semmi dokumentáció, rajz. Nem lehet tudni hogy melyik PLC ki és bemenet mit csinál, stb. Ilyen körülmények között nehéz és hosszadalmas hibát keresni. -
Szirty
őstag
válasz
#95092224
#904
üzenetére
Szevasz topsli!
"Összefoglalva egy ethernetes jelvezeték konverter lesz. Fő szempont az volt, hogy olcsó legyen (áfás áron 20 rugó alatt marad)."
Ennél konkrétabban kellene. Így csak sejtem mi lehet ez.
"Szóval amin jár az agyam, hogy kifelejtettem-e valamit a listáról, amire még gondolhatnék, és ami sokat segítene majd a jövőben, hogy könnyebb legyen egy elkészített eszköznek piacot bővíteni."
Pl. hogy itt konkrétan mire is gondolsz.
"Ja igen, a célpiacok sorában nyilván nem szerepel majd az a cég, ahol egyben kipengetnek 100milcsit"
Az élet nem ennyire fekete és fehér...
-
Szirty
őstag
válasz
#95092224
#904
üzenetére
Hali topsli!
Nyilván nehéz a felfogásom, de még mindig csak igen érintőlegesen van fogalmam róla hogy konkrétan mi is ez az eszköz és konkrétan mire való és mit tud. A kérdéseidre nem is igazán lehet választ adni, mert nem is igazán kérdések.
Persze beszélhetünk róla, mert miért ne? De ha semmi konkrét dolog nem hangzik el, akkor kevés információ tartalma lesz."Második szempont az volt, hogy semmiféle kevert ismeretet ne követeljen meg a felhasználása. Szét kellett választani, hogy a PLC-t is, és a számítógépet is csak a saját szakija programozza, és egymás munkájához ne kelljen érteniük."
Tehát lényegében nem bánod ha a titkárnők csavarhúzóval szaladgálnak.
A gyártók szoktak törekedni arra, hogy a kütyüik univerzálisak legyenek és bárki tudja használni pilótavizsga nélkül is. Van amikor nem sikerül ezt elérni.
Ha valami univerzális, akkor bonyolult lesz, ha viszont egyszerű, akkor korlátozott. (és itt nem a csapágygolyóra vagy a fakockára gondolok).
A két dolog rendszerint ellentmondásban van egymással így nem nagyon lehet mindkettőnek egyszerre megfelelni.
Ha valaki valamihez nem ért, akkor tanulja meg (vagy ne csinálja). És ez igaz az automata mosógép kezelésére is). -
Szirty
őstag
válasz
#95092224
#910
üzenetére
Hali topsli!
"Nosza, filozom. Pár fotót felleltem neten szerelési szekrény belsőkről. Dugaszolósra éppen nem sikerült példát találnom, de ez csak eseti véletlen is lehet. Egy átlag szaki kényelmesebbnek tartja a fix modellt? Vagy a dugaszolóst tarthatják igazából kényelmesebbnek? Esetleg a dugaszolós szerelést felesleges körülményeskedésnek tartják?"
Használják mindkettőt. Én a magam részéről jobban szeretem a csatlakozósat. Ilyenek gyakoriak pl. frekvenciaváltókban, biztonsági relékben, panelműszerekben, PLC-kben.
Arra érdemes figyelni, hogy ha több egyforma pin számú van, akkor ne lehessen felcserélni őket (a szaki oda dugja be ahova bemegy)... -
Dezsi82
tag
válasz
#95092224
#961
üzenetére
Hali!
Szerintem civil célnál az ár a döntő szempont. MiniPC árakban nem vagyok jártas , de pl ha nem kell kijelző (mint mondjuk egy öntöző rendszernél) akkor jóval olcsóbb mondjuk vaterán egy használt PLC. Másrészről meg talán aki mondjuk PLC programozásban jártas, szívesebben használ PLC-t mint hogy PCre fejlesszen egy vezérlő szoftvert, és azt is meg kelljen tanulnia. Illetve aki PLCkkel foglalkozik (márpedig iparban ez a döntő) az lehet tud "kamionról leesett" PLCt
De én például használtam már iparban PC-t vezérlésre, és az is stabil, ha nem raknak rá hülyeségeket, és arra használják, amire kell. Az ellenkező ellen meg tudok védekezni. Bár az is igaz, hogy nem csinál semmi veszélyeset. Ha tudna emberben kárt tenni, biztos nem bíztam volna PCre. -
Szirty
őstag
válasz
#95092224
#961
üzenetére
Helló topsli!
"Bocsi, hogy így belekotyogok a dolgokba, de miért is kell mindenre PLC-t használni? "
Azt ki írta, vagy mondta, hogy mindenre azt kell használni.
Szó sincs róla. Mindenre azt kell használni (lehetőleg) amire való. Mert úgy hatékony."mi baj van az ipari miniPC-kkel? "
Semmi, ha arra használják őket, amire azok valók.
-
Dezsi82
tag
válasz
#95092224
#975
üzenetére
Hali!
A diagnostic interrupt azt jelenti, hogy ha diagnosztizálható esemény van, akkor meghívja az OB82-t. Annak a paramétereiben, pedig le tudod kérdezni, hogy mi történt.
Az, hogy ez megtörténik-e, ha rövidzárlat van, azt nem tudom. Sosem próbáltam
Amennyire jól emlékszem a Siemens-es modulok rövidzár védettek, de hogy ez, meddig, és hogyan. azt nem tudom.
-
Szirty
őstag
válasz
#95092224
#993
üzenetére
Hali topsli!
"A pic is szemantikailag egy teljes értékű számítógép, noha csak egyetlen áramköri tok az egész, mégsem gondolok rá számítógépként. Te hogy vagy vele?"
Úgy vagyok vele hogy nem kívánok a "számítógép" fogalmának definíciójáról vitát nyitni.
Legyen elég annyi, amennyinek a téma kapcsán már egyértelműen ki kellett volna derülnie: a számítógép nem feltétlenül egy x86 PC monitorral és billentyűzettel...
Egyébként kérdezd Dezsi82-t mi az a számítógép. Ő írta hogy minden robotot számítógép vezérel... -
Szirty
őstag
válasz
#95092224
#998
üzenetére
Hali topsli!
"Egy PLC-vel is ez a helyzet. Időkritikus alkalmazásra termett, nem absztrakt munkavégzésre. Egy PC-hez képest a PLC csupán periféria."
Én úgy gondolom, hogy a periféria fogalma alárendeltségi viszonyt is jelent.
Mi leggyakrabban PC-t PLC közelében kijelzési (HMI) feladatok ellátására használunk.
Vagyis arra, hogy a PLC-vel kommunikálva lehetővé tegyen beállításokat a PLC-ben keletkező üzeneteket jelenítsen meg, stb.
Akkor ott a PC a PLC perifériája?"Némelyik PLC-nek PIC12C magja van, mint időközben megtudtam: összteljesítményét tekintve iszonyúan gyengusz egy típus."
Közepes vagy nagyobb teljesÍtményű PLC-kben a proc. is nagyobb. S7-300 CPU315-2 PN/DP-ben pl. Infineon Tricore van:
-
-
Szirty
őstag
válasz
#95092224
#1003
üzenetére
Helló topsli!
"Az a felsőbbik szint, ami a közvetlenebb emberi kommunikációt teszi lehetővé. Az időkritikus folyamat végrehajtás az absztraktabb szint alatt van, és a képernyőre kiírt adat is felsőbbrendűbb információ, mint a PLC memóriája."
Nézőpont kérdése.
Az irodában, excel tábla előtt ülő gazdasági munkatárs által használt rendszer legfontosabb (elsődleges) célja a képernyőn, az ember számára megjelenő információ megjelenítése.
Egy gyártási folyamatban résztvevő berendezés elsődleges célja a produktum. A munka aminek az elvégzésére létrehozták és amiért üzemeltetik.Azt pedig, hogy ez filozófiailag többszörös áttételen keresztül hogyan köthető az emberhez, lehet máshogy is magyarázni, de az nem az én asztalom.
-
Dezsi82
tag
válasz
#95092224
#1016
üzenetére
Hali!
Időközben letöltöttem a leírást, és abban az van, hogy ha nincs bepipálva az "include project file" feltöltésnél, akkor nem tudom visszaolvasni sem.
Ahogy néztem, alapként be van pipálva. Remélem nem volt memóriahiányuk, és bekapcsolva hagyták.
Azért köszi.
A .Net-et még nem használtam, csak nézegettem. Akkor az nem exe-t csinál? Valami olyasmi, mint a java?[ Szerkesztve ]
-
#95904256
törölt tag
válasz
#95092224
#1194
üzenetére
Hali!
Már két megoldásom is van. Egyik, hogy nem a CPU-ba integrált ethernet egységet használom, hanem egy külön modult. A másik a soros port - ethernet átalakítás. Ez utóbbi célra bőven megfelel egy Atom processzoros kártyaPC. Sőt ez utóbbi megoldás még olcsóbb is, mert a PLC CPU-jának alapból is van egy soros portja, így nem kell méregdrága kommunikációs modult venni. A protokoll megírása meg gyorsabb is PC-re, mint a PLC-re.
-
Marty76
csendes tag
válasz
#95092224
#1209
üzenetére
Szia topsli !
Konkrétan, egy taiwani ( APHA
) plc-ből kellene kiolvasni az adatokat. A plc egyedi fejlesztésű és kereskedelmi forgalomba nem kapható és kizárólag csak a taiwani cég ( Zitai)által gyártott nyomásos alu. öntőgépekben található meg.
Maga a PLC egy DS80C320-as microcontroller köré épített egység. Rendelkezik 2db párhuzamos RS232 porttal , amiből az egyik egy ipari, beépített PC-vel kommunikál.A Taiwan-i cég készített egy egyedi HMI programot, amin a gépi funkciókat lehet kezelni. Az összes adat ( decimális, bináris), amit a HMI programon beviszek egy CSV fájlban van tárolva. A csv. fájl D100...D999 tárol adatokat, ami a közös pont a PLC és a pc-n futó szoftver között. Ezek a D paraméterek egy az egyben jelen vannak a plc-ben és szabadon módosítható és változtatható. Maga a plc program nagyon leegyszerűsített és csak szöveges sorokból tudom programozni.
Maga a probléma ,amit meg kellene oldani...
A HMI programot nem áll módomban módosítani jogosultság híján. Nem tudok új beviteli mezőt létrehozni vagy akár a beviteli mező tulajdonságát változtatni de legfőképpen adatokat nem tudok kivenni a plcből.
Kérdés...
Tudnák írni egy új HMI programot, de hogy tudnám kibogozni , azt hogy mi jön át a plc-ből RS232-ön? Hogyan kellene ehhez hozzá kezdenem? Milyen programmal?
Köszi!
-
Marty76
csendes tag
válasz
#95092224
#1221
üzenetére
Szia!
Amikor adatgyűjtésről beszélünk, akkor az a cél termelési magas szinten, hogy a gépek által már elvégzett munkát - mint statisztikai adatot - real-time eljuttassuk egy központi szerverbe.
Igen ez pontosan így van, de sok félképen kivitelezhető. Itt jelen esetben a gépbe beépített PC-n ( http://www.advantech.eu/products/search.aspx?keyword=ppc-103t) minden ciklusban készül egy txt. fájl a kiadott paraméterekkel ( ciklusidő, pogácsaméret, sebesség stc.) Ez a txt. fájl van beforgatva adattá egy VB progival excel-be. Elég kezdetleges,de ezen dolgozunk!Az egyedi konstrukciód úgy néz ki, hogy a taiwani pajtás fogott egy mini pc-t, gyártott egy külön kis mikrokontrolleres áramkört, a kettőt soros porton összekapcsolta, és ezt az egységet egyetlen dobozba pakolva elnevezte a végeredményt valami akármi PLC-nek. Szólj rám ha ezt rosszul vettem ki soraidból.
Igen ez jól érted, de végeredmény egy PLC az szó legteljesebb értelmében. ( ha úgy vesszük ez az összes plcről elmondható legyen az omron, siemens ).Te szétbontanád a dobozt, és lecserélnéd a beépített mini pc saját vezérlését egy saját magad által készített központi vezérléssel.
Nem! Én a jelenlegi PC-n futó egyedi megjelenítőt programot cserélném le olyanra , amit mi saját magunk tudunk kialakítani és módosítani. Azt hogy az adatokból msql adatbázist csinálnánk és azt mondjuk PHP-val webes felületre raknák az már csak hab a tortán lenne. De minden megoldás érdekelne amivel "egyszerűen" tudnák adatokat fogadni és küldeni a PLC-vel.
(B)Itt egy kép a jelenlegi HMI programról
/B)
[ Szerkesztve ]
-
Marty76
csendes tag
válasz
#95092224
#1226
üzenetére
Sziasztok!
Arra jutottam, hogy ez így borzasztó sok időbe telne mire kibogoznám mi-mit jelent.
Arra gondoltam, hogy egy kisebb omron plc-vel fogok kommunikálni ezzel a taiwani plc-vel, I/O-kon keresztül
Viszont az Omron plc-vel kellene kommunikálni RS232-ön keresztül úgy, hogy a meglévő pc-re készítenénk egy HMI szoftvert. Van valakinek már ilyesféle- fajta tapasztalata, mai el tudnák indulni?!Üdv.
-
izriot
tag
válasz
#95092224
#1515
üzenetére
Ezek hőmennyiség számítóműk, amikre becsatlakozik 2db PT100/PT500 és egy áramlástávadó, amiből a hőcserélő primer ágából felvett gépészeti kWh adatot számít. A műszer összes része a szekunder ágban van. Erről távkapcsolaton jó volna a számítómű megkapott pillanatnyi értékeit és a számított értékek pillanatnyi és integrált értékét is kiolvasni, no meg ha lehet paraméterezni rajta valamit, akkor azt is jó volna tudni (bár elég behatároltan lehet csak sztem, mert elszámolásról van szó).
A legjobb a wifi/URH volna, de csak ezekkel a kimenetekkel lehet rendelni. Meg ugye a 4...20mA, ami tök jó, ha megunom a banánt, mert azzal a pillanatnyi számított értéket el tudom hozni, a PLC meg majd integrálja, de a 2 hőmérséklet távadó meg az áramlástávadó jelét is akkor külön kell behozni, ami megint hülyén néz ki.
Szóval a wifihez, meg amihez te mondasz, ahhoz is kellene megint egy külön átalakító, ami gondolom szintén csillióforintos tétel. Mert gányolást ugye nem akarok kiírni, csak komplett, azonnal megvehető műszert, ami egyből azt tudja, amit kell. Aztán ha a kivitelező meg tudja oldani olcsóbban, amit a megrendelő is elfogad, hát legyen, az már nem az én dolgom. -
sörösló
aktív tag
-
sörösló
aktív tag
válasz
#95092224
#1844
üzenetére
Amennyire én tudom, a modbus csak egy kommunikációs protokoll, amit anno az ős-Modicon plc rendszerhez fejlesztettek. Nem plc programnyelv! Stabil ipari cucc, talán ezért használják még ma is. Az Omron CX-One alapból kezeli, sőt mindenféle új cucchoz is kínál modbus kommunikációt. Ez az alapkommunikáció még a Schneider legújabb vezérlőihez is. Persze már nem RS 232-re írják, de a lényeg ugyanaz. Olyan ez, mint a Siemens S-5 plc-je. A Siemensnél valszeg már azt is letagadják hogy valaha ismerték azt az embert aki fejlesztette. Túl jól sikerült, olyan mint billygecynek az XP. Ajánlanak helyette minden jót de csak nem akar kimúlni a piszok! Lehet, hogy már az S-9xx-et ajánlgatják az S-7 helyett, amikor még belefuthatsz majd egy-egy ottfelejtett S-5-be.
-
Szirty
őstag
válasz
#95092224
#1844
üzenetére
Hali topsli!
"Milyen szélességű adatokat kezelnek? 16 vagy 64 biteseket?"
Főleg egy bites adatokat kezelnek. Ez a fő erősségük, és az alap feladatokhoz (amire a PLC-ket szánták) pontosan erre van szükség.
De pl. S7 300/400 közvetlenül kezeli a köv. bitszélességű típusokat:Bool (1bit)
Byte (8bit)
Integer, Word (16 bit)
DWord, DInt, REAL (32 bit)Nem tudom ez a kérdés miért fontos, de megjegyezném, hogy a bitek száma kb annyira jelent "minőségbeli" különbséget is a számmal együtt, mint amekkora minőségbeli különbség van az alacsony és magasabb szintű programozási nyelvek között (tehát kvázi semennyire)..
-
Szirty
őstag
válasz
#95092224
#1847
üzenetére
Hali topsli!
"Arra gondolok, megcsinál-e olyat automatikusan, hogy lebontja a 32 bites adatot kettő 16 bitesre, és azokat kiírja a (regiszter cím) címre (alsó 16 bit), és a (regiszter cím+1) címre (felső 16 bit)? Létezik ilyen nyelvi tulajdonság?"
Olyan tulajdonság létezik, hogy ha egy 32 bites adatot írsz egy olyan "valamibe", ami kisebb, mondjuk 16 bites, akkor automatikusan a 32 bites adat alsó részért írja bele, a felső 16 bitet levágja.
Ha két külön 16 bites "valamibe" akarod beleírni a 32 bitet és a két 16 bites rész egymást követő címen van, akkor 32 bites célként egyszerre is beleírható a két 16 bites célba a 32 bites adat mindkét fele.
Ha a két 16 bites "valami" nem egymást követő címen van, akkor ezekbe a 32 bites forrás adat két 16 bites felét csak 3 lépésben lehet kiírni a két 16 bites cél "valamibe". -
Szirty
őstag
válasz
#95092224
#1848
üzenetére
Hali!
"Majd mindjárt elkezdem sajnálni a Siemens-t "
Erre nyilván nagyon nagy szükségük lenne :>
Szerintem (a válaszodból ítélve) félreértetted a lényeget, mert a hangsúly nem a siemens néven van.
A lényeg szerintem az volt, hogy van egy régi cucc, ami nagyon bevált, igen megbízható és évtizedekig működik. Történetesen ez siemens gyártmány.
Mindez nem zárja ki, hogy ilyet más gyártó is alkotott (és nyilván alkotott is)... -
Szirty
őstag
válasz
#95092224
#1851
üzenetére
Hali topsli!
Nekem úgy tűnik, hogy a felhasználóra bízza, hogy a türelmi idő mekkorára van szabva.
Mivel a ModBus egy ipari kommunikációs eljárás, gondolom az lenne a jó, ha determinisztikus lenne.Gondolok itt arra, hogy a független folyamatoknak zavartalanul mennie kell tovább, csak azt az egy folyamat ágat le kell stoppolni.
Ez általában nem így működik. Csináljon bármit is a kommunikáció, a program zavartalanul fut tovább (már ha a "folyamat" szót a programra és nem a program által vezérelt folyamatra értetted).
Persze a kommunikáció késésének vagy hiányának nyilvánvalóan lesz valamilyen következménye, de nem a program szintjén. Tehát a program nem fogja azt "várni" hogy addig ott ácsorogjon. -
Szirty
őstag
válasz
#95092224
#1855
üzenetére
Szevasz topsli!
"Ami példát láttam utasítás listás garázsajtó vezérlésre pld, annak a szerkezete nem hasonlít sem egy C programra, de még egy VHDL kódra sem. "
Mert egyik sem arra való, amire egy PLC STL nyelve. Ezért nem nagyon hasonlít rá. Pl. ha teljesen úgy nézne ki mint a C, akkor C lenne
(Ha valami úgy mozog mint egy kacsa, olyan tollas mint egy kacsa, úgy hápog mint egy kacsa, akkor az egy kacsa).
"Ha mindezen tényleg keresztül akarom rágni magam, cirka mennyi pénzembe fog kerülni, és durván hány oldalnyi doksit kellene megemésztenem?"
Ezt így elég nehéz megbecsülni.
Attól is függ, hogy milyen PLC-vel akarsz foglalkozni. Hogyan szerzel szoftvereket hozzá. Bizonyos PLC-hez "ingyenes" máshoz nem. Milyen HW elemeket akarsz venni stb.
Ha nincs vezérléstechnikai háttered, akkor kicsit lassabban fog menni. Többet kell olvasni és káromkodni. Egy PLC-t programozni eléggé (nagyon) más, mint PC-re C-ben windows alá megírni valamit. Máshogy kell gondolkozni.
Meg mennyire gondolod komolyan. Egyetlen feladatért, általában nem érdemes megtanulni, kivéve ha:
- Elképzelhető, hogy több ilyen feladat is lesz
- Elképesztően sokat fizet
- Fanatikus vagy és nagyon érdekel a témaMennyi doksit kellene megemészteni? Attól függ hova akarsz eljutni és mivel.
Olyan biztos nem lesz, hogy elkezded megtanulni, és egyszercsak egy szép napsütéses szerda délelőtt eljön a pillanat, amikor azt mondod, hogy na megtanultam.
Én pl. a mai napig sok-sok doksit olvasok és sokat tanulok a témában, mert mindig van valami olyan, amivel azelőtt nem foglalkoztam (ez egyébként igen változatossá tudja tenni ezt a munkát). -
Szirty
őstag
válasz
#95092224
#1859
üzenetére
Hali topsli!
"Bármiféle szabványosított scriptes vagy akármilyen előredefiniált utasítás készlete is van a PLC-knek, az a jelek szerint egy kicsit sem publikus."
Ilyen nem létezik. Ezt nem szabványosították. Minden gyártó kitalált egyet és azt használja. Ezek olykor alapvetően eltérnek egymástól. Ráadásul nem is ugyanúgy hívják őket. (Statement list, Instruction list, Mnemonic list, stb).
Az én észrevételeim a kérdéshez amit vázoltál.
"ne lehessen simán csak folytatni" Ez az első probléma. A termelés (mennyiség) az esetek 99%-ában elsődleges. Minden gyárban jellemző, hogy komoly erőfeszítéseket tesznek annak érdekében, hogy lefaragják az állás időt (az alló gép a világ legdrágább gépe). Ezzel az intézkedéssel viszont növelnéd azt."adjon a gép kezelője egy 5-6 soros listát kiírva"
A másik probléma, hogy tapasztalatim szerint egy komplexebb gépen (tehát ahol nem egy motor van, amit két feltétel indít) egy leállás vagy hibaesemény oka hihetetlenül sokféle lehet. Nem hogy 5-6 sorban, de 5-6 oldalon sem lehetne felsorolni azokat. Persze redukálhatod ezeket, és általánosíthatsz az okok megfogalmazásánál, csakhogy ezzel pontatlanná teszed az eredményt. Ha viszont sok választási lehetőséget adsz a kezelőnek, akkor inkonzisztens lesz az eredmény és időigényes lesz a választás.A harmadik probléma, hogy ezzel a megoldással emberi tényezőz vonsz bele a dologba, ami egy gyártási folyamatban soha nem jó (hacsak nem a káosz kialakítása a cél
Pl.: A kezelő egy idő után hiba miatti leállás esetén a listában várhatóan a következő szempontok szerint fog választani: "magasról leszarom", "qrvaanyját" stb, stb. -
sörösló
aktív tag
válasz
#95092224
#1857
üzenetére
Ejnye lássunk már valami kézzelfoghatóbbat. Mondjuk egy fejlesztői környezet összepakolást.
Ha viszonylag egyszerű ismerkedést akarsz, ajánlanám figyelmedbe az Unitronics Vision sorának valamelyik tagját. Van benne HMI, CPU, IO. A programnyelv egyszerű,
a fejlesztőszoftvert és a kábelt ingyen adják. Részletes a Help (angol nyelven) és ha a Kwalix-tól veszed, szakmai kérdéseidre preciz válaszokat kaphatsz. Funkcióblokkban előprogramozva nagyon sokféle kommunikációt tud, többek között Modbus-t is. A Plc-k világával belépőszinten ismerkedni tök megfelelő. Mondjuk ez sem ingyé van, de a legegyszerűbbet 120-140 rugó körül megkapod. A szoftver letölthető a netről is, nem kell hozzá semmit venni. Az is igaz viszont, hogy bármit tesztelni csak online lehet, tehát mindenképpen kell egy szerkezet a gyakorlati munkához.
A többihez meg csak ennyi: Egy kábel miért kerül 21 rugóba? Miért kerül pénzbe a fejlesztőkörnyezet? Miért csak vásárlás után juthatsz többletinformációhoz? Hát mert csak! -
sörösló
aktív tag
válasz
#95092224
#1859
üzenetére
Szirty-nek tök igaza van. Nálunk működik hasonló rendszer, de függetlenül a géptől. Van telepítve külön a gépen egy adatgyűjtés, regisztrálja a bekapcsolást, a termelési sebességet, darabszámot, állásidőt, a kezelő kódját, meg amit akarsz. A megállás okait egy listán összefoglalva, vonalkóddal ellátva kiakasztják a gép oldalára, ahonnan a kezelő egy kézi eszközzel beolvastatja az állás okát. A gép nem áll meg, használható tovább, de a felügyeleti redszer megjegyzi, hogy nem lett az állásidő oka regisztrálva. Magyarul a gépvezető bevette a Leszarom tablettát. Az viszont a főnökség dolga, hogy ebben az esetben alkalmaz e valamilyen retorziót vagy sem.
-
sörösló
aktív tag
válasz
#95092224
#1864
üzenetére
Nem tudom biztosan, hülyeségeket írni meg nem szeretek, de én a helyedben nem nagyon piszkálnám a Fanuc vezérlőket. Ha célirányosan szerszámgépvezérlő, akkor a programnyelve valszeg köszönőviszonyban sincs azzal a problémával, amire használni szeretnéd. Ok hogy 64 bit meg számítógép. Nálunk is mennek Pentium 4-es meg kétmagos procis gépek ipari vezérlő PC funkcióban. Nevetni fogsz ha elmondom, a P4-eseken DOS alapú a PLC program! Erre lett kifejlesztve, a hátteret adó hardwer meg tökmindegy. Gyorsabb gépen gyorsabban megy a DOS aztán annyi. Az XP-s gépeken meg a Siemens S7, Pro-Tool, Simodrive szervo és társaik. A futó program és a futtató hardver fügetlenek egymástól. Az S7-nek úgy látszik mindegy, hogy valódi PLC-n vagy IPC-n fut. A Fanuc meg nagyszerűen elboldogul egy marógép speciális vezérlőmatekjával, de egy egyszerű öntartó blokkra szerintem úgy nézne, mint boci az új kapura. Egyszerűen más a nyelve és a fogalomrendszere! Valszeg ezért független nálunk is a felügyeleti rendszer meg a gép vezérlése. A felügyeletet nem érdekli a gépvezérlő, legfeljebb néhány meglévő érzékelő jelét kéri kölcsön, ami meg nincs a gépen, azt a vezérléstől függetlenül fel kell szerelni. A felügyeleti infókat egy kis Beckhoff Plc gyűjti és továbbítja a központ szerverére.
-
sörösló
aktív tag
válasz
#95092224
#1864
üzenetére
Ja és még egy:
Tablet PC is van már ilyen áron, vagy legalábbis a kicsike fajta, csak azt meg széteszi az olaj ipari környezetben.
Nem tudom hol dolgozol, de ettől nem kell félned. A tablet PC-t nem tudod odahegeszteni a géphez, következésképpen már az összekoszolódás előtt ellopja valaki. Persze csupa jóindulatból hogy tönkre ne menjen!
-
-
Szirty
őstag
válasz
#95092224
#2479
üzenetére
Helló topsli!
"Ha olyat kellene megcsinálnom, mint fentebb említett példa, nevezetesen egy plc regisztereit kell olvasnom és írnom is annak működése közben, és mindezt a plc programjába való beavatkozás nélkül, általános jelleggel elmondható, hogy bármilyen profibuszra felcsatlakozott szabványos eszköz meg tud ilyet csinálni? "
Nem. Nem teheti meg bármilyen Profibuszra csatlakoztatott eszköz, csak amelyik erre képes, azaz erre fel van készítve, más szóval amelyiknek erre szüksége van.
Pl. egy remote I/O DP slave ilyet soha nem tesz. Nem tesz ilyet DP-s frekvenciaváltó sem szóval semmilyen DP slave. ha jól gondolom ez egyáltalán nem is a profibusz DP protokoll / kommunikáció része.
Egy profibuszra csatlakoztatott HMI nem DP slave és nem is DP master! Egy profibuszos HMI más protokollt használ a PLC-vel való kommunikációra, nem a profibusz DP-t, de a profibusz fizikai közegét használja a kommunikációra. megteheti, mert pl. siemens S7 a profibuszon egyszerre képes többféle protokollt is használni. Ez teszi lehetővé pl. hogy számítógépet csatlakoztassunk a profibuszra és így programozzuk a PLC-t, az sem a profibusz protokollon keresztül történik!
Mindebből az következik, hogy ha egy olyan profibuszos PLC rendszered van, amelyik csak DP kommunikációra képes a profibuszon keresztül, annál semmi olyasmit nem tehetsz meg, amiről írtál.Az egész dolog nem is köthető a profibuszhoz konkrétan éppen a fentiek miatt.
Hiszen pl. S7 rendszerben egy MPI buszra vagy ethernetre kötött HMI is képes a PLC regisztereit írni vagy olvasni és azokon keresztül is zavartalanul működni."Azon filozom, hogy a profibusz hálózaton belül nincsen valamiféle előre beállított védelem, hogy bizonyos eszközök bizonyos eszközökhöz nem férhetnek hozzá, mert a busz master a kezükre csap érte?"
A profibusz és egyéb terepi hálózatra kapcsolt eszközök egymáshoz való hozzáférhetősége nem korlátozások hiányának, hanem a lehetőség szándékos megteremtésének az eredménye!
A cél nem a kommunikáció korlátozása, hanem a kommunikáció lehetőségének a megteremtése!"Alapértelmezetten minden eszköz "megbízható"-nak van nyilvánítva, és bármelyik megtehet akármit?"
A terepi buszt használó eszközök tervezésekor igen komoly figyelmet fordítanak arra, hogy az eszköz minden tekintetben jól, a specifikációban pontosan meghatározott módon működjön a specifikációban meghatározott körülmények között.
ha nem így működnének, akkor ki lehetne őket dobni a kukába, mert hibás működésükkel teljes gyártósorok megbízhatóságát ásnák alá.Ha a megbízhatóságot azért kérdőjelezed meg, mert a fent említett korlátlan "nyíltság" lehetővé teszi, hogy eszközök vagy valakik azok segítségével esetleg illegális vagy szándékosan kártékony tevékenységet folytathatnak, akkor igazad van.
Bárkinek aki fizikailag hozzáfér egy terepi buszhoz lehetősége nyílik könnyedén hatalmas károkat okozni egy rendszerben azzal, hogy a buszra csatlakozik és regisztereket kezd el felülírni.
De ne felejtsük el, hogy ha már ott van (vagyis fizikailag hozzáfér) akkor ezt egy baltával még ennél is sokkal egyszerűbben megteheti!Az illegális behatolások, hekkerek, adathalászat stb ellen nem a terepi busz szintjén kell védekezni! A terepi busz és a rákapcsolódó eszközök közvetlen részei egy zárt automatizálási rendszernek.
Ilyen alapon kételkedhetnénk egy mezei analóg bemeneti modul, vagy a PLC-be dugott flash memória megbízhatóságában is, ami a "jó szándékot" illeti.Tehát nem elvetélt ötlet az, hogy HMI-t illesztesz egy PLC-hez, aminek a programját nem akarod megváltoztatni.
De ismerni nagyon kell azt a programot, mert ha írkálni kezd a HMI a PLC-be, akkor jó szándék ide vagy oda, bizony nem mindegy mit hova ír
Az adatok olvasásával kapcsolatban pedig tudni kell hogy az adat amit olvasni akarunk egyáltalán rendelkezésre áll-e a PLC-ben és ha igen mit kell kiolvasni és ami onnan jön azt hogyan kell értelmezni.
A PLC-nek nem kell hogy profibuszos legyen. Olyan legyen, aminek van szabad csatlakozási lehetősége HMI eszközhöz, legyen az profibusz is akár, vagy ethernet, vagy soros port. -
Szirty
őstag
válasz
#95092224
#2481
üzenetére
Hali topsli!
"Ipari környezetben annyira jól kiképezett szimulátor alkalmazások lennének, hogy ha hibásan van egy alkalmazás elkészítve, garantáltan észreveszik még a logikai butaságokat is?"
Majdnem mindig garantáltan észreveszik a butaságot. Leggyakrabban akkor, amikor a gép hülyeséget csinál, vagy épp semmit.
De ez sem mindig jön össze azonnal. Van, hogy a problémát egy hosszú feltételsor teljesülése szüli. Ilyenkor az "együtt állás" csak kis eséllyel, vagyis ritkán jön létre.
Ez egyébként a hibajelenségek mumusa...
Szóval igen, előfordulnak hibák az ipari rendszerekben is, hogyne fordulnának elő.
A fejlesztői környezetek itt is segítik a fejlesztőt a munkájában, de nem kötik meg az ember kezét olyan módon ahogy a kérdésed sugallja.
Kivételek ez alól a safety rendszerek, ahol nagyon komoly szabályrendszer szerint lehet (csak úgy engedi) bizonyos funkciókat összeállítani. Konkrétan pl. a safety PLC.
Elég jelentős korlátot jelent egyébként. Az ilyen PLC azon kívül hogy drága, emiatt elég korlátolt is. csak indokolt esetben használják. Pl. ahol emberélet, testi épség forog kockán, vagy környezeti katasztrófa esetleg jelentős anyagi kár keletkezhet a hibás működésből (gyógyszer ipar, olajfinomítók, vegyi üzemek, erőművek, és általános gépek munkabiztonsági rendszerei).A privát véleményem az, hogy a PLC programozás eléggé gépközeli programozás. Tehát nem végletesen magas szintű, mint pl. a PC-s adatbázis kezelés, webes fejlesztés, objektum orientált nyelvek, vagy épp a vizuális egérhúzogatós alkalmazás generátorok.
A PLC program sokkal közvetlenebbül és ezért átláthatóbban hat a berendezésre, mint mondjuk egy visual basic a PC hardverér. Szerintem sokkal jobban oda lehet figyelni a hibákra.Egyébként meg ha durva hibát vét az ember, akkor a gép adott esetben tör és zúz, görbülnek a vasak. Volt már olyan és lesz is! De sokkal gyakoribb az, hogy nem megy, mint az, hogy kárt tesz.
Jellemzően nagyobb közvetlen károkat lehet okozni mint egy játék program vagy böngésző elrontásával. De nehezebb is elhibázni!"A busz protokollokkal a jelek szerint valamit félre értettem."
A profibusz egy bizonyos konkrét terepi busz kialakítás neve. Beleértve az összes lajert és lehetséges protokollt is. Ha csak a fizikai rétegről beszélnénk, akkor RS485-nek kellene hívni és nem profibusznak, mert RS485 alapú.
Szinte minden nagyobb gyártónak megvan a maga által fejlesztett saját buszrendszere, amik semmilyen szempontból nem kompatibilisek egymással, hogy ne legyen olyan egyszerű az élet."Részemről a "profibusz" alatt egy layer 1 felületet értettem, nevezetesen halom kábelezés, és csatlakozók, rajtuk előreszámítható 0 és 1 bitekkel, amik azonos típusú adat keretekbe szerveződnek, amire magasabb layeren protocolok illeszkednek."
Akkor nem porofibuszról kell beszélni, hanem terepi buszról (fieldbus). A profibusz egy fieldbus a sok közül. Minden profibusz terepi busz, de nem minden terepi busz profibusz
Azt, hogy ilyen, olyan, meg amolyan kommunikáció is mehet rajta egyszerre, amiknek szinte közük sincs egymáshoz úgy kell elképzelni mint az ethernet+TCP/IP-t. Lehet rajta file-okat le/fel tölteni (pl. FTP) böngészni és videót nézni (stream)."Ellenőrzésként megkérdezném, az MPI protocol elektronikailag ugyan arra a buszra csatlakozik, mint a DP slave-ek, vagy fizikailag is külön busz, külön csatlakozók, és teljesen szét vannak választva?"
Az MPI és a profibusz két teljesen külön busz, teljesen más protokollal, de teljesen azonos a fizikai réteg. Mind a kettő ugyanolyan RS485. Ezért a csatlakozó kialakítása, sőt annak bekötése is teljesen azonos. De egy kábelen ez a kettő soha nem megy. Egy busz vagy MPI, vagy profibusz. Ha egy PLC-n mindkettő rendelkezésre áll, akkor az külön csatlakozót jelent, teljesen külön kábelezéssel.
"A "HMI"-ről kb annyit találtam, ami a wiki-ben le van írva (human machine interface, ami kb mindenre igaz, monitorra, egérre, billentyűzetre, stb),"
A HMI megnevezés kb annyira pontosan határozza meg az eszközt, mint mondjuk a "számítógép" kifejezés. Sok belefér.
Régebben valahol itt megpróbálkoztam a megfogalmazásával, de most nem találom.
Az én értelmezésemben a HMI egy olyan eszköz, ami:
- Kijelzővel rendelkezik
- Saját processzora van, esetleg saját oprendszere, a feladatra programozható
- Billentyűzete van, esetleg érintő kijelzője, vagy mutató eszközt lehet rá csatlakoztatni
- Közvetlen kapcsolatban áll egy vezérlővel (rendszerint PLC-vel)
- A vezérlővel képes adatot cserélni, általában mindkét irányban
- Lehetővé teszi a vezérelt berendezés és az azt kezelő ember között az összes szükséges kapcsolat megteremtését.Az utolsó a lényeg, az előtte lévők annak a célnak vannak alárendelve.
Ezért nem HMI egy egér vagy egy billentyűzet, bár a HMI rövidítésben szereplő szavak alapján lehetnének azok.
Egy HMI tehát egy programozható készülék. Rendszerint LCD kijelzővel, billentyűzettel, előlapba szerelhető kivitelben (néha hordozható kivitelben) és szinte mindig sokféle kommunikációs lehetőséggel.
Konkrétan arra való, hogy egy ipari vezérlés "monitora és billentyűzete" legyen. helyettesíti (kiváltja) az ún. űrhajós pultokat, amin ezer lámpa gomb meg kapcsoló van.
A HMI-n a vezérlő hibaüzeneteket jelenít meg, a vezérelt berendezésről közöl információkat (darabszám, nyomás, hőmérséklet, lényegében bármilyen információ megjeleníthető rajta a gépről, ami a PLC-ben rendelkezésre áll. Továbbá lehetővé teszi a berendezés működésmódjának, vagy paramétereinek megváltoztatását, ellenőrzését.
Egy egér, vagy egy monitor önmagában ilyesmire nem képes, ezért azt nem tekinthetjük HMI-nek. De pl. egy számítógép konfiguráció egy HMI szoftverrel már igen. -
Szirty
őstag
válasz
#95092224
#2481
üzenetére
Hali topsli!
"Van egyáltalán szabványban leírt neve a kommunikációs protokoljának az S7 rendszerekben, vagy definíció szerint ez valami olyasmi, amit a Siemens olyanra tervezett, amilyenre, és senki másnak nincsen hozzá nyúlka-piszka?"
Pl. a profibusz esetében a profibusz kifejlesztői (ami néhány cég) létrehoztak egy szervezetet akik pátyolgatják, egyengetik az útját.
A cél nagyjából az, hogy más gyártók számára is elérhetővé tegyék és ezzel egy kvázi ipari szabványt hozzanak létre. Akárcsak a profinettel, ami lényegében a profibusz ethernetes változata.
Ez a szervezet készséggel megad minden információt a buszról, ami egy ilyen buszra csatlakozó eszköz kifejlesztéséhez kell. Persze nem ingyen.Az MPI-vel nem tudom mi van, nem tudom a siemens elérhetővé tette-e a protokollt.
Az ethernetes (profinetes) S7-ek képesek TCP, UDP stb kommunikációra, aminek módja hozzáférhető.
Többet erről sajnos nem tudok mondani. Én nem fejlesztek terepi buszos eszközöket. Inkább alkalmazom (felhasználom) őket. -
Szirty
őstag
válasz
#95092224
#2482
üzenetére
Helló topsli!
Ezt a kérdésed nem teljesen értem. Mit értesz "ilyen protokol" alatt?
Azt, amikor ír/olvas a PLC regisztereiből?
Ha igen, akkor nem, ez nem új keletű dolog. Eleve tudják ezt a kezdetektől fogva.
Az S7-hez vagy a siemens-hez sem köthető.
Más gyártók PLC-s környezetében is általános hogy a HMI-k így működnek. -
Szirty
őstag
válasz
#95092224
#2486
üzenetére
Helló topsli!
Mint már említettem, szerintem egy standard profibus DP slave nem képes arra amit szeretnél. Példaképpen említettem is, hogy azok a siemens panelek, amiket profibuszra is lehet csatlakoztatni (és azon át írnak olvasnak PLC regisztereket) nem DP slave-ként szerepelnek a buszon. A DP slave-ek szerintem csak I/O regiszterek megvalósítására képesek. Az a chip amiket DP slave-ekbe tesznek a profibusz megvalósítására szerintem éppen ilyen.
Egy fénykép vagy segít, vagy nem. Látsz ott egy Xilinx FPGA-t vagy egy céláramkört és meg is állt a történet.
Régebben szétszedtem egy S7-et, amin van egy MPI/Profibusz csatlakozás is.
[ Szerkesztve ]
-
Szirty
őstag
válasz
#95092224
#2488
üzenetére
Helló topsli!
Gondolom már előbb is érezhető volt, hogy én mint információ forrás kimerültem a számodra.
Már most többet tudsz a profibuszról mint énAzt hiszem sajnos nem tudok többet érdemben segíteni.
Azért hangsúlyoztam, hogy a profibuszon kommunikáló standard HMI eszközök nem DP slave-ként vannak jelen a buszon, mert a DP konfigurációban nem is szerepelnek. A DP master nem illeti őket a "token ring-szerű megszólítással" és igazából nem is érzékeli a DP master a hiányát a buszon (ellentétben a konfigurált DP slave-ek eltűnésével, amik során komoly herce-hurca kezdődik egy PLC programban).
Az általad többször is linkelt leírás említi a slave-ek között a HMI-t, mint lehetséges slave eszközt. Valóban lehet egy slave HMI is, de konkrétan a siemens HMI-k nem azok.Sajnos fogalmam sincs milyen kommunikációt használ egy HMI a profibuszon. Talán FMS lehet, vagy DPM2. Nem tudom.
. Sok PLC-n már alapban is van valamilyen adatport, vagy olcsón bővíthetőek ilyesmivel. Ezek némelyike hardveresen egyszerűen (interfészen keresztül, de akár közvetlenül is) összehozható egy számítógéppel. Ilyen lehet pl. az RS232, RS422/RS485-alapú protokollok (pl. modbus), vagy mostanában az ethernet (pl. modbus over TCP/IP), hogy a különféle gyártók háziszabványait ne is említsem. Modbus TCP-vel pl. viszonylag egyszerűen megoldható a PLC memóriacímeinek (regisztereinek) közvetlen irása, olvasása, és az egy 'számítógépesnek' sem olyan emészthetetlen. Azt persze nem említetted, hogy miféle PLC lenne az alany, esetleg már adott, vagy még csak most kell kiépíteni a rendszert.
Ahogy néztem, alapként be van pipálva. Remélem nem volt memóriahiányuk, és bekapcsolva hagyták.
) plc-ből kellene kiolvasni az adatokat. A plc egyedi fejlesztésű és kereskedelmi forgalomba nem kapható és kizárólag csak a taiwani cég ( Zitai)által gyártott nyomásos alu. öntőgépekben található meg.
/B)
Új hozzászólás Aktív témák
- Milyen okostelefont vegyek?
- Fallout 4
- Renault, Dacia topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Vicces képek
- Székesfehérvár és környéke adok-veszek-beszélgetek
- A fociról könnyedén, egy baráti társaságban
- EA Sports WRC '23
- Villanyszerelés
- További aktív témák...
