Allen-Bradley PLC-communicatieprotocollen uitgelegd: EtherNet/IP, DeviceNet, ControlNet en meer

Als u een op Allen-Bradley gebaseerd besturingssysteem beheert of onderhoudt, bent u waarschijnlijk deze situatie tegengekomen. Een PLC-module wordt niet meer leverbaar, of de prijs bij de oorspronkelijke leverancier verdrievoudigt plotseling en je gaat in plaats daarvan kijken naar een vervangende of compatibele module. De specificaties zien er goed uit, de fysieke connector komt overeen en de prijs is redelijk. Maar voordat u de bestelling plaatst, wordt één vraag vaak overgeslagen: spreekt deze module eigenlijk hetzelfde protocol, op dezelfde manier, als degene die hij vervangt?

Dit is het deel van de Allen-Bradley-communicatie dat zelden duidelijk wordt uitgelegd. In de meeste handleidingen wordt uitgelegd wat EtherNet/IP, DeviceNet of ControlNet in algemene termen zijn, maar slechts weinigen verbinden die kennis met de praktische beslissingen waarmee ingenieurs worden geconfronteerd bij het aanschaffen van onderdelen. In dit artikel bespreken we de belangrijkste Allen-Bradley PLC-communicatieprotocollen, waarbij elk protocol in een echt systeem past, en, net zo belangrijk, wat u moet controleren voordat u een vervangende of compatibele module koopt, zodat u na de installatie geen communicatieprobleem krijgt.

Wat is een PLC-communicatieprotocol en waarom het ertoe doet

Definitie in gewone taal

Een communicatieprotocol is simpelweg de afgesproken set regels waarmee twee apparaten op de juiste manier gegevens kunnen uitwisselen. Zie het zoals je zou denken over een gedeelde taal: als een PLC en een HMI hetzelfde protocol gebruiken, begrijpen ze elkaars berichten. Als dat niet het geval is, kan de verbinding er fysiek goed uitzien, terwijl er feitelijk geen bruikbare gegevens tussen worden uitgewisseld.

Waarom protocolkeuze de uptime en onderhoudskosten van het systeem beïnvloedt

Niet-overeenstemmende protocollen zijn een van de meest voorkomende en beter te voorkomen oorzaken van downtime. Een besturingssysteem dat is gebouwd rond het verkeerde protocol voor zijn omvang zal later moeite hebben om uit te breiden, en het mixen van oude en nieuwe apparatuur zonder de protocolcompatibiliteit te controleren leidt vaak tot periodieke fouten die moeilijk te diagnosticeren zijn omdat de bedrading en de stroom er correct uitzien. Ook de onderhoudskosten worden beïnvloed. Het oplossen van een probleem op protocol-niveau duurt doorgaans langer dan het oplossen van een bedradingsfout, omdat de symptomen zelden rechtstreeks naar de oorzaak wijzen. Begrijpen van welk protocol uw systeem afhankelijk is en wat dat protocol vereist van elk apparaat dat erop is aangesloten, is de eerste stap om deze problemen te voorkomen.

Laten we, nu we dat fundament hebben gelegd, eens kijken naar de protocollen die u waarschijnlijk tegenkomt in een Allen-Bradley-omgeving, te beginnen met het protocol dat tegenwoordig nieuwe installaties domineert.

Moderne Ethernet-gebaseerde protocollen

EtherNet/IP

EtherNet/IP (Ethernet Industrial Protocol) is het communicatieprotocol waarop de meeste nieuwe Allen-Bradley-systemen zijn gebouwd. Het werkt via standaard Ethernet-hardware en maakt gebruik van het Common Industrial Protocol (CIP) op de applicatielaag, hetzelfde protocol dat wordt gedeeld met DeviceNet en ControlNet. Die gedeelde basis is één van de redenen waarom EtherNet/IP zo soepel integreert in een Rockwell Automation-architectuur.

