Step 7 STEP7 XOR mit mehr als 2 Eingängen

Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Harald!
Ich stolpere gerade über Deinen Beitrag zum Thema "xor-mit-mehr-als-2-eingaengen"
In SPS gibt es überhaupt nur XOR mit 2 Eingängen ...
... aber in FUP freundlicherweise zu einem XOR-Block zusammengefasst werden ...
... XOR mit mehr als 2 Operanden werden z.B. zur Generierung von Paritätsbits verwendet ...
Zu diesem Thema wird leider viel Unsinn geschrieben. Deine Beschreibung ist die solideste, die ich bisher gesehen habe.
Ich möchte jetzt noch eins draufsetzen und versuche zu erklären, warum die Angelegenheit immer wieder VerständnisSchwierigkeiten bereitet.
Das Exclusiv-Oder (auch Antivalenz oder XOR genannt) ist klar definiert, aber nur für 2 Eingänge!
Im dualen System, in dem die Eingänge nur einen von zwei Zustanden annehmen können (0 oder 1, true oder false, ...), kann es keine XOR-Verknüpfung mit mehr als 2 Eingängen geben!
Schon drei Eingänge können nie alle unterschiedlich sein, wenn nur die Zustände 0 und 1 zur Verfügung stehen. Eine XOR-Verknüpfung mit drei oder mehr Eingängen hätte damit immer am Ausgang eine 0 bzw. false.
Eine Verknüpfung, die am Ausgang immer nur 0 liefert, braucht niemand. Also: XOR ist nur mit 2 Eingängen sinnvoll.
Anders sieht es mit der UmkehrFunktion "Äquivalenz" (manchmal auch XNOR genannt) aus. Diese ist durchaus auch bei mehr als zwei Eingängen sinnvoll, da ohne weiteres alle Eingänge gleichermaßen 0 oder alle gleichermaßen 1 sein können.
Folglich: Die Welt ist nur in Ordnung, wenn man von XOR mit 2 Eingängen spricht und nur dann ist auch XNOR die UmkehrFunktion von XOR.
XOR mit mehr als zwei Eingängen gibt es nicht! Was uns aber nicht davon abhält oder abhalten sollte, mehrere XOR-Verknüfpungen zu kaskadieren - die sind durchaus sinnvoll (Parity, GRAY in DUAL Konvertierung, "WechselSchaltung" --> "KreuzSchaltung", ... )
Völlig irreführend ist es allerdings, solche Kaskadierungen als XOR-Verknüpfung zu bezeichnen - sie verwenden zwar XOR-Verknüpfungen, stellen aber keine XOR-Verknüpfung dar.
Viele haben dieses Dilemma erkannt ... und verstehen deshalb die Welt nicht mehr. Und viele trauen sich nicht so recht, XOR anzuwenden. Sehr schade! Ist eigentlich eine sehr "interessante" Verknüpfung (z.B. "StromStossRelais", bedingtes Invertieren, ...), solange man weiss, was man tut und nicht alles glaubt, was darüber geschrieben wird.

Gruss, Heinileini

PS: Wem die Begriffe "WechselSchaltung" und "KreuzSchaltung" etwas sagen, der hat es vielleicht ein wenig leichter, das Dilemma beim Sprung von 2 auf 3 Eingänge nachzuvollziehen, ohne dadurch verwirrt zu werden!?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Harald!
Apropos
... beim Elektronikbasteln mit 7486
... der 74LS286 war auch nübel (= nicht übel) mit seinen open collector Ausgängen (die ich bei anderen Gattern eher gemieden habe).
Es gab damals auch keine "XOR" mit mehr als 2 Eingängen! Nur AND, OR, NAND, NOR gab's auch mit 3, 4 oder sogar 8.
Es gab auch die Parity-Dinger, die hiessen aber richtigerweise nicht "XOR".

Gruss, Heinileini
 
Zuletzt bearbeitet:
Hallo zusammen,

ich bräuchte mal eure Hilfe.
Passend zum Thema muss ich 14 Eingänge abfragen und das Ergebnis darf nur TRUE sein wenn einer dieser 14 Eingänge TRUE ist.
Dazu müssten die XOR eigentlich kaskadiert werden, das wiederum gibt aber ein riesiges Netzwerk bzw. eine riesige Anweisung, je nachdem welche Darstellungsform gewählt wird und verschlechtert die Übersichtlichkeit. Die Eingänge sind quer über DI-Karte verteilt, sodass eine blockweise Auswertung wie auch immer die ausgesehen hätte nicht in Frage kommt.

Die Frage ist nun gibt es da eine Elegantere Lösung als die Kaskadierung?

Software ist Step7 Professional V5.5 das Programm läuft nachher auf ner 314er CPU.

Gruß Micha
 
