Hirdetés
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Brogyi: CTEK akkumulátor töltő és másolatai
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- gban: Ingyen kellene, de tegnapra
- sziku69: Fűzzük össze a szavakat :)
- eBay-es kütyük kis pénzért
- droidic: Videó letöltés yt-dlp-vel (profi módszer)!
- vrob: Próbálkozás 386 alaplap újraélesztésre
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
#9021
And
veterán
Professzore
#9019
And
veterán
válasz
Professzore
#9019
üzenetére
Szia, a listádhoz:
- ABB: nagy folyamatirányító (DCS-) rendszereknél szeretik (hasonló pl. az Emerson, Yokogawa),
- Siemens: az S5 vagy két évtizede nem támogatott, már semmilyen formában nem beszerezhető. Már az S7-300/400 is kifutó sorozat.
Ami pedig kimaradt, pl.: Mitsubishi, Honeywell, Schneider.
Sok gyártónak van olcsó, Moeller/Eaton Easy- vagy Siemens Logo-szerű egyszerű PLC-je, programozható reléje. Egy átlagos PLC-fórumban - ahogy itt is - nagyon nagy arányban a Siemens a téma, pedig elég húzós áraik vannak, az S7-1200 sorozat talán a kivétel. A Schneider pl. eléggé hanyagolt errefelé, pedig nekik is széles a palettájuk, és némely sorozathoz még mindig lehet ingyenesen regisztrálható programot használni. -
And
veterán
válasz
DasBoot
#8831
üzenetére
XBTG2110: igaz, van ilyen is. Ezen viszont úgy tűnik, hogy USB sincs, csak két másik port. A felprogramozáshoz elvileg a Tool Portot (Mini Din) lehet használni XBTZG915-ös kábellel (a 935-ös USB-s kivitel). Ez a HMI nem túl friss, a v4.1-es vagy v4.3-as SoMachine / v6.2-es VijeoDesigner alatt ki sem tudom már választani.
Twido: ezt a típust előszeretettel használtuk, míg ki nem futott teljesen. Soros (TSXPCU1030) vagy USB-s kábellel elérhető, esetleg etherneten keresztül, de sajnos utóbbival a TwidoSuite sem tud csatlakozni Win7/10 alól. Így marad a dedikált adatkábel, vagy a WinXP + ethernet.
Adatkapcsolat a kettő között RS485 modbus protokollon:
- a HMI-n a COM1-en (DB25),
- a PLC-n pedig vagy a programozóporton (8p Mini Din), vagy az opcionális soros adapterkártyán (TWDNAC485D/T) illetve modulon (TWDNOZ485D/T) keresztül. -
And
veterán
válasz
DasBoot
#8828
üzenetére
Az XBTGT2110 - gondolom ez akart lenni - vagy úgy általában a Magelis HMI-k többféle módon is felprogramozhatók. Az adott típuson nincs ethernet (az RJ45-foglalat a COM2 RS485-port, nem ethernet) vagy kártyafoglalat, van viszont USB-host port, így pendrive-val (Vijeo Designer: file system beállítás) valószínűleg fel lehet programozni. Létezik dedikált USB-kábel is, XBT ZG935, amivel PC-re csatlakoztatható. Soros COM-porton tudomásom szerint nem lehet feltölteni ezeket.
A Twido-típust nem említetted, de ha ethernettel rendelkezik, akkor azon keresztül lehet csatlakozni hozzá program fel- és letöltés valamint modbus ethernet kommunikáció céljából. Ha jól rémlik, a TwidoSoft program - bár elindul akár Win10 alatt is - etherneten keresztül utoljára csak WinXP alatt volt hajlandó programot letölteni. A másik, ezt a sorozatot támogató program a TwidoSuite, az talán újabb oprendszerek alatt is képes erre, de azzal nincs ennyi tapasztalatom. MiniDIN 8-as (PC felől USB-s vagy COM-portos) programozókábellel természetesen az ethernettől függetlenül is működik. Amelyik Twido-n meg nincs ethernet, az kizárólag ilyen (egyébként relatív egyszerűen utánépíthető) kábellel szólítható meg. -
And
veterán
válasz
Marci0607
#7954
üzenetére
Egész pontosan milyen típusjelű CPU-hoz próbálsz csatlakozni, miféle kábellel és melyik portján keresztül? Ez azért lehet érdekes, mert futottunk már bele olyan (emlékeim szerint) 315-ösbe, amelyiken a két port (Profibus) DP illetve MPI/DP volt, és mint később kiderült, utóbbi DP-nek volt konfigurálva, így az MPI-kábelünkkel nem értük el. Később szereztünk Helmholz MPI/Profibus-ethernet gateway kábelt, azzal tudtunk hozzá csatlakozni.
-
And
veterán
Úgy tűnik, kicsit leragadtál a PLC-t kezelő program / GUI kinézetén, elrendezésén. Csakhogy a PLC programozás nagyon nem csak abból áll, hogy adott nyelven egymás után pakolgatjuk a létrákat, utasításlistát, funkcióblokkokat, stb. Olyan elvi - kicsit magasztosan fogalmazva: felfogásbeli, filozófiai - szintű eltérések vannak az egyes rendszerek között, hogy sokszor el sem tudja képzelni az, aki még nem látott többféle fejlesztői környezetet. Ez még azonos gyártó különböző sorozatú - évtizedes különbséggel fejlesztett - programjai között is megvan, nemhogy eltérő gyártók esetén. Egy rakás példát lehet erre mondani: adatterület kiosztása, változók címzése, összetett adatformátumok közti eltérések, kommunikáció beállítása (egy Mobdus vagy Profibus DP adatcsere vagy a buszrendszerek felkonfigurálása teljesen máshogy nézhet ki különböző gyártmányok esetén). De még olyan, az előbbieknél egyszerűbb dolgok megoldása is nagyon eltérő lehet, mint például a fel- és lefutó élvezérlés megoldása, az analóg input csatornák skálázása, PLC belső órájának kezelése, rendszeradatok, system-bitek kialakítása, satöbbi, satöbbi (biztos, hogy a valós eltérések száma, sokkal nagyobb, mint amelyeket itt említettem). És ez még csak maga a PLC, pedig annak a környezete is lehet fontos, hogy mondjuk miféle eszközöket kell kiszolgálnia, milyen jellegű I/O-eszközök kapcsolódnak rá. Ezt meg már nem csak a PLC, hanem az iparág is befolyásolja, amelyben a vezérlő dolgozik.
Természetesen annak, aki látott és programozott már PLC-t, legalább az alap dolgok tiszták lesznek, gyorsabban belejön az új / másik típus programozásába, de azért neki sem feltétlenül megy az átszokás egyik rendszerről a másikra (és annak hardveres környezetére). -
And
veterán
válasz
Tomika86
#7517
üzenetére
Megfelelő kivitel esetén maga a Danfoss-frekvenciaváltó is képes megoldani ezt a feladatot. Ha rendelkezik belső PI(-D) szabályozóval és szabad analóg bemenetekkel (0-10V / 4-20mA) az alap- és ellenőrző jelekhez, akkor nem szükséges hozzá külső vezérlő vagy szabályozó egység.
-
And
veterán
Ha fizikailag csillag a topológia, akkor muszáj úgy használnod, minden kábelvéget összekötve. Egyébként ez egy roppant szerencsétlen felállás: nálunk is volt abból probléma, hogy - hiába az egészen alacsony, pl. 9600 bps bitsebesség - pár év elteltével elkezdett bizonytalanul működni egy ilyen csillagpontos RS485 (modbus protokollt alkalmazó) hálózat, pedig annak csak feleannyi résztvevője volt, mint nálad, és a kábelhosszak sem voltak óriásiak. A végén kénytelenek voltunk egy felújítás kapcsán rendesen újrakábelezni, soros kialakítással, leágazások nélkül.
Másik kérdéshez: a Logo szoftvere nem képes megtalálni az ismeretlen című állomásokat? Más PLC-k esetén találkoztam olyannal, hogy a program el tudta érni az összes állomást valamilyen broadcast-üzenettel még úgy is, hogy a PC, amely a programot futtatta egészen más címtartományban volt, mint a PLC-k. Komolyabb adatkapcsolatra (fel- és letöltésre) más címtartományból nem volt képes, de arra igen, hogy megtalálja, kilistázza a hálózatra kötött vezérlőket és villogtassa rajta a ledeket. Persze ez a Logo-nál azért frissebb fejlesztés. -
#7370
And
veterán
darkengurry
#7368
And
veterán
válasz
darkengurry
#7368
üzenetére
Szia,
Ennek én nem sok értelmét látom, a gyakorlatban ráadásul (majdnem) dupla munka, hisz a végeredményt így is, úgy is be kell majd vinned a cél PLC-hez tartozó programba.
"Feltételezem a létra diagramnak az alapelvei mindenhol ugyanazok."
Az elv nagyon hasonló, csak épp a megvalósítás nem, és ez ismét csak bonyolítaná a munkádat. Minden egyes fizikai címet át kellene fordítani a végleges CPU-hoz, vagy tisztán szimbolikus címzésnél létre kellene hozni a szimbólumtáblát mindkét programban. A működésről is csak a legvégén tudsz megbizonyosodni, még ha támogatott is valamilyen szintű szimuláció mindkét keretprogramban. Amit szeretnél, egy kicsit olyan, mintha - PLC-től kissé elvonatkoztatva - neked nem lenne szimpatikus például a C++ nyelv, ezért először mondjuk Pascal-ban írnád meg a szükséges programot. Lehet, hogy hasonlatnak nem az igazi, de mégis.
Tény, hogy nem találkoztam még a GX Works programmal, de jó néhány más PLC-s környezettel igen, amelyek esetenként még egy adott gyártó különböző sorozatainál is elég nagy eltérést mutattak használhatóságban, kinézetben, célszerűségben. De az semmiképp nem jutott volna eszembe, hogy egy másikban írjam meg a szükséges alkalmazást csak azért, mert a célgéphez tartozó szoftver valamiért nem fekszik nekem. Amelyekkel találkoztam, mindig biztosítottak lehetőséget a gyors használatra (egerészés helyett például gyorsbillentyűkkel), és mindegyikben volt valami olyan, ami a többiekhez képest kevésbé szimpatikus volt, más tulajdonságában pedig jobb. El kell fogadni, hogy nem létezik olyan általános fejlesztőkörnyezet, amely minden hardverhez jó, és mindenkinek maximálisan megfelel. -
And
veterán
válasz
Dezső_38
#7116
üzenetére
Leírás: MOVIDRIVE Fieldbus Unit Profile.
Tipp-1: próbáltad már, hogy a referencia (célsebesség) értékét negatív számként adod meg? Annyira nem látok bele, meg valószínűleg - más frekvenciaváltóhoz hasonlóan - egyéb paraméterek függvénye is lehet az értelmezési tartomány. Talán akkor működhet így, ha a setpoint %-os értékben (max = 4000h) van megadva.
Tipp-2: a doksi szerint a CW1 vezérlőszó 8. bitje váltja a forgásirányt (valamint nem az 5., hanem a 6. bit a reset).
Mod.: na, mire leírom..
-
#6943
And
veterán
Achilles83
#6942
And
veterán
válasz
Achilles83
#6942
üzenetére
Ha le lehet tölteni a PLC tartalmát, a hardverkonfigurációt átnézve elég sok minden kideríthető a Profibus konfigurációból, főleg ha a CPU-ban lévő DP-csatolót használja a program, nem egy külön DP-modult (CP342-5, bár lehet, hogy azzal is megy, ha a konfigurációját a CPU tárolja). Ilyen infókat lehet megtudni: a PLC master vagy slave, állomáscím, buszsebesség, időzítési paraméterek. Ha a PLC a master, akkor a kapcsolódó slave-ekről is kiderül a DP-címük, az I/O-műveletekhez használt periféria- és diagnosztikai címük, a telepítésükhöz felhasznált GSD-fájlok neve, abból jó esetben a slave típusa, funkciója is.
-
And
veterán
Ok, már értem, honnan jött neked ez a 2048-as osztás mizéria. Épp csak azt felejtetted el leírni a #6845-ben, hogy te analóg bemeneti értékeket komparálsz, ez ugyanis abból a részletből nem látszik. Százalékokat említettél, meg integer változókat, csak az nem volt egyértelmű, hogy azok eredete egy PIW. Ráadásul ha az S5 manual-ban jól látom, nem feltétlenül igaz, hogy egy analóg bemenetnél a '100%' értéke 2047, mert ez az input kártya és a jel függvénye is lehet, 0..20 mA-es - vagy más unipoláris - bemenetnél lehet 4095 is a skála teteje. Ezt neked kell megállapítanod az adott hardverkonfiguráció alapján.
Az a 130, amire az előbbi hsz-ben is utalnak, gondolom sima elírás, és 150 akart lenni.
FB14: Jó lenne látni ennek a funkcióblokknak a paramétereit (illetve azok deklarálását és típusát), úgy talán tisztázható lenne a szerepük. Mert a PUM1, PUM2 boolean változókat valóban inputként használja (olvassa), a MULT és DIVI nevű paramétereket látszólag valóban csak fix értékre állítja be az előbbi input bitek állapota alapján. -
And
veterán
Nem tudom, ez a 2048-as osztás miből következne. A KF sima 16 bites előjeles integer változó, és a (korábban már megnyitott adatblokkban található) DW is nyilván hasonló formátumú.
"Itt vajon mire gondolt a költő?"
Ha jól sejtem, semmi mást nem csinál, mint hogy a KF után található konstanst szépen átadja az utána következő szimbólumnak (vagyis a szimbólum által reprezentált változónak). Azaz MULT= +190, és DIVI= +100. -
And
veterán
válasz
crucified
#6534
üzenetére
Annyira sajnos nem vagyok jártas a Siemens PLC-kben, de tudomásom szerint az OB-k nem jönnek létre csak úgy maguktól, (az OB1 ugye mindenképp kell) legalábbis az összes biztos nem. Találkoztam már olyan hibával, amely az azt lekezelő OB hiányában stop-ba vitte a PLC-t, majd létrehozva az OB-t (egyébként teljesen üresen, nulla hasznos kóddal) a hiba miatti leállás megszűnt. Erről is volt már értekezés a topikban. Úgyhogy azt sem tudom megmondani, hogy a készen 'importálható' FC-k / FB-k számozásában van-e valamilyen logika. Amelyekkel én találkoztam - például kommunikációt (pl. soros modbus) vagy PID-szabályozást lekezelő blokkok -, azok számozása nem tűnt annyira rendezettnek, de a help szerencsére elég jó, az segített.
Mod. #6536: Mire leírom..
-
And
veterán
válasz
crucified
#6528
üzenetére
"7.136 mA-t mértem a jeladótól a terminál blokknál."
Ez az áramérték ugye csak a távadó adatainak ismeretében releváns: alsó- és felső határérték, 0-20 vagy 4-20 mA-es távadó. A hardverkonfigurációban az AI-modul szokásosan egy egész (16-bites integer) értéket fog mutatni, skálázás nélkül. Ezt megnézheted pl. Step7 alatt a HW-konfigban az adott modulra jobb gombbal klikkelve a Monitor/Modify menüpontban online. A nyers számérték átskálázása már a szoftver dolga, erről több infó is van ebben a topikban, keress csak rá az FC105 kifejezésre. Hogy ezt a hőmérsékleti értéket a scada milyen formátumban kapja, az megint más kérdés, de ha a PLC jól skálázza (ott még megfelelő az érték), akkor az is lehet, hogy a megjelenítő is jól kapja meg, de mondjuk nem lebegőpontos, hanem egész (int, word) értékként, és nem megfelelő helyen (vagy egyáltalán nem ) jeleníti meg a hozzá tartozó tizedespontot. -
And
veterán
válasz
crucified
#6525
üzenetére
Az MPI-kábel nem jó S5-höz. Utóbbiakon 15 pólusú programozó csatlakozó (DB15 mama) található, fizikailag TTY áramhurok interfésszel. Mi pár éve beszereztünk valami olcsó utángyártott USB-s kábelt S5-ös PLC-hez, amibe bele van építve a soros-USB konverter a PC felé. Gond nélkül működött a megfelelő driver feltelepítése után WinXP-n. Hogy Win7 alatt működik-e ez illetve a Step 5, azt nem tudom, pedig a közelmúltban kikoptak a WinXP-s laptopjaink. Azt sem tudom, hogy manapság a Step 5 beszerezhető-e egyáltalán legális forrásból, de ezt majd szirty kolléga megmondja, ahogy esetleg azt is, hogy mire lehet számítani egy ilyen DOS-ablakban működő programtól az újabb oprendszerek alatt, esetlen kell-e hozzá virtuális gép: Virtualbox, VMware vagy hasonló.
-
And
veterán
"A mikroC-s témához tudnál nekem linkelni esetleg egy általad javasolt hardver tanulókitet? Felkeltetted az érdeklődésemet vele."
Ehhez sajnos nem tudok sokat hozzáfűzni, mert sosem rendelkeztem hivatalos 'tanuló kittel' vagy eval board-dal. Egy akkoriban jónak számító magyar nyelvű jegyzettel (Madarász L.) kezdtem, aztán jöttek a lehetőleg egyszerű nyelvű - basic, néha egy kevés beágyazott assembly - fordítók és a kisebb 8-bites (esetemben PIC, de természetesen ez lehet egyéni preferencia szerint akármi más is) kontrollerek adatlapjai, aztán hajrá. Egy mai jobb fordító, például a MikroElektronika termékei egy rakás példaprogramot, nagyon jó help-eket és azokhoz tartozóan sok-sok áramköri részletrajzot tartalmaznak. Ugyan nem ingyenesek, de egy bizonyos kódméret eléréséig teljes értékű demóként használhatók a letölthető fordítóik, és ez sok esetben kezdő feladatokhoz, kisebb tárhellyel rendelkező kontrollerekhez - meg nagyobbakhoz is, csak azok nem teljesen kihasználhatóak ebben a formában - elegendő lehet. De ez itt eléggé offtopik. -
And
veterán
Nem az a baj az ethernettel meg a modbus-szal, hogy ne lehetne megoldani azokat egy kisebb (akár nyers mikro-) kontrolleren, hanem pont az, hogy az olyan feladatokhoz, mint egy egyszerű hőmérés, teljesen feleslegesek, ehhez 'túl sokat tudnak'.
"A soros port/i2c-nél pedig a kábelezhető távolság ami gondot okoz."
Ez akár igaz is lehetne, de például egy SPI-buszos hőmérő órajele DC-től sok MHz-ig skálázható. Tehát nem gond a távolság, legfeljebb szokatlanul lassú, kHz-es nagyságrendű órajelet alkalmazunk hozzá. Példa: TC77, 1/16 °C-os mérési felbontás (13-bites kód), szobahőmérséklet közelében legfeljebb 1°C hiba, körömpiszoknyi tokban (SOT-23-5) is létezik és nagyjából 300 forintba kerül. Kiolvasni pedig még egy I2C-buszosnál is egyszerűbb eset, akár tisztán szoftveres rutinokkal is megoldható minimális gyakorlattal.
Nekem is az az egyik legfőbb érvem az otthoni PLC-vel vagy ahhoz hasonló 'bonyolultabb' vezérlővel szemben, hogy (bár azokkal dolgozom és egy-egy levedlett példányhoz akár hozzá is juthatnék) az ilyen egyszerű, pici és főleg olcsó hőmérő vagy akármilyen szenzorokkal sajnos nem tud mit kezdeni, vagy nagyon meg kellene erőszakolni ehhez a feladathoz. Egy szintén háromjegyű forintösszegért beszerezhető μC ellenben tartalmaz egy rakás legalább 10-bites ADC-t és ráköthető egy marék ilyen szenzor, a filléres LC-kijelzőkről, nyomógombokról, kapcsolókról, háttértárról meg mindenféle alacsony szintű perifériáról nem is beszélve. Csak akkor nem kell a szabvány codesys, hanem egy akármilyen forrásnyelven megírt fix program. Persze egy Arduino vagy más diszkrét I/O-val rendelkező kontroller is megbirkózik egy ilyen buszos érzékelővel, egy dedikált PLC viszont ehhez erős túlzás. Mellesleg egy bonyolultabb vezérlő (akár PLC) és egy filléres kontroller sem zárja ki egymást feltétlenül. Utóbbi használható többek közt az egyes érzékelők alacsonyabb szintű áramköri protokollon való lekérdezésére, valami 'PLC-hez jobban passzoló' linken, akár modbus-on pedig továbbíthatja azt egy nagyobb kontroller felé, ha a 'kicsi' mellet olyanra is szükség lenne. -
And
veterán
"nem ipari projektről van szó, inkább otthoni "berhelés""
Az otthoni 'berhelés' szerintem tipikusan mikrokontrolleres téma. Legfeljebb nem codesys-es stílusban hozod létre a vezérléshez szükséges szoftveredet, hanem akármilyen nyelven, amihez rendelkezik fordítóval az adott μC. Akár az ethernet is megoldható, de én azt nem erőltetném, mivel jóval egyszerűbb fizikai vonalak / protokollok is illeszthetőek kontrollerekhez. Például adatbuszos hőszenzorokból elég nagy a választék, némelyik megfelelő pontossággal és felbontással rendelkezik, nagyon olcsó és szinkron soros buszon kiolvasható. Modbus-t már egyszer elkezdtem leprogramozni mikrokontrollerre, de aztán nem volt meg hozzá a kellő motiváció (ha a PLC-t kihagyjuk a képletből, vagy nincs valami komolyabb kész egységünk, pl. valamilyen mérőmodulunk, amely csak modbus-on kérdezhető le, akkor ez a protokoll mellőzhető). -
And
veterán
Az online regisztráció / aktiválás során kaptam. Úgy emlékszem, kézzel semmilyen ID-t nem kellett bepötyögni. Olyannal már találkoztam, hogy a regisztrációs weboldal nem volt elérhető órákon keresztül. Van egy PDF-em (Schneider oktatási anyag része), abban vannak képernyőképek a regisztráció folyamatáról is, és a SoMachine v4.1-nél ugyanaz a part number és activation id látható benne, mint a saját regisztrált példányomnál.
-
And
veterán
Emlékeim szerint telepítéskor is rákérdez (én már hónapokkal ezelőtt csináltam), de ha már feltelepítetted, akkor a központi - SoMachine Central - menüoldalon a Tools / Registration Wizard segédprogrammal lehet véghezvinni a regisztrációt. Ha az adott gépnek van netkapcsolata, akkor a legegyszerűbb / leggyorsabb módszer a webes regisztráció, amikor is a lényegesebb mezőket automatikusan kitölti. Olyan opció is választható, hogy másik, netkapcsolattal ellátott PC-n végzed a regisztrációt ezen a weboldalon keresztül: [link]. A sikeres regisztrációt követően talán aktiválni is kell a szoftvert a Tools / Schneider Electric License Manager menüben.
[ Módosította: Parci ]
-
-
And
veterán
"[..] az olaszok sok "érdekes" dologra képesek."
Ja, természetesen nem szeretnék általánosítani, de elég vegyes tapasztalataim vannak a témában.
"Rendkívül jellemző rájuk (szerintem) hogy a géphez igyekeznek a lehető legkevesebb hasznos információt adni."
Úgy tűnik, hogy mi akkor azért részben jobb helyzetben vagyunk, mert ez vegyipar, illetve annak egy speciális területe. A lényeg, hogy a gyártó berendezés és minden elektromos csingilingi, amit rászereltek vagy a közelében van (műszerezés, hajtások, szelepek, HMI, stb.), az mind robbanásveszélyes térségben, gyártócsarnokban helyezkedik el. Ezek az eszközök nem lehetnek akármilyenek, csak minősített, adott veszélyességi zónának megfelelő Rb-s gyártmányok, illetve a vezérlőszekrény ezekhez kapcsoló berendezései (pl. gyújtószikramentes leválasztók) is hasonló elvek mentén kerülnek kiválasztásra. Ezért ha megnézzük a PLC-hez kapcsolódó terepi műszereket vagy magát a vezérlőszekrényt, akkor mifelénk szinte berendezéstől függetlenül ugyanazon kevés számú gyártó termékeivel találkozhatunk: Pepperl+Fuchs, Endress+Hauser (meg ABB, Siemens, Vega, Krohne, ..), helyi szerelésnél Datcon és társai, a PLC (készen, külföldről beszerzett gépek esetén) szinte mindig Siemens, a HMI pedig Bartec / Stahl. Akadnak persze mindenhol egzotikus dolgok, de jelentős részük ezekből áll. A dokumentáció is elég bőséges elvileg, de az kell, mert ezeket a gépeket nem lehet egy valag doksi nélkül csak úgy átadni, újabban szinte minden második-harmadik hétre jut valamilyen hatósági ellenőrzés. Ok, nem egy atomerőmű vagy NASA, de azért papírok - anyagbizonylatok, Rb-s dokumentációk, villamos-műszeres rajzok, kalibrálási papírok, beüzemelési tesztek, működéi leírás, akármi - nélkül nem lehet meglenni.
A PLC / HMI szoftveres része viszont sok esetben mostohagyereknek számít, átadott programok és projektfájlok az ilyen berendezések többségénél nincsenek, főleg a régebben ( >10 éve) telepített gépek esetén, mivel akkoriban nem igazán tartották ezt olyan fontosnak a beruházók, a felhasználó üzemrészek meg még kevésbé, ott helyben nem szokás ilyenekkel foglalkozni. Úgyhogy a kommentek és szimbólumok nélküli PLC-programok turkálása lassan mindennapossá válik, rengeteg idő megy el apróbb módosítások előkészítésével vagy hibakereséssel. A gyártók hozzáállása is igen változatos az ezzel kapcsolatos megkeresésekre, a 'tessék, itt van'-tól elkezdve a megszűnt / beolvadt cégeken és a 'már nincs meg, de van az a pénz, amiért szívesen segítünk' felfogáson át a 'nem adjuk'-ig, vagy a sima lepattintásig, ha kiderül, hogy nem új berendezések után érdeklődünk. A legutóbbi, olasz céggel kapcsolatos tapasztalatunk a lepattintás volt, szerencsére a közelmúltban volt is alkalmam finoman a fejükre olvasni ezt a tényt, amikor üzemeltetési tapasztalatokról meg hasonlókról érdeklődtek, nyilván új üzlet reményében.
"Én nem tudom (tényleg) mi a helyzet abban a programban, de nem érdemes látatlanul olyan prekoncepciókkal élni hogy mi szokás és mi nem."
Ennek az előzményét csak azért írtam, mert speciel az olasz eredetű PLC-vezérlésű berendezéseink az egyszerűbbek közé tartoznak, relatív kevés I/O-val és kisebb vezérlőprogramokkal. Ezek programjait nem szokták agyon bonyolítani, ha lennének bennük megjegyzések és szimbólumok, még kevés gyakorlattal is el lehetne igazodni bennük. Volt, hogy a módosításhoz szükséges blokkokat elkezdtem szimbólumozni, de iszonyú macera volt, sok esetben a HMI-ről letöltött és helyreállítható projekt és a fizikai I/O-lista alapján haladva. Kaptunk már olaszoktól is forrásprogramot, de csak addig örültünk neki, amíg bele nem néztünk: megjegyzések és magyarázatok olaszul, blokknevek olaszul, még a HMI tag-ek kifejtése is olasz nyelven volt
. -
And
veterán
válasz
Mazsika
#5965
üzenetére
Igen, van kezelői terminál a vezérelt gépnél. De az egy Profibus DP-s kliens eszköz, nem Siemens gyártmány, és kizárólag DB-területeken át kommunikál a PLC-vel. A kódrészletben látható DB101-ben tárolt bitek például közvetlenül a saját címükön (word-ként) jutnak el a HMI-hez, ahol ki vannak animálva. Az input bitek (ezek is megjelennek a HMI-n) szintén egy DB-n keresztül vannak átadva. Tehát a HMI közvetlenül PLC I/O-területet nem tud írni / olvasni.
-
And
veterán
Oké, ez nem is volt elvárás
. Valahol egy eldugott indirekt címzés lehet akár a bűnös? Mondjuk nem tudom, mennyire megszokott ez fizikai kimeneteknél S7-fronton: eddig elég jól körülhatárolt logikát láttam csak kimenetek írásánál, főleg hogy logikailag nem túl sok közük van egymáshoz a szomszédos kimeneteknek, és több nem használt tartalék is van össze-vissza az adott csoportban / kártyán. Tény, hogy S7-ben annyira nem vagyok otthon, meg ezt amúgy is olaszok írták ![;]](//cdn.rios.hu/dl/s/v1.gif)
. -
And
veterán
Hali,
Gondoltam, hogy van benne valami fortély, már azon felül, hogy valahol máshol piszkálják az adott kimenetet, ami a keresztreferencia szerint amúgy nem áll fenn. Ez a kimeneteket író egyetlen blokk egyik network-részlete, a kimenet csak itt íródik. Olyan rejtett felhasználói programblokkok sincsenek, amelyekre a keresztreferencia ne látna rá. Ráadásul minden egyes DO vezérlése hasonlóan néz ki, és ennél az összes feltétel (reteszelő inputok és DBX-ben tárolt határérték-bitek) ismert - na nem a programból, az szokás szerint mentes a szimbólumnevektől és a kommentektől. Ez és a többi hasonló kimenetek természetesen mind működik, csak az nem tiszta, hogyan. -
And
veterán
Üdv,
Step7-es kérdés: mi az értelme ennek a - konkrét programból származó - szekvenciának?A Q 1.4
A(
A DB101.DBX 312.2
A DB101.DBX 312.3
A I 0.1
A I 1.3
A I 3.6
A I 4.0
O
A DB15.DBX 1.3
)
= Q 1.4Arra gondolok, hogy mi a trükkje a Q1.4 kimenet vezérlésének, mikor a feltételek között logikai ÉS kapcsolatban van önmagával?
-
#5751
And
veterán
Hasaggymeg
#5749
And
veterán
válasz
Hasaggymeg
#5749
üzenetére
Ez egy érdekes kérdés, mivel a szuperkapacitás töltésének elvesztése ilyenkor várhatóan csak az RTC-adatokra lehet befolyással, az eeprom 'elfáradása' meg csak a konfigurációra, illetve az eeprom-ban tárolt egyéb adatokra. Azt természetesen nem tudhatjuk, hogy a firmware végrehajt-e bármilyen alapértékre visszaállítást, ha az eeprom-ban nem talál értelmes konfigurációt (magyarán az utóbbi eredményezi-e az RTC resetet) induláskor. Annyit mindenesetre ki tudsz próbálni, hogy a komplett modulra tápot adsz néhány órára, majd azt elveszed, és kikapcsolás után rövidebb-hosszabb idővel (ha azonnal elfelejti az időt, akkor nem kell túl sokat várnod) egy normál DMM-mel DC feszültségmérés állásban rámérsz a goldcap kondenzátor kivezetéseire. Ha ott normális értéket mérsz (> 1V, az RTC elvileg eddig működőképes), akkor nem a kapacitás hibája okozza az óra alapértékre állítását.
Mod. #5750: de sokáig írtam. Mellesleg a 750-841 adatlapja szerint táp nélkül 6 napig tartja az időt, pedig a kapacitásból, az RTC áramfelvételéből és alsó működési feszültségéből nekem > 1 hónap jött ki (persze lehet, hogy más is teheli a kondenzátort, illetve én 5V-os induló feszültséggel számoltam, ami lehet, hogy nem igaz). -
#5744
And
veterán
Hasaggymeg
#5742
And
veterán
válasz
Hasaggymeg
#5742
üzenetére
A SoC alatt középen látható a korábban már említett 24C32, egy 32 kilobites, I2C-buszos eeprom, mellette jobbra az RTC-áramkör (R8564), ami ugye a valós időt kezeli. Ezen a képen egyéb azonosítható memória chip nem látható (a bal alsó sarokban a HB125 nevű alkatrésztől jobbra található tok felirata nem azonosítható).
#5743: Az ES29LV320EB tok a korábbi feltételezésnek megfelelően egy flash-tároló, 4 Mbit / 512 kByte méretű. Mellette az ESMT M12L128324A chip pedig egy DRAM (ja jól számolom, összesen 16 MB méretű: 1M x 32bit x 4 bank). A fehér címkével leragasztott tok így nem mond semmit, akár a korábban előkerült nvSRAM is lehet.
Ezek közül a gyakori törlés / újraírási ciklusokkal biztosan kivégezhető a 24C32 és az ES29LV320. Az #5731-ben közölt táblázat alapján a program az utóbbi, nagy méretű flash-be kerülhet (a mérete miatt más már nem tárolódhat itt), a 'nem felejtő' adatoknak pedig az elvileg gyakori írással szemben önvédelemmel (SRAM-mal) szerelt nvSRAM tok adhat helyet. Az egyéb hw-konfigurációs adatokat pedig _esetleg_ a 4 kB-os eeprom tárolhatja. Érdekes, hogy a nyákon látható egy Goldcap 0,22F-os kapacitás (nyilván elem helyett), az RTC működtetése gondolom e kondenzátor feladata volna. A téli / nyári időszámításra vonatkozó adatot az RTC az adatlapja szerint nem tárol, tehát van rá esély, hogy az is a kisebbik eeprom-ban kapott helyet. Én ezek alapján a 24C32 cseréjével kezdeném, az amúgy is könnyen beszerezhető, olcsó és akár sima pákával is leszedhető, cserélhető. -
#5739
And
veterán
Hasaggymeg
#5736
And
veterán
válasz
Hasaggymeg
#5736
üzenetére
Hát az gáz, de akkor biztosan nem olyan elvű adattár volt, mint az nvSRAM, mert azt egyszerűen nem lehet így tönkretenni, direkt meg biztos nem kér tőle a SoC állandóan store-műveletet, mert akkor pont a lényege veszne el, lehetne helyette mezei eeprom-ot vagy flash-t is használni. Utóbbi lehet nálad az a normál SOIC-tokos alkatrész, amelyre címke van ragasztva. A baloldalon látható nagy IC viszont ránézésre tipikusan olyan széles tokozású, amibe flash-chipeket szoktak szerelni, középen felül meg lehet pl. RAM, bár a típusjelek nem nagyon olvashatóak rajtuk.
-
#5733
And
veterán
Hasaggymeg
#5732
And
veterán
válasz
Hasaggymeg
#5732
üzenetére
(Az STK14C88 (32kB) nvSRAM-nak - az adatlapja szerint - pont az lenne a lényege, hogy az írás/olvasás ciklusok száma nincs limitálva, mivel az üzem közben egy RAM-területen történik. Az adat csak akkor tárolódik vissza (store) a 'quantum trap' nevezetű, az SRAM-mal megegyező méretű nemfelejtő tárterületre, amikor elvesszük tőle a tápot, vagy szoftveresen kéri tőle ezt a kontroller. Ez utóbbi művelet, amely csak véges mennyiségben hajtható végre, az adatlap szerint legfeljebb egymillió alkalommal.)
Mod.: Épp ezért nem lehetséges, hogy nem erről a tárolóról van szó? Moseras fotóján látszik egy 24C32 eeprom, az elég kis méretű (4 kB) ahhoz, hogy konfigurációt tároljon. Nem lehet, hogy a te kontrollereden is egy ahhoz hasonló alkatrésszel van gond? -
#5728
And
veterán
Hasaggymeg
#5727
And
veterán
válasz
Hasaggymeg
#5727
üzenetére
(Ha valóban az a típusa, amit moseras kolléga említett, akkor az a tároló, de nem tisztán flash vagy eeprom, hanem az adatlapja szerint egy nemfelejtő háttértárral rendelkező nvSRAM. Kérdés amúgy, hogy miért szeretnéd ezt cserélni, és mire jutsz vele. Ha a firmware is ebben tárolódik - márpedig az adatlapja szerint a Net+50 jelű SoC nem rendelkezik flash / eeprom memóriával -, akkor azt egy újra cserélve előfordulhat, hogy hiába ismered az egyéb felhasználói szintű paramétereket, a kontroller működésképtelen lesz.)
-
And
veterán
(Nálunk /vegyipar/ a dolog úgy néz ki, hogy azokban az üzemrészekben, amelyekben nagy számú I/O-t kezelnek, ott eleve létezik felsőbb szintű DCS-rendszer, amely megoldja többek közt a megjelenítést a hozzá kapcsolódó terminálokon, plusz az adatgyűjtést és archiválást. Ahogy Szirty is vázolta, ez alatt van egy csomó egyedi PLC-vel rendelkező berendezés, amely önállóan is működőképes és általában saját HMI tartozik hozzájuk. Mivel ezen berendezések PLC-i nem egységesek, az adott géppel együtt jöttek, a közös felület, amellyel a fölöttes rendszer felé csatlakoznak általában modbus - többféle fizikai adatvonalon -, Profibus DP, esetleg szimpla analóg jelek csoportja. Az egyedi berendezések telepítése előtt megadták a DCS felé kommunikálandó adatok mennyiségét és típusát, a PLC-kben pedig a gyártó szépen létrehozta az ehhez szükséges adatblokkokat. Vannak olyan régebben épült egységek is, ahol nincs felsőbb folyamatirányító rendszer, ott a meglévő sziget PLC-k vagy egyszerű mérőkörök jeleinek központi adatgyűjtését utólag telepített remote I/O-k oldják meg, de természetesen lényegesen kevesebb számú jelet fogadva.)
-
And
veterán
válasz
DasBoot
#5614
üzenetére
Ennek az adatlapnak a 26. oldalán konkrét példákat találsz a passzív OC-kimenetre. A legfelső ábra az oldalon például megfelelhet: a 24V-os tápot a kimeneti NPN-tranzisztor kollektorára kapcsolod, az emitterét pedig a PLC (gyors számláló) inputra viszed. Az emitterkörbe rajzolt ellenállást magának a csatornának bemeneti ellenállása adja, tehát ugyanazt a fix 24V-ot lehet a kollektorra kötni, amelyet a DI-csatornákra is vinnél (vagyis a fix tápnak ugyanaz legyen a GND-je / 0V-ja, mint a digitális bemenetek referenciapontja).
Mod: a fázishelyzet / nyugalmi polaritás impulzusszámlálás vagy frekvenciamérés esetén ugye nem lényeges, de a vázolt bekötéssel csak akkor működik, ha az inputod nyelő / sink elrendezésű: [link]. -
And
veterán
Nem annyira szerencse kérdése, bár úgy is fel lehet fogni. Ha nincs meg a forrás, csak az égethető bináris, akkor a program egyszerűsége szabja meg, hogy az ajánlott 'új' típus viszi-e a régi programot. Az említett 16C71 -> 16F716 esetén például eleve nincs olyan sok speciális regiszter, és a leglényegesebbek mindkettőnél ugyanazon a címen / lapon vannak. De például az ADC-hez tartozókra ez már abszolút nem igaz. A szabadon felhasználható RAM-címeknek is van közös átfedésük, de nem sok. Még a konfigurációs szó legfontosabb bitjei is megegyeznek, ide értve az oszcillátor típusát és a watchdog-ot. Bár ezek külön kezelése még hex-fájlok esetén is megoldott az MPLAB-ban, nem kötelező a binárisban lévő konfig-beállítások használata, azoktól el lehet térni. Tehát egy csak digitális I/O-t használó program akár mehet is az újabb típuson, de jó eséllyel problémás lesz, ráadásul nem biztos, hogy a gond azonnal előjön, mikor a kontroller elindul.
Ha adott a forrás (úgy tűnik, a kollégánál ez megvolt(?) ), akkor az SFR / RAM címek eltérésével nincs gond, mert a céltípus beállításával a fordító módosítja ezeket, hiszen ismeri az általa támogatott MCU-k memóriatérképét. Egy felülről nagyjából kompatibilis típusban pedig minden olyan FSR adott, ami az eredetiben is megvolt, legfeljebb akadnak újabbak is (a 16F716 például tartalmaz két újabb timert, egy CCP - capture/compare/pwm - modult, meg nagyobb RAM- és program tárterületet, ami a 16C71-ben nem volt). Tehát így egész kis vagy akár nulla lényegi (forrás-)programmódosítás árán migrálható a kód.
Nemrég kellett egy sok éve 16F876-ra írt kódot az ajánlott utód 16F886-ra költöztetnem, az nem ment módosítás nélkül, mivel ADC-t használt, azok konfigurációja meg némileg eltér a két típus között: az újnál szabadabb portkiosztás vehető igénybe, ezért az ADCON0/1 regiszterek felépítése nem azonos. De a gyártó itt elég konkrét dokumentációt adott a migrációhoz, összeszedte az apró eltéréseket, hogy mire kell figyelni a váltásnál. -
#5606
And
veterán
TotoThomas
#5605
And
veterán
válasz
TotoThomas
#5605
üzenetére
(Az száz százalékos bizonyossággal gond, ha egy adott típushoz való programot egy egészen más fajtába próbálsz beégetni. Ez még azonos családon belül sem nyerő, nemhogy egy totál másik sorozatnál: a 16C egy meglehetősen régi, EPROM-alapú - kvarcablakos vagy egyszer programozható / OTP - jószág, a 16F-sorozat pedig flash-tárral rendelkező család. Ha a program csak a beégetésre való .hex-fájlban van meg, forrásban pedig nincs, akkor kénytelen vagy az eredeti típust használni. Ha megvan forrásban is, akkor esetleg átfordítható egy újabb flash-alapú típusra, de ez több-kevesebb módosítást igényel, - nagyon egyszerű program kivételével - nem csak annyit, hogy a fordítóban másik célkontrollert választasz ki: más méretű és kiosztású memóriaterület, eltérő című és funkciójú SFR-ek, más portok és egyéb perifériák, stb. Egyszerűen nem megy úgy, hogy más van kéznél, biztos az is jó lesz.)
-
And
veterán
válasz
DP_Joci
#5435
üzenetére
Szia,
Ez konkrétan BAT-300-as típusú volt, de lényegében a nálunk előforduló régebbi Panel PC sorozat összes tagja (BAT VGA Pro, BAT-600, BAT-300) letölthető soros RS232 porton keresztül. Vagyis azok, amelyekben belül még csak két natúr RS232-es port van beépítve, az egyéb fizikai rétegeket - RS422, Profibus DP - pedig egy vagy két opcionális, cserélhető belső konverter 'dobozka' biztosítja. Ezen HMI-k fájl-szintű tartalma letölthető egy '90-es évekből származó, DOS (!) alatt futó programmal, és be is tölthető ugyanolyan (vagy legalább kijelzőméretben megegyező) típusba. Az, hogy a Bartec alkalmazása (BMS Graf Pro) is meg tudja nyitni szerkeszthető formában, egészen ritka, egy .PRJ-fájl megléte esetén lehetséges, ilyet viszont utoljára talán a DOS-os szerkesztőjük generált, az újabb projektek között nem találunk. A BAT-sorozat viszont sajnos már évekkel ezelőtt kifutott, az utód Polaris-család példányainak tartalma pedig egyáltalán nem menthető, feltölteni is csak a saját (jó drága, mert Ex-es) Bartec-es pendrive-jával lehetséges, legalábbis a Profibus-os típusokét. A régi BAT-okból kimentett fájlok Polaris-formátumúra konvertálására is találtunk megoldást, de szerkeszteni vagy módosítani nem tudjuk a projektet, csak 'Polaris-kompatibilissé' tudjuk varázsolni azokat némi fájl-alapú turkálással, hogy betölthetők legyenek a Polaris-okba. -
And
veterán
Köszönöm! Így valóban létrehoz egy új instance DB-t az FB41-hez.
Mod. (#5422) Hasaggymeg: valószínűleg annyit jelent, hogy a szabályozó a megadott értékű holtsáv = hibajelig a hibajel értékét nullának veszi, vagyis a beállított alapjeltől maximum ekkora eltérésig nem avatkozik be. Lásd pl. ezt a blokkdiagramot: [link]. -
And
veterán
Szia,
Kösz a választ! Egy viszonylag egyszerű gépről / programról van szó, amihez természetesen nincs meg az eredeti kommentezett, szimbólumokkal ellátott gyári program, csak egy backup (az olasz gyártó lepattintott, mikor megpróbáltuk elkérni a programot, bár olasz nyelvű kommentekkel csak egy kicsit lennénk előrébb). Szerencsére a Bartec HMI-ről letöltött projekt visszaállítható volt szerkeszthető formába, az sokat segített a változók és a programrészletek azonosításában.
Összesen hét DB létezik a programban, három shared és négy instance blokk. Ezeken kívül 24 darab FC, két FB és öt OB (amiből 3 lényegében tök üres, gondolom a PLC leállását megelőzendő, mint az OB121, OB122). Bónuszként látok 1-1 SFB-t és SFC-t.
Az új DB-t egyszerűen új objektumként próbáltam létrehozni a jó öreg Step7 v5.3 SP1 alatt (Insert new object / Data Block), adtam neki nem létező sorszámot, de ha létezőt próbáltam, akkor úgyis egyből piros lett a DB sorszáma. Szóval shared DB-ként (mondjuk DB51 névvel) simán létrehoz egy üres blokkot, ha viszont azt mondom neki, hogy legyen Instance DB, a legördülő menüből kiválasztom hozzá az FB41-et és Ok-t nyomok, akkor némi gondolkodás után feldob egy 'Insert Data Block' üzenetablakot, benne a következő üzenettel: "Insert Data Block (34:4343) / W Ln 000001 Col 020: No valid offline ASCII type description found for called or addressed block FB 41."
Erre a help annyit mond, hogy "Description of Error: This is just a warning. No type description is available for the block you called. ". Erre az ablakra Close-t lehet nyomni, és a DB nem jön létre.
"OB1-ből vagy egyéb blokkból hívott FB41-nél is biztosítható a pontos ciklusonkénti hívás a blokk EN "bemenete" előtt megadott megfelelő feltétellel."
Látszatra mindenféle egyéb feltétel megadása nélkül hívja meg a meglévő FB41-et egy STL-ben írt blokk, a hívás előtt sem látok semmilyen feltételes elágazást vagy időzített hívásra utalást. Az FB41-et hívó FC is két áttétellel hívódik meg az OB1-ből (OB1: Call FC20, FC20: Call FC51, FC51: Call FB41), látható feltételek nélkül. -
And
veterán
Üdv,
Egy már régóta üzemelő S7-300-as (315-2 DP) PLC-be kellene egy új PI-szabályozást varázsolnom. A vezérlőben van már egy másik fizikai jellemzőt szabályozó funkció, amely az FB41-es "CONT_C" blokkot hívja meg, a hozzá tartozó DB41-es instance data block-kal. Ha az újabb szabályozáshoz is az FB41-et szeretném használni, akkor azt hogyan tehetem meg, ha egyáltalán lehetséges? Létrehozok egy újabb instance DB-t az FB41-hez (ezt viszont nem hagyja), és azzal hívom meg? Az FB41 paraméterei a Siemens dokumentációja és a Szirty weboldaláról letölthető példa alapján nagyrészt világosak. Érdekesség, hogy a programban már meglévő FB41-hívás nem ciklikus megszakításból (OB30..38) származik, hanem simán az OB1-en és más FC-ken keresztül történik, ugyanakkor az FB41-es IN8 (Cycle) paraméterének értéke T#1s, engedélyezhető I- és D-tag mellett. -
And
veterán
(Az RS485 interfész IC - a PLC felé - persze egyik esetben sem kerülhető meg, de a két integrált áramkörön kívül egyetlen tranzisztor meg néhány passzív alkatrész kell hozzá: [link]. A soros verziót több példányban megépítettem, és egyszer az FT232-est is kipróbáltam próbapanelen. Az is működött.)
-
And
veterán
válasz
Andris246
#5171
üzenetére
(Mi is ilyen ócska ATEN-féle USB-soros illesztőket kaptunk annak idején 'valódi' soros portos laptopok helyett, de pont a Siemens S7 PLC-k nem szoktak problémázni vele. Telemecanique / Schneider-ek - Micro, Premium, Twido - és Allen-Bradley-ek - ebből csak 1-2 példánnyal próbáltuk - viszont nem komálják.)
-
And
veterán
-
And
veterán
válasz
byte-by
#5050
üzenetére
"az elem tudtommal nem a programot védi ( pont mert az általában nem felejtő területen van , vagy memóriakártyán is szinte kivétel nélkül minden plc-ben)"
(A kérdéses PLC-családot ugyan nem ismerem, de akad olyan sorozat Schneider-éknél (pl. a Twido), amelyiken van ugyan nem felejtő programtár, de a program csak kérésre kerül oda (backup). Alapjában ez a funkció be van kapcsolva, első letöltéskor - és utána is minden online módosítás után - elvégzi ezt a backup-ot, de ha ezt letiltják, vagy offline-ba váltáskor a feltett kérdésre nemmel válaszolnak, akkor a teljes program vagy az online végrehajtott változtatás csak a RAM-ban marad, és kikapcsoláskor, lemerült / hiányzó elemnél elvész. Mod.: hab a tortán, hogy ennél a sorozatnál van lehetőség az előlapi - elemhibát jelző - 'BAT' led letiltására szoftverből, de alapesetben természetesen mutatja a lemerült elemet.) -
And
veterán
válasz
DP_Joci
#4978
üzenetére
Megnéztem: ha nincs rajta program, amit a gyári új állapotot kivéve csak kiszedett elemmel lehet produkálni, akkor a CPU-modulon csak a vörös ERR led villog (és az IO-modulokon is), más életjelet nem ad. Csatlakozás után egy 'üres' applikációt hozott létre a PL7 Pro szoftver, és már ekkor eltűnt az ERR jelzés, a RUN led világított / villogott attól függően, hogy futott-e a 'program' vagy nem. Mindezt úgy, hogy egy sort nem írtam bele.
Azt is kipróbáltam, hogy lekapcsolt vagy éppen kiszerelt - elemet nem is tartalmazó - tápnál pár perc nem számít, ennyire gyorsan nem felejti el a programot a CPU, ha éppen van benne program. Tehát a tápcserét kényelmesen végre lehet hajtani, azon nem múlik a program elvesztése (TSX PSY2600-as táp és P57203-as CPU). -
And
veterán
válasz
DP_Joci
#4972
üzenetére
A Premium rendszer leírásában van szó a tápegységek jelzéseiről: [link], lásd az az 50-51. oldalakat. Az elég egyértelműnek tűnik, hogy rendben lévő feszültségszintek esetén a zöld OK jelzésnek világítania kellene. A 24V led szerepe nem ennyire tiszta, mivel a megléte típusfüggő. De két helyen is utalnak arra, hogy a PSY1610-es tápnál ez a led nem játszik: egyrészt azt írják, hogy a sensor power supply csak AC-tápoknál létezik (utóbbiaknál van csak értelme, a '24V' led ennek a kimenetnek a meglétét jelezné), másrészt konkrétan a 1610-es táp adatainál (51. oldal tetején) az 'Output = 24V sensors' ki van húzva, mivel annak DC-tápként nincs olyan kimenete, maga is 24V DC-t igényel.
Tehát ha a BAT led nem aktív és az OK sem, akkor van rá esély, hogy valóban csak táphibás a vezérlő. A CPU-n villogó ERR és a teljesen inaktív RUN led ebben a helyzetben nem túl egyértelmű, de normálisan működő tápnál hiányzó programra utalna. Ha érdekel, jövő hét elején meg tudom írni, hogy milyen jelzéseket ad egy programmal nem rendelkező Premium, mert van egy tesztpéldány a közelemben (annak a tápegysége az a bizonyos PSY 2600). -
And
veterán
válasz
DP_Joci
#4969
üzenetére
Sajnos a közelemben is csak egy TSX PSY 2600-as táp van, de ilyenkor jól jön egy multiméter
.
"A ki-bemeneti kártyák hibában vannak és az a kérdés, hogy lemerült az aksi és elszállt a program"
Ha a programot elfelejtette, akkor a CPU-modulon lévő RUN led biztosan nem fog folyamatosan zöld színnel világítani, és az elemhibát is jelzi egy vörös BAT feliratú led.
Ha még megvan a program, minél előbb csinálj róla egy mentést, amíg nem késő. -
And
veterán
(Szia! Ehhez annyit tudnék hozzátenni, hogy jó két éve egyszer belefutottunk egy hasonló problémába WAGO-témában. Ott annyival egyszerűbb volt - vagyis csak annak tűnt - a helyzet, hogy nem új modulokat kellett betenni egy DP-s buszcsatoló / fejegység alá, hanem magát a csatolót kellett cserélnünk meghibásodás miatt. Vettünk egy új, típusra ugyanolyan csatolót (750-343), majd csodálkoztunk, hogy beépítés után hibát jelez, és természetesen az alatta lévő WAGO IO-modulok sem működnek. Egy másik hasonló gépből kivettünk egy ugyanilyen csatolót, azzal gond nélkül elindult a rendszer. Hamar kiderült, típusra hiába az eredeti a csatoló, más (újabb) firmware-verzióval rendelkezik. A mellette lévő fő Siemens S7-300-as hw-konfigurációjában ez a WAGO-s remote-egység úgy szerepelt, mint néhány "Universal module" nevezetű eszköz, és ezekhez rendelt IO-címek. Az univerzális modulok darabszáma egyébként csak néhny darab volt, messze nem egyezett meg a fizikailag meglévő WAGO-modulok számával. Úgyhogy muszáj volt az S7-hardverkonfig ezen részének teljes újjáépítése a megfelelő GSD telepítése után, ráadásul elég trükkös módon, de a tényleges számú WAGO-modulokkal megegyező sorral.)
-
And
veterán
Mifelénk (vegyipar - gyógyszeripar) ugye eléggé tipikus berendezések vannak, de azért többféle gyártótól. Eddig egyetlen olyan - centrifuga - gyártóval találkoztunk, amelyik nem volt hajlandó a PLC-program és a HMI-projekt utólagos átadására (illetve hajlandó lett volna, de mindenféle jogi nyilatkozat CEO-val történő aláíratása után, ami itt közel lehetetlen), de az brit volt. Ugyanez a gyártó védi egyedül jelszóval a Siemens PLC-k programjait, tehát minimális változtatást sem tudunk eszközölni rajtuk. Volt olyan eset, hogy a tartalékként vett új HMI-t csak úgy tudtuk felprogramozni, hogy a HMI gyártóját kértük meg, hogy ha már úgyis nála van javításon a régi panel, olvassa ki belőle a menübe lépéshez szükséges kódot (menüből fel- és le is tölthető a HMI bináris tartalma, de magát a menübe belépést is jelszóval védték).
Olasz gyártóval is akadt problémánk, de az inkább olyan jellegű volt, hogy egyszerűen csődbe mentek
. Hiába maradt meg valamilyen szintű támogatás egy újabb cég részéről, a régi programokat érdekes módon fizikailag képtelenek voltak ezután előkeríteni (előtte még tudták). Volt, hogy személyesen járt itt más géphez kapcsolódóan az olasz szervizmérnök, ő is azt mondta, hogy megpróbált utánanézni, de egyszerűen nincsenek meg a régi programok. Szerencsére a HMI az ő esetükben Bartec-gyártmányú volt, ezt errefelé nagyon sok gyártó adja a berendezéséhez.
Nemrég pedig egy Siemens PLC-hez tartozó gyújtószikramentes Profibus DP-s remote fejegységet és hozzá egy rakás IO-modult kellett kiváltani hagyományos modulokra plusz gyszm. leválasztókra, mert kiderült, hogy a modulokat tápláló speciális (azaz mással kiválthatatlan) Siemens tápegységet már nem gyártják, egy elfekvő darabért pedig forintban 7-jegyű összeget (!) kért volna egy szerviz. -
And
veterán
Köszönjük az infókat, így kicsit világosabb! Egyébként kisebb PLC-k esetén (pl. Schneider Twido) is előfordult már, hogy a létrában bevitt rung egyszer csak utasításlistává változott, de csak az az egy - ennél a PLC-nél a rung-ok hossza a szerkesztőben maximum 7 sor lehet. Ehhez pedig vissza sem kellett olvasni a PLC-t, már szerkesztéskor olyan lett. Maga a projektfájl (.twd) mellesleg egy xml-formátumú szöveg, az láthatóan utasításlistát tárol, amit csak a programszerkesztő alakít létrává.
"Épp ezért nem szabad soha senkitől olyan gépet, berendezést, gyártósort vásárolni amihez nem adják mellékelve a teljes aktuális forrás anyagot kommentekkel, mindennel együtt."
Ezzel mélységesen egyetértek. A gond akkor van, amikor az ember egy csomó olyan, PLC vezérelte gépet 'örököl', amelyekhez sosem volt meg a gyári program, plusz terminálokat, amelyekhez szintén nincs semmi. Átadáskor egyszerűen tojtak az egészre. Funkcióteszt, FAT-SAT, mérési jegyzőkönyvek meg a vegyiparban szokásos összes bisz-basz az legyen (a gyakorlatban ez ugye egy köteg dossziét jelent), de hogy a program vagy egyéb projekt-állomány is ott legyen, az véletlenül sem jutott eszébe senkinek sem. A közelmúltban egy komplett gépünk vezérlését alakította át egy cég úgy, hogy az eredeti program nem volt meg hozzá, csak amit az S7-300-as PLC-ből ki tudtunk szedni. Mondjuk a terminál (Profibus DP kommunikációval) projektje az éppen megvolt, az biztosan sokat segített a változók azonosításában, de így is sok millióba került az átalakítás. A kész programban van olyan programrész (komplett FC-k), amelyhez látszólag nem kellett nyúlni, régi a módosítási dátuma, nincs benne komment, és a szimbólumok is csak részlegesek, de a teljes program nagy része kommentezett. Sajnos néha hajmeresztő dolgokra kényszerülünk a működőképesség fenntartásához egy-egy alkatrész vagy HMI cseréjekor, apróbb módosítási igényeknél. Gondolom, ezzel nem vagyunk egyedül. -
And
veterán
válasz
Peddy789
#4864
üzenetére
"[..] nemhogy csak szimbolumok nincsenek, de az egész STL-ben lesz hiába létrán írták."
Na, azért ez nem igaz. Ezer éves Step7-essel nyomulunk, és ha feltöltjük a programot a PLC-ről a gépre, akkor minden blokk azon a nyelven jön vissza, amelyiken írták. Mellesleg a nézetet akár mikor meg lehet változtatni a szerkesztőben, pl. utasításlistává lehet varázsolni egy létradiagramban írt funkciót (nem tudom, hogy ez minden esetben így van-e, vagy valami korlátja, de nekem már többször sikerült).
Oké, sajnos szimbólumok meg kommentek nincsenek. Ez egyébként PLC-típusonként eltér. Például Schneider (Modicon) Micro / Premium PLC-k esetén a rung fejlécek megmaradhatnak, vagy mondjuk M340-nél az egész mindenséget visszakaphatom szimbólumokkal, megjegyzésekkel, anim-táblákkal.
Mod.: "Hát programozo l legyen a talpán sok kávával és stresszkezelő ejárással aki egy közepes prorgamot is megtud abból érteni."
Hidd el, hogy van az a pénz, láttunk mi már olyat. -
And
veterán
válasz
DP_Joci
#3237
üzenetére
Működőképes lehet az elv, ha a proporcionális szelep megfelelő vezérlését meg tudod oldani. Mifelénk ezt pneumatikus működtetésű szabályozószeleppel, vagy ha a vákuumgép felépítése lehetővé teszi, a motor frekvenciaváltós vezérlésével szokták megoldani (utóbbi esetben is szükség lehet a vákuum rontására).
-
-
And
veterán
válasz
AVarice
#3188
üzenetére
Nálunk viszont nem megy az Aten UC232A semmilyen Modicon / Schneider PLC-vel, legyen az Twido vagy TSX Micro / Premium. A Zelio programozható relé soros kábele ellenben működik vele, és szerencsére a Siemens RS232-MPI adaptere szintén.
Schneider-hez viszont igen egyszerűen lehetett működő soros (MAX232 / LTC485) kábelt készíteni, és FTDI chip-es USB-soros konverterrel (FT232R) is sikerült működésre bírni. -
-
And
veterán
Hát ha nem az érzékelő hibásodik meg (vagy leválasztó esetén a bemeneti áram tűnik el), hanem maga a távadó (áramgenerátor) elektronika romlik el, akkor ahogy Szirty írta, gyakorlatilag bármi lehet. Ha tudnánk, milyen áram hagyja el, akkor nem mondhatnánk, hogy rosszul működik..
-
And
veterán
(Némely okosabb, esetleg HART-interfésszel is rendelkező 4-20mA-es távadó vagy leválasztó konfigurációjánál megszabható, hogy hogyan viselkedjen (szenzor-)hiba esetén a kimenet: kiakadjon valami szélsőséges értékre, >21.5 vagy <3.6mA-re, esetleg tartsa tovább az utolsó helyes értéket.)
-
And
veterán
válasz
hali.papa
#2018
üzenetére
Egyetértek Szirty-vel. Elektronikailag egy sima 'indít-leállít' időmérővel, párszáz forintos mikrokontrollerrel megoldható feladat. Szinte a leggagyibb fototranzisztor is megahertzes frekvencia- (mikroszekundumos idő-) tartományú működésre képes. Nem is túlságosan gyors komparátorokkal - akár a µC saját beépített komparátoraival - történő jelfeldolgozás, impulzusformálás után mérhető és egyszerű hétszegmenses vagy alfanumerikus LCD-modulos kijelzőn indikálható az egymástól ismert távolságra lévő optikai kapuk jelének időkülönbségéből számított sebességérték. A feladat további nehézségei (puska megfelelő rögzítése, a lövedék útjának pontos behatárolása) már nem elektronikai jellegűek, de annyira nem is tűnnek megoldhatatlannak.
-
And
veterán
Üdv!
Hátha valaki már találkozott hasonlóval: Siemens CP341 (RS232C) kommunikációs probléma. Adott egy régóta működő rendszer: a Siemens PLC egyetlen készüléket működtet és az üzemi DCS-rendszerrel cserél adatokat a 341-es modulon keresztül. Egyik percről a másikra a kommunikáció megállt, a CP-341 és a CPU (315-2 DP) SF-ledje is aktív lett. A CP-341 modbus-slave RTU módban, a hátuljában benne a hardverkulcs /dongle/. A Step7 szerint "Faulty module", nosza, rendeltünk egy újat. Meg is kaptuk, ugyanaz a rendelési kód (6ES7 341-1AH01-0AE0), bár az új példány fw-verziója valamivel újabb (1.02 vs 1.01). Ilyet még nem konfiguráltunk, kiderült, hogy kell hozzá 1.) CP PtP Modbus-Slave RTU software és 2.) Point-to-Point Connection Parameter Assignment Tool. Ezeket is felraktuk szépen a Step7 alá. Az új modulba áttetük az eredetiből származó dongle-t, beszereltük a modult a PLC-be, az eredeti konfiguráció szerint felparamétereztük, és letöltöttük rá a drivert (a konfiguráció kényszerű mentésekor némi adat láthatóan a CPU-ba is íródott). Majd PLC indít, és.. És semmi! SF-ledek továbbra is világítanak, nincs adatcsere. A csavar: mindezek után az eredeti CP341-es modul + dongle visszakerült (ellenőrizendő a konfigurációt) a PLC-be, és csodák csodája, megy a kommunikáció! Csak az a kár, hogy fogalmunk sincs, mitől romlott el, pontosan mitől javult meg, és főleg: miért nem megy az új, elvileg jól felkonfigurált, driver-rel ellátott kommunikációs modullal az adatcsere (a 'rossz' modult vissza kellene szolgáltatnunk).
Ilyenkor mi a lehetséges megoldás? A modul beállításai elvileg jók (három, közel egyforma berendezés / PLC van, azonos CP341-konfiggal). Frissítsünk a modulon firmware-t? Esetleg downgrade-eljünk, hogy az újban is ugyanaz legyen, mint az eredetiben? A Siemens-től azóta újabb modbus RTU driver és parameter assigment tool verziót töltöttünk le, de ezekkel még nem próbálkoztunk, mivel a gépet egyelőre használják. Számíthat ez valamit? -
And
veterán
válasz
kip.kop
#1497
üzenetére
Persze hogy nem hajtja végre mindhármat, hiszen nem gondoskodtál arról, hogy ne egy futási cikluson belül indítsa a három kérést. Lásd a 479. oldalon: "If several messages are sent in the same cycle, only the first message is transmitted. The user is responsible for managing the transmission of several messages using the program."
Tehát neked kell gondoskodnod a lekérések 'elosztásáról'. Azon az oldalon találsz egy példát is, amely két üzenetet kezel, és egy jelzőbittel (%M0-val) irányítják a forgalmat: az első üzenettel párhuzamosan beállítják ezt a flag-et, és majd ez engedélyezi a másodikat, ha az első véget ért. Ugyanígy a második üzenet küldésekor törlik a jelzést, ami pedig az első üzenet végrahajtásának a feltétele. Ha kettőnél több üzenetet kezel a program, akkor nyilván nem elegendő egyetlen bit a jelzéshez, hanem létre kell hoznod egy számlálót: ezt az egyes üzenetek sikeres elküldésekor szépen inkrementálod, majd ha az utolsó is kész, akkor kinullázod. Az egyes lekérésekhez pedig a %MSG.D bittel ÉS kapcsolatban feltételként hozzárendeled, hogy a számláló a megfelelő (három EXCHx esetén: 0, 1, 2) értékű legyen. -
And
veterán
válasz
kip.kop
#1486
üzenetére
Ajánlom figyelmedbe ezt a dokumentációt: [link]. A 126. oldaltól láthatod a modbus kommunikáció megvalósítását Twido-n. A megoldás lényege az EXCHx utasítás (134. oldaltól), ill. a %MSGx belső funkcióblokk két állapotjelző bitje, a %MSGx.D és a %MSGx.E. A kommunikáció megkezdése előtt definiálni kell egy adott hosszúságú táblázatot, amely tartalmazza az összes szükséges paramétert. A 131. oldalon találod a táblát, amely három részre van osztva: vezérlő-, adási- és vételi táblázat. Utána szépen ki van fejtve, hogy az egyes elemeknek mi a szerepük. A korábban már megismert 3-as (és 4-es, mivel a kérés itt is ugyanúgy néz ki) funkciókód bővebb leírása a 145. oldalon van. A control table tartalma itt kötött, a transmission table tartalmában állítható be a lekérdezett slave címe, a slave-ből kiolvasandó regisztertömb kezdőcíme és a tömb hossza. Példaprogram a 140. oldalon, ezt átalakítva a neked szükséges feladatra úgy, hogy a DigitalT és DigitalRH nevű adatregisztereket olvassuk ki a slave egységből:
LD 1
[%MW0 := 16#0106 ]
[%MW1 := 16#0300 ]
[%MW2 := 16#4003 ]
[%MW3 := 16#0008 ]
[%MW4 := 16#0002 ]
LD 1
AND %MSG2.D
[EXCH2 %MW0:9]
END
Az első két word a control table, mint írtam, itt a tartalmuk kötött, lásd a funkciókód leírásnál. A %MW2..%MW4 a transmission table, itt adjuk meg a slave címét (64dec = 0x40), a modbus kérés funkciókódját (0x03), a kezdő regisztert (8, ami a DigitalT regiszter 7-es címe plusz egy), ill. a lekérdezett tartomány hosszát (2 db. word). A %MW5-től kezdődik a reception table, amelynek tartalma a slave válasza után áll be, ha nincs hiba a kommunikáció során. Utóbbi vételi tábla a következőket fogja tartalmazni:
%MW5: 0x4003, a slave címe és a válasz kódja, ezek a válaszban szintén megjelennek,
%MW6: 0x0004, az 'Rx offset' által beiktatott 0x00 (MSByte) és a kiolvasott byte-ok száma (LSByte), ami 4, hiszen két darab 16-bites word-öt kértünk le,
%MW7: ebben kapod meg az első lekért regiszter tartalmát, vagyis a DigitalT-t,
%MW8: ebben pedig a másodikat, azaz a DigitalRH-t.
A %MSG2.D bit jelentése: 'communication complete', ez azért kell, hogy a kontroller (több lehetséges üzenet kezelése esetén) csak akkor kezdje el küldeni az aktuális adatkérést a buszon, ha az előző már befejeződött.
Természetesen a hardverek megfelelő összekötéséről és a Twido portjának beállításáról a hw-konfigurációnál (lásd: 139. o.) előzőleg gondoskodnod kell. Az adattábla meg bárhol kezdődhet, nem csak %MW0-nál (a példában %MW0:9), és nem csak a 2-es számú (EXCH2 és %MSG2), egyébként opcionális portot lehet igénybe venni a feladathoz. Az alap, programozáshoz is felhasznált 8-pólusú mini-din aljzat az 1-es számú port. E port használatához az aljzat DPT-jelét GND-re kell húzni (128. o.), ill. az A-B adatvonalakra megfelelő fel- és lehúzó ellenállásokat kell kötni (129. o.). -
And
veterán
válasz
kip.kop
#1474
üzenetére
Igen, sajnos ez az eggyel történő regisztercím eltolódás nem szokatlan a modbus-nál. A modpoll esetén is van opció (-0, 'First reference is 0') ennek a kezelésére, de épp azért nem írtam bele a paraméterek közé, mert a regisztertérkép 1-től indult.
Mod: a parancssoros modpoll csak lekérdezésre képes, az a GUI-s Modbus Poll esetleg képes az írásra (nem próbáltam), ha a funkciók között találsz írásra valót. -
And
veterán
válasz
kip.kop
#1463
üzenetére
(Ja, ha ezt a hozzászólásodat is elolvastam volna, akkor számomra is egyértelmű lett volna, hogy 64-es a slave cím
. Szépen látszónak az előbb említett regiszterek, pl. a 7-es "DigitalT" értéke 289, vagyis 28.9 °C. Az 1..3 számú "Offset", "Baud rate" és "Data stream" regiszterek default értékei is jelen vannak: 64, 6, 2.)
Mod.: Igen, ezek szerint legfeljebb 26 regiszter tartalmát tudja lekérdezni, de a kezdő regiszter címe nem csak 1-es lehet, azt át tudod írni az "Address" mezőben. -
And
veterán
válasz
kip.kop
#1461
üzenetére
Ez valóban konkrét infó, de sajnos még mindig kevés, mert hiányzik az eszköz címének konkrét értéke. Erre szolgál az "Offset" nevű regiszter, amelyet be kell állítani (default értéke 64), ill figyelembe kellene még venni az 1..3-as DIP-kapcsolók állapotát is, amelyre a megjegyzés utal (elvileg az Offset regiszter tartalma hozzáadódik az 1..3 DIP-ek által meghatározott értékhez, és az eredmény lesz a cím), de ezen a két oldalon nincs róla több infó. Ha elfogadjuk, hogy ezekkel a dip-ekkel beállítható a "0", akkor az eszköz slave címe 64 lesz. Hasonló a helyzet a kommunikációs paraméterekkel is, bár itt szintén van default beállítás: 19200, 8O1. A fenti beállításokhoz konfigurációs módba kell állítani az egységet, ennek a mikéntje szintén homályban marad.
Ha kipróbálod ezt, akkor elvileg a "DigitalT" és a "DigitalRH" nevű regiszterek értékét kell visszakapnod, 16-bites (signed) integer formátumban, tizedfok / tized-% egységekben:
modpoll -a 64 -r 7 -c 2 -b 19200 -d 8 -p odd -4 10 COM1.
A "TM" nevű regisztert olvasva pedig az "LG" textet (0x4C47) kell visszakapnod:
modpoll -a 64 -r 120 -t 4:hex -1 -b 19200 -d 8 -p odd -4 10 COM1.
Ez utóbbi a kommunikáció ellenőrzésére például megfelel, de jó lenne látni a komplett doksit. Hozzászólásban linkelni tudod, ha hozzáférhető a neten valahol, vagy te feltöltöd valahová, és onnan linkeled. -
And
veterán
válasz
kip.kop
#1451
üzenetére
"Gondolom ha nem is tudnam melyik regiszterben mit tudok kiolvasni, akkor is valamit ki tudnak kiolvasni a "04 - Read Input Registers" es a "03 - Read Holding Registers"-bol."
Az az érzésem, hogy még mindig félreérted a protokoll lényegét. Ez a két (egyébként általában hexadecimális formában megadott) 04h ill. 03h nem egy-egy konkrét regiszter, amelyet olvasol, hanem funkciókód, amely megmondja a lekérdezett slave-nek, hogy mit szeretnénk tőle. Ha megnézed az #1432-ben adott első linket, abban a doksiban szépen fel vannak sorolva az elérhető funkciókódok, és a hozzájuk tartozó kérdés (master) / válasz (slave) adatstruktúrák. Egyébként a modbus-t támogató eszközök nem feltétlenül ismerik az összes lehetséges funkciót. De pl. a "03h" valószínűleg az egyik leggyakrabban alkalmazott modbus-funkció, egy slave több (egymás utáni című) adatregiszterének lekérdezésére szolgál. A kérésben meg kell adni a lekérdezett slave címét, a funkciókódot (jelen esetben 0x03-at), a kiolvasandó regisztercím-tartomány kezdőcímét (16 biten) és hosszát (szintén 16 biten, de legfeljebb 125 lehet a tartomány hossza). A válaszban visszakapod a kért regiszterek tartalmát, egyenként 16 biten. Ha olyan regisztereket olvasunk, amelyek a slave-ben nem 2 byte-on tárolódnak, akkor a a kért adatokat esetenként a master-nek kell a megfelelő formátumra visszakonvertálnia.
Az interfészt (adatformátum: ASCII / RTU, bitsebesség, paritás fajtája, stopbitek száma, slave esetén: cím) nyilván megfelelően kell beállítani az eszközökben, és a fizikai konverterek beállításait sem szabad a véletlenre bízni.
#1452: Az általad linkelt oldalon vannak példák a paraméterezésre. Mondjuk 4 db. 16-bites word kiolvasása a 8-as, RS485 illesztővel rendelkező slave 670-es számú (című, ahol az első regiszter címe a nulla) regiszterétől kezdődően, modbus RTU-n, 19600 8N1 portbeállítás mellett, a PC COM1 portján (majd RS485 konverteren) keresztül:
modpoll -a 8 -r 670 -c 4 -l -0 -b 19200 -p none -4 5 COM1
A többi beállítás default értéken van hagyva, ill. RS485 / Modbus RTU esetén szükségtelen. Ez a segédprogram - mint a weboldala is említi - egy master-szimulátor, vagyis az ezt futtató géppel csak slave(ek) fűzhető(k) össze. Képes a kiolvasott n*16-bites word-öket más adatformátumra gyúrni, ill. felcserélhetőek vele a nem szokványos sorrendű (big-endian) 32 bites integer v. lebegőpontos formátumok adatszavai. -
And
veterán
válasz
kip.kop
#1439
üzenetére
"Ugy ertsem, hogy ha PLC-vel osszekotom, akkor lehet hogy nem is kellenek a bovebb informaciok a reszletekrol es olvasni tudja a me'rt ertekeket a PLC."
Ha ez kérdés akart lenni, akkor a válasz: nem. A modbus alapvetően adott regiszterek (általános célú memóriacímek vagy I/O-k) írásáról és olvasásáról szól, így ha olvasni szeretnénk egy adatot egy slave-ből, akkor nem árt tudnunk, hogy mely címen érjük el a kívánt adatot, és azt milyen formátumban kapjuk. Ha van doksid, ezek az infók biztosan le vannak írva benne. -
And
veterán
válasz
kip.kop
#1437
üzenetére
Le kellene tisztázni, hogy valójában milyen protokollal működik az a rendszer. Ha tényleg modbus-szal (vagy az a 'titokzatos' Kilnbus is valamilyen modbus-szerű képződmény), akkor is kellenek bővebb információk a részletekről: milyen formátumban olvasható az adat a mérőegység(ek)ről, az melyik belső regisztercímen érhető el, stb. Ha ez megvan, akkor lehet tovább lépni. Ráadásul első körben PLC-t említettél, utóbb meg már PC-t, mint lekérdező egységet / mastert (persze az egyik nem zárja ki a másikat). PLC esetén egyszerűbb a helyzet, rengeteg kisebb PLC (akár némelyik programozható relé is) támogatja a modbus-t, vagy olcsó kiegészítővel képes lehet erre. De léteznek pici megjelenítők, terminálok, amelyek szintén tudnak modbus-on adatokat kérdezni. Ha közvetlenül PC-n kell megjeleníteni / tárolni az adatokat, akkor vagy magadnak kell megírnod a szükséges alkalmazást, vagy használhatsz valamilyen fizetős modbus scanner programot, esetleg drágább SCADA-rendszert. Utóbbival már elég sok funkció megvalósítható, de ezek a programok nem feltétlenül olcsók.
-
And
veterán
válasz
kip.kop
#1431
üzenetére
A Modbus-ról itt olvashatsz bővebben: [link], de általában a Modbus-t támogató PLC-k dokumentációja is jól használható segédletnek, hisz utóbbiak a konkrét PLC-típusra jellemző paraméterezést is megadják.
RS485: Kicsit kevered a protokoll és az átviteli közeg fogalmát. Az RS-485 nem határoz meg protokollt, pusztán a busz fizikai jellemzőit definiálja. Egyes protokollok - a Modbus is ilyen - pedig nincsenek közeghez kötve, éppúgy működhetnek RS485-ön, mint RS232-n, etherneten (TCP-csomagban), vagy akár másfajta adatvonalakon.
Erről a bizonyos KilnBus protokollról pedig úgy látom, minimális elérhető információ van, eléggé 'háziszabványnak' tűnik. A rendszerelemekről szóló gyors adatlap alapján RS485 ill. -232 alapokon létezik, de bővebb leírást nem igazán adnak. -
And
veterán
válasz
#95904256
#1294
üzenetére
Amik felénk mennek, éghető gázok és oxigén vonatkozásában: Sieger ([link]), Dräger ([link]), MA Kft ([link]). Főleg telepített érzékelőket használunk, de akad kézi is. A telepítettek mindegyike rendelkezik kimenetekkel, leginkább diszkrét jelzésekhez (éghető gázoknál ARH 20 és 40%, oxigénnél 18 és 17 tf%), ill. akad néhány mérgező anyagot mérő kör is (PPM). Füstérzékelők, ill egyéb kombinált (láng- és hősebességszenzorok) is vannak, de azokról nem tudok sokat, csak azt nagy vonalakban, hogy milyen rendszerhez csatlakoznak.
-
And
veterán
válasz
Blaze71
#1183
üzenetére
Némi hasznos infó: [link]. Ha jól tudom, már kifutott széria, ezért is lehet időnként párezer forintért hozzájutni a legkisebb típusokhoz. Néhány hónapja nálam járt egy ilyen 10 I/O-s kivitel, hogy megnézzem, működőképes-e. Már a szoftverét (PL7-07) is elég nehezem találtam meg, de szerencsére ugyanaz a programozókábel jó volt hozzá, mint a Mikro-, Premium- és Twido-család tagjaihoz (a kábel soros verziója viszonylag könnyen utánépíthető).
-
And
veterán
Könnyen lehetséges, hogy létrában nem lehet ezt megvalósítani Zelio-val, egy pár dolog ugyanis kizárólag FBD-ben működik. Ladder-ben - ha jól látom - nincs lehetőség counter preset megadására.
#1079: Alapműveletekkel FBD-ben egész jól elvan, úgyhogy a hiszterézis nem akkora gond, de hát szerencsétlen mégsem 'igazi' PLC. Viszont a kijelzővel és programozható funkciógombokkal ellátott fajták az árukhoz képest egész használhatóak. -
And
veterán
Nem fix paraméter! Lehet numerikus konstans, de bármilyen blokk számértékkel kifejezhető kimenete, és egy analóg bemenet is. Nálam a szimuláció szerint működött is rendesen. Ha a 0-10V-os analóg bemenetet összekötöd a számláló preset value inputjával, a blokk preset forcing bemenetének segítségével a neked kellő időpillanatban bemásolható a bemeneti változó értéke a számláló aktuális értékébe, így a gyakorlatban analóg (16-bites) regiszterként működik. Igaz, a Zelio 0-10V-os bemenetei mindössze 8-bitesek.
-
And
veterán
Meg lehet oldani funkcióblokkok segítségével (FBD). Az alap probléma ugye az, hogy a Zelio hivatalosan nem támogat általános változókat tároló regisztereket. De ezt meg lehet kerülni pl. egy beírható értéket (preset) kezelő fel/le számlálóval. A számláló preset-érték inputjára kötheted az analóg bemenet jelét, a futás első másodpercében pedig egy rövid impulzust kell adni ugyanennek a számlálónak a preset-engedélyező bemenetére, amire az el fogja tárolni ezt a bemeneti értéket. Mivel a számlálót a továbbiakban nem piszkáljuk (a fel- és lefelé számláló, valamint a reset-bemeneteit üresen hagyjuk, a preset pedig többet nem kap impulzust), annak az 'aktuális érték' nevű kimenete a továbbiakban megőrzi az induláskor kapott értéket. Utána már a megfelelő időzítő és összehasonlító blokkokkal elvégezhető a művelet.
-
And
veterán
válasz
Dezsi82
#1051
üzenetére
Mi mostanában Twido-kat használunk előszeretettel. Nem minden verzión van ethernet, de mi azt szeretjük, amin van. Egyébként Modbus-TCP a célja, egyebet nem támogat rajta. Ha jól tudom, analóg I/O sem a moduláris, sem a kompakt kivitelben nincsen alapkiépítésben, talán az IP67-nevű legújabb típuson van belőle egyetlen. A programozó szoftvere, a TwidoSoft szerencsére ingyenes.
-
And
veterán
Mi annak a chipnek a típusa, ha nem titok? Mert 1/16 °C felbontású adatbuszos példányokat dögivel kapni, de olyannal, amelyiknek a specifikáció szerint az abszolút pontossága is max. 0,1 °C lenne, még nem találkoztam. Főleg nem ilyen széles hőmérsékleti tartományban. Amelyeket láttam, azok szobahőmérséklet közelében úgy-ahogy pontosak (például +/- 0,5 °C), de 80..100 °C környékén és felette ill. fagyponton már nem ritka a +/- 2..3 °C hiba sem.
-
And
veterán
Arra azért ne számíts, hogy ennél sokkal olcsóbban megúszod, ha kész modult veszel. A Pt100-as 'kimenete' ugye alapban ellenállás, ebből csak egy távadó (legyen az kijelzős vagy szimpla fejbe építhető 'pogácsa') vagy átalakító, leválasztó tud másmilyen típusú jelet előállítani. Ha olcsóbb megoldás kell, és van ilyesmiben tapasztalatod, építhetsz is valami egyszerű analóg távadót: [link], nem csak kizárólag Pt100-assal.
-
And
veterán
válasz
#95092224
#827
üzenetére
"Erre tippeltem HW alapnak (jó? / rossz?)"
Az biztos, hogy nem digitális I/O-modulokon cserélnék adatokat egy számítógéppel. Persze ez nyilván attól is függ, hogy miféle és mennyi adatot szeretnénk továbbitani, és melyik irányba. (Pl. egyetlen kontaktus kedvéért lehet, hogy nem bonyolítanám túl én sem, és a PC-re valami egyszerű porton / hardveren keresztül vinném). A digitális I/O nem erre való, a különféle - szokásosan - soros kommunikációs vonalakat meg épp adatcserére találták ki. Sok PLC-n már alapban is van valamilyen adatport, vagy olcsón bővíthetőek ilyesmivel. Ezek némelyike hardveresen egyszerűen (interfészen keresztül, de akár közvetlenül is) összehozható egy számítógéppel. Ilyen lehet pl. az RS232, RS422/RS485-alapú protokollok (pl. modbus), vagy mostanában az ethernet (pl. modbus over TCP/IP), hogy a különféle gyártók háziszabványait ne is említsem. Modbus TCP-vel pl. viszonylag egyszerűen megoldható a PLC memóriacímeinek (regisztereinek) közvetlen irása, olvasása, és az egy 'számítógépesnek' sem olyan emészthetetlen. Azt persze nem említetted, hogy miféle PLC lenne az alany, esetleg már adott, vagy még csak most kell kiépíteni a rendszert. -
And
veterán
Néztem, én is azt linkeltem. Örültem is, hogy végre valami
. A kártyákat már meggyógyítottam a hozzájuk való image-fájlokkal (elvileg, majd hétfőn kiderül, sikerült-e), csak nem tudom, mitől jött épp most elő ez a gond. Ráadásul egy másik, de ugyanilyen típusú CPU-példányon, másik kártyával is ugyanezt csinálta, pedig korábban mindkét párost többször is módosítottuk.
A "jelenlegi verzió" alatt a következőt értettem: a mi moduljainkon elvileg 2.0.0-ás ill. 2.0.8-as fw van, az aktuális utolsó egészen friss kiadás pedig a v2.6.9-es (köztük 7-8 másik verziószámú fw is van). A feature- és buglista egyébként meglehetősen hosszú a frissítések leírásában. Az egyik feltétel a frissítéshez, idézet a Siemens-től: "The module in the station whose firmware is to be updated must have firmware version V2.6.1 or higher and be accessible online." Tehát vagy több lépcsőben kell frissíteni, vagy egyáltalán nem is lehet. Ezen felül a bootloadernek külön verziószáma van, és annál is van megkötés, minimum A0.21.0 számúnak kell lennie. Elvileg frissíthető MMC-n keresztül is, de ehhez nincsenek meg a megfelelő eszközeink, ahogy látom.
Igazából az érdekelne, hogy mit lehet tenni, ha nem lehet frissíteni a CPU-t (vagy az hatástalan marad)? A jelenség csak esetleges, vagy adott konfiguráció és program esetén mindig előjön? Addig kell próbálkozni, míg egyszer csak sikerül a letöltés? Van ezzel kapcsolatban tapasztalatod? -
And
veterán
Üdv! Egy Siemens S7 315-2DP vezérlőnél belefutottam a Szirty által is említett MMC-problémába. Már az is megnyugtató, hogy találtam róla valamit, mert eddig nem nagyon tudtam, mivel állok szemben. Azt észrevettem, hogy kártya nélkül nincs hibajelenség, de egymás után zsinórban két kártyát is 'elrontottam', mindig a program letöltésekor. Ki lehet küszöbölni ez a jelenséget valahogy? A Siemens oldalán láttam, hogy létezik egy rakás újabb firmware is az említett CPU-hoz (a mi példányunkon még talán a v2.0.0 van, ha a feliratát jól láttam). Érdemes lehet azt frissíteni? A legutolsó fw-hez pl. azt írják, hogy azt csak a jelenleginél frissebb kiinduló verzióra lehet ráfrissíteni, ami azért elég vicces. A kártyákat egyelőre felélesztettem, de ez csak részeredmény.
Onnan indult a dolog, hogy a PLC remote I/O-egységének egyik Ex-es modulja meghibásodott, emiatt kellett belenyúlni a hw-konfigurációba, és az érintett inputokat egy másik modul (amelyen volt még szabad csatorna) címére áthivatkozni a programban. -
And
veterán
Pt100 vs NTC kérdéskör: én is úgy tudtam, hogy az NTC-k nincsenek szabványosítva. A Testo oldalán viszont ebben a pdf-ben azt írják, hogy a jelleggörbék és a tűrések szabványosak. Sőt, a -25...+75°C tartományban használatos 'alapkivitelű' NTC-k pontossága 0,2°C, amely még az A-osztályú Pt100 érzékelőknél is jobb. Aztán a 2. oldalon meg már ezt említik: "Az NTC mérési adat
felvevõkre/felfogókra nem vonatkozik szabvány.". Szóval érdekes..
Nem is tudom, hogy használnak-e tömegesen NTC-t az iparban. Én már kénytelen voltam 1-2 alkalommal egyedileg lekalibráltatni (szerencsére cégen belül) tizenvalahány darabot, és lineáris interpolációval közelíteni a köztes értékeket. Az nem ipari alkalmazás volt, és az ellenségemnek se kívánom ezt a módszert, de az adott áramkörbe muszáj volt NTC-t tenni. Tény, hogy vannak szabványos jelleggörbék, melyek az adott típus 25°C-ra vonatkozó (egyébként sajnos sok százalék alaptűrésű) értékére szorzószámokat adnak meg, amelyekkel kiszámítható az adott fajta ellenállása egy bizonyos hőmérsékleten. Itt látható egy ilyen, Epcos-gyártmányú NTC-khez kiadott szorzótábla: [link]. Ahhoz képest, hogy direkt ismert típusú (és ezzel elvileg megadott karakterisztikájú) példányokat szereztem be, a kalibrálás szerint a mért adatok jelentős eltérést adtak az adatlap alapján kiszorzott elméleti értékekhez viszonyítva. Tehát hiába az elméleti pontosság meg az adott karakterisztika, szerintem is jobban jársz, ha a Pt100-nál maradsz. A Pt100 nem olcsó, de azt a tökölődést senki sem fogja megfizetni, amit az NTC-ket választva kellene megcsinálnod. -
And
veterán
(Szia! Próbáltam én a HW-konfigurációból kiindulni, de nem sok sikerrel. Ez C7-es, úgyhogy a hw-konfigban egyedül a 621-es CPU látszódik, egyetlen I/O-tömbbel. A ki- és bemenetek címe ugyanaz a bazinagy tartomány. Ennek nincsenek fizikai moduljai, mint pl. egy S7-300-nak, az összes I/O-ja integrált, ezért okozott problémát. Mondjuk szerencsére csak 4 analóg bemenete van
.) -
And
veterán
Köszönöm a válaszod! A program több helyen hivatkozik az említett PIW-re, amely az érték megjelenítésén túl egy PID-szabályozásnak is az ellenőrzőjele. Ezért az utolsó javaslatodnak megfelelően létrehoztam egy FC-t, amelyik átskálázza a bemeneti értéket. Azzal valóban nem mentem volna sokra, ha csak a kijelzőn változik az érték. Az alany egyébként egy C7-621-es volt, ezért a változó megtalálása sem ment olyan egyszerűen az 'ömlesztett' I/O-címek miatt, de egy 4..20mA-es szimulátor segített ebben. Eredetileg valamilyen globális, már a bemenet konfigurációjánál megadható skálázásra gondoltam, de sajna úgy nem megy. Kicsit macerás volt így elsőre, bújni kellett a helpet, de végül sikerült. Kösz
! -
And
veterán
Üdv! Szintén Siemens PLC-s kérdés: megoldható-e, hogy az egyik analóg bemenetet átskálázzuk? Magyarul van egy 4..20mA-es távadó, amelyik elromlott, és nem pont ugyanolyan méréstartományú eszközt tesznek a helyére, mert az eredetivel megegyező épp nincs kéznél. Ettől pedig a 20mA-es jel nyilván más értelmezést kap (a tartomány alja változatlan marad). Hogyan lehet ezt egyszerűen megváltoztatni, ha egyáltalán? Az eszközeink adottak a Siemens programjának módosításhoz, de sajnos ez egy komplett berendezés része, mi pedig hivatalból más PLC-vel szoktunk dolgozni (annál viszonylag egyszerűen meg tudnánk oldani a dolgot).
-
And
veterán
-
-
And
veterán
Némi keresgélés után rá lehet lelni 1-2 olyan hardverre, amely Neked talán megfelel:
[link], itt találsz mindenféle M-Bus konvertert RS232C-re -> PW-sorozat, de van USB-s meg modemes verzió is. A legegyszerűbb talán a PW3-as illesztő (master), amely legfeljebb 3 slave-et kezel.
Egy másik: [link], bár ez utóbbi ''túl sokat'' tud, amit valszeg. az árcédulája is tükröz.
Az árakról, beszerezhetőségről, hazai forgalmazókról nincs sok infó. Sajnos master oldalra nincs olyan viszonylag egyszerű, cél IC-s megoldás, mint amilyen a TSS721A ([link]) a slave oldalon (utóbbi integrált áramkör Mo.-on is beszerezhető párszáz Ft-ért). -
And
veterán
Hi!
''mondjuk a PLC-kben van sok vedelem...''
Egyrészt. A PLC ipari kivitel, arra van kitalálva. Egyszerűen más felhasználói szegmenst céloznak meg egy PLC-vel, mint egy kontrollerrel. Persze egy PLC-t is kontroller vezérel, de az azért egy ''egyszerű'' PIC-nél jóval többet tud (hogy mást ne említsek, egy PID-szabályozót valszeg. nem olyan egyszerű összehozni PIC-kel ). Aztán: egy mai PLC a legtöbbször moduláris felépítésű, bizonyos szintig bővíthető, külön (esetenként szabványosított) programnyelve van, és mindenféle, az iparban alkalmazott kommunikációs módokat támogat (RS485 / modbus, profibus; ethernet, stb). Egy natúr kontroller meg inkább csak alacsonyabb, áramköri szinten kommunikál ''kifelé'': I2C, SPI, esetleg RS232, USB, stb.
Persze léteznek olyan kisebb kontrollerek is, amelyek nem kimondottan PLC-k, de kevés I/O-számú vezérléshez megfelelőek, sínre szerelhetőek, akár önmagukban is programozhatóak (van saját, néhány billentyűből álló kezelőfelületük meg LCD-kijelzőjük), olcsók, pl. ilyen a Moeller Easy-je.
#13-hoz: ezt a hibát véletlenül nem az okozza, hogy a notebook-ok soros portja általában nem az asztali PC-ken megszokott, szabványos jelszintekkel (+/- 5..15V) dolgozik? (Ez esetben megoldás lehet egy RS232<->TTL konverter, mint a MAX232.)
.![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
. Hiába maradt meg valamilyen szintű támogatás egy újabb cég részéről, a régi programokat érdekes módon fizikailag képtelenek voltak ezután előkeríteni (előtte még tudták). Volt, hogy személyesen járt itt más géphez kapcsolódóan az olasz szervizmérnök, ő is azt mondta, hogy megpróbált utánanézni, de egyszerűen nincsenek meg a régi programok. Szerencsére a HMI az ő esetükben Bartec-gyártmányú volt, ezt errefelé nagyon sok gyártó adja a berendezéséhez.
. Szépen látszónak az előbb említett regiszterek, pl. a 7-es "DigitalT" értéke 289, vagyis 28.9 °C. Az 1..3 számú "Offset", "Baud rate" és "Data stream" regiszterek default értékei is jelen vannak: 64, 6, 2.)
!
Új hozzászólás Aktív témák
- Gaming notebook topik
- Sorozatok
- AMD vs. INTEL vs. NVIDIA
- Úgy állhat le a 16 GB-os GeForce RTX 5060 Ti gyártása, hogy közben nem áll le
- Vezetékes FÜLhallgatók
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Luck Dragon: Asszociációs játék. :)
- Picit gazdaságosabb és halkabb lett a PlayStation 5 Pro legfrissebb verziója
- PlayStation 5
- Okosóra és okoskiegészítő topik
- További aktív témák...
- Pokémon Trading Card Game csomag BONTATLAN
- BESZÁMÍTÁS! ASRock B650M R7 7700 32GB DDR5 1TB SSD RX 7900 XTX 24GB Fractal Design Pop Air RGB 850W
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új Razer Kraken v4 vezeték nélküli gamer fejhallgató
- KÉSZLETKISÖPRÉSI KARÁCSONYI ULTRAAKCIÓ! - MacBook Air M4 16GB 256GB Garancia!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest