Verhalten von Zählern an VIPA CPU314

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen,

an einer unserer älteren Anlagen sind 2 Messräder zur Verbrauchserfassung von Folien angebracht.
Die Messräder sind mit Gebern/Encodern ausgestattet, welche auf 2 Zähleingänge einer VIPA 314-6CF02 mit einer SpeedBus-Karte angeschlossen sind.
Im Programm werden die Zählerwerte ausgelesen und in einen Datenbaustein geschrieben.
Ein OPC-Server liest die Werte aus und meldet sie an eine MDE-Software.
Ich habe vor einigen Tagen die Rückmeldung bekommen, dass die dort gebuchten Verbräuche sporadisch extrem von den eingeplanten Werten abweichen (Faktor 5 und mehr).
In den Logfiles ist ersichtlich, dass das MDE tatsächlich recht große Zählerwerte ausgelesen hat.

Ich habe mir dann die Werte mal selbst ausgelesen und schreibe diese in eine Datenbank.
Dort kann ich nun auch nachvollziehen, dass die Werte sporadisch extreme Sprünge machen und dann wieder auf sinnvolle Werte zurückfallen. Teilweise bleiben die Zähler auch für mehrere Stunden, manchmal nur für 30 Minuten auf diesen sinnfreien Werten.
Wenn man sich die Werte in der Datenbank anschaut, bekommt man den Eindruck als würden die Werte innerhalb der CPU überschrieben oder verschoben werden. Was, meiner Meinung nach, aber eigentlich nicht sein kann. Querverweise und überlappende Speicherzugriffe habe ich gecheckt.
Den DB aus dem ich die Werte auslese ist neu eingefügt.

Meine Frage: verhalten sich die Zähler einer VIPA-CPU irgendwie anders? Was könnte ich noch übersehen?

Danke für Eure Hilfe und Anregungen im Voraus!

 

[PN/DP]

Wo in Deinem Log sind denn die extremen Sprünge?
Wie zählen die Zähler?

Ich kenne Deine VIPA nicht. Ist die Adresse PED124 korrekt? Liefert der Zähler 32-Bit-Werte oder nur 16-Bit? Müssen evtl. noch Bits ausgeblendet werden?
Werden FC201 und FC202 im selben OB aufgerufen? Werden sie evtl. mehrmals aufgerufen?
Werden die im FC202 verwendeten Variablen an mehreren Stellen beschrieben? Oder die Adressen der Variablen (eventuell überlappend) noch woanders beschrieben?
Verwendet der OPC-Server die korrekten Adressen und Datentypen der Variablen?

Harald

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo PN/DP,

danke für Deine Rückmeldung.
Die großen Sprünge sieht man in den zwei Bilder meiner Antwort (ich konnte gestern nur 5 Bilder anhängen).
Einer der Zähler liegt auf dem PED124.
Der Zähler liefert meines Wissens nach 32-Bit-Werte. Im Handbuch zur Vipa steht sinngemäß: Eingangsdaten Startadresse....+16 = Doppelwort = Zählerwert/Latch
Im FC202 kopiere ich die Werte nur aus dem DB101 in den DB202.
Im FC101 wird der Zähler aus dem PED124 ausgelesen, umgerechnet und in den DB101 geschrieben.
FC101 und FC202 werden im selben OB aufgerufen. Die Eingangsadressen werden auch nur dort verwendet und nirgendwo anders beschrieben.

Das Programm habe ich so vom Anlagenlieferanten übernommen, die Anlage läuft seit gut 20 Jahren so. Das Verhalten ist jetzt im Zuge der Einführung von SAP aufgefallen. Gut möglich, dass es schon immer so ist.

 

[PN/DP]

Ich habe mir dann die Werte mal selbst ausgelesen und schreibe diese in eine Datenbank.

