TIA Word auf >= vergleichen nicht möglich. (Nur ==)

TIA_TESTER

Level-1
Beiträge
103
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich würde gern zwei WORD miteinander vergleichen auf GrößerGleich....

Leider kann ich in FUP nur bei == und <> als Format WORD auswählen.

Kann mir jemand erklären wieso ich nicht auf > oder >= vergleichen kann?

Irgendwie sehe ich kein Grund warum es nicht geht. Jedes Word ist doch auch eine bestimmte Dezimalzahl. bei INT funktioniert es ja auch,.. und der Aufbau ist bis auf das Vorzeichenbit das selbe.

Danke Gruß TT
 
Ein WORD ist keine Dezimalzahl sondern einfach nur eine Ansammlung von 16 Bits. Deshalb kann man mit WORD nicht rechnen und auch nur vergleichen, ob kein oder irgendein Bit gesetzt ist.

Willst du rechnen, dann benutze INT oder konvertiere/kopiere das WORD in eine INT-Variable.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein WORD ist keine Dezimalzahl sondern einfach nur eine Ansammlung von 16 Bits. Deshalb kann man mit WORD nicht rechnen und auch nur vergleichen, ob kein oder irgendein Bit gesetzt ist.

Willst du rechnen, dann benutze INT oder konvertiere/kopiere das WORD in eine INT-Variable.

Harald

Danke Harald,

ich mache/möchte folgendes:

ich habe 16 Meldungen auf 16bit geführt. Das alles ist am Ende halt ein komplettes word.

Jetzt würde ich gern ein einziges bit setzten, falls irgend eins oder mehrere dieser Bits in einem Zyklus von 0 zu 1 wird. Ich dachte ich vergleich einfach den Dezimalwert des word aber das geht ja nicht.

Wenn ich allerdings in INT kopiere ist das letzte Bit doch fürs Vorzeichen und falls dieses Dazukommt wird mein Dezimalwert geringer? Oder bin ich jetzt komplett durcheinander,..

GrußTT
 
Siehst Du, wie Du selbst bemerkst, würde das größer/kleiner-Vergleichen bei Deiner Bitsammlung sowieso nicht funktionieren. Außerdem können im selben Zyklus Bits kommen und andere Bits gehen.

Du mußt einfach nur Vergleichen, ob ein Bit dazugekommen ist, also im letzten Zyklus 0 war und jetzt 1 ist --> die klassische Flankenerkennung, allerdings gleich für 16 Bit auf einmal. Dafür gibt es WORD-Verknüpfungs-Operationen. Und sogar einen FAQ zur wordweisen Flankenauswertung.

In AWL könnte Dein Code etwa so aussehen:
Code:
L Word_vorher
INVI
L Word_jetzt
T Word_vorher
UW
U <>0
= Bit_dazugekommen
S Meldebit

Harald
 
Ich hab mir das mal auf ein Zettel gemalt und muss mich bei dir bedanken!

Für den Link und den Code. Sehr einfach wenn man es verstanden hat und funktionieren tut es auch noch. Es werden nur Positive Flanken erkannt... DANKE
 
Zuviel Werbung?
-> Hier kostenlos registrieren
und funktionieren tut es auch noch.
Ja, geniale Lösungen sind meistens einfach :D

Du hast aber auch noch genug damit zu tun, es in (TIA-)FUP zu übersetzen. Da mußt Du die Operationen umstellen, was aber einfach ist, da Du das Prinzip verstanden hast.

Harald
 
Hallo nochmal,

hab jetzt nochmal ein wenig die Dualzahlen aufgearbeitet und komm Grundsätzlich klar denke ich. Was man alles vergisst was eigentlich 2/3 Klasse ist... unfassbar.

Woher kommt dein
Code:
U <>0

Das Ergebnis der WORD-UND-Verknüpfung ist in Akku1, ich hätte jetzt eine 0 geladen [(Akku1), vorheriges Ergebnis wandert in (Akku2)] -> und auf ungleich verglichen. :S