Passend zum Thema muss ich 14 Eingänge abfragen und das Ergebnis darf nur TRUE sein wenn einer dieser 14 Eingänge TRUE ist.
Dazu müssten die XOR eigentlich kaskadiert werden, das wiederum gibt aber ein riesiges Netzwerk bzw. eine riesige Anweisung, je nachdem welche Darstellungsform gewählt wird und verschlechtert die Übersichtlichkeit. Die Eingänge sind quer über DI-Karte verteilt, sodass eine blockweise Auswertung wie auch immer die ausgesehen hätte nicht in Frage kommt.

Die Frage ist nun gibt es da eine Elegantere Lösung als die Kaskadierung?
XOR-Kaskadierung ist leider nicht der richtige Ansatz. Eine blockweise Auswertung dürfte wohl doch einfacher sein. "Quer über DI-Karte verteilt" sind wieviele Bytes? 4 oder 8?
DW in Akku laden, die relevanten Bits maskieren.
In Schleife bis Akku=0 nach rechts schieben und die herausgeschobenen Bits=1 zählen. Kann abgebrochen werden, sobald das 1. Bit=1 festgestellt wird und der Akku>0.
Habe noch einen anderen Ansatz im Hinterkopf (mit XOR), aber jetzt keine Zeit, darüber nachzugrübeln. Melde mich ggfs nochmal.
Gruss, Heinileini
 
Passend zum Thema muss ich 14 Eingänge abfragen und das Ergebnis darf nur TRUE sein wenn einer dieser 14 Eingänge TRUE ist.
Das passt nicht zum Thema weil das mit XOR nicht geht (bzw. nur extrem aufwendig).

Ich würde die Bits in ein Word eintragen und dann das Word en bloc testen, ob genau 1 Bit oder mehr als 1 Bit TRUE ist. Dafür gibt es uralte bewährte :cool: und auch mysteriöse ;) Algorithmen. Schau mal HIER und lies auch mal den ganzen Thread vom Anfang an.

Harald
 
... Habe noch einen anderen Ansatz im Hinterkopf (mit XOR), aber jetzt keine Zeit, darüber nachzugrübeln. Melde mich ggfs nochmal.
Sooo, ich glaub', jetzt habe ich's:
Code:
[FONT=courier new]     L    TestVariable   (DWORD oder WORD oder BYTE)
[COLOR=#0000ff]     L    BitMaske       (ggfs die irrelevanten ...)
     UD                  (... Bits ausblenden)
[/COLOR]     PUSH 
     NEGD 
     UD                  (liefert nur das niederwertigste Bit=1)
     ==D                 (wenn identisch mit dem zu testenden BitMuster, ...)
     =    OneBitOnly     (... enthält auch das zu testende BitMuster nur eine 1)[B][I][U][SUB][/SUB][/U][/I][/B][/FONT]
Die beiden blauen Zeilen entfallen, wenn alle geladenen Bits (maximal 32) getestet werden sollen.
Hat aber nichts mit XOR-Verknüpfung zu tun, wie ich fälschlicherweise angekündigt hatte.

Oder indirekt vielleicht doch? Siehe folgende Erklärung, die ich bei Wikipedia gefunden habe:
"Trick zur schnelleren Umwandlung (einer negativen in eine positive Binärzahl oder umgekehrt) von Hand: Von rechts angefangen, alle Nullen und die erste Eins abschreiben und alle nachfolgenden Stellen invertieren."

@Harald: Die Umwandlung in eine RealZahl, bei der die Mantisse (sofern ungleich 0) solange nach links verschoben wird, bis die erste 1 an der höchstwertigen Position erscheint und dann um noch 1 Bit-Position weiter nach links, damit sie wieder verschwindet ... das ist schon genial!
Diese Art, REAL-Zahlen "intern" darzustellen, ist mir zwar geläufig, aber seit wann wird sie bei Siemens-PLCs angewendet? Das habe ich wohl irgendwie verschlafen ;o(

Gruss, Heinileini

PN/DP hat mich darauf aufmerksam gemacht, dass ich geschludert hatte! Hier die Korrektur:
Code:
      L    TestVariable
[COLOR=#0000ff]      L    BitMaske       //ggfs die irrelevanten ...
      UD                  //... Bits ausblenden)
[/COLOR]      PUSH
      NEGD
      UD                  //liefert nur das niederwertigste 1-Bit
      ==D                 //wenn identisch mit dem zu testenden BitMuster, ...
      =    OneBitMax      //... enthält auch das zu testende BitMuster höchstens eine 1

      L    0
      <>D
      U    OneBitMax      //wenn ungleich 0 ...
      =    OneBitOnly     //... enthält das zu testende BitMuster genau eine 1
Besten Dank Harald, für die vielen Varianten, die Du vorgeschlagen hast - eine schöner, als die andere!
Ich habe mich schweren Herzens zu der obigen durchgerungen, weil sie ...
- zwei verschiedene Ergebnisse liefert - man muss sich nur noch für eins von beiden entscheiden ;o)
- auf Tricks verzichtet, die den "gestressten Leser" verwirren könnten
- fast S5-kompatibel ist (bis auf den PUSH - den könnte man z.B. durch L KB0 und OD ersetzen)
 
Zuletzt bearbeitet:
Zurück
Oben