Hirdetés
- AMD Catalyst™ driverek topikja
- Videós, mozgóképes topik
- AMD vs. INTEL vs. NVIDIA
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- A Logitech egere összement a mosásban, és ez lett belőle
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- TCL LCD és LED TV-k
- Azonnali alaplapos kérdések órája
- Csekély 4000 dollárért tervezetten "hibás" az ASUS limitált VGA-ja
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
Új hozzászólás Aktív témák
-
-
Dezsi82
tag
Szia Szirty!
Én is töltöttem fel C7 sorozatú képernyőt MPI-n keresztül (nem tudom pontosan a típusát), nem tudom ennél miért nem lehet. Van egy olyan változata, aminek a típusszámában szerepel a "DP" a végén. És a rajz, amit adtál, az a "közönséges" OP-hoz való kábel bekötése? -
Szirty
őstag
válasz
Dezsi82
#1897
üzenetére
Hali Dezsi82!
"Én is azt hittem, hogy meg tudom oldani MPI-n, de ehhez a panelhez a ProTool-ban nincs ilyen beállítás, csak soros. És a dokumentáció is ezt mondja"
Én két okból gondoltam, hogy lehet MPI-n is tölteni:
C7-624-et így programoztam. Persze ez nem 624, hanem 633, de azt feltételeztem, hogy a 624 alapján ez is tudja.
A szöveget én is olvastam, de az csak azt írja le, hogy MPI-n lehet a CPU-t, és RS232-n keresztül pedig lehet az OP-t tölteni. Arról nem ír, hogy az OP-t ne lehetne MPI-n keresztül (is) tölteni...Nos akkor IJ van
Szerintem ugyanaz a soros kábel kell hozzá, ami a "közönséges" OP-khoz is (OP7, OP17, OP27, stb...). -
Szirty
őstag
válasz
Dezsi82
#1895
üzenetére
Helló Dezsi82!
"Fel kellene töltenem egy általam módosított programot egy Siemens C7-633 OP-ra. Azt már megtaláltam, hogy ehhez egy Programming device cable (RS 232/TTY) kellene a dokumentáció szerint. Tudja esetleg valaki, hogy ennek milyen a bekötése?"
Szerintem ilyen:
Csak a PC oldalon DB25-ös cati van a rajzon, ezt át kell forgatni DB9-re ha neked olyan kell.
Egyébként a C7-ben lévő OP-t MPI-n keresztül is lehet tölteni. Tehát ugyanazzal a kábellel és interfésszel, amelyikkel az S7 CPU-t is töltöd benne. Akkor nem kell két kábel.
Csak megadod a ProToolnál, hogy MPI-n akarod tölteni és beírod címét... -
Dezsi82
tag
Sziasztok!
Fel kellene töltenem egy általam módosított programot egy Siemens C7-633 OP-ra. Azt már megtaláltam, hogy ehhez egy Programming device cable (RS 232/TTY) kellene a dokumentáció szerint. Tudja esetleg valaki, hogy ennek milyen a bekötése? Vagy ez sima null-modem kábel lenne? Jó lenne biztosan tudnom, mert nincs közel a masina. Egyelőre sehol nem láttam bekötési rajzot róla.
Előre is köszi -
Szirty
őstag
Hali!
"Ha nincs meg a progid, esetleg csinálhatsz backup-ot SD kártyára, vagy akár laptopra is."
"Esetleg megpróbálhatnál más IMG-t fölrakni a panelra. Hátha másik verzióval jobban muzsikál...."
Csakhogy ha prosave backup után frissíti, akkor a visszatöltés után már nem biztos hogy fog rajta menni az a runtime, ami le lett mentve
Ezért írtam, hogy jobb ha megvan a forrás project!
-
oli83
tag
válasz
levelko
#1858
üzenetére
Szia levelko!
"A PLC programból látható-e hogy milyen kommunikációt használ?"
Elvileg ha megvan a PLC progid NetPro-ból kilesheted, hogyan beszélget az MP370-es panelod.
Itt majd meglátod, hová van fűzve. Katt a vonalra, majd tulajdonságok fülre.
(példa lila: Profibusz 1-es cím, kis ablakban látható paraméterek).Ha nincs meg a progid, esetleg csinálhatsz backup-ot SD kártyára, vagy akár laptopra is.
Esetleg megpróbálhatnál más IMG-t fölrakni a panelra. Hátha másik verzióval jobban muzsikál....
-
-
-
Szirty
őstag
válasz
sörösló
#1884
üzenetére
Hali sörösló!
Igen. Mindez S7-ben (300/400) is megoldható így.
De pl. időalap bitek még ha nem is rendszer bitek, de vannak.
A HW config CPU beállításainál a Cycle/Clock Memory fülön megadható egy merker byte címe. Ennek minnen bitjét a rendszer kapcsolgatni fogja meghatározott időállandóval:Bit 0 M255.0 Impulzus: 10Hz, 0.1s
Bit 1 M255.1 Impulzus: 5Hz, 0.2s
Bit 2 M255.2 Impulzus: 2.5Hz, 0.4s
Bit 3 M255.3 Impulzus: 2Hz, 0.5s
Bit 4 M255.4 Impulzus: 1.25Hz, 0.8s
Bit 5 M255.5 Impulzus: 1Hz, 1s
Bit 6 M255.6 Impulzus: 0.625Hz, 1.6s
Bit 7 M255.7 Impulzus: 0.5Hz, 2sA First scan flag-et sem nagyon nehéz előállítani.
A restart OB-ba (OB100) rakni kell egy Set-et valamelyik merker bitre, az OB1 végén meg egy Reset-et. Mivel restart OB minden induláskor csak egyszer fut le, kész a first scan flag.Egyébként OB-kban vannak előre deklarált lokális változók, amik tartalmaznak rendszer információkat. Pl. az OB1-ben kiolvasható ezekből az előző, a legkisebb és a legnagyobb ciklus idő (ms-ban) vagy a belső óra állása, stb.
-
sörösló
aktív tag
Nem tudtam, hogy az S7-ben sincs ilyesmi, de most már tudom.
Hirtelen összekaptam pár dolgot:AN F 0.0 Ez az OB1 első sora. Az F0.0 egy ciklusidőre
= F 0.0 ki-be kapcsolgató bit.AN F 0.1 Az F0.1 induláskor bebillen és ott is marad.
S F 0.1 Reset sehol nincs.***
--------------------------------------------------
A I 2.3 Itt 2 nyomógombbal lehet értéket növelni,
A F 0.0 vagy csökkenteni. A számláló értéke minden
CU C 1 második ciklusban eggyel nő vagy csökken.
Egy frekiváltó sebességjelét növeli-csökkenti.
A I 2.2
A F 0.0
CD C 1
--------------------------------------------------A F 24.2
A F 0.0
A(
L C 2
L KF +200
<F
)
CU C 2AN F 24.2
R C 2L C 2
T FW 96
***
-----------------------------------------------A F 0.0 Ez egy hosszabb időalapú ki-be
CU C 3 kapcsolgatás. A C3 100 ciklusra bekapcsol,
majd százra ki. Ha jól emlékszem, valami
hibajelzést villogtat.L C 3
L KF +50
>F
= F 2.6L C 3
L KF +100
>F
R C 3
BE
--------------------------------------------Használják rendszerindításkor is, mivel ez az első impulzus a programindulásnál.
-
Szirty
őstag
válasz
sörösló
#1879
üzenetére
Hali sörösló!
Igen Siemens. Nem, nincs ilyen "rendszerbit". Tulajdonképpen alapesetben semmilyen "rendszer bit" nincsen S7-ben. Legalábbis olyan, mint amilyenek vannak Omronban.
Tehát nincs olyan bit, ami adott időalappal billeg, nincs olyan, ami első ciklusban TRUE, nincs mindig kikapcsolt, bekapcsolt bit.
Ezeket meg kell csinálni ha szükség van rájuk, és akkor vannak.Mint írtam az a sor teljesen megfelel annak a kapcsolásnak, amit "csengő kapcsolásnak" hívnak. Vagyis egy tekercs, ami behúz,de amikor behúz, akkor kikapcsolja magát, ettől viszont elejt, ha elejt, akkor ismét bekapcsolja magát, amitől behúz, stb.
Egy hagyományos csengő kalapácsa ettől mozog és veri a harangot (ezért hívják csengő kapcsolásnak).
Mágneskapcsolóval relével is meg lehet csinálni, egyszerűen sorba kötjük a tekercsét a saját nyitó (NC) érintkezőjével. Persze ott nem a ciklus idő fogja meghatározni az oszcilláció sebességét, hanem főleg a mechanikai tehetetlenség, az elektromágnes húzóereje, a megtett út, stb.Hogy mire használnak ilyet a programban? Biztos volt oka. Én is láttam már ilyet programban, de én nagyon ritkán találkozok vele.
Az egyik ok lehet az, hogy pl. egy élvezérelt funkciót a lehető leggyakrabban végre akar hajtatni. -
sörösló
aktív tag
válasz
kip.kop
#1876
üzenetére
Siemens, nem? Vagy valami német programozó. Arrafelé általánosan használt fogás. Többnyire a program indulásánál az alapraállításhoz használják. A mostani eszközökön ezt alapból kínálja a program mint olyan rendszerbitet, ami a bekapcsolás után egyszer van, elvégzi a dolgát, aztán nincs rá többé szükség. Ez egy S5 maradvány, akkor bevált és azóta sem bírnak leszakadni róla. Az S7-ben ha jól tudom megvan mint rendszerbit, de az átállás nehéz kicsit. Valszeg valami idősebb szaki írhatta, aki az S5-ön nőtt fel. Erre írtam valamikor nemrégen, hogy a régi dolgok még sokáig viszaköszönnek majd! Persze hogy Siemens. Mégpedig S7, most látom!
-
Szirty
őstag
-
#95092224
törölt tag
Egy link: http://www.ge-ip.com/products/family/90-30-cpus
Van ott egy olyan, hogy "Built-in Communication Ports" -> "One RS-485 port on power supply.Supports SNP ". Ezt az "on power supply" dolgot elektronikailag hogyan kell érteni?
-
-
sörösló
aktív tag
válasz
bodnarg
#1870
üzenetére
Nem egészen érthető a problem az általad leírtak alapján. Esetleg nem lehet valami védelem letöltés ellen? Minden 115 esetén is megvan ez a jelenség, vagy csak egy bizonyos CPU-nál? Nyugodtan és részletesen nézd át a jelenséget, step by step... aztán majdcsak kiderül valami.
-
bodnarg
csendes tag
Sziasztok!
Egy lehet hogy csak számomra különös jelenséggel találkoztam. Valamilyen oknál fogva S5 115-ös CPU val szerelt gépeknél nem tudom on-line monitorozni a programblokkot. Olyat sem ami biztosan meg fut pl. OB1. Próbáltam a Siemens saját S5 progijával, illetve megvan az IBH softech S5 for windowsa is. Ha ugyanezekkel a programozókkal illetve softverekkel egy S5 95 vagy egy S5 135-höz csatlakozok akkor gond nélkül lehet a blokokat online nyomon követni. A 115-nél ha csak egy operandus értékét/állapotát karom megnézni akkor az működik. Van valakinek ötlete mi lehet a fentinek az oka?
Előre is köszönöm a segítséget.
-
levelko
csendes tag
válasz
sörösló
#1868
üzenetére
Hát igen! A jó öreg DOS. Még hosszú parancssorokat kellet írni egy tömörített állomány kicsomagolásához is. Mostmeg kitt-katt és nem tudod mi folyik a háttérben. Néhány "számítógép összerakó" ember meg azt sem tudja hány bit egy byte, de hetetnte telepíti újra az XP-jét.
Bocs, de nem akartam elkanyarodni a PLC-től.
-
sörösló
aktív tag
válasz
sörösló
#1866
üzenetére
Hát igen, a DOS-t még bitszinten írták. Egy komplett vállalati könyvelést elvitt a szintén bitszintű Commodore 64 program. Nem volt gigabájtos memória meg gigahertzes proci, hát spórolni kellett. Nemrég kapcsoltam be valamiért a régi 486-ost. Apám! 40 Mb merevlemez, 64 Kb memória, 66 MHz-es processzor, DOS és az erre épülő Win 3.1. Csúcsgép volt akkoriban, csak gondolkodni is kellett rajta néha, nem volt minden szarhoz varázsló!
-
#95092224
törölt tag
válasz
sörösló
#1865
üzenetére
A pic-es áramkör fejlesztéssel nem lesz gond, abban a világban otthon vagyok. A külön interface-t akartam lespórólni. Ezért nyafogtam. Simán csak mert plussz költség, amit rá kell áldozni. De ha muszáj beletörődni, akkor beletörődöm.
A DOS-ról meg csak annyit, hogy szerintem az egyik legjobb találmány volt. Amíg a gépeken DOS futott, addig időkritikus alkalmazásokat is futtatni lehetett rajta, és pld a printer porton keresztül vezérelni HW-ket. Anno még én is csináltam. Win alól minderre már külön HW kell, mert anélkül ilyet már nem lehet megcsinálni. Nem meglepő, ha ipari elektronikában még visszaköszön a puszta valóság.
-
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!
-
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.
-
#95092224
törölt tag
Köszönöm a vásárlási tippeket. Amikor legközelebb lesz egy nyugodt időszakom, akkor belefogok. Addig a mostani problémával már csak kerülőúton tudok megbirkózni, vagy segítséggel (éppen azért is írkálok ide).
Szirty:
"ne lehessen simán csak folytatni"
Oké, az én hibám. Marhaságot írtam. Bocsánat. Nem kell kényszer legyen. Megengedő jelleggel kell egy ilyen funkció. Szinkronizálni sem kell semmivel. Pld gombnyomásra az illető átvált egy másik képernyőre, és ott ha bök valamire, akkor a printer nyomtasson egy sort összetartozó adatokkal. Így is tökéletes."adjon a gép kezelője egy 5-6 soros listát kiírva"
Feltettem ezt a kérdést magam is. Mint kiderült, félreértettem a szándékot. Vannak bizonyos problémák, amikről tudnak, és már ellenintézkedések is vannak. Az igazi kérdés csak az ellenintézkedések hatékonysága, amiről kell a visszajelzés.A harmadik probléma, hogy ezzel a megoldással emberi tényezőt
Hát ezzel bizony úgy vagyok, hogy nem szívesen vetek fel olyan problémát, amivel nem tudok mit kezdeni![;]](//cdn.rios.hu/dl/s/v1.gif)
Szóval van egy megbízás X gépre első körben, és ha nagyon nem jön be, akkor a második ütemet törölni fogják. Ez előfordulhat. De az elsőt akkor is kifizetik. Azért az is csak pénz.Sörösló:
Köszönöm a tippet. A vonalkódolvasó nekem eszembe sem jutott. Én "hangpostán" filoztam, csak sajna túl nagy sávszélesség és túl sok tárolókapacitás kell hozzá, ha valaki esetleg unalmában elkezdene karaokizni. Saját human interface-t gyártani is sorozatgyártásban jó 40k huf, mire mindent összeszámolok. Tablet PC is van már ilyen áron, vagy legalábbis a kicsike fajta, csak azt meg széteszi az olaj ipari környezetben.
Részemről még mindig filozok rajta, hogy ha a PLC-t fel is lehet programozni erre, akkor egyáltalán semmiféle külön HW nem kellene, és hosszú távon tuti az a legüzembiztosabb. Még egy vonalkódolvasó is taccsra megy időnként, és akkor dobni kell, másikat venni helyette, amit majd vagy megtesznek, vagy nem. A PLC program nem amortizálódik.
Szóval a fanuc 16i-ben is már 64 bites proci van, és az alaprendszerében is van egy rakásnyi menü. Az nem valami buborékmemóriás kábelkorbács kukás szutyok, hanem kvázi egy számítógép. Tényleg a PLC gyártók lennének annyira szemetek, hogy a testreszabás legkisebb kezdeményét sem engedik? Vagy a PLC programozók lettek mind Stockholm-szindrómások és eltanulták tőlük a pénzéhséget? Csak lesek, mi a fenébe csöppentem már megint bele
-
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
#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! -
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. -
#95092224
törölt tag
A "PLC STL"-ről nem találtam kb semmit. Max félig névben stimmel brossúrákat. 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.
Akkor most lenne egy kérdésem, amit máshogyan vetek fel.
Nem tudom, lehet-e ilyet csinálni, de ha lehet, árajánlatot kérnék rá (egyszeri alkalmi munka / tanácsadás). Adva vannak Ge Fanuc 16i / 32i vezérlők. A gépen futó termelési program időnként leáll. Pld elfogy a bemeneti nyersanyag, vagy elkopott a kés és cserélni kell, vagy csak a gép kezelője állítja meg a mittudomén miért. Kellene egy olyat programozni, hogy ha megállt a termelési folyamat bármiért is, akkor ne lehessen simán csak folytatni, hanem kapjon a gép kezelője egy 5-6 soros listát kiírva (leállás lehetséges okai), és muszáj legyen megnyomnia legalább az egyik gombot pld F1..F6 (visszajelzés, hogy melyik eset is történt), mielőtt a programot tovább léptethetné / újraindíthatná a termelést. A Fanuc-ok mindegyikén ott egy soros port, arra rákötve egy karakteres printer (és amúgy tuti biztos működni fog). Arra kellene gombnyomás után kiküldeni egy nyomtatási sort, hogy gépidő / kiválasztott lista elem, esetleg még egykét PLC regiszter értéke, és sordobás. Ennyi. Szóval mint írtam, nem tudom, egyáltalán lehetséges-e ilyet csinálni. Ha igen, és valaki meg is tudja csinálni, várom a jelentkezését. Köszönöm.
(Kérdés, jelentkezés csak priviben)
-
levelko
csendes tag
Üdv!
Egy MP370-es SIMATIC multipanel problémájáról szeretnék kérdezni.
Egy S7 315 2DP plc-vel és 3db EUROTHERM hőfokszabályzóval van összekötve profibus-on. Az a gondja, hogy -mostmár egyre gyakrabban- spontán lefagy. Nem reagál semmi érintésre és hibaüzenetet sem ad. Egy táp ki-bekapcsolása után helyre áll, de hosszútávon nem ezt a megoldást várják tőlem. Az előző multipanelt elküldtük a gép gyártójának, pontosan ezzel a hibával. A hibájáról csak valami ködös hablaty volt a válasz.A kérdés az lenne: Van-e valami módszer, annak kiderítésére hogy mi okozta a lefagyást. Visszakereshető-e, vagy van-e valami "teszt" funkció amiből kiderülne?
A PLC programból látható-e hogy milyen kommunikációt használ?
Sajnos porosfülű karbantartóként még nem volt dolgom Pro Tool-lal, WinCC-vel, meg egyéb ilyesmivel.Köszönettel K.L.
-
#95092224
törölt tag
Konkrétan ilyen feladatom még nincs, de perpillanat a küszöbön van, és elképzelhető, hogy rámkopog.
Kezdésnek az elsődleges cél az lenne, hogy lássam a saját szememmel, ahogy egy elképzelésből program lesz, és az a program valami úton módon a cpu-ba kerül, elindul, és működik. Amúgy igazából nem pont a PLC vezérlés a szakterületem, és nem is számítok semmiféle komoly megmérettetésre ezen a téren, de olyan helyzet állt elő, hogy nem lesz elválasztható az egyik a másiktól, és legalább alapokkal képben kell legyek.
Ejnye lássunk már valami kézzelfoghatóbbat. Mondjuk egy fejlesztői környezet összepakolást. Ez most csak egy példa lesz. Schneider árlista. Itt pld: [link] az BMXP341000 L1-es processzor 92khuf+áfa. Az adatlapja szerint 24V-ról megy, kell hozzá egy tápegység. Találtam itt [link] BMXCPS2010 46+áfa. Aztán ezt a valamit programozni kell. Találtam olyat, hogy programozó kábel [link] BMXXCAUSBH018. Mondjuk azt nem vágom, hogy egy 1.8m usb-s kábelben mi kerül 21 ezerbe, de nyilván van valami oka, hogy nem használhatok pld egy sima PC-s usb kábelt. Ahogy a cpu-t elnéztem, a modbus kimenete rj45-ös. Ha több elektronikát kell rákötni, kellene hozzá valami elosztóféle is. Ilyet egyáltalán nem találtam. Másik problémám, hogy nekem db9-es csatlakozóra kellene a modbus rtu, nem rj45-re. A felkötendő elektronikának db9-es csatlakozója lesz. A kábelek között találtam egy TCSMCN3M4M3S2 -t, de ez is kicsit gyanús, hogy egy sima kábel 15 rugóba kerül - és persze nem vagyok biztos benne, hogy ezt kell használni egy külső elektronika cpu-ra felkötéséhez. Ennek az egész hóbelebancnak a szoftveres hátteréről egy deka szót sem találtam. A fejlesztői környezetet a csomagban adják a cpu-hoz dvd mellékleten? Kimaradt még valami fontos, amire nem is gondoltam?
Az STL nyelvnek most kezdek utánaolvasni. Köszönöm a tippet.
-
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). -
#95092224
törölt tag
Amennyire elnézem én ezt a modbus témát, tényleg nagyon rosszul álltam hozzá. Akkor megközelítem másik oldalról. Egyenlőre csak tegyük fel eset.
Tegyük fel vásárolnék egy PLC CPU-t egy kifejlesztendő elektronika tesztelésére. Kicsit bele kellene rázódnom a programnyelvekbe is (részemről az utasítás listás feküdne jobban, asm / c-s vagyok). A CPU-ra csak egy olyan egyszerű programot kellene megírnom, ami egy hozzá kötött modbus-os elektronika egyik állapot regiszteréből adatot olvas, és ír oda vissza. Igazából semmi mást nem is kell tudnia, csak ezt ciklusban. Van hozzá laptop, winXP, a többiről gőzöm sincs. Azt vennem kell. Utolsó tápegység és csatlakozó kábelig mindent a nulláról. 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. Szóval az elején kellene kezdenem, mert valami nagyon zöld ebben az egészben.
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?
-
Szirty
őstag
válasz
sörösló
#1853
üzenetére
Hali sörösló!
Nálunk is van pár kövület a régi gyárban. Több S5 is pl.
De van két Omron C120 is pl. (az egyik maximális kiépítésben) meg egy Omron C1000H.
Jól elvannak azok is. A relés kimenetek cseréjén és néhányszori tápegység cserén kívül semmi bajuk. (Van pár relés kimenet, ami naponta 10000 kapcsolást művel). Kb fél évente a relét cserélni kell, de amúgy jól elvannak. -
sörösló
aktív tag
Van nálunk egy 1980-ban gyártott AEG Modicon 864-es. Sihederkorában még javában Cocom listás katonai cucc volt. Azóta bejárta Belgiumot, Franciaországot, Romániát, végül kikötött Magyarországon. Szótlanul teszi a dolgát, legfeljebb azt sérelmezi ha néhány napig kaja nélkül marad. Nem is kapcsoljuk ki soha, így lehetséges hogy még engem is túlél.
-
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. -
#95092224
törölt tag
Szerintem (a válaszodból ítélve) félreértetted a lényeget
Hát tényleg nem értem. Pedig én már sok dolgot nem értettem.Más. Még egy ModBus kérdésem lenne. Az Application Protocol nem köti le szabványban, hogy egy CPU üzenetre mennyi időn belül kell kötelezően nyugta üzenetet küldenie a megcímzett perifériának, csak az van kikötve, hogy kell rá küldeni nyugta üzenetet. Figyelmeztetésként is csak annyi van, hogy:
Note: It is desirable to manage a time out in order not to indefinitely wait for an answer which will perhaps never arrive.
A jelek szerint ezt a késleltetési idő dolgot program szintről szokás lekezelni. Olyan doksikba még nem ástam bele magamat, szóval nem vagyok képben, mennyire kényelmes / kényelmetlen dolog egy elhúzódó nyugta üzenetre várni? Gondolok itt arra, hogy a független folyamatoknak zavartalanul mennie kell tovább, csak azt az egy folyamat ágat le kell stoppolni. Meg lehet tenni ezt különösebb megizzadás nélkül akár az idők végtelenségéig?
-
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
#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". -
#95092224
törölt tag
Modbusos elektronikát kellene gyártanom, és ásom belefele magamat a szoftver / elektronika kapcsolat lehetséges problémáiba.
Azt a bizonyos DWord, DInt, REAL (32 bit) típust képes úgy kezelni, hogy modbusra kapcsolt elektronika állapot regisztereibe simán csak beleírni egy lépésben? 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?
-
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)..
-
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.
-
#95092224
törölt tag
Kezdő kérdés PLC nyelvekről. Milyen szélességű adatokat kezelnek? 16 vagy 64 biteseket?
Eddig csak a modbusba ástam bele magam, az a világ full 16 bites a legújabb doksik szerint. A PLC elektronikák viszont 64 / 128 bitesek. Szóval kicsit értetlenkedem.
-
dekorn
csendes tag
Szia Szirty!
Ami volt nekem nem is olyan rég problémám ill. észrevételem , azt sikerült lemodeleznem újból. A problémám a következő van egy FB blokom amibe új stat változókat vittem fel. amikor kész volt az FB utána próbáltam beírni a DB-be de sehogy se ment ezért kitörültem a régit és generáltam egy újjat, azonban ezekután mikor az OB1 eset megnyitottam offline akkor az FB blokra való hivatkozás a következő képpen íródott át magától:
Call
BLD 3
= L 25.0
CDB
OPN DI 114
TAR2 LD 21
A M 28.0
= DIX 0.0
A M 28.1
= DIX 0.1
A M 28.2
= DIX 0.2
LAR2 P#DBX 0.0
UC FB 114
LAR2 LD 21
CDB
BLD 4
End Call
ezt persze hibásnak találta de mitán ezt kitörültem és beírtam neki az eredeti Call parancsort akkor azt elfogadta és minden oké.
Kérdésem lenne, hogy miért nem tudtam módosítani a DB-t ,és ha lehet hogy lehet? Az OB1-be miért ugrik így szét a call hívás és hogy ez normális dolog a Step 7 ben vagy valamit nem állítottam be? Előre is köszönöm a segítségeket. -
covekcbr
csendes tag
Hali!
Szeretnék kérni valakítől segítséget. Wincc Flexible-vel kapcsolatban, elég új vagyok a témában Siemens PLC-kel foglalkoztam, de Wincc Flexible-vel még eddig sosem, és szeretnék jobban megismerkedni vele. Ha esetleg valaki tudna egy oktatóanyagot hozzá, vagy leírást küldeni vagy megmonani honnan lehet megszerezni, nagyon hálás lennék. Köszönöm!
-
-
dekorn
csendes tag
Szia Szirty!
Köszönöm a választ. Szóval csak annyit csináltam hogy az egyik FB egyik NWjében egy timer FB meghívásának idő beviteli módját változtattam meg , hogy azt a Scada-ból lehessen állítani. Ehhez plusz két változót kellett létrehoznom a statba az ellőbeolvasáshoz a két idő összehasonlítása miatt. Azonban ez a rész nem is volt problémás azonban már itt is hibát jelzett a STAT elemek között volt egy FB meghívás amit újra kellett deklarálnom és csak ezután lett oké, de ehhez a részhez nem is nyúltam.Most az jutott eszembe még hogy lehet hogy hiába a letöltött projektel dolgoztam mégis a DB blokkot átmásoltam egy eredeti projektből ahol azt átalakítottam, mivel az symbolum listával rendelkezett. Hát nem tudom mi lehett a pontos dolog ami kiváltotta a problémát , mondjuk engem csak az OB1-es blokkban a call rész magától való átalakulása call ... end call osra zavar csak. Lehet hogy ott az volt a probléma hogy az FB blokkot változtattam , de a hozzá tartozó DB-t nem? És ha egy instant DB okozhat közvetetten más FB blokk hibássá válását? Szóval jobban utána kell néznem ezeket a viszonyokat az FB és az instant DB között. Hát ha van valami tipped akkor azt megköszönöm , meg ha produkálom a jelenséget akkor ledokumentálom a lépéseket.
-
Szirty
őstag
Hali dekorn!
Ha egy FB-hez instance DB is tartozik, és az FB blokkot úgy módosítod, hogy a blokk interface részét megváltoztatod oly módon, hogy STAT, IN, OUT vagy INOUT változót törölsz, felveszel, ezek sorrendjét, típusát vagy nevét megváltoztatod, tehát szinte bármit csinálsz ezekkel, a blokk "inkozisztensé" válik. Ha ezután megnyitod azt a blokktot, ami a módosítottat hívta, akkor jön a hibaüzenet és a pirossal jelölt hívás a programban. Meg akár a CPU STOP is ha menet közben csinálod.
Ennél pontosabbat akkor tudnék rá írni, ha ennél pontosabban tudnám hogy mit változtattál... -
dekorn
csendes tag
Sziasztok!
Olyan problémám lenne , hogy egy S7-300 317-2DP-és PLC-én módosítottam két FB blokkot (minimális módosítás)és az egyikhez a módosított DB-t is feltöltöttem(felülírtam), ezek után monitorozni akartam online a DB blokkba Saitek Scada felületről bevitt értékeket, ekkor kérdezett egyet amit leokéztam és ment a folyamat. Két érdekesség történt , mégpedig hogy az offline módosításnál mikor az FB-be két stat értéket bevittem akkor az OB1-esbe a rá hivatkozó call magától átíródott egy hosszabb call ... end call részre amit sajna nem mentettem , mert kitörültem és miután újra simán beírtam a call parancsot akkor úgy maradt és elfogadta. Ez a dolog csak akkor lett érdekes mikor egy teljesen más FB blokk ugrott így szét magától amihez nem is nyúltam. Ez volt az egyik érdekesség , a másik talán csak az én tudatlanságomból fakad, hogy time stamp hiba miatt nem akarta menteni az OB1-et csak miután a hibásnak jelzett részt cntr+x-el kicuttoltam és utána undo-ztam egyet és ezzel elfogadta a call részt. Valószínű hogy ezek az érdekességek abból is fakadtak , hogy én egy eredeti projektbe terveztem át az FB blokkokat és , mivel csak a letöltött PLC programmal akart csak kapcsolatot teremteni az interface (connection can't estabilished valami ilyesmi volt) , ezért abba kellett átillesztettem a módosított részeket. Kérlek segítsetek megérteni nekem az FB és DB blokkok eme lelkivilágát , mert ugyan megoldottam a problémát és a PLC megfelelően működik , de szeretném ezeket a dolgokat tisztán látni. Bocsi ha egy kicsit összevissza lett a leírtak logikája, de sajna ott csak az volt a lényeg hogy mennyen a progi, így nem foglalkoztam ezzel.
-
Szirty
őstag
válasz
levelko
#1830
üzenetére
Hali levelko!
"Nem ezzel az egy network beszúrásával van gond, hanem hogy a gépet nem állíthatom meg, tehát a CPU-t nem kapcsolhatom STOP-ba."
Alapvetően az nem probléma, hogy a programot futás közben módosítod.
Egyszerűen átírod a megfelelő blokkot (berakod a kimenet bekapcsolását) és utána rátöltöd a CPU-ra azt a blokkot, miközben a kapcsolója RUN-P állásban van (RUN állásban nem engedi).Ha először csinálod, célszerű az aktuális programot a módosítás előtt a PLC-ből kiolvasni és lementeni (programot és az adatblokkokat is).
A következő pár dologra kell odafigyelni:
- Az az offline blokk, amit módosítasz, legyen aktuális. Tehát a módosítás előtt tökéletesen legyen azonos, azzal, ami a PLC-ben van. Esetleg a módosítást ONLINE is végezheted, de ezt nem javaslom.- A módosítás ne tartalmazzon durva programhibát
Pl. ha elírod valamelyik címet (olyan merkert timert, kimenetet stb-t címzel ami az adott CPU-ban nincs) és nincs a CPU-ban Programming error OB, (vagy van, de az ki tudja mit csinál) akkor lehet gond. (pl. hogy STOP-ra megy).Ha a programmódosítás egyszerű, mint ate esetedben, akkor ez nem lesz probléma.
Hogy a 314C-nél konkrétan hogy van nem tudom, de a memória kártyára a projectet csak úgy tudod átmásolni, ha a CPU-t leállítod.
Ezt a Simatic manager PLC menüjében lévő Copy RAM to ROM menüpontjával teheted meg. Újabb CPU típusoknál asszem nincs már ilyen lehetőség.
Szóval ha ez a régebbi fajta és kell a copy RAM to ROM, akkor ki kell várni a lehetőséget a gép leállítására. De addig is működhet a módosított programmal... -
levelko
csendes tag
Üdv!
Ezzel kapcsolatbam szeretnék kérdezni. Adott egy S7 314C 2DP CPU. A programban megközelítőleg 80 funkció és adat blokk van. Többször monitoroztam már hibakeresés céljából több kevesebb sikerrel, de ezidáig módosítást csak a gépgyártó (német) végzett a saját PG-jével. Most azonban feladatként kaptam egy kisebb módosítást. A feladat annyi lenne csak hogy egy szabad kimenetet hozzárendeljek néhány belső változóhoz. Nem ezzel az egy network beszúrásával van gond, hanem hogy a gépet nem állíthatom meg, tehát a CPU-t nem kapcsolhatom STOP-ba. Alap esetben RUNP-be van kapcsolva. OMRON és MITSUBISHI CPU-kon már csináltam ilyet minden gond nélkül, de S7-hez nem igen vettem a bátorságot. Tehát hogyan tudom úgy módosítani valamelyik FC blokkot, hogy ne legyen baj? Ráadásul memória kártya is van benne, tehát úgy kellene módosítani hogy oda is rákerüljön, ha esetleg teljes tártörlést csinálna valaki.
Köszönettel. K.L.
-
Szirty
őstag
Hali Atok79!
A dolog egyszerű, ha a PLC-ben lévő program nincs jelszóval védve. (nem a blokkok knowhow védelemére gondolok).
Összekötöd a gépedet a PLC-vel megfelelő módon. Gondolom ha foglalkozol 300-asokkal hibakeresés okán, akkor ez nem okoz gondot, nem írom le.
Elindítod a Simatic managert. Létrehozol egy új projectet (De nem a wizard segítségével!): File menü/New parancs.
Lesz egy üres projected, amiben semmi nincs, csak egy MPI(1) nevű objektum.
Kiválasztod a PLC menüből az Upload Station to PG.. pontot.
Kapsz egy Select Node Address ablakot.
Ennek a formája függ attól mi van beállítva a PG/PC interface-ben. Ha profinetre dugtad rá a PC-t és ethernet van kiválasztva, akkor meg kell adnod a PLC IP címét. Ha profibusz vagy MPI busz van kiválasztva és arra dugtad rá, akkor a profibusz vagy MPI címet kell megadnod. A View lehetőség segít megtalálni.
Ha ezután OK-t nyomsz, akkor áttöltődik minden a PLC-ből a gépedre és létrejön egy project. Benne lesz a hálózat konfig a HW config, minden, kivéve a szimbólum táblát, a DB blokkok szimbólum neveit és a kommenteket. Azok nem lesznek benne (A PLC ezeket nem tárolja). -
Atok79
csendes tag
Kedves Szirty. A segítségedet szeretném kérni abban, hogy volna egy S7-300-as plc, profinet csatlakozási felülettel. A forrásprogram nincs meg, hogyan tudnám kiszedni a plcből a programot? Sajna a siemens plc-khez inkább csak hibakeresés okán kellett ezidáig hozzá nyúlnom, viszont ott mindig megvoltak a pg-n a programok..
A segítséged előre is köszönöm, üdv:Sanyi. -
sörösló
aktív tag
-
#95092224
törölt tag
Kicsit más téma.
Fényképen látok narancs-fekete olajos-zsíros-mocskos dobozt, rajta billentyűzet panel, kijelző, meg egy felirat, hogy "Fanuc 16", "Fanuc 32". Kellene nekem valami egyszerűsített rendszertan arról, fejlettségi szinten hol is tarthat az, ami a burkolaton belül van. Egyáltalán már digitális CPU-ja és rendszer sínje van, vagy még külön egységekből van összekábelkorbácsolva az egész mákostészta módjára?
Kotorásztam neten, de a jelek szerint ez már nem mai technológia. Vagy ha az, engem biza elárasztott a bőség zavara (meg a sok tonnás mellébeszélés). Bízom benne, itteni szakik még emlékeznek ilyesmire, és rövid úton be tudnak tájolni.
Köszönöm.
-
sörösló
aktív tag
válasz
Dezsi82
#1823
üzenetére
Egyről beszélünk mi, Barátom! Nem csak a gépész lehet hülye hanem a villszer is. Szakmai kultúra vagy annak hiánya a lényeg, nem a képzés iránya. Ha a megrendelő nem kéri a foráskódot és egyebeket, az az Ő dolga. Hív téged ha gondja van, ez is teljesen OK. Ott a problema amikor nem kell a forráskód, de a saját embereimtől várom a tudást hogy ne kell- jen Téged hívni, infót meg nem adok hozzá! Nálunk most kezdenek erre rájönni. A gyártó cégtől annyiért jön egy hétre a technikus amennyiből engem két hónapig tartanak! Neki van szervizkönyve, nekem nincs. Nem okosabb nálam (sőt), csak neki van információja és "telefonos segítsége" nekem meg nincs. Telepítettünk anno egy német nyomdagépet. A skacok sokszor széjjelhagytak éjszakára laptopot, szerszámot meg mindent amit csak el tudsz képzelni. De volt nekik egy kb. 800 oldalas doksijuk, na azt addig sem hagyták szem előtt hogy beleolvassak! Ha elkértem, csak a mutató és a hüvelykujjukat dörzsölgették össze. Money Brother, money...
-
Dezsi82
tag
válasz
sörösló
#1822
üzenetére
Szia!
Annak ellenére, hogy nagyjából egyetértek veled, gondoltam nem hagyhatom szó nélkül a másik oldalt se.
Én is láttam már villanyszerelőt golyósorsón, meg lineáris csapágyon állni. És persze neki az tök mindegy, mert állni lehet rajta, bár kicsit zsíros a nyavalyás. Mozgás közben meg lejön a kosz, igaz visszaegyenesedni nem fog. Általában az ember saját területén jártas, és annak ellenére hogy némi ésszerű viselkedés elvárható, lehet az illető bele sem gondol.
Vagy programozásnál mondhatnám példának azt a német kollégát, aki Siemensben 150 szerszámhoz képes volt 150 létrát összehozni, ahelyett, hogy egy NW-ben kb 10 STL utasítással megoldotta volna dolgot.
Meg aztán a forráskód átadása sem egyértelmű dolog. Van jó pár olyan megrendelőnk, akik nem akarják a forráskódot, mert nem is értenek hozzá, emberük sincs aki akár meg is tudná nézni. Így inkább azt mondják, működjön a rendszer, legyen olcsóbb a program, de minket hívnak ha gond van.
És én is elég sok olyan PLC programozót ismerek, akik csak programozásban jártasak, és nem értenek az érzékelőkhöz, aktuátorokhoz. De vannak olyan cégek, ahol van programozó, és van beüzemelő. A programozó megírja a program gerincét, struktúráját, a beüzemelő pedig elvégzi a helyszínen a kisebb módosításokat, beállításokat. -
sörösló
aktív tag
Közben rájöttem a "nem villamos beállítású" kifejezés értelmére. Az ilyen programozó bármely érzékelőt matematikai úton közelít meg! Két eset lehetséges a bináris logikában: igen vagy nem. Tiszta ügy, más lehetőség NINCS! Én láttam már induktív érzékelőt létrának használva; a gépészember máshol nem tudta megvetni a sarkát olyan kényelmesen. A valódi létra meg messze volt, bent a műhelyben. Ráállok, ha már kiáll! Ha letörik, akkor nem szólok ám mert még megtisztelik néhány keresetlen kifejezéssel a szegény mamát az elektromos gecik. (Bocs a kifejezésért.) Útban van a kis szervomotor, amihez optikai kábeles jeladó meg mittoménmi csatlakozik. Négy csavar tartja, hát leszerelem. Amíg szerelek, addig elfityeg az ott magának azon a két szál narancsszínű dróton (ez az optikai kábel). Basszus, melléütöttem a baltával! Kicsit belengett na! Elkaptam idejében, le se szakadt, most mit rinyálsz! Szóval valahogy így megyen ez gyakorlatice, Kedves Uraim! Kaland az Élet, szó se róla...
-
sörösló
aktív tag
Akkor tényleg utoljára.
" Főleg németeknél látom, azoknál akik tisztán programozok, és nem villamos beállítottságúak."
Na ezt soha nem tudtam felfogni. Hogy a ***Máriába programoz valaki elektromos vezérlést, ha nem 'villamos beállítású'? Hát milyen? Szövőnői, kutyaidomítói vagy mi??? Ha valaki SCADA rendszerekben spéci, akkor még megértem hogy az üzemi rendszerek felett lebeg , hiszen éppen ezeknek az integrálása a szakmája lényege, érhetően nem feladata a vezérlések érzékelőszintű ismerete. Azért nem hátrány, ha a folyamatoknak legalább a lényeges részeit ismeri.
A másik, amit azóta sem bírok megemészteni:' Magyarország leragadt a létránál'. Szuperjól állnánk, ha már csak ez lenne a legnagyobb probléma. Sajnos a magyar 'szakemberek' jó része még azt sem tudja hogy merre lehet az a bizonyos "létra"!
Házat építeni még nem tudunk, de a tetőre szánt szélkakas aranyozása már nagyon jól megy. -
sörösló
aktív tag
Hali, Szirty! Összefoglalnám.
""Az általad felállított szempont is lényeges, de sokszor fel sem merül." Úgy mondanám hogy szinte sohasem.
"a fejlesztő (szerzői jogi okokra hivatkozva) egyszerűen megtagadja a forrásanyagok átadását a berendezéssel együtt." Ez sajna így van mindig, ha nincs jelen szakember a szerződéskötésnél. Normális esetben kikötik a dokumentáció tartalmát, a kommentezett program átadását stb. Ennek persze ára van, amit lehet megtakarítani, de később majd drága lesz!
"Egyes rendszerek támogatják a program jelszavas védelmét és titkosítását is."
Még a leggagyibb programozható relék is tartalmazzák a titkosítási lehetőséget. Itt van megint az üzleti szellem. Ha már fizetek, akkor meg kellene nézni hogy miért. Ha nem adod a foráskódot, a kinyomtatott és felkommentezett programot, akkor nincs bót! Majd megveszem, ha azt adod amit szeretnék. Sajna az ilyen üzletkötéseknél a legritkább esetben van jelen olyan ember, aki tisztában van az ilyen dolgokkal. De ez már messze nem programozási probléma, hanem OFF a topicban, úgyhogy abba is hagyom... -
Szirty
őstag
válasz
sörösló
#1814
üzenetére
Üdv!
"Pontosan a karbantartás és a hibakeresés az a terület, ahol nem mindig 'teljes az adatbázis'. Itt kell egyszerű, sokak által megérthető módon programozott módszereket használni."
A program írás sokféle szempont figyelembevételével történhet. A legfontosabb, hogy az előállítónak olcsó legyen és gyorsan kész legyen, a megrendelőnek, hogy működjön.
Az általad felállított szempont is lényeges, de sokszor fel sem merül.Sőt sok esetben épp az a szempont, hogy a lehető legjobban megnehezítsék a programba való belenézést, vagy annak módosítását.
Néha ezt elég egyszerűen megtehetik, pl. úgy, hogy a fejlesztő (szerzői jogi okokra hivatkozva) egyszerűen megtagadja a forrásanyagok átadását a berendezéssel együtt.
Egyes rendszerek támogatják a program jelszavas védelmét és titkosítását is.
Úgyhogy nem egyszerű az élet....és azt is tudjuk, hogy se tökéletes program se pedig kész program nem létezik
-
sörösló
aktív tag
Jaj, drága barátom! Hát pont erről beszélek!
"Csupán azokat a részeket, ahol az "előnyös" lehet (sok szempontot megnézve pl. karbantarthatóság, hiba keresés)."
Pontosan a karbantartás és a hibakeresés az a terület, ahol nem mindig 'teljes az adatbázis'. Itt kell egyszerű, sokak által megérthető módon programozott módszereket használni. Jómagam egyszerű műszerészként a relés vezérléstől jutottam el a PLC-ig. Nem vagyok nagy szakértő, a tevékenység jórészt csak a monitorozásig terjed. Persze írtam már 80-100 IO-s programot (ami csak ujjgyakorlat a Szirty által alapként említett 500-600 IO terjedelmű programhoz képest), de sokféle gondba belefutottam már. Amint már említettem, sokszor a 'fényesagyú' mérnök is eltéved a saját maga ültette erdőben. Ne bonyolítsuk azt amit nem muszáj! Ezt mint gyakorló karbantartó kérem tőletek, a jövő mérnökeitől! -
oli83
tag
Így van. Megszokás kérdése.
Tudom nem illik, de most megismétlem magam:
"Mindent ott kell használni, amire azt kitalálták."
Lehet, hogy az előbb félre értettetek. Nem arra gondoltam, hogy az egész progit scl-ben kell megírni. Csupán azokat a részeket, ahol az "előnyös" lehet (sok szempontot megnézve pl. karbantarthatóság, hiba keresés).oli83
-
Szirty
őstag
Hali oli83!
"Egyébként 300-asoknál van olyan eset pl. hogy FUP-ba megvan írva valami, és azt nem lehet átfordítani KOP-pá. Azszem ez a bemenetre visszacsatolt (#) fordul elő. Biztos fordított esetben is van ilyen."
Az ilyesminek mindig az az oka, hogy a létradiagram megjelenítési szabályai nem teszik lehetővé a megjelenítést.
Más szóval: létrában lehetetlen megjeleníteni.
Ilyen pl. az az eset is, amikor van egy több tagból álló soros (ÉS) kapcsolat, aminek az egyik tagja egy timer.
Ha az ÉS kapcsolatok sorában a timer az első, akkor megjeleníthető létrában, ha nem az első, akkor már nem. Ez még egyszerű eset, mert ha ezt FBD-ben átírjuk úgy, hogy a timer az ÉS kapu legfelső bemenetén legyen, akkor onnantól már meg fog jelenni létrában is. A feltételsor végeredményét ez nem befolyásolja. Több ilyen eset is van, de nem mindegyiket ilyen egyszerű létrásítani.Mellesleg véleményem szerint az FBD megjelenítés egy fikarcnyit sem fejlettebb a létradiagramnál. (Ha már ott tartunk, hogy leragadt az ország a létránál
Egyszerűen csak egy másik megjelenítési módja ugyanannak a dolognak, de kissé eltérő szabályokkal. Nem jobb vagy rosszabb, (műszaki tartalom szempontjából) csak más.Szerintem FBD-t sem nehezebb átlátni mint a létrát, csak hozzá kell szokni.
-
Szirty
őstag
Hali norcee!
"Teljesen egyetértek azzal, amiket írtál, bár a suliban az első ilyen felvezető órán ahol ismertették, hogy mik lesznek a félévben, ott elmondták, hogy az egy nagyon szomorú dolog, hogy Magyarország "csak a létradiagramnál tart"."
Aki ezt kijelentette, annak azt üzenném, hogy kicsit ki kellene mozdulni és szétnézni. Nem, nem az interneten, hanem egy gyárban, ahol olyan berendezéseket üzemeltetnek, amire a programozására a fent idézett mondatban utalt. Úgy tűnik, csak elméleti szinten foglalkozik a témával. Már bocsánat, de ostobaságot mondott.
Úgy gondolom, hogy az elvégzett munka minőségét nem az elvégzéséhez használt eszközök fejlettsége vagy minősége, színe, szaga, vagy a drágakőberakások száma határozza meg. Ha ez egy program, akkor a legfontosabb annak hatékonysága!
Vagyis az, hogy a feladatot, aminek elvégzésére rendeltetett milyen hatékonyan képes ellátni.Szerintem a PLC programozási nyelvek (mint ahogy maga a PLC is) erősen specifikusak, cél-orientáltak. Vagyis kimondottan egy szűk feladatkörre fejlesztették ki. Azt a feladatot amire készült igen hatékonyan képes ellátni, de ettől eltérő feladatra nem lehet hatékonyan alkalmazni, vagy teljesen alkalmatlan rá.
Kinek okozok meglepetést azzal, ha azt is kijelentem, hogy a létra / funkcióblokk kifejezetten alkalmas hosszú és összetett logikai feltételsorok programozására?
Az SCL teljesen másra való! Nem írom le még egyszer, másik hozzászólásban megtettem már.
Akinek meglepetést okoztam valamelyik kijelentésemmel, az nyugodtan próbáljon meg 400-500 (csak hogy ne legyen túl sok) logikai feltételből álló programot írni.
Egy percig sem állítom, hogy nem lehet SCL-ben megcsinálni, de abban biztos vagyok, hogy se könnyen áttekinthető nem lesz, se hatékony, se könnyen megírható.Ha szöget kell beverni, használjunk kalapácsot. Ha kommunikálni akarunk, használjunk telefonkészüléket.
Aki fejlett, az mobillal veri be a szöget, és kalapáccsal kopogtatja a fűtés csövet ha kész az ebéd? -
oli83
tag
válasz
sörösló
#1808
üzenetére
Szia Sörösló!
Szeretném leszögezni, hogy nem azért vagyok itt hogy vitatkozzak.
Pontosan tudom, hogy mire gondolsz. Írtam már újra olyan logo vezérlést, amit enyhén szólva is túlbonyolítottak. Egy rajzlap volt, teli pókhallóval.
A szépség pedig az volt benne, hogy tervező: kapuzott, karbantartók: létráztak, és minden egyes átfordítás után egész máshogy nézett ki a logika. Kommentár noku.
Persze utána mindig jött a fejvakarás, hogy mi is volt, hogy is volt.
Én is létra párti vagyok, megírtam nekik létrába, és kikötöttük, hogy csakis létrába szabad tovább írni. Ennyi.
De, dolgoztam olyan helyen is, ahol viszont a kapuzás volt az elfogadott. Főleg németeknél látom, azoknál akik tisztán programozok, és nem villamos beállítottságúak.
Egyébként 300-asoknál van olyan eset pl. hogy FUP-ba megvan írva valami, és azt nem lehet átfordítani KOP-pá. Azszem ez a bemenetre visszacsatolt (#) fordul elő. Biztos fordított esetben is van ilyen.
De ha már itt vagyunk, olyan karbantartót se láttam még, aki panaszkodott volna a Gráf miatt. Van olyan helyzet, amikor az átláthatóság miatt áldozatot kell hozni.oli83
-
norcee
csendes tag
válasz
sörösló
#1808
üzenetére
Szia sörösló!
Teljesen egyetértek azzal, amiket írtál, bár a suliban az első ilyen felvezető órán ahol ismertették, hogy mik lesznek a félévben, ott elmondták, hogy az egy nagyon szomorú dolog, hogy Magyarország "csak a létradiagramnál tart". Ha a dolognak azt az oldalát nézem, hogy így megismerhetünk olyan nyelveket, amiket esetleg önszorgalomból nem -mivel nem feltétlen lenne rá szükségünk - de esetleg valamikor találkozhatunk velük, akkor az egy jó dolog. Nekem viszont az jött le a dologból, mint amit te is említettél, hogy valamiféle "tudományoskodó akármi" van emögött, hogy de már pedig ezzel kell mert ez az egzakt ez a jelen... Ha jól tudom az SCL és a GRAPH azok külön szoftverek, amiket gondolom borsos áron is lehet megvenni. Nem tudom, hogy hogyan működik de azt feltételezem egy gazdasági osztályról, hogy ha van három-, akkor nem biztos, hogy ad pénzt a negyedik programozási nyelvre is
, így megint a létra nyert, de látod mégsem ez kell...--norcee
-
sörösló
aktív tag
oli83:
"De azért lehet törekedni, nem muszáj megállni egy szinten. Fejlődni muszáj......"
Ebben tökéletesen igazad van. De! Mondok egy gyakorlati példát. Adott feladat: egy szeget kell bejuttatni a deszkába. Egyik módszer hogy odakensz egyet a kalapáccsal. A fejlődés miatt meg lehet építeni egy bonyolult hidraulikus rendszert abszolút útmérővel és proporcionális szeleppel stb. A további cifrázást a fantáziádra bízom. Szépséges megoldás meg nagyon fejlett meg minden. Hú de okosak vagyunk! Na de minek, amikor a végeredmény ugyanaz? Sajnos sokszor találkozni ilyen túlagyalt dolgokkal pl. német csúcsgépekben. Szervomotor hajtja még az egyszerű ventilátort is, aztán megengedi a gép összetörését egy olyan egyszerű esetben is, amikor egy jeladót kellene látni ahhoz, hogy egy bizonyos mozgást engedélyezzen. Nem látja a jeladót de megengedi a ráközelítő mozgást. Úgy programozta, hogy ha odaér, akkor majd meglátja és megáll. Elmozdult a jeladó, nem látta meg és nem állt meg. Jé, összetört a masina. Nahát, ki a fene gondolta. Ilyen még sosem volt. Hát most lett! Francia mintavevő, előre programozott helyeken megáll meg minden, nagyon okos. A munka végén parkhelyzetre megy. Kissé lötyögős a mechanika, nem vette észre a jeladót. A gép végénél nem tud továbbmenni, de makacsul próbálkozik véghelyzetet keresni, amíg a motor le nem ég. Mondom a francia mérnöknek: nem kéne ide esetleg egy futásidőfelügyelet? Úgy nézett rám, mint bantunéger az atomreaktorra! A szakmai szótárából ez a fogalom egészen egyszerűen hiányzott. Megmagyaráztuk mire gondolunk, megértette, megcsinálta De egy ilyen hóttegyszerű alapfogás egyszerűen nem jutott az eszébe magától. Szóval csináld SCL-ben ha másképp nem megoldható, de létrázz, ha az is elég. A német bonyolítás iskolapéldája a LOGO. Programozható relé hülyegyerek villanyszerelőnek. Minden más gyártónál a létra az alapnyelv, a LOGO-nál nem. Ó dehogy. Alapból funkcióblokk! Én a TTL logikán nőttem fel, ismerem a blokkokat, de a legtöbb villanyszerelő sose látott ilyet. Ránéz és azt mondja: nekem ez hottentotta. Mondom neki, kapcsold át létrába! Ja ezt is lehet? Szóval ez van... Sok sikert a Való Világban! -
oli83
tag
válasz
sörösló
#1805
üzenetére
Keményen fogalmazol.
Persze részben igazad van. Mindent ott kell használni, amire azt kitalálták.
Minél egyszerűbb, átláthatóbb annál jobb.
Mondjuk sok helyen ezért is alkalmaznak előírásokat, hogy rögzítsék miben, hogyan, miként szabad programozni. Ezek néha idegesítőek, de nem alaptalanok.
De azért lehet törekedni, nem muszáj megállni egy szinten. Fejlődni muszáj...... -
sörösló
aktív tag
Szerintem ez is iskolapéldája annak hogy hogyan nem lenne szabad oktatni ezt a dolgot. Volt már ilyen problémám, az illető azt mondta: "te alulról közelíted meg a PLC programozást, a gyakorlati oldala felől, én meg az elmélettől haladok a gyakorlat felé. Az alapvető vitánk a Grafcet programnyelv volt. Ő értette, mi, akiknek esetleg csak monitorozás szintjéig lett volna szüksége a dologra, nem egészen. Ha nem világos valami, majd szóljatok.- mondta Ő. De mi van ha esetleg elüt egy autó holnap? Hát majd valaki ír egy új programot! Az SCL is valami hasonló dolog lehet, nem értek és nem is akarok hozzá érteni. Ez olyan irányzat, mint a mikrovezérlők világa. A fejlesztő érti, olcsó meg minden, de ha kivülállónak kell javítani, akkor halál az egész. A főnök meg nem érti hogy mit nem lehet egy ilyen egyszerű kis valamin érteni. Tenyérnyi kis panel, néhány alkatrész... egyszerű eset. Ha megvan az eredeti fejlesztőkörnyezet, akkor talán. Ha nincs, akkor max. az Eeprom-ból ügyesen kiolvashatod a féloldalnyi hexakódot. Aztán hogy ez most kisnyúl vagy magyarvizsla kutya, találd ki. Vagy nyersz hangszórót vagy nem. Az egyszerű mezei technikus szepontjából a legrémületesebb a "fekete Doboz". Azt tudod,hogy mi megy be. Azt is tudod, mi jön ki. Hogy eddig kolbász jött ki, most meg miért hurka, csak akkor tudod esetleg megérteni, ha belelátsz a konyhába. Ha nem, akkor hiába veri az asztalt a kedves vendég, csak a válladat vonogathatod. Másik megoldás az eredeti fejlesztő mérnökét hívni. Ez egyrészt drága, másrészt nem biztos hogy ráér vagy még egyáltalán a cégnél van-e? Ezért rokonszenves bizonyos szempontból a távolkeleti szemlélet. Alap a létra, spec megoldásokat előreprogramozva kínál, lehetőleg bolondbiztos és bizonyos szintig viszonylag egyszerű. Mezei embereknek is szól nemcsak fényesagyú spéciknek akik nem mindig érnek rá.
-
norcee
csendes tag
Szia oli83!
Az inkább gyakorlatiasabb fővárosi suliról van szó. Siemens, Omron, Modicon PLC-k vannak a suliban, ezért programozási nyelveket, ill. a programtervezés lépéseit fejlesztőkörnyezettől függetlenül általánosságban tanítják, a hallgatók feladata, hogy a fejlesztőkörnyezeteket megismerjék. A strukturált szöveggel kapcsolatban a már meglévő C nyelvű ismeretekre hivatkoznak a gráfhoz adtak némi segédanyagot, hogy milyen step-ek, elágazások... vannak. Ha gondolod ezt szívesen elküldöm.
--norcee
-
#1803
Szirty
őstag
01101010111
#1802
Szirty
őstag
válasz
01101010111
#1802
üzenetére
Hali!
"LAD meg a FBD szimpatikusabb, de az SCL sokkal tömörebb. "
Ez nem szimpátia kérdése, mindegyik alkalmas valamire és van amire nem. Ennek alapján érdemes dönteni.
De igen értem, hogy érdeklődésből csinálod. Azzal nincsen semmi gond... -
#1802
01101010111
csendes tag
01101010111
csendes tag
Szirty: „Miért SCL-ben akarod megvalósítani?”
Csak a gyakorlás miatt. LAD meg a FBD szimpatikusabb, de az SCL sokkal tömörebb. Idővel szeretnék eljutni a CAN kommunikációig és ott biztos jó hasznát veszem.norcee:
FUNCTION_BLOCK FB3
VAR_INPUT bemenet
YTE; END_VAR
VAR_OUTPUT kimenetYTE; END_VAR
VAR mYTE:=0; END_VAR
kimenet:=(bemenet XOR m) AND NOT m;
m:=bemenet;
END_FUNCTION_BLOCKKöszönöm a tippet, megcsináltam már úgy is, de végül sikerült azt a 8 boolt is összeolvasztani egy byteba, igaz kissé nyakatekerten, nem túl szépen.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Szóval van egy megbízás X gépre első körben, és ha nagyon nem jön be, akkor a második ütemet törölni fogják. Ez előfordulhat. De az elsőt akkor is kifizetik. Azért az is csak pénz.
YTE; END_VAR
Na az tuti. Amúgy nincs velük semmi bajom, csak kerüljenek el jó messziről...Új hozzászólás Aktív témák
- MSI Katana 2 év garival, bomba áron!
- Apple iPhone 16 Pro Max 256GB 99% Akku! Újszerű,Dobozos,Tartozékaival! 1 Év Garanciával!
- Samsung Galaxy A56 5G 8/256GB Újszerű,Kártyafüggetlen,Dobozos,Tartozékaival! 1 Év Garanciával!
- Logitech g920+ váltó
- Kingston HyperX KHX8500D2BK2/4G DDR2-1066 MHz CL5 2 x 2 GB Kit
- Dell Latitude 5430 - i5-1245U, 16GB RAM, 512GB SSD, jó akku számla, garancia
- Apple iPhone 13 Pro 1TB,Újszerű,Dobozával,12 hónap garanciával
- LG 55B4 - 55" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready
- HP Thunderbolt-dokkoló, 120W G4 (4J0A2AA)
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest