OVEN PLK110[M02]-MS4, HMI, OPC és SCADA, vagy mennyire van szüksége egy embernek kamillatea. 1. rész

Üdvözöljük a cikk olvasóit. Ezt egy áttekintő formátumban írom.

Kis figyelmeztetésSzeretném figyelmeztetni, hogy ha azonnal megértette, miről van szó a cím alapján, akkor javaslom, hogy az első pontot (tulajdonképpen a PLC mag) cserélje valami másra, ami az árkategóriában egy szinttel feljebb van.
Egy fillér megtakarítás sem éri meg annyi idegességet, ez szubjektív.

Azok számára, akiket nem ijeszt meg a kis ősz hajszál és a stressz amplitúdója, később részletesen leírom, hogyan készült ez a technológiai csoda. Ebben a cikkben azonban egy rövid elemzés a projektről, bizonyos szintű kritikával.

Kezdet. A feladat megfogalmazása

Tulajdonképpen mérnöki irodában dolgozom, és automatizálási berendezéseket tesztelünk, amelyeket kulcsrakész integrációnkhoz használunk a gyárainkban. Nemrég érkezett egy OVEN berendezés a raktárba, és úgy döntöttünk, hogy építünk egy tesztfelállást belőle:

• PLC110[M02]-MS4 (MasterSCADA 4D végrehajtási környezet)
• Üzemeltető panel SP307
• Analóg jelek univerzális bemeneti modulja MV110-224.2A
• Feszültségérzékelő jelek bemeneti modulja MV110-4TD
• Mérőmodul MV110-220.3M

A rendszer felépítése A hálózatok cél szerinti elválasztásával lett kiválasztva:

