Handrad (KPT700F Mobile HW/OR) an Simotion

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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:
Anhang anzeigen 55017

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

        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]

@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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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

 

[Draco Malfoy]

@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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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]

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]

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.