Een paar dingen maken EtherNet/IP de standaardkeuze voor nieuwe builds. Het maakt gebruik van standaard Ethernet-switches en -bekabeling, zodat de hardwarekosten laag blijven en IT-afdelingen het netwerk kunnen ondersteunen met tools die ze al kennen. Het is goed schaalbaar, omdat een geschakeld Ethernet-netwerk de bandbreedte niet over alle apparaten deelt zoals oudere bus-gebaseerde protocollen dat doen. En omdat EtherNet/IP zo wijdverspreid wordt toegepast, ondersteunen sensoren, schijven en gateways van derden het vrijwel altijd kant-en-klaar, waardoor de integratie van meerdere-leveranciers veel minder pijnlijk is dan vroeger.

Als uw systeem gegevens moet delen met een MES, een historicus of een clouddashboard, is EtherNet/IP bijna een standaardkeuze, omdat het zich op hetzelfde fysieke netwerk kan bevinden als uw IT-infrastructuur zonder een aparte gatewaylaag.

Welke AB-modellen ondersteunen dit:De meeste huidige-generatie Allen-Bradley-controllers, waaronder ControlLogix- en CompactLogix-platforms, bevatten standaard EtherNet/IP, ingebouwde-communicatiepoort. Voor sommige oudere of meer gespecialiseerde controllermodellen is mogelijk een aanvullende communicatiemodule nodig om een ​​EtherNet/IP-netwerk te bereiken in plaats van dit systeemeigen te ondersteunen. Het is dus de moeite waard om het specifieke model en de firmwarerevisie te bevestigen in plaats van uit te gaan van ondersteuning voor een hele productfamilie. Als u een controller of een communicatiemodule aanschaft en wilt bevestigen wat een specifiek onderdeelnummer ondersteunt, kunt u onzeAllen-Bradley PLCEnAllen-Bradley PLC-modulepagina's tonen de huidige voorraad met protocoldetails, of u kunt ons het modelnummer rechtstreeks sturen.

EtherNet/IP-naslaggids

Moderne op Ethernet-gebaseerde communicatie omvat de meeste nieuwe installaties, maar een groot deel van de geïnstalleerde Allen-Bradley-systemen is nog steeds afhankelijk van protocollen die dateren van vóór EtherNet/IP. Die zijn nog steeds erg in gebruik, dus het is de moeite waard om ze ook te begrijpen.

Legacy Bus-gebaseerde protocollen

ApparaatNet

DeviceNet verbindt eenvoudige veldapparaten zoals sensoren, drukknoppen en motorstarters via een gedeelde bus met een PLC, in plaats van elk apparaat afzonderlijk te bedraden. Het draait op Controller Area Network (CAN)-technologie en werkt doorgaans met snelheden tot 500 kbps, afhankelijk van de kabellengte. Een praktisch voordeel is dat DeviceNet zowel stroom als signaal via dezelfde kabel transporteert, waardoor de installatiekosten voor grote aantallen eenvoudige apparaten worden verlaagd. Je zult dit het vaakst tegenkomen in kostengevoelige, afzonderlijke toepassingen, zoals verpakkingslijnen of apparatuur voor voedingsmiddelen en dranken, waar een groot aantal sensoren belangrijker is dan de ruwe doorvoer.

ControleNet

ControlNet is gebouwd voor een andere prioriteit: deterministische, tijd-kritische controle in plaats van goedkope- veldbedrading. Het maakt gebruik van een time{3}}slicing-schema om bandbreedte voor gepland verkeer te garanderen, waardoor het zeer geschikt is voor toepassingen zoals bewegingscontrole over meerdere- assen, waarbij de timing van berichten voorspelbaar moet zijn in plaats van alleen maar snel. Waar voor DeviceNet wordt gekozen omdat je veel eenvoudige apparaten goedkoop moet aansluiten, wordt voor ControlNet gekozen omdat de applicatie geen variabele berichtlatentie kan tolereren. Als uw systeem gecoördineerde bewegings- of procescontrole met strakke timingvereisten omvat, blijft ControlNet een geschiktere oplossing dan DeviceNet, ook al delen beide dezelfde CIP-basis als EtherNet/IP.

Waarom deze protocollen nog steeds in gebruik zijn en waar u op moet letten

