Auflösung und Positonen !

Ein sehr interessantes Thema, dass du hier anführst.

Ich verstehe leider noch nicht so ganz, was gegen eine Proportionalitätskonstante spricht. Wenn der Sollwert nahe dem Ist Wert liegt, dann wird langsam gefahren, und wenn er weit entfernt liegt, dann eben schnell.
Der Motor darf nur nie schneller die Soll Position erreichen, als die Steuerung die Datenpakete erhält, weil sonst ja gebremst und angefahren wird. Stop'n'Go sozusagen.

Wüsste aber nicht, warum man damit keine Bodenwellen simulieren kann.
Weiß ehrlich gesagt nicht, auf welche Art die Daten für die USO aufbereitet werden.
Aber man muss m.E nur sicherstellen, dass Bodenwellen ein heftigen Soll Ausschlag erzeugen.
Also sollte der USO im Fall Bodenwellen fast Rohdaten übermitteln
Denn in diesem Fall gibt ja auch die proportionale Steueurung das Signal zur Fahrt mit voller Leistung -> Bodenwellen

Wenn im Zuge des Prof2 dann 16bit und mehr zur Vefügung stehen, dann ist das doch super. Auch wenn bei schneller Fahrt nur ein Bruchteil der Postitionen angefahren werden können, so stehen doch bei langsamer Fahrt weitaus mehr Positionen zur Verfügung, als vorher. Das ist doch das, was wir wollen.

Ich glaube was du bei deinen Überlegungen vergisst, ist die Tatsache, dasss es bei der digitalen Pneumatik eben nur 3 Geschwindigkeiten gibt. Deswegen kannst du sie nicht direkt mit einer dynamischen DC Motorensteuerung vergleichen. Und genau DAS ist der katastrophale Nachteil der digitalen Pneumatik. Und nur das.

Das Netzwerk delay ist halt auch ein Problem. Deswegen finde ich es auch besser einen dual oder multicore Prozi zu nutzen, anstatt einen 2. Rechner.

Also sollte es nun erstrebenswert sein, aufs Netzwerk zu verzichten, und die 33ms des Profilers zu verkürzen. Zumindest für den USO eine Justiermöglichkeit der Update Rate anbieten.

hmm, wenn Frex mit 1ms ausliest, dann machen wir evtl vielleicht was falsch?

So, nun widerlege mich, damit die Diskussion interessant bleibt ;D

Gruss
ego

I think, that a value of 5 to 8 ms update will be enough even if we receive less position per second from the computer. This will also enable us to use less accurate optical encoder resolution perhaps 11-bit or 12-bit that a single microcontroller can handle better.

Just think that the output pulley of my joyrider setup turns around 3 times to travel the frame from one side to another. And with a 120 CPR optical encoder disk I get only 360 points!! So the only way to get bigger resolution from my wiper motors I have to hack them and attach the encoder disk directly on the motors shaft (that is before the gear reduction box). And even so, the max resolution could be 18000 points (if the reduction rate is 50:1).

In my electronics though I can increase the resolution of the input data by using PID algorithms since the steps are translated into speed settings. This means that if a constant rate of changes in the input is occurring, no matter how small the change, it will keep rotating without sights of stepping!

Its indeed a very interesting Thema that needs lots of analysis

More on this later.... (busy right now ;-) )

Regards, Thanos

Hi Sirnoname,

These steps are time-based, not the true resolution of the output.

It affects the fast oscilating motion (bumps, vibration, etc) but isn't so important as I see it.

I guess we can have more than 33 changes per second using faster update rate like 5ms...

Regards, Thanos

hier noch was kommerzielles zum Thema. Vielleicht finden wir ja was vergleichbares als Freeware^^

link Realtime Suite 8.0