Fehlerhandling über verkettete Liste

OOP

Level-1
Beiträge
49
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich habe gerade vor ein Fehlerhandling für Maschinen zu erstellen.
Hierzu dachte ich an einen "Errorhandler", welcher auf Basis einer verketteten Liste arbeitet.
Man könnte Bspw. mit folgendem Quellcode die Fehlernummer einer Achse hinzufügen.
Code:
Errorhandler.AddError(AxisErrorId);

Über einen geeigneten Wrapper könnte man dann die Listeneinträge (Bspw. die letzten10) darstellen.

Was haltet ihr davon?
 
Wenig. Wenn mal ein unerwarteter Meldeschwall kommt fliegt Dir das ganze u.U. um die Ohren.
In SPS macht man absichtlich keine dynamische Speichernutzung.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für den Grund der Harald beschrieben hat verwende ich für die Meldungen für den Bediener immer eine Alarmsystem mit ein Meldung = ein Bit.
Die Meldungen sind dann fest definiert in den SPS als auch in den HMI. Den HMI sorgt für dass die Meldungen angezeigt und geloggt werden.

Als eine interne Debug-Funktion verwende ich manchmal eine Liste wie du vorschlägst.
Es gibt die Vorteile, dass jeden Eintrag bekommt eine Zyklusgenaue Zeitstempel, und den Reigenfolge von die Einträge in Liste passen mit den realen Reihenfolge womit die Eintrage im Programm aktiviert werden.
Klar ist dass die Liste hat eine begrenzte Anzahl Einträge.
Ich verwende es nur wenn den Maschinensekvenz so schnell ist, man hat keinen Möglichkeit es zu beobachten in Real-Zeit.

edit:
Mit die S7-1500 CPUs finde ich dies ist ein guten Funktion, weil sie haben relativ viel RAM (MB anstatt kB) in vergleich zu die Classic CPUs.
 
Zuletzt bearbeitet:
Verkettete Liste in SPS ist so möglich: alle maximal benötigten Listenplätze müssen beim STOP/RUN der CPU schon Speicherplatz belegen (z.B. als Array Of Listenelement). Nur so weiß man sicher, daß im Bedarfsfall genug Speicher zur Verfügung steht. Der Speicherplatz für ein neues Listenelement darf nicht erst zur Laufzeit angefordert werden (ala malloc), weil dann bekommt man Probleme mit der Fragmentierung von Speicher und braucht einen Garbage Collector.

Ich vermute stark, daß so ein "Errorhandler.AddError(AxisErrorId);" die Programmabarbeitungszeit erheblich mehr verlängert gegenüber einer immer ausgeführten logischen Verknüpfung, wo es egal ist ob am Ende 0 oder 1 rauskommt. Bei einem Ereignisschwall kann es da zu unerwarteten Zykluszeitüberschreitungen kommen, wenn man das nicht vorher abtestet mit dem Worst Case: Anzahl Ereignisse * ungünstigste Suchzeit nach freien Listenelementen.

Harald
 
Also Harald, Du hast ja schon des Öfteren ST/SCL und OOP dahingehend kritisiert, dass sie dazu verleiten, eine SPS wie einen PC zu programmieren. Ich muss gestehen, dass Du mich damit so langsam auf Deine Seite ziehst. Wenn wir mal in Rente gehen, wird es vielleicht üblich sein, bei einer IBN gleich zwei Maschinen hinzustellen, weil die erste eh verschrottet wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn wir mal in Rente gehen, wird es vielleicht üblich sein, bei einer IBN gleich zwei Maschinen hinzustellen, weil die erste eh verschrottet wird.
Dafür brauchen wir nicht unbedingt zwei Maschinen hinzustellen. Die Maschine wird einfach mit Gutscheinen für die ersten 5 Retrofits ausgeliefert . . . oder mangels Alternativen in China gekauft und dann behältst Du mit Deiner Prognose fast Recht. Die eine Maschine wird aber nicht verschrottet, sie ist das ErsatzteilPaket!

PS und off topic:
OWL lese ich da in Deinen technischen Daten - damit bist Du (fast über-) qualifiziert für den SPS-Forum-Regional-Stammtisch im Bielefelder Runkelkrug!?!
 
Naja eine dynamisch verkettete Liste ist bei SPS natürlich nicht optimal.
Störpuffer gibt's aber in den verschiedensten Formen.
Ich hab sowas schon mal als Ringpuffer umgesetzt.

Gruß
Blockmove
 
Wenig. Wenn mal ein unerwarteter Meldeschwall kommt fliegt Dir das ganze u.U. um die Ohren.
In SPS macht man absichtlich keine dynamische Speichernutzung.

Harald

Verstehe dein Argument. Nur nutzen Steuerungshersteller mittlerweile selbst dynamische Speicherallokation fürs Fehlerhandling. Man kann denen natürlich vorwerfen, das die das leichtfertig machen oder man kann davon ausgehen das heutige steuerungen in der Lage sind dies zu handeln.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Verstehe dein Argument. Nur nutzen Steuerungshersteller mittlerweile selbst dynamische Speicherallokation fürs Fehlerhandling. Man kann denen natürlich vorwerfen, das die das leichtfertig machen oder man kann davon ausgehen das heutige steuerungen in der Lage sind dies zu handeln.

