Ein sporadisches Durchgehen des Schlittens ist ein Maschinensicherheitsereignis

Eine Achse, die sich ohne den erwarteten Befehl bewegt, ist kein routinemäßiger Inbetriebnahmefehler. Es handelt sich um ein Ereignis unkontrollierter Bewegung, das Werkzeuge, Maschinenstrukturen, Werkstücke, Vorrichtungen und Personen beschädigen kann. Das Risiko lässt sich noch schwerer beherrschen, wenn sich der Schlitten viele Stunden lang normal verhält und sich dann plötzlich mit unerwarteter Geschwindigkeit oder in unerwarteter Richtung bewegt.

Die in diesem Fall betrachtete Maschine verwendet eine Siemens SIMATIC S7-200 CPU 226, ein SIMOVERT MASTERDRIVES-Gerät für die Schlittenachsen, einen MICROMASTER 440 für die Spindel und ein TP 170A-Bedienpanel. Befehls- und Statusdaten werden über ein serielles USS-Kommunikationsnetz übertragen.

Das gemeldete Problem tritt an einem oder an beiden Schlitten auf. Ein Vorfall kann während eines Arbeitstags ein- oder zweimal auftreten, gefolgt von zwei oder drei Tagen normalem Betrieb. Zu den bisherigen Maßnahmen gehörten die Trennung des Spindel-VFDs vom Hauptschaltschrank und die Verbesserung der Erdung. Diese Maßnahmen beseitigten den Fehler nicht.

Dieses Muster verleitet oft zu spekulativer Fehlersuche. Techniker tauschen möglicherweise einen Encoder aus, verlegen ein Kabel neu, ändern einen Antriebsparameter oder fügen einen weiteren Erdungsleiter hinzu. Eine Änderung kann das Symptom vorübergehend verändern und den Eindruck erwecken, das Problem sei gelöst. Das Ereignis tritt dann erneut auf, weil der tatsächliche Befehlsweg nie nachgewiesen wurde.

Eine zuverlässige Untersuchung muss den ersten Punkt ermitteln, an dem das erwartete Verhalten abnormal wird. Das Team muss wissen, was das HMI angefordert hat, was die SPS akzeptiert hat, was die SPS übertragen hat, was der Antrieb empfangen hat, was der Antrieb intern aktiviert hat und was der Motor tatsächlich getan hat.

Beginnen Sie mit der Bestätigung jedes installierten Geräts

Ältere Siemens-Systeme bleiben oft noch lange in Betrieb, nachdem das ursprüngliche Inbetriebnahmeteam ausgeschieden ist. Zeichnungen können handschriftliche Änderungen enthalten. Parametersicherungen können unvollständig sein. Ersatzmodule wurden möglicherweise eingebaut, ohne die Dokumentation zu aktualisieren. Daher muss die Hardwareidentifikation vor der Interpretation der Parameter erfolgen.

Notieren Sie die vollständige Bestellnummer von jedem Typenschild. Verlassen Sie sich nicht allein auf eine abgetippte Geräteliste. Die angegebene S7-200-CPU-Nummer enthält Zeichen, die möglicherweise falsch übernommen wurden. Bei der tatsächlichen Steuerung könnte es sich um die Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226 handeln, doch Netzteil und Ausgangsvariante müssen direkt am installierten Gerät bestätigt werden.

Ein einziges falsches Zeichen kann zum falschen Handbuch, Klemmenplan oder Ersatzteil führen. Der Buchstabe O wird häufig mit der Ziffer null verwechselt. Die Ziffer eins kann mit dem Buchstaben I verwechselt werden. Auch ein fehlendes Suffix kann eine wichtige Hardwareoption verbergen.

Für das SIMOVERT-MASTERDRIVES-Gerät gilt dieselbe Sorgfalt. MASTERDRIVES ist eine umfangreiche Produktfamilie und kein einheitliches Antriebsdesign. Steuerplatinen, Softwareversionen, Encoder-Optionen, Technologiekarten sowie Konfigurationen für Vector Control oder Motion Control können die verfügbaren Parameter und die interne Signalführung verändern.

Die Bestellnummer des MICROMASTER 440 sollte ebenfalls überprüft werden. Obwohl der MM440 die Spindel und nicht die Schlitten steuert, befindet er sich in derselben Schaltschrankumgebung und kann denselben USS-Kommunikationspfad nutzen. Seine Schaltvorgänge, Kabelführung, Adresskonfiguration und Kommunikationszeitsteuerung können das Gesamtsystem beeinflussen.

Dokumentieren Sie das TP-170A-Modell, die Version des HMI-Projekts, die Kommunikationseinstellungen und die angeschlossenen SPS-Adressen. Das Bediengerät kann Tastenereignisse, Rezeptfunktionen, Startwerte oder das Tag-Verhalten enthalten, die allein anhand des SPS-Programms nicht erkennbar sind.

Erstellen Sie vor jeder Parameteränderung vollständige Sicherungen des SPS-Programms, des HMI-Projekts, des MASTERDRIVES-Parametersatzes und des MM440-Parametersatzes. Fotografieren Sie Kabelschirme, Platinen-Schalter, Klemmenanschlüsse und optionale Module. Diese Ausgangsbasis ermöglicht den Vergleich und die Rückgängigmachung aller späteren Änderungen.

Definieren Sie, was die Bediener mit „Durchgehen“ meinen

Das Wort „Durchgehen“ kann mehrere unterschiedliche Ereignisse beschreiben. Eine Beschleunigung auf volle Geschwindigkeit unterscheidet sich von einem kurzen unbeabsichtigten Tippvorgang. Eine Bewegung während des Hochlaufs unterscheidet sich von einer Bewegung während einer automatischen Sequenz. Der Diagnoseweg richtet sich nach dem genauen Ereignis.

Befragen Sie jede Person, die den Fehler beobachtet hat. Fragen Sie nach Beobachtungen, nicht nach Schlussfolgerungen. „Der Encoder ist ausgefallen“ ist eine Schlussfolgerung. „Der Schlitten bewegte sich schnell in positiver Richtung, während das HMI eine Geschwindigkeit von null anzeigte“ ist eine Beobachtung.

Dokumentieren Sie die betroffene Achse, die Richtung, die geschätzte Geschwindigkeit, die Dauer, die Ausgangsposition, den Maschinenmodus, den Spindelzustand, den aktiven Programmschritt und die Methode, mit der die Bewegung gestoppt wurde. Stellen Sie fest, ob die Bewegung aus dem Stillstand begann oder während einer bereits laufenden Bewegung entstand.

Wenn der Schlitten auf die Höchstgeschwindigkeit beschleunigt, untersuchen Sie die Polarität der Rückführung, aktive Sollwertquellen, die Freigabesequenz und die Antriebsregelung. Bewegt er sich nur ein kurzes Stück, untersuchen Sie Tippbetriebsbits, doppelte Flankenauslöser, veraltete Befehle und Zustandsübergänge der Sequenz.

Wenn das Ereignis nur im Automatikbetrieb auftritt, wird die Sequenzlogik wichtiger. Wenn es auch im Handbetrieb auftritt, konzentrieren Sie sich auf die Befehlsarbitrierung, die beide Betriebsarten gemeinsam nutzen. Wenn sich die Achse während des Einschaltens, eines CPU-Übergangs, eines Antriebs-Resets oder der erneuten HMI-Verbindung bewegt, sollte die Startinitialisierung sofort überprüft werden.

