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

L

L4s3r73k

Level-2
Beiträge
113
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich hab an verschiedenen Orten und verschiedenen Situationen bereits gehört, dass Merker in aktuellen 1500er CPUs eine "emulierte" Geschichte sei, die nur wegen Altprogrammierern behalten würde, damit diese sich nicht an neue Dinge gewöhnen müssen. Dass das Leistung kostet und das pauschal die Zykluszeit ab dem ersten Merker, der verwendet wird, den CPU Zyklus verdopple. Siemens selbst rate von der Verwendung ab.

In meiner vorherigen beruflichen Laufbahn hatte ich einen Kollegen, der dies glaubhaft versicherte bewiesen zu haben und demnach haben wir alle Merker eliminiert. Leider kann ich heute diesen Benefit nicht mehr rekonstruieren.

Kann man mir Quellen nennen oder ist das tatsächlich alles Humbug?

Vielen Dank
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn man Unfug betreiben will, kann man das mit DBs genauso gut wie mit Merkern.

Aber DBs zwingen einem zumindest eine Mindeststrukturierung irgend einer Art bereits auf, was bei Merkern wirklich nicht gegeben ist. Außerdem sind Merker halt immer Nicht-Optimiert, was im Zusammenspiel mit Optimierten Bausteinen zumindest mal "nicht-optimal" ist. Da aber hoffentlich niemand KB Weise von Merker auf DB und zurück kopiert, wird das vermutlich in den allermeisten Fällen egal sein.

Ich persönlich bin auch Fan von DBs, aber wenn es 3 Uhr Nachts brennt und der Programmierer sich fix mit einem Merker zu helfen weiß ist das allemal besser, als keine Lösung zu haben.
 
L4s3r73k schrieb:
Kann man mir Quellen nennen
Zum Vergrößern anklicken....
Aus dem Programmierleitfaden für S7-1200/S7-1500 Seite 101:

1743680493791.png


So ganz traue ich den Aussagen hier nicht:
Der Umgang mit Merkern (auch System- und Taktmerker) ist problematisch, da
jede Steuerung einen unterschiedlich großen Merkerbereich hat.
Zum Vergrößern anklicken....
Stimmt nicht. Eine CPU 1511 hat 16KB Merker, genauso wie eine 1518 und alles dazwischen.
Nur bei den 1200érn gibt es Unterschiede. Entweder 4KB oder 8KB.

Der Umgang mit Merkern (auch System- und Taktmerker) ist problematisch, da jede Steuerung einen unterschiedlich großen Merkerbereich hat.
Zum Vergrößern anklicken....
Ich sag mal so, wenn das ein Totschlagargument sein soll weil es Programmierer vor Probleme stellt, ja dann weiß ich auch nicht. Anscheinend traut man bei Siemens den Programmierern nicht viel zu.

PS:
Ich ahne schon, wer hier bald noch seinen Senf dazu abgibt....
 
Zuletzt bearbeitet:
Ich verwende die Merker für Quick-and-dirty Programmänderungen in einer laufende System einzufügen.
Wenn ich in Shared-DBs oder FBs die Deklaration ändern wurde, dann wurde es bedeuten die Shared-DBs oder dazuhörende Instanz-DBs neu geladen werden musste. Und dass kann problematisch sein auf eine laufender Anlage.

Spähter, wenn die Änderung getestet ist, mache ich die Programmänderung sauber in die Shared-DB oder FB.

L4s3r73k schrieb:
Dass das Leistung kostet und das pauschal die Zykluszeit ab dem ersten Merker, der verwendet wird, den CPU Zyklus verdoppl
Zum Vergrößern anklicken....
Bin sicher dass ist Quatsch.
Heute haben die CPUs so viel Leistung und so viel Speicher, das es ist sowiso egal.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der best practices wegen werden Merker heutzutage wirklich nicht mehr benötigt, die Taktmerker verwende ich hingegen schon noch gerne.. das gute an Systemmerkern ist halt, dass die nicht selbst gebastelt werden müssen..

