Step 7 Ausgang triggern, wenn sich der Zählerwert erhöht

[aliksander1612]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe folgendes vor: Ich habe einen Zähler aus der HMI, der durch NC-Variablen getriggert wird und somit hochzählt. Jetzt möchte ich einen Funktionsbaustein (FB) erstellen, bei dem ich auf der Eingangsseite das Datenwort des Tageszählers eintragen kann. Jedes Mal, wenn sich der Zählerwert um 1 erhöht, soll am Ausgang des FB ein Ausgang getriggert werden. Optimalerweise sollte man diesen Ausgang dann zeitlich anpassen können, etwa im Bereich von 100 bis 300 ms.

Könnt ihr mir da kurzfristig Anhaltspunkte geben, wie ich so etwas in AWL oder KOP umsetzen könnte? Die Steuerung, die ich verwende, ist eine S7-300 Klassik.

Vielen Dank im Voraus!

 

[Nordischerjung]

Moin,

Netzwerk 1: Vergleiche Dein Dint auf > mit gespeicherter Variable von Deinem DINT das auf ein P_Trig und ab auf einen TOF, dieser TOF schaltet dein Output.
Netzwerk 2: MOVE dein DINT auf gespeicherter Variable von Deinem DINT (Static VAR)

die Variablen legst du dann so wie du sie möchtest als In oder Out

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jedes Mal, wenn sich der Zählerwert um 1 erhöht, soll am Ausgang des FB ein Ausgang getriggert werden.

Nur wenn der Wert sich um genau 1 erhöht oder bei jeder Änderung? Also auch mehr als 1? Und wenn er sich verringert?

 

[aliksander1612]

Also verringern sollte nicht passieren da es sich ja um einen Stückzahl Gesamt Zähler handelt, aber wahrscheinlich wäre bei jeder änderung einfach die bessere variante

 

[Januar]

Moin,

Netzwerk 1: Vergleiche Dein Dint auf > mit gespeicherter Variable von Deinem DINT das auf ein P_Trig und ab auf einen TOF, dieser TOF schaltet dein Output.
Netzwerk 2: MOVE dein DINT auf gespeicherter Variable von Deinem DINT (Static VAR)

die Variablen legst du dann so wie du sie möchtest als In oder Out

Das P_Trig kannst du dir an der Stelle auch sparen.

Durch den Vergleich und die nachfolgende Zuweisung wird sowieso erreicht, dass der Vergleich (generell auf <>) ein TRUE liefert, wenn es einen Zählerwert gibt, der sich vom Zählerwert des letzten Zyklus unterscheidet. Demnach ist das P_Trig vielleicht sogar kontraproduktiv, wenn es in mehreren aufeinander folgenden Zyklen zu Wertänderungen kommt.

Zyklus 1: Zähler 1, vorher 0 → True
Zyklus 2: Zähler 2, vorher 1 → True
Zyklus 3: Zähler 3, vorher 2 → True
Zyklus 4: Zähler 3, vorher 3 → False

Mit dem P_Trig würde der Zählerwechsel nur in Zyklus 1 erkannt werden.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das P_Trig kannst du dir an der Stelle auch sparen.
(...)
Demnach ist das P_Trig vielleicht sogar kontraproduktiv, wenn es in mehreren aufeinander folgenden Zyklen zu Wertänderungen kommt.

Sehe ich auch so.
Der P_Trig macht im Grunde auch nichts anders als Vergleich Neuwert mit Altwert und dann Neuwert als Altwert speichern. Nur das Ergebnis ist da noch richtungsabhängig.

Also verringern sollte nicht passieren da es sich ja um einen Stückzahl Gesamt Zähler handelt, aber wahrscheinlich wäre bei jeder änderung einfach die bessere variante

Da sollte man etwas drüber nachdenken. Es gibt keine Endlos-Zähler. Jeder Zähler läuft irgendwann mal über oder wird sogar absichtlich zurückgesetzt. Dabei wird der Neuwert kleiner als der Altwert. Überlaufen soll vermutlich sinnvollerweise einen Impuls liefern, aber absichtlich rücksetzen des Wertes auch?
Weiters: wie wird der Zählerwert übertragen? Kann es da Unterbrechungen geben und der Wert wird dabei womöglich 0?

 

[aliksander1612]

Stimmt hast du vollkommen recht also der Bediener kann ja den Zähler auch wieder zurücksetzten also auf 0 schreiben das sollte man vielleicht auch noch in Betracht ziehen

 

[PN/DP]

Wie "wichtig" ist der erzeugte Puls? Ist das schlecht, wenn da einer zuviel erzeugt wird?
Oder kann man das Rücksetzen des Zählerstandes organisatorisch so legen, dass zu der Zeit eventuelle Pulse automatisch ignoriert werden können, z.B. nur Zählerstand rücksetzen wenn die Anlage gestoppt oder Aus ist?
Überlauf kann man verhindern, wenn der Zähler groß genug ausgelegt wird (Ganzzahl DINT, LINT - aber nicht REAL, LREAL!) und vor einem möglichen Überlauf sicher schon vorher der Zählerstand rückgesetzt wurde.

 

