Profibus + ethernet protokol

 ( meditor | 2018. január 26., péntek - 12:24 )

Kedves fórum- és fejlesztőtársak!

Adva lenne egy plc hálózat, amely profibus + ethernet vonalon szolgáltatna adatokat.
Ehhez kéne egy drivert írnom, hogy egy mérésadatgyűjtő rendszer el tudja venni azokat.
Szeretnék tájékozódni a témában, kérdezem tisztelettel, van-e valakinek tapasztalata
ez ügyben, merre induljak el, milyen anyagokat érdemes átnyálazni.

A válaszokat előre is köszönöm: med.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

OPC?

Frissites:
A legtobb PLC gyartonak van OPC Server alkalmazasa a termekeihez. De vannak mas cegek is amelyek arulnak ilyen programokat. Ezeknek a lenyege, hogy tartalmazzak a drivereket az adott PLC-hez. Neked csak be kell konfiguralni: megadni, hogy mi a cime a PLC-nek, es hogy mely memoriacimrol levo adatokat olvasson ki belole. Aztan ezeket az informaciokat elerhetove teszik az OPC Client alkalmazasok szamara. Ha valami ipari standard program gyujti az adatokat, akkor jo esellyel alapbol tud OPC Client-kent mukodni. Ez esetben szinten nem kell semmit programoznod, csak bekonfigralnod az OPC Server-hez szukseges csatlakozasi parametereket, majd a kiolvasando valtozokat. Ha netan megsem tudja, es neked kell megirni ezt a reszt, akkor is talasz keszen szamos OPC Client library-t. En anno egy C#-hoz irt library-t hasznaltam, es nagyon konnyu volt az integralasa. Annyi hatranya van, hogy behoz egy kis kesleltetest az adateleresbe.
Jo par eve mar, hogy nem foglalkozom ipari automatizalassal. Akkoriban aktualis adatok olvasasara az OPC DA volt hasznalva. Akkor kezdtek el fejleszteni az OPC UA-t. Vaoszinuleg manapsag mar ez hasznalatos.


Sic Transit Gloria Mundi

Mivel több részletet nem írtál, feltételezem, hogy S7-röl van szó.
Én inkább az MPI-ra csatlakoznék ethernet konverterrel. Ahhoz vannak dirverek a neten (forráskóddal) és nem zavarják az osztott perifériákat a profibuszon. (Konverter van pl. http://vipa.at/index.php?lang=D&category=data&products=322 oldalon).

Az MPI-t lehet jobb lenne meghagyni programozni es helyi diagnosztikanak, esetleg lokalis kijelzonek.

Ethernetet, gondolom, itt nem kell reszletezni, meg ha Industrial Ethernet vagy ProfiNET is :}. Profibus alacsony sebesseg eseten repeater hasznalataval kilometerekre is elvilheto. Az MPI, ha jol emlekszem, talan 50 meter. Bar, adott esetben az is eleg lehet.


Sic Transit Gloria Mundi

Ettöl még megy a programozás lazán. Egy HMI nem kommunikál sokat.
A konverter amit ajánlottam, rögtön és helyben ethernetet csinál, azt olcsóbb messze vinni.
Ha megnézed a linket direkt rá lehet dugni a programozó kábelt is,
valamint tcp-n keresztül is tudod direkt a plc-t programozni.

Nem vagyok benne biztos, hogy, ha hivatalos Siemens kabeleket es repeaterek akarsz hasznalni az ethernetet olcsobb elvinni tobb szaz meterre. Alacsony sebessegen (187.5 kbps) a Profibus repeater nelkul is megbir talan 1 km-t. Mondjuk Profibus eseten a szamitogepbe is kell valami, ami tud RS485-ot. De, mig nem tudunk reszleteket, elegge folosleges errol vitazni.

A konverter kapcsan, bevallom, a linket nem neztem meg. Reszemrol, ha csak anyagi megszoritas nincs, maradnek hivatalos Siemens adapterek hasznalata mellett. Remlik valami, hogy talan volt Siemens-es emberkek alapitottak a VIPA-t, es kezdtek el S7 koppintas PLC-ket kesziteni, de ettol fuggetlenul, ipari kornyezetben nem biztos, hogy VIPA termekeket kotnek a Siemens PLC-re. Felteve, hogy egyaltalan Siemens PLC-krol van szo.

