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

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Grimsey,

ja, Du erfaßt in jedem SPS-Zyklus die Differenz zum Vorgängerzyklus. Und genau dabei mußt Du auch den von Larry angemahnten Überlauf abfangen. (ggf. auch andere Betriebszustände: Rolle läuft rückwärts...)
Jetzt teilst Du den Umfang vom Rad durch 3282 Inkremente, dann hast Du die Strecke pro Inkrement. Diese multimplizierst Du mit Deiner ermittelten Inkrement-Differenz.

Um die Frage von weiter oben: A/B-Zähler oder Spur+Richtung zu beantworten, wäre dann ggf. ein Oszilloskop eine Möglichkeit.

Ich habe diese Karte noch nicht eingesetzt, kenne das aber von anderen Herstellern, daß man explizit noch auf die Eingänge zugreifen kann, nicht nur auf den Zähler. Hier könntest Du Dir ein kleines Programm schreiben, daß die Impulse an den Eingängen erfaßt und Dir dann als Graphen/Trace ansehen. - Alternative zum Oszilloskop...

Gruß
Jens

 

[Larry Laffer]

Hallo Grimsey,
ich sehe das ähnlich wie Jens - du wirst hier das Zählprogramm möglicherweise überdenken müssen.
Was mich allerdings "ein wenig" erstaunt ist die Anzahl der Inkremente für eine Umdrehung. Hier hätte ich tatsächlich einen auf einer Zweirepotenz basierenden Wert erwartet (1024 - 2048 - 4096 etc).
Wie auch immer - die Division des Zählwertes durh 1000 bringt dich hier ja im Leben nicht auf Meter (oder Millimeter oder ...).

Deine Zählerkarte arbeitet im DINT-Bereich (+/- 2 Milliarden und nen Keks). Das heißt hier einfach nur zu dividieren macht keinen Sinn - in dem Moment, wo sie auf dem einen (oder anderen) Endwert angekommen ist, spring sie auf die Gegenseite über (nicht aus Boshaftigkeit sondern weil das innerhalb des Binärzählers so läuft). Das wäre das, was du im Programm abfangen musst, wenn oder falls es geschieht.
Ansonsten für die Streckenerfassung jetzt tatsächlich mit dem "richtigen" Divisor arbeiten. Wenn du hier genauer werden willst dann mach einfach 10 Umdrehungen und bilde davon die Differenz (durch 10) - dadurch wird ein möglicher Fehler kleiner ...

Gruß
Larry

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich danke Euch für Eure Hinweise!

@Larry: ich habe das Rad von Hand gedreht und mir vorher eine Markierung gemacht. Gut möglich das es nicht so genau ist und der Wert deswegen so komisch ist.
Vielleicht hat auch der Geber einfach einen weg....

Ich werde das nach Euren Tipps mal umsetzen und dann beobachten. Ggf. einen neuen Geber bestellen.

 

[Larry Laffer]

... Ggf. einen neuen Geber bestellen.

Das wäre natürlich das Beste - so kommst du aus der Nummer des Ratespiels heraus und weißt dann ja, durch was du teilen mußt ...
Deine Messung sollte jedenfalls genau hinzubekommen sein ...

 

[PN/DP]

Lese in jedem Zyklus den Zählerstand des Zählkanals und bilde die Differenz zum Zählerstand des Zyklus davor. Diese Differenz addiere auf einen zweiten "relativen" Zähler, der beim Start der Längenmessung auf 0 gesetzt wird. Diesen relativen Zählerstand (Inkremente) kannst Du durch die Anzahl "Inkremente pro Meter" teilen und erhältst die Länge in Meter seit der 0-Setzung. Beispielcode in AWL:

      L     Enc_old             //(INT 16 Bit) Zählerstand_vorher
      L     ACT_CNTV            //Zählerstand/Encoderwert jetzt, untere 16 Bit reichen
      T     Enc_old             //als Zählerstand_vorher merken
      TAK
      -I                        //muß -I! braucht keinen WordWrap beachten! funzt automatisch

//hier in AKKU1-L die 16-Bit-Differenz zu Zählerstand vorher ---> auf Relativ-Position verrechnen

      ITD
      L     RelPos              //relative Position (DINT 32 Bit) (bei Mess-Start auf 0 gesetzt)
      +D                        //die Zählerstand-Differenz (+/-) dazu
      T     RelPos              //neue relative Position (Anzahl Inkremente seit 0-Punkt)
      DTR                       //in REAL wandeln
      L     6529.33             //Encoder-Inkremente pro Meter
      /R
      T     RelMeter            //Folienlänge in Meter seit 0-Punkt