Das Stoppverhalten liefert wertvolle Hinweise. Wenn das Entfernen des SPS-Antriebsfreigabesignals die Achse stoppt, reagiert die Leistungsstufe möglicherweise weiterhin auf den erwarteten Freigabepfad. Wenn die Bewegung fortgesetzt wird, bis die Hauptspannung abgeschaltet wird, untersuchen Sie die Antriebshardware, die externe Freigabeverdrahtung, das Schützverhalten und Befehlsquellen außerhalb der SPS.

Ermitteln Sie außerdem, ob der Antrieb eine Warnung oder einen Fehler erzeugt hat. Ein fehlerfreies Ereignis beweist nicht, dass der Antrieb ordnungsgemäß funktioniert hat, deutet aber darauf hin, dass der Antrieb den Befehl und die Rückmeldung möglicherweise als gültig bewertet hat.

Betrachten Sie die Maschine als vollständige Befehlskette

Der Bewegungsbefehl kann am Bedienpanel TP 170A beginnen. Eine Schaltfläche, eine numerische Eingabe, ein Rezept, ein Bildschirmereignis oder eine automatische Sequenz setzt einen SPS-Speicherwert. Die S7-200 validiert diese Anforderung und berechnet einen Geschwindigkeits- oder Bewegungssollwert. Eine USS-Kommunikationsroutine erstellt anschließend ein Telegramm mit Steuer- und Prozessdaten.

Das MASTERDRIVES-Gerät empfängt das Telegramm und führt Steuerwort und Sollwert durch seine interne Signalstruktur. Der endgültig aktive Befehl kann außerdem Festdrehzahlen, Analogeingänge, Klemmenbefehle, zusätzliche Sollwerte, Tippbetrieb-Eingänge oder interne Funktionsbausteine enthalten.

Der Rückmeldepfad ist ebenso wichtig. Für Motor oder Last können ein Inkrementalgeber, Resolver, Tachometer oder ein anderes Rückmeldegerät verwendet werden. Der Antrieb interpretiert dieses Signal als Geschwindigkeit oder Position. Einige Istwerte können anschließend an die SPS übertragen werden.

Mechanische Endschalter, Referenzsensoren, Überfahrschalter, Schütze, Bremsen und Antriebsbereit-Kontakte bilden zusätzliche Pfade. Jeder Pfad kann beeinflussen, ob die Bewegung beginnt, fortgesetzt oder gestoppt wird.

Jede Stufe sollte einen messbaren Wert liefern. Protokollieren Sie in der SPS die rohe HMI-Anforderung, den ausgewählten Betriebsmodus, den Sequenzstatus, den endgültig validierten Sollwert, die Richtung, den Freigabebefehl und das Kommunikationsergebnis. Überwachen Sie am Antrieb das empfangene Steuerwort, den empfangenen Sollwert, den aktiven internen Sollwert, die Istgeschwindigkeit, den Rückmeldestatus, den Strom, Warnungen und Fehler.

Eine am HMI angezeigte Null beweist nicht, dass die SPS eine Null übertragen hat. Eine Null in einem SPS-Register beweist nicht, dass eine andere Befehlsquelle inaktiv war. Ein korrektes USS-Telegramm beweist nicht, dass der Antrieb so konfiguriert war, dass er dieses Telegramm als einzige Sollwertquelle verwendet.

Die Untersuchung sollte die erste Stelle ermitteln, an der der erwartete Wert und der aufgezeichnete Wert voneinander abweichen. Dieser Punkt teilt das Problem in HMI-Logik, SPS-Anwendung, Kommunikation, Antriebskonfiguration, Rückmeldung, Leistungshardware oder Mechanik auf.

Die wichtigste diagnostische Unterscheidung

Die erste technische Frage ist einfach: Hat der Antrieb einen gültigen Bewegungsbefehl empfangen?

Vergleichen Sie während des Ereignisses vier Werte:

• Der endgültige SPS-Bewegungssollwert.
• Der vom Antrieb empfangene Sollwert.
• Der aktive interne Antriebssollwert.
• Die tatsächlich gemessene Bewegung des Motors oder Schlittens.

Wenn der endgültige SPS-Sollwert ungleich null wird und der Antrieb ihm folgt, arbeitet der Antrieb möglicherweise korrekt. Die unerwünschte Bewegung wurde übergeordnet erzeugt. Untersuchen Sie HMI-Ereignisse, Ablaufsteuerung, gespeicherte Werte, Moduswechsel und mehrere Schreibzugriffe auf den endgültigen Befehl.

Wenn der endgültige SPS-Sollwert null bleibt, der Antrieb jedoch einen Wert ungleich null empfängt, untersuchen Sie den Telegrammaufbau, die Speicherzuordnung, die Skalierung, die Pufferverarbeitung und die Ausführung des Kommunikationsbausteins. Der genaue unerwartete Wert kann den Mechanismus erkennen lassen. Ein wiederholt auftretender fester Wert deutet häufig auf gespeicherte oder veraltete Daten hin. Ein extrem positiver oder negativer Wert kann auf ein Problem mit vorzeichenbehafteten Zahlen oder der Byte-Reihenfolge hindeuten.

Wenn der Antrieb null empfängt, sein aktiver interner Sollwert jedoch ungleich null wird, prüfen Sie die Antriebskonfiguration. Ein fester Drehzahlsollwert, ein Analogwert, eine Tippfunktion, ein Klemmeingang, ein zusätzlicher Sollwert, ein Motorpotenziometer oder eine Technologieoption kann aktiv sein.

Wenn Sollwert in der SPS, empfangener Sollwert und interner Sollwert während der Beschleunigung des Motors weiterhin null sind, ist das Ereignis schwerwiegender. Untersuchen Sie das Verhalten der Rückmeldung, die Antriebsregelung, die Versorgung der Steuerplatine, die Antriebshardware, das Verhalten der Endstufe und die mechanische Kopplung.

Diese Methode mit vier Signalen verhindert den unkontrollierten Austausch von Komponenten. Sie ermöglicht außerdem eine technisch belastbare Schlussfolgerung. Der Fehler wird anhand der aufgezeichneten Belege und nicht anhand von Annahmen zugeordnet.

Rückmeldung ist ein vorrangiger Verdächtiger, aber kein automatisches Urteil

Ein sporadischer Geber- oder Tachometerfehler ist plausibel, insbesondere wenn sich das Ereignis durch Vibrationen, Temperatur, Kabelbewegung oder die Position des Schlittens verändert. Die Annahme, dass jeder Rückmeldeverlust automatisch zur Höchstdrehzahl führt, ist jedoch zu pauschal.

Ein korrekt konfigurierter Antrieb sollte normalerweise fehlende oder unplausible Rückmeldungen erkennen und entsprechend seinen Überwachungs- und Fehlerparametern reagieren. Die genaue Reaktion hängt von der Steuerungsversion, der Rückmeldeoption, der Konfiguration und der Anwendung ab.

Gefährliches Verhalten kann weiterhin auftreten, wenn das Rückmeldesignal vorhanden, aber falsch ist. Verpolung, eine falsche Phasenfolge, instabile Signalamplitude, beschädigte Kanäle, der falsche Gebertyp, eine falsche Skalierung, lose Kupplungen oder eine ungeeignete Reglereinstellung können dazu führen, dass der Antrieb in die falsche Richtung reagiert.

