BYTE-Umschalter

[FoodFighter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo allerseits,

ich benötige einen simplen Byte-Umschalter - d.h.
3 Eingänge: 2x Byte, 1x Bool
1 Ausgang: Byte

Über den Bool-Eingang soll man umschalten können, welcher der beiden Byte-Eingänge auf den Ausgang durchgereicht wird.
Eigentlich sehr simpel.
In der Siemens-Standard-Lib gibt es zwar einen FC36 - SEL, dieser hat jedoch am Ausgang (logischerweise) einen ANY-Datentyp definiert, weshalb ich ihn nicht ohne weiteres verschalten kann, sofern ein Eingang einen bestimmten Datentyp erwartet.

Lange Rede, wenig Sinn:
Ich habe folgendes gebaut:

      U     #UMS
      SPB   QBY2

QBY1: L     #BY_1
      T     #Q_BY
      SPA   ENDE

QBY2: L     #BY_2
      T     #Q_BY

ENDE: BE

Das funktioniert auch soweit, jedoch bin ich mir unsicher, ob ich noch was vergesse.
Oft liest man was von "NOP 0" statt "BE" (wo ist der funktionelle Unterschied? NOP 0 ist eine Leeranweisung, BE beendet den Baustein)
Ebenfalls habe ich sowas ähnliches schonmal gesehen, da waren aber noch SET, SAVE und CLR Befehle drin (vermutlich weil der SCL-Baustein in AWL geöffnet wurde, da die SCL-Quelle nicht (mehr) vorhanden war?)

Habe ich was vergessen oder gibt es bei diesem simplen Baustein Verbesserungspotential?

Liebe Grüße

 

[Ralle]

Das funktioniert so.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe ich was vergessen oder gibt es bei diesem simplen Baustein Verbesserungspotential?

Wie so oft im Leben und beim Programmieren gibt's verschiedene Ansätze/Lösungswege. Z.B.:

      L     #BY_1
      T     #Q_BY
      UN    #UMS
      BEB
      L     #BY_2
      T     #Q_BY
      BE

// - - - - o d e r - - - -

      L     #BY_1
      L     #BY_2
      U     #UMS
      SPB   STOR
      TAK
STOR: T     #Q_BY
      BE

// - - - - o d e r - - - -

      L     #BY_2
      U     #UMS
      SPB   STOR
      L     #BY_1
STOR: T     #Q_BY
      BE

Oft liest man was von "NOP 0" statt "BE" (wo ist der funktionelle Unterschied? NOP 0 ist eine Leeranweisung, BE beendet den Baustein)

Nein, nicht NOP 0 statt BE. Der funktionelle Unterschied ist genauso, wie Du schreibst.
NOP 0 "macht nix" (ausser SpeicherPlatz zu belegen und AusführungsZeit zu erhöhen) und der BE beendet den Baustein, der BEB übrigens auch, sofern VKE = 1 ist.
Der NOP 0 dient eigentlich dazu, einen AWL-Baustein so zu formulieren, dass er wahlweise eindeutig als KOP oder FUP dargestellt werden kann.
Wenn er hier in "PseudoCode" so häufig auftaucht, dann eigentlich nur, weil sich keiner traut, rechts von einem Sprungziel keinen OP-Code hinzuschreiben.

Ebenfalls habe ich sowas ähnliches schonmal gesehen, da waren aber noch SET, SAVE und CLR Befehle drin (vermutlich weil der SCL-Baustein in AWL geöffnet wurde, da die SCL-Quelle nicht (mehr) vorhanden war?)

SAVE kopiert das VKE ins BIE-Bit des StatusWorts und somit in den ENO-Ausgang (der in der FUP- bzw KOP-Darstellung erscheint).

CLR und SET definieren das VKE.
Diese sind am Anfang eines Bausteins sinnvoll, wenn man sich nicht darauf verlassen will oder kann, dass eine vorausgegangene Verknüpfung (in dem aufrufenden Programm) auch ordnungsgemäss durch = oder S oder R oder SPB oder BEB oder sonstwie VKE-begrenzend abgeschlossen wurde.
In diesem Fall würde das, was in Deinem Baustein als erste "Erstverknüpfung" gemeint ist, nicht als Erstverknüpfung ausgeführt, sondern als Fortführung einer woanders (für Dich in Deinem Baustein nicht sichtbaren Weise) bereits begonnenen Verknüpfung.
In anderen Sprachen gibt es U, UN, O, ON, X, XN nicht als Erstverknüpfung, weil man dort für eine Erstverknüpfung einen anderen OP-Code (z.B. L oder RD) schreiben muss, so dass man hier dieses Problem nicht kennt.
Solche unvollständigen Verknüpfungen können leicht versehentlich entstehen, wenn für TestZwecke oder bei einer Inbetriebnahme "mal eben" ein paar ProgrammZeilen "auskommentiert" werden. Mit auskommentiert ist gemeint, dass man einen Befehl im Programm "optisch" beibehalten, ihn aber unwirksam machen will, ihn also in einen Kommentar umwandelt.

 

[ducati]

NOP 0 "macht nix" (ausser SpeicherPlatz zu belegen und AusführungsZeit zu erhöhen) und der BE beendet den Baustein, der BEB übrigens auch, sofern VKE = 1 ist.
Der NOP 0 dient eigentlich dazu, einen AWL-Baustein so zu formulieren, dass er wahlweise eindeutig als KOP oder FUP dargestellt werden kann.
Wenn er hier in "PseudoCode" so häufig auftaucht, dann eigentlich nur, weil sich keiner traut, rechts von einem Sprungziel keinen OP-Code hinzuschreiben.

.

Bei manchen TIA Versionen kannst Du Code der rechts vom Sprungziel steht nicht beobachten...
Deshalb schreib ich da immer NOP 0 hin...

 

[FoodFighter]

Super,
vielen Dank für die Rückmeldungen, Anregungen und Erklärungen

Liebe Grüße

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

... In der Siemens-Standard-Lib gibt es zwar einen FC36 - SEL, dieser hat jedoch am Ausgang (logischerweise) einen ANY-Datentyp definiert, weshalb ich ihn nicht ohne weiteres verschalten kann, sofern ein Eingang einen bestimmten Datentyp erwartet...

Der FC36 hätte aber auch mit dem Datentyp "Byte" funktionieren müssen. Wo hat es denn da geklemmt?

 

[FoodFighter]

Der FC36 hätte aber auch mit dem Datentyp "Byte" funktionieren müssen. Wo hat es denn da geklemmt?

An den unterschiedlichen Datentypen ANY (Ausgang vom FC36) und BYTE (Eingang vom Folgebaustein).
Hier mal exemplarisch:

 

[Onkel Dagobert]

Ja, aber an solchen Stellen muss man doch so wie so mittels einer (temporären) Variable übergeben? Wie sieht das denn mit deinem selbstgestrickten Baustein aus?

Ist das CFC?

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum Baustein 24 auch nicht als Sel_by. Das ist doch den Selekt?

 

[FoodFighter]

Ja, aber an solchen Stellen muss man doch so wie so mittels einer (temporären) Variable übergeben? Wie sieht das denn mit deinem selbstgestrickten Baustein aus?

Ist das CFC?

Ja, ist CFC.
Nunja, mit dem selbstgestrickten Umschalter funktioniert die Verbindung, da Ausgang und Eingang den gleichen Datentyp haben;


Oder im konkreten Beispiel:

Warum Baustein 24 auch nicht als Sel_by. Das ist doch den Selekt?

Weil dieses Beispiel exemplarisch dafür dienen sollte, wieso ich einen solchen SEL_BY gerne haben wollte (und eben darum "gebaut" habe...wenn man diesen Achtzeiler so titulieren möchte ).

Edit:
Vllt. sollte ich noch erwähnen: der SEL_BY IST der selbstgestrickte FB...in dem steckt der AWL-Code aus Beitrag #1.

 

[Thomas_v2.1]

Ich würde ja die Parameter genau so bezeichnen wie bei den anderen SEL-Funktionen aus der Bibliothek.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der FC36 Select SEL ist nicht aus der CFC-Library oder PCS7-Bibliothek, sondern aus der Step7 Standard Library IEC... Da muss man mit sowas rechnen.

Nebenbei, ob das so ne gute Sache ist, bei PCS7 das Qualitybyte umzuschalten muss man halt schaun... Da hebelt man auch mal schnell das ganze Konzept mit den Baugruppentreibern aus...

Eigentlich gibts ja für Digital-Eingänge auch Treiberbausteine

 

[FoodFighter]

Ich würde ja die Parameter genau so bezeichnen wie bei den anderen SEL-Funktionen aus der Bibliothek.

Das passt schon so - hier werden noch andere Bibliotheken verwendet, in denen es ähnliche Umschalter gibt, an welche die Parameterbezeichnungen angelehnt sind

Der FC36 Select SEL ist nicht aus der CFC-Library oder PCS7-Bibliothek, sondern aus der Step7 Standard Library IEC... Da muss man mit sowas rechnen.

Ja, ist auch kein Drama - darum wurde ja kurzerhand was eigenes gebaut.

Eigentlich gibts ja für Digital-Eingänge auch Treiberbausteine

Yessir - diese werden auch verwendet. In der Anlage geht auch kein Eingang sondern eine Laufmeldung über einen anderen Baustein auf den Umschalter.
Diese sind/waren aber alle schon fertig getaggt - daher wurde hier im Beispiel des Datenschutzes wegen improvisiert

Nebenbei, ob das so ne gute Sache ist, bei PCS7 das Qualitybyte umzuschalten muss man halt schaun... Da hebelt man auch mal schnell das ganze Konzept mit den Baugruppentreibern aus...

Auch dem stimme ich prinzipiell zu - in diesem speziellen Anwendungsfall ist dies allerdings ein vertretbarer Kompromiss.
Hierbei handelt es sich um elektronische Stellantriebe mit Stellungsrückmeldung (Keystone EPI2 ).
Sobald diese spannungslos geschaltet werden, schmeißt die Rückmeldung einen Fehler.
Es gibt eine ganze Batterie von diesen Antrieben, die bei längerfristiger Nichtverwendung gnadenlos stromlos gemacht werden.
Die funktionslosen Stellungsrückmeldungen stören dann im Bild und in der Fehlerliste - daher werden diese nun ausgehebelt, sobald keine Rückmeldung vom Schütz, welches den Antrieb bestrom, vorhanden ist.
(Bislang wurde der Quality teilweise einfach gar nicht verschaltet, weil die anstehenden Störungen mehr störten, als sinnvoll nutzbar waren, wenn denn wirklich mal was gestört war)

Der Quality wird nun also nur durchgereicht, wenn er überhaupt die Chance hat sauber zu sein.
(In der Anlage stehen die Treiber dieser Rückmeldungen auch auf LAST_ON=1 ... der letzte gültige Stellungswert wird also weiter angezeigt, sobald die Messung aussteigt)
Ist und bleibt ein Kompromiss.

Eine andere Idee war, die Eingangstreiber der Rückmeldungen einfach auf Simulation zu nehmen, sobald die Antriebe Spannungslos werden.
Der V hätte auf SIM_V zurück geführt werden können - durch LAST_ON=1 würde dann wenigstens der letzte gültige Wert als Simulationswert angezeigt.
...hat so auch wieder Vor- und Nachteile...

Konzeptionell könnte man jetzt wieder sinnlose Diskussionen starten, wieso diese Antriebe überhaupt stromlos geschaltet werden, da landen wir aber wieder beim Kampf gegen Windmühlen. Es gibt Gründe dafür und dagegen...et is, wie et is - man versucht nun das Beste draus zu machen.

Das alles wollte ich aber gar nicht weiter ausführen und durchkauen - dafür gibt's vor Ort Leute, die fürstlich dafür entlohnt werden um Entscheidungen zu fällen....naja..

Vielen Dank für die Anregungen und Hilfestellung.
Kommt gut ins neue Jahr

 

[ducati]

Ja, Grundsatzdiskussionen zum Thema "Alarme" "Meldungsunterdrückung" "Folgemeldungen" "Alarm-Meldungen die im Normalbetrieb anstehen" ist ein leidiges Thema. Immer und überall...

Die funktionslosen Stellungsrückmeldungen stören dann im Bild und in der Fehlerliste -

Naja, im Bild würde ich schon anzeigen dass die wirkliche Position nicht bekannt ist... Für die Alarmliste würd ich die Meldung allerdings sperren. Aber das ist meine hochbezahlte Meinung

 

[FoodFighter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, im Bild würde ich schon anzeigen dass die wirkliche Position nicht bekannt ist... Für die Alarmliste würd ich die Meldung allerdigs sperren. Aber das ist meine hochbezahlte Meinung

Auch hier stimme ich persönlich (und einige Jungs aus der Wartung) zu...ABER...
Hier wurde abgewägt und man kam (traurigerweise) zu dem Schluss, dass die Anlagenbediener teilweise so wenig mit der Materie vertraut sind, dass man befürchtet, wenn da ständig 14 Messungen in einem Bild gestört angezeigt werden, weil die Antriebe eben stromlos sind, ignorieren die Bediener irgendwann die Messungen, die wirklich gestört sind und melden diese dem Wartungspersonal nicht mehr.
Die Einstellung der Bediener, der Vorgesetzten, die diese dulden usw. usf. wäre dann der nächste Angriff auf Windmühlen, der nur wieder bei der traurigen Realität endet, dass Ehrgeiz, Eigeninitiative und Verbundenheit mit seinem Betrieb/der Anlage scheinbar aus der Mode kommen.
(Ich erwische mich zunehmend selbst, wie ich vieles leider nur noch kopfschüttelnd und schulterzuckend hinnehme um meinen Blutdruck im Zaum zu halten...kennt hier vermutlich jeder.)