# Handrad (KPT700F Mobile HW/OR) an Simotion



## Draco Malfoy (13 Juni 2021)

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
> ...



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 (16 Juni 2021)

Draco Malfoy schrieb:


> 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 (16 Juni 2021)

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 (16 Juni 2021)

Draco Malfoy schrieb:


> 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 (16 Juni 2021)

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 (16 Juni 2021)

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 (17 Juni 2021)

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 (17 Juni 2021)

... 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 (17 Juni 2021)

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 (18 Juni 2021)

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 (18 Juni 2021)

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 (18 Juni 2021)

DeltaMikeAir schrieb:


> 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 (18 Juni 2021)

Heinileini schrieb:


> 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 (19 Juni 2021)

DeltaMikeAir schrieb:


> 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 (19 Juni 2021)

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 (19 Juni 2021)

DeltaMikeAir schrieb:


> 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 (19 Juni 2021)

Heinileini schrieb:


> 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 (19 Juni 2021)

rostiger Nagel schrieb:


> 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 (19 Juni 2021)

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


----------



## zako (20 Juni 2021)

... 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.


----------



## DeltaMikeAir (20 Juni 2021)

Guten Morgen Zako,
das Handrad kann man endlos drehen, es liefert aber nur zwei Bytes als Info zurück.
Das eine Byte zählt die Drehimpulse im Uhrzeigersinn, dass andere Byte die Impulse gegen den Uhrzeigersinn.

Warum es zwei eigenständige Bytes sind und nicht ein INT der in beide Richtungen zählt habe ich noch nicht verstanden. Das war beim x77 Mobile Panel auch schon so.


----------



## Heinileini (20 Juni 2021)

Richtig, Michael, Schluss mit Philosophieren und Ärmel hochkrempeln!

Habe mal was in Excel-VBA ausprobiert und dann noch auf die Schnelle in (Pseudo-?)SCL umformuliert:


```
VAR_IN
    iiZhlPls : INT  ; // MoPa-SST Handrad ZählerByte für '+'
    iiZhlMin : INT  ; // MoPa-SST Handrad ZählerByte für '-'
END_VAR

VAR_OUT
    orPosIst : REAL ; //
END_VAR

VAR_STATIC
    siZhlPls : INT  ; // "FlankenMerker" von ZählerByte für '+'
    siZhlMin : INT  ; // "FlankenMerker" von ZählerByte für '-'
    siPosSol : INT  ; // "FlankenMerker" von "SollPositon"
    siPosIst : INT  ; // "FlankenMerker" von "geglättete SollPositon"
END_VAR

VAR_TEMP
    tiKorr   : INT  ; // KorrekturWert bei Überläufen der ZählerBytes
    itSGN    : INT  ; // Vorzeichen für die "Entschleunigung" des Ergebnisses
END_VAR

If iiZhlPls < siZhlPls Then tiKorr := 256 ; Else tiKorr := 0 ; End_If ;  // Korr bei ZhlPls-Überlauf
If iiZhlMin < siZhlMin Then tiKorr := tiKorr - 256 ; End_If ;            // Korr bei ZhlMin-Überlauf
siPosSol := siPosSol + ( iiZhlPls - siZhlPls ) - ( iiZhlMin - siZhlMin ) + tiKorr ; // neue SollPos

IF siPosSol > siPosIst THEN         // zum "Glätten" Vorzeichen von 'siPosSol - siPosIst' ermitteln
    itSGN := 1 ;
ELSIF siPosSol < siPosIst THEN
    itSGN := -1 ;
ELSE
    itSGN := 0 ;
END_IF ;
siPosIst := siPosIst + itSGN ;      // neue, geglättete SollPos

siZhlPls := iiZhlPls ;      // akt. Zustand von ZhlPls speichern für Vergleich beim nächsten Aufruf
siZhlMin := iiZhlMin ;      // akt. Zustand von ZhlMin speichern für Vergleich beim nächsten Aufruf

orPosIst := INT_TO_REAL(siPosIst) ; // hier ggfs skalieren ?
```

Edit: Habe im Code '16' in '256' geändert!
(Die '16' war die Simulations-Version von 4-Bit-Zählern für Faule  )


----------



## Heinileini (20 Juni 2021)

Sorry, da die Variablen-Namen wohl ohnehin noch "angepasst" werden, habe ich darauf verzichtet, die NamensBestandteile 'Ist' in etwas weniger Irreführendes zu ändern. Gemeint ist damit der geglättete ("entschleunigte") SollWert.

PS:
Eine SIGN-Funktion habe ich in SCL nicht gefunden und ersatzweise mit IF..ELSIF..ELSE "umschrieben".
Eleganter wäre schlicht und einfach ...

```
siPosIst := siPosIst + Sign(siPosSol - siPosIst) ;  // neue, geglättete SollPos
```


----------



## Draco Malfoy (20 Juni 2021)

DeltaMikeAir schrieb:


> 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.
> 
> ...



Ihr seid an dieser Stelle leider einem Irrtum aufgesessen. Der Override-Schalter ist ein separates Bedienelement und hat nichts mit dem Handrad zu tun. Das Handrad hat nach Handbuch, und, glaube ich, auch in der Realität 50 Ink / Udr.

Ich habe zwischenzeitlich einen Baustein aus der LPresH zur Glättung des Sollwerts eingesetzt, das Handrad mal von Hand gedreht und den Istwert-/Geschwindigkeitsverlauf aufgenommen. Die Aufnahme habe ich leider verloren und kann sie hier nicht anhängen. Das Geschwindigkeitsprofil sah hierbei noch nicht optimal aus, der Verlauf war sehr unruhig.


----------



## Draco Malfoy (20 Juni 2021)

Zu dem Vorigen:

Filtereinstellungen:

```
posFilterTime           :   LREAL := 0.05;
            velFilterTime           :   LREAL := 0.3;
```

Istwertbereitstellung:

```
u8StepForward   :=  BYTE_TO_USINT(sOverlap.Handrad[0]);
        u8StepBackward  :=  BYTE_TO_USINT(sOverlap.Handrad[1]);
       
        r32ActualPos    :=  LIMIT ( 0.0, USINT_TO_REAL(u8StepForward - u8StepBackward) * 1.418, 360.0 );
```

Nützt aber nichts, weil Ihr das Trace nicht sehen könnt.


----------



## Heinileini (20 Juni 2021)

Draco Malfoy schrieb:


> ```
> r32ActualPos    :=  LIMIT ( 0.0, USINT_TO_REAL(u8StepForward - u8StepBackward) * 1.418, 360.0 );
> ```


'u8StepForward - u8StepBackward' kommt mir verdächtig vor, Draco.
Sind das schon die ZählerBytes der Schnittstelle vom Handrad, so ganz ohne Verwurstung der Überläufe?

Du willst anscheinend die absolute Position des Handrades einlesen? Das dürfte etwas problematisch werden bzw. irgendeine Form des Referenzierens erfordern, um die Position in der PLC-SW mit der Mechanik zu synchronisieren. Wahrscheinlich eine Kombination aus Bedienhandlung am Handrad kombiniert mit einem Reset bzw. Set des Positionswertes in der PLC.

Ich glaube, mein Ansatz ist nicht verkehrt, um die (relativen) Bewegungen des Handrads nachzuvollziehen.
Ob mein Weg, den Wert zu glätten (Rampen), für Dich brauchbar ist, kann ich nicht beurteilen, da ich das Umfeld/die Anforderungen nicht kenne.

PS:
Heisst das jetzt, dass die 19 Raststellungen sich auf den OverrideSchalter beziehen und keineswegs auf das Handrad? Dann habe ich ja völlig(?) zu Unrecht über Siemens gelästert.  

PPS:
Der Blick (bzw. das Starren) auf den LIMIT hat mich zu einer weiteren Variante für den Ersatz der SIGN-Funktion "inspiriert" ...

```
// praktischere Variante als SIGN-Ersatz zur Erzeugung von Rampen
siPosIst := siPosIst + LIMIT ( -1, siPosSol - siPosIst, 1 ) ; // neue, geglättete SollPos
// oder für steilere Rampen z.B. ...
siPosIst := siPosIst + LIMIT ( -5, siPosSol - siPosIst, 5 ) ; // neue, geglättete SollPos
```
Hier die Revision im Zusammenhang ...