Ein intermittierender Kabelfehler führt selten zu einer vollständigen Unterbrechung. Ein Leiter kann sich nur lösen, wenn das Kabel gebogen wird. Ein Steckverbinder-Pin kann den Kontakt nur bei starker Vibration verlieren. Die Encoderversorgung kann beim Betätigen eines Schützes abfallen. Schirmstrom kann einen differentiellen Kanal verzerren, ohne das Signal vollständig zu entfernen.

Vergleichen Sie die vom Antrieb gemeldete Ist-Drehzahl mit einer unabhängigen Messung. Ein Handtachometer, ein vorübergehend angeschlossener geprüfter Sensor oder eine geeignete Oszilloskopmessung kann feststellen, ob der interne Istwert der tatsächlichen Bewegung entspricht.

Wenn der Antrieb bei drehender Welle eine Drehzahl von null meldet, ist der Rückkopplungspfad verdächtig. Meldet der Antrieb die korrekte Drehzahl, während der Sollwert fehlerhaft wird, funktioniert die Rückkopplung möglicherweise normal.

Führen Sie niemals eine Rückkopplungsprüfung durch, bei der Personen einer bewegten Schlitteneinheit ausgesetzt werden. Verwenden Sie Absperrungen, reduzierte Geschwindigkeit, kontrollierte Prüfbedingungen und eine unabhängige Stoppmöglichkeit.

Den gesamten Rückkopplungskreis prüfen

Ein Rückkopplungssystem umfasst mehr als den Encoder. Sensor, mechanische Kupplung, Kabel, Steckverbinder, Versorgung, Schirmung, Erdungsanordnung, Eingangsplatine und Antriebskonfiguration tragen alle zum Messwert bei.

Beginnen Sie mit der mechanischen Verbindung. Stellen Sie sicher, dass Encoderwelle, Riemen, Getriebe oder flexible Kupplung nicht rutschen können. Prüfen Sie Kupplungsnaben, Passfedern, Gewindestifte, Risse, Verunreinigungen und Fehlausrichtung. Ein mechanisch getrennter Encoder kann weiterhin ein Signal erzeugen, das die tatsächliche Lastbewegung nicht mehr repräsentiert.

Prüfen Sie jeden Steckverbinder bei guter Beleuchtung und mit Vergrößerung. Achten Sie auf zurückgedrückte Kontakte, schwache Crimpverbindungen, verbogene Pins, Korrosion, Ölverunreinigungen, beschädigte Zugentlastungen und Kabelzug. Stellen Sie sicher, dass Ersatzsteckverbinder den richtigen Kontakttyp verwenden.

Prüfen Sie die Durchgängigkeit bei stillgesetzter und sicher isolierter Maschine, verlassen Sie sich jedoch nicht allein auf eine statische Widerstandsmessung. Ein gebrochener Leiter kann bei geradem Kabel Durchgang haben und bei Biegung unterbrochen sein. Überwachen Sie im Rahmen einer genehmigten Prüfung mit geringem Risiko das Rückkopplungssignal, während die Energieführungskette ihren normalen Bewegungsbereich durchläuft.

Messen Sie die Encoderversorgung direkt am Encoder unter Betriebsbelastung. Eine stabile Spannung im Schaltschrank beweist nicht, dass die Spannung am Sensor stabil bleibt. Erfassen Sie den Minimalwert während der Spindelbeschleunigung, der Achsumkehr, des Bremsens und des Schützbetätigens.

Bei einem Inkrementalgeber prüfen Sie Kanalamplitude, Kanalsymmetrie, Phasenbeziehung und, falls verwendet, den Indeximpuls. Differenzielle Leitungspaare sollten symmetrisch bleiben. Rauschimpulse, fehlende Impulse oder eine zusammenbrechende Amplitude können auf Kabel-, Schirmungs-, Versorgungs- oder Sensorprobleme hinweisen.

Überprüfen Sie Encodertyp, Impulszahl, Polarität, Skalierung und Rückkopplungsquelle im Parametersatz des installierten Antriebs. Gehen Sie nicht davon aus, dass eine Parameternummer aus einem anderen MASTERDRIVES-Handbuch für diese Steuerplatine gilt.

USS-Fehler sollten nicht auf zufällige Bitänderungen reduziert werden

Die USS-Kommunikation arbeitet mit einem strukturierten Telegramm. Das Protokoll umfasst eine Fehlerprüfung, daher sollte ein beschädigtes Telegramm normalerweise zurückgewiesen werden, anstatt als ein unabhängiger gültiger Drehzahlsollwert akzeptiert zu werden.

Das bedeutet nicht, dass USS ignoriert werden kann. Kommunikationsprobleme können durch das Verhalten der Anwendung weiterhin zu einem Durchgehen beitragen. Die SPS kann das falsche Prozessdatenwort bilden. Ein vorzeichenbehafteter Wert kann falsch interpretiert werden. Das höherwertige und das niederwertige Byte können vertauscht sein. Alte Daten können in einem Übertragungspuffer verbleiben. Wenn eine Antwort ausbleibt, kann der vorherige Sollwert aktiv bleiben.

Doppelte Slave-Adressen können ebenfalls zu verwirrendem Verhalten führen. Jeder Antrieb im Netzwerk muss eine eindeutige Adresse verwenden. Die SPS-Abfragesequenz muss jede Antwort dem richtigen Slave und dem richtigen Speicherbereich zuordnen.

Das Steuerwort verdient die gleiche Aufmerksamkeit wie der Drehzahlsollwert. Ein Antrieb kann weiterhin aktiviert bleiben, während das SPS-Programm davon ausgeht, dass er gestoppt wurde. Quittierung von Fehlern, EIN-/AUS-Befehle, Richtungsbits und Neustartlogik können während der Wiederherstellung der Kommunikation falsch verarbeitet werden.

Zählen Sie erfolgreiche Transaktionen, Zeitüberschreitungen, zurückgewiesene Telegramme, aufeinanderfolgende Fehler und Wiederherstellungsereignisse. Ein einzelnes Bit für eine „Kommunikationsstörung“ liefert zu wenig Informationen. Die Diagnosedaten sollten angeben, welcher Slave abgefragt wurde und welche Transaktion fehlgeschlagen ist.

Beim MICROMASTER 440 bezieht sich P2010 auf die Konfiguration der USS-Baudrate. Der Parameter sollte nicht als allgemeine Einstellung für die Telegramm-Zeitüberschreitung behandelt werden. P2011 wird üblicherweise mit der USS-Adresse in Verbindung gebracht. Die Bedeutung aller Parameter muss dennoch anhand des korrekten MM440-Handbuchs und der Schnittstellenkonfiguration überprüft werden.

Eine längere Zeitüberschreitung ist nicht automatisch sicherer. Wenn der Antrieb während des Wartens auf die Zeitüberschreitung weiterhin einen vorherigen Wert ungleich null verwendet, kann eine Verlängerung dieser Verzögerung die unerwünschte Bewegung verlängern. Legen Sie zunächst fest, wie auf einen Kommunikationsverlust reagiert werden soll.

Die physische Schicht von RS-485 ist weiterhin wichtig

Auch wenn beschädigte Telegramme zurückgewiesen werden, kann ein instabiles RS-485-Netzwerk wiederholte Übertragungsversuche, veraltete Daten, verpasste Statusaktualisierungen und unregelmäßiges Anwendungstiming verursachen. Das physische Netzwerk erfordert daher eine vollständige Überprüfung.