Wie liest Du die Werte selber aus? Sind die Sprünge bzw. viel zu großen Zahlen schon in den DB in der SPS?
Du könntest im FC202 die Zählerwerte zusätzlich auf vorher noch nie benutzte Variablen kopieren (am besten neuen DB anlegen) und vergleichen, ob diese Kopien auch falsche Werte haben.
Zeige uns mal den FC202 ohne Symbolik (oder Symbolik + Adressen), so daß man die verwendeten DB-Adressen sieht.

Falls die falschen Zahlen nicht im DB sind, sondern erst im MDE: Verwendet der OPC-Server die korrekten Adressen und Datentypen der Variablen?
In den DB in Deiner SPS scheinen die Zählerwerte DINT (32-Bit Ganzzahl) zu sein. Nicht daß der OPC-Server die Zählerwerte als LINT (64-Bit) liest und dadurch eine Überlappung mit dem davor oder danach liegenden Speicherbereich hat.

Weiters hatte ich gefragt wie die Zähler zählen. Sind das fortlaufende Zähler, oder messen die irgendwas über einen (kurzen?) Zeitraum mit regelmäßigem Rücksetzen und Neustarten der Zähler? Hast Du mal einen Link zu dem VIPA-Handbuch, wo die Verwendung der Zähler erklärt wird?

Harald

 

[PN/DP]

In Deinem ersten Bild in Beitrag #1 ist die Rede von "Setzwert übernehmen" - kann es sein, daß das SPS-Programm direkt die Zählerstände fehlerhaft/unerwartet beeinflußt? Kannst Du das Zähler-Setzen mit dem Ladewert deaktivieren und schauen, ob die Sprünge dann immer noch auftreten?

Harald

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo PN/DP,

also ich versuche mal die nicht beantworteten Fragen zu beantworten:
die Zähler sind so eingestellt, dass sie endlos zählen (müsste auch im 1. Beitrag auch ein Screenshot sein).
Ich selbst lese die Werte über eine .Net-Anwendung mittels der Bibliothek S7.Net+ aus, was bei ich bereits bei 6 anderen Produktionsanlagen mache und sich bewährt hat. Mein Auslesen ist also unabhängig vom OPC-Server des Lieferanten (auf den ich leider auch keinerlei Zugriff habe).
Leider kann ich bis jetzt auch nicht nachvollziehen, ob die Wert bereits im DB so "falsch" stehen (ich gehe aber davon aus) da ich hier auch noch mit anderen Aufgaben betraut bin und das System nicht ständig beobachten kann und der "Fehler" nur sporadisch auftritt.

Soweit ich das alte Programm nachvollzogen habe, wird der Setzwert an keiner Stelle im Programm benutzt. Der Programmteil ist geschrieben, korrekt. Der dafür notwendige Ausgang A115.5 wird, laut Querveweise, aber an keiner Stelle im Programm außer im FC 201 benutzt und dort nur lesend und rücksetzend.
Ich kann das allerdings einfach mal auskommentieren und schauen was passiert, danke für den Hinweis!

Im Anhang noch das Handbuch zur VIPA. Kapitel 05 ab Seite 129 im PDF ist alles zu den Zählern.
Ich habe jetzt auch schon alles gelesen und mit dem Programm verglichen. Kann aber erstmal keinen Fehler sehen.

Weiterhin noch ein Bild nur mit absoluter Adressierung.

Vielen Dank für Deine Unterstützung!

 

[Heinileini]

Zu den Bildern aus #3:
Dort, wo die Sprünge zu sehen sind, wechselt der Zählwert entweder von der einen Spalte in die andere oder von der anderen in die eine. Das verstehe ich überhaupt nicht. Woher weiss ein Zähler, welchen Zählerstand der andere erreicht hatte und warum springt der andere?
Warum 2 Spalten mit Zählerwerten aber nur 1 Geschwindigkeit? Wo kommt die Geschwindigkeit her?

 

[Grimsey]