```
VAR_INPUT
    iiZhlPls : INT  ; // MoPa-SST Handrad ZählerByte für '+'
    iiZhlMin : INT  ; // MoPa-SST Handrad ZählerByte für '-'
END_VAR

VAR_OUTPUT
    orPosIst : REAL ; //
END_VAR

VAR_STATIC
    siZhlPls : INT  ; // "FlankenMerker" von ZählerByte für '+'
    siZhlMin : INT  ; // "FlankenMerker" von ZählerByte für '-'
    siPosSol : INT  ; // "FlankenMerker" von "SollPositon"
    siPosIst : INT  ; // "FlankenMerker" von "geglättete SollPositon"
END_VAR

VAR_TEMP
    tiKorr   : INT  ; // KorrekturWert bei Überläufen der ZählerBytes
END_VAR

If iiZhlPls < siZhlPls Then tiKorr := 256 ; Else tiKorr := 0 ; End_If ;  // Korr bei ZhlPls-Überlauf
If iiZhlMin < siZhlMin Then tiKorr := tiKorr - 256 ; End_If ;            // Korr bei ZhlMin-Überlauf
siPosSol := siPosSol + ( iiZhlPls - siZhlPls ) - ( iiZhlMin - siZhlMin ) + tiKorr ; // neue SollPos
siPosIst := siPosIst + LIMIT ( -1, siPosSol - siPosIst, 1 ) ; // neue, geglättete SollPos

siZhlPls := iiZhlPls ;      // akt. Zustand von ZhlPls speichern für Vergleich beim nächsten Aufruf
siZhlMin := iiZhlMin ;      // akt. Zustand von ZhlMin speichern für Vergleich beim nächsten Aufruf

orPosIst := INT_TO_REAL(siPosIst) ; // hier ggfs skalieren ?
```


----------



## Draco Malfoy (21 Juni 2021)

@Heinileini :

Danke für die gemachte Arbeit, ich werde den Vorschlag umsetzen & prüfen. Dadurch, daß wir nicht mit SCL sondern mit ST arbeiten, hats hier einen anderen Befehlssatz, also u.A. auch solche Anweisungen wie LIMIT.

Edit: Absolute Position des Handrades möchte ich nicht sehen. Dadurch daß das Handrad nur inkrementell wirkt, hat es auch gar keine. Deshalb kann auch nur eine relative Gleichlaufkopplung aufschalten, und womit wir dann numerisch im Leitwert starten, ist dem Grunde nach egal.


----------



## Draco Malfoy (21 Juni 2021)

Also, ich habe jetzt das V-Profil und den Istwertverlauf aufgenommen. Die beiden Werte werden mit den Zeitkonstanten wie oben im Beitrag #25 angegeben, gefiltert.

Der Positionsverlauf sieht für mich befriedigend aus, der Geschwindigkeitsverlauf hingegen überhaupt nicht.

P.S: Ich habe dabei einfach von Hand das Rad mäßig schnell gedreht.


----------



## Heinileini (21 Juni 2021)

Draco Malfoy schrieb:


> Der Positionsverlauf sieht für mich befriedigend aus, der Geschwindigkeitsverlauf hingegen überhaupt nicht.


Welche negativen Auswirkungen hat denn der unbefriedigend aussehende Geschwindigkeitsverlauf?
Erhält der Antrieb ca. alle 50 ms einen neuen PositionierAuftrag?
Das abwechselnde Be- und Entschleunigen finde ich zumindest nicht überraschend. Anscheinend wird auf ca. die Hälfte der letzten zuvor erreichten MaxGeschwindigkeit entschleunigt. Die Achse kommt nie zum Stillstand bevor der nächste PositionierBefehl etwas Neues vorgibt.
Wie sieht Deine Wunschvorstellung aus?
Vielleicht müsste man die max. Geschwindigkeit bzw. Beschleunigung des Antriebs während des HandradBetriebs herabsetzen.


----------



## NBerger (22 Juni 2021)

Wie sehen denn die Takte aus?
Buszyklus; Servotakt; Aktualisierung Geberwert?


----------



## Draco Malfoy (25 Juni 2021)

@Heinileini :