1. Modbus RTU RS-485 alapon – a PLC kommunikációja az alárendelt eszközökkel (modulok, frekvenciavezérlők, intelligens érzékelők, HMI SP307 panel), PLC-mester hálózat.
2. Modbus TCP Ethernet alapon – Különböző PLC-k közötti kommunikáció és az OPC szerverrel
3. PC-szerver Az OPC és SCADA rendszerek egyúttal kapuként működnek a két különböző hálózat között (a vállalat belső LAN és a Modbus TCP vezérlőhálózata (két hálózati adapter az adatok Windows standard megoldásaival történő irányításával)
4. A vállalati LAN internet-hozzáféréssel rendelkezik egy proxy szerveren keresztül

A rendszer felépítése általános formában az alábbi képen látható:

A beépített funkciók

• Adatok gyűjtése és átirányítása a PLC-től az OPC szerverre
• Helyi irányítás és megfigyelés HMI-panelek segítségével
• Irányítás és megfigyelés SCADA-n keresztül az OPC szerveren
• Irányítás bármely PC-ről a vállalat LAN-ján és az interneten keresztül SCADA klienssel
• Mobil OPC megfigyelők csatlakozása LAN-on és interneten
• Természetesen archiválás és jelentéskészítés

Úgy tűnik, semmit nem hagytunk ki. Általános leírás van a rendszerről, és most, tulajdonképpen a témától (az eltávolítás módját cikkekben fogom leírni, amely minden egyes egység megvalósítását tartalmazza):

Felmerült nehézségek

1. Dokumentáció a PLC-hez

A MasterSCADA 4D kernel-based PLC beta testing was announced by the manufacturer in 2012. Despite such an impressive duration of the concept's existence, what the developer has in 2019 is merely a programming guide comprising 28(!?) pages, which contains almost no useful information, and the screenshots in the manual are from MasterSCADA 3D, which is quite amusing considering the interface has changed.

A forum thread is also actively supported by three advocates and a sales manager, consisting of 20 topics.

2. PLC Architecture

This is a separate topic for discussion. Briefly: the PLC communicates with the modules as Modbus RTU slave devices, which must first be configured using a utility by connecting each one to a PC through an RS-485 converter.

Smart guys surely know how to do this without a converter through the PLC, connecting the modules in series in the network and writing the required registers, but this comes with experience and a lot of pain.

For a developer seeing this architecture for the first time, it is not very user-friendly.
Also, all analog modules tend to fail for unknown reasons, taking the entire RS-485 network into Terra Incognita, but I also want to discuss this separately; it's quite an epic saga. By the way, this issue has been around for about 10 years, and the manufacturer jokes about it. "It must be acknowledged, our templates have not succeeded", however, this is the only interface for communicating with the modules, and people, quite seriously, have long documented their Modbus RTU implementations.

Meanwhile, chamomile tea was running out... The sun was setting.

3. MasterSCADA IDE

I won't discuss the graphical tools, I haven't tested them much, but I will say right away that I didn't like them.

We are talking about implementing data exchange and the IEC standard languages:

The physical inputs and outputs of the controller are not global variables, and one cannot refer to them from any part of the program just by writing an alias, for example, "DI1". Each program needs to manually include this, creating a local variable that inherits or passes on the value. Thus, the entity of the PLC seems to be a bit lost in my view: the device should simplify programming the logical operations of physical channels to the level of "If input DI1 is triggered — turn on output DO1", but it looks like this. «DI1 bemenet — LI1 változó — LO1 kimenet DO1», szintén e prinicp nem tudása miatt az IDE figyelmeztetést adhat, miszerint „Boolean-Boolean konverzió nem lehetséges” (valószínűleg az egyik pointer, de az alkotók verziójában így harmonikusabb).

A ST, FBD, SFC nyelvek könyvtárai elég terjedelmesek, van lehetőség a kényelmes programozásra, azonban ezek a komponensek nem funkciók, hanem osztályok, amelyekben a módszerek rejtve vannak, míg a többségükhöz nincs dokumentáció, amely a funkciókat és adat típusokat leírná. A makacs keresésem a CodeSys kernel könyvtáraiba vezetett, ahonnan ezek a funkciók származnak, és a dokumentáció segített.

4. Kommunikáció az SP307 panelnél

Elég érdekes esemény azok számára, akiknek nincs hova elkölteni pár napot.

A szabványos GUI (HMI vagy SCADA) tesztelés számomra 6 próbát jelent:

1. Digitális jel olvasása
2. Digitális jel írása
3. Egész szám érték olvasása
4. Egész szám érték írása
5. Valós szám érték olvasása
6. Valós szám érték írása

Ennek megfelelően 6 primitív komponenst rajzolok a képernyőre, és ezeket sorban ellenőrzöm.
A kommunikáció teljesen hasonló a modulokéhoz, de a PLC külön RS-232/485 portjáról, és úgy tűnik, stabilabb is. Mivel HMI-slave, csak írtam bele változáskor, és olvastam pollinggal 500 ms-onként, hogy ne mulasszam el az operátor cselekedeteit.

Az első 4 pont tökéletesen teljesült, de az 5. és 6. problémákat okozott.

Single Float típusú adatokat küldünk, megjelenítjük a képernyőn, és látjuk, hogy az adatok nem azok, bár minden kimeneti beállítás (Float, 1 regiszter méret stb.) helyesen van beállítva. Hamis lenne azt mondani, hogy a dokumentációban nincsen leírva az eset, viszont próbálja meg megtalálni, melyikben és hol, ez érdekes oldalról.

A lehetőségek hisztérikus átnézése után, amelyek az adatokra és azok küldésére vonatkoznak, írunk a technikai támogatásnak, a válasz átlagosan 5-6 naptári nap, dolgozunk a technikai támogatás alap scriptjén: „Ellenőrizze, hogy a tápegység be van-e dugva — ellenőrizze a szoftververziót — kérem várjon még egy hetet — menjünk neki egyedül”.

Megjegyzendő, hogy a probléma egy megjegyzés kipipálásával oldódott meg egy teljesen nem megfelelő helyen, teljesen nem megfelelő felirattal.

A képernyő funkciójába nem lett beépítve az analóg „Potenciométer” formátumú jel bevitele., csak számokkal lehet beírni a szövegmezőbe. Ez egyszerűen csodálatos, vagy használjuk a „±” gombokat és a szkript saját magunk készítjük el, vagy beírjuk a számot a billentyűzettel, a lágy vezérlésről bármilyen hajtással pedig megfeledkezhetünk.

Nem akarom túlterhelni a cikket, ezért a 2. részben a felső szintű problémákat fogom ismertetni.

Összefoglalva, szeretném megjegyezni, hogy elegendő szabadságom és sok időm volt ezen problémák megoldására, amelyek első ránézésre nevetségesnek tűnnek, de sok fájdalmat okoznak az érintetteknek. Korlátozott határidők mellett kritikus, ha ilyen problémákkal kell szembenézni.

P.S.: Az itt bemutatott összes tézis szubjektív, és csak arra próbálja figyelmeztetni az előkészületleneket, nem pedig diszkrétálni a gyártókat, kérem, ezt a cikket így tekintsék.

A második rész már itt van: kattintsunk

Forrás: habr.com