[Januar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Alternativ lässt sich der Impuls auch unterdrücken, indem noch die Abfrage "Zählerwert <> 0" hinzugenommen wird.

 

[Onkel Dagobert]

Man könnte beim Zurücksetzen auch beide Zählrstände auf Null setzen.

 

[aliksander1612]

Also der Impuls sollte immer dann für die eingestellte Zeit kommen wenn der Zähler am Eingang hochzählt, wäre schon gut wenn der Impuls dann genauso häufig kommt wie der Zähler in einer bestimmten Uhrzeit an teilen gezählt hat. Also überlaufen kann der Zähler am Eingang nicht bzw. dafür bin ich nicht verantwortlich. Ich habe jetzt Größer gleich als Vergleicher genommen und wenn er dann zurückgesetzt wird auf 0 dann kommt der Trigger auch 1x nicht bis das nächste Bauteil gefertigt wird, so wollte ich das eigentlich auch

 

[Januar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie lange ist denn die eingestellte Zeit? Hast du dir darüber Gedanken gemacht, was passieren soll, wenn innerhalb der eingestellten Zeit der Zähler erneut hochzählt?

 

[PN/DP]

Ich habe jetzt Größer gleich als Vergleicher genommen

??? Dann käme der Ausgang auch, wenn der Zählerstand sich gar nicht ändert. Der Impuls wäre ein Dauer-Signal.

und wenn er dann zurückgesetzt wird auf 0 dann kommt der Trigger auch 1x nicht bis das nächste Bauteil gefertigt wird,

Wo fehlt das Komma bzw. wie ist das gemeint?
Bei Vergleich "größer" ist automatisch dabei, dass beim Rücksetzen auf 0 kein Impuls kommt.

Also die Lösung von #2 ohne P_Trig wäre schon passend.

 

[PN/DP]

Wie lange ist denn die eingestellte Zeit? Hast du dir darüber Gedanken gemacht, was passieren soll, wenn innerhalb der eingestellten Zeit der Zähler erneut hochzählt?

Vermutlich kann so schnell (in weniger als 1s) gar nicht mehr als 1 Stück kommen/hergestellt werden.

 

[aliksander1612]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also, den Trigger für den Ausgang muss ich individuell an die Taktzeit der Maschine anpassen. Wenn ich jetzt 10 Sekunden nehme und die Taktzeit 8 Sekunden beträgt, dann kommt das Signal selbstverständlich nur einmal. Als Vergleicher habe ich den CMP > D, und der vergleicht ja an einem Eingang den aktuellen Wert mit dem gespeicherten und setzt daraufhin die Flanke. Im nächsten Netzwerk habe ich den TOF und im letzten wird vom aktuellen Zählwert auf den gespeicherten überschrieben.

Wie gesagt, es scheint erst einmal alles zu funktionieren. Die Maschinen variieren in der Taktzeit, aber keine ist im Millisekundenbereich. Ich möchte nur sicherstellen, dass ich ein Signal auf jeden Fall erhalte und es nicht aufgrund einer Zykluszeit-Überschneidung verloren geht.

 

[021aet04]

Für was benötigst du die Flanke eigentlich. Benötigst du das TOF?

MfG Hannes

 

[PN/DP]

Der TOF ist eine klassische Signalverlängerung.

Die Flankenerkennung wird aber nicht benötigt (die steckt quasi schon im Vergleich >D und danach speichern des Wertes), die erfordert nur unnötigerweise, dass zwischen zwei Wertänderungen zwingend ein Zyklus ohne Wertänderung erfolgen muss. Das wurde bereits im Betrag #5 kritisiert. Also die Flankenerkennung (P-Trig) weglassen. Funktioniert dann besser.

 

[021aet04]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Flanke ist mir schon bewusst. Ich habe eher das Ausgangssignal gemeint, für was das Signal benötigt wird.
Das in dem Programmteil keine extra Flankenerkennung nötig ist, das weiß ich.

In #15 steht: "Ich möchte nur sicherstellen, dass ich ein Signal auf jeden Fall erhalte und es nicht aufgrund einer Zykluszeit-Überschneidung verloren geht."

Das hört sich für mich so an als ob das TOF weglassen könnte. Außer es sind Zykluszeitüberschneidungen von verschiedenen Steuerungen gemeint. Deswegen meine Nachfrage.

Das mit der Flanke war etwas schlecht von mir ausgedrückt.

MfG
Hannes

 

[Heinileini]

Das hört sich für mich so an als ob das TOF weglassen könnte.

Das kann man sicherlich auch. Wenn man fehlende Logik im Programm oder fehlendes Handshake meint durch Timer und verlängerte Impulse "reparieren" zu können, dann ist mir das immer sehr suspekt.

Ich habe mich schon gewundert, dass niemand hier vorgeschlagen hat, die Differenz zwischen zwei aufeinanderfolgenden ZählerStänden zu bilden und auszuwerten.
- Differenz negativ: Zähler übergelaufen oder rückgesetzt.
- Differenz 0: keine Änderung.
- Differenz positiv: ZählerStand wurde erhöht und es ist nachvollziehbar, um wieviel er erhöht wurde. Man kann also auswerten, wieviele Erhöhungen (um 1) stattgefunden haben und wieviele man "übersehen" haben muss. Je nach Anwendung genügt letzteres, damit nichts aus dem Lot gerät?

 

[Onkel Dagobert]

Das kann man sicherlich auch. Wenn man fehlende Logik im Programm oder fehlendes Handshake meint durch Timer und verlängerte Impulse "reparieren" zu können, dann ist mir das immer sehr suspekt...

Ich nehme an, es soll am Ende so etwas wie eine S0-Schnittstelle entstehen. Und dann benötigt man schon einen Impuls mit definierter Länge.