Ethernet-tiedonsiirtomoottoriohjaimet: protokollat, integrointi ja valinta

Miksi Ethernet on korvannut vanhan kenttäväylän moottorin ohjauksessa

Kahden vuosikymmenen ajan RS-485-pohjaiset protokollat, kuten Modbus RTU ja CANopen, hallitsivat moottorin ohjausviestintää. Ne olivat luotettavia, deterministisiä ja halpoja toteuttaa. Ne olivat myös hitaita, topologialtaan rajallisia ja yhä enemmän yhteensopimattomia nykyaikaisten automatisoitujen tuotantolinjojen tietovaatimusten kanssa. Siirtyminen teolliseen Ethernetiin ei johtunut muotista – sitä ohjasi matematiikka.

Vanhat kenttäväyläjärjestelmät toimivat tyypillisesti nopeudella 1–12 Mbps ja verkkotopologiat, jotka rajoittuvat muutamaan kymmeneen solmuun ennen kuin suorituskyky heikkenee. Teolliset Ethernet-protokollat ​​toimivat nopeudella 100 Mbps - 1 Gbps, ne tukevat satoja solmuja yhdessä verkkosegmentissä ja tarjoavat usean akselin liikekoordinoinnin vaatimat alimillisekunnin sykliajat. HMS Networksin 2025 Industrial Network Market Shares -raportin mukaan 79 % uusista tehdasautomaatiosolmuista toimitetaan nyt teollisen Ethernet-protokollan kanssa perinteisen kenttäväylän sijaan – luku, joka olisi vaikuttanut epätodennäköiseltä vuosikymmen sitten.

Moottoriohjainten suunnittelijoille ja järjestelmäintegraattoreille tällä siirtymällä on suora käytännön seuraus: tietoliikennerajapinta ei ole enää toissijainen määrittely. Se määrittää, mitä ohjain voi tehdä koordinoidussa käyttöjärjestelmässä, miten se integroituu PLC:iden ja käyttöliittymän kanssa ja voiko se osallistua IIoT-dataputkiin ilman välittäjäyhdyskäytävää. Harjattomat DC-moottoriohjaimet teollisiin B2B-sovelluksiin Ethernet-liitännät ovat yhä useammin vakio-ominaisuutena valinnaisen lisäosan sijaan – heijastus siitä, kuinka syvälle protokollamuutos on tunkeutunut asemamarkkinoille.

Tärkeimmät teollisuus-Ethernet-protokollat moottoriohjaimille

Neljä protokollaa muodostaa suurimman osan Ethernet-liitetyistä moottorinohjausjärjestelmistä maailmanlaajuisesti. Jokaisella on erilainen arkkitehtoninen lähestymistapa samaan ydinhaasteeseen: ohjaustietojen lähettäminen luotettavasti ja ennustettavasti tavallisen Ethernet-laitteiston kautta.

EtherCAT (Ethernet for Control Automation Technology) Sen on kehittänyt Beckhoff Automation, ja siitä tuli IEC-standardi vuonna 2005. Sen ratkaiseva innovaatio on "lennossa käsittely": sen sijaan, että jokainen solmu vastaanottaisi erillisen paketin, yksi EtherCAT-kehys kiertää kaikkien orjasolmujen läpi peräkkäin, ja jokainen solmu lukee omat tietonsa ja lisää vastausdataa kehyksen kulkiessa. Tämä eliminoi pakettien vaihtamisen ylimääräiset kustannukset ja tuottaa alle 100 mikrosekunnin sykliajat alle 1 mikrosekunnin värinän kanssa – suorituskyky tekee kymmenien servoakseleiden synkronoinnin aidosti mahdolliseksi. The EtherCAT Technology Groupin virallinen tekninen dokumentaatio yksityiskohtaisesti kuinka protokolla saavuttaa IEC 61158 -yhteensopivuuden samalla kun se tukee linja-, puu-, tähti- ja rengastopologioita ilman hallittuja kytkimiä.