Tegenwoordig starten nieuwe installaties zelden met DeviceNet of ControlNet, maar een groot deel van de daarop gebouwde apparatuur functioneert nog steeds betrouwbaar in het veld. Het vervangen van een volledig netwerk om over te stappen op EtherNet/IP is duur en in veel gevallen wegen het risico en de kosten van ongeplande downtime tijdens een migratie zwaarder dan het voordeel van het upgraden van apparatuur die al werkt. De belangrijkste onderhoudsuitdaging bij deze bestaande netwerken is niet het protocol zelf, maar het vinden van compatibele veldapparatuur en communicatiemodules, omdat originele onderdelen moeilijker te vinden zijn. Wanneer een DeviceNet- of ControlNet-component vervangen moet worden, is het de moeite waard om de protocolversie en de knooppuntcapaciteit zorgvuldig te controleren, omdat oudere netwerken minder vergevingsgezind zijn ten aanzien van kleine mismatches dan een modern geschakeld Ethernet-netwerk.

Naast deze bus-gebaseerde protocollen vertrouwen Allen-Bradley-systemen ook op een oudere generatie seriële en eigen netwerkstandaarden die de moeite waard zijn om te begrijpen, vooral als je apparatuur onderhoudt die ouder is dan DeviceNet.

Seriële en datasnelwegprotocollen

DH+ / DH485

Data Highway Plus (DH+) en DH485 zijn Allen-Bradley's vroege eigen netwerkprotocollen, oorspronkelijk ontwikkeld om PLC's en programmeerterminals te koppelen voordat op Ethernet-gebaseerde opties bestonden. DH+ werkt met snelheden tot ongeveer 230 kbps en ondersteunt maximaal 64 knooppunten, waarbij gebruik wordt gemaakt van een token-passing-schema om de netwerktoegang te controleren. DH485 is een verwant maar afzonderlijk protocol, ontworpen voor kleinere-werkvloertoepassingen met minder ondersteunde knooppunten en een lagere doorvoer. Geen van beide wordt tegenwoordig gebruikt in het nieuwe systeemontwerp, maar beide worden nog steeds aangetroffen met programmeerterminals, oudere operatorinterfaces en oudere PLC-5- of SLC-500-controllers op productievloeren die nog niet volledig zijn geüpgraded.

RS-232 / RS-485

RS-232 en RS-485 zijn op zichzelf geen protocollen. Het zijn fysieke laagstandaarden die bepalen hoe signalen over een kabel reizen, en protocollen zoals Modbus RTU of DF1 draaien er doorgaans bovenop. RS-232 ondersteunt een eenvoudige point-to-point-verbinding over korte afstanden, die vaak wordt gebruikt voor het programmeren van kabels en standaard HMI-verbindingen. RS-485 ondersteunt meerdere apparaten op een gedeelde bus over veel langere afstanden. Daarom blijft het gebruikelijk om eenvoudige HMI's of instrumenten van derden aan te sluiten op oudere AB-apparatuur. Het herkennen van dit onderscheid is van belang omdat een apparaat dat wordt beschreven als "RS-485-compatibel" u vertelt over de bedrading, en niet noodzakelijkerwijs of het daadwerkelijk kan communiceren met behulp van het specifieke protocol dat uw PLC verwacht.

Wanneer de originele hardware niet meer beschikbaar is

Apparatuur die op DH+, DH485 of standaard seriële verbindingen draait, is vaak tientallen jaren oud, en het is niet altijd mogelijk om een ​​exact origineel vervangend onderdeel te vinden. Wanneer dat gebeurt, zijn er over het algemeen een paar realistische paden voorwaarts: het lokaliseren van een gebruikte of gereviseerde originele module, het toevoegen van een protocolconversiegateway om het oude netwerk naar een nieuwer netwerk te overbruggen, of het aanschaffen van een compatibele vervangende module die is gebouwd om hetzelfde oude protocol te ondersteunen. Elke optie heeft nadelen op het gebied van kosten, doorlooptijd en ondersteuning op lange termijn, en de keuze tussen deze opties komt meestal neer op hoe de rest van het systeem zich naar verwachting in de komende paar jaar zal ontwikkelen.

Die beslissing leidt uiteraard tot een bredere vraag die op al deze protocollen van toepassing is: hoe beslis je welke daadwerkelijk geschikt is voor een bepaald systeem, in plaats van standaard te blijven bij wat de vorige keer werd gebruikt?

Het juiste protocol voor uw systeem kiezen