Die Geschwindigkeit ist die Anlagengeschwindigkeit, die gibt es nur 1x.
Die Zähler sind Verbrauchszähler von Folien, welche über je 1 Messrad mit Geber erfasst werden.

Warum die Zähler springen und zu verrutschen scheinen, versuche ich ja gerade herauszufinden.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soweit ich das alte Programm nachvollzogen habe, wird der Setzwert an keiner Stelle im Programm benutzt. Der Programmteil ist geschrieben, korrekt. Der dafür notwendige Ausgang A115.5 wird, laut Querveweise, aber an keiner Stelle im Programm außer im FC 201 benutzt und dort nur lesend und rücksetzend.

Vielleicht setzt irgendwas den Ausgang über Kommunikation, z.B. HMI/Panel?
Weise dem Ausgang in jedem Zyklus fest 0 zu. Ich empfehle so:

[...]
      S     M   104.1

//M001: NOP   0

[COLOR="#FF0000"]      SET
      R     A   115.5[/COLOR]

... oder noch besser das Rücksetzen am Ende des OB1 (Hat die VIPA einen Zykluskontrolpunkt für Kommunikation?)

Harald

 

[Grimsey]

Ich werde das mal so reinmachen und schauen, wie sich die Werte verhalten.
Gerade heute, da ist Stillstand, habe ich kleinere Sprünge von +2 bzw +5 aufgezeichnet ohne das die Maschine und damit das Messrad sich bewegt haben......

Vielleicht auch ja auch einfach nur der Geber einen weg....?

 

[Heinileini]

Was ich auch nicht verstehe: es war ausschliesslich von PED 124 die Rede, aber von 2 MessRädern und 2 Zählern. Wo/wie wird der andere Zähler eingelesen? Z.B. von PED 120 oder PED 128?
Die Springereien zwischen den Spalten in den Bildern aus #3 kommt mir so vor, als ob wir (De-)Multiplexer bei der Arbeit beobachten: ein und derselbe Zähler wird mal in der einen und mal in der anderen Spalte dargestellt. Welche Bedeutungen die jeweils andere Spalte dann hat, ob wir tatsächlich immer beide Zähler sehen, das steht anscheinend in den Sternen? Haben wir es mit einem "Wackler" bei einem der AdressBits (AdressBit 2 oder höher?) zu tun?

PS:

Vielleicht auch ja auch einfach nur der Geber einen weg....?

Der Geber? Gibt es nicht je Messrad 1 Geber?

PPS:
Der Sprung eines Zählerstandes in die andere Spalte ist auch auf Bild 5 von #1 zu sehen.

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe beispielhaft nur den Programmcode von einem der Geber gezeigt, weil der andere Geber identisch arbeitet und nur auf eine andere Variable im DB geschrieben wird.
Der 2. Geber liegt im PED132.
Und ja es gibt 2 Messräder mit je einem Geber......ich hab nur "laut gedacht" ob nicht der/die Geber einen kleinen Schaden haben könnten...

 

[PN/DP]

Ich selbst lese die Werte über eine .Net-Anwendung mittels der Bibliothek S7.Net+ aus

