Musste da doch stark an ein paar Kollegen denken die noch aus der S5 Zeit kommen und wie wild Schmiermerker nutzen. Was da alles für ein Schund bei so einem Programm rauskommen würde will ich gar nicht wissen...
Ich habe sehr wohl gesehen, dass dieser Thread schon "etwas älter" ist und habe ihn heute erst entdeckt, weil er kürzlich erst wiederbelebt wurde.
Was soll schon Vernünftiges dabei heraus kommen, wenn man Merker so abfällig als
SchmierMerker bezeichnet.
Da ist man auf eine negative Beurteilung ja schon so was von festgenagelt bzw. ist der gute Ruf schon derart ruiniert, dass man kaum eine Chance hat, sachlich zu erklären, worum es wirklich geht.
Wenn man SchmierMerker wild (= undiszipliniert und planlos) nutzt, dann besteht selbstverständlich die Gefahr, Schund zu programmieren.
Aber SchmierMerker waren nichts Chaotisches, sondern ein sehr klar strukturiertes und sorgsam angewendetes HilfsMittel, um die akute "MangelWirtschaft" bei S5 zu entschärfen.
Merker gab es viel zu wenige. Nämlich 256 * 8 Bit = 2048 Bit, die man einzeln aber auch gruppiert zu max. 256 Bytes à 8 Bit, max. 128 Worten à 16 Bit oder max. 64 DoppelWorten à 32 Bit verwenden/ansprechen konnte.
Die o.g. max. 128 Worte bzw. max 64 DoppelWorte sind insofern wörtlich zu verstehen, wenn man den MerkerBereich so in Raster einteilt, dass sich verschiedene Worte nicht gegenseitig überlagern und sich verschiedene DoppelWorte auch nicht gegenseitig überlagern.
Nahm man Überlagerungen (gemeint sind Doppel- oder MehrfachBelegungen desselben SpeicherBereichs) in Kauf, so konnte man max. 255 MerkerWorte und max. 253 MerkerDoppelWorte adressieren. Aber es sind noch etliche weitere gegenseitige Überlagerungen denkbar.
Gründe, Doppel- bzw. MehrfachBelegungen zu wollen, gab es aber nicht bzw. kenne ich keine - ausser beim Befehl B MW und bei den sogenannten SchmierMerkern, die nichts anderes sind, als temporäre bzw. lokale Merker, die man bei S5 allerdings selbst verwalten musste, weil sie nicht vom BetriebsSystem bereitgestellt wurden.
Stattdessen gibt es aber jede Menge Gründe, Doppel- bzw. MehrfachBelegungen zu vermeiden. Dazu war ein gründliches und gewissenhaftes Studium der QVL (QuerVerweisListe) und des BelegungsPlans erforderlich.
Ja, bei einigen S5-CPUs gab es als Maßnahme gegen die MangelWirtschaft "ParallelWelten" für die SpeicherBereiche der Merker und der DBs.
Das waren die sogenannten S-Merker und die DX-DatenBausteine.
Man hört immer wieder den Tipp, keine Merker zu verwenden, sondern stattdessen Variablen, die man in DatenBausteinen anlegt.
Das muss man aber nicht ausgerechnet auf die S5 beziehen. Die Adressierung war im Bereich DB bzw. DX komplizierter bis unmöglich beim Ansprechen von DatenBits und aufwändiger, wenn man häufig zwischen Daten in unterschiedlichen Bausteinen umschalten musste. Diesen MehrAufwand gab es im Bereich der Merker nicht, weshalb er durchaus gerne und sinnvoll genutzt wurde.
Für eine Byte-orientierte Adressierung bot sich die Benutzung des MerkerBereichs ebenfalls an, da der DB- bzw. DX-Bereich bei der S5 (fortschrittlicherweise schon ;o) Wort-orientiert war. Dieser "Fortschritt" wurde bei der S7 wieder "zurückgenommen" mit dem Vorteil, dass es hier in allen Bereichen einheitlich nur noch die byteweise Numerierung bei der Adressierung gibt (Ausnahme, die S5-Timer und -Zähler), allerdings ergänzt um weitere 3 Bit für die Adressierung von 8 einzelnen Bit je Byte. Dieses gutgemeinte, vereinheitlichte System bei Siemens SPS, das zudem versucht, die Bits aus der Welt der SPS in die Welt der HochSprachen zu überführen/zu retten, hat in der Praxis aber anscheinend viel KopfZerbrechen bereitet.
Da kann ich meinen Vorrednern nur Recht geben. Merker können sofort nach zuweisung abgefragt werden.
Ja, und aber wie! Das gilt doch für alle Variablen, dass sie durch die Zuweisung unverzüglich ihren ggfs neuen Inhalt erhalten und dass der neue Inhalt auch sofort abrufbar ist! Da wird nichts auf geheimnisvolle und unsichtbare Weise zwischengelagert!
Das, was wir im Programm als Eingänge oder Ausgänge ansprechen, sind doch normalerweise nicht direkt die HardwareEingänge und nicht direkt die HardwareAusgänge, sondern ihre ProzessAbbilder. Die wiederum sind ganz normale SpeicherBereiche. Na ja, ganz normal sind sie insofern nicht, als das BetriebsSystem zyklisch etwas mit ihnen macht. Das BS kopiert die Zustände der HW-Eingänge in das PAE (ProzessAbbild der Eingänge) und die Zustände des PAA (ProzessAbbild der Ausgänge) auf die HW-Ausgänge.
Man kann selbstverständlich Ausgänge beschreiben (z.B. setzen oder rücksetzen) und auch Eingänge. Die Ausgänge und die Eingänge kann man danach auch abfragen.
Um sich selbst und anderen das Leben nicht unnötig schwer zu machen, wird immer wieder geraten, die Ausgänge an nur 1 Stelle im Zyklus (nicht mehrfach im Zyklus) zu schreiben und die Eingänge gar nicht, denn die werden ja schon anderweitig vom BetriebsSystem geschrieben (s.o.).
Aber man kann es tun. Man sollte aber wissen, was man da tut und man sollte sich gut überlegen, ob es sinnvoll ist und welche unbeabsichtigte NebenWirkungen auftreten können.
Oben schrieb ich, dass man normalerweise die Hardware-Ein- und -Aus-gänge im Programm nicht direkt anspricht, sondern ihre ProzessAbbilder.
Man kann aber die "Peripherie" direkt, also unter Umgehung der ProzessAbbilder, ansprechen, wenn man es mal tun will oder muss.
Auch hier gilt natürlich: genau überlegen, was man damit erreicht/anrichtet/kaputtmacht.
