Zurück zum Blog

Kapazitätsplanung für CompactLogix L35E EtherNet/IP

Planen Sie die EtherNet/IP-Kapazität des CompactLogix L35E anhand des konfigurierten CIP-Datenverkehrs, der Live-Diagnose, der Aktualisierungsraten und des Lebenszyklusrisikos – ohne sich auf falsc...

Der CompactLogix 1769-L35E ist nach wie vor in Maschinen verbreitet, die ihren ursprünglichen Netzwerkplan überlebt haben. Erweiterungsprobleme beginnen meist, wenn eine Geräteliste mit einer Verbindungsanzahl gleichgesetzt wird. Die EtherNet/IP-Kapazität hängt davon ab, welche Art von Datenverkehr jedes Gerät erzeugt, wie häufig Daten ausgetauscht werden und welche Controller-Ressourcen die Anwendung bereits nutzt. Eine sichere Prüfung beginnt daher mit dem laufenden Projekt und den Diagnosedaten, nicht mit einer allgemeinen Regel zur Anzahl der Geräte pro Port.

CompactLogix-L35E-Controller, der mit einem industriellen EtherNet/IP-Netzwerk verbunden ist

Bei der Verbindungsplanung müssen der konfigurierte Datenverkehr, die Aktualisierungsraten und das Lebenszyklusrisiko berücksichtigt werden, nicht die Anzahl der Ethernet-Stecker.

Mit dem dokumentierten Controller-Limit beginnen

Das Benutzerhandbuch für CompactLogix-Controller der Serie 1769 von Rockwell Automation dokumentiert, dass der L35E 100 CIP-Verbindungen unterstützt. Das ist eine Ressourcenbegrenzung und keine Erlaubnis, 100 Geräte anzuschließen. Ein einzelnes Gerät kann mehr als eine Verbindung benötigen, während manche Kommunikationsvorgänge eine optimierte Verbindung gemeinsam nutzen können. Firmware-Version, Modulkonfiguration, erzeugte und konsumierte Tags, zwischengespeicherte Nachrichten sowie HMI- oder übergeordnete Clients beeinflussen die endgültige Summe.

Der Controller ist außerdem ein abgekündigtes Produkt. Rockwell führt den 1769-L35E seit dem 20. Dezember 2020 als abgekündigt. Das macht ein funktionierendes System nicht unbrauchbar, verändert aber die technische Entscheidung: Ein Kapazitätsproblem sollte gemeinsam mit der Verfügbarkeit von Ersatzgeräten, der Firmware-Unterstützung, der Cybersicherheitslage und den Kosten eines ungeplanten Ausfalls bewertet werden.

Ein Verbindungsinventar aus dem Projekt erstellen

Öffnen Sie das Offline-Projekt, das dem laufenden Controller entspricht, und erfassen Sie jeden konfigurierten E/A-Adapter, Antrieb, erzeugten oder konsumierten Tag, Nachrichtenpfad, HMI-Datenserver, Historian, Gateway und Programmieranschluss. Notieren Sie, ob es sich bei jedem Austausch um zyklische E/A, erzeugte Daten, eine explizite Nachricht oder Client-Abfragen handelt. Weisen Sie nicht allein anhand des Herstellernamens einen festen Verbindungsbedarf zu. Maßgeblich ist die tatsächliche Konfiguration.

Prüfen Sie bei dezentralen E/A, ob das ausgewählte Kommunikationsformat direkte Modulverbindungen oder eine rackoptimierte Verbindung erzeugt. Ermitteln Sie bei MSG-Anweisungen, welche zwischengespeichert werden und ob mehrere Nachrichten gleichzeitig aktiv sein können. Zählen Sie bei übergeordneten Systemen die unabhängigen Kommunikationspfade und prüfen Sie deren Abfragestrategie. Eine Tabelle sollte jede angenommene Verbindung mit einem Projektobjekt oder einer getesteten Client-Konfiguration verknüpfen.

Verbindungsanzahl und Paketaufkommen voneinander trennen

Ein Controller kann unterhalb seiner Verbindungsgrenze bleiben und dennoch eine schlechte Netzwerkleistung liefern. Angeforderte Paketintervalle, Nachrichtenhäufigkeit, Paketgröße, Multicast-Verhalten, Switch-Konfiguration und Datenverkehrsspitzen mehrerer Clients beeinflussen die Paketlast. Sehr schnelle RPIs sollten durch den mechanischen Prozess und die erforderliche Regelreaktion begründet sein; jedes Gerät schneller zu machen, verbessert die Maschine nicht automatisch.

Ermitteln Sie eine Basislinie, während die Maschine normal produziert. Erfassen Sie die Verbindungsnutzung, Ethernet-Fehlerzähler, verpasste oder abgelaufene Nachrichten, den E/A-Status, die HMI-Reaktionsfähigkeit und das Scanverhalten des Controllers. Wiederholen Sie die Erfassung während des Starts, beim Herunterladen von Rezepten, bei Alarmschüben, beim Wartungszugriff und bei anderen plausiblen Spitzenlasten. Durchschnittswerte können das kurze Zeitintervall verbergen, das einen sporadischen Fehler verursacht.

Managed Industrial-Ethernet-Switch zur Überwachung des CompactLogix-Netzwerkverkehrs