Von welchen Adressen liest Du die Werte?
Wo kommt der Zaehlwert1 in Deinem Log her (Beitrag #3 Bild2) ? Ist das der Wert eines Zählkanals (PED132 ?) durch +/-1000 dividiert? Dann kann eigentlich nie ein Wert 10.811.65? rauskommen, sondern nur ein Wert von +/-2.???.??? oder höchstens +4.???.???, aber nicht +10.???.??? - das würde für einen Fehler außerhalb des Zählkanals sprechen (nachträgliches Überschreiben der Variable im DB oder Fehler in der Kommunikation beim Auslesen der Werte für das Log).

Leider kann ich bis jetzt auch nicht nachvollziehen, ob die Wert bereits im DB so "falsch" stehen (ich gehe aber davon aus)

Das solltest Du klären, um zu sehen wo der fehlerhafte Wert herkommt.
Ist es ein Problem in der Kommunikation der SPS oder ist es eine Fehlfunktion im Anwenderprogramm. Springt der Zähler selber oder werden nur die Kommunikationsvariablen verfälscht.
Hast Du mal den Programmteil im FC201 beobachtet, ob da schon der "gesprungene" Wert aus dem PED124 gelesen wird? Wird der Code von FC201 und FC202 immer ausgeführt?

Wenn tatsächlich der Zähler beeinflußt wird:
Werden im Programm die SFC 55/56/57/58 verwendet mit den Datensätzen 83h, 89h, 87h, 8Dh, 9Ah, 9Bh?
Gibt es im Programm indirekte Adressierung, die vielleicht aus dem Ruder läuft?

Passieren die Sprünge vielleicht immer in den ersten Sekunden nach Netzspannung-Ein der SPS?
Warum sind da Programmteile für Setzen und Reset des Zählers vorhanden? Wurden diese Funktionen unvollständig/unsachgemäß entfernt? Oder sind sie in einem HMI vorhanden, was die Funktionen manchmal (ungewollt?) auslöst?

Warum wird der Zählerstand PED124 durch -1000 geteilt? Läuft der Zähler rückwärts, warum hat der Programmierer in der Zählerparametrierung nicht die Zählrichtung invertiert?

Sind die von den Zählern verwendeten Digitaleingänge mit irgendwelchen Zählfunktion-fremden Signalen belegt?
E+0.1 Zähler0(B)
E+0.2 Gate0/Latch0/Reset0
E+0.4 Zähler1(B)
E+0.5 Gate1/Latch1/Reset1

Gibt es bei VIPA Firmware-Updates-Beschreibungen der 314-6CF02?

Harald

 

[Grimsey]

Hallo zusammen,

nachdem ich gestern und heute morgen nicht wirklich dazu kam, will ich Euch jetzt mal einen aktualisierten Stand geben:
@PN/DP danke für Deine Hinweise. Die Werte in meinem Log lese ich aus dem DB202 aus. Mit Deinem Hinweis auf den maximalen Zahlenbereich hat es bei mir dann auch endlich mal gefunkt.
Ich hatte, Gott sei Dank, auch am Montag die Möglichkeit, die Zählerstande in der SPS zu prüfen. Zu diesem Zeitpunkt wurden wieder verschobene und riesig große Werte in der Datenbank erfasst.
In der SPS waren die Werte aber vollkommen korrekt, also nicht verschoben und nicht riesig groß sondern im Bereich < 1.000.

Ich habe dann mein Log-Programm mal gestoppt und neu gestartet und siehe da, standen die ab dann mitgeschriebenen Werte korrekt in der Datenbank.
Also habe ich mein Log-Programm dahingehend angepasst, dass ich die Verbindung zur SPS nur aufbaue, wenn ich auch loggen will. Zuvor hatte ich die Verbindung beim Programmstart auf- und beim Schließen des Programmes abgebaut.
Seitdem ich diese Änderung vorgenommen habe, kam es zu keinen Sprüngen/Verschiebungen oder ähnlichem mehr.

Weshalb die Zählerwerte durch -1000 geteilt werden, weiß ich nicht. Ich habe das Programm leider nur in der so unkommentierten Version, der Anlagenlieferant ist nicht mehr verfügbar.
Ebensowenig weiß ich, weshalb die Programmteile für Setzen und Reset der Zähler vorhanden sind. Das alles entzieht sich meiner Kenntnis und ich sehe auch keine Möglichkeit, dies noch herauszufinden. Ist schade aber bei so einer betagten Anlage wohl leider nicht mehr zu ändern.

Ich werde das jetzt mal noch ein bisschen beobachten aber ich denke/hoffe, dass es mit der oben genannten Änderung nun passt.

Danke für Euer Mitdenken!