- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Hogy is néznek ki a gépeink?
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Használt VGA / videókártya ajánló
- Soundbar, soundplate, hangprojektor
- Apple asztali gépek
- Videós, mozgóképes topik
- Vezeték nélküli fülhallgatók
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- VR topik (Oculus Rift, stb.)
Új hozzászólás Aktív témák
-
Szirty
őstag
Helló oli83!
1. Mutasd meg CPU stop utáni diag buffert! (hiba esetén hibaüzenetet nem hagyunk figyelmen kívül)!
2. Mutasd meg az FB133 blokk interface részét az összes használt változódefinícióval!Ha ennek a kettőnek eleget teszel az jelentősen növelheti az esélyeimet egy valamire való válaszra.
-
dokikaaa
csendes tag
Üdv!
Van egy ib il temp 2 rtd Phoenix-es ellenállás hőmérős modul, ami egy phoenix-es I/O szigetre van rákötve. A Phoenix-es io sziget profibuszon kommunikál egy siemens PLC-vel. A kérdésem az volna, hogy valamit konfigurálni kell ezeken az ellenállás hőmérő modulokon, vagy ha egyáltalán lehet, akkor hogyan paraméterezhető? A katalógus szerint van neki Controll Wordje, de a siemenses hardver configba csak statusz word van (PIW258), ami elvileg előjelesen adja vissza az analóg értéket. Ez a vissza adott analóg érték szoba hőmérsékleten 60-120 között megállás nélkül az ob35 ciklusaitól függően ugrál a két érték között. Ha a mérendő szakaszt felfűtöm(kb 100fokra), akkor 160-230 érték között szintén ugrál. (2 vezetékes bekötés)
Valakinek van valami ötlete hogy ezt hogyan lehetne használni? vagy nem jól működik a modul? (Másik 2 PT100-assal is ugyan ez a jelenség tapasztalható)
-
oli83
tag
Sziasztok!
Siemensesek segítsetek.
Írtam egy programot, amiben van egy hiba, és sehogy sem találom, mi a hiba forrása.
A progi hiba része egyszerűsítve így nézne ki:
A hiba az FB133-ban van.
Ha M10.0 bebillentem stop állapotba kerülünk.Tettem a progiba kikommnetezéseket (//), ezekben az esetekben M10.0 hatására nem kerülünk stop állapotba,
Mi lehet a gond?
Szükségem lenne mindkét címregiszterre, valamint statikus INT tárolóra.üdv.: oli83
-
Szirty
őstag
válasz
moseras
#4340
üzenetére
Üdv moseras!
"Akik PLC világból jönnek, ragaszkodnak a hagyományos PLC-s nyelvekhez, aki C++ világból jön, az ahhoz, akik WEB-es világból csöppen bele, az javascipt-ben akar PLC-t programozni"
Ez így van, ebből mindig van vita.
Ez a tény azonban a legkevésbé sem támasztja alá azt, a törekvést hogy PLC-t programozzunk pl. java scriptben.
Az ilyen vita szűklátókörűségből ered és hitvita jelleget szokott ölteni és átcsap veszekedésbe.A programozási nyelvek nem azért sokfélék, hogy mindenki használja azt ami neki a legjobban tetszik, hanem azért, mert specializáltak. A specializáció célorientáltságot jelent. Célja az, hogy az adott feladatot hatékonyabban és könnyebben lehessen megoldani, leprogramozni.
A feladat jellegéből adódóan a kilométeres logikai összefüggések programozására orientálódott nyelv a LAD és az FBD (az előbbi megdobva egy kis áramút terves múlttal is).
Meg lehet csinálni ugyanazt C nyelven is, de az kevésbé hatékony erre a kifejezett célra. A C ugyanis univerzális célú nyelv és mint tudjuk az univerzális dolgok sok mindenre jók egy kicsit. (Mint az ásólapát. Se ásni, se lapátolni nem lehet vele normálisan.)Aki meg létradiagramban akar PC-re grafikus felületű MP3 lejátszót írni, vagy PLC-t javascripttel programozni vagy operációs rendszert python-ban írni az szerintem meg is érdemli...
-
moseras
tag
válasz
dodzylla
#4337
üzenetére
Üdv!
Szóba jöhet még gondolkodásra alkalmasnak a matiec nevű fordító:
A benne lévő iec2c fordító tud ST-ből, IL-ből vagy SFC-ből C kódot generálni. Tehát ha valaki a PLC-nél megszokott programozási nyelvekben akarja leírni a kódot, akkor abból ezzel a fordítóval tud C kódot generálni, azt meg már mikrokontrollerhez vagy Raspberry-hez kis munkával tudja adaptálni. Persze a kommunikációt (legyen most OPC) ez a fordító nem fogja megvalósítani, azt továbbra is neked kell leprogramozni.
Mindettől függetlenül szerintem, az, hogy milyen nyelven programozzunk PLC-t (vagy milyen nyelven írjuk a Windows-on futó Soft PLC-t), az egy örök vita kérdése. Akik PLC világból jönnek, ragaszkodnak a hagyományos PLC-s nyelvekhez, aki C++ világból jön, az ahhoz, akik WEB-es világból csöppen bele, az javascipt-ben akar PLC-t programozni, vagy mondjuk mikrokontrollert:
[Javascript mikrokontrollerre]
Pl. a beckhoff új PLC-s fejlesztőkörnyezte (Twincat 3) a Microsoft Visual Studio-val van összeintegrálva, és a hagyományos ST, IL, SFC mellett lehetővé teszi C++ kódok írását is.
Imi.
-
-
Szirty
őstag
válasz
Mazsika
#4336
üzenetére
Üdv!
"Ez a megoldás már csak azért sem jó, mert így túl lassú lenne a folyamatod, mire átmegy opcn az adat +feldolgozás"
Sok olyan folyamat is van (főleg szabályzások) ahol 10-20 másodperces vagy akár perces beavatkozási gyakoriság is elég.
"Ráadásul egy s7nek is kell egy hw config tehat nem ugy van hogy kiveszed a dobozbol es megy..."
Úgy gondolom ennyire nem volt konkrét a kérdése. Nem írta hogy S7-ben gondolkozik. (az mellesleg pláne pazarlás lenne). A sok compact CPU nem igényel konfigurálást.
-
Mazsika
őstag
-
dodzylla
csendes tag
c++ magas szintű nyelv
assembly alacsony szint, de az nagyon körülményes mondjuk én nagyon szeretem de erre szerintem nem a legjobb bár gondolom a PLC is valami hasonlógépi kódra fordul le, mert végülis a PLC is egy mikrokontroller
Itt beszélnek hasonlóról bár itt RaspberryPI vel dolgoznak, az egy elég jó kis cucc, bár kezdésnek arduino jobb szerintem.
Itt olvashatsz.
http://www.raspberrypi.org/forums/viewtopic.php?f=72&t=54117 -
moseras
tag
válasz
n0rbert0
#4328
üzenetére
Üdv!
Az mennyire elképzelhető, hogy egy prg nyelvben, mint pl c++ egy szabályzás/vezérlés lenne megvalósítva, ami OPC szerveren keresztül a PLC memóriáját, IO-jait írja/olvassa?
Ez megvalósítható. Csináltunk hasonlót, csak nem OPC-n keresztül, hanem az egyik esetben MODBUS TCP-n keresztül ment a kommunikáció, a másik esetben pedig CANopen-en keresztül, szintén C++-al. Vannak ilyen megoldások nagy cégeknél is, pl. a Codesys-nél Real Time SoftPLC-nek hívják. Windows alatt fut, van egy Real Time beépülő modul, illetve emlékeim szerint az ethernet kártya driverének Windows kezelőjét is kicseréli, így "próbál meg" Real Time lenni. A demo-ját próbáltam, működik, de hogy mennyire Real Time, arra már nem emlékszem. Van free cucc is, az a neve, hogy ClassicLadder. Linux alatt is fut, ott az RTLinux patch-et használja. Használtam node.js-ben működő MODBUS TCP-n kommunikáló soft plc-t is, az is működik, a real time akkor nem volt fontos.
Szóval működik, véleményem szerint inkább a kiszolgáló op. rendszer, illetve az alatta lévő HW megbízhatóságával vannak problémák, és kérdések.
Imi.
-
n0rbert0
senior tag
Értem, akkor egy kicsit tovább megyek...
Az mennyire elképzelhető, hogy egy prg nyelvben, mint pl c++ egy szabályzás/vezérlés lenne megvalósítva, ami OPC szerveren keresztül a PLC memóriáját, IO-jait írja/olvassa?
Teszem azt, valaki vesz egy PLC-t használtan (pici pénzért), otthoni célra, de nem vesz hozzá szoftvert mert nincs hozzá kedvepénze, ezért fogja a c++ tudását és megvalósítja a vezérlést abban. (még mindig elméleti síkon...)Ez jó, így még nem hallottam ezt az aforizmát.
-
Szirty
őstag
válasz
n0rbert0
#4326
üzenetére
Üdv n0rbert0!
Nem vagyok nagy OPC tudor, de véleményem szerint az OPC kommunikáció mint szabvány, (legalábbis az MS azt szeretné) nincs felkészítve arra, hogy a PLC-ben futó programkódot megváltoztassa.
Jelen ismereteim szerint az OPC szerver feladata hogy hidat biztosítson a Microsoft windows és az automatizálás/folyamatvezérlés hardvere közötti adat átjáráshoz. Vagyis egy szabványos (ismert) és egységes kommunikációs (adatformátum) szintre emeli a különböző fajta vezérlőkből (pl. PLC-kből, így a gyártási folyamatokból) származó adatokat. Ezáltal ezek az adatok elérhetővé válnak a Microsoft windows rendszeren futó alkalmazások számára.
Nem célja az ipari automatizálásban, folyamatirányításban működő teljesen különböző vezérlő egységek programozásának egységesítése.(A személyes véleményem egyébként hogy jó az uniformis, mert mindegyiknek ugyanott van a zsebe, de van akire annyira illik, mint tehénre a gatya...)
-
n0rbert0
senior tag
Azt tudom, hogy általában az általad felsorolt esetekben szokták alkalmazni, de lehetne OPC szerver + valamilyen prg. nyelv alkalmazásával PLC szabályzást/vezérlést írni? (természetesen csak elméleti síkon)
Igen rosszul fogalmaztam alacsonyabb/hardware közelibb prg. nyelv (mint pl. egy interpretált java vagy phyton).
-
Szirty
őstag
Üdv bozig!
"Siemens-ről tudom, hogy a Simatic Step 7 kezeli a 61850-et, viszont azzal ugye csak Siemens PLC-t lehet programozni, ha jól tudom."
Nem tudom van-e félreértés, de ez a szabvány szerintem arra törekszik (arról szól) hogy az ember számára egységessé tegye a különböző PLC-k programozásnak legalább az alapjait és nem arról, hogy az ilyen szabványt használó szoftver képes legyen minden az összes olyan PLC programozására amelyik támogatja ezt a szabványt.
-
Mazsika
őstag
Persze ezeken kívül is még nagyon sok minden befolyásolja a megírt programot, persze az olvashatóság is fontos lenne, bár ez nem minden esetben jön össze...
Más: NTP szervert szeretnék használni, S7-300-asnál, viszont annyi baj van vele, hogy két órával korábbanra frissíti az időt. Gondolom valami időzóna téma, lehet ezt valahogy állítani a PLC-be?
-
moseras
tag
Üdv!
Ha valódi "objektum orientált" nyelvre gondolsz, amivel PLC-t is lehet programozni, akkor a Codesys V3.xx tud ilyent (a V2.xx nem!). A WAGO bizonyos PLC-it lehet Codesys V3-ban programozni (de nem mindegyiket, sőt a többségét nem).
Az is kérdés, hogy pontosan mit értesz objektum alatt. Mert ha elég az, hogy külön az adat "struktúra", és külön a kód, akkor az IEC 61131-3 is elég.
Ha valódi osztályokra gondolsz, akkor pl. Codesys V3, vagy esetleg olyan környezetek, amelyek megengedik C++ kód futtatását, és megengedik a C++ osztályait.
A Codesys nem nyílt forrású !
Imi.
-
bozig
tag
Sziasztok!
Az a kérdésem, hogy létezik-e, illetve ismertek-e olyan, lehetőleg nyílt forráskodú program nyelvet, amiben én tudok szabadon objektumokat definiálni, és adott esetben több gyártó PLC-it tartalmazza. Előrebocsátanám, hogy nem a saját agyszüleményem ennek keresése, tehát ha nagyon irreálisat kérdeztem, kérlek ne torkolljatok le. -
Szirty
őstag
Üdv tibi-d!
"Egy 32 bites memória területet elkülönítettek a vezérlés állapotnak."
Ismerős ez a megoldás is.
Gyönyörű, amikor egy ilyen (vagy számlálós-léptetős) szekvenciális programot újabb lépésekkel kell bővíteni.
Vagy átírod az egészet más számokhoz rendelve ugyanazokat a lépéseket, vagy a nem használt számokat veszed igénybe. Innentől 1,2,3,4,5,6,7,8,9 helyett majd az 1,2,10,11,3,4,12,13,5,6,7,8,9 fog egy sornak számítani.
De van olyan is, ahol erre gondoltak és egy integer mondja meg az aktuális lépés számát, amit nem egyesével növel, hanem tízesével. Így lehetőség van új lépések beszúrására. A rend így is felborul, mert kevésbé lesz követhető melyik lépés után melyik jön. Ráadásul az integer léptetése tele lesz komparátorokkal, mert 10 után 20 jön, de 20 után 21, majd 22, és csak utána 30. -
tibi-d
tag
Nálunk a Sirty által vázolt vezérlési logikát tovább bonyolították. Egy 32 bites memória területet elkülönítettek a vezérlés állapotnak. Ebből az első 10 (0-9) bit a berendezés kiindulási állapota, attól függően, hogy milyen üzemmód van kiválasztva. Ha a berendezés megkapja az indító parancsot, a 10-es bit aktivizálódik, (bárhol is volt előtte "0-9"). Ha az első parancsot végrehajtotta, lép a 11-re, stb. Előfordulhat olyan eset is, hogy pl. 12-es állapotról bizonyos esetben nem 13-ra, hanem 15-re lép. (Pl. ilyenkor nem balra mozdul, hanem jobbra). Majd onnan folytatja. De olyan is előfordulhat, hogy 21-ről 15-re lép vissza. Ez az éppen bekövetkező események függvénye. Ez a logika arra is jó, hogy csak ezt a 32 bitet regisztrálva vissza lehet követni a berendezés működési lépéseit.
-
tibi-d
tag
Sziasztok!
Pár gondolatot had írjak le, hogy egy főként ipari berendezés vezérlését hogyan lehet áttekinthetően megírni. Én a berendezés működését két alapvető tényezőre szoktam bontani. Egyiket feltétel rendszernek hívom, a másik az utasítás rendszer. Az első hivatott azt garantálni, hogy a berendezés soha ne kerülhessen olyan állapotba, ami a berendezés tönkremeneteléhez vezetne. A másik gondoskodik a működtetésről. Itt lehet programozni a kézi, automata, szerviz üzemmódokat, stb. Az automatikus üzemmódnál nálunk is alkalmazzák Szirty logikáját. A berendezés csak akkor végez feladatot, ha mindkét feltétel teljesül. -
Szirty
őstag
válasz
KB.Pifu
#4306
üzenetére
Üdv KB.Pifu!
"Kézi üzemmódban, a gépnél kiválasztunk egy állomást és gombnyomásra egyesével "végigléptetjük" a munkafolyamatot, ott már feltétlenül szükséges a számláló jelenléte, nem?"
Most attól eltekintve hogy mit gondolok a kézi üzemmódról, azt tudom erre mondani, hogy feltétlenül mindenképpen ide sem szükséges számláló. (az hogy most a lépési feltétel forrása tényleg számláló (C) vagy egy inkrementált merker word tartalma, az jelen esetben mindegy).
Pl. egyszerűen kell egy "lépés vége" merker, ami bebillen minden mozzanat végén és a léptetés gombbal lehet törölni. És ezt a merkert be kell rakni minden továbblépés feltételsorába. Ezzel ugyanúgy léptethetővé válik.A léptetőlánc nélküli programra van itt egy a közlekedési lámpánál valamivel komplexebb kidolgozott kommentezett feladat.
Ha gondolod nézd át: Tolópad szimuláció S7-300/400-ra -
byte-by
tag
válasz
KB.Pifu
#4307
üzenetére
halo !
ha a rendben befejezett munkafolyamat is feltétele a számláló léptethetőségének, akkor nyomkodhatod, nem fog történni semmi, amíg rendben végig nem csinálta az adott léptetést.de a számláló így sem szerencsés.
sok gépsor sajátja a "félautomata" üzem, volt szerencsém párhoz. van olyan gépsor ahol frankó távirányítóval kiválasztod az állomást , majd lépteted a folyamatot.mondjuk pont ez a gép nem volt a tervezés etalonja.
viszont a "kézi üzem" valóban a komponensek egymástól akár független működtetéséről szól, persze a megfelelő feltétel rendszer mellett. ez bizonyosan nem szekvenciális.ha esetleg szekvenciáról van szó számlálót én sem használok.leginkább egy merker szót szoktam használni amibe értéket írok ha a feltétel sor igaz.egy comparátorral ez adja a következő network első feltételét, aztán ha a többi is igaz lesz ,egy másik érték íródik bele.ezzel szekventált programblokkonként 1 merker word-öt használok el.
"félautomata" léptetéshez is használható, a befejezett hibátlan programsor fogja csak átírni a merker szót,majd újabb gombnyomás. ha közben is nyomogatják a gombot nem fog történni semmi.ez SZIGORÚAN szekvenciális gyártógépekre vagy állomásokra igaz.
egyébként sajnos tényleg igaz, hogy szinte csak a léptetős programírást oktatják.visznek kis kivágógép vagy mártogatógép modellt és mindenféle léptetős munkára bírják.persze látványos meg sikerélmény annak aki még semmi ilyesmit nem csinált,de kissé csalóka.sehol egy szabályzás, PID, regiszter kezelés, stb. de legalább felhívnák a figyelmet a továbbképzés szükségességére.
byte
-
Szirty
őstag
válasz
KB.Pifu
#4306
üzenetére
Üdv!
Az én értelmezésemben a "kézi üzemmód" azt jelenti, hogy kézzel kapcsolok be és ki mindent.
Tehát kiválasztom a hajtást/munkahengert és azt irányítóm. Ki/be kapcsolom két gombbal vagy előre/hátra vagy le/fel mozgatom.Az hogy egy automatikus folyamat állapotait léptetem nyomógombbal azt inkább félautomata módnak tekintem.
-
KB.Pifu
tag
Szia!
Köszi!
ezért vagyok ezen a fórumon, hogy másféle látásmódom legyen mint amit oktattak.
adott egy gép, mondjuk egy több állomásos összeszerelő automata..
Kézi üzemmódban, a gépnél kiválasztunk egy állomást és gombnyomásra egyesével "végigléptetjük" a munkafolyamatot, ott már feltétlenül szükséges a számláló jelenléte, nem?
Én ezt a feladatot saját meggondolásból számlálóval és pozitív élfigyeléssel tudnám csak megoldani. -
Szirty
őstag
válasz
KB.Pifu
#4303
üzenetére
Üdv KB.Pifu!
Ok.Tehát ha jól értem a kérdést akkor ez a válasz rá...
Nem szoktam számlálót léptetni amikor egy gép elér egy állapotot és megint léptetni amikor elér egy másik állapotot és így tovább. Az adott mozgásokat meg a számláló pillanatnyi értékéhez kötni.
Pl.: ha a számláló tartalma 1, akkor emelés szelep meghúz. Ha felért, számlálót léptetem. Ha számláló tartalma 2, akkor rögzítő szelep nyit, időtag indul. Ha időtag letelt, számlálót léptetem, ha a számláló tartalma 3 akkor... és így tovább.Kimondott léptetőláncot sem szoktam építeni, ami úgy működik mint a "futófény". Azaz van sok-sok merker bit, amik egymást billentik be egyéb feltételek teljesülése esetén. Amelyik bebillent az törli azt amelyik az imént bebillentette. Így lesz egy merker sor, amiben egy bit mindig 1 állapotú a többi meg 0. Az 01-es állapot "végig sétál" a láncon. ha 1-es lépés aktív, akkor akkor emelés szelep meghúz. Ha felért, láncot léptetem. Ha 2-es bit értékre 1, akkor rögzítő szelep nyit, időtag indul. Ha időtag letelt, láncot léptetem, stb, stb, stb.
Vannak gépek amik mozgása kifejezetten lépésekre bontható. Jól definiálható állapotok vannak amik mindig azonos sorrendben követik egymást és vannak amiké egyáltalán nem bontható ilyen állapotokra vagy ezek az állapotok véletlenszerű sorrendben követik egymás (pl. a technológiai állapottól függően).
Olyan esetekben ahol ilyen ismétlőfő lépések meghatározhatók én jelzőbiteket használok. Amikor egy művelet megtörtént, bebillentek egy jelzést és a következő műveletnek ez is feltétele (az egyéb véghelyzetekkel, időtagokkal együtt).
Ez funkcionálisan tekinthető léptető láncnak is, mert hasonlóan működik, de a program felépítése nem léptetőláncra épül.Más gépeknél (ahol nincsenek előre definiálható állapotok amik egymást követik) nem is alkalmazható ilyen módszer.
Ezért pl. kifejezetten haragszok amikor ilyet oktatnak. Illetve amikor csak ilyet oktatnak (pl. OKJ-s tanfolyamon, de egyetemen is. lásd futófény, közlekedési lámpa példaprogramok).Aztán a delikvens szembe találja magát pl. a kézi üzemmóddal vagy egy szabályzással, vagy olyan feladattal ahol rengeteg párhuzamos folyamat fut amik sorrendisége nem határozható meg előre, akkor csak lesnek mint hal a szatyorban...
-
Szirty
őstag
Helló hukhl!
Te már a komplett feladatot tekinted én meg az alapvető egységeket.
A létradiagramban és a relés vezérlésben is van érintkező, ami kétféle lehet: nyitó és záró. Meg "tekercs" ami kapcsolja ezeket
Illetve van érintkező amit kapcsoló vagy nyomógomb működtet (létradiagramban bemenet)."Illetve több feladatot is "ütemekre" bontva Counter és Comparator segítségével könnyedén megtudok csinálni addig ezt relékkel nem."
A komparátor és a counter valóban nem relé-konform
Sokszor megjegyeztem már ezzel kapcsolatban az aggályaimat.
Futófényt és közlekedési lámpát nem csinálunk a gyakorlatban ipari PLC-vel bármilyen meglepő is. Ettől még lehet kihívás a feladat, de a legkevésbé sem gyakorlatias példa.
A létradiagramos lépésenkénti (szekvenciális) programozás, ahol egymástól jól elkülöníthető és pontosan meghatározható állapotokból álló lépések vannak egy módszer.
De!
1. Erre önálló programozási nyelvek vannak (grafcet, graph)
2. Nem minden folyamat írható le elkülöníthető lépések sorozatával!Én pl. szinte soha nem használok ilyen számlálót, aminek az értékéhez állapotokat rendelek.
-
hukhl
csendes tag
Köszönöm a további segítséget!
Szirty: Igen itt valószínűleg valami alapvető értelmezési gondom lesz ,mert tényleg nagyon hasonló a két logika.Érdekes módon több szaktársamnál is az van ,hogy vagy a relés kapcsolást vagy LAD-ot értik ,de olyan hogy mindkettőt érti az már csak nagyon elvétve van. Itt szimbólumok egymásnak megfeleltetése jelenti a gondot pl. reléknél a kapcsoló,nyomógomb,időrelé kapcsoló stb. létezik addig LAD-nál simán van NO és azt címzem meg. Illetve több feladatot is "ütemekre" bontva Counter és Comparator segítségével könnyedén megtudok csinálni addig ezt relékkel nem.Jövő héten vége lesz a szorgalmi időszaknak ,akkor újra neki állok az elejétől fogva és tüzetesen átvizsgálom a dolgot.
dodzylla: Én is csak megerősíteni tudom ezt az oktatási színvonalat/rendszert ,de nagyon nem örülök ennek a "cég filozófiának" se. Egyszer csak elfogynak(kiöregednek vagy elmennek küldföldre) a régen végzett még megfelelő szaktudással rendelkező mérnökök/technikusok aztán marad a mi generációnk akiket meg sz@rnak most gyakornokként is fogadni.
pár percet rálehet szánni, ha tudod ,hogy nem jó az is + tudás
Új hozzászólás Aktív témák
Hirdetés
- TUF Gaming F15 FX506HE 15.6" FHD IPS i5-11400H RTX 3050Ti 16GB 512GB NVMe gar
- ZBook Firefly 14 G11 14" FHD+ IPS Ultra 7 155H RTX A500 32GB 512GB NVMe ujjlolv IR kam gar
- PlayStation Portal hibátlan
- Csere-Beszámítás! RTX Számítógép PC Játékra! I3 10100F / RTX 2060 12GB / 32GB DDR4 / 500GB SSD
- GL.iNet AXT1800 (Slate AX) - Vadiúj Wi-Fi 6-os mini router, VPN-re is ideális
- ÁRGARANCIA!Épített KomPhone Intel i5 13400F 32/64GB RAM RTX 4060Ti 16GB GAMER PC termékbeszámítással
- AKCIÓ! MSI B365M i5 8600 16GB DDR4 512GB SSD RX 5700XT 8GB CM MASTERBOX Q300L Zalman 600W
- Thinkpad P16s notebookot vennék
- Bomba ár! Lenovo ThinkPad L480 - i5-8GEN I 16GB I 256GB SSD I 14" FHD I HDMI I Cam I W11 I Gari!
- ÚJ Lenovo Yoga Slim 7 - 14.5" 3K OLED Érintő 90Hz - Snapdragon X Elite - 32GB - 1TB - 2,5+év gari
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest