Handrad (KPT700F Mobile HW/OR) an Simotion

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Grüßle

In den Beispielapplikationen und in den realen Maschinen sind häufig Handräder verbaut, die durch einen Absoluwertgeber mit Drive-Clique oder durch einen gewöhnlichen Inkrementalgeber dargestellt sind. Dieser lässt sich relativ easy als Master benutzen und ich kann eine Achse damit synchron fahren.

Jetzt möchte der Kunde gerne ein Mobile-Panel mit Handrad einsetzen. Gleich ergeben sich daraus mehrere Probleme.

1. Das Handrad ist kein richtiger Geber, sondern liefert mir bloß "Impulse" im E/A-Bereich:

Bitzuordnung des Handrads
– Für das Handrad ist kein Sollwert vorgegeben.
– Nach dem Hochlauf des Bediengeräts werden die Bytes "n+4" bis "n+5" auf Null gesetzt.
Die Drehung des Handrads erzeugt abhängig von der Drehrichtung positive oder negative Impulse. In
den Bits I0 bis I7 wird die Anzahl positiver Impulse abgelegt. In den Bits D0 bis D7 wird die
Anzahl negativer Impulse abgelegt. Die Werte werden binär eingetragen, wobei Bit 0 das
niederwertigste und Bit 7 das höherwertigste Bit ist.
Eine vollständige Handraddrehung ergibt 50 Impulse.
– Jeder Impuls des Handrads wird je nach Drehrichtung auf das entsprechende Byte "n+4" oder
"n+5" addiert. Es gibt dabei keine negativen Werte. Wenn der mögliche Wertebereich überschritten
wird, erfolgt ein Überlauf:
Wenn der Wert 255 um einen Impuls erhöht wird, dann ergibt dies den Wert 0.

Wenn ich aber eine Achse synchron auf einen Master mitlaufen lassen möchte, dann muss ich aber ein TO-"Externer Geber" anlegen. Ich hatte zwar - in einer Applikation - den Fall, daß ein externer Geber mit numerischem Istwert über eine Variablenschnittstelle versorgt wurde. Jedoch hatte dort der Leitwert vernünftige Werte zwischen 0° und 360° gehabt, und nicht diesen seltsamen Krempel wie da oben.

Hat jemand schon mal das Handrad vom MobilePanel in der Applikation als Master angelegt, und wie ist er dabei vorgegangen ?

 

[Heinileini]

1. Das Handrad ist kein richtiger Geber, sondern liefert mir bloß "Impulse" im E/A-Bereich:

Bis hierhin klingt das ja gar nicht sooo übel, vorausgesetzt, man kann die Impulse schnell genug nachvollziehen.
Aber dann kommt das dicke Ende. Damit man einen begrenzten Teil die Historie der verpassten Impulse rekonstruieren kann:

Die Drehung des Handrads erzeugt abhängig von der Drehrichtung positive oder negative Impulse. In
den Bits I0 bis I7 wird die Anzahl positiver Impulse abgelegt. In den Bits D0 bis D7 wird die
Anzahl negativer Impulse abgelegt. Die Werte werden binär eingetragen, wobei Bit 0 das
niederwertigste und Bit 7 das höherwertigste Bit ist. ...

Es artet wirklich aus, das wieder in eine verwertbare Form umzuwandeln. Nicht unmöglich, aber ein praktikabler ShortCut will mir dafür gerade auch nicht einfallen ...
Die Zuwächse der beiden ZählerBytes verarbeiten, d.h. die beiden Zuwächse subtrahieren und zum (noch nicht weiter verarbeiteten) Rest der zuvor ermittelten Differenz addieren. Zu guter Letzt (vermutlich) noch die Differenz in eine A-/B-SignalFolge um wandeln ...

 

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Letzten Endes brauche ich ja nur einen REAL-Wert der von 0° bis 360° geht, aber stetig, also ohne harte Sprünge. Dann kann ich das mithilfe von einem Trick dann als "Istwert" eines TO- "ExternerGeber" einspeisen und verarbeiten.

 

[Heinileini]

Letzten Endes brauche ich ja nur einen REAL-Wert der von 0° bis 360° geht, aber stetig, also ohne harte Sprünge.

"ohne harte Sprünge" bedeutet was genau? Wie "hart" wäre noch vertretbar?
Man könnte die Ausgabe über Rampen "glätten". Aber bezüglich des vermeintlich harten Sprunges von 359,x° nach 0°, der mechanisch ein kaum wahrnehmbarer ist, müsste man dafür Sorgen, dass die Rampen nicht eine Drehung in der falschen Richtung vorgaukeln.

 

[NBerger]

Aus den beiden Zählwerten eine Position 0-360° generieren dürfte mit ein wenig Nachdenken kein Problem sein...

Für den kontinuierlichen Wert solltest du keinen externen Geber anlegen sondern eine simulierte Achse und die dann jeweils auf die Position fahren lassen (relativ). Die Geschwindigkeit ergibt sich dann aus v= ds/dt.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe mich beim alten Mobile Panel 277 schon gefragt, warum für positiv und negativ drehen jeweils ein eigenes Byte verwendet wird. Ich habe es mir damals auch so programmiert, dass ich einen INT habe der in beide Richtungen zählt.

 

