# Wofür Immer-Ein oder Immer-Aus Merker



## det (1 Dezember 2019)

N'Abend zusammen,

ich sitze gerade über einem Prog das von jemand externen geschrieben wurde. 
Im OB1 wird 
"UN M0.0 ; SM0.0"  (immer_ein)           und
"U   M0.1 ; RM0.1"  (immer_aus)
programmiert.

In diversen Netzwerken tauchen die beiden Merker dann auf.
ZB: 
U M100.2  (Presse Start)
U M0.1       (immer_aus)
= Q10.1     (Presse Start)

oder

U M25.3  (Anschlag Band1)
U M0.0   (immer ein)
S Q11.3  (Anschlag Hoch)
R Q11.4  (Anschlag Runter)

Warum macht man das? Wo ist der Nutzen? Ich habe auch noch keine Logik gefunden, wann welcher Merker eingesetzt wird.
Wie und warum macht Ihr das? Oder nicht.

Grüße Detlef


----------



## Ph3niX (1 Dezember 2019)

Wir haben teilweise Programme und/oder Bausteine, welche für diverse Anlagen einsetzbar sind.

Meinetwegen eine Heizungsregelung für ein Wasserrohrsystem. Hat dieses Rohrsystem bei einem anderen Kunden jedoch keine Heizungsregelung, so schalten wir die Fehlermeldungen oder Funktionen mit einem "Immer_aus" oder auch in TIA heißend "Always_false" einfach ab, weil diese nicht benötigt werden.


----------



## Piit278 (1 Dezember 2019)

det schrieb:


> N'Abend zusammen,
> 
> ich sitze gerade über einem Prog das von jemand externen geschrieben wurde.
> Im OB1 wird
> ...




Servus, 

Vllt. War es so gedacht, dass man schnell die Logik auskommentieren kann. Einfach aus dem „U“ ein „UN“ oder umgekehrt und schon kann man die Logik dahinter auskommentieren.
In diesem Zusammenhang macht das aber meiner Meinung nach wenig Sinn.

Zum auskommentieren sollte man aber nicht „einfache“ Merker mit der Bezeichnung „immer-eins“ benutzen. In den meisten Programmen gibt es zur Inbetriebnahme 
1 und 0 Merker die bsp. „IBN_TRUE“ bzw. „IBN_FALSE“ benannt sind, damit man bei der IBN schnell Programmteile auskommentieren kann. Der Vorteil bei dieser Benennung ist, dass du gezielt in den Querverweisen nach Inbetriebnahme Logik suchen kannst und du nicht ausversehen einen dieser Merker vergisst zu löschen nach der IBN.



In KOP/FUP kannst du Immer-Eins oder Immer-Null Merker benutzen um das Programm in einem Netzwerk besser zu strukturieren. (Kann jetzt leider kein Bild hochladen wie ich das meine).


Mit freundlichen Grüßen
Piit


Gesendet von iPhone mit Tapatalk


----------



## escride1 (1 Dezember 2019)

Das wäre das Beispiel das Pit meint. Strukturierung in FUP/KOP-Netzwerken.

Der Code den Du gepostet hast:

Q10.1 Presse Start wird nicht mehr Starten. Das wird so gemacht wenn sie vorübergehend herausgenommen wurde, oder aber dauerhaft, aber das Gundkonzept für Referenzen weiterhin vorhanden bleiben soll. In meinem Fall nutze ich solch eine Programmierung wenn ich Änderungen an einem Programm mache. Dann kopier ich das Netzwerk, füge es dahinter neu ein. Das erste wird deaktiviert durch DauerNull sowie Kommentar geändert. Anschließend wird das neu kopierte um die neuen Funktionen erweitert. Vorteile: Jeder sieht wie es mal funktionierte und falls die neue Funktion nicht den Zweck erfüllt ist ein Rücksetzen leichter.

Das zweite Beispiel liegt vielleicht daran das es mal in FUP programmiert wurde. Wenn man den &-Baustein einfügt, dann sind immer zwei Kontakte anzugeben. Der erste dann in diesem Fall M25.3 und im zweiten hat man dann einfach den DauerEins-Merker genommen. Hätte aber auch 25.3 nochmal nehmen können oder aber den Kontakt entfernen.

Vielleicht ist in dem Programm aber auch DauerEins und DauerNull so gemacht worden um die Funktionen aus bestimmten Gründen zumindest zeitweise zu unterbrechen. Das erkennt man dann nur daran was und wie etwas verhindert oder ermöglicht wurde.

Es gibt dann noch Bausteine wie z.B. Regler, die an bestimmten Eingängen immer TRUE oder FALSE haben wollen. Dafür würden dann ebenfalls diese Merker benutzt.

Die Merker AlwaysTrue und AlwaysFalse sind heute in den 1200 und 1500er Baugruppen sogenannte Systemmerker. Sie gehören einfach dazu. Ob man diese verwendet oder nicht bleibt jedem selbst überlassen. Es entfällt lediglich das Netzwerk im OB wo diese Merker zugewiesen werden, die Funktion ist gleich.
edit: Die Funktion ist gleich solange man im fortgeschrittenen Zyklus ist. Der erste Anlauf würde die Merker im OB1 erst nach dem Anlauf-OB starten. Dadurch könnte ein Programm das diese Merker bereits im Anlauf nutzt kompromittiert werden.


----------



## Heinileini (1 Dezember 2019)

det schrieb:


> ich sitze gerade über einem Prog das von jemand externen geschrieben wurde.
> Im OB1 wird
> "UN M0.0 ; SM0.0"  (immer_ein)           und
> "U   M0.1 ; RM0.1"  (immer_aus)
> ...


Dürfte "historisch" bedingt sein. Ich kenne ähnliches aus S5-Zeiten, in denen es keinen CLR- und keinen SET-Befehl gab, um das VKE zu löschen oder zu setzen.
Es war mal von Siemens so vorgegeben, dass M 0.0 immer False und M 0.1 immer True zu sein hatte. Einige Siemens-StandardBausteine verliessen sich darauf - glaube ich - und wir haben uns "drangehängt". 
Braucht man wirklich den CLR- bzw. SET-Befehl? Braucht man wirklich Boolsche Variablen die nie ihren Wert verändern, z.B. um damit AufrufParameter von FCs bzw. FBs zu versorgen? Möchte man S5-Gepflogenheiten in S7 unverändert am Leben erhalten? Ist sicherlich alles Geschmackssache.
In S5-Projekten habe ich damals aus gegebenem Anlass am Ende von OB1 eingeführt:

```
UN  M 0.0
U   M 0.1
BEB
A   DB 0
BE
```
Der A DB 0 war unzulässig und hat die PLC in Stopp versetzt. Dadurch wurde man mit der Nase darauf gestossen, wenn ein Kollege (oder man selbst) sich erdreistet hatte, etwas zu programmieren, wodurch die "heile Welt" zerstört wurde.
Vor der Zeit von M 0.0 und M 0.1 hatte Siemens zwei andere Merker für denselben Zweck festgelegt. Waren es M 238.6 und M 238.7 oder M236.6 und M 236.7 oder ... ich weiss es nicht mehr.


----------



## det (1 Dezember 2019)

Hallo,

@ph3nix  Ich habe Überbrückungen (ODER) gefunden. Da die Merker im OB1 immer VKE True haben geht es immer weiter.
@piit        Scheinen wirklich IBN Merker zu sein. Sitzen in Schrittketten und diversen Ausgängen. 
Die Merker sind nicht am Anfang vom Netzwerk, sondern immer mittendrin. Oder wie meinst du das mit der Struktur.

Grüße Detlef


----------



## det (1 Dezember 2019)

N'Abend,
da habe ich meinen letzten Post ein Stunde vergessen und nicht abgeschickt.:|
Danke an alle für die Infos. Scheint eine Mischung aus allem zu sein. Ich bin jetzt einmal grob durch. Warum das mit TIA13 so gemacht wird.
Werde bei Gelegenheit mal aufräumen.

Grüße Detlef


----------



## PN/DP (1 Dezember 2019)

det schrieb:


> Im OB1 wird
> "UN M0.0 ; SM0.0"  (immer_ein)           und
> "U   M0.1 ; RM0.1"  (immer_aus)
> programmiert.


Wer hat sich das ausgedacht? Das ist ganz schön verwirrend 
Üblicherweise ist M0.0 immer 0 und M0.1 immer 1 ...

Variablen Immer1 (AlwaysTrue) und Immer0 (AlwaysFalse) braucht man auch, wenn man bei Bausteinaufrufen in FUP/KOP einen BOOL-Eingang (z.B. Modus-Steuereingang) mit True oder False beschalten will (z.B. den Modus-Steuer-Input "BIPOLAR" beim FC105 SCALE). In AWL kann man die Systemkonstanten True oder False an Inputs verschalten, in FUP/KOP muß es aber zwingend eine Variable sein.

Harald


----------



## de vliegende hollander (2 Dezember 2019)

Seit TIA V15 kann mann auch in KOP/FUP Netzwerken direktanweisung benutzen. (true / false)
Und, im TIA , glaube ab V13 (oder nur mit 1500 SPS), kannst dun im ein Netzwerk mehrere FUP Netzwerken machen.

Also, braucht mann sie nicht mehr.
Ich verzichte ab V15 komplett drauf. Nur Direktanweisungen.

Bram


----------



## de vliegende hollander (2 Dezember 2019)

