# Zähler mit Überlauf



## MSB (1 September 2007)

Sorry für den dämlichen Titel, was anderes fiel mir nicht ein.

Nun zum Problem:
Ich bekomme über Profibus einen freilaufenden Zähler, effektiv werte dieser Impulse eines MID's aus.
Die Wertigkeit dieses Zählers ist von 0 - 32768 und springt dann einfach wieder auf 0.
Der Profibusslave ist ein 2-Draht Bussystem, an dem hängen über mehrere Kilometer Erdkabel verteilt,
div. Hochbehälter, Übergabeschächte ...
Das ein System welches auf solche Entfernungen funktioniert nicht gerad schnell ist, dürfte klar sein.

Hier mal was ich bisher habe:
Anhang anzeigen FB170.pdf


Das Problem ist nun, wenn ein Busausfall ist, entweder Profibusseitig oder 2-Draht Busseitig,
kann es passieren kann das das PEW vom Zähler "0" wird,
ebenso kann dies passieren beim Hochlauf des Systems, also Steuerung und 2-Draht Station.

Ich weiß jetzt nicht wie ich trennen kann, ob das nun ein "echter" Rücksprung war,
oder das halt durch irgend eine Busstörung zustande gekommen ist.

Wenigstens von diesem 2-Draht System, dauert es ca. 30 Sekunden bis eine Station als gestört erkannt wird.
Das kann ich auch nicht irgendwie ändern.

Also:
Wie könnte man den Baustein "solider" bekommen?

Mfg
Manuel


----------



## Oberchefe (2 September 2007)

Wie wär's mit einer Plausibilitätsprüfung? Also Wert davor (und evtl. Wert danach) in Bezug setzen und schauen ob der Wert dazu paßt und nur in diesem Fall verrechnen.


----------



## IBFS (2 September 2007)

@MSB

1. Was ist ein "MID" und in welcher zeitlichen Folge kommen die IMPULSE.

2.
Zitat:
"Das ein System welches auf solche Entfernungen funktioniert nicht gerad schnell ist, dürfte klar sein"
Zitat-Ende:

Was heißt "LANGSAM"?
Langsamer als 9.6 kBit/s kann man den Profibus doch garnicht einstellen.

D.h. deine REFRESH-Rate dürfte dann etwa - je nach Anzahl der Stationen - um etwa max. eine Sekunde sein, oder sehe ich dass völlig falsch.

3. Vielleicht kann man in jede Station ein LEBENSBIT einbauen.
    Wenn dann nichts mehr "blinkert" weißt du das ggf. eher, als die DP-Diagnose und kannst den Zähler auf "UNPLAUSIBEL" setzen.

Gruß


----------



## MSB (2 September 2007)

@IBFS
1. Ein MID = Magnetisch Induktiver Durchflussmesser
Die Pumpe wird zwischen 5 und 20 l/s betrieben, und ich werte 100 liter Impulse aus.

2. Über Profibus koppele ich nur auf das System, das 2-Drahtsystem selbst hat Refreshraten / Unterstation zwischen 8 - 10 Sekunden, im gegenwärtigen Ausbau.

3. 
Die Stationen werden ja laufend durch das System überwacht, wie das genau funktioniert ist nicht näher dokumentiert.


@Oberchefe
Die Idee mit der Plausbilitätskontrolle hatte ich grundsätzlich auch schon,
ich weiß in dem Fall nur nicht wie ich mich mit der Plausibilität verhalte wenn das System
wirklich mal längere Zeit ausgefallen ist.
Oder wie würdest du den "höchsten" plausiblen Wert bestimmen.

Mfg
Manuel


----------



## Larry Laffer (2 September 2007)

Hallo Manuel,
bleiben denn die Zählwerte auch zwischen 2 "Updates" auf dem gleichen Wert stehen ? Kann bei Durchflussmessungen im Kanalnetz eigentlich nicht der Fall sein ...
Ich denke mal, dass du in diesem Fall eine maximale und eine minimale Änderung pro Zeiteinheit haben wirst. In dem Fall wären die Werte plausibel, die innerhalb des Zeitfensters in dem Rahmen bleiben. Die zu erwartenden Werte berechnest du nach jedem "Update" der Werte neu. Ich denke, mehr kannst du ohne eine "echte" Fehler-Diagnose nicht machen ...


----------



## MSB (2 September 2007)

Also ich messe nicht in einem Kanalnetz sondern einen Durchflussgeregelten Trinkwasserbrunnen.

