OVEN PLC110[M02]-MS4, HMI, OPC och SCADA, eller hur mycket romerskt te en person behöver. Del 1

God dag, kära läsare av denna artikel. Jag skriver detta i form av en recension

En liten varningJag vill varna för att om du direkt förstod vad rubriken handlar om, rekommenderar jag att byta ut den första punkten (själva PLC-kärnan) mot något från en högre priskategori.
Ingen ekonomisk besparing är värd sådan nervpress, subjektivt sett.

För dem som inte skräms av lite grått hår och nervösa tick, kommer jag senare att beskriva i detalj hur detta teknologiska underverk skapades. I denna artikel finns det en kort analys av projektet med en viss grad av kritik.

Uppkomst. Problemlösning

Jag arbetar på en designbyrå, och vi testar automatiseringsutrustning för integration i våra fabriker nyckelfärdig. Nyligen anlände utrustning från OVEN till lagret, och vi beslutade att bygga en testbänk av den:

• PLC110[M02]-MS4 (exekveringsmiljön MasterSCADA 4D)
• Operatorpanel SP307
• Modul för universell analoga signaler MV110-224.2A
• Modul för ingångssignaler för töjningssensorn MV110-4TD
• Mätningsmodul MV110-220.3M

Systemstruktur valdes med åtskillnad av nätverk efter avsikt:

1. Modbus RTU baserat på RS-485 — kommunikation mellan PLC och underordnade enheter (moduler, frekvensomvandlare, intelligenta sensorer, HMI-panel SP307), PLC-mästare i nätverket.
2. Modbus TCP baserat på Ethernet — kommunikation mellan olika PLC:er och med OPC-servern
3. PC-server OPC och SCADA-system fungerar samtidigt som en gateway mellan två olika nätverk (företagets LAN och Modbus TCP-kontroller-nätverk (två nätverksadaptrar med data-routing via standard Windows-mekanismer)
4. Företags LAN har internetåtkomst genom en proxyserver

Systemstrukturen visas i allmänna termer på bilden nedan:

Inbyggd funktionalitet

• Insamling och omdirigering av data från PLC till OPC-server
• Lokal styrning och övervakning via HMI-panelen
• Styrning och övervakning från SCADA via OPC-server
• Styrning från vilken PC som helst i företagets LAN och via internet med SCADA-klient
• Anslutning av mobila OPC-monitorer via LAN och internet
• Naturligtvis arkivering och generering av rapporter

Det verkar som om vi inte missade något. En allmän beskrivning av systemet finns, och nu kommer vi till ämnet (metoder för att lösa problemen kommer att beskrivs i artiklar med implementering av varje enhet):

Uppkomna svårigheter

1. Dokumentation för PLC

Beta-testningen av den angivna PLC:n baserad på MasterSCADA 4D markerades av tillverkaren år 2012. Trots en så imponerande existensperiod för konceptet har utvecklaren i 2019 endast en programmeringshandbok på 28 (!) sidor, där den nyttiga informationen är nästan obefintlig, och skärmdumparna i manualen är från MasterSCADA 3D, vilket är ganska roligt med tanke på att gränssnittet har förändrats.

Även en tråd på forumet med 20 trådar stöds aktivt av tre anhängare och en säljare.

2. Arkitektur PLC-moduler

Detta är ett separat ämne för diskussion. Kort sagt: PLC:n kommunicerar med moduler som Modbus RTU-slave-enheter, som först måste konfigureras med ett verktyg genom att koppla varje modul till en PC via en RS-485-omvandlare.

Kloka gubbar, naturligtvis, kan säkert göra detta utan omvandlare genom PLC:n, och koppla modulerna i serie och skriva de nödvändiga registren, men det kommer med erfarenhet och en enorm mängd smärta.

För en utvecklare som ser en sådan arkitektur för första gången är det verkligen inte användarvänligt.
Dessutom älskar alla analoga moduler att gå ner av okända skäl, vilket tar med sig hela RS-485-nätverket in i Terra Incognita, men detta vill jag också berätta om separat, det är verkligen en epopé. Problemen har, för att nämna, funnits i ungefär 10 år, och tillverkaren skämtar om det. "Man måste erkänna att vi inte lyckades med mallarna", men det är det enda gränssnittet för kommunikation med modulerna, och folk har, fullt seriöst, länge skrivit sina implementationer av Modbus RTU.

Under tiden tog kamomillteet slut... Solen gick ner i horisonten.

3. IDE MasterSCADA

Vi ska inte tala om grafiska verktyg, jag har inte testat dem mycket, men jag kan säga direkt att jag inte gillade dem.

Vi pratar om implementeringen av datautbyte och språken i IEC-standarden:

Kontrollerns fysiska in- och utgångar är inte globala variabler och kan inte nås från vilket program som helst genom att skriva ett alias, exempelvis "DI1". Varje program måste manuellt dra in detta, där en lokal variabel skapas som antingen ärver eller överför värdet. D.v.s. själva PLC:n, i min uppfattning, har blivit något förlorad: enhetens syfte borde vara att förenkla programmeringen av logiken för fysiska kanaler till nivån "Om ingång DI1 aktiveras - slår vi på utgång DO1", och det ser ut så här «Ingång DI1 — Variabel LI1 — Variabel LO1-Utgång DO1», även utan kunskap om denna princip kan IDE ge det märkliga meddelandet «Boolesk-Boolesk omvandling är omöjlig» (troligen är någon av dem en pekare, men jag föreställer mig i författarnas redigering, så harmoniskt).

Programmeringsspråken ST, FBD, SFC är tillräckligt omfattande och det finns alternativ för bekvämlighet, men dessa komponenter är inte funktioner utan klasser, i vilka metoderna är inbyggda, och för det mesta finns det ingen dokumentation med beskrivning av funktionalitet och datatyper. Min ihärdighet ledde mig till kärnbiblioteken för CodeSys, därifrån alla dessa funktioner togs, deras dokumentation hjälpte mig.

4. Utbyte med panelen SP307

Ett ganska intressant evenemang för dem som inte vet hur de ska spendera ett par dagar.

Standardtestning av GUI (HMI eller SCADA) för mig är att göra 6 prover:

1. Läsa diskret signal
2. Skriva diskret signal
3. Läsa heltalsvärde
4. Skriva heltalsvärde
5. Läsa flyttal
6. Skriva flyttal

Därför ritar jag 6 primitivkomponenter på skärmen och kontrollerar dem i ordning
Utbytet är helt likadant som med moduler, men från en separat port PLC RS-232/485, och verkar mer stabilt. Eftersom HMI-slaven, så skrev jag till den vid ändringar, och läste via polling var 500 ms för att inte missa operatörens handlingar.

De första 4 punkterna genomfördes utmärkt, men 5 och 6 orsakade problem.

Vi skickar data av typen Single Float, visar dem på skärmen och ser att datan inte stämmer, även om alla utdata-inställningar (Float, dimension 1 register etc.) är korrekta. Det skulle vara osant att säga att dokumentationen inte beskriver en sådan situation, men försök hitta i vilken och var, det är roligt från sidan.

Efter en hysterisk genomgång av alla inställningar som rör själva datan och dess sändning, skriver vi till supporten, svarstid i genomsnitt 5-6 kalenderdagar, arbetar enligt standardprotokollet för support «Kontrollera att strömmen är på — kontrollera programvaruversionen — vänligen vänta ytterligare en vecka—Gå vidare med att lösa det själva».

För övrigt löstes det med att aktivera en kryssruta på en helt orimlig plats med en helt orimlig etikett.

Funktionen på skärmen har inte stöd för inmatning av analog signal av typen «Glidare», kan endast skrivas in i textfältet med siffror. Det är helt fantastiskt, antingen använder vi knapparna «±» och skriptet själva, eller så skriver vi in siffran med tangentbordet, vi glömmer mjuk kontroll av någon drive.

Jag kommer inte att överbelasta artikeln, så jag kommer att beskriva problemen på den översta nivån i del 2.

Sammanfattningsvis, vill jag påpeka att jag hade tillräckligt med frihet och mycket tid för att lösa dessa problem, som vid första anblick kan verka löjliga, men orsakar mycket smärta för den drabbade. Under begränsade tidsramar är det kritiskt att stöta på sådana problem.

P.S.: Alla punkter som presenteras här är subjektiva och är bara ett försök att varna de ovana, snarare än att diskriminera tillverkarna. Jag ber att ni ser på denna artikel just ur detta perspektiv.

Den andra delen är redan här: klicka

Källa: habr.com