PROFINET , jota hallitsee PROFIBUS & PROFINET International (PI), on Profibusin suora seuraaja ja hallitsee Euroopan teollisuusmarkkinoita. Se toimii kahdessa tilassa: PROFINET RT (Real Time), jonka sykliajat ovat 1–10 millisekuntia tavallisille I/O-sovelluksille, ja PROFINET IRT (Isokronous Real Time), jonka sykliajat ovat jopa 250 mikrosekuntia tarkkaa liikkeenohjausta varten. Jälkiasennusprojektien tärkein etu on natiivi Profibus-välityspalvelintuki – olemassa olevat Profibus-laitteet voivat kommunikoida PROFINET-verkon yli yhdyskäytävävälityspalvelinten kautta, mikä mahdollistaa asteittaisen siirtymisen ilman asennettujen laitteiden vaihtamista.

EtherNet/IP ODVA:n ylläpitämä ja Common Industrial pöytäkirja (CIP) -protokollalle rakennettu standardi TCP/IP:n ja UDP/IP:n päälle kerrostettuna on Pohjois-Amerikan erillisvalmistuksen hallitseva protokolla. Se toimii tavanomaisessa IT-infrastruktuurissa ilman erikoistuneita kytkimiä, ja se tarjoaa suoraviivaisen integroinnin olemassa oleviin laitosverkkoihin ja tukee laajaa ekosysteemiä, joka sisältää useiden toimittajien PLC:itä, asemia ja I/O-moduuleja. Tyypilliset 2–10 millisekunnin sykliajat sopivat useimpiin erillisiin I/O- ja keskinopeisiin käyttösovelluksiin; tiukempi synkronointi on saatavilla CIPsync-laajennuksen kautta.

Modbus TCP on yksinkertaisin ja laajimmin tuettu vaihtoehto – klassisen Modbus RTU -rekisterimallin suora käännös TCP/IP:hen. Sillä ei ole alkuperäisiä reaaliaikaisia ​​takuita, mikä estää sen vaativista liikkeenohjausrooleista, mutta sen yleinen laitetuki ja nolla lisenssikustannukset tekevät siitä käytännöllisen valinnan valvonta-, konfigurointi- ja tiedonkeruukerroksiin, joissa determinismia ei vaadita.

Protokollavertailu: sykliaika, topologia ja yhteensopivuus

Näistä protokollista valitseminen edellyttää protokollan ominaisuuksien sovittamista sovelluksen vaatimuksiin – ei oletusarvoisesti tutuinta. Alla olevassa taulukossa on yhteenveto neljän päävaihtoehdon tärkeimmistä eroista:

Yksi kuvio erottuu tiedoista: EtherCATin sykliaikaetu ei ole marginaalinen – se on suuruusluokkaa nopeampi kuin EtherNet/IP vastaavissa olosuhteissa. Sovelluksissa, jotka vaativat tiukkaa synkronointia useiden moottorin akseleiden välillä, kuten CNC-työstökoneet, robottivarret tai koordinoidut kuljetinjärjestelmät, tämä rako muuttuu suoraan paikannustarkkuuteen. Yksiakselisissa taajuusmuuttajissa vakioprosessilaitteistoissa erolla on harvoin käytännössä merkitystä, ja EtherNet/IP:n tai PROFINET RT:n tuttuus ja infrastruktuurin yhteensopivuus ovat usein suurempia kuin raakanopeus.

Verkkotopologialla on myös käytännön painoarvoa. EtherCATin daisy-chain-arkkitehtuuri eliminoi hallittujen kytkimien tarpeen, mikä vähentää sekä kaappitilaa että kustannuksia järjestelmissä, joissa on monia hajautettuja asemasolmuja. PROFINET IRT:n vaatimus ajoituskykyisille kytkimille lisää infrastruktuurikustannuksia, mutta mahdollistaa kellon synkronoinnin maantieteellisesti hajautettujen solmujen välillä, jota EtherCATin lineaarinen topologia ei voi helposti ottaa huomioon.

Ethernet-tiedonsiirron integrointi BLDC-moottoriohjaimiin

Ethernet-liitännän lisääminen harjattomaan DC-moottorin ohjaimeen sisältää päätökset kolmella tasolla: fyysinen laitteisto, tietoliikennepinon laiteohjelmisto ja sovellustason käyttöprofiilin toteutus.