Bei z.B. 6529,33 Encoder-Inkrementen pro Meter kann der Code ohne Überlauf bis ca. 320 km abmessen. (Der Zählkanal muß endlos zählen, darf vorwärts und rückwärts.)
Die Berechnung könnte man auch so ändern, daß man die Anzahl Encoder-Elemente je Umdrehung (3282) und den Umfang des Messrades (502,65 mm) einzeln einsetzen kann.

Harald

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Haarscharf am Topic entlang geschrammt:
Zugriffe auf's Forum waren mir gestern verwehrt und ich habe, angeregt durch den Hinweis auf Hengstler, mal dort angegebene (für meine Begriffe überraschend viele) Strichzahlen aus DatenBlättern gesammelt und "verExcelt" (anbei als pdf).
Habe die Zahlen in PrimFaktoren zerlegt bezogen auf die Spalte "x 1". Am häufigsten und mit den höchsten Potenzen kommen die Primzahlen 2, 5 und 3 vor. Die Basen 7 .. 29 treten nur vereinzelt oder gar nicht auf. Danach folgt eine lange SendePause und ein einziger Ausreisser: 157. Verdoppelt man diese Zahl, so hat man 314 (ca. 1 "HektoPi") - aha, ein Versuch, die Kreiszahl in den Geber zu integrieren.
Besser versteckt ist dieser Versuch in der Strichzahl 7854 (mal 4 = 31416).
Wozu diese Versuche, die Kreiszahl mit der Strichzahl anzunähern? Sind das Relikte aus der Zeit als die bzw. manche SPS noch keine Gleitkommazahlen kannten?
Sind diese Strichzahlen wohl vom Hersteller der Geber "in weiser Voraussicht" angeboten worden oder haben einzelne Kunden diese angefordert?

Habe die Zahl 3282 noch in der letzten Zeile hinzugefügt:
3.282 6.564 13.128 2^1*3^1*547^1
Hier fällt nur auf, dass in der Liste der HengstlerWerte die nächst kleinere Zahl 3000 ist und die nächst grössere 3480 ... und, dass der AussreisserPrimFaktor 547 auftritt.
In der Spalte "x 2" ist der nächstliegende Wert 3200.
Ja, an der Zahl 3282 sollte man sich nicht allzu sehr festhalten. Sie ist nach "AugenMass" ermittelt und enthält vielleicht auch noch einen Defekt des Gebers.

Anhang anzeigen DrehgeberStrichzahlen2.pdf

 

[Grimsey]

Habt vielen vielen Dank für Eure zahlreichen und hilfreichen Tipps!

Ich konnte am vergangenen Freitag die Berechnung der Laufmeter anpassen und bin dafür der Berechnung gefolgt, welche @PN/DP aufgezeigt hat.
Das Ganze ist so mathematisch und logisch absolut nachvollziehbar.

Dennoch scheint in dem ganzen System (vermutlich einfach der Geber) ein Fehler zu sein. Wie die ersten Vergleiche heute ergeben haben, wird nun im Schnitt nur noch halb so viel gezählt, wie tatsächlich verbraucht wird.
z.B.: geplanter Verbrauch 449m, tatsächlich erfasst rund 230m...

 

[Larry Laffer]

Ich sehe in Haralds Berechnung nun keinen Fehler ...
Ist RelPos bei dir eine statische Variable (MD, DBD) ... oder ein TEMP ? Letzteres sollte sie nicht sein ...

Ansonsten tatsächlich bei dem Geber mal die Inkremente von mehreren Umdrehungen erfassen und schauen ob das Vielfache von ca. 3282 werden ...

Gruß
Larry

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es liegt ganz sicher nicht an der Berechnung, die passt.
Variablen sind alle statisch.

Donnerstag kann ich wieder ran die Maschine

 

[Heinileini]

Es liegt ganz sicher nicht an der Berechnung, die passt.