Snelheid, aantal knooppunten en omgeving

Drie factoren zijn doorgaans bepalend voor de meeste protocolbeslissingen. Snelheidsvereisten komen op de eerste plaats: als uw toepassing een timing van minder dan- milliseconden nodig heeft, zoals gecoördineerde bewegingsbesturing, is EtherNet/IP met tijd- een gevoelig netwerk of ControlNet geschikt, terwijl eenvoudige bewakingstaken comfortabel kunnen worden uitgevoerd op veel langzamere seriële verbindingen. Vervolgens is het aantal knooppunten van belang: de geschakelde architectuur van EtherNet/IP schaalt mee naarmate het aantal apparaten groeit, terwijl op bus-gebaseerde protocollen zoals DeviceNet de bandbreedte delen over elk aangesloten knooppunt, wat een beperkende factor wordt in grotere systemen. Omgeving is de derde factor: lange kabels of gebieden met elektrische ruis geven de voorkeur aan protocollen met een sterke ruisimmuniteit of glasvezelondersteuning, zoals ControlNet, boven standaard koper-Ethernet of standaard seriële verbindingen.

Oude en nieuwe protocollen mixen

Er zijn maar heel weinig echte systemen die end-to-end op één enkel protocol draaien. Het is gebruikelijk om een ​​EtherNet/IP-backbone te hebben die controllers verbindt met het IT-netwerk, waarbij DeviceNet of seriële verbindingen nog steeds oudere veldapparatuur op machineniveau verwerken. Meestal zijn het protocolconversiegateways die deze netwerken met elkaar verbinden, maar de gateway zelf heeft hetzelfde onderzoek nodig als elk ander apparaat: bevestig welke protocolversie en firmwarebereik het aan elke kant ondersteunt, aangezien een gateway die beide protocollen lijkt te verwerken er nog steeds niet in kan slagen bepaalde berichttypen correct te interpreteren als de firmware verouderd is. Het testen van een gateway of transitiepunt onder reële bedrijfsomstandigheden, in plaats van aan te nemen dat het zal werken omdat de datasheet beide protocollen vermeldt, is de extra tijd vóór een volledige uitrol waard.

Het kiezen van het juiste protocol lost de ontwerpvraag voor een nieuw systeem op, maar voor de meeste onderhouds- en upgradewerkzaamheden komt de moeilijkere vraag later: als je daadwerkelijk een specifieke module moet vervangen of toevoegen, hoe zorg je er dan voor dat deze correct communiceert met alles dat al is geïnstalleerd?

Compatibiliteit van communicatieprotocollen bij het aanschaffen van vervangende modules

Waarom protocolspecificaties over het hoofd worden gezien

Wanneer ingenieurs een vervangende of compatibele module beoordelen, gaat de aandacht uiteraard naar de dingen die gemakkelijk te vergelijken zijn: komt het onderdeelnummer overeen, past de connector en is de prijs redelijk? Protocolcompatibiliteit wordt vaak aangenomen in plaats van gecontroleerd, vooral wanneer een module er fysiek identiek uitziet aan het origineel. In de praktijk kunnen twee modules dezelfde connector en vormfactor delen terwijl ze verschillende protocolversies of firmwarereeksen ondersteunen, en dat verschil zal pas zichtbaar worden als het apparaat is geïnstalleerd en niet betrouwbaar communiceert of met tussenpozen communiceert op een manier die veel moeilijker te diagnosticeren is dan een volledige storing.

Wat u moet controleren voordat u een vervangende of compatibele module koopt

Voordat u bestelt, is het de moeite waard om het volgende te controleren op uw bestaande systeem:

• Protocolversie en firmwarebereik.Controleer of de vervangende module dezelfde protocolversie en firmwarerevisiebereik ondersteunt als het apparaat dat hij vervangt, en niet alleen dezelfde protocolnaam.
• Communicatiesnelheid.Controleer of de ondersteunde baudsnelheid of datasnelheid overeenkomt met de snelheid waarvoor de rest van uw netwerk is geconfigureerd, aangezien een discrepantie hier een verbinding kan verhinderen, zelfs als het protocol zelf correct is.
• Knooppunt- of adrescapaciteit.Controleer voor op bus-gebaseerde netwerken zoals DeviceNet of ControlNet of de vervanging voldoende knooppuntadressen ondersteunt voor uw huidige netwerkgrootte, vooral als het systeem is gegroeid sinds het voor het eerst werd geïnstalleerd.
• Fysiek interfacetype.Controleer of de connector en de bekabelingsstandaard exact overeenkomen, aangezien sommige modules die hetzelfde protocol ondersteunen nog steeds verschillende fysieke connectoren gebruiken, afhankelijk van de modelgeneratie.
• Behoefte aan een conversiemodule.Als de vervanging het protocol dat uw systeem gebruikt niet standaard ondersteunt, bepaal dan of er een extra gateway of conversiemodule nodig is en houd daar rekening mee bij zowel de kosten als de installatietijd.

Als u niet zeker weet hoe een specifiek vervangend onderdeel op deze punten presteert, kan ons technische team u helpen de protocolspecificaties te bevestigen aan uw bestaande installatie voordat u bestelt via onzeaanvraagpagina.

Wat gebeurt er als de compatibiliteit niet wordt gecontroleerd

Een paar patronen komen herhaaldelijk naar voren wanneer protocolcompatibiliteit wordt gemist. Een vervangende module met een lagere firmwarerevisie dan het originele apparaat vereist, kan intermitterende communicatie-uitval veroorzaken in plaats van een schone fout, waardoor de fout moeilijker te traceren is omdat de verbinding een deel van de tijd lijkt te werken. Een module die het juiste protocol ondersteunt, maar met een andere standaardcommunicatiesnelheid, kan mogelijk helemaal geen verbinding tot stand brengen totdat de snelheidsinstelling handmatig wordt gecorrigeerd, iets dat gemakkelijk over het hoofd wordt gezien als de vorige module automatisch-onderhandelde. En op busnetwerken met een vaste knooppuntcapaciteit kan het toevoegen van een vervangend apparaat zonder de resterende adresruimte te controleren conflicten met bestaande apparaten veroorzaken in plaats van simpelweg geen verbinding te maken. Geen van deze situaties is moeilijk te voorkomen, maar het kost veel meer tijd-om na de installatie een diagnose te stellen dan om deze vooraf te controleren.

Als u momenteel een vervangende of compatibele module voor een specifiek Allen-Bradley-model evalueert, kan ons team u helpen de protocolcompatibiliteit met uw bestaande systeem te bevestigen voordat u een bestelling plaatst. U kunt ons bereiken via onzecontactpaginamet de modeldetails.

Algemene tips voor het oplossen van communicatieproblemen

Veelvoorkomende fouttypen

De meeste Allen-Bradley-communicatieproblemen vallen in een paar herkenbare categorieën. Time-outs treden op wanneer een apparaat niet binnen het verwachte tijdsbestek reageert, wat vaak wijst op een defect apparaat, een kapotte kabel of een overbelast netwerk. Checksum- of CRC-fouten duiden op gegevensbeschadiging tijdens de verzending, meestal veroorzaakt door elektrische ruis of een beschadigde kabel in plaats van een configuratieprobleem. Adresconflicten doen zich voor wanneer aan twee apparaten in hetzelfde netwerk hetzelfde knooppuntadres wordt toegewezen, wat ook kan gebeuren nadat een vervangende module met een protocol-niet goed kan worden geregistreerd. Vermeldenswaard: een firmware- of protocolversie die niet overeenkomt op een vervangend apparaat kan symptomen veroorzaken die identiek lijken aan een time-out of een periodieke fout, wat nog een reden is om compatibiliteitsproblemen vroegtijdig uit te sluiten in plaats van laatst.

Basisstappen voor probleemoplossing

Voordat u een diepere diagnose stelt, moet u beginnen met de basisprincipes: controleer de fysieke verbindingen en de toestand van de kabel, bevestig dat de apparaatadressering geen conflict heeft veroorzaakt met een ander knooppunt en controleer of de instellingen voor de communicatiesnelheid over het hele netwerk overeenkomen. Standaardtools zoals RSLinx van Rockwell voor het doorzoeken en testen van communicatie, of een algemene netwerkanalysator voor op Ethernet-gebaseerd verkeer, kunnen helpen bepalen waar in het netwerk het probleem zit. Als deze basiscontroles het probleem niet oplossen, bestaat de volgende stap meestal uit het bevestigen van het apparaatmodel en de firmwaregegevens aan de hand van de documentatie van de fabrikant voor dat specifieke onderdeel.

