Új hozzászólás Aktív témák
-
Dezsi82
tag
Hali!
A használtakkal kapcsolatban én nem tudok semmit, de itt vannak az újak:
http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&siteid=cseus&aktprim=0&extranet=standard&viewreg=WW&objid=10805335&treeLang=en
Step 5 meg nem azon van, amire feltelepíted? -
Dezsi82
tag
Bocsi, az előbbi link stornó. Az csak archív
-
-
Szirty
őstag
Üdv plajos!
"Az a gond, hogy nálunk van jópár EPROM/EEPROM-os PLC, jó lenne ezeket is írni/olvasni."
EPROM-al rendelkező S5-ben is módosítható a program.
Egyszerűen fel kell rá tölteni a módosítottat.
A program EPROM-os gépben is RAM-ból fut, ahol le lehet cserélni. Gond akkor van, ha az elem kimerül és áramszünet van. Induláskor az EPROM-ban tárol verzió visszatöltődik és aszerint működik tovább. -
Szirty
őstag
Hali Dezsi82!
"Amúgy saját véleményem szerint nem éri meg kimondottan Siemens PG-t venni. Az újak, legalábbis amennyire én tudom semmivel sem jobbak, mint egy normális laptop."
Strapabíróbbak mint egy laptop, amit managereknek, igazgatóknak gyártanak irodába, meg fimet nézni egyetemistáknak. Magnézium váz ide vagy oda
Persze vannak ipari körülményekre gyártott laptopok is. Pont a PG árábanEgyébként tényleg nem éri meg, mert a laptopok "amortizációja" hihetetlenül gyors. Eltelik két év és már semmit nem érnek.
Nekem a soros port hiányával szokott gondom lenni, PG-ben legalább van (kettő is). Az ilyen laptop vagy régi, vagy ritka mint a fehér holló.
Az USB-s RS232 adapterekkel meg gigantikus a szívás -
Dezsi82
tag
Hali Szirty!
Persze, kicsit strapabíróbbak, mint a gagyi kategória, ezért írtam, hogy "normális"
De ha megnézed az újakat, pont olyan mint egy átlagos laptop, leszámítva a Siemens logót.
A Hp nc sorozatának pl van soros portja.
Nekem pl HP nx sorozatú van. Most már két éves. Az aksit leszámítva tökéletesen működik. Pedig nagyon sok helyen jártam már vele, mostoha, ipari körülmények között. Az aksi sajna már csak 10 percet bír. És valóban, én is hiányolom a soros portot. Persze vannak átalakítók, de tapasztalatom szerint se pont olyan, mint a beépített."Gond akkor van, ha az elem kimerül és áramszünet van. Induláskor az EPROM-ban tárol verzió visszatöltődik és aszerint működik tovább."
Márpedig áramszünetek voltak, vannak, lesznek...[ Szerkesztve ]
-
Szirty
őstag
Üdv Dezsi82!
"De ha megnézed az újakat, pont olyan mint egy átlagos laptop"
Hát igen. Nos Field PG-t nem használtam még. csak Power PG-t évekig, meg előtte PG740-et, meg azelőtt PG720-at.
CD és floppy meghajtókkal voltak bajaim bennük. Nem bírják a port Meg egyszer elszállt a Power PG-ben a standby 5V-os táp. Szerencsére sikerült megjavítani, bár eléggé maga alá rondított ott belül. Más gond nem volt."Az aksit leszámítva tökéletesen működik. Pedig nagyon sok helyen jártam már vele, mostoha, ipari körülmények között."
Én Dell-t használok másfél éve. Azon is van egy db RS232 hálaégnek! Szerencsére aksi jó, négy (4!) órát bír, ami már-már hihetetlen.
"Márpedig áramszünetek voltak, vannak, lesznek..."
Igaz. De nem vetted figyelembe amit az és előtt írtam: "Gond akkor van, ha az elem kimerül és áramszünet van." Az elem kimerülését meg lehet előzni cserével, és akkor jöhet az áramszünet
-
#95092224
törölt tag
Bocsi, hogy így belekotyogok a dolgokba, de miért is kell mindenre PLC-t használni? Ipari termelésre, az okés, de egyéb civil célokra mi baj van az ipari miniPC-kkel? Laptopot én se raknék ki termelési területre, de egy miniPC-t be lehet szerelni a szekrénybe, és elvan, mint a befőtt. Van rajta azonnal ethernet, meg ami SW támogatást csak akarsz. És egyáltalán Windows.
-
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. -
#95904256
törölt tag
Mi egyaránt gyártunk PLC és PC vezérlésű szerelő/tesztelő gépeket. Mind egyedi gép, egyedi funkcióval, felépítménnyel, vezérlőprogrammal. A PC vezérlés olcsóbb, viszont sok nagy cégnél adott típusú PLC-kre vannak ráállva ( olyan van náluk raktáron, azt ismerik a helyi mérnökök, központi előírás, stb. ), így nem lehet mindenütt használni. Megbízhatóságuk egyforma. A gép biztonsága meg nem azon múlik, hogy PLC vagy PC vezérli, hanem az alkalmazott biztonságtechnikai eszközökön és módszereken. Ha menet közben elromlik a gép vagy (szándékosan) rossz program kerül a vezérlőre, akkor sem okozhat sérülést.
-
Dezsi82
tag
válasz #95904256 #963 üzenetére
És mi van akkor, ha a PC lefagy? Mondjuk kiad egy kimenetet, kimegy egy munkahenger, egy nyomáskapcsoló jelére pedig visszahúzza azt. De ha lefagy a PC, akkor nem fogja visszahúzni a munkahengert, és összetöri a munkadarabot.
De igaz, hogy az ember biztonságát nem a vezérlő logika kell, hogy biztosítsa, úgyhogy módosítok. Ha a gép tudna magában kárt tenni.
Nagy cégek meg szerintem azért is írják elő a PLC-t, mert azt könnyen tudják módosítani, a fent lévőt visszaolvasni. Egy PC-s alkalmazásnál, amennyire én tudom, visszafejteni nem lehet az exe-t. -
#95904256
törölt tag
(#964) Dezsi82: "És mi van akkor, ha a PC lefagy?"
Ugyanaz mint amikor a PLC döglik be.
A Delphi / C++ / VB program ugyanúgy módosítható mint az LD / FBD / ST / IL ...
Az exe fájlt is visszafejthető, csak rengeteg munkával jár. Megjegyzem, nem minden PLC-ből tudod visszaállítani a forrást. Sok PLC pl. nem tárolja el a kommenteket vagy éppen az exe fájlhoz hasonló lefordított kóddal dolgozik. ( Pl. ilyen a Beck / Festo PLC ami ráadásul x86 kompatiblis processzort tartalmaz. )
-
Dezsi82
tag
válasz #95904256 #965 üzenetére
Ugyanaz mint amikor a PLC döglik be
Azért úgy gondolom, hogy a PLC-nek a meghibásodási mutatói nagyságrendekkel jobbak, mint egy PC-nek. Jómagam pl elvétve találkoztam lefagyott PLCvel, míg PCvel jóval többször.
Egy kollégám pl előző munkahelyén olyannal találkozott, hogy egy lefagyott NIDAQ kártya miatt egy műszak CD író tönkrement.
A Delphi / C++ / VB program ugyanúgy módosítható mint az LD / FBD / ST / IL .
Amennyiben megvan a forráskód, nem? És mi a helyzet a keresztreferenciával? Delphiben csak keresni tudsz, vagy nem? Vagy pl IO ponttól visszakeresni egy ismeretlen programban. PLCvel majdnem sima ügy, PC-s programnál, ha nem kommentezett a program, nagyon eltarthat.
Sok PLC pl. nem tárolja el a kommenteket
Ez igaz, de ha megvan egy régi programod, visszaolvasod bele az újat, és sokkal jobb a helyzet, mintha nullláról kezded az egészet.Más különben milyen rendszert használtok PC-s vezérlénél? Milyenek az IO-k? Csak mert én is szívesen használom a PC-s vezérlést, és hátha Ti jobbat használtok.
[ Szerkesztve ]
-
#95904256
törölt tag
(#966) Dezsi82: "Azért úgy gondolom, hogy a PLC-nek a meghibásodási mutatói nagyságrendekkel jobbak, mint egy PC-nek."
Én meg úgy látom, hogy mindkettő egyformán megbízható. Mindkettő ugyanazon gyártók ugyanazon alkatrészeiből épül fel, ugyanolyan mérnökök tervezik, ugyanolyan garanciákkal. Ráadásul a PC alkatrészek még nagyobb darabszámban is készülnek.
(#966) Dezsi82: "Amennyiben megvan a forráskód, nem?"
Ha nincs meg, be kell szerezni. Nem minden cégnél törekednek arra, hogy forráskód nélkül dolgozzanak...
(#966) Dezsi82: "És mi a helyzet a keresztreferenciával? Delphiben csak keresni tudsz, vagy nem?"
Nincs olyan keresztreferencia Delphi alatt amire célzol. De érdekes módon még egyszer sem éreztem hogy problémát jelentene. Viszont azt igen, hogy Delphivel sokkal kényelmesebb és gyorsabb a programfejlesztés mint akármelyik PLC fejlesztő környezetben.
(#966) Dezsi82: "Ez igaz, de ha megvan egy régi programod, visszaolvasod bele az újat, és sokkal jobb a helyzet, mintha nullláról kezded az egészet."
Azért ennek is megvan a maga veszélye. Ha a PLC-ben lévő kód egy-két networkkel/runggal/steppel itt-ott hosszabb vagy rövidebb akkor rossz kommentek kerülnek rossz helyre. A félrevezető információktól lehet csak igazán agybajt kapni...
(#966) Dezsi82: "Más különben milyen rendszert használtok PC-s vezérlénél? Milyenek az IO-k? Csak mert én is szívesen használom a PC-s vezérlést, és hátha Ti jobbat használtok."
PC-s megoldásoknál főképp Advantech ipari PC-ket használunk Delphi alól. Az I/O-k általában NI vagy Advantech, néha Addidata gyártmányúak. Ha egyszer megírja az ember a megfelelő objektumokat, akkor utána meg különösen kényelemesen kezelhető.
szerk.: Megjegyzem nem feltétlenül ezek a legmegfelelőbb eszközök mindneki számára. Mindenesetre nálunk bevált.
[ Szerkesztve ]
-
Csikáno
csendes tag
Üdv mindenkinek!
Egy probléma megoldásában kérném a segítségeteket! Van egy Siemens S7-200.
cpu 222-as PLC-m. Szereztem egy programozó kábelt,(USB/PPI) ami nem gyári Siemens de kompatibilis a 200-as sorozattal. A cpu 222-as plc-t gond nélkűl felismeri és tudom is
programozni. Most kaptam próbára egy S7-200.cpu 224-es PLC-t. Ezt viszont nem ismeri fel nem tudok a plc-vel komunikálni. A kommunikációs beállításoknál USB,COM3 és COM4.prtokat választhatom. A cpu 222-nél a COM 4. simán megy. A cpu 224-nél egyik sem! Tudna valaki segítséget adni nekem, nagyon megköszönném. -
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.
-
Szirty
őstag
válasz #95904256 #963 üzenetére
Hali akosf!
"A gép biztonsága meg nem azon múlik, hogy PLC vagy PC vezérli, hanem az alkalmazott biztonságtechnikai eszközökön és módszereken."
A gép biztonsága kb. a gép részét képező elemek megibásodási gyakoriságának összegén múlik.
"Én meg úgy látom, hogy mindkettő egyformán megbízható. Mindkettő ugyanazon gyártók ugyanazon alkatrészeiből épül fel, ugyanolyan mérnökök tervezik, ugyanolyan garanciákkal."
Ez nagyon érdekes, mert én meg úgy gondolom, hogy a PC és a PLC megbízhatóságban nincsenek közel egymáshoz. PLC teljesen más alkatrészekből épül fel! Vagy te az m3-as csavarokra meg a kondenzátorokra és a NYÁK lapra, gondolsz?
Akkor gondolj arra, hogy ehetsz isteni finom túrós palacsintát is, meg ehetetlenül elbaszottat is. Ez akkor is megeshet, ha teljesen ugyanazokból az alkotóelemekből áll mindkettő!!
Az hogy ugyanolyan mérnökök terveznék a PLC-t és a PC-t, az meg elég durva túlzás. Köszönő viszonyban sincsenek egymással imho.
Ugyanlyan garanciák sem állnak szerintem, mert egy átlagos PC sokkal lazább körülmények között kell hogy teljesítse a megadott műszaki paramétereket (ha egyáltalán megadnak rájuk bármilyen műszaki paramétert a GHz-eken meg MIPS-eken kívűl és azon kívül hogy hány FPS-el megy rajta a Counter strike)."Ha nincs meg, be kell szerezni. Nem minden cégnél törekednek arra, hogy forráskód nélkül dolgozzanak..."
Meg kell szerezni.. Ha nincs meg eleve, akkor ez így nem nagyon szokott működni ám a gyakorlatban!
"Viszont azt igen, hogy Delphivel sokkal kényelmesebb és gyorsabb a programfejlesztés mint akármelyik PLC fejlesztő környezetben."
Az üzeneteid mögött elfogultságot érzek. A fenti mondat erre eléggé rávilágít.
Én úgy gondolom, hogy egy bizonyos célra gondosan kifejlesztett eszköznél és programnyelvnél nem hatékonyabb egy általános célra kitalált eszköz vagy programnyelv.
Márpedig a PLC és annak programnyelve specializált és igencsak hatékony.
De aki szerint az általános célú Delphi, C java stb megfelelőbb automatizálási feladatok ellátására, az írjon napestig sok ezer logikai feltételsorokat delphiben... És ássa fel a kertet ásólapáttal, amivel se ásni, se lapátolni nem lehet normálisan (de kicsit azért mindkettőt lehet).A PC-nek is van helye az ipari automatizálásban, nem vitás, mi is használunk jópárat. Igaz nem vezérlésre, hanem megjelenítésre, adatkezelésre. Van közöttük ipari kivitel is (ami mellesleg nem kimondottan olcsóbb mint egy PLC)
Bátran és túlzás nélkül leírhatom, hogy ezek mindegyikével volt már probléma. Akár az oprendszer miatt, akár HW miatt.
PLC-kkel is volt már gond, nem tagadom. De PLC-k között sok darabbal még soha. (évekről van szó).
Összességében az én gyakorlati tapasztalataim nem támasztják alá az elhangzott megbízhatósági összehasonlításban említetteket. -
Dezsi82
tag
Hali!
A HW eszközökben én is Szirtyvel értek egyet. Legalábbis annak idején én úgy tanultam, hogy CPU-k gyártásánál a gyártás utáni ellenőrzésénél a hibás transzformátorok százalékában osztályozzák őket. Normál PC, ipari PC, PLC, gyógyszeripar, hadipar, űrhajózás. Bár nem tudom ,ez így van-e még.
A SW dologban viszont akosf-fel. A Delphi, pl mint objektumorientált programnyelv nem lassabb, mint a WinCC. Legalábbis egy menüben beállítani hogy milyen színű, nem gyorsabb , mint beírni, hogy xxx.color:=clRed; Ráadásul, ha Delphiben írod, egyszerre haladsz a vezérléssel, és a megjelenítéssel. Míg ha megjelenítő szoftvert használsz, akkor le kell programoznod a PLC oldalt is. -
Csikáno
csendes tag
válasz #95904256 #969 üzenetére
Helló akosf!
A cpu 224-nél is éppen úgy állítottam be a típust mint a cpu 222-nél, ahogy leírtad!
Ezért nem értem, hogy miért nem találja meg a PLC-t. Lehetséges, hogy a prog.kábel
az egyik szériát felismeri a másikat meg nem?
USB : nem csinált semmit.
COM4 : végigszámol 126-ig és hibát ír ki.
COM3 : végigszámol és egymás alá kiírja 126-szor. UNKOWN és a szám -
#95092224
törölt tag
A kérdés ipari PLC-k Digit Output moduljaira vonatkozik. Az adatlapokban nem találtam arra vonatkozó infót, hogy mi várható, ha a szaki bután kötöget drótokat, és kimeneti meghajtást beköt fogyasztó nélkül (rövidre zárja a kimeneti meghajtást a 24V-os külső tápegységgel).
Konkrét példának mondjuk a "Siemens SM 322; DO 8 x 24 VDC/0.5 A with diagnostics interrupt" - ezt írta róla egy adatlap. Ezen a diagnostic interrupton akadt meg a szemem. Mit jelent ez a gyakorlatban? Ha zárlatban rákötöttem a tápfeszt (nem hogy 0.5A-t, de 100x annyit is lazán be tudna az tolni), képes felismerni, automatán lekapcsolni, és mindezt még üzemszerű körülményként állandó ismétléssel is túlélni?
Vannak más Digit Output modulok is, ahol nem olvastam ilyen apróbetűs jegyzetet. Azokkal általánosságban mi a szitu? Túlélhetnek egy félrekötést, vagy tönkremennek tőle?
-
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. -
Dezsi82
tag
Hali
Ezeket a hibákat ismeri, nem tudom melyik jön be rövidzárra, talán a félkövér
OB82_MDL_DEFECT BOOL Module is defective
OB82_INT_FAULT BOOL Internal fault
OB82_EXT_FAULT BOOL External fault
OB82_PNT_INFO BOOL Channel fault
OB82_EXT_VOLTAGE BOOL External voltage failed
OB82_FLD_CONNCTR BOOL Front panel connector not plugged in
OB82_NO_CONFIG BOOL Module is not configured
OB82_CONFIG_ERR BOOL Incorrect parameters on module
OB82_SUB_MDL_ERR BOOL Submodule is missing or has an error
OB82_COMM_FAULT BOOL Communication problem
OB82_MDL_STOP BOOL Operating mode (0: RUN, 1: STOP)
OB82_WTCH_DOG_FLT BOOL Watchdog timer responded
OB82_INT_PS_FLT BOOL Internal power supply failed
OB82_PRIM_BATT_FLT BOOL Battery exhausted
OB82_BCKUP_BATT_FLT BOOL Entire backup failed
OB82_RESERVED_2 BOOL Maintenance request
OB82_RACK_FLT BOOL Expansion rack failure
OB82_PROC_FLT BOOL Processor failure
OB82_EPROM_FLT BOOL EPROM fault
OB82_RAM_FLT BOOL RAM fault
OB82_ADU_FLT BOOL ADC/DAC error
OB82_FUSE_FLT BOOL Fuse tripped
OB82_HW_INTR_FLT BOOL Hardware interrupt lost[ Szerkesztve ]
-
Szirty
őstag
Hali Dezsi82!
"A SW dologban viszont akosf-fel. A Delphi, pl mint objektumorientált programnyelv nem lassabb, mint a WinCC."
Azt senki nem is állította és csodálkozni sem lehet ha egy 40Mhz-en ketyegő WinCC flex panelt haonlítunk össze egy kétmagos dualcore procival szerelt PC-n futó delphi programmal.
A programfejlesztés sebessége meg egy másik kérdés."Legalábbis egy menüben beállítani hogy milyen színű, nem gyorsabb , mint beírni, hogy xxx.color:=clRed;"
Alapvetően a vezérlőprogramról volt szó, nem a megjelenítésről.
Én azt jegyeztem meg, hogy logikai vezérlésre hatékonyabb egy logikai vezérlésre kifejlesztett célprogram, mint egy általános célú magas szintű nyelv, amilyen a Delphi is. Még példával is próbáltam illusztrálni, nem értem miért értetted félre. -
Dezsi82
tag
Hali!
Értettem én mindent, szerintem én nem voltam világosÉn kimondottan a fejlesztésre gondoltam, nem a működésre.
És pont arra akartam rámutatni, hogy egy saját fejlesztésű PC vezérlésnél a megjelenítés és a vezérlés szorosan egymás mellett megy.
Logikai? Miért a Delphi milyen, ha nem logikai?[ Szerkesztve ]
-
Dezsi82
tag
Hali!
A PCről jutott eszembe egy probléma, amin túlléptem, de nem tetszik a megoldásom.
Szóval a gond a következő:
Van egy S7 PLC Profibuson kommunikál egy jó pár eszközzel. A PLCre feltöltöttem az összes OB-t, amit hiba esetén meghív a PLC. Így ha valamelyik profibus-os eszköz hibában van, és nem kommunikál, akkor világít ugyan a BF, meg az SF, de nem áll le a PLC.
Viszont van egy PC egy CPxxxx kártyával, de nem Siemens fejlesztő környezetben írt szoftverrel, amit nem mi írtunk. Na, ha ezzel van valami gond, pl lekapcsolom, akkor leáll a PLC ciklusidő túllépés miatt, mert nem tudja írni a területet. És igazából nem tudom miért. Van valakinek ötlete? -
-
Csikáno
csendes tag
Üdv mindenkinek!
Egy kis segítséget kérnék! S7-200 cpu 222-es PLC-t tudok programozni, a kábel és software (MicroWin V4/SP4)jó! A gondom a cpu 224-es PLC-vel van. Nem tudom kommunikációra bírni a PLC-t! Mi lehet a hiba, hogy az egyiket kezeli a másikat pedig nem? Van valakinek ötlete, hogy mit nézzek meg?
Köszi! -
Szirty
őstag
Hali Csikáno!
Én csak annyit tudok hirtelen írni a problémádra, hogy az tény, hogy bizonyos 200-as CPU típusok csak bizonyos microwin verzióva vagy afölöttivel hajlandóak együttműködni.
Továbbá a PPI interfész verziója sem mindegy (van olyan PPI interfész amelyikkel bizonyos CPU-kat nem lehet programozni).
A te nem gyári PPI interfészed nem tudom milyen...Ilyen tippjeim vannak.
Szét kell nézni siemens technical fórumon... -
Szirty
őstag
Hali Dezsi82!
"És pont arra akartam rámutatni, hogy egy saját fejlesztésű PC vezérlésnél a megjelenítés és a vezérlés szorosan egymás mellett megy."
Aminek semmi köze ahhoz, amit abban a postban írtam amire reagáltál
"Logikai? Miért a Delphi milyen, ha nem logikai?"
Amennyire én tudom nem nagyon támogatja a boolean műveleteket... Tévednék?
Egy automatizálási feladat pedig 80-90%-ban ilyenekből áll.
Nem nagyon támogatja a boolean változókat sem, de itt már nem a delphi, hanem inkább az oprendszer és az architektúra az ok.
Persze lehet booleant csinálni. Igaz hogy 32 biten tárolja az 1 bitet, de kit érdekel? van RAM elég.
Ha nincs, veszünk, a logikai feltételsorokat meg leprogramozzuk kilométeres If Then Else szerkezetekkel, amiket nagyon könnyű a programban egy pillantással átlátni és működés közben debugolni monitorozni....A Delphi programokat futtató platform, a windows nem éppen real time oprendszer. Az kit zavar?
"Értettem én mindent, "
Vagy mégsem?... :-(
-
Dezsi82
tag
Hali Szirty!
Tévednék?--> Tévedsz
Nagyon jól lehet vele logikai műveleteket végezni.
A bool változótípus épp ilyen.
Ami kicsit macerásabb, az egy bájt, word, vagy double word adott bitjének az állapotát lekérdezni, vagy beállítani, de az is viszonylag könnyű.
Az viszont igaz, hogy egy hosszabb logikai hálót nehezebb átláthatóra megcsinálni. Megoldható, de kicsit nehezebb. De egy nagyobb hálót Siemens-szel sem tudsz monitorozni, mert csak a képernyőn látható első néhány utasítást monitorozza.
És akkor jobb szétszedni.
De az nagyon igaz, hogy működés közbeni debugolás nehézkesebb, sőt lehetetlen, ha nem készülsz fel rá..
van RAM elég.
Ez egy sajnálatos programozói hozzáállás, de tényleg gyakran találkozom vele én is. De PLC programnál is.
a windows nem éppen real time oprendszer
Őszintén, nem tudom mire gondolsz, mit jelent a real time oprendszer. De a PLC-k is egymás után hajtják végre az utasításokat. Továbbá, ha kijelzőkön, robotvezérlőkben megfelel a PC, és a windows, akkor azért olyan vacak mégsem lehet -
Szirty
őstag
Hi Dezsi82!
"Nagyon jól lehet vele logikai műveleteket végezni. A bool változótípus épp ilyen."
Ha nem akarod érteni nem fogod.
"Őszintén, nem tudom mire gondolsz, mit jelent a real time oprendszer. De a PLC-k is egymás után hajtják végre az utasításokat."
Egymás után, de az sem mindegy mennyi idő telik el két ciklus között és mennyire garantálható az, hogy tényleg annyi fog eltelni. Alap windóznál erre semmi garancia nincsen.
A valós idejő rendszerben garantált, hogy egy művelet egy előre meghatározott időn belül végrehajtásra kerül. Eindows-ban erre nincsen garancia.
Még a siemensnek is van annyi esze, hogy a szoftveres PLC-jük (WinAC) alá tegyenek egy Real Time szoftvert (RTX), ami a fentit legalább valamennyire biztosítja.
Más gyártók ilyen megoldásainál meg lehet hogy fel sem merül a windows..."...robotvezérlőkben megfelel a PC, és a windows, akkor azért olyan vacak mégsem lehet"
Biztos van ilyen is. A robotok szervóinak vezérlése különösen érzékeny az időre.
Végig igyekeztem szem előtt tartani és annak megfelelően válaszolni, de úgy érzem meg is kell fogalmaznom, hogy én nem kétlem mit lehet megoldani PC-vel, delphivel. Láttam már én is sokmindent.
Itt arról van szó, hogy a szóbanforgó feladatokra vagy azok egy részére van sokkal jobb megoldás mint a PC. -
Dezsi82
tag
Ha nem akarod érteni nem fogod.
Nekem a bool utasítások az és, vagy, xor, stb. Ezeket mind tudja a delphi. Gondoltam, ha leírom, hogy van ilyen változótípus, akkor egyértelmű, hogy a hozzá tartozó utasításokat is kezeli.
Biztos van ilyen is
Ki kell, hogy ábrándítsalak, minden robotot számítógép vezérel.
van sokkal jobb megoldás mint a PC.
Nyilván vannak feladatok, amit PCvel, van amit PLCvel egyszerűbb megoldani. De szerintem semelyik esetben sem tehető meg az, hogy ne nézzük meg mindkét lehetséges megoldást, illetve kijelenteni, hogy a PLC mindig gyorsabb, és hogy a PC mindig olcsóbb. -
Szirty
őstag
Hi Dezsi82!
"Ezeket mind tudja a delphi. "
Pedig meg is jegyeztem, itt nem arról van szó, hogy tudja-e vagy sem. Eltekintenék a szóban forgó megjegyzés idézésétől, egy hozzászólással arrébb van.
"Ki kell, hogy ábrándítsalak, minden robotot számítógép vezérel."
Ugye tudod hogy a PLC is számítógép!?
Vagy PC-re gondoltál? Nálunk is üzemel robot. Nem láttam PC-t vagy windows-t a környéken."De szerintem semelyik esetben sem tehető meg az, hogy ne nézzük meg mindkét lehetséges megoldást"
Egyetértek. Nem beszélve a számtalan egyéb megoldásról is ami még esetleg lehetséges.
-
-
Dezsi82
tag
Hali!
Ha jól tudom a PLC inkább microcontroller. Az igazat megvallva nem tudom pontosan az miből áll, de egy robotvezérlő szekrényben van winchester, op rendszer, általában CD meghajtó, stb. Ha esetleg van KUKA robototok, nézd meg bootolás közben. Kb 5 perc, mire beindul szegény. És szépen mutatja a windows boot képernyőt. A japánok általában megcsinálják, hogy saját op rendszert írnak, ezért aztán gyorsabban is indulnak. Nézd meg az egyik robototok vezérlő szekrényét, a szervók fel lesznek fűzve egy kommunikációs hálózatra. A hálózat egyik végén lesz egy nagyobb doboz, az a számítógép.
Azért nem PC-t írtam, mert az nekem a személyi számítógép. És a robotokban általában nem közönséges PC van. Bár a KUKA ez alól is kivétel, ott sima PC van. A vezérlőben ha jól emlékszem Win95, a kijelzőben attól függ mikori kiadás, Win95-WinXP. Na meg is kell, hogy mondjam, az a fajta robotvezérlővel van a legtöbb gond. De nekünk ez csak jó
Nem beszélve a számtalan egyéb megoldásról is ami még esetleg lehetséges.
Egyetértek.
tt nem arról van szó, hogy tudja-e vagy sem.
Azt írtad úgy tudod nem támogatja. Akkor úgy mondom, hogy támogatja, ha így jobban tetszik -
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
Hali Dezsi82!
"Ha jól tudom a PLC inkább microcontroller."
Nem. Legfeljebb mikrovezérlő van egy PLC-ben.
Ham Wiki szerint a mikrovezérlő:
A mikrovezérlő egy olyan integrált áramkör, amely a processzorhoz hasonlóan egymás utáni utasításvégrehajtásra lett tervezve, azonban az integrált áramköri lapka magába foglalja a programmemóriát, az adatmemóriát és az intelligens perifériák közül sokfélét (RS232, SPI, I2C, CAN, LIN, A/D, D/A, PWM, USB, Ethernet). A mikrovezérlő tulajdonképp egy kis teljesítményű, olcsó egycsipes számítógép.A Wikipédia szerint:
A mikrokontroller egyetlen lapkára integrált, általában vezérlési feladatokra optimalizált számítógép.Ez lenne a PLC?
-
Dezsi82
tag
Legfeljebb mikrovezérlő van egy PLC-ben
Igazad van, mert egyik ismerősöm szétszedett egy PLC-t, és egy PIC-et talált benne. (Gyártmányt nem tudok). Valóban durva hiba, ha egy autóra azt mondjuk, hogy az egy V8-s motor, de úgy gondolom ez a legjellemzőbb része. Ahogy a PLCnek a mikrokontroller az esze. Legalábbis így gondolom.
Másrészről nevezhetünk egy speciális igényeknek megfelelően módosított PC-t PC-nek?
Ha igen, akkor PC vezérli a robotokat. És a PC nem számítógép? -
#95092224
törölt tag
Szerintem a fa helyett lássátok inkább az erdőt. A számítógép definíciójába inkább én se mennék bele, de van egy sokkal egyszerűbben megfogható különbség a számítógép, és a periféria eszköz között: maga az alkalmazás.
Egy számítógép tipikusan absztrakt felületen dolgozik. Afféle ideális körülmények között. Nincsen rajta idő-kritikus nyomás. Egy periféria vezérlő pedig idő-kritikus alkalmazásokra van optimalizálva.
Írok egy példát. Pld adva van egy információ stream, másodpercenként csak 1 millió bittel. Nem egy nagy sebesség. Ennek a többszörösét is fel lehet dolgozni számítógéppel. Viszont ha azt vesszük, hogy minden információ elem éppen csak abban az egy uSec időablakban áll rendelkezésre, máris problémái lesznek a számítógépnek (pld a PC-nek). Ugyanis egy mai oprendszerrel (pld WinXPsp3) nem lehet 16 mSec időablakon belülre pozicionálni. Ha ki kell nyisszantani fixen egy bitet a streamből, akkor kell egy perifériát kötni a számítógéphez, ami ugyan sokkal gyengébb teljesítményű, viszont azt a csekélyke teljesítményt koncentráltan a feladatra tudja fordítani. Pld kinyisszantani egy bitet az adott uSec időablakból, amivel egy PC felsülne, arra még egy aprócska pic10-es is képes. Azután valamilyen információ bufferbe rakni a dolgokat, ahonnét kötegelve lehet továbbítani a számítógép felé, amikor majd a számítógép éppen kegyeskedik odafigyelni, és kötegelve átvenni egyszerre mindent, ami időközben felgyülemlett.
Bármilyen számítógép perifériát is veszünk alapul, azok mindegyikének önmagának is van egy processzora, és kvázi perifériái (sima TTL / CMOS jelvezetékei, ha más nem). Ergo azok önmaguk is számítógépek. De az alkalmazás típusa miatt mégis perifériáknak hívjuk őket.
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.
Amúgy a miniPC-ket "ipari" célokra én úgy értettem, hogy pld egy nagyobb kivetítő monitort nem feltétlenül kell időkritikus üzemben működtetni. Tök8, hogy egy kép az adott uSec időablakban jelenik-e meg, vagy akár több mSec idővel később. Egy absztrakt eszköznek maximum az emberi reflexek sebességéhez kell alkalmazkodnia, de arra meg bármelyik képes. Időkritikusabb alkalmazásokra én sem használnék miniPC-t, ugyanis alkalmatlan rá. Oda vagy PLC vagy pic.
Némelyik PLC-nek PIC12C magja van, mint időközben megtudtam: összteljesítményét tekintve iszonyúan gyengusz egy típus.
-
Csikáno
csendes tag
válasz #95904256 #990 üzenetére
Hali!
A cpu 222-nél, ami ugye megfelelően működik, teljesen mindegy, hogy RUN vagy
STOP állásban van-e a kapcsoló. Mégpedig azért, mert anélkül is fel kellene ismernie
a PLC-t, valamint ha átakarom tölteni a progit a plc-re úgy is megkérdezi, hogy
állítsa-e a plc-t stop állásba. Csak stop állásban lehet fel ill. letölteni.
Egyébként a MicroWinben hól kell beállítani azt az értéket? -
#95904256
törölt tag
Hali!
A RUN állapotban a soros portot lefoglalhatja a PLC-ben futó program ( pl. egy vonalkódolvasó jeleire várakozik ). Csak STOP állapotban garantált, hogy él a host protokoll.
A beállításokat MicroWin alól a File / Download / Communications / Set PG/PC Interface panelen lehet elérni. De ugyanez a panel elérhető a Windows Start / Beállítások / Vezérlőpult / Setting the PG/PC Interface ikonnal is.
Új hozzászólás Aktív témák
- Samsung Galaxy S24 Ultra 12/512gb, Titánszürke, 1 hetes, csak kipróbált, 3 év garanciával, eladó!
- HP ENVY x360 15-fh0755ng Convertible - ÚJ - 15,6" notebook - Ryzen 5, 16GB, 512SSD, Win11
- Iphone 12 64GB független 94% akku
- HP PROBOOK 450 G9 (6A150EA) - ÚJ - 15,6" FullHD IPS üzleti notebook - i3-1215U, W11pro
- fehér RTX3060Ti Gamer PC Intel i5-11400F, Zotac Gaming RTX3060Ti 8GB, 16GB Corsair RAM, vízhűtés!