Wie sieht denn aktuell Deine Erfassung der Werte von der endlos zählenden Karte und Deine Berechnung aus?
Ein Faktor 2 im Ergebnis legt nahe, dass ...
- die Anzahl der von der Karte gezählten Flanken pro Periode (1 oder 2 oder 4) nicht zur Berechnung passt.
- versehentlich mit Durchmesser statt Radius oder umgekehrt gerechnet wird.
Zur Erinnerung:
Die Division durch 1000 spricht dafür, das 1000 Inkremente pro m entspechend 1 Inkrement pro mm erwartet werden.
Dein Rad hat einen Umfang von ca. 500 mm und macht deshalb pro m 2 Umdrehungen.
Wenn
- der Geber 500 Striche pro Umdrehung hat UND 1 Flanke pro Strich gezählt wird oder
- der Geber 250 Striche pro Umdrehung hat UND 2 Flanken pro Strich gezählt werden oder
- der Geber 125 Striche pro Umdrehung hat UND 4 Flanken pro Strich gezählt werden,
dann würde die Division durch 1000 passen.
Die ermittelten 3282 Inkremente pro GeberUmdrehung passen so gar nicht ins Konzept, es sei denn, da wird noch irgendwo etwas gerechnet, was wir bisher nicht nachvollziehen können.
Gibt es noch eine weitere Stelle in der Software, wo der Zählerwert weiter umgerechnet wird oder soll der durch 1000 dividierte Wert bereits der in m umgerechnete sein?
Was wird da mit dem SW-Gate gemacht?
Hast Du eine Doku der ZählerBaugruppe, evtl. als pdf und könntest sie hier einstellen?
Wurde irgendwann der Geber gegen einen mit anderer Strichzahl getauscht?
Wurde das MessRad irgendwann gegen eines mit anderem Durchmesser getauscht?

Tipp: Es soll SchaltSchränke geben, in denen man eine Kladde findet, in der ServiceEinsätze und sogar Umbauten dokumentiert oder zumindest "angedeutet" sind. Manchmal wissen auch die Bediener der Maschine oder ServicePersonal des Kunden viel besser um solche Details Bescheid, als man ihnen zutraut.

 

[PN/DP]

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

Da kann ich mir vorstellen daß Radius/Durchmesser verwechselt wurde oder falsch gemessen wurde oder es war nur eine halbe Umdrehung oder 2.
Als "zweite Meinung" mal ein Messband oder eine Schnur um das Rad legen und die Schnurlänge messen.

Kannst Du nicht auf dem Rad und auf der Folie einen Strich machen und nach einer (besser: mehreren) Umdrehung(en) wieder einen Strich auf der Folie machen und den Abstand der Striche auf der Folie messen?

Harald

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

der durch 1.000 dividierte Wert wird bisher direkt als m-Wert benutzt. Es erfolgen darauf keine weiteren Zugriffe und es wird auch nur an der in Post #1 gezeigten Stelle im Programm verwendet.

die Zählerbaugruppe ist irgendeine uralte VIPA-Speedbus Baugruppe. Wie schon in den ersten Posts geschrieben habe ich dazu keinerlei Doku. Die Hardwarekonfiguration der Zählerkarte über Config-Stage zeigt und nur das, was in den Screenshots in Post #1 zu sehen ist.
Ich habe 2019 hier im Werk angefangen. In dieser Zeit wurde der Geber nicht getauscht. Ob ein Tausch davor erfolgte, kann hier keiner mehr sagen bzw. gibt es niemanden, der das noch wissen könnte.
Das Messrad wurde ebenfalls nicht getauscht, solange ich hier bin. Über die Zeit davor kann auch wieder niemand etwas sagen.

Schaltungsunterlagen und Doku sind vielleich zu 25% vorhanden bzw. aktuell. Die ganze Anlage wurde in den letzten Jahren so gut wie nicht gepflegt, mal ganz abgesehen von der Doku oder eventuellen Änderungsunterlagen.

Ich werde jetzt ein neuen Geber bestellen und den einbauen. Dann weiß ich wenigstens ganz genau, wie der zählen soll und kann die Berechnung darauf hin anpassen.

@Harald: doch das könnte ich natürlich noch überprüfen. Allerdings erst am Donnerstag, wenn die Anlage wieder für die Wartung steht.
Ich bin sehr sicher, dass ich letzte Woche genau 1 Umdrehung gemacht. Aber das kann ich ja ohne Weiteres auch noch ein 2. oder 3. mal überprüfen.
Durchmesser des Laufrades sind 160mm. Mit U = Pi*d ist U = 502,65 mm (wenn ich nicht zu doof bin).
Eine Verwechslung von Durchmesser/Radius schließe ich damit aus.