A profibus + ethernet meghatarozast en ugy ertelmezem, hogy a PLC-n van egyarant Profibus es Ethernet interface. Ily modon felesleges a konverter.


Sic Transit Gloria Mundi

Megpróbálok pontosítani, nem biztos, hogy sikerül.

Adva van egy rendszer, amiben PLC-k vannak, ezek a PLC-k szedik össze az elemi adatokat a szenzorokról.
Az adatokat profibusra kerülnek és ethernetcsatlakozon keresztül lehet hozzáférni.

Adva van egy mérésadatgyűjtő rendszer, aminek minden részlete ismert, forráskód szinten is.

A kettő közé kell betenni egy interface-t. Annyit tudok, hogy a hardver rendelkezik ip-címmel.

A kérdés az, hogy itt egy socket alapú kommunikációt képzeljek el, vagy van valami
speciális eljárás, illetve vannak-e olyan nyilvános minták, leírások, amik segíthetnek.

[Az eddigi segítségeket köszönöm]

> Sol omnibus lucet.

"Az adatokat profibusra kerülnek és ethernetcsatlakozon keresztül lehet hozzáférni."
Igaz, hogy reg nem foglalkozom automatizalassal, de ennyit nem valtozhatott a fizika azota :}} Ha jol emlekszem, a Profibus fizikailag 2 szalon meno RS485. Az Ethernet meg ugye Ethernet. Ott valaminek meg lennie kell...

Amugy milyen tipusu PLC?


Sic Transit Gloria Mundi