Problem:
Wenn das 2-Drahtsystem und/oder die DP-Kopplung ausfällt, ist mit Automatikbetrieb sowieso zunächst mal sense,
denn auch alle Ansteuerungen/Sollwertvorgaben erfolgen über das 2-Draht System.
Dann gibt es vor Ort im jeweiligen Brunnen noch die Möglichkeit diesen in einer Art Notbetrieb zu fahren, in dem Fall dann also mit Festfrequenz.
Wenn nun der Zähler noch Spannung hat, und funktioniert, zählt dieser dann die Durchflussmenge vom MID trotzdem munter weiter.
Kritisch wirds bei den im Regelfall gefahrenen 7-10 l/s erst nach ca. 4 Tagen,
denn dann läuft der Zähler über, bzw. der neue Wert ist (wieder) größer als der alte Wert.
Solange hätte ich die Chance trotz Busausfalls nach wiederinbetriebnahme des Systems
trotzdem noch den richtigen Wert des Wasserzählers zu haben.

Problem hierbei natürlich, während des Ausfalls weiß ich natürlich nicht, ob und mit welchen Durchfluss der Brunnen gefahren wird.

Der Wertsprung wären in dem Fall aber bis zu ca. 3200 m³,
und in dem Fall wäre selbst das dann plausibel.

Andere Möglichkeit wäre natürlich noch, ich knalle den Wert des Gesamtzählers auf "0",
und zwinge den Wasserwart so, den Wert wieder mit dem MID abzugleichen.

Meinungen?
Oder ist das alles Scheiße und ich denke gerade zu viel.

Mfg
Manuel


----------



## Onkel Dagobert (2 September 2007)

Hallo Manuel,

funktioniert deine Überlauf-Funktion? Das mit dem -D und +D halte ich für etwas gewagt, hab's aber nicht wirklich nachvollzogen. Ich würde den Überlauf wie folgt berechnen (nicht getestet):


```
//*** Differenz ermitteln
      L     #PEW_Zaehler                // aktueller Zählerstand
      L     #Wert_Letzter_Zyklus        // alter Zählerstand
      -I    
      SPBN  M001
      L     #Ueberlauf_Zaehler          // Überlauf
      +I    
M001: T     #PEW_Diff_Zyklus
 
//*** aktuellen Zählerstand sichern
      L     #PEW_Zaehler                // aktueller Zählerstand
      T     #Wert_Letzter_Zyklus        // alter Zählerstand
 
//*** keine Änderung
      L     #PEW_Diff_Zyklus
      L     0
      ==I   
      =     #KEINE_AENDERUNG            // keine Aktualisierung
 
//*** Kommunikationsausfall
      CALL  #WATCHDOG                   // TON
       IN:=#KEINE_AENDERUNG
       PT:=T#1M
       Q :=#FEHLER_KOM_1                // ???
       ET:=
 
//*** Kommunikationsausfall
      L     #PEW_Zaehler                // aktueller Zählerstand
      L     0
      ==I   
      =     #FEHLER_KOM_2               // ???
 
//*** Änderung zu groß
      L     #PEW_Diff_Zyklus
      L     #Max_Aenderung              // max plausible Änderung
      >I    
      =     #AENDERUNG_ZU_GROSS         // nach Busausfall?
```
 
Wenn du noch mehr machen willst, käme eventuell eine Speicherung des Zeitstempels der letzten Wertänderung in Frage.

Was ist denn das für ein lahmes 2-Drahtsystem, von dem die Rede ist?


Gruß, Onkel


----------



## MSB (2 September 2007)

@Onkel
Das 2-Drahtsystem ist das:
http://www.ees-online.de/frameset.p...rtragung&Language=de&Issue=1&NavigationId=112

Das ist deshalb so langsam, weil es sehr störunempfindlich ist, und auf Leitungen bis zu 30km funktioniert.
Diese Aktualisierungszeit ist aber eigentlich egal, es hängt ja grundsätzlich in dem Fall nichts Zeitkritisches dran.

Mfg
Manuel


----------



## Larry Laffer (2 September 2007)

MSB schrieb:


> Meinungen?
> Oder ist das alles Scheiße und ich denke gerade zu viel.


 
Hallo Manuel,

2.Versuch:
Wenn nach 4 Tagen der Zähler überläuft, dann wäre das plausibel und eine geringfügige Änderung zum zuletzt eingelesenen Wert eigentlich nicht ...
Somit läge für mich die Annahme nahe, dass in dem Fall wirklich >3200 m³ Durchfluss da waren und nicht 100 oder so ...
Ansonsten könntest du m.E. per Zeit-Überwachung den Wasserwart nach einer Zeit x (z.B. 3 Tagen) ohne sinnsolle Zahlenwerte dazu auffordern, die Angelegenheit zu überprüfen ...

Nachsatz:
Entschuldige bitte den Ausrutscher mit dem Kanalnetz ...


----------



## MSB (2 September 2007)

@Larry
Brauchst dich nicht zu entschuldigen,
hatten auch schon mit diesem braunen Zeugs zu tun !


----------



## Larry Laffer (2 September 2007)

... dann bin ich ja beruhigt ...

Was hälst du von meinem Vorschlag ?


----------



## MSB (2 September 2007)

@Larry
Läuft aber trotzdem drauf hinaus, den plausiblen Wert Ausfallzeitabhängig zu berechnen.
Naja dann wolln mer mal kucken, oder tippen.