Naja Codesys kann __NEW und __DELETE.
Damit könnte man sehr wahrscheinlich eine verkettete List umsetzen.
Nur ist das - meines Wissens - in Verbindung mit Online-Change sehr mit Vorsicht zu geniesen.
Darum hab ich zumindest einen großen Bogen darum gemacht.
 
Nur nutzen Steuerungshersteller mittlerweile selbst dynamische Speicherallokation fürs Fehlerhandling. Man kann denen natürlich vorwerfen, das die das leichtfertig machen oder man kann davon ausgehen das heutige steuerungen in der Lage sind dies zu handeln.
Ich gehe mal davon aus, daß die Steuerungsherstellern viel mehr Manpower, Testzeit, Versicherung, Anwälte und vor allem viel exzellentere Programmierer zur Verfügung haben, als die Firmen wo Du und ich als SPS-Programmierer angestellt sind. ;) (Wobei, wenn man überlegt, wie lange es dauert bis z.B. eine S7-1500 eine halbwegs stabile Firmware hat...)
Ein stabiles dynamisches Speichermanagement und Zykluszeiteinhaltung liegt weniger an der verwendeten Steuerung, sondern am Können der Programmierer die es implementieren.

Harald
 
Ich gehe mal davon aus, daß die Steuerungsherstellern viel mehr Manpower, Testzeit, Versicherung, Anwälte und vor allem viel exzellentere Programmierer zur Verfügung haben, als die Firmen wo Du und ich als SPS-Programmierer angestellt sind. ;) (Wobei, wenn man überlegt, wie lange es dauert bis z.B. eine S7-1500 eine halbwegs stabile Firmware hat...)
Ein stabiles dynamisches Speichermanagement und Zykluszeiteinhaltung liegt weniger an der verwendeten Steuerung, sondern am Können der Programmierer die es implementieren.

Harald

:D vor allem die Aussage zur "Testzeit" ist aus Erfahrung eher Wunschdenken. Oftmals kommt es mir so vor, dass die Sachen direkt als Prototypen an den Kundem weitergereicht werden. Im Idealfall hat man dann "nur" skalierbarkeits Probleme.
Ich gebe dir recht, man muss schon wissen was man tut. Ich gehe aber davon aus das der Threadersteller diese Gedanken auf Grund von erhöhten Anforderungen z. B. an Flexibilität hat und die entsprechende saubere Programmierung, bzw. Der erhöhte Zeitaufwand, sich durch die ergebenen Möglichkeiten amortisieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Abseits von grundsätzlichen Bedenken gegen dynamische Speicherverwaltung bei der SPS betrachte ich das konkrete Vorhaben des TE eher skeptisch. Selbst wenn eine stabile und echtzeitfähgie Speicherverwaltung vorhanden ist, steht davor immer noch die Handhabung der verketteten Liste durch das Anwenderprogramm mit kaum vorhersehbaren Ausführungszeiten. Ich gehe mal davon aus, dass die Methode "AddError" aus schnellen Steuerungstasks aufgerufen werden soll, dort kann ich so etwas aber gar nicht gebrauchen.
Ausserdem dürften die Fehlereinträge in der Liste relativ klein sein. Damit entstehen Speicherlücken, die man für kaum etwas anderes gebrauchen kann als wieder für neue Fehlereinträge.
 
. . . Worst Case: Anzahl Ereignisse * ungünstigste Suchzeit nach freien Listenelementen.
Sorry, dass ich jetzt erst darüber stolpere:
Das "Verketten" einer Liste bzw. die kleinen Änderungen in der Verkettung geschehen doch normalerweise "scheibchenweise" so ganz nebenbei, damit einem der grosse Klumpen einer SuchOrgie erspart bleibt! Das ist doch geradezu ideal für die SPS-Programmierung. Also: auch die freiwerdenden ListenElemente verketten!!!

Ich gehe mal davon aus, dass die Methode "AddError" aus schnellen Steuerungstasks aufgerufen werden soll, dort kann ich so etwas aber gar nicht gebrauchen.
Ich sehe eigentlich überhaupt keine Anwendung dafür, bei einer SPS im laufenden Betrieb eine Fehlermeldung hinzuzufügen, die es vorher noch nicht gab. Das sollte doch schon bei der Konfigurierung der Software entsprechend der an der Maschine bzw. Anlage realisierten optionalen Maschinen- bzw. AnlagenTeile geschehen sein. Damit wäre es ein Fall für eine bedingte Compilierung der Software oder ein Fall für die Parametrierung einer "allumfassenden" Software.

Noch mehr KopfGrimmen bereitet mir, dass die Anwendung dieser Methode für "ErrorHandling" gebraucht wird. Soll damit tatsächlich eine Liste der (Gegen-)Massnahmen erstellt werden, die den Weg aus dem Schlammassel weist, auf das das Auftreten einer Fehlermeldung oder einer bestimmten Ansammlung von Fehlermeldungen schliessen lässt? Eine solche Liste inhaltlich sinnvoll zu füllen dürfte das eigentliche Problem sein - nicht so sehr die Aufgabe, einen geeigneten Platz für die Liste zu finden.
 
Zuletzt bearbeitet:
Zurück
Oben