Igen nekem, is kézenfekvőbb lenne, egy soros (RS485/RS232) kommunikáció. Végülis 2 drót az ethernet csatlakozóban is van (-::
Valszeg van valami okosság benne, amitől IP-cím alapú lesz az egész. Valószínűsítem az adatok TCP-be való csomagolását,
többet nem tudok - egyelőre. A PLC típusát nem tudom, de ez gyorsan kideríthető.

> Sol omnibus lucet.

Azt a valamit is kellene elemezni, ami a Profibus-bol csinal Ethernetet, hogy pontosan milyen protokolt hasznal: Industrial Enthernet, Profinet, valami sajat, stb.


Sic Transit Gloria Mundi

A PLC típusa: SIEMENS 212-1BE40-0XB0

Kaptam néhány manualt, de ezek főleg magára a PLC programozására szolgálnak, egyelőre nyomozok tovább.

> Sol omnibus lucet.

Ilyet már programoztam.
Ennek a kacatnak van webszervere is...
De vannak benne számlálók is...

Én a helyedben a számlálókkal gyűjtenék eseményeket, vagy az állapotokat tenném ki web-re.
Esetleg darabnullázót stb. lehet csinálni, analóg állapotokat (ha van) kiíratni.
Aztán http-n keresztül begyűjteném amit kell...

Anno az első verziómat ca. 5 éve úgy csináltam, hogy amíg nem jött meg a KTP panel, addig a paramétereket a belső webszerverén keresztül kellett beadni...

Ez is eszembe jutott. Rányitok a 80-as portra és egy "get"-tel lehúzom az oldalt, aztán a halmazból kiszedegetem az adatokat. Nem túl elegáns, de vészmegoldásnak jó.

> Sol omnibus lucet.

Kulcsszavak:

open ie communication

> Sol omnibus lucet.

ez esetben nem "drivert" kell írnod, hanem a mérés-adatgyűjtődben egy tcp porton hallgatni, amire a 1212-es kvarcjáték majd kapcsolódni fog, és mondjuk tsend_c-vel átküldi az adatokat (aminek a felépítésről előzetesen megállapodtatok, és amit a 1212-es programja összeállít neked)

opcionálisan úgy is lehet konfigolni plc oldalon, hogy a mérés-adatgyűjtődnek kelljen konnektolni

Igen én is így látom, bind, listen, stb. (-::

> Sol omnibus lucet.

ps.: Azért ez a mérésadagyűjtő aspektusából mégiscsak driver.

Valami ilyesmi rémlik nekem is, bár csak a partvonalról kotyogok bele, sok éve nem nyúltam már S7 1200-ashoz. :(
Akkor a libnodave-et használtam a kommunikációra, működött egyszerűen.

Nem tud valaki egy szakterületet a GIS és a PLC-k határmezsgyéjén? Szívesen visszatérnék PLC-zni, ha találnék ilyen munkát.

nodave ezzel az eszközzel nem játszik, snap7 vagy hasonló igen, de ezek nem opencomm témák (hanem s7 comm)

Tényleg, akkor nodave-et a Logo-khoz használtam. Köszi, rég volt.

SCADA rendszerek fejlesztese? Vannak esetek, mikor van/kell GIS komponens is hozza, es a PLC-kkel valo kommunikacio is adott...


Sic Transit Gloria Mundi

Nem tudom a Profibus hogyan jott kepbe, de, ahogy nezem a leirast, ez a PLC alapbol csak Profinet interface-el van ellatva. Profibushoz kulon kommunikacios modul kell(ene) hozza.

A PLC programjahoz van dokumentaciod? Ahhoz, hogy kinyerd a megfelelo adatokat belole, tudnod kell, hogy az informacio hol es hogyan van tarolva: melyik DB (bar elvileg lehet a bit memory reszen is) melyik cimen, hany biten es integer vagy floating point formaban.

Open IE Communication kapcsan nem tudok segiteni. Reszemrol az lenne az utolso a sorban, amivel probalkoznek. Ha jol emlekszem, az arra van, hogy sajat protokollt hasznalva kommunikalja a PLC-vel. Ez azt is jelenti, hogy a PLC oldalon is implementalni kell ezt a protokolt a TCON, TSEND, TRCV, stb fugvenyekkel. Kis leiras hozza

Ha kell modositani a PLC oldalon is, lehet egyszerubb Modbus TCP/IP-t hasznalni. Szerintem azt konyebb a PC oldalan implementalni, es a PLC oldalan is van kesz library hozza (bar lehet ujabban alapbol tudjak a PLC-k).

Bar en tovabbra is az OPC Server iranyaba mennek :} Jo esellyel az jar a legkevesebb programozassal.


Sic Transit Gloria Mundi

>> Ahhoz, hogy kinyerd a megfelelo adatokat belole, tudnod kell, hogy az informacio hol es hogyan van tarolva

open communication esetén pont nem kell tudnia, (s7 comm esetén kellene tudnia, de annak megint egyéb feltételei vannak (engedélyzett put/get, a stuffok nonoptimized dbben, stb))

Ezzel nem dolgoztam, ugyhogy pusztan a sajat kivancsisagom miatt kerdezek reszleteket rola. Open IE communication eseten szukseges a PLC programjanak modositasa, hogy a TSEND_C/TRCV_C fuggvenyekkel lehessen kuldeni/fogadni adatokat. Nem? A kezdeti leirasbol nem volt szamomra evidens, hogy lehet-e modositani a PLC programjat. Amennyiben van aki atprogramozza a PLC-t, ugy jobb lenne az illetovel megbeszelni, hogy milyen lehetosegek vannak...


Sic Transit Gloria Mundi

Szerencsére a fickó megvan és segítőkésznek tűnik.

> Sol omnibus lucet.

Szerintem uljetek szepen ossze, es beszeljetek meg, hogy milyen lehetosegek vannak. Mindegyik opciot elemezzetek, hogy mennyi munkaval jar mindket oldalon az implementalasa. Mindenkepp vegyetek figyelembe, hogy mely opciok maradnak legkozelebb ipari standardokhoz es hoznak be minimalis specifikus implementalast, hogy egyszerubb legyen a dokumentalas az esetleges kesobbi bovites/modositas szamara.


Sic Transit Gloria Mundi

>> Open IE communication eseten szukseges a PLC programjanak modositasa

természetesen

>> A kezdeti leirasbol nem volt szamomra evidens

én abból úgy értettem ez már megoldott, csak "át kell venni" az adatokat

Valóban, a PLC alapszinten már működik, inkább nekem kell alkalmazkodni a helyzethez. Persze, ha nem túl nagy munkával könnyíteni lehet a driverírást, vagy méginkább: ha nem nagy PLC programozási munkával EGYSZERŰBBÉ válik a driver oldal, akkor ez az út is járható lesz szerintem.

> Sol omnibus lucet.

nem nagy ügy plc oldalon, összemazsolázza neked egy bufferbe, és átlövi mondjuk fix méretű csomagban (tsend_c esetén a kapcsolat fenntartásával sem kell foglalkoznia - természetesen az fb sátusz/hiba kimeneteit le kell azért kezelni)

a te oldaladon így gyakorlatilag listen/bind/accept/receive + feldolgozás az egész (a csomag felépítése megállapodás kérdése, az endiannessre mindig (float esetén is) figyelj :))

ha kétirányú kommunikációt szeretnétek ugyanazon a porton, meg tudja csinálni egy az ugyanazzal a connection id-vel használt trecv_c-vel

O.K., köszi valszeg ez lesz a csapásirány.

> Sol omnibus lucet.

Miert jo sajat adatstruktura bevezetese letezo ipari standardok hasznalata elleneben? A floating point valtozokat kezeli vagy nekem kell a DWORD-ot floating point-ta alakitanom?
Ha 2 het mulva rajonnek, hogy kell menteni mas valtozot is, esetleg status allapotot:
- Modbus TCP: a PC oldalon csak novelem a kiolvasott terulet meretet (ha egy teruleten vannak a kivant adatok) vagy kiolvasok egy masik memoria zonat is. Csak a memoria terkepre van szuksegem, ami standard formatumu. Ha a PLC iranyaba is kell kuldeni adatot, akkor siman meghivom a write fuggvenyt. PLC oldalon nem kell modositani semmit.
- OPC: a PC oldalon hozzaadok egy uj valtozot az OPC serverben, amit a programban kiolvasok. Csak a memoria terkepre van szuksegem, ami standard formatumu. Ha a PLC iranyaba is kell kuldeni adatot, akkor az OPC serverben RW tipuskent definialom a valtozot, es a programbol maris irhatom.
- Open IE Communication: modositani kell a PLC programjat, hogy mazsolazza be az uj valtozot a bufferve, majd a PC oldalon is modositani kell, hogy olvassa ki azt. Mindket oldalon erteni kell, hogyan lettek osszemazsolazva az adatok. Ha a PLC iranya is kell kuldeni az adatot, akkor egyreszt implementalni kell a PLC-ben, valamint ott is kell a sajat adatstruktura definialasa.

Azt hiszem, tul sok takolt megoldast kellett kiepitenem penzszuke miatt, ezert tulsagosan alergias vagyok a sajat adatstruktura es protokol hasznalatara :}}


