Step7 - VIPA - Zählerkarte - Werte auslesen und umrechnen

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe hier ein Problem mit einem Zähler an einer VIPA-CPU einer alten Bestandsanlage.
Der Hardwareaufbau ist wie folgt:

Es geht um die Baugruppe ganz rechts (VIPA_SPEEDbus).
Im STEP7-Hardwaremanager ist die Karte wie folgt konfiguriert:


Die VIPA-CPU kann noch über eine separates Program namens "ConfigStage" konfiguriert werden. Aber darin habe ich die Baugruppe gar nicht gefunden.
Die Anlage besteht seit ca. 1994 und wir haben im letzten Jahr SAP eingeführt.
Der Zähler erfasst einen Folienverbrauchswert.
Seit der Einführung von SAP fällt nun auf, dass die Verbrauchswerte nicht stimmen und immer viel zu viel gebucht wird.
Der Zählerwert wird via OPC aus einem DB in der SPS ausgelesen.

Die Auswertung des Zählerwertes von der Karte geschieht wie folgt:



Der Zählerwert wir lediglich durch -1000 geteilt.
Zum Geber selber kann ich leider nur sagen, dass es ein Laufrad mit Geber ist. Das Typenschild am Geber ist leider nicht mehr lesbar.

Ich frage mich, ob die Auswertung des Geberwertes so überhaupt korrekt ist.
Müsste der nicht in Bezug zum Umfang des Laufrades gesetzt und umgerechnet werden?
Könntet Ihr mir dazu vielleicht Eure Meinungen und/oder Tipps mitteilen?

Habt recht vielen Dank im Voraus!

 

[wee]

Schon im Programm nachverfolgt was anschliessend mit "MW_Zaehler0" gemacht wird?

Vielleicht greift ihr nur die falsche Variable ab (vor der Umrechnung in Meter/Verbrauch) oder muesstet die Umrechnung entsprechend im OPC Server machen wenn das im Programm nicht irgendwo passiert. Dazu brauchst du dann aber die Daten des Gebers, Foliendurchmesser und den Durchmesser der Laufrolle.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Müsste der nicht in Bezug zum Umfang des Laufrades gesetzt und umgerechnet werden?

Vielleicht ist das schon "extern" geschehen durch die Festlegung des LaufradDurchmessers und der Anzahl Striche/Umdrehung des Gebers?
Ich würde zunächst mal ermitteln, um wie viele Einheiten bei 1 Umdrehung des Laufrades weitergezählt wird und den LaufradUmfang berechnen.
Vielleicht dient die Division durch -1.000 schon zur Umrechnung von z.B. mm in m?

PS:
Um wie viel zu viel wird gebucht? So ca. 2,4%?

 

[Grimsey]

Danke für Eure Antworten,

die Zählervariable wird in einem anderen FC dazu genutzt, um den Wert in den DB zu schreiben.
Damit passiert rein gar nichts weiter.

Die Abweichung bei den Buchungen schwankt zwischen 2x und 8x...selten auch mal 10x.

Die Division durch -1.000 dient scheinbar nur der Umrechnung...jedenfalls besagt das ein Kommentar im AWL-Code " // Ausgabe Meterwert".

Wenn der Bezug zum Umfang durch den Gebertyp festgelegt ist (Anzahl Striche pro Umdrehung und Durchmesser)....bedeutet das dann, dass evtl. der Gebertyp nicht zum Anwendungsfall passt?
Verstehe ich das richtig?

 

[Larry Laffer]

@Grimsey:
Du hast m.E. Recht damit, das zu hinterfragen ...
- erstmal wird da ja einINT-Wert erzeugt - das ist schon mal nicht besonders genau
- dann wird wahrscheinlich nur so PI mal Daumen Inkremente in Meter umgerechnet - der Laufrad-Ansatz ist schon richtig
- dann hat der Zähler ja auch irgendwann einen Überlauf. Wird dem Umstand irgendwo Rechnung getragen ?
- ach ja : läuft das Laufrad immer schön sauber mit oder kann das auch durchrutschen ?

Gruß
Larry

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

@LarryLaffer

mit dem Zählerwert passiert rein gar nichts mehr. Der Code ist so wie auf dem 3. Bild.
Überlauf etc. wird m.E. nirgends beachtet.
Das Einzige was ich mir noch vorstellen könnte, wäre, dass es in der Hardware behandelt wird.
Bei anderer Anlage mit S7-1500 und Zählerkarte muss man extra maximale Zählwerte angeben in der Hardwarekonfiguration.
So etwas oder ähnliches habe ich aber leider auch nirgends gefunden (siehe Bild 1 und 2)
Dort ist für die Signalauswertung "Impuls/Richtung", Zählrichtung "nicht invertiert" und Zählerfunktion "endlos zählen" eingestellt.