Dokumentieren Sie den Bus vom Kommunikationsanschluss der S7-200 zu jedem Antrieb. Stellen Sie sicher, dass die Verdrahtung eine geeignete Linientopologie verwendet. Lange sternförmige Abzweigungen können Reflexionen verursachen und sollten vermieden werden, sofern die Dokumentation der installierten Schnittstelle sie nicht ausdrücklich zulässt.

Überprüfen Sie, dass alle Geräte übereinstimmende Kommunikationseinstellungen verwenden. Dazu gehören Baudrate, Parität, Telegrammstruktur, Prozessdatenlänge und Slave-Adresse. Dokumentieren Sie die Einstellungen, anstatt sie aus dem Gedächtnis zu ändern.

Die Terminierung muss den Anforderungen der tatsächlichen Siemens-Schnittstellen und -Steckverbinder entsprechen. Ein allgemeiner 120-Ohm-Widerstand sollte nicht automatisch hinzugefügt werden. Eine falsche Terminierung oder Vorspannung kann das Signal verschlechtern.

Prüfen Sie Kabeltyp, Schirmdurchgängigkeit, Steckererdung und Verlegung des Kommunikationskabels. RS-485-Kabel sollten nicht über längere Strecken neben Motorausgangskabeln, Leitungen für Bremswiderstände, Schützverdrahtung oder anderen Hochfrequenz-Leistungskreisen verlaufen.

Wenn der Trennabstand begrenzt ist, kreuzen Sie Leistungs- und Signalkabel ungefähr rechtwinklig. Sorgen Sie für einen gezielten Potenzialausgleich zwischen Schaltschränken und Maschinenteilen. Vermeiden Sie lange Schirmanschlusslitzen, die die Hochfrequenzwirkung verringern.

Verwenden Sie bei Bedarf eine geeignete Differenzial-Oszilloskopsonde, um die Wellenform zu untersuchen. Achten Sie auf Reflexionen, eine übermäßige Gleichtaktspannung, Überschwingen, langsame Flanken, Störimpulse und Amplitudenänderungen während der Beschleunigung der Spindel oder des Abbremsens der Achse.

Ein angeschlossener Laptop oder USB-Konverter kann die Erdung und die Busbelastung verändern. Dokumentieren Sie, ob sich der Fehler ändert, wenn Diagnosegeräte angeschlossen werden.

Komponenten für industrielle Kommunikation und Vernetzung sollten zusammen mit Topologie, Schirmung, Terminierung, Adressierung und der Transaktionsverarbeitung in der SPS bewertet werden. Der Austausch eines einzelnen Steckverbinders behebt keinen instabilen Zustandsautomaten der Kommunikation.

Überprüfen Sie das S7-200-Programm als Zustandsautomat

Intermittierende Fehler bei der Inbetriebnahme treten häufig während Übergängen und nicht im stationären Betrieb auf. Die Maschine kann sich bei kontinuierlichem Betrieb korrekt verhalten, aber beim Wechsel zwischen Hand- und Automatikbetrieb, beim Abschluss der Referenzfahrt, bei der Wiederherstellung nach einem Alarm, beim Wechsel eines Rezepts oder bei der Wiederherstellung der Kommunikation ausfallen.

Durchsuchen Sie den Programmquerverweis nach jeder Anweisung, die in die Variablen für die endgültige Geschwindigkeit, Richtung und Freigabe schreibt. Ältere Programme schreiben häufig in mehreren Netzwerken in dasselbe V-Speicherwort. Der zuletzt ausgeführte Schreibvorgang bestimmt das Ergebnis, was ein scheinbar zufälliges Verhalten verursachen kann.

Erstellen Sie eine eindeutige Stufe zur Befehlsarbitrierung. Handbetrieb, automatische Bewegung, Referenzfahrt, Einrichtfunktionen und Wartungsbefehle sollten als separate Anforderungen in diese Stufe eingehen. Der endgültige Sollwert sollte erst nach der Prüfung von Modus, Grenzwerten, Rückmeldungen, Kommunikation und Sicherheitsfreigaben erzeugt werden.

Überprüfen Sie die Logik für Einmalimpulse und Flankenerkennung. Ein Befehl, der nur für einen Abtastzyklus aktiv sein soll, kann aktiv bleiben, weil sein Flankenspeicher wiederverwendet, beibehalten oder überschrieben wurde. Ein Befehl kann auch erneut ausgelöst werden, wenn sich ein Modusbit ändert.

Prüfen Sie jede Verriegelung. Ermitteln Sie die Bedingung, die sie setzt, und jede Bedingung, die sie zurücksetzt. Eine Bewegungsverriegelung, die nur von einem späteren Schritt der Sequenz abhängt, kann aktiv bleiben, wenn die Sequenz durch einen Fehler unterbrochen wird.

Prüfen Sie die Verarbeitung vorzeichenbehafteter Daten. Eine negative Ganzzahl, die als vorzeichenloses Wort interpretiert wird, kann zu einem großen positiven Wert werden. Bei der Multiplikation kann ein Überlauf auftreten. Ein Wort, das in die falsche Byte-Reihenfolge kopiert wird, kann einen extremen Sollwert erzeugen.

Überprüfen Sie die Skalierung von technischen Einheiten auf den USS-Prozesswert. Wenden Sie positive und negative Grenzwerte nach der abschließenden Berechnung an, nicht nur an der HMI-Eingabe.

Legacy-Siemens-SIMATIC-S7-Steuerungssysteme können jahrzehntelang zuverlässig arbeiten, doch ihre Anwendungen enthalten häufig Änderungen aus mehreren Inbetriebnahmephasen. Eine strukturierte Querverweisprüfung ist aussagekräftiger, als von einer instabil gewordenen CPU-Hardware auszugehen.

Start- und Wiederherstellungszustände müssen separat getestet werden

Nicht initialisierte oder remanente Daten können nach Unterbrechungen der Versorgungsspannung, Software-Downloads, CPU-Übergängen von STOP nach RUN, Antriebsresets oder der Wiederverbindung des HMI eine seltene Bewegung auslösen.

Ermitteln Sie jeden remanenten Speicherbereich, der vom Bewegungsprogramm verwendet wird. Bestimmen Sie den Anfangswert von Geschwindigkeitsbefehl, Richtung, Freigabe, Betriebsart, Sequenzschritt, Tipp-Bits und Kommunikationsstatus nach jeder Art von Neustart.

Die Startroutine sollte alle Bewegungsanforderungen auf null setzen. Sie sollte anstehende Tipp- und Automatikbefehle löschen, die Rückmeldung prüfen, den Status der Endschalter bestätigen, die Kommunikation herstellen und eine bewusst ausgelöste neue Freigabesequenz verlangen.

Ein gespeicherter Sollwert ungleich null darf niemals allein dadurch wirksam werden, dass der Antrieb betriebsbereit wird, bevor die SPS ihre Initialisierung abgeschlossen hat.

Testen Sie Kaltstart, Warmstart, CPU-Übergang von STOP nach RUN, Antriebsreset, Wiederverbindung des HMI und die Wiederherstellung eines ausgefallenen USS-Teilnehmers. Führen Sie diese Tests bei mechanisch kontrollierter Maschine und reduzierter verfügbarer Geschwindigkeit durch.

