AWL nach SCL convertieren

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo ...!

Differenz := Neuer_Wert - Alter_Wert ;
Alter_Wert := Neuer_Wert ;

Erst wird die Differenz gebildet ... dann der Wert überschrieben ...

 

[zotos]

Ich habe das mit dem Zeilen vertauschen zwar zitiert... aber als ich es gelesen hatte war es noch nicht editiert ;o)

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Tut mir leid ... aber als mir auffiel, was ich da geschrieben hatte, wollte ich deshalb keinen neuen Beitrag machen ...
Lieber dann das Richtige schreiben ...

 

[gravieren]

L Alter_Wert Alter_Wert --> Akku 1
L Neuer_Wert Neuer_Wert --> Akku 1 Alter_Wert --> Akku 2
T Alter_Wert Akku 1 --> Alter_Wert

Die Anweisung sollte heissen Alter_Wert := Neuer_Wert (In dieser Reihenfolge)





TAK Akku 1 und Akku 2 tauschen --> Akku1=Alter_Wert Akku2=Neuer_Wert

-I
T Differenz

Anweisung: Differenz := Neuer_Wert - ALter_Wert



Oder wo habe ich einen Denkfehler ?

 

[Larry Laffer]

@Karl:
die Differenz wir von dem alten "Alten Wert" und dem neuen Wert gebildet ...
So habe ich es jedenfalls gesehen ...

@Zotos:
SPO heißt "Springe bei Überlauf" (also bei INT bei 32767) ...
Das wäre auch kein Problem für SCL ...

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
Lieber dann das Richtige schreiben ...

Dann solle man das auch mal machen:

Differenz := Neuer_Wert - Alter_Wert;
Alter_Wert := Neuer_Wert;

Ihr habt ja recht das der alte Wert vom neuen abgezogen wird.

Aber das überschreiben des alten Werts mit dem neuen muss nach die Differenzbildung.

 

[gravieren]

Wie ist es jetzt richtig ?

Muss ich erst meinen SCL-Compiler starten ?

 

[Larry Laffer]

... jetzt wollte ich gerade was Schlaues schreiben ... aber ich weiß es nun auch nicht mehr ...

@Karl:
raus mit dem SCL-Compiler ...!

Edit:
Ich bleibe bei meiner Variante, weil nur die Sinn machen würde ...

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... die Frage ist natürlich auch noch ...
Macht der Brocken, den uns Kermit hingeworfen hat, so überhaupt Sinn ...?

 

[gravieren]

FUNCTION_BLOCK FB100
VAR
  Differenz  : INT;
  Alter_Wert: INT;
  Neuer_Wert: INT;  
END_VAR
BEGIN
Alter_Wert := Neuer_Wert;
Differenz := Neuer_Wert - Alter_Wert;
END_FUNCTION_BLOCK

ergibt:

      L     #Neuer_Wert
      T     #Alter_Wert
      L     #Neuer_Wert
      TAK   
      -I    
      T     #Differenz

 

[Larry Laffer]

... das Beispiel sah aber so aus :

L Alter_Wert
[COLOR=red][B][U][COLOR=magenta]L[/COLOR][/U] [/B]Neuer_Wert[/COLOR]
[COLOR=red][B][U][COLOR=magenta]T[/COLOR][/U][/B] Alter_Wert[/COLOR]
TAK
-I
T Differenz

sorry Karl ...

 

[gravieren]

Zuviel Werbung?
-> Hier kostenlos registrieren

Stimmt.

Mein SCL erzeugt ihn aber so.


Ich bin der Meinung, das ist der gleiche Code ! ?

Der AWL-Code des SCL-Compilers ist auch irgendwie "lesbarer"/logischer.

(UPS, hoffentlich habe ich hier nicht einen Glaubenskrieg ausgelöst )


Wenn der Code vorher mit einem SCL-Compiler erzeugt wurde, stimmt das ergebnis. (Codegleich)

 

[gravieren]

Setzen wir doch mal Werte ein, und wir vergleichen das Ergebnis.


Ich mache es in SCL, du in AWL.


Gib doch mal Werte vor.

 

[Larry Laffer]

ich habe jetzt mal die Original-Variante und meine Version (Idee) in einen Baustein eingebaut. Meine Version erzeugt natürlich nicht den ursprünglichen Code (ist das nötig ?). Ich spiele das jetzt mal ins PLCSim und sehe mal was heraus kommt. Ach ja, deine Variante packe ich auch mal mit dazu ...