Du liegst da grundsätzlich falsch in der Annahme, ich würde irgendwelche Positionierbefehle absetzen. Das ist nicht Sinn der Sache bei einem Handrad in Verbindung mit einem Transfer. Der Sinn vom Handrad ist, einen Master-Leitwert zu simulieren, und damit den Ablauf von Hand durchfahren zu können. Das erfolgt über eine Gleichlaufkopplung an den Master mit Kurvenscheiben. Vom realen Betrieb unterscheidet es sich nur insofern, als daß der Leitwert später der Pressengeber ist. Im Einrichtbetrieb kann ich aber auf Handrad umschalten und den Ablauf händisch abfahren. Dazu muß der Leitwert allerdings sauber und ruhig sein.

@NBerger

Bus ist nicht IRT... Prozessabbild ist der ServoSynchronousTask zugeordnet.


----------



## Heinileini (25 Juni 2021)

Draco Malfoy schrieb:


> @Heinileini :
> Du liegst da grundsätzlich falsch ...


Hmmm, ich kenne es eigentlich so, dass man eine "virtuelle" Achse genau so verfährt bzw. verfahren kann, wie eine "real existierende", egal, ob in JOG, MDI oder AUTO.
Dann dürfte das Problem wohl da liegen, dass 1 Inkrement am Handrad sehr vielen Inkrementen an der Achse entspricht.
D.h. die Rampe darf nicht in Einheiten der Handrad-Inkremente (INT/DINT) gebildet werden, sondern erst nach der Multiplikation mit einem Faktor (durch den dann das REAL-Ergebnis wieder geteilt werden muss).

Z.B. (die viertletzte und die letzte Zeile aus Beitrag #26 wie folgt geändert rot: Faktor/Divisor 4 bzw. 4.0, grün: Deine Skalierung aus Beitrag #25):

```
siPosIst := siPosIst + LIMIT ( -1, *4 * (* siPosSol - siPosIst *)*, 1 ) ; // neue, geglättete SollPos

siZhlPls := iiZhlPls ;      // akt. Zustand von ZhlPls speichern für Vergleich beim nächsten Aufruf
siZhlMin := iiZhlMin ;      // akt. Zustand von ZhlMin speichern für Vergleich beim nächsten Aufruf

orPosIst := INT_TO_REAL(siPosIst)* * 1.418 **/ 4.0* ;
```


----------



## Draco Malfoy (26 Juni 2021)

> Hmmm, ich kenne es eigentlich so, dass man eine "virtuelle" Achse genau so verfährt bzw. verfahren kann, wie eine "real existierende", egal, ob in JOG, MDI oder AUTO.



Wie gesagt, das sind alles Kathegorien aus der Sinamics-Welt und haben mit dem Simotion-Konzept nichts gemeinsam. JOG, MDI usw. sind Begriffe die du auf EPOS mit TLG111 anwenden kannst.

In der SIMOTION-Welt und speziell in der Logik der Applikation LPresH (PressHandling) hats Leitwerte, die man untereinander umschalten kann. Hier schalte ich zum Beispiel zwischen dem Pressenmaster und dem Handrad um. Welcher Leitwert auch immer dann genommen wird, auf den Leitwert werden im Kurvenscheibengleichlauf die virtuellen Achsen für die Freiheitsgrade aufgeschaltet, und auf die VAs dann im Getriebegleichlauf die motorischen Achsen des Transfers gekoppelt.

Den Vorschlag mit Multiplikation vor der Filterung werde ich aufnehmen und hernach berichten.


----------



## Heinileini (26 Juni 2021)

Draco Malfoy schrieb:


> Den Vorschlag mit Multiplikation vor der Filterung werde ich aufnehmen und hernach berichten.


Die Zahl 4 als Faktor/Divisor bitte nur als Beispiel verstehen.
Wird die Zahl zu gross gewählt, wird die Achse bei schnellem Drehen am Handrad nicht mithalten können und zu langsam laufen und letztlich noch nachlaufen.
Bei langsamem Drehen am Handrad wird die Achse weiterhin "ruckeln", will sagen, BeschleunigungsPhasen und Pausen werden sich abwechseln.
Eigentlich müsste man die Zahl (Faktor/Divisor) entsprechend der Geschwindigkeit der aufeinander folgenden Handrad-Impulse variieren.


----------