Überwachen Sie die 24-V-Steuerversorgung während Einschalt- und Ausschaltvorgängen. SPS, Encoder, HMI, Kommunikationsschnittstelle, Schütze und Antriebselektronik können sich bei unterschiedlichen Spannungsschwellen zurücksetzen. Ein kurzer Spannungseinbruch kann dazu führen, dass ein Gerät weiterläuft, während ein anderes neu startet.

Dokumentieren Sie die Reihenfolge von Steuerungsspannung, SPS in RUN, intakter Kommunikation, betriebsbereitem Antrieb, gelöster Bremse und Bewegungsfreigabe. Diese Reihenfolge sollte eindeutig und wiederholbar sein.

Das HMI kann Befehle erzeugen, die nicht mehr sichtbar sind

Das TP-170A-Projekt muss gemeinsam mit dem SPS-Programm überprüft werden. Ein HMI-Befehl kann beim Drücken oder Loslassen eines Tasters, beim Öffnen oder Schließen eines Bildschirms, beim Herunterladen eines Rezepts, beim Aktualisieren eines Tags oder beim Wiederherstellen der Kommunikation geschrieben werden.

Eine Tasterfunktion mit Impulsbetrieb kann einen gefährlichen Zustand erzeugen, wenn das Drücken ein Bit setzt und das Loslassen es löscht. Fällt die Kommunikation aus, während der Taster gedrückt ist, erreicht der Löschbefehl die SPS möglicherweise nie.

Der Bediener sieht später eine nicht gedrückte Schaltfläche, aber das SPS-Bit bleibt aktiv. Ein weiterer Moduswechsel oder eine Freigabebedingung kann dann dazu führen, dass die veraltete Tippanforderung den endgültigen Bewegungsbefehl erreicht.

Eine robuste Tippfunktion sollte sich nicht nur auf ein Drücken-und-Loslassen-Paar stützen. Die SPS sollte eine kontinuierliche Aktualisierung des Befehls verlangen, eine kurze Ablaufzeit anwenden, den Betriebsmodus validieren und den Befehl entfernen, sobald die Kommunikation ungültig wird.

Prüfen Sie jedes HMI-Ereignis im Zusammenhang mit Tippbetrieb, Geschwindigkeitseingabe, Richtung, Rücksetzen, Modusauswahl, Referenzfahrt und der Steuerung des Automatikzyklus. Suchen Sie nach doppelten Tags, die auf dieselbe SPS-Adresse verweisen.

Numerische Eingaben müssen sowohl im Bedienpanel als auch in der SPS einer Bereichsprüfung unterzogen werden. Die SPS muss Werte außerhalb des zulässigen technischen Bereichs zurückweisen, selbst wenn das HMI-Feld scheinbar korrekt konfiguriert ist.

Ältere Siemens-SIMATIC-HMI-Systeme können ein auf Bildschirmebene ausgeführtes Verhalten enthalten, das in der SPS-Logik nicht sichtbar ist. Die separate Protokollierung des rohen HMI-Tags und des validierten SPS-Befehls hilft dabei, die tatsächliche Befehlsquelle zu ermitteln.

Der MM440 kann das Ereignis beeinflussen, ohne den Schlitten zu steuern

Der MICROMASTER 440 steuert die Spindel, kann aber dennoch die Umgebung der Schlittensteuerung beeinflussen. Sein Eingangsgleichrichter, Zwischenkreis, Motorausgang, Bremskreis und seine Schaltfrequenz können leitungsgebundene oder abgestrahlte Störungen erzeugen.

Die stärkste Störung kann während der Beschleunigung oder Verzögerung der Spindel, bei Stromspitzen oder beim Bremsen auftreten und nicht im stationären Betrieb. Vergleichen Sie die Zeitstempel des Weglaufens mit dem Spindelzustand.

Protokollieren Sie Spindelstart, Stopp, Geschwindigkeitsänderung, Strom, Zustand des Zwischenkreises, Fehlerhistorie und Bremsaktivität. Ermitteln Sie, ob jedes Ereignis während eines ähnlichen Spindelübergangs auftritt.

Wenn MM440- und MASTERDRIVES-Geräte denselben USS-Bus nutzen, beeinflusst die Spindel ebenfalls das Timing der Kommunikation. Die SPS muss jeden Slave vorhersehbar abfragen und jede Antwort in der korrekten Speicherstruktur verarbeiten.

Stellen Sie sicher, dass sich die USS-Datenbereiche der Spindel und des Schlittens nicht überschneiden. In kompakten S7-200-Anwendungen wird der V-Speicher manchmal ohne klare Trennung wiederverwendet. Ein für die Spindel geschriebener Baustein könnte einen Teil des Schlittenbefehls überschreiben.

Das Verlegen des MM440 außerhalb des Schaltschranks beseitigt seinen Einfluss nicht vollständig. Motorkabel, Erdungswege, Kommunikationsführung und gemeinsam genutzte Stromversorgungen können weiterhin verbunden sein.

Verwenden Sie Messungen statt wiederholter Verlagerungen. Untersuchen Sie die Kabeltrennung, die Schirmanbindung, die für den Antrieb spezifizierten Netzdrosseln oder Filter, die Potenzialausgleichsverbindungen im Schaltschrank, den Abschluss des Motorkabels sowie den zeitlichen Zusammenhang zwischen Schaltvorgängen und Kommunikationsfehlern.

MASTERDRIVES nach Signalfunktion prüfen

Eine Parameterprüfung der MASTERDRIVES sollte dem vollständigen Signalweg folgen. Beginnen Sie nicht mit einer Liste von Parameternummern, die aus einer anderen Installation kopiert wurde.

Überprüfen Sie zunächst die installierte Steuerungsversion, die Softwareversion, die Steuerungsplatine und die Rückmeldeoption. Prüfen Sie anschließend den Steuerungsmodus, die Motordaten, den Rückmeldungstyp, die Rückmeldungsskalierung und die Rückmeldungsquelle.

Ermitteln Sie jede Quelle, die die EIN-/AUS-Befehle des Antriebs steuern kann. Dazu können USS-Steuerwörter, Klemmeingänge, Festbefehle, interne Binektor-Verbindungen oder Technologiefunktionen gehören.

Ermitteln Sie jede Quelle, die zum endgültigen Drehzahl- oder Positionssollwert beitragen kann. Prüfen Sie den Hauptsollwert, zusätzliche Sollwerte, Festdrehzahlen, Tippfunktionen, Analogeingänge, Motorpotenziometerfunktionen und interne Funktionsbausteine.

Überprüfen Sie die positiven und negativen Drehzahlgrenzen, Beschleunigungsrampen, Verzögerungsrampen, Stromgrenzen, Drehmomentgrenzen und Richtungseinschränkungen. Vorübergehend konservative Einstellungen können das Diagnoserisiko verringern, sind jedoch kein unabhängiger Sicherheitsschutz.

Untersuchen Sie die Rückmeldungsüberwachung und die Störungsreaktion. Ermitteln Sie, wie der Antrieb konfiguriert ist, wenn die Rückmeldung ausbleibt, instabil, umgekehrt oder unplausibel wird.

Lesen Sie den Warnungs- und Störungsverlauf des Antriebs aus, bevor Sie ihn löschen. Eine scheinbar nicht relevante Warnung kann den Zeitpunkt dokumentieren, an dem sich die Steuerungsbedingung geändert hat.