.. für alles andere einfach Variablen im Datenbaustein verwenden.. ist schon schöner.
 
Man kann auch mit Merkern sehr strukturiert arbeiten.
Flankenmerker, . . . mach ich immer noch gerna damit.

Muss man halt von anfang an sauber überlegen in welchen Bereichen man was unterbingen will.

Dann möglichst gleich einige Reserven in der Symbolliste eingeben aus denen hervorgeht welcher Bereich für was zuständig ist.

Schmiermerker kommen mir keine ins Programm, das war S5 (und ev. ganz alte S7 wo man mit jedem Bit ausieren musste (oder sehr viel Geld in die Hand nehmen)

Systemmerker heissen wohl deshalb so weil es eben "Merker" sind.

Welche Farbe haben die Tabletten die sich die bei Siemens da einwerfen. (haben will die Selben :) )
 
winnman schrieb:
Flankenmerker, . . . mach ich immer noch gerna damit.
Zum Vergrößern anklicken....
Die Frage ist doch, was brauche ich global und was nur lokal.. darum geht es wohl auch Siemens, Informationen nur dort verwendbar machen wo sie wirklich gebraucht werden. Flanken werden im statischen Bereich der Funktion vorgehalten.. global passieren andere Events. Auf neuen Steuerungen darf auch gerne mit Daten gehaushaltet werden. Viel Speicher sollte nicht zum rumschmieren einladen, sondern zum effizienten Austausch von Daten und Informationen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DCDCDC schrieb:
Der best practices wegen werden Merker heutzutage wirklich nicht mehr benötigt
Zum Vergrößern anklicken....
Blöd nur wenn man im laufenden Betrieb Änderungen machen möchte und TIA bei DB Änderungen dann einen STOP / Reinit verlangt. Bei alten Firmwareversionen reicht eine Kommentaränderung im DB zur Stopanforderung.

In dem Fall finde ich Merker praktisch.
 
Vollsymbolisch sind Merker praktisch.
Also kann ich die ein TAG Nummer vergeben und dann das TAGnummer im Programm verwenden.
Der ein oder andre Signal kann das bei mir zutreffen.
Sonnnst hast du vollsymbolisch; Datenbaustein.TAG

Oja, ich habe sonnst genau 4 Merker selber angelegt
TODO false
TODO true
FORCE false
FORCE true
 
DeltaMikeAir schrieb:
Blöd nur wenn man im laufenden Betrieb Änderungen machen möchte und TIA bei DB Änderungen dann einen STOP / Reinit verlangt. Bei alten Firmwareversionen reicht eine Kommentaränderung im DB zur Stopanforderung.

In dem Fall finde ich Merker praktisch.
Zum Vergrößern anklicken....
Hi,

Das ist irgendwie das allerwichtigste Argument pro Merker. Aber was ist denn der Unterschied einfach einen neuen global DB anzulegen in dem die schnelle "Lösungsvariable" drin ist, dann läuft doch auch alles ohne Init weiter. Fehler in Programmen müssen ja nicht immer nur BOOL Variblen sein. Und alles komplexere würden wahrscheinlich Wenige über Merker abbilden oder?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Blöd nur wenn man im laufenden Betrieb Änderungen machen möchte und TIA bei DB Änderungen dann einen STOP / Reinit verlangt. Bei alten Firmwareversionen reicht eine Kommentaränderung im DB zur Stopanforderung.
DeltaMikeAir schrieb:
In dem Fall finde ich Merker praktisch.
Zum Vergrößern anklicken....
Ich habe dafür einen MerkerDB (oder auch mehrere) darin lege ich provisorisch die neuen Variablen an und zwar so wie sie dann im Definitivum auch heissen. Somit ändert dann nur der Prefix (der Name des DBs) im Programm.
Ich habe dann also die richtige Struktur inklusive neuer Tags im provisorischen DB der da z.B. Heisst ParameterCharge2
der im Programm verwendete DB heisst Parameter. Charge2 ist eine Kopie des OriginalDBs.
Sobald ich dann das Programm mal neu Laden kann inkl Reinit. Lösche ich den DB Parameter. Aktualisiere die Typen die ggf verändert wurde. Benenne den DB ParameterCharge2 um nach Parameter. Download.
 