Mag sein das es geht, meine Frage ist nur wie kommst du auf "U <>0" ? In der Liste der Funktionen ist es nicht dabei (wie sicher manch anderes). Nur mit Angabe einer Interpretierung der AKKUS-> I, D, R...

Wenn ich in AWL eine Zahl lade. Kann ich einfach "L 3423423" schreiben, oder bedarf es eines Zusatzes für die richtige Interpretierung?

Danke GrußTT
 
Zuletzt bearbeitet:
Siehe hierzu: TIA-Hilfe -> Index -> "Statuswort" -> Doppelklick drauf -> Dann "Grundlagen zum Statuswort"
Grundlagen zum Statuswort schrieb:
Beschreibung
Das Statuswort fasst Statusbits zusammen, die die CPU zur Steuerung der binären Verknüpfungen verwendet und bei der digitalen Bearbeitung setzt.
Sie können die Statusbits abfragen und gezielt beeinflussen.
Das Statuswort ist ein Wort innerhalb des Betriebsystems der SPS das folgende Bits enthält:

  • OS (Überlauf speichernd)
  • OV (Überlauf)
  • A0 und A1 (Auskunft über das Ergebnis verschiedener Anweisungen)
  • BIE (Binärergebnis)
  • VKE (Verknüpfungsergebnis)

In dem Fall geht es um die Bits A0/A1.
Das Ergbnis der UW-Funktion (und anderer) beeinflusst diese automatisch.
Ein Ergebnis "ungleich null" führt dazu dass die Bits A0/A1 entweder 1/0 oder 0/1 sind.
Mit U <>0 wird die Ungleichheit dieser Bits geprüft und somit wird auch geprüft ob der vorherige Ergebnis von UW "ungleich 0" war.

Es gibt noch weitere Befehle mit denen diese Statusbits abgefragt werden könnten. Siehe dazu den Artikel "Abfragen der Statusbits mit Bitverknüfungsanweisungen"
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Woher kommt dein
Code:
U <>0

Das Ergebnis der WORD-UND-Verknüpfung ist in Akku1, ich hätte jetzt eine 0 geladen [(Akku1), vorheriges Ergebnis wandert in (Akku2)] -> und auf ungleich verglichen. :S
Das UW setzt schon die Status-Flags A0 und A1 entsprechend dem Ergebnis der Operation (quasi ein integrierter Vergleich auf 0), ein nachfolgender Vergleich auf 0 ist eigentlich unnötig, macht den Code aber manchmal besser verstehbar.

Die Statusflags A0 und A1 kann man direkt abfragen in AWL/KOP/FUP mit U/UN/O/ON/X/XN <>0/==0/>=0/<=0/>0/<0
Siehe AWL-Hilfe "Abfragen des Zustands der Bits im Statuswort" bzw. Stichwort "Ergebnisbit" bei KOP/FUP

Ob und welche Statusflags eine Operation beeinflußt, findet man in der Online-Hilfe zur Operation (AWL/KOP/FUP). (Eine entsprechende Hilfe sollte es auch in TIA geben.)


In classic-AWL muß man bei positiven DINT-Konstanten keinen Zusatz L#... schreiben - wenn die Zahl > 32767 ist, dann wird L# automatisch ergänzt. Bei FUP/KOP wird der erforderliche Datentyp meist aus der Operation erkannt. Bei positiven Zahlen ist es übrigens egal, ob man Konstanten als 8-, 16- oder 32-Bit-Wert in den AKKU lädt. Die nicht angegebenen Bits/Bytes werden beim L automatisch auf 0 gesetzt.

Bei negativen Konstanten MUSS man L#... angeben, wenn der DINT-Wert auch in INT passen würde, weil -1 und L#-1 nicht das selbe ist. Ohne Angabe von L# würden die oberen 16 Bit im AKKU auf 0 gesetzt werden, bei DINT müssen die aber 1 sein.

Harald
 
Zurück
Oben