Verwenden Sie die installierte Engineering-Methode, etwa DriveMonitor, die PMU, OP1S oder eine andere freigegebene Schnittstelle, um interne Konnektoren und Istwerte zu beobachten. Wählen Sie die Werte entsprechend der jeweiligen Steuerungsversion aus.

Dieser funktionale Ansatz gilt für Siemens-Antriebs- und Bewegungssteuerungssysteme älterer und aktueller Bauart. Die Steuerungssoftware, Rückmeldemöglichkeiten und interne Verschaltung können sich unterscheiden, selbst wenn zwei Antriebe physisch ähnlich aussehen.

Erstellen Sie einen ereignisgesteuerten Aufzeichner

Ein Ereignis, das einmal täglich auftritt, lässt sich nicht durch kontinuierliche Beobachtung des HMI lösen. Das System benötigt einen Diagnoseaufzeichner, der den Zeitraum vor und nach einer anormalen Bewegung erfasst.

Erstellen Sie einen zirkulären SPS-Puffer mit dem unverarbeiteten HMI-Befehl, dem validierten Befehl, dem endgültigen Drehzahlsollwert, der Richtung, der Freigabe, dem Modus, dem Ablaufzustand, den Grenzwereingängen, dem Bereitstatus des Antriebs, dem Ergebnis der USS-Transaktion und einem Abtastzähler.

Am Antrieb sollten das empfangene Steuerwort, der empfangene Sollwert, der aktive interne Sollwert, die tatsächliche Geschwindigkeit, der Rückmeldestatus, der Ausgangsstrom, sofern verfügbar der drehmomentbildende Strom, Warnungen und Störungen erfasst werden.

Der Trigger kann auf einer tatsächlichen Geschwindigkeit oberhalb eines kleinen Schwellenwerts basieren, während der endgültige SPS-Befehl null ist. Ein weiterer Trigger kann eine Bewegung außerhalb eines freigegebenen Ablaufzustands erkennen. Auch eine Abweichung zwischen befohlener und gemessener Richtung kann die Aufzeichnung auslösen.

Daten vor dem Trigger bewahren. Wenn die Aufzeichnung erst beginnt, nachdem sich der Schieber bewegt hat, kann die auslösende Bedingung bereits verschwunden sein.

Die Kommunikationsdiagnose sollte erfolgreiche Transaktionen, ausbleibende Antworten, zurückgewiesene Nachrichten, aufeinanderfolgende Fehler und Wiederherstellungsereignisse unterscheiden. Erfassen Sie, welcher Slave während des Fehlers aktiv war.

Halten Sie die Diagnoselogik kompakt. Die S7-200 verfügt über begrenzten Speicher und eine begrenzte Zykluskapazität. Stellen Sie sicher, dass die Protokollierung das Timing der vorhandenen USS-Routinen nicht beeinträchtigt.

Exportieren Sie die Daten nach jedem Ereignis. Speichern Sie sie zusammen mit dem Datum, dem Maschinenzustand, dem Zeugenbericht und allen physischen Beobachtungen. Eine Abfolge mehrerer Ereignisse kann ein Muster erkennen lassen, das ein einzelnes Ereignis nicht offenlegt.

Verwenden Sie Diagnosezähler, die spezifische Fragen beantworten

Zähler sind nur dann nützlich, wenn ihre Bedeutung eindeutig ist. Ein allgemeiner Befehlszähler und ein allgemeiner Rückmeldezähler können aus vielen normalen Gründen voneinander abweichen.

Zählen Sie jede akzeptierte HMI-Bewegungsanforderung. Zählen Sie jeden von der abschließenden SPS-Arbitrierung akzeptierten Bewegungsbefehl. Zählen Sie jede erfolgreich abgeschlossene USS-Übertragung. Zählen Sie jede gültige Antwort, die vom Achsantrieb empfangen wurde.

Zählen Sie außerdem Kommunikations-Timeouts, Ereignisse „Antrieb nicht bereit“, Grenzwertaktivierungen, Moduswechsel und abgelaufene Befehle.

Speichern Sie den zuletzt übertragenen Drehzahlwert und das Steuerwort. Speichern Sie den zuletzt gültig empfangenen Istwert und das Zustandswort. Fügen Sie der Befehlsstruktur, sofern praktikabel, eine Sequenznummer hinzu.

Wenn ein Ereignis auftritt, können die Zähler mehrere Fragen beantworten:

• Hat das HMI eine Anforderung erzeugt?
• Hat die SPS diese Anforderung freigegeben?
• Hat die SPS ein neues Telegramm übertragen?
• Hat der Antrieb eine gültige Antwort zurückgegeben?
• Hat die tatsächliche Bewegung ohne einen neuen freigegebenen Befehl begonnen?

Ein Zähler sollte nicht bei jedem Start automatisch zurückgesetzt werden, sofern sein historischer Wert nicht benötigt wird. Erwägen Sie, einen Ereigniszähler in einem remanenten Speicher zu sichern und gleichzeitig alle Bewegungsbefehle selbst auf einen sicheren Startwert zu setzen.

Unabhängiger Überfahrschutz darf nicht von der normalen Logik abhängen

Softwareseitige Positionsgrenzen sind sinnvoll, dürfen aber nicht die einzige Schutzmaßnahme gegen einen Fehler sein, der im SPS-Programm, im Kommunikationspfad oder in der normalen Antriebssteuerung entstehen kann.

Jede Achse sollte über einen ordnungsgemäß ausgelegten Endlagenschutz verfügen. Abhängig von der Risikobeurteilung der Maschine können dazu fest verdrahtete Endschalter, sicherheitsbewertete Positionssensoren, Sicherheitsrelais, Sperrschaltungen des Antriebs, Schütze, Bremsen oder eine andere validierte Architektur gehören.

Ein standardmäßiger SPS-Eingang, der einen Drehzahlbefehl von null schreibt, ist nicht automatisch eine Sicherheitsfunktion. Derselbe Logikfehler, der die Bewegung ausgelöst hat, kann verhindern, dass dieser Stoppbefehl verarbeitet wird.

Das Entfernen des Drehzahlsollwerts garantiert ebenfalls nicht, dass kein Drehmoment mehr anliegt. Der Antrieb kann weiterhin freigegeben sein, ein sekundärer Sollwert kann weiterhin aktiv sein oder gespeicherte mechanische Energie kann die Last weiter bewegen.

Prüfen Sie Not-Halt, Schutzverriegelungen, Überfahrschalter, Antriebsfehlerkontakte, Bremsen und Schütze unabhängig voneinander. Bestätigen Sie, dass nach dem Auslösen der Schutzeinrichtung ein bewusster Bedienvorgang zum Neustart erforderlich ist.

Reduzieren Sie während des diagnostischen Betriebs, soweit technisch möglich, die maximale Geschwindigkeit, Beschleunigung, das Drehmoment und den verfügbaren Verfahrweg. Temporäre mechanische Anschläge dürfen nur verwendet werden, wenn sie für die mögliche Aufprallenergie ausgelegt sind.

Kein Diagnoseziel rechtfertigt es, eine Person einer Achse auszusetzen, die bereits eine unkontrollierte Bewegung gezeigt hat.

Fallbeispiel: Ein Kabel, das nur während der Richtungsumkehr ausfällt

