Codesys softmotion mit moduloachae

S

SY50

Level-1
Beiträge
271
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Halo, bei der codesys softmotion Funktionalität mit modulo Achse, gibt es in de achsstruktur die Werte dwOneTurn (gibt die inkremente pro modulowert an). Dann gibt es einen. Numerator und einen denumerator. Wenn das übersetzungsverhältnis nicht mit einer modulo Umdrehung aufgeht ( modulowert ist bei x,y inkremente ... Wobei y ungleich 0 ist), so steht noch etwas in dem Wert iRestNumerator.
ich habe jetzt mehrfach übersetzungsverhältnisse gewählt, die nich aufgehen. Und tatsächlich kommt man bei iRest immer auf eine ganzzahlige Integer Zahl. Ist ja auch gut so, dass es passt, aber warum ist das so? Kann mir das jemand Mathematisch erklären?

Danke
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das mit der Modulofuntion ist schön, führt aber genau zu Teilungsfehlern wenn das Verhältnis nicht passt. Wenn du zum Beispiel 65536 Ink/U hast und ein Modulowert von 5 eingibst so ist das nicht ohne Rest teilbar. 65536/5 = 13107,2. Jetzt müssen die restlichen 0,2 ink auch "irgendwo hin". Die werden dann wohl in dem Rest gespeichert. Alle 5 Umdrehungen geht das wieder auf. Ansonsten hast du ein Summenfehler der unter Umständen ziemlich groß werden kann bei Endlosachsen wie Förderbändern usw. Du hast geschrieben, dass es sich um ein iRestNumerator handelt also eine Ganzzahl. Ich habe das im speziellen nicht beachtet, denke aber, dass er hier einfach die Inkremente pro Umdrehung zwischenspeichert die übrig bleiben. Hast du beobachtet, was das System mit diesem Wert macht? Korrigiert er diese wieder oder was tut es damit?

Meine Vorgehensweise bei Moduloachsen ist IMMER eine mechanische Lösung zu suchen. Das heißt ich verwende Getriebe und Teilungen die aufgehen. Dazu nehme ich bei normalen 65536ink/U Getriebe die in binären Stufen ausgelegt sind also nicht 3:1 oder 5:1, sondern 2:1, 4:1, 8:1, 16:1. Dann die Ritzel oder Zahnräder so auslegen, dass am Getriebeabgang eine Umdrehung dem entspricht was du als Modulowert haben möchtest.

Noch was mir immer wieder "zwischen die Füße kommt". Es heißt nicht Denumerator, sondern Denominator. Das ist ein Flüchtigkeitsfehler der immer wieder auftritt.
 
excelite schrieb:
Meine Vorgehensweise bei Moduloachsen ist IMMER eine mechanische Lösung zu suchen. Das heißt ich verwende Getriebe und Teilungen die aufgehen. Dazu nehme ich bei normalen 65536ink/U Getriebe die in binären Stufen ausgelegt sind also nicht 3:1 oder 5:1, sondern 2:1, 4:1, 8:1, 16:1. Dann die Ritzel oder Zahnräder so auslegen, dass am Getriebeabgang eine Umdrehung dem entspricht was du als Modulowert haben möchtest.
Zum Vergrößern anklicken....

Ich hatte mal ein Feuerwehrfahrzeug, wo beim Drehtellerantrieb beide Zahnräder eine Primzahl als Zähnezahl hatten! Das muss schiefgehen und war nach einigen Schwenks nicht mehr in die Nullage (Einfahren und nach Hause) zu bringen.

Code: 
(* Version        2.0.0.4                                                        *)
(* returns the value of angle  digits for 1 TT turn                            *)
(* this is the best approximation because of prime number division!!!        *)
(* modif ROB 03.12.2010 55 m boom added                                        *)
(* COS / ROB 00.02.2013 45 m boom added                                        *)
(* modif ROB 28.12.2010 55 m boom ratio 136/ 17                             *)
(* modif ROB 20.01.2011 42 m ladder added                                    *)

    CASE (eType) OF
        eLadder32m:
            nDigits := 31508;                (* 31507,69230769 ....            *)
        eLadder44m:
            nDigits := 40960;                (* 10 / 100                        *)
        eBoom25m:
            nDigits := 39385;                (* 125 / 100 * 31507,692..        *)    
        eBoom37m:
            nDigits := 32768;                (* 136 / 17  dis = 8 tur 8 x 4096 = 32768.        *)
        eBoom55m, eBoom45m:
            nDigits := 32768;                (* 136 / 17  dis = 8 tur 8 x 4096 = 32768.        *)
        ELSE    
            nDigits := 39385;                (* should never happen !!!!        *)
    END_CASE

GetFullTurnDigits := nDigits;
 
Also codesys verrechnet den Restwert... Eben auch genau mit den 0,2 und das funktionier auch. Die Achse läuft nicht weg. Ist auch mathematisch nachvollziehbar, das ist mir klar... Wollte nur wissen, wie es mathematisch dazu kommt, dass der restnumerator immer ne ganze Zahl ist. Aber versteht man wohl schwer.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das werden wohl die "übrigen" Ink pro Umdrehung sein. 0,2 Ink gibt es nicht bzw. wäre dann bei krummen Werten die nicht im REAL Format darstellbar sind auf Dauer fehlerhaft bei einer Menge an Umdrehungen.

Ohne es jetzt geprüft zu haben würde ich sagen:
Es wird einfach der Rest, der bei der Berechnung an Ink übrig bleibt zwischengespeichert. Genau um die muss intern korrigiert werden. Bei diesem Beispiel würde da dann in deinem Rest der Wert "1" stehen vermute ich?!?
 
Genau so ist es nicht. Wenn man für einen modulowert bspw. 1000,6 Inkremente fahren müsste, so wird der Wert für eine Umdrehung auf 1000 gesetzt und es wird der Rest von 0,6 gemerkt. Dass sich meiner Meinung codesys nachfolgend mit der restwertverarbeitung etwas verhaspelt ist jetzt egal.
Codesys wählt nur den denominator für den scalefactor und den Rest (ein denominator) so, dass immer eine ganze Zahl raus kommt. Bspw. denominator durch gegeben Getriebe bspw. 250 => Rest Nominator = 150
... 150/250 = 0,6
 
Zurück
Oben