Managed Switching, eine dokumentierte Topologie und wiederholbare Messungen machen sporadische Kapazitätsfehler diagnostizierbar.

Einen 1769-AENTR nicht als zweiten L35E-Port verwenden

Ein 1769-AENTR ist ein EtherNet/IP-Adapter für eine dezentrale Compact-I/O-Station, die über das Netzwerk gesteuert wird. Er ist keine zusätzliche Ethernet-Schnittstelle, die den Kommunikationspool des L35E-Controllers erweitert, und kann nicht als zweiter Controller-Port angeschlossen werden, um HMI- oder Nachrichtenverkehr von der integrierten Schnittstelle wegzuleiten. Eine Planung auf dieser Grundlage erzeugt eine Topologie, die die behauptete Funktion nicht erfüllen kann.

Wenn dezentrale E/A geeignet sind, kann ein Adapter die physische E/A an einem anderen Standort bündeln; die daraus resultierende E/A-Verbindung endet jedoch weiterhin am Controller. Wenn die Anwendung mehr Kommunikationskapazität, ein zweites unabhängiges Netzwerk, moderne Sicherheitsfunktionen oder eine längere Lebensdauer benötigt, kann die Lösung eher in der Migration zu einer neueren Controller-Familie als in einem weiteren Adapter liegen.

Vermeidbare Last reduzieren, ohne das Problem zu verschleiern

Die Optimierung sollte die Anforderungen des Prozesses erhalten. Entfernen Sie verlassene Pfade und nicht verwendete Clients. Bündeln Sie E/A-Verbindungen, sofern Plattform und Modultypen dies unterstützen. Zwischenspeichern sollten Sie nur MSG-Verbindungen, die eine schnelle wiederholte Ausführung benötigen, und nichtkritische Nachrichten so staffeln, dass sie nicht alle gleichzeitig geöffnet werden. Erhöhen Sie ein RPI oder Abfrageintervall erst, nachdem bestätigt wurde, dass Erkennungszeit, Verriegelungen, Alarmierung und Regelqualität weiterhin akzeptabel sind.

Verwenden Sie Managed Industrial-Ethernet-Switches und dokumentieren Sie VLAN-, Multicast- und IGMP-Einstellungen, sofern zutreffend. Ein Switch kann unnötige Überflutung begrenzen und die Beobachtbarkeit verbessern, aber keine Controller-Verbindungsressourcen schaffen. Ebenso verändert das Hinzufügen eines unmanaged Switches die Portanzahl, nicht die Controller-Kapazität.

Einen vermuteten Kapazitätsfehler systematisch diagnostizieren

Bestätigen Sie zunächst das laufende Projekt, die Katalognummer des Controllers, die Firmware-Version und die Netzwerktopologie. Vergleichen Sie anschließend die konfigurierten Verbindungen mit den Live-Diagnosedaten. Achten Sie auf E/A-Module, die zwischen Betriebs- und Fehlerzustand wechseln, MSG-Anweisungen, die unter Spitzenlast ablaufen, oder HMI-Werte, die veralten, während die Controller-Logik weiter ausgeführt wird.

Ändern Sie jeweils nur eine Variable. Trennen Sie einen genehmigten, nicht wesentlichen Client, halten Sie einen nichtkritischen Abfragedienst an oder staffeln Sie Nachrichten vorübergehend während eines kontrollierten Wartungsfensters. Wenn sich das Symptom ändert, messen Sie die Last vor und nach der Änderung, statt aufgrund einer einzigen störungsfreien Stunde Erfolg zu verkünden. Verlängern Sie niemals Timeouts und unterdrücken Sie keine Kommunikationsalarme, nur um eine Überlastung zu verbergen.

Erweiterungen mit Ausfalltests in Betrieb nehmen

Definieren Sie vor dem Hinzufügen eines Geräts den Verbindungstyp, die Aktualisierungsanforderung, den Verantwortlichen und das Verhalten im Fehlerfall. Testen Sie den normalen Betrieb sowie die ungünstigste plausible gleichzeitige Belastung. Unterbrechen Sie das neue Gerät, stellen Sie es wieder her, schalten Sie seine Netzwerkversorgung aus und wieder ein und bestätigen Sie, dass Controller, HMI und Alarme fehlerhafte oder veraltete Daten von einem gültigen Prozesszustand unterscheiden. Prüfen Sie, dass die Wiederherstellung nicht unerwartet Anlagen neu startet.

Bewahren Sie das Inventar, Diagnoseaufnahmen, die Switch-Konfiguration und die Abnahmeergebnisse zusammen mit der Steuerungssicherung auf. Aktuelle Hardwareoptionen finden Sie unter SPS- und PAC-Systeme; Managed Switches und Netzwerkkomponenten finden Sie in der Kollektion für Kommunikation und Netzwerktechnik. Die redaktionelle Einschätzung ist einfach: Eine Erweiterung des L35E ist nur dann vertretbar, wenn Spitzenlast, Fehlerverhalten und Lebenszyklusplanung vollständig dokumentiert sind.

Einen Kommentar hinterlassen

Bitte beachten Sie, dass Kommentare genehmigt werden müssen, bevor sie veröffentlicht werden.