Betrachten Sie einen Schlitten, der sich bei langsamer statischer Prüfung normal verhält, sich aber während einer schnellen Richtungsumkehr heftig bewegt. Das SPS-Protokoll zeigt einen stabilen Befehl. Die Antriebsspur zeigt eine plötzliche Störung der gemessenen Geschwindigkeit, gefolgt von einer starken Korrekturausgabe.

Eine Durchgangsprüfung des Geberkabels ist erfolgreich, während die Maschine stillsteht. Das Kabel verläuft jedoch durch eine Energieführungskette. Ein Leiter ist nahe dem minimalen Biegeradius gebrochen und wird nur unterbrochen, wenn die Kette eine bestimmte Position erreicht.

Eine Oszilloskopmessung am Antriebseingang zeigt, dass ein Geberkanal während der Richtungsumkehr zusammenbricht. Der Befehl bleibt korrekt, und es wird kein USS-Fehler aufgezeichnet.

Das Kabel wird durch den korrekten, dauerhaft biegefähigen Typ ersetzt. Die Zugentlastung und der Schirmanschluss werden wiederhergestellt. Die Geberversorgung und die Signalformqualität werden über den gesamten Schlittenweg geprüft.

Die abschließende Überprüfung umfasst wiederholte Richtungsumkehrungen bei reduzierter Geschwindigkeit, gefolgt von einem kontrollierten Betrieb mit normaler Produktionsgeschwindigkeit. Eine neue, einwandfreie Signalform wird als Referenz gespeichert.

Dieser Fall zeigt, warum ein Rückkopplungsfehler dynamisch nachgewiesen werden sollte. Eine statische Widerstandsmessung kann erfolgreich sein, obwohl das Kabel im Betrieb ausfällt.

Fallbeispiel: Ein Tippbefehl bleibt nach einem Ausfall der HMI-Kommunikation bestehen

Bei einer anderen Maschine setzt das Drücken einer Tipptaste ein SPS-Bit. Beim Loslassen der Taste wird es gelöscht. Die HMI verliert während des Gedrückthaltens der Taste die Kommunikation, sodass der Loslassbefehl die SPS nie erreicht.

In diesem Moment verhindert eine andere Verriegelung die Bewegung. Das veraltete Tippbit bleibt verborgen. Später ändert der Bediener den Maschinenmodus. Die endgültige SPS-Logik akzeptiert nun die alte Tippanforderung, und der Schlitten bewegt sich unerwartet.

Der Antrieb folgt einem gültigen SPS-Sollwert. Die USS-Kommunikation ist beim Bewegungsbeginn intakt. Das Ersetzen des Gebers oder das Hinzufügen einer weiteren Schirmverbindung wird das Problem nicht beheben.

Die überarbeitete SPS-Logik erfordert eine kontinuierlich aktualisierte Tippanforderung. Der Befehl läuft nach einem kurzen Zeitraum ab. Er wird nur im richtigen Modus, bei gültiger Kommunikation und erfüllter erforderlicher Freigabebedingung akzeptiert.

Die Startlogik löscht alle Bewegungsanforderungen. Die HMI-Freigabeaktion bleibt bestehen, ist jedoch nicht länger der einzige Mechanismus, der den Befehl entfernt.

Der Ereignisschreiber bestätigt, dass das rohe HMI-Bit nach dem früheren Kommunikationsausfall weiterhin aktiv war. Die Ursache war keine Kommunikationsverfälschung, sondern die unsichere Verarbeitung eines gültigen, aber veralteten Befehls.

Fallbeispiel: Störungen legen eine Schwachstelle bei der USS-Pufferverarbeitung offen

Bei einer dritten Maschine treten USS-Timeouts auf, wenn die Spindel beschleunigt. Beschädigte Telegramme werden verworfen, sodass das Netzwerk einen Geschwindigkeitsbefehl nicht direkt in einen anderen umwandelt.

Die SPS-Anwendung verwirft den vorherigen Achsbefehl nach einer fehlgeschlagenen Transaktion jedoch nicht. Außerdem läuft die USS-Routine bedingt, wodurch unregelmäßige Abfrageintervalle entstehen.

Während eines Sequenzübergangs wird der neue Nullbefehl an eine Speicherstelle geschrieben, während der Übertragungspuffer weiterhin einen älteren Wert ungleich null enthält. Das nächste erfolgreiche Telegramm sendet gültige, aber veraltete Daten.

Der Antrieb erkennt einen korrekt strukturierten Befehl und reagiert normal. Die Störung der physikalischen Übertragungsschicht legte eine Softwareschwäche offen, anstatt den Sollwert direkt zu erzeugen.

Die Abhilfemaßnahme verbessert die Kabelführung und die Schirmanbindung. Anschließend wird die SPS-Kommunikationsroutine so umgestaltet, dass jeder Antrieb einen eigenen Speicherbereich verwendet. Der abschließend validierte Sollwert wird unmittelbar vor der Transaktion in den Übertragungspuffer kopiert.

Eine ausbleibende Antwort markiert die Daten als ungültig. Die programmierte Reaktion auf einen Kommunikationsverlust wird durch kontrollierte Tests verifiziert.

Dieser Fall zeigt, warum die Fehlersuche bei der Kommunikation sowohl die elektrische Signalform als auch den Lebenszyklus der Anwendungsdaten abdecken muss.

Eine praxisnahe Untersuchungssequenz vor Ort

Schritt 1: Die Maschine sichern. Einen unabhängigen Überfahrschutz einrichten, die Testenergie reduzieren und den Zugang für Personen beschränken.

Schritt 2: Die Hardware bestätigen. Vollständige Bestellnummern, Softwareversionen, Optionsbaugruppen, Feedbackgeräte und Schnittstellenmodule dokumentieren.

Schritt 3: Backups erstellen. Das S7-200-Programm, das TP-170A-Projekt, den MASTERDRIVES-Parametersatz und die MM440-Parameter sichern.

Schritt 4: Das Ereignis definieren. Richtung, Geschwindigkeit, Dauer, Betriebsart, Position, Spindelzustand und Anhalteverhalten dokumentieren.

Schritt 5: Die Befehlskette abbilden. Jede Quelle für Sollwert, Freigabe, Richtung, Festdrehzahl, Tippbetrieb und Zusatzsollwert identifizieren.

Schritt 6: Synchronisierte Protokollierung hinzufügen. SPS-Befehle, USS-Daten, interne Antriebswerte, Feedback, Strom, Grenzwerte, Warnungen und Fehler erfassen.

Schritt 7: Startzustände testen. Kaltstart, Warmneustart, CPU-RUN-Übergänge, HMI-Wiederverbindung und Wiederherstellung der Kommunikation untersuchen.

Schritt 8: Feedback dynamisch prüfen. Versorgungsspannung, Signalformqualität, Kopplung, Steckverbinder, Schirmung und Kabelbewegungen testen.

Schritt 9: Prüfen Sie USS und RS-485. Kontrollieren Sie Adressierung, Topologie, Abschluss, Datenbereiche, Zeitverhalten und Fehlerbehandlung.

Schritt 10: Überprüfen Sie die SPS-Querverweise. Ermitteln Sie alle Schreibzugriffe auf den endgültigen Sollwert, die Richtung und die Antriebsfreigabe.

Schritt 11: Prüfen Sie die Signalführung des Antriebs. Überprüfen Sie jede Befehlsquelle und jeden Einflussfaktor auf den aktiven Sollwert.