Ich hatte nur gehofft jemand hatte sich schon mal den Schädel zerbrochen mit so einem Blödsinn.

Wenn der Wert nicht noch aufgezeichnet würde und "halbautomatisch" beim Wasserwirtschaftsamt landen würde,
wäre es mir ja vermutlich egal.

Mfg
Manuel


----------



## Larry Laffer (2 September 2007)

MSB schrieb:


> Läuft aber trotzdem drauf hinaus, den plausiblen Wert Ausfallzeitabhängig zu berechnen.


 
Ich glaube nicht, dass du sonst eine Alternative hast.
Du müstest aber unter Berücksichtigung der letzten erfassten Werte näherungsweise einen zeitabhängigen Zielpunkt ausrechnen können.
Ansosnsten sieht es ja so aus, dass bei einem korrekt funktionierendem Datenaustausch, du solche Klimmzüge gar nicht zu machen bräuchtest ... Ein bißchen Schwund ist immer ... :twisted:


----------



## Ralle (3 September 2007)

Hängt auf der Zählerseite auch eine SPS oder nur dieser Zähler (vermute ich mal). Gäbe es eine Möglichkeit, den Wert Null für den Zähler generell zu sperren ? (Also z.Bsp. erst wieder ab 1 den Wert auf den Bus zu legen) Dann wäre der Wert Null immer ein ungültiger Wert. Kannst du einen weiteren Ausgang übertragen, der immer log. True sein muß. Wenn der Bus ausfällt, wäre dieser ja genauso False, wie den Zählwert Null ist und auch so eine Plausibilitätskontrolle möglich. Auch die Überlaufkontrolle könnte man evtl. so über einen weiteren E/A machen, dazu braucht man aber etwas Hardware/Software auf der Zählerseite.


----------



## MSB (3 September 2007)

Also die Zählerseite hat im herkömmlichen Sinn keine Intelligenz,
jedenfalls keine programmierbare.
Das einzige was ich parametrieren kann, ist irgend ein Wert zwischen 0 - 32767,
bei dem der Zähler 0 wird.

Die Möglichkeit mit den Aus-> Eingang muss ich mal prüfen wie sich das
verhalten würde, ist auf jeden Fall ne gute Idee.

Mfg
Manuel


----------



## Approx (3 September 2007)

*Uhrzeitalarm-OB*

Hallo,
wie steht es denn mit der Idee, einen Uhrzeitalarm-OB (OB10..17) zu benutzen? In diesem OB könnte man zu einer selbst definierten Zeit (z.B. tägl. um 16:00Uhr) den Zählwert auf Null setzen und bereits aufgelaufene Zählwerte abspeichern. Wenn dann der Zählwert zwischendurch wieder zu Null wird, dann ist der Fehlerfall...
Wie gesagt, nur ne Idee.


----------



## MSB (3 September 2007)

Wenn das ginge, das wäre natürlich das optimum.
Aber ich kann das PEW, also diesen EES-Zähler von "Außen" nicht beeinflussen,
also auch nicht "bewußt" auf 0 setzen.

... Leider ... :sm23:

By the way: Ob Chuck das könnte?

Mfg
Manuel


----------



## Larry Laffer (3 September 2007)

...
aber der Vorschlag von Approx hat schon was ...
Du könntest den letzt eingelesen Wert als Offset speichern. Dann hast du ja wieder etwas "Luft" bis dein Zähler diesen Wert wieder erreicht hat.
Du hast dann halt trotzdem noch das Problem mit dem Komplett-Ausfall ...


----------



## Maestro (3 September 2007)

Ausgehend von der Annahme, dass Du das Impulsbit des Durchflussmengenmessers aufgrund der langsamen Busanbindung nicht direkt anstehen hast:
Wie wäre es, das kleinste Bit Deines Zählers auf negative+positive Flanke zu überwachen (Zeitüberwachung in Abhängigkeit zu Deiner Durchflussmengenregelung)?
Beispiel:

```
U(    
      U     #DurchflussBit0
      FP    #Hilfsm1
      O(    
      U     #DurchflussBit0
      FN    #Hilfsm2
      )     
      )     
      L     #UeberwZeit
      SE    #Zeit1
```
wobei Deine überwachungszeit aus Deinem Stellwert für den Durchfluss berechnet werden muss. So hast Du je nach Parameterwahl eine recht scharfe Kontrolle Deiner Werte.
Nur mal so ein Vorschlag.

Grüße

PS.: Als Zähler würde ich für so einen Anwendungsfall - wenn irgendwie möglich - ein Doppelwort nehmen (hier einfach aus den Impulsen wieder regenerieren). Den kann man dann z.B. zum Jahres-, Wochen-, Tages- oder Stundenwechsel dann bequem definiert reseten. 

PPS: Funktioniert natürlich nur, wenn Dein Zähler nicht "blind" weiterzählt - d.h. Dein Bus immer schneller, als ein Zählimpuls ist.


----------

