TIA Merker - lahmendes Relikt aus alten Zeiten oder ist es egal?

Zuviel Werbung?
-> Hier kostenlos registrieren
Analog zu die elektrische Steurung - ein SPS ist ja 'nur' eine software Steuerung.

Wenn man bei den IBN eine Fehler in die Schaltschrank findet, bittet man die Elektropläner um aktualisierte Schaltpläne, Stückliste, Montageplan, und ein Kit mit die Hardware bevor man es installiert, wobei eine Maschinen-Stop gefordert ist ?
Oder ..... liegt man schnell ein Draht damit dass die Fehler mitlerweile überbrückt wird, und ohne Maschinen-Stop ? Dann spähter korrekt machen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Genügend Reserven in den Strukturen der DBs vorsehen und sich für Variablennamenänderung nen Rettungsmechanismus gegen Reinitialisierung bauen...
Oder Speicherreserve nutzen und neue/geänderte Variablen am DB-Ende anfügen...

Aber schön ist beides nicht...

Und man muss sich VORHER überlegen, dass man irgendwann später geänderte Variablen braucht.
 
L4s3r73k schrieb:
Dass das Leistung kostet und das pauschal die Zykluszeit ab dem ersten Merker, der verwendet wird, den CPU Zyklus verdopple.
Zum Vergrößern anklicken....
L4s3r73k schrieb:
Kann man mir Quellen nennen oder ist das tatsächlich alles Humbug?
Zum Vergrößern anklicken....
Ich halte diese Aussage für Humbug.

VIELLEICHT wird sich die Verwendung von Merkern so ähnlich äussern wie die Verwendung von nichtoptimierten DBs.

Aber, Zykluszeitprobleme sind doch nicht das Hauptkriterium für den einen oder anderen Programmierstil.

Ich verwende in 300/400ern in der Regel auch keine Merker. Nur mal zwischendurch zum Testen von irgendwas.

Für lokale Verwendung in FCs/FBs sollte man keine globalen Variablen hernehmen, weder Merker noch Global-DBs.

Für globale Verwendung eignen sich DBs halt besser als Merker, weil besser strukturierbar.

Wenn man Zykluszeiten im einstelligen ms Bereich braucht, muss man sowieso konkret über alles mögliche nachdenken..

Wenn man winzige SPSn mit 20 UND/ODER verwendet, dann ists scheißegal ob Merker oder DBs. Umso größer die Software umso wichtiger ne gute Strukturierung des Programms.
 
Aus genau diesen Gründen sind bei mir, wie auch früher im S7-Classic, die DBs für den Programmablauf bei Start IBN voll mit Variablen wie ResBool107 oder ResInt21 im jeweiligen Struct des Anlagenteils. Dann kann ich nur durch Kommentaränderung die Funktion Quick and Dirty beschreiben und später brauch ich keine Programmänderungen für den Download machen, sondern nur Variablennamen ändern. Arbeite aber hauptsächlich mit FC + Global-DB. Die DBs werden getrennt in einen Ablauf-DB und einen Einstellungen-DB je Bereich. Ein Bereich ist meistens ein Automatik- und analog Sicherheits-Bereich. Alles in der diskreten Fertigung. Jede einzelne Automatik in der Fertigungslinie ist soweit autark bis zur Übergabe an den nächsten Bereich.

Bei S7-Classic hatte ich anstelle der deklarieren Reserve-Variablen oftmals Strings mit Bezeichnung Reserve z.B. 20 Byte.

Bei Classic war ne S7-319F üblich und jetzt S7 1514F/1515F/1516F.

An der Speichergrenze war ich noch nie. Aber ne Zykluszeit von 20ms ist dann das absolute Limit. Besser ist unter 10ms.
 
Zurück
Oben