Sic Transit Gloria Mundi

>> Miert jo sajat adatstruktura bevezetese

a másik két általad vázolt példában is valamilyen struktúrában állnak rnedelkezésre az adatok
ezt a belső elrendezést és ennek esetleges változását nem kell ismerni kívülről az ajánlott esetben

>> letezo ipari standardok hasznalata elleneben

létező ipari standardról van szó itt is

>> A floating point valtozokat kezeli vagy nekem kell a DWORD-ot floating point-ta alakitanom?

a legegyszerűbb esetben real típusúként írja ki, te iee754 floatként olvasod be (illetve fordítva is)

>> Ha 2 het mulva rajonnek, hogy kell menteni mas valtozot is, esetleg status allapotot:

mindhárom esetben egyszerű a megoldás, de az első két esetben az adatok plc-n belüli elrendezését/változását kell ismerni kívülről (is), a harmadik esetben csak a kiajánlott csomag struktúráját

>> penzszuke miatt

eleve ezt feltételezem az 1200-as miatt ;)

>> sajat adatstruktura

mindhárom esetben egyedi az adatstruktúra

>> es protokol

ilyenről nincs szó

Igen, a modbus is járható út, ráadásul ezt már megírtam egy korábbi munkához. A jelzett PLC tudja a modbust is.