Veelgestelde vragen

 

 

Wat is tegenwoordig het meest gebruikte communicatieprotocol in Allen-Bradley PLC's?

EtherNet/IP is het meest gebruikte protocol voor de huidige Allen-Bradley-installaties. Het combineert standaard Ethernet-hardware met op CIP-gebaseerde industriële communicatie, en de meeste huidige ControlLogix- en CompactLogix-platforms ondersteunen dit als een standaard ingebouwde--poort.

Kunnen EtherNet/IP en DeviceNet op hetzelfde systeem worden gebruikt?

Ja, dit is een veel voorkomende opstelling. Veel systemen gebruiken EtherNet/IP als de belangrijkste netwerkbackbone, terwijl DeviceNet eenvoudiger veldapparaten op machineniveau blijft verwerken, aangesloten via een controller die beide ondersteunt, of via een gateway.

Welk communicatieprotocol gebruikt ControlLogix standaard?

ControlLogix-controllers worden doorgaans geleverd met EtherNet/IP-ondersteuning ingebouwd in hun standaardcommunicatiepoort. Extra protocollen, zoals ControlNet of DeviceNet, worden meestal toegevoegd via afzonderlijke communicatiemodules in plaats van alleen via de basiscontroller.

Hoe weet ik welk protocol mijn bestaande Allen-Bradley PLC ondersteunt?

Het controleren van het modelnummer en het onderdeellabel op de controller of communicatiemodule is het meest betrouwbare startpunt, aangezien ondersteunde protocollen variëren per model en per welke communicatiemodules zijn geïnstalleerd. Als u niet zeker weet hoe u de specificatie moet lezen, kan ons team u helpen de protocolondersteuning voor een specifiek model te bevestigen.

Wat moet ik controleren voordat ik een vervangende of compatibele PLC-module koop?

Bevestig ten minste de protocolversie en het firmwarebereik, de communicatiesnelheid, de knooppunt- of adrescapaciteit en het fysieke connectortype voor uw bestaande apparaat. Een module die alleen op onderdeelnummer en connector overeenkomt, garandeert geen protocolcompatibiliteit.

Kunnen modules van derden-of compatibele modules betrouwbaar communiceren met originele Allen-Bradley-hardware?

In veel gevallen wel, op voorwaarde dat de protocolversie, het firmwarebereik en de communicatie-instellingen goed zijn afgestemd op het bestaande systeem. Betrouwbaarheid hangt af van het bevestigen van deze details vóór installatie, en niet van het veronderstellen van compatibiliteit op basis van alleen de fysieke pasvorm. Als u wilt dat een specifiek model wordt gecontroleerd aan de hand van uw configuratie, neem dan gerust contact op via onzeaanvraagpagina.

Laatste gedachten

Geen van de hier behandelde protocollen is op zichzelf bijzonder ingewikkeld. EtherNet/IP, DeviceNet, ControlNet en de oudere DH+- en seriële standaarden lossen elk een vrij specifiek probleem op, en als je eenmaal weet waarvoor ze zijn ontworpen, is de keuze tussen deze standaarden voor een nieuw systeem meestal eenvoudig. Waar het daadwerkelijk misgaat, is verderop in de lijn, wanneer een specifieke module moet worden vervangen en de protocoldetails worden aangenomen in plaats van gecontroleerd.

Als uw systeem naast Allen-Bradley-apparatuur ook Mitsubishi-hardware gebruikt, is onze eerdere analyse vanMitsubishi PLC-communicatieprotocollenomvat CC-Link, het MC-protocol en Modbus in hetzelfde praktische formaat.

Als u momenteel een vervangende of compatibele module aanschaft en wilt bevestigen dat deze correct communiceert met uw bestaande installatie, kan ons team de protocol- en firmwaregegevens van uw specifieke model controleren voordat u bestelt. U kunt ons de gegevens sturen via onzecontactpagina.

Gratis advies