Schritt 12: Ändern Sie jeweils nur ein Element. Dokumentieren Sie den alten Zustand, den neuen Zustand, den Grund, das Testergebnis und die Methode zum Zurücksetzen.

Die langfristige Absicherung muss die Architektur berücksichtigen

Nachdem die unmittelbare Ursache gefunden wurde, fragen Sie, warum ein einzelner Fehler eine schädliche Bewegung auslösen konnte. Ein einzelner Kommunikations-Timeout, Kabelbruch oder HMI-Fehler sollte nicht jede Schutzschicht umgehen können.

Trennen Sie Befehlserzeugung, Befehlsvalidierung, Kommunikationsübertragung, Antriebssteuerung und Sicherheitsschutz. Jede Schicht sollte eine klar definierte Verantwortung haben.

Die SPS sollte einen begrenzten und zustandsvalidierten Befehl erzeugen. Die Kommunikationsroutine sollte aktuelle Daten mit eindeutiger Gültigkeit und Aktualität übertragen. Der Antrieb sollte konfigurierte Betriebsgrenzen und die Überwachung der Rückmeldungen anwenden. Unabhängige Sicherheitsfunktionen sollten die gefährliche Bewegung steuern.

Prüfen Sie, ob die S7-200- und USS-Architektur weiterhin unterstützt werden kann. Die Migration auf eine neuere SPS- und Antriebsplattform kann Diagnose, Zeitstempel, Komponentenverfügbarkeit, Netzwerkeinsicht und Backup-Verwaltung verbessern.

Ein neueres Netzwerk macht eine Maschine nicht automatisch sicher. PROFINET allein behebt keine schwache Befehlsarbitrierung, eine mangelhafte Startlogik oder einen unzureichenden Überfahrschutz.

Die Modernisierung sollte das HMI, die Zeichnungen, die Versionskontrolle der Software, die Sicherheitsarchitektur, die Ersatzteilstrategie und die Schulung des Personals umfassen. Der Austausch nur der SPS kann das Problem auf eine andere Plattform verlagern.

Bei anspruchsvollen Positionieranwendungen sollte geprüft werden, ob das Bewegungsprofil in einem dedizierten Antrieb oder einer dedizierten Bewegungssteuerung statt über wiederholte serielle Geschwindigkeitsbefehle ausgeführt werden sollte. Die richtige Entscheidung hängt von Positioniergenauigkeit, Synchronisierung, Zykluszeit, Rückmeldungsarchitektur und Maschinenrisiko ab.

Verifizierung bedeutet mehr, als auf die Rückkehr des Fehlers zu warten

Sieben Tage ohne Zwischenfall sind ermutigend, beweisen jedoch nicht, dass die Grundursache beseitigt wurde. Bei der Verifizierung sollten die Bedingungen, die das Risiko zuvor erhöht haben, gezielt reproduziert werden.

Führen Sie wiederholt vollständige Verfahrzyklen mit kontrollierter Geschwindigkeit durch. Beziehen Sie schnelle Richtungsumkehr, Spindelbeschleunigung, Spindelbremsung, warme Schaltschrankbedingungen, die maximale normale Last und die Bewegung der Energiekette ein.

Wiederholen Sie die Start- und Wiederherstellungstests. Schalten Sie die Steuerungsspannung gemäß einem genehmigten Verfahren ein und aus. Testen Sie CPU STOP-zu-RUN, Antriebsreset, HMI-Wiederverbindung, den Ausfall eines USS-Slaves und die Wiederherstellung der Kommunikation.

Überprüfen Sie die Reaktion auf einen Ausfall der Rückführung mit einer zugelassenen Testmethode. Trennen Sie keinen Encoder einer Produktionsanlage, solange Personen der Bewegung ausgesetzt sind.

Testen Sie jeden Hardware-Endschalter, jede Softwarebegrenzung, jeden Antriebsfehlereingang, den Not-Halt, die Bremse und jedes unabhängige Überfahrgerät. Bestätigen Sie das erforderliche Stoppverhalten und das Verhalten beim Neustart.

Vergleichen Sie während jedes Tests den endgültigen SPS-Befehl, den vom Antrieb empfangenen Befehl, den aktiven internen Sollwert und die tatsächliche Bewegung.

Definieren Sie die Abnahmekriterien vor dem Test. Geeignete Kriterien können Folgendes umfassen:

• Keine unbeabsichtigte Bewegung bei irgendeinem Start- oder Wiederherstellungszustand.
• Kein unbehandelter USS-Kommunikationsfehler.
• Kein beibehaltenes Bewegungskommando nach Verlust der HMI-Kommunikation.
• Stabile Versorgung der Rückführung und stabile Signalform über den gesamten Verfahrweg.
• Korrekte Funktion jedes unabhängigen Überfahrgeräts.
• Aufgezeichnete Übereinstimmung zwischen Befehl, empfangenem Sollwert, aktivem Sollwert und tatsächlicher Bewegung.

Halten Sie den Ereignisrekorder während des frühen Produktionsbetriebs aktiv. Eine erfolgreiche Korrekturmaßnahme sollte sowohl das physische Symptom als auch das abnormale Diagnosemuster beseitigen, das es verursacht hat.

Die Grundursache zeigt sich dort, wo die Signale erstmals voneinander abweichen

Ein intermittierendes Durchgehen des Schlittens in einem System mit Siemens S7-200 und MASTERDRIVES sollte nicht ohne Belege „Störungen“, dem „Encoder“ oder „USS“ zugeschrieben werden.

Die entscheidende Methode besteht darin, den endgültigen SPS-Befehl, den vom Antrieb empfangenen Befehl, den aktiven internen Sollwert und die tatsächliche mechanische Reaktion miteinander zu korrelieren.

Wenn der SPS-Befehl falsch wird, untersuchen Sie HMI und Anwendungslogik. Wenn der übertragene oder empfangene Wert falsch wird, untersuchen Sie Speicherverwaltung, Skalierung, Telegrammkonstruktion und das RS-485-Netzwerk.

Wenn der Antrieb eine Befehlsquelle aktiviert, die von der SPS nicht vorgesehen war, prüfen Sie die interne Antriebskonfiguration. Wenn jeder Befehl weiterhin sicher ist, während der Motor beschleunigt, untersuchen Sie Rückführung, Versorgung der Steuerplatine, Antriebshardware und Mechanik.

Fehler in der Rückführung bleiben plausibel, müssen jedoch als vollständige Stromkreise geprüft werden. USS-Probleme bleiben ebenfalls plausibel, aber veraltete gültige Daten und eine unzureichende Wiederherstellungslogik sind oft wahrscheinlicher als ein zufällig beschädigtes Telegramm, das zu einem gültigen Befehl für maximale Geschwindigkeit wird.

Die Maschine sollte erst dann wieder in den Normalbetrieb gehen, wenn der unabhängige Schutz wirksam ist, der auslösende Mechanismus durch aufgezeichnete Belege gestützt wird und kontrollierte Tests sowohl die Korrekturmaßnahme als auch das Verhalten bei künftigen Fehlern bestätigt haben.

Dieser disziplinierte Ansatz erfordert mehr Vorbereitung als der spekulative Austausch von Komponenten. Er führt außerdem zu einem wertvolleren Ergebnis: einer Maschine, deren Bewegungsbahn verstanden, protokolliert, dokumentiert und gegen den nächsten Einzelfehler geschützt ist.