Új hozzászólás Aktív témák
-
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.) -
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
-
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
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
(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
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
Ü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
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?[ Szerkesztve ]
-
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
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
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
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
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
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
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
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
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
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
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
#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
#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.[ Szerkesztve ]
-
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
#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.[ Szerkesztve ]
-
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.[ Szerkesztve ]
-
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
#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
Ü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![;]](//cdn.rios.hu/dl/s/v1.gif)
? 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
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
(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
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
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
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
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.[ Szerkesztve ]
-
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
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
(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
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
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
#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
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.)[ Szerkesztve ]
-
And
veterán
-
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.)
). 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.
!
.)
. 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.)![;]](http://cdn.rios.hu/dl/s/v1.gif)
? 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?
.
Új hozzászólás Aktív témák
- Amazfit I T-REX 2 I GTS 3 I GTR 3 I GTR 3 Pro
- Új Latitude 7440 2-in-1, FHD+ IPS kihajtható érintő, i7-1365U, 32GB DDR5, 512GB NVMe, IR kamera, gar
- Beszámítás! GB H610M i5 13400F 32GB DDR4 1TB SSD RTX 3070Ti 8GB MONTECH AIR 1000 Lite Corsair 650W
- Xiaomi Instant Photo Printer 1S Set Bontatlan!
- Beszámítás! GB H610M i5 13400F 16GB DDR4 250GB SSD RTX 3070Ti 8GB MONTECH AIR 100 Lite Chieftec 700W