Kliknutím na „Prijať/Prijať všetky“ súhlasíte s ukladaním súborov cookies na vašom zariadení na zlepšenie navigácie na stránke, analýzu používania stránky a pomoc pri našom marketingovom úsilí. Viac informácií nájdete v našich Zásadách ochrany osobných údajov.
MožnostiOdmietnuťPrijať
4.3.2025

Komunikácia - Mitsubishi MELSEC protokol

Peter Humaj

IT Specialist

Komunikácia - Mitsubishi MELSEC protokol

Dnes si povieme niečo o komunikácii s PLC vyrábanými firmou Mitsubishi. Aby som bol presný, vyrába ich firma Mitsubishi Electric. A ktoré PLC mám konkrétne na mysli?

Výrobné rady MELSEC

Existuje niekoľko výrobných rád PLC vyrábaných Mitsubishi Electric:

  • MELSEC-iQ-R
  • MELSEC-iQ-F
  • MELSEC-Q
  • MELSEC-L
  • MELSEC-F
  • MELSEC-QS/WS
  • MELSEC-A – produkcia jednotlivých modelov skončila v roku 2006/2008/2014

My sme sa zamerali na rady MELSEC-L a MELSEC-Q. Komunikáciu s nimi popisuje dokument MELSEC Communication Protocol Reference Manual. Tento dokument hovorí aj o rade MELSEC-iQ-R, zároveň ale hovorí iba o sériovej komunikácii s touto radou. Implementácia protokolu v D2000 sa primárne sústredí na Ethernet komunikáciu.

Obrázok 1 - Rady a modely podporujúce komunikačný protokol MELSEC

Z pohľadu klasifikácie sa jedná o štandardný request/response komunikačný protokol.  Komunikácia prebieha s použitím TCP alebo UDP, formát správ v oboch prípadoch rovnaký.

Konfigurácia stanice v D2000 teda obsahuje IP adresu a číslo portu (pre linku TCP-IP/TCP aj TCP-IP/UDP). Pokiaľ sa použije linka TCP-IP/UDP, zadáva sa IP adresa a UDP port, na ktorom bude D2000 KOM proces počúvať. Ak sa adresa zadá ako ALL  alebo *, KOM proces počúva na všetkých dostupných sieťových rozhraniach. Pokiaľ sa použije linka TCP-IP/TCP, IP adresa a port sú nepoužité (rovnako je to aj v protokole Omron FINS, ktorý tiež podporuje TCP aj UDP variant).

Formáty

V skutočnosti špecifikácia popisuje nie jeden formát pre komunikácii na sieti Ethernet, ale dokonca tri! Ich názvy sú 1E, 3E a 4E a jedná sa zrejme po postupne vyvíjané varianty protokolu.

Formát 1E je najjednoduchší variant. Správa obsahuje:

  • špecifikáciu operácie - Subheader - napr. dávkové čítanie po bitoch alebo po slovách, dávkový zápis po bitoch alebo po slovách)
  • identifikáciu cieľovej stanice  - PC No.‍
  • časovač udávajúci dobu čakania na dokončenie čítania/zápisu - ACPU monitoring timer‍
  • sekciu s dátami (Request/response data - napr. typ a adresa zapisovaných dát a zapisované hodnoty).

Odpoveď obsahuje okrem polí hlavičky informáciu o úspechu (End code), voliteľne dáta (napr. ak bola požiadavka na čítanie), v prípade chyby ďalšie detaily o chybe (Error information).

Obrázok 2 - Formát 1E. Pole Header je TCP resp. UDP hlavička.

Formáty 3E a 4E majú komplikovanejšiu štruktúru. Líšia sa implementáciou poľa Subheader. Formát 3E ho má konštantné, formát 4E obsahuje aj sériové číslo, ktoré má odpoveď  zhodné s požiadavkou. Pole Access route udáva cestu k cieľovému PLC, pokiaľ sa nachádza za PLC, s ktorým priamo komunikujeme (čiže umožňuje niečo ako protokolové routovanie, ktoré má napr. aj protokol BACnet – cieľové PLC pritom môže byť napr. na sériovej zbernici). Nasleduje pole udávajúce dĺžku dát (Data length), rovnako ako v protokole 1E časovač udávajúci dobu čakania na dokončenie čítania/zápisu (ACPU monitoring timer) –a sekcia s dátami (napr. typ a adresa zapisovaných dát  – špecifikácia je iná ako vo formáte 1E - a zapisované hodnoty).

Odpoveď obsahuje okrem polí hlavičky informáciu o úspechu (End code), voliteľne dáta (napr. ak bola požiadavka na čítanie), v prípade chyby ďalšie detaily o chybe (Error information).

Špecifikácia dĺžky dát a sériové číslo umožňuje pri použití formátu 4E poslať viacero požiadaviek na čítanie/zápis a následne spracovať odpovede, spárovať ich a vyhodnotiť.

Obrázok 3 - Formáty 3E a 4E.