Das Rad läuft auf einer Folie und wird mit einer Feder angedrückt. Im normalen Betrieb rutscht es nicht durch, wäre aber theoretisch möglich bzw. nicht zu 100% auszuschließen.
Das Rad hat einen Durchmesser von 160mm und damit einen Umfang von 502,64mm.
Leider zählt der Zähler nur im Betrieb...das konnte ich gerade nicht so schnell anpassen, sonst hätte ich das eben auch noch überprüft aber die Produktion musste weitergehen.
Werde ich aber bei der nächsten Möglichkeit überprüfen. Dann hätte ich die genaue Anzahl an Inkrementen pro Radumdrehung.

Und das könnte ich mir dann ja zusammenrechnen, wenn ich nicht gerade ein Brett vorm Kopf habe

 

[Larry Laffer]

Dann ist es aber schonmal so, das schon das Dividieren falsch läuft.
Hier müßte ja nun der Zählerwert durch eben diese 502,64 dividiert werden.
Dann ... wenn du endlos zählst kommt ja auf jeden Fall irgendwann der Überlauf - natürlich je nachdem wieviel Material zwischen Einschalten und Ausschalten da so dran her läuft (vielleicht sagst du dazu mal etwas).
Das wäre im Programm aber auch recht einfach abzufangen.
Insgesamt eklärt da aber schon die von dir genannten Abweichungen ...

Gruß
Larry

 

[Grimsey]

Die Menge des Materials.....hmm..gute Frage....die Jungs an der Anlage setzten diese Verbrauchswerte mit jedem neuen Auftrag auf Null.
Je nach Auftragsgröße laufen da einige 100 Meter durch. Bei großen Aufträgen werden aus mal Kilometer.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Rad läuft auf einer Folie und wird mit einer Feder angedrückt. Im normalen Betrieb rutscht es nicht durch, wäre aber theoretisch möglich bzw. nicht zu 100% auszuschließen.
Das Rad hat einen Durchmesser von 160mm und damit einen Umfang von 502,64mm.

Du sagtest weiter oben, dass zu viel gezählt wird, nicht zu wenig. Das spricht dafür, dass ein Rutschen nicht die Ursache sein kann.
Du hast also einen Umfang von "fast genau" einem halben Meter und wenn nun der Geber sagen wir mal 500 Striche/Umdrehung hat und jede 4. Flanke ausgewertet wird, dann sind wir schon bei 1 Inkrement pro mm und mit Pi mal Durchmesser braucht die Software nichts zu rechnen.
Mein Hintergedanke, warum ich nach 2,4% zu viel gefragt hatte, war, dass vielleicht ein ursprünglicher Geber mit z.B. 1000 Strichen/Umdrehung irgendwann gegen einen Typ mit 1024 S/U gewechselt worden sein könnte.
Aber die Bandbreite der zu-viel-Zählerei (bis zu 10 x) spielt in einer anderen Liga und scheint alles andere als reproduzierbar zu sein. Ich finde keinen Hinweis auf eine einfache, plausible Erklärung.

 

[PN/DP]

Das Rad läuft auf einer Folie und wird mit einer Feder angedrückt.

Das Messrad läuft wirklich auf der Folie (oder dem Umfang der Folienrolle) und nicht etwa auf der Welle der Folienrolle? Der Umfang der Folienrolle nimmt ab beim Abwickeln...

Harald

 

[Grimsey]

Das Rad läuft auf der Folie und nicht auf der Folienrolle.
Die Folie wird über einen ca. 80m langen Tisch gezogen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei der Zähler-Einstellung die Signalauswertung "Impuls/Richtung" bedeutet 1 Eingang Impulse und 1 Eingang Richtung? Also nicht A/B-Zähler, wo man die Anzahl Flanken-Auswertungen vorgeben kann?
Nicht daß da mal A/B-Zähler mit 2 Flanken eingestellt war und deshalb die Division durch 1000 (bei Geber mit 500 Strichen/Umdrehung), und später wurde wegen Gebertausch (oder versehentlich?) auf "Impuls/Richtung" eingestellt, wo man durch 500 dividieren müsste?

PS: Falls nicht A/B-Zähler sondern 1 Eingang Impulse und 1 Eingang Richtung: prellt das Gebersignal? Kommen Impulse im Stillstand?

Harald

 

[Grimsey]

Diese Informationen habe ich leider überhaupt nicht.
Das wurde alles vor meiner Zeit installiert und es gibt hier wirklich niemanden mehr, der weiß ob was wann wo gewechselt wurde.
Wenn ich da jemanden hätte, wäre mir ja auch schon geholfen.