[Draco Malfoy]

Wie DeltaMikeAir korrekt schreibt, es artet wieder aus. Ich versteh es wirklich nicht - weshalb man an dieser Stelle nicht einen wirklichen profinetfähigen Geber im Panel verbaut hat, den ich dann für jeden beliebigen Zweck verwenden kann. Und weshalb - wenn es denn schon kein PN-Geber werden sollte - dann nicht eine Library gibt, die mir aus diesen seltsamen Bytes und Inkrementen einen adaptionsfähigen Leitwert bereit stellt. Ich verstehe es nicht warum es jeweils so kompliziert sein sollte. Ich habe in dem Projekt schon zahlreiche Bibliotheken neu geschrieben und jetzt will ich bloß ein scheinbar triviales Problem lösen, also das Handrad so einbinden, daß ich den Transfer damit von Hand durchfahren kann, wie mit einem virtuellen Leitwert. Und schon wieder muß ich eine Doktorarbeit schreiben.

 

[zako]

... ein Drehzahlgleichlauf reicht nicht?
Ansonsten kann man das Telegramm 81 konfigurieren und man muss den XIST1 selbst versorgen - zumindest macht man das bei der S7-1200 / 1500 so, wenn man mit dem TO geberlos positioniert, siehe

SIOS

support.industry.siemens.com

Ich vermute, dass SIMOTION hier ähnliche Flexibilität bietet.

 

[gangsterbob]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du kannst einen Trajektoriengenerator mit Dynamikbegrenzung davor hängen. Bei manchen Herstellern gibt es sowas als FB… So mache ich es immer bei Sensorsignalen die direkt auf einen Antrieb einfluss nehmen.

 

[Draco Malfoy]

Hallo ZAKO,

kennst du dich denn im Detail mit der Simotion aus ? Kennst Du vielleicht die Applikation LPresH ?

Bezüglich der TLG81 und Trajektoriengenerator: Ich kann die Begriffe zwar jeweils für sich einordnen, aber im Kontext der Simotion nichts mit ihnen anfangen. Auf der Simotion verschalte ich keine Telegramme, das macht die DO-TO Verschaltung automatisch. Ich kann aber, wie erwähnt, sehr wohl einen Geber anlegen, der seinen Istwert von einer Variablen bezieht. Dafür gibt es einen entsprechenden Trick.

Das Gebersignal sollte allerdings stetig und hinreichend hochauflösend sein. Sonst funktioniert die Gleichlaufkopplung nicht.

 

[DeltaMikeAir]

Wenn die Auflösung hinreichend hochauflösend sein soll ist das Handrad doch eh nicht verwendbar. Das liefert doch pro Umdrehung nur 200 Impulse pro Umdrehung soweit ich mich erinnere.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn die Auflösung hinreichend hochauflösend sein soll ist das Handrad doch eh nicht verwendbar. Das liefert doch pro Umdrehung nur 200 Impulse pro Umdrehung soweit ich mich erinnere.

Oh Michael, was hat denn die Hitze mit Dir gemacht?

Die Impulse (bzw. die 4 Flanken pro Periode des A-/B-Signals) sind doch die kleinste denkbare Einheit und wen interessiert schon, wieviele Umdrehungen dem Bediener abverlangt werden?

 

[DeltaMikeAir]

Oh Michael, was hat denn die Hitze mit Dir gemacht?

Die Impulse (bzw. die 4 Flanken pro Periode des A-/B-Signals) sind doch die kleinste denkbare Einheit und wen interessiert schon, wieviele Umdrehungen dem Bediener abverlangt werden?

Das Handrad hat kein AB Signal.
Es ist auch kein frei drehendes Handrad sondern "klickt" von einer Position zur nächsten. Damit eine glatte Bewegung zu erzeugen halte ich für äußerst schwierig

 

[Heinileini]

1. Das Handrad hat kein AB Signal.
2. Es ist auch kein frei drehendes Handrad sondern "klickt" von einer Position zur nächsten. Damit eine glatte Bewegung zu erzeugen halte ich für äußerst schwierig

Zu 1.:
Aber zwei 8-BitZähler. Einen für die Vorwärts- und einen für die Rückwärts-Impulse.
Kann man häufig genug auf diese Zähler zugreifen, so kann man "zeitnah" die Impulse des Handrads rekonstruieren.
Treten mehrere Inkremente zwischen den Zugriffen auf, so werden diese gepuffert und lassen sich zwar nicht im Detail (ich meine damit die Reihenfolge der Vorwärts- und Rückwärts-Impulse), aber im "EndEffekt" richtig dekodieren. Allerdings kann es hierbei zu den gefürchteten Sprüngen kommen.
Werden die Sprünge zu gross, so sollte man anstreben, die beiden ZählerStände häufiger auszuwerten.
Sind die Sprünge dann immer noch zu gross, dann man "interpolieren", indem man Rampen bildet.