Ich möchte es jetzt auch einfach nur wissen ...

 

[gravieren]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Larry Laffer

Meine Version erzeugt natürlich nicht den ursprünglichen Code (ist das nötig ?).

Nein, es ging um AWL nach SCL und NICHT um Codegleichheit.

Ich spiele das jetzt mal ins PLCSim und sehe mal was heraus kommt. Ach ja, deine Variante packe ich auch mal mit dazu ...

Schon fertig ?
Bin gespannt wie ein "Flitzebogen"

Ich möchte es jetzt auch einfach nur wissen ...

Ich auch.

Sonst kann ich heute NICHT schlafen

 

[Larry Laffer]

Ergebnis:
Dein Werk bringt das gleiche Ergebnis, wie der Vorschlag von Kermit. Differenz=0, weil nach Transfer gebildet. Hier ist das Ermitteln der Differenz Unsinn.

Mein Werk funktioniert so, wie es für mich Sinn machen würde - nicht aber wie die Vorgabe ...!

 

[Larry Laffer]

Ach ja,
hat Spaß gemacht mit Euch (respektive dir, Karl) ...

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... und nochmal falsch gemacht ...
Ich hatte "Alter Wert" und "neuer Wert" oben am Kopf zugewiesen. Das war der Fehler ... somit Korrektur :
Mein Werk bringt das gleiche Ergebnis, wie der Vorschlag von Kermit. Es sieht aber vom SCL-in-AWL-Code nicht aus wie das Original ...

 

[kermit]

... die Frage ist natürlich auch noch ...
Macht der Brocken, den uns Kermit hingeworfen hat, so überhaupt Sinn ...?

Hat mich gefreut, Euch einen so vergnüglichen Sonntag-Nachmittag bereitet zu haben.

Zum Sinn meiner Code-Schnipsel: diese kommen recht regelmäßig in meinen Programmen vor. Das mit Alter_Wert und Neuer_Wert habe ich oft, wenn ich z.B. den Bewegungsfortschritt von Drehgebern rechne. Aber z.B. auch, um die Zeitdifferenz zwischen zwei SFC64-Aufrufen zu berechnen. Dadurch, dass ich nur einen Zugriff auf die Datenquelle hab (L Neuer_Wert), brauche ich mir z.B. bei PEW o.dgl. keine Gedanken darüber zu machen, ob sich der Wert zwischenzeitlich geändert haben könnte, wenn ich ihn als Alter_Wert speichere. Wenn also die Übersetzung in SCL dazu führt, dass der "L Neuer_Wert" dann zweimal als Code auftaucht, so habe ich bei einem Operanden im PEW-Bereich ein sporadisches Problem (liebe Grüße an kiestumpe, der gerade in einem anderen Thread so treffend schrieb: "der erfahrene Benutzer weiß, warum").

Der nächste Schritt ist, diesen Zeit- oder Wegfortschritt wieder irgendwo aufzusummieren. Ggf. in mehreren Zählern oder Teilprozessen, um schon mal der Gegenfrage zu begegnen, warum erst Differenzbildung und dann wieder aufsummieren Das ist der Codeschnipsel mit dem SPO-Befehl. IdR. ist es angeraten, den jeweiligen Zähler, sofern er den Endwert erreicht (oder einen Wert kurz davor), dort anzuhalten und den Überlauf nicht zuzulassen.

 

[Larry Laffer]

@Kermit:
Sowohl Gravieren wie auch ich haben deinen PEW als Input einer Funktion bzw. eines FB's betrachtet. Hier relativiert sich deine Anmerkung, denn egal, wie oft ich einen IN-Parameter in einer FC (oder einem FB) aufrufe, es wird nur auf die übergebene Variable zugegriffen - nicht auf das PEW, wenn das der Übergabe-Parameter gewesen wäre.
Falls dieses Code-Schnipsel öfters in deinem Programm(en) Verwendung findet, so würde ich schon aus Gründen der Übersichtlichkeit hier auf ein Unter-Programm zugreifen.
In gleicher Weise säh das (bei mir) mit einem Eigenbau-Zähler aus ...
An dieser Stelle würde ich ggf. sogar beide Sachen zusammenziehen (wenn sie sowieso schon zusammengehören) um mir von der Funktion das Endergebnis als OUT liefern zu lassen. (Spart Code und erhöht definitiv die Übersichtlichkeit ...)

Zu deinem Bezug auf den anderen Thread habe ich in demselben zu dem Thema bereits meine Meinung dargestellt.

Gruß
LL