Im Stillstand kommen keine Impulse.
Wenn die Anlage steht, kommen auch keine Impulse. Das wird aber wohl am Programmcode liegen, vermute ich. Da wird das Software-Tor an und ausgeschaltet (siehe Bild 3 im Post #1).

Was ich aber jetzt noch beobachtet habe: wir fahren derzeit mit so ziemlich genau 4 m/min.
das sind 0,655 m/10s....ich logge hier in einer Datenbank alle möglichen Maschinendaten aller 10s mit. In der Datenbank wird in 10s immer 1m erfasst.
Es scheint also, als würde an hier an dieser Stelle immer ca. doppelt so viel gezählt.
Das erklärt nur leider nicht die unterschiedlichen Schwankungen.
Ohne Typenschild vom Geber ist es schon sehr schwer.
Wenn nächste Woche wieder Wartung ist, werde ich auf alle Fälle mal die Anzahl der Inkremente / Umdrehung ermitteln

 

[Larry Laffer]

OK ... dann ist dann natürlich auch noch so ein Punkt.
Das "geteilt durch 1000" impliziert ja, dass der Geber eigentlich 2000 Impulse pro Umdrehung haben müsste damit es stimmt. Ist das nicht so dann erklärt das natürlich deine Fehlmessung.
Allerdings bei mehreren Kilometern / Tag dann auch irgendwann einmal das Thema mit dem DINT-Überlauf ...

Gruß
Larry

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das "geteilt durch 1000" impliziert ja, dass der Geber eigentlich 2000 Impulse pro Umdrehung haben müsste damit es stimmt.
... dann auch irgendwann einmal das Thema mit dem DINT-Überlauf ...

2000 Impulse pro Umdrehung? Es müssten 500 Flanken pro Umdrehung gezählt werden also 1000 Flanken pro 2 Umdrehungen, weil der Umfang des Rades ca. 500 mm beträgt.
Das Wort 'Impulse' finde ich furchtbar irreführend, weil z.B. 500 Impulse pro Umdrehung von dem A-Signal kommen und weitere 500 Impulse pro Umdrehung von dem B-Signal. Sollte man die folglich addieren???
Eine Periode (entsprechend 1 Strich) von A und B hat 4 Flanken und davon kann jede, jede zweite oder jede vierte gezählt werden (es könnten auch 3 von 4 Flanken gezählt werden - aber das tut anscheinend niemand).
Der Überlauf des endlos zählenden Zählers - egal, ob INT oder DINT - ist unkritisch, wie Harald hier im Forum schon zig-mal gezeigt hat.
Mich stört viel mehr, dass vermutlich nicht endlos gezählt wird, zumindest könnte das durch die genannten Tore zerschossen werden.

 

[Larry Laffer]

@Heinrich:
2000 Impulse pro Umdrehung heißt, dass es auf einer Spur 2000 positive Flanken gibt.
Hat man 2fache Flankenauswertung so werden die positiven Flanken von Spur "A" und Spur "B" von der Zählerkarte erfasst - ergibt dann 4000 Inkremente pro Umdrehung.
Hat man 4fache Flankenauswertung so werden die positiven und die negativen Flanken von Spur "A" und Spur "B" von der Zählerkarte erfasst - ergibt dann 8000 Inkremente pro Umdrehung.

Gruß
Larry

 

[Heinileini]

Ja genau, Larry!
Aber wie kommst Du auf 2000? Das Rad hat ca. 500 mm Umfang und muss pro m 2 Umdrehungen machen, nicht eine halbe Umdrehung!?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... es wird aber gerade doppelt so viel gemessen als real vorhanden ist.
Ist aber eigentlich nicht relevant - ich denke Grimsey wird das bei nächster Gelegenheit mal antesten.
Die ganze Rechnerei ist ja nun, so oder so, ja sowieso eher Pi mal Daumen.
Ich denke auch hier, dass Grimsey sich das jetzt vornehmen wird ...

Gruß
Larry

 

[Heinileini]

Ja, z.Z. können wir alle nur wild drauf los spekulieren.
Solange wir nichts greifbares haben, wird nicht nur die Folie über den Tisch gezogen.
Die Faktoren 2x und 8x regen natürlich auch die Fantasie an, was einen evtl. Tausch des Gebers in der Vergangenheit betreffen könnte ... oder eine Umschaltung der gezählten Flanken pro Periode.

 

[Grimsey]

Heute Wartung...gerade mal die Inkremente pro Umdrehung ermittelt (Rad von Hand gedreht, ist also so ein Schätzwert):

Zählerstand Anfang: -2165246
Zählerstand 1/U : -2168528
Differenz: 3282

Ein Kollege konnte irgendwie das Typenschild entziffern (keine Ahnung wie der das lesen konnte): Hengstler 0523247
Damit weiß ich zwar den Typ, aber das genaue Modell leider nicht. Man kann dort bei der Bestellung ja noch einiges Konfigurieren.

Jetzt muss ich aber mal "dumm" fragen: ich müsste ja jetzt eigentlich ständig die Differenz der Geberwerte berechnen und immer wenn 3282 erreicht sind, den Umfang des Rades zur Wegstrecke addieren, richtig??? Ich stehe gerade etwas aufm Schlauch, sorry.