Hilfreiche merker  die immer true oder false sind, sind to do und forcemerker.
Die müssen aber selbst angelegt und beschaltet werden.
Während der Inbetriebnahme kannst du sie verwenden, und noch wichtiger, immer wieder zurück zufinden.

"TO_DO_false" := "FORCE_false" := false;
"TO_DO_true"  := "FORCE_true"  := true;


----------



## winnman (2 Dezember 2019)

in Classik braucht man hin und wieder die logischen Zustände an irgendwelchen dingen (zB.: bei Reglern kann damit P,I,D feigegeben werden, . . .)

Wenn das Projektweit im OB1 fix definiert ist, kann mann da dann eben schnell den logischen Zustand draufschalten.

M0.0 (bei uns M1.0 da auf MB0 der Takmerker liegt) sollte immer low und M0.1 sinngemäß dann high sein.


----------



## PN/DP (2 Dezember 2019)

de vliegende hollander schrieb:


> Seit TIA V15 kann mann auch in KOP/FUP Netzwerken direktanweisung benutzen. (true / false)
> [...]
> Also, braucht mann sie nicht mehr.
> Ich verzichte ab V15 komplett drauf. Nur Direktanweisungen.


Auch bei S7-300/400 ?

Harald


----------



## de vliegende hollander (3 Dezember 2019)

PN/DP schrieb:


> Auch bei S7-300/400 ?
> 
> Harald



Hallo Harald,

nein, leider nicht. Ich hab es probiert.

keine Direktanweisung und netzwerken müssen zusammenhangend sein.

Bram


----------



## MFreiberger (3 Dezember 2019)

Moin de vliegende hollander,



de vliegende hollander schrieb:


> Seit TIA V15 kann mann auch in KOP/FUP Netzwerken direktanweisung benutzen. (true / false)
> Und, im TIA , glaube ab V13 (oder nur mit 1500 SPS), kannst dun im ein Netzwerk mehrere FUP Netzwerken machen.
> 
> Also, braucht mann sie nicht mehr.
> ...



Guter Hinweis.
Retorische Frage: Warum bietet SIEMENS dann noch im Systemmerkerbyte "AlwaysTrue" und "AlwaysFalse" an? Da könnten sie ja dann auch sagen, dass ihr Standard die Direktanweisungen sind und, wenn man noch, zu Kompatibilitätszwecken, ein Merker benötigt, sich diesen ja selber bauen kann.

VG

MFreiberger


----------



## de vliegende hollander (3 Dezember 2019)

MFreiberger schrieb:


> Retorische Frage: Warum bietet SIEMENS dann noch im Systemmerkerbyte "AlwaysTrue" und "AlwaysFalse" an? Da könnten sie ja dann auch sagen, dass ihr Standard die Direktanweisungen sind und, wenn man noch, zu Kompatibilitätszwecken, ein Merker benötigt, sich diesen ja selber bauen kann.



Ich kann mich vorstelen das nicht jeder das will.


----------



## Heinileini (3 Dezember 2019)

MFreiberger schrieb:


> R?etorische Frage: ... im Systemmerkerbyte "AlwaysTrue" und "AlwaysFalse" ... wenn man noch, zu Kompatibilitätszwecken, ein Merker benötigt, sich diesen ja selber bauen kann.


Man kann so manches selber bauen und dann hat jeder wieder seinen eigenen Standard. Und wäre es wirklich sooo kompatibel, wenn man dafür andere Variablen (z.B. Merker) belegt?
Vielleicht verwendet Siemens in seinen StandardBausteinen noch die "bewährten" Merker und mag sie deshalb noch nicht zur freien Verwendung freigeben.

Richtig hinterhältig finde ich übrigens, wenn man zwar dieselben Merker nimmt, aber ihre Bedeutungen genau vertauscht - so wie es in diesem Thread gezeigt wird. 
Ich hatte ja die stille Hoffnung, dass diese Vertauschung unserem TE versehentlich durch falsches Zitieren passiert ist und nur in diesem Thread existiert ...

PS: 


de vliegende hollander schrieb:


> Ich kann mich vorstelen das nicht jeder das will.


Ich kann mir auch vorstellen, dass viele nicht das wollen, was SIEMENS will.


----------



## det (4 Dezember 2019)

Moin Heinileini,

es ist nicht so hinterhältig wie es scheint. Im Abschreiben war ich schon immer schlecht  
M1.0 ist der immer_aus.  Der M1.1 ist der immer_ein.  sorry 

Grüße Detlef


----------



## Heinileini (4 Dezember 2019)

Moin Detlef,
hinterhältig hätte ich eine absichtliche Vertauschung gefunden - ein oder zwei versehentliche sind allemal verzeihlich. 
Gruss, Heinileini


----------