> Sol omnibus lucet.

A profibus úgy jött képbe, hogy azt mondták: profibus és én jobb híján elhittem (-::
Valóban profinetről van szó.

Természetesen nagyon szépen köszönök minden tanácsot és információt!

> Sol omnibus lucet.

Modbus/TCP lett a végeredmény.
Üdv: med.

> Sol omnibus lucet.

Sziasztok!

keresek valami használható modScan-t Linux alá. Egy párat megnéztem, egyik sem hatott meg, hátha valakinek van valami jól bejáratott metódusa.

A válaszokat előre is köszönöm.

> Sol omnibus lucet.

Az általad küldött típus alapján ez egy Siemens S7-1200 PLC.
Alapvetően ProfiNet lesz az az "ethernet csatlakozó", nem pedig ProfiBus.

Google-ben "snap7 s7-1200" keresőszavakkal indulj el ;)
Esetleg ajánlom még figyelmedbe a Node-Red-et, annak is van kész S7 modulja.

Amennyiben tudsz konzultálni a PLC-t programozó emberkével, akkor OPDB-be szépen ki tudja tenni azokat az adatokat, amire szükséged van, onnan meg simán ki tudod olvasni. Az adatgyűjtős géped egyik ethernet lábát kell csak bele lógatni a PLC-s ProfiNet alhálóba.

Köszi, nagyjából itt tartunk, ahogy azt leírtad. Megvan a libmodbus forrása is a tesztprogramokkal, gond nélkül fordult és a héten talán megkapom a CPU-t valami kis mórickaprogrammal, hogy lehessen tesztelni. A ModScan valamilyen linuxos verziója még jó lenne, erre céloztam az előző bejegyzésemmel.

> Sol omnibus lucet.

még egy tipp, ha csak egy extra tool kell tesztelni:
a TwinCAT-et (PC alapú realtime PLC) letöltheted és 7 napig ingyenesen kipróbálhatod az összes kiterjesztéssel, többek között kipróbálható a Modbus TCP szerver és kliens valamint PROFINET device és controller is (= a te géped lesz a PLC). Ha lejárt a 7 nap, egy kódot kell megerösíteni és van újra 7 napod.

Megkóstolom az m-Duinó plc-t. Egy nap alatt kihozta az rs-components, adtam neki, tápot azt már fordult is a modbus/TCP protokoll. Jó kis tesztcucc lesz. Teszek rá hőmérőt, potit, meg kacsolókat és a ledekkel meg egy voltmérővel nézem az output oldalt. Az adatokat saját mérésadatgyűjtővel kapom el.

Ha valaki érdekel, beszámolok az eredményről.

Üdv: m.

> Sol omnibus lucet.

igen, érdekel

Engem is érdekel.

Egyelőre az ethernet élesztéssel bajlódok. Nincs IP cím, a példaprogramok sem adnak vissza jót.
Hardver probléma? Majd meglátjuk.

Ha valakinek van M-duinoja vagy Arduinó Mega2560 alaplapja az szóljon, küldök neki kódot, hogy nála fut-e rendesen. Üdv: m.

> Sol omnibus lucet.

A megoldás: download ethernet2 mduino. Van ip, connectál, pingelhető.
Következő: Élesztem a modbust. A modbus_lib ütközik az ETH2-vel.

****

Ez is megvan A Mudbus.h-ban ki kell kommentezni az ethernet includot.
Fordul, indul a modbus, telnettel látja az 502-es portot.

Megírom a modus clienst, a server oldalon meg beadok valami adatot a regiszterekbe.
Ha ez megy, akkor logikailag kézben van, föl kell rá akasztani a szondákat, oszt jónapot. (-::

> Sol omnibus lucet.

Folytatás itt: https://hup.hu/node/159995

> Sol omnibus lucet.