Laitteistotasolla EtherCAT-integraatio perustuu tyypillisesti omistettuihin orjaohjaimen ASIC:eihin – kuten ET1100- tai ESC10-perheisiin – jotka käsittelevät kehyskäsittelyä pää-MCU:sta riippumatta. Tämä purkaminen mahdollistaa alle 100 mikrosekunnin sykliajat: Ethernet-käsittely ei koskaan kilpaile CPU-jaksoista moottorin ohjaussilmukan kanssa. PROFINET- ja EtherNet/IP-toteutukset käyttävät useammin kaksiporttisia RAM-moduuleja tai soft-core-toteutuksia FPGA:issa, jotka tarjoavat enemmän joustavuutta, mutta vaativat huolellisempaa viiveen hallintaa laiteohjelmistoarkkitehtuurissa.

Laiteohjelmistotasolla taajuusmuuttajan profiili määrittää, kuinka moottorin ohjauskomennot yhdistetään verkkoprotokollaan. CiA 402 -taajuusmuuttajaprofiilista, joka alun perin kehitettiin CANopenille, on tullut hallitseva sovellustason standardi moottorikäyttöille EtherCAT- (CoE:n kautta, CANopen EtherCATin kautta), PROFINET- ja EtherNet/IP-toteutuksissa. Se määrittelee tilakoneet käytön päälle/pois käytöstä, toimintatiloista (asento, nopeus, vääntömomentti) ja viankäsittelystä toimittajasta riippumattomalla tavalla, mikä yksinkertaistaa PLC-ohjelmointia eri ohjainmerkkien välillä. Ohjaimet, jotka toteuttavat CiA 402:n oikein, voidaan tyypillisesti ottaa käyttöön millä tahansa IEC 61131-3 -yhteensopivalla logiikalla ilman mukautettuja toimintolohkoja.

Koordinoiduissa moniakselijärjestelmissä hajautettu kellon synkronointi on laiteohjelmiston kriittinen ominaisuus. EtherCATin hajautettu kellomekanismi synkronoi kaikki orjasolmut 1 mikrosekunnin etäisyydelle toisistaan ​​– tämä on edellytys elektroniselle vaihteistolle, nokkaprofiloinnille ja muille synkronoiduille liiketoiminnoille. Tämän oikea toteuttaminen vaatii tarkkaa huomiota etenemisviiveen kompensointiin ja kellon poikkeaman korjaukseen orja-laiteohjelmistossa. Tehokkaat T-sarjan moottoriohjaimet Sisällytä prosessointiarkkitehtuuri, joka tarvitaan ylläpitämään tiukkoja virtasilmukoiden päivitysnopeuksia verkon viestinnän käsittelyn ohella – tasapaino, jonka lähtötason ohjainsuunnittelu usein vaarantaa.

Puhtaiden taajuusmuuttajien ohjainten lisäksi järjestelmätason tietoliikenneintegraatio ulottuu valvontayksiköihin. Ajoneuvon ohjausyksiköt integroidulla verkkoyhteydellä yhdistää useiden moottoriohjaimien taajuusmuuttajatietoja, hallita järjestelmätason tilakoneita ja tarjota ylävirran Ethernet-yhdyskäytävän telematiikkaa ja etädiagnostiikkaa varten – toiminto, joka kasvaa tärkeämmäksi, kun kalustot ja teollisuuslaitteet siirtyvät kohti ennakoivia huoltomalleja. Kevyempiin sähkö- ja sähköpyöräsovelluksiin, sähköpyörän ja kevyiden sähköautojen moottoriohjaimet sisältävät yhä enemmän Bluetooth- ja CAN-liitäntöjä viestintäkerroksena, joka toimii siltana yksinkertaistettujen käyttöliittymien ja taustalla olevan moottorin käyttösilmukan välillä.

Oikean protokollan valitseminen moottorinohjaussovelluksellesi

Protokollan valinta riippuu harvoin yhdestä tekijästä. Kuusi kysymystä kattaa käytännön päätöstilan useimpien moottorinohjausjärjestelmien suunnittelussa:

1. Minkä sykliajan liikesovellus vaatii? Moniakselinen servokoordinointi vaatii tyypillisesti alle 1 millisekunnin sykliaikoja, mikä osoittaa EtherCAT:iin tai PROFINET IRT:hen. Prosessilaitteiden yksiakseliset muuttuvanopeuksiset käytöt toimivat yleensä mukavasti 5–10 millisekunnin päivitysnopeudella, kun EtherNet/IP tai PROFINET RT toimivat riittävästi.
2. Mikä PLC tai liikeohjain on jo järjestelmässä? Tämä on usein ratkaiseva tekijä. Siemens S7 -ohjaimet suosivat PROFINETiä; Rockwell/Allen-Bradley-järjestelmät on rakennettu EtherNetin/IP:n ympärille; Beckhoffin ja Omronin liikealustat ovat standardoituneet EtherCATiin. Protokollarajojen ylittäminen on mahdollista yhdyskäytävien kautta, mutta se lisää latenssia ja monimutkaisuutta, mikä heikentää alkuperäisen protokollan suorituskykyetuja.
3. Kuinka monta käyttöakselia verkko tukee? EtherCATin teoreettinen solmuraja 65 535 laitetta yhdessä verkossa ylittää reilusti minkä tahansa realistisen asennuksen, mutta sen ketjutettu topologia tarkoittaa, että solmujen lisääminen pidentää kehyksen läpikulkuaikaa hieman. Erittäin suurille asennuksille, joissa on satoja hajautettuja I/O-pisteitä, PROFINETin kytkinpohjainen tähtitopologia voi tarjota joustavamman fyysisen asettelun.
4. Vaaditaanko toiminnallista turvallisuutta verkkokerroksessa? Sekä EtherCAT (FSoE:n kautta, Functional Safety over EtherCAT) että PROFINET (PROFIsafen kautta) tukevat IEC 61508 -yhteensopivaa turvatietoliikennettä saman kaapeliinfrastruktuurin kautta kuin vakioprosessidata. EtherNet/IP tukee CIP-turvallisuutta vastaavissa sovelluksissa. Jos vaaditaan SIL 2- tai SIL 3 -turvallisia vääntömomentti- tai -nopeustoimintoja, varmista, että moottoriohjaimen turvalaiteohjelmisto on sertifioitu valitun protokollan turvalaajennukselle.
5. Mitkä ovat infrastruktuurin ja ylläpidon rajoitukset? EtherCATin hallittujen kytkimien poistaminen yksinkertaistaa kaapin suunnittelua ja vähentää vikakohtia. PROFINET ja EtherNet/IP hyödyntävät standardia IT-kytkininfrastruktuuria, jota tehtaiden huoltoryhmät voivat jo hallita ja varastoida varaosia varten – käytännön etu tiloissa, joissa ei ole erityistä automaatioverkkoasiantuntemusta.
6. Miten ohjain muodostaa pariliitoksen kohdemoottorin kanssa? Tiedonsiirtoprotokolla ja moottorin sovitus ovat toisistaan ​​riippuvaisia: suuren kaistanleveyden verkkoviestintään optimoidun ohjaimen on myös ylläpidettävä nykyisen silmukan päivitysnopeutta moottorin sähköisen aikavakion vaatimuksia. Tarkistetaan moottorin ohjain ja moottorin pariliitoksen opastus Ennen kuin sitoutuu ohjain-protokollayhdistelmään, varmistaa, että verkkoliitännän määritykset eivät ylitä taustalla olevan taajuusmuuttajan suorituskykyä, jota moottori voi todella käyttää.

Pääasia hankinta- ja suunnittelutiimille: oikea protokolla on se, joka vastaa PLC-ekosysteemiä, täyttää liikesyklin aikavaatimuksen ja sopii asennustopologiaan – tässä järjestyksessä. Raakaprotokollan nopeuden optimointi sovelluksessa, joka ei tarvitse sitä, lisää kustannuksia ilman hyötyä. Alimäärittely sovellukselle, joka tarvitsee determinististä synkronointia, aiheuttaa luotettavuusongelmia, joita mikään viritys ei korjaa täysin.