# Impulse auswerten für Durchfluss-Berechnung



## DrumJoeyDrum (20 Februar 2019)

Hallo Zusammen,

ich habe an einer Wasseruhr einen Impulszähler, welcher mir *1 Impuls pro 100 Liter* gibt.

Jetzt bin ich in meiner *S7-300* hergegangen
und Zähle einfach mit, wie viele Impulse ich in 60 Sekunden (sprich pro Minute) erhalte.
Die erhaltenen Impulse/Minute multipliziere ich mit 100
und erhalte dann einen Durchfluss in Liter/Minute, welcher sich alle 60 Sekunden aktualisiert.

Das Problem ist jedoch jetzt das mein Durchfluss nur in 100er Sprüngen sich bewegt... das ist sehr ungenau.

Eine andere Wasseruhr, welche mir mehr Impulse ausgibt will ich eig. nicht verbauen.

Gibt es eine Möglichkeit in der SPS diese Bit-Eingabe von 1 Impuls pro 100 Liter schöner aufzuschlüsseln?


Danke im Voraus


----------



## MFreiberger (20 Februar 2019)

Moin DrumJoeyDrum,

aber 100 Liter ist doch Dein LSB (1Bit == 100 Liter). Das kannst Du nicht feiner aufschlüsseln.

VG

MFreiberger


----------



## DrumJoeyDrum (20 Februar 2019)

MFreiberger schrieb:


> Moin DrumJoeyDrum,
> 
> aber 100 Liter ist doch Dein LSB (1Bit == 100 Liter). Das kannst Du nicht feiner aufschlüsseln.
> 
> ...



habe ich befürchtet...


----------



## PN/PN (20 Februar 2019)

Da muss ich Mario zustimmen.


----------



## PN/DP (20 Februar 2019)

DrumJoeyDrum schrieb:


> Gibt es eine Möglichkeit in der SPS diese Bit-Eingabe von 1 Impuls pro 100 Liter schöner aufzuschlüsseln?


Zeige den Zählerstand nicht in Liter sondern in Kubikmeter (oder Hektoliter) an: "123.4 m³" (oder "1234 hl") sieht "schöner" aus als "123400 l" 

Harald


----------



## Onkel Dagobert (20 Februar 2019)

DrumJoeyDrum schrieb:


> .. Zähle einfach mit, wie viele Impulse ich in 60 Sekunden (sprich pro Minute) erhalte..
> .. Gibt es eine Möglichkeit in der SPS diese Bit-Eingabe von 1 Impuls pro 100 Liter schöner aufzuschlüsseln? ..



Messe die Zeit zwischen den Impulsen und rechne diese auf l/min um. Zusätzlich könnte man das Ergebnis noch dämpfen.


----------



## DrumJoeyDrum (21 Februar 2019)

PN/DP schrieb:


> Zeige den Zählerstand nicht in Liter sondern in Kubikmeter (oder Hektoliter) an: "123.4 m³" (oder "1234 hl") sieht "schöner" aus als "123400 l"
> 
> Harald




das bringt mir aber nur eine schöner Zahl...
habe ja dann immer noch Sprünge im bereich 1m3 (was 1000 Liter sind) 




Onkel Dagobert schrieb:


> Messe die Zeit zwischen den Impulsen und rechne diese auf l/min um. Zusätzlich könnte man das Ergebnis noch dämpfen.



kannst du mir das mal in ein AWL bzw. FUP-Programm packen?


----------



## PN/DP (21 Februar 2019)

DrumJoeyDrum schrieb:


> das bringt mir aber nur eine schöner Zahl...
> habe ja dann immer noch Sprünge im bereich 1m3 (was 1000 Liter sind)


Du schriebst, daß Du alle 100 Liter einen Impuls bekommst - also wird die m³-Anzeige "Sprünge" von 0.1 m³ machen, z.B. von 123.4 zu 123.5 m³. (Es sei denn, Du programmierst den Zähler ganz dämlich )
Du kannst "intern" die Impulse in einen Ganzzahl-DINT-Hektoliter-Zähler zählen und für die Anzeige in m³ den Wert in REAL wandeln und durch 10.0 teilen. (Oder in der Anzeige des DINT-Wertes einfach eine Stelle von hinten ein Dezimalkomma/-punkt einfügen)