Zu 2.:
Ich weiss nicht, ob Du mit "klicken" das meinst, was ich darunter verstehe. Das Einrasten des Handrades auf z.B. 200 (?) Positionen pro Umdrehung ist doch eigentlich normal. Damit soll u.a. die "Unwucht" des als Kurbel ausgeführten Rades abgefangen werden, damit nicht die Schwerkraft die Kurbel in Bewegung versetzt. Und der Bediener fühlt die eingegebenen Inkremente und muss nicht dauernd auf eine Skala oder einen angezeigten PositionsWert schielen.
Das Thema "glatte Bewegung" wird m.E. durch das "Klicken" nicht beeinflusst, sonst wären Generationen von Handrädern unbrauchbar gewesen. Hier wird m.E. nur gefordert, dass zwischen zwei Zugriffen auf die Zähler sich nicht zig Impulse ansammeln können.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Heinrich, das Handrad des Mobile Panel hat aber nicht 200 Stellungen pro Umdrehung sondern nur 19.
Also fast 20° pro "Klick"
Da sieht die Welt wieder etwas anders aus als bei einem Sinumerik Maschinensteuertafel Handrad.

Daher kann man dies auch nicht als "vollwertiges" Handrad ála Sinumerik verwenden...


Aus dem Handbuch:

 

[Heinileini]

Heinrich, das Handrad des Mobile Panel hat aber nicht 200 Stellungen pro Umdrehung sondern nur 19.
Also fast 20° pro "Klick"

Donnerwetter! Ich habe ja gar nicht geahnt, dass Siemens sooo kreativ sein kann.
Das wäre ja 1 Klick zu viel, um zu 360° zu passen und 1 Klick zu wenig, um zu 400 "NeuGrad" zu passen.
Na ja - you can't have a cake and eat it - immerhin ist es exakt der MittelWert aus den beiden naheliegenden Zahlen 18 bzw. 20.
Wirklich 19 Klicks pro Umdrehung? Ausgerechnet eine Primzahl? Ich komme aus dem Staunen nicht mehr heraus.
Da musste Siemens wohl unbedingt mit seinen siemmensen Fähigkeiten strotzen!?
Wie heutzutage so oft bei Siemens, waren da Fachleute am Werk, die von allem eine Ahnung haben, ausser von dem, was gebraucht wird.
Oder denke ich einfach zu altmodisch? Zu S5-mässig?

Häwenaissuiikend - trotzdem!

 

[rostiger Nagel]

Donnerwetter! Ich habe ja gar nicht geahnt, dass Siemens sooo kreativ sein kann.
Das wäre ja 1 Klick zu viel, um zu 360° zu passen und 1 Klick zu wenig, um zu 400 "NeuGrad" zu passen.

360 Grad erreicht man bei einer Achse eigentlich nicht,
die springt nach 359 wieder auf 0

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

360 Grad erreicht man bei einer Achse eigentlich nicht,
die springt nach 359 wieder auf 0

Und trotzdem hat eine " volle" Umdrehung 360° (DEG) bzw. 400 "NeuGrad" (GRD), wenn auch die ZahlenWerte 360 bzw. 400 im ModuloBetrieb - oh Wunder - nie erreicht werden.
Na und? Was sagt uns das?
Obwohl Du natürlich Recht hast, Helmut, verstehe ich Deinen Einwand leider nicht.

Um von 0° in ein und derselben Richtung wieder auf 0° zu drehen, muss ich um n Abstände zwischen benachbarten Raststellungen drehen, um dann wieder den AusgangsPunkt zu erreichen, der allerdings der n+1ste RastPunkt auf dieser Tour ist.
Das ist irgendwie ein Bisschen blöd zu formulieren. Wahrscheinlich ist das der wahre Grund dafür, dass sich Siemens zu der Einteilung mit den 19 RastPunkten hat hinreissen lassen ...

PS:
Ist das denn wirklich so mit den 19 RastPunkten oder hat sich die Doku-Abteilung auf's Glatteis führen lassen?

PPS:
Oder ein GetriebeFreak hat die Primzahl 19 ausgeguckt, von Wegen der gleichmässigen Abnutzung der Zähne?

PPPS:
Oder es war ein FAN von GleitpunktZahlen.

 

[DeltaMikeAir]

Da könnte man jetzt noch tagelang philosophieren, das bringt den Themenstarter aber auch nicht weiter.

 

[zako]

... kann man das Handrad "endlos" drehen?
Der Xist1 im Tel.81 macht auch einen Modulo - allerdings bei DINT Überlauf - irgendwas mit +/-2^31
Wie "feinfühlig" muss das denn sein? Wenn man "gradgenau" an der Last positionieren will, dann muss man eben schon min. Ca. 20 Handradumdrehungen machen, damit die Last eine Umdrehung macht. Eigentlich sagt man dass man min. Faktor 4 noch höher auflösen sollte als die geforderte Genauigkeit. Aber dann müsstest Du das Ding schon 80x drehen? Aber je öfter man drehen muss, desto feiner kann man auflösen.
Bei der S7-1200/1500 würde ich das über die Möglichkeit der Datenbausteinanbindung machen. Vermutlich geht so was ähnlich bei SIMOTION - aber da kenne ich mich nicht so genau aus.