Ich arbeite mittlerweile überwiegend mit Schneider/Codesys unterwegs und vermisse als gelernter S5´ler die Merker überhaupt nicht. Das Thema Reinitialisieren im TIA ist schon übel, vor allem wenn man einen Globalen DB gebastelt hat für Merker und dann feststellt das man den nicht nach belieben ändern kann ohne die CPU durch Stopp zu jagen...
 
Ich habe in den letzten Jahren außer den Systemmerkern fast nur noch mit DB's gearbeitet. Die sonstigen (aus Gewohnheit und Bequemlichkeit) verwendeten Merker waren: IBN (Inbetriebnahmemerker), Flanken von Systemtakten (z.B. um Betriebsstunden mit Sekundenanzeige zu zählen), usw.
Aber es gibt einen großen Vorteil von Merkern, diese sind immer überlagert, d.h. ich kann mir ein MW als INT und die dazugehörigen Bits als BOOL definieren ohne zusätzlich eine Überlagerung mit AT anlegen zu müssen. (z.B. Statuswort und Bedeutung der einzelnen Bits)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In meinen Programmen passiert das Meißte in FB's - dieser hat dann in sich auch schon alles in der Instanz drin was er braucht. Aber es gibt ja auch FB's die untereinander Daten auszutauschen haben. Hier greife ich dann grundsätzlich NICHT auf die Instanz des Anderen zu sondern übergebe solche Info's dann über die Schnittstelle an der außen dann wieder Merker (oder -Worte) dran hängen.
Das Siemens generell von der Verwendung von Merkern abrät ist in meinen Augen völliger Humbug - in jedem Programmier-Entwicklungssystem gibt es globale Variablen und als solche sehe ich die Merker im Grunde auch an. Einen globalen DB an dieser Stelle finde ich aufgrund des Re-Init-Verhaltens der "neuen" CPU's unpraktisch ...
 
Larry Laffer schrieb:
Das Siemens generell von der Verwendung von Merkern abrät ist in meinen Augen völliger Humbug
Zum Vergrößern anklicken....
Ich würde es mal so sagen. Wenn man sie mit Bedacht einsetzt, sind sie gut, hilfreich und an der Stelle ggf. angebracht ( z.B. um einen Produktionsstop zu vermeiden ). Diese ausgearteten Programme in denen z.B. in sämtlichen FB´s mit Merkern ab Werk gearbeitet wird sind halt schlecht. Aber das war zu Step7 Zeiten nicht anders.
 
Larry Laffer schrieb:
Das Siemens generell von der Verwendung von Merkern abrät ist in meinen Augen völliger Humbug - in jedem Programmier-Entwicklungssystem gibt es globale Variablen und als solche sehe ich die Merker im Grunde auch an.
Zum Vergrößern anklicken....
Sehe ich auch so.
Ich glaube, dass Siemens die Programmierer mit durchschnittlichem Ausbildungsstand vor sich selbst schützen will, weil das Programmieren heutzutage anscheinend kaum noch jemand richtig lernt und ohne richtigen Plan einfach losprogrammiert (vorher planen kostet ja zusätzlich Arbeit/Zeit). Bei Merkern muss man aber mehr beachten und planen, und z.B. selbst drauf achten, dass die Merkervariablen sich nicht überlappen. Der Klassiker: MW1, MW2, MW3, M4.0, M4.1 ... Also werden die Merker einfach mit Schreckensszenarien von angeblich extremem Performanceverlust generell verteufelt.

Das ist wie bei den TEMP-Variablen. Weil die wohl auch zu oft falsch verwendet werden (Werte lesen ohne vorher was reinschreiben), werden die TEMP-Variablen nun eigentlich unnötigerweise initialisiert (allerdings nicht immer je nach SPS-Typ und Firmware-Version und optimiert/Standard). Da wird dem Programmierer nicht erzählt, dass das unnötig Performance kostet.
 
Zurück
Oben