Ďalšou komplikáciou je existencia dvoch kódovaní. Binárne kódovanie používa „little endian“ formát dát. ASCII kódovanie posiela čísla od najvyššej číslice a jeho správy sú 2-krát väčšie ako binárne. Špecifikácia čítaných a zapisovaných dát je rozdielna pre ASCII a binárne kódovanie. Výhodou ASCII kódovania je ľahšia čitateľnosť voľným okom pri prezeraní komunikačných logov. Aby sme ju zachovali, vznikol parameter protokolu „Text Debug“. Ak je nastavený na hodnotu True a je použité ASCII kódovanie, výpis komunikácie je v ASCII tvare, v opačnom prípade v hexa.

Služby

Protokol Mitsubishi MELSEC špecifikuje pomerne rozsiahlu množinu operácií. Z nich sme implementovali 3 základné:

  • batch read in word units – čítanie viacerých hodnôt zo spojitého intervalu adries, dáta sú čítané po wordoch (2-bajtových jednotkách)
  • batch write in word units – zápis viacerých hodnôt zo spojitého intervalu adries, dáta sú zapisované po wordoch (2-bajtových jednotkách)
  • batch write in bit units – zápis viacerých hodnôt zo spojitého intervalu adries, dáta sú zapisované po bitoch

Neimplementovali sme čítanie po bitoch – aj bitové premenné čítame po wordoch. V prípade nespojitých adries (napr. bitové premenné s adresami 0,1, 5, 20, 25) sa načíta celé rozmedzie adries (0-31, tj. 32 bitových premenných, t.j. 4 bajty). Na obmedzenie rozmedzia vznikli dva protokolové parametre. „Max Points“ definuje maximálny počet objektov v jednej požiadavke, „Max Data Bytes“ obmedzuje veľkosť dát v odpovedi. Napr. odpoveď na čítanie 100 wordových premenných má 100 dátových bajtov  pre binárne kódovanie, 200 pre ASCII kódovanie. Odpoveď na čítanie 100 bitových premenných má 13 dátových bajtov  pre binárne kódovanie, 26 pre ASCII kódovanie.

Formáty 3E a 4E umožňujú aj “random” čítanie, ale zatiaľ sme túto optimalizáciu neimplementovali.

Obrázok 4 - Zoznam príkazov pre formát 1E . Pre formáty 3E a 4E je zoznam ešte rozsiahlejší.

Objekty

Objekty (zodpovedajúce meraným bodom) sa v terminológii Mitsubishi MELSEC nazývajú zariadenia (devices). Existujú rôzne typy zariadení, môžu byť bitové alebo wordové (v prípade MELSEC iQ-R aj double-wordové).

Zoznam podporených typov zariadení je zobrazený na nasledovnom obrázku. Okrem názvu je zobrazený aj kód zariadenia (zadávaný v adrese meraného bodu) a typ dát.

Obrázok 5 - Typy zariadení podporené v D2000.

Typ hodnoty

Hodnoty jedného alebo viacerých zariadení môžu byť interpretované rôznym spôsobom. Podporili sme:

  • prácu s jednotlivými bitovými aj wordovými zariadeniami
  • prácu s konkrétnym bitom wordového zariadenia
  • interpretáciu wordového zariadenia (alebo bloku 16 bitových zariadení so spojitými adresami) ako celého čísla bez znamienka a so znamienkom
  • interpretáciu dvoch wordových zariadení (alebo bloku 32 bitových zariadení so spojitými adresami) ako celého čísla bez znamienka, so znamienkom, aj ako reálneho 32-bitového čísla.
Obrázok 6 - Typ hodnoty (value type) v adrese meraného bodu definuje interpretáciu dát.

A nakoniec, je podporené aj čítanie do stĺpca štruktúrovanej premennej. Pomocou jedného meraného bodu je tak možné načítať viacero hodnôt a uložiť ich do stĺpca štruktúrovanej premennej.

Adresa meraného bodu sa tak skladá z kódu zariadenia (device code), čísla zariadenia (device number), voliteľne je možné špecifikovať konkrétny bit (pre zariadenia s wordovými dátami), typ hodnoty (value type) a počet čítaných elementov (items). Ak adresa začína reťazcom %IGNORE, tak meraný bod bude ignorovaný.

Obrázok 7 - Formát adresy meraného bodu.

A aby si užívateľ D2000 pospájal všetky uvedené informácie o adresácii meraného bodu, tak dokumentácia protokolu Mitsubishi MELSEC obsahuje aj príklady adresácie.

Obrázok 8 - Príklady adresácie meraných bodov.

Záver

Podpora protokolu Mitsubishi MELSEC opäť rozširuje komunikačné schopnosti applikačného servera reálneho času Ipesoft D2000. Verím, že poteší ľudí z praxe a pritiahne ďalších zákazníkov, ktorí s PLC firmy Mitsubishi pracujú a potrebujú s nimi komunikovať z úrovne SCADA a MES systémov.

12. marec 2021, Ing. Peter Humaj, www.ipesoft.com

Iné blogy

Všetky

Right time/Right place solutions

Menu
Dôležité odkazy
Kontaktné údaje
© Copyright IPESOFT 2023