PS: wie groß ist denn der Zeitabstand der 100l-Impulse? Wie groß ist die Durchflußgeschwindigkeit minimal und maximal?

Harald


----------



## DrumJoeyDrum (21 Februar 2019)

PN/DP schrieb:


> Du schriebst, daß Du alle 100 Liter einen Impuls bekommst - also wird die m³-Anzeige "Sprünge" von 0.1 m³ machen, z.B. von 123.4 zu 123.5 m³.



Richtig. Schreibfehler von mir. Aber es bleibt sich dennoch egal ob mein Zähler (meine Anzeige) in 100 Liter oder in 0,1m3 Sprüngen arbeitet - die Wassermenge ist die selbe 




PN/DP schrieb:


> wie groß ist denn der Zeitabstand der 100l-Impulse? Wie groß ist die Durchflußgeschwindigkeit minimal und maximal?



Im Bereich von 300-500l/min - sprich 3-5 Impulse pro Minute


----------



## DeltaMikeAir (21 Februar 2019)

> Richtig. Schreibfehler von mir. Aber es bleibt sich dennoch egal ob mein  Zähler (meine Anzeige) in 100 Liter oder in 0,1m3 Sprüngen arbeitet -  die Wassermenge ist die selbe :wink:


Da geht es eher um den psychologischen Faktor.


----------



## PN/DP (21 Februar 2019)

DrumJoeyDrum schrieb:


> PN/DP schrieb:
> 
> 
> > wie groß ist denn der Zeitabstand der 100l-Impulse? Wie groß ist die Durchflußgeschwindigkeit minimal und maximal?
> ...


Bei so wenig Impulsen pro Minute ist es für die Auflösung des Messwertes in der Tat günstiger, den Zeitabstand zwischen den Impulsen zu messen (also die Periodendauer), so wie Onkel Dagobert schon empfohlen hat. Und wenn z.B. 1 Minute lang kein Impuls kam, dann setze den Anzeigwert auf 0 l/min. Netter Nebeneffekt: Du bekommst schon früher als nach 1 Minute einen neuen Meßwert. Falls Dir der Meßwert noch zu doll "springt", dann kannst Du den Wert noch glätten, z.B. den Meßwert alle 15 Sekunden abtasten und den Mittelwert der letzten 4 Abtastungen bilden.

Für die Zeitmessung könntest Du günstig den SFB4 TON verwenden, den Du mit dem Impuls startest (TON mit IN = TRUE und PT = T#1S aufrufen). Wenn der nächste Impuls kommt, speicherst Du die abgelaufene Zeit ET für die Durchflußberechnung und startest den TON neu (1x mit IN = FALSE aufrufen und gleich danach nochmal mit IN = TRUE). Wenn der TON (1s) abläuft (Q = TRUE), dann den Meßwert auf 0 setzen.

Die Zeitmessung in Millisekunden kann man auch mit SFC64 TIME_TCK machen, oder #OB1_PREV_CYCLE aufsummieren.

Harald


----------



## DrumJoeyDrum (21 Februar 2019)

PN/DP schrieb:


> Bei so wenig Impulsen pro Minute ist es für die Auflösung des Messwertes in der Tat günstiger, den Zeitabstand zwischen den Impulsen zu messen (also die Periodendauer), so wie Onkel Dagobert schon empfohlen hat. Und wenn z.B. 1 Minute lang kein Impuls kam, dann setze den Anzeigwert auf 0 l/min. Netter Nebeneffekt: Du bekommst schon früher als nach 1 Minute einen neuen Meßwert. Falls Dir der Meßwert noch zu doll "springt", dann kannst Du den Wert noch glätten, z.B. den Meßwert alle 15 Sekunden abtasten und den Mittelwert der letzten 4 Abtastungen bilden.
> 
> Für die Zeitmessung könntest Du günstig den SFB4 TON verwenden, den Du mit dem Impuls startest (TON mit IN = TRUE und PT = T#1S aufrufen). Wenn der nächste Impuls kommt, speicherst Du die abgelaufene Zeit ET für die Durchflußberechnung und startest den TON neu (1x mit IN = FALSE aufrufen und gleich danach nochmal mit IN = TRUE). Wenn der TON (1s) abläuft (Q = TRUE), dann den Meßwert auf 0 setzen.
> 
> ...




Danke für die Erklärung, das habe ich hinbekommen 

Ich weis nun wie viel Zeit zwischen zwei Impulsen vergeht.
Was mach ich nun mit der Zeit?


----------



## Plan_B (21 Februar 2019)

Der kehrwert der Zeit ist proportional zum Durchfluss.

1 Impuls per Sekunde sind dann 100L/s
1 Impuls alle 2s  --> 1/2 Imp/s *100l/imp = 50 l/s

1 Impuls pro Minute --> 1/60 Imp/s * 100 l/imp = 1,66 l/s

Einfacher Dreisatz


----------



## DrumJoeyDrum (21 Februar 2019)

ich glaub ich habs  sau cool! vielen dank an alle Helfer!!!


----------



## Plan_B (21 Februar 2019)

DrumJoeyDrum schrieb:


> vielen dank an alle Helfer!!!



dafür bietet das Forum auch was an:


----------



## Dome_Step7 (30 Mai 2022)

Guten Tag Forum,

kann sich mir jemand erbarmen und mir bei meinem Code helfen.
Ich wollte die Zeit im MD145 (Format: Time) in eine Real Zahl umrechnen um eine Durchflussrate zu bestimmen.
Mit der Formel: [(1/0,111s)*60] *0,5 = 270 L/min
Ich habe mir euren Beitrag durchgelesen aber mir sind hierbei zwei Ungereimtheiten in meiner Anwendung aufgefallen.
1. Meine Durchflussrate passt nicht was ich auf meinen Umrechnungsfehler mit "DTR" vermute.
2. Das ist bei <10Hz schon ziemlich stark am springen mit dem TON im OB1 habt ihr das im OB40 programmiert?

    U     E      0.6
      U     "High_Merker"
      =     M    144.2
      SPBNB _030
      T     MD   145
      DTR  
      T     #TimePulse_REAL
      L     1.000000e+000
      /R   
      T     #TimePulse_REAL
      L     6.000000e+001
      *R   
      T     #TimePulse_REAL
      L     5.000000e-001
      *R   
      T     #TimePulse_REAL




_030: T     #TimePulse_REAL


Also ich suche die AWL Funktion hiervon:





						SIOS
					






					support.industry.siemens.com
				



Da ich die FUP-Convert Bbausteine nicht finde.

Sorry wenn das an eine andere Stelle gehört.


----------



## Tschoke (30 Mai 2022)

Ein TIME ist im Prinzip ein DINT in Millisekunden. Also musst du den Wert nach dem wandeln in einen REAL mit 1000.0 Dividieren um auf Sekunden zu kommen.
Außerdem Rechnet dein AWL Code: [(*0,111s/1*)*60] *0,5 = 270 L/min 
und nicht: [(*1/0,111s*)*60] *0,5 = 270 L/min


----------



## MFreiberger (30 Mai 2022)

Tschoke schrieb:


> Ein TIME ist im Prinzip ein DINT in Millisekunden. Also musst du den Wert nach dem wandeln in einen REAL mit 1000.0 Dividieren um auf Sekunden zu kommen.
> Außerdem Rechnet dein AWL Code: [(*0,111s/1*)*60] *0,5 = 270 L/min
> und nicht: [(*1/0,111s*)*60] *0,5 = 270 L/min


Ich habe mir den Code jetzt nicht angesehen, aber, wenn als Ergebnis 270 rauskommt, wird die untere Gleichung gerechnet.
Bei der oberen kommt 3,33 raus…


----------



## Tschoke (30 Mai 2022)

Ich habe es so verstanden, dass er eben *nicht* 270 raus bekommt (weil der Code falsch ist). Habs nicht nachgerechnet, nur Code mit der Formel verglichen.


----------



## sunny22 (30 Mai 2022)

Also ich finde der Code ist ziemlich merkwürdig ihr nicht?
Wieso "T     MD   145"? Sollte das nicht "L     MD   145" sein?
Wozu dieses ständige "T     #TimePulse_REAL"?
Gibt es noch Code vor und nach dem hier gezeigten?


----------



## DeltaMikeAir (30 Mai 2022)

sunny22 schrieb:


> Also ich finde der Code ist ziemlich merkwürdig ihr nicht?


Schon, ja. 



Dome_Step7 schrieb:


> U E 0.6
> U "High_Merker"
> = M 144.2


Der HighMerker ( ich gehe mal davon aus, das es ein DauerHigh ist ), hat auch keine Funktion.


----------



## Heinileini (30 Mai 2022)

DeltaMikeAir schrieb:


> Der HighMerker ( ich gehe mal davon aus, das es ein DauerHigh ist ), hat auch keine Funktion.


Keine Funktion, ganz genau. Vielleicht ist genau das seine Funktion, er dient vielleicht als PlatzHalter für etwas, das vorübergehend unwirksam gemacht wurde?


----------



## DeltaMikeAir (30 Mai 2022)

Heinileini schrieb:


> Keine Funktion, ganz genau. Vielleicht ist genau das seine Funktion, er dient vielleicht als PlatzHalter für etwas, das vorübergehend unwirksam gemacht wurde?


Habe ich mir auch schon so gedacht. Vielleicht ein Überbleibsel von der Inbetriebnahme.

Mein Hinweis war einfach als Anregung an den TE.


----------



## PN/DP (30 Mai 2022)

Dome_Step7 schrieb:


> Ich wollte die Zeit im MD145 (Format: Time) in eine Real Zahl umrechnen um eine Durchflussrate zu bestimmen.
> Mit der Formel: [(1/0,111s)*60] *0,5 = 270 L/min


In der Formel kommt gar keine Variable vor, da fehlt das "x" (das MD145) 



Dome_Step7 schrieb:


> U     E      0.6
> U     "High_Merker"
> =     M    144.2
> SPBNB _030
> ...


- Die 4 blau markierten Zeilen sehe ich als Test/Inbetriebnahme-Code, der den eigentlichen Code nicht stört, der aber in der fertigen Version nicht mehr drin sein sollte.
- Das "T MD 145" müsste ziemlich sicher "*L* MD145" heißen, oder wird MD145 auch noch vor dem gezeigten Code geladen?
- Wo ist das "1/0,111s" aus der Formel geblieben? Im Code wird nur noch (unnötigerweise) durch 1 geteilt, die 0.111 kommen nirgends vor.
- das letzte rote "T #TimePulse_REAL" speichert *irgendwas*, was zufällig vor dem Code im AKKU1 ist, wenn zu _030 gesprungen wird (wenn E0.6 = 0 ist)



Dome_Step7 schrieb:


> Also ich suche die AWL Funktion hiervon:
> 
> 
> 
> ...


Welche CPU hast Du? S7-300?
Welches TIA verwendest Du?

Du könntest für die Berechnung eine eigene Function (FC) programmieren, da kannst Du für die Formel SCL verwenden.
Bei S7-1200/1500 kann man sogar in einem FUP-Baustein direkt einzelne Netzwerke in SCL programmieren.

Harald


----------



## hucki (30 Mai 2022)

Dome_Step7 schrieb:


> Ich wollte die Zeit im MD145 ...


Und solch "furchtbare" Adressen solltest Du Dir auch erst gar nicht angewöhnen.
Das wird in der Regel als "unsauber programmiert" angesehen.


Adressen für MD (DWORD, DINT, Real ...) sollten immer auf einer ohne Rest durch 4 (Byte) teilbaren Adresse beginnen.
Also hier entweder MD144 (da drin wird aber u.a. Dein Merker M144.2 schon verwendet, der dann eine anderweitige Adresse benötigen würde, wie z.B. die dann freie M148.2) oder halt als Nächstes das MD148.


----------



## Dome_Step7 (31 Mai 2022)

Guten Morgen liebes Forum Team,

herzlichen Dank für die vielen Kommentare ich gehe erstmal auf die Fragestellungen ein.
@PN/DP genau das x hatte ich nicht geschrieben es sind die 0,111s aus MD145, dies entspricht dem Ausgang ET vom TON-Baustein.
2. Genau das ganze war ein schneller Test mit der Inbetriebnahme am Arbeitsplatz, da der Stand noch nicht aufgebaut wurde.
3. Den restlichen Code habe ich gestern aus "Frust" gelöscht und wollte heute mit neuen Gedanken starten. (Bestand aus TON und der Auswertung zum Steuern des Zählers mit SW_GATE und Zählwert in LADDR1).
4. Da ist mir wohl ein Fehler in der Reihenfolge passiert sollte natürlich 1 / MD145 sein und nicht MD145 / 1 gut bemerkt.
5. War noch nicht fertig geschrieben ich wollte in den Zeilen vorher meinen Wert erstmal beobachten als Gleitpunktzahl da stand halt nie die gewünschten 270, damit habe ich es dann auch belassen (90 und 700 kamen da teilweise zurück.)

Also ich arbeite mit Step 7 V5.6 SP2 ohne SCL, das hat mir mein Vorgänger hinterlassen.
Ich programmiere die Steuerung für einen Wasserprüfstand und diese Funktion soll einen Durchfluss berechnen.
Die Visuelle Anwendung und Steuerung erfolgt über LabView.
(Was auch eigentlich mein Anteil mal an dem Projekt war mit Siemens bin ich eher weniger vertraut, aber mittlerweile kann ich mich zu funktionierenden Lösungen hinarbeiten und verstehe auch den Daten-Aufbau der ECU.
Zum Anwenden nicht entwickeln natürlich bevor ich gleich gesteinigt werde.

@Tschoke genau ich bin zu keinem brauchbaren Ergebnis gekommen.
Mein Ansatz war es die Periodendauer direkt umzurechnen in eine Durchflussrate was bei konstantem Volumenstrom oder nahe zu konstant auch eigentlich sauber gehen sollte, ich arbeite da mit 0-10Hz und 0-2kHz Sensoren sprich 200L/min wären dann 2kHz.

Wenn mir noch jemand kurz auf die Sprünge helfen könnte bezüglich Strukturierung in der Siemens Welt:
1. Ich Löse über meinen Prozessalarm meines Z0 z.B. eine Logfunktion aus mit der ich jeden VG =4  sichere in einem DB.
2. Will ich im OB1 meine Durchflussrate wie oben beschrieben berechnen können für Z0, Z1, Z2.

Wie ich zähle am Besten?
Mir ist schon das Steuern bekannt mit SW_GATE im Kontrollwort und dem Statuswort auch wie ich zurücksetzte, einen Algorithmus würde ich mir noch überlegen zum automatisieren.
Aber wo schreibe ich den meine Durchflussberechnung hin damit sie Zeit unabhängig erfolgt, also das die Zeit zwischen den Impulsen auch der tatsächlichen entspricht ?
OB40 - wird nur beim erreichend es Vergleichswerts ausgelöst also hier nicht oder?
OB1 - hat eine Zykluszeit ~ ? (wo sieht man das in Step7 ?)

Oder ist das mit der TON Funktion schon unkritisch, weil er die Zeit bereits passend auswertet mit dem Pulseingang von meinem Sensor wie es Harald beschrieben hat.


CPU basiert auf einer 318 ist aber eine VIPA 314ST


----------



## PN/DP (31 Mai 2022)

Dome_Step7 schrieb:


> Wie ich zähle am Besten?
> Mir ist schon das Steuern bekannt mit SW_GATE im Kontrollwort und dem Statuswort auch wie ich zurücksetzte, einen Algorithmus würde ich mir noch überlegen zum automatisieren.


Bei der Verwendung von Hardware-Zählern verzichte ich meistens auf den ganzen Brimborium mit Starten/Stoppen/Steueraufträgen der Zählkanäle. Ich lasse die Kanäle meistens endlos frei laufen und lese nur den Zählerstand aus.
Möglicherweise kann Deine Zähler-Hardware auch direkt die Periodendauer oder Frequenz des Eingangssignals messen? Da könnte es günstiger sein, diese Betriebsart zu nutzen. Was für Zähler-Hardware hast Du?



Dome_Step7 schrieb:


> Aber wo schreibe ich den meine Durchflussberechnung hin damit sie Zeit unabhängig erfolgt, also das die Zeit zwischen den Impulsen auch der tatsächlichen entspricht ?


Bei max 10Hz könntest Du auf den Digitaleingang einen Prozessalarm bei steigender Flanke projektieren (falls Deine Hardware das unterstützt), und dann im OB40 die abgelaufene Zeit umrechnen.



Dome_Step7 schrieb:


> OB40 - wird nur beim erreichend es Vergleichswerts ausgelöst also hier nicht oder?


Das kommt auf Deine Hardware drauf an und wie Du die projektiert hast.
Der OB40 wird bei allen projektierten Prozessalarmen ausgelöst. In den Startinformationen des OB40 wird in OB40_MDL_ADDR und OB40_POINT_ADDR mitgeteilt von welcher Baugruppe und welchem Eingang der Prozessalarm aufgerufen wurde. Siehe Step7-Hilfe zum OB40 und die Beschreibung Deiner Zähler-Hardware.



Dome_Step7 schrieb:


> OB1 - hat eine Zykluszeit ~ ? (wo sieht man das in Step7 ?)


Rechtsmausklick auf die CPU > Zielsystem > Baugruppenzustand > Reiter: Zykluszeit

Harald


----------



## Dome_Step7 (31 Mai 2022)

Hi @PN/DP ,

das ist natürlich ein sehr guter Ansatz!
Ich denke den Verfolge ich auch einmal quasi die Zählerdifferenz zwischen einem Zeit Intervall auszuwerten?
Kann ich dabei den auf TON vertrauen also quasi nicht die Zeit ET betrachten, sondern das Delta aus dem LADDR1 des Zählers bilden?
(Zum Zeitpunkt T0 und T1)

Ich habe extra diese Impulsvariante übernommen, damit ich eine unabhängige Programmstruktur habe.
Damit bei einem Wechsel der Hardware dann einfach den imp/L als Datentyp eingibt.
Klar könnte man das auch schön mit HART-Signal umsetzten, aber das habe ich noch nie gemacht und mir fehlt auch eine Karte dafür.
(und zwei Sensoren sind nur PNP-Transistoren die sind leider wirklich nur als Rechtecksignal zu gebrauchen..)

Also das mit dem Pointer des Eingangs ist natürlich klasse, das sehe ich mir auch noch an!
Eigentlich habe ich es über die Reihenfolge der Sensor Auswertung ausgeschlossen (verschiedene Messleitungen über Ventile), aber ein "Fehlerhafter Impuls" kann natürlich trotzdem nicht technisch ausgeschlossen werden.

Mit OB40 würde ich ungerne Zeiten berechnen, da ich hier bereits einen Wert speichere das sind schon ein paar Zeilen Code.
Ich versuche mich gleich mal an deiner ersten Idee mit der Differenzbildung.


----------



## Dome_Step7 (1 Juni 2022)

Für die Nachwelt ich habe es jetzt wie folgt gelöst:
OB35 Weckalarm auf 1000ms gestellt.
OB35 Programmiert - Im Netzwerk 1 wird der Zählerwert des betroffenen Zählers zwei mal gespeichert in Var1 und Var2.
Anschließend bilde ich die Differenz daraus und multipliziere dies mit der genannten Formel. 
Geg: 
Sensor = "Wert" L/imp

Formel:
[(var1,2 Differenz =imp/s) *60]* L/imp

Also solange meine Gesamtzykluszeit des Projektes <1000ms bleibt habe ich immer den genauen Durchfluss das sollte eigentlich kein Problem sein.
Und dann kann man damit weiter arbeiten im OB1 z.B. Mittelwertbildung..
Eine Mengenbildung würde ich im OB40 realisieren da ich dort meinen Zähler zuordnen kann wie Harald schrieb.

Viel Erfolg und besten Dank allen!


----------

