[Rumgucker]

Ich sehe meinen Denkfehler.... ;wall

Hinter dem gezeigten Stromverlauf stecken ja schon vier Vollschritte und zwar:

t0 = oben Null, unten negativer Max

t8 = oben positiver Max, unten Null

t16 = oben Null, unten positiver Max

t24 = oben negativer Max, unten Null


Also muss man die 32 Mikroschritte noch durch die vier Vollschritte teilen. Also ergibt das 8 Mikroschritte, bzw. 200 mal 8 = 1600 Mikroschritte pro Vollkreis.

Pro Step brauche ich 75 Mikrosekunden. Die Wendeln haben eine Steigung von 3 Millimetern (das haben die 12 mm-Wellen fast immer). Also brauche ich für drei Millimeter 75 Mikrosekunden mal 1600 Schritte = 12 Millisekunden, pro Millimeter also 40 Millisekunden.

Für die längste Achse, die 400 Millimeter, brauche ich also 16 Sekunden. Das kann man schön im Video sehen, wenn ich von hinten nach vorne fahre (mit etwas Respektabstand zu den Anschlägen). Passt!

Puh. Dann haben wir die Kuh jetzt vom Eis.

Maximalgeschwindigkeit v = 0,025 m/s

Schrittweite ds = 1.875 um

[Rumgucker]

Hab Kahlos Kritik angenommen und doch einen sanften Auslauf eingebaut. Schont die Maschine.

Will eigentlich jemand die Weichware haben, wenn fertig?

[christianw.]

Btw. Wenn das Diagramm jetzt 1/8 abbildet, was ist mit 1/16? (Seite 14)

Gibts eine Implementierung für Referenzfahrt?

(End-2-End mit Schrittzählung für Absolutwerte)

Willst du noch was an der Gui schrauben?

[Rumgucker]

Können kannst Du das. Klar. Aber wozu?

Grafik findet in CAD und ggfls. "makehpgl" (Delphi-Software zum Beispiel zum Optimieren oder Konturfräsen oder BMP->Vektor-Konversion) statt. Das ist alles fertig. Ich berichtete....

Beim in Arbeit befindlichen PLT2CNC dagegen gehts nur um den eigentlichen Maschinentreiber. Während des Steppens ist Windows sowieso blockiert. Eine gleichzeitige Darstellung von Grafik und Steppen geht nicht und finde ich auch weniger sinnvoll als die Darstellung des gerade in Arbeit befindlichen HPGL-Befehls.

[christianw.]

Muss ja nicht "live" sein.

1/32?

Bezüglich des Ports und direktem Ansprechen, kenne ich noch DLPortIO und InpOut32. Damit hat man auch unter neueren System direkten Zugriff auf dem Port.


http://real.kiev.ua/tag/dlportio/?langswitch_lang=en

http://www.highrez.co.uk/Downloads/InpOut32/default.htm

[Rumgucker]

Ja. Man kann sich mit Tricks im Schichtenmodell des Betriebssystems hochheben, wenn man Treiber schreibt.

Man muss allerdings bedenken, dass wir im Mikrosekundenraster steppen! Das leistet die relativ langsame Kommunikation zwischen Anwenderprogramm und Treiber nicht.

Alternativ kann man alle zeitkritischen Teile in die höheren Schichten umlagern. Da aber beim CNC-Treiber 99% der Software zeitkritisch ist (der 3D-Bresenham muss z.B. in Echtzeit berechnet werden), kann man gleich alles als Treiber formulieren.

Zur Programmiereung von Microsoft-Systemtreibern hab ich keine Lust. Meinen letzten und einzigen Treiber hab ich 1990/91 geschrieben. Das mach ich gewiss nie wieder.

Ist auch für mich nutzlos, weil auf meinem 300 MHz-Notebook geht eh nur maximal Win98.

--------------

Grafikdarstellung unter dem von mir verwendeten Objekt Windows (C++) ist ein Zweizeiler. Vielleicht mach ich ein Darstellungsfenster auf, so dass man das zu plottende Projekt schon mal sehen kann. Das wär wohl sinvoll...

[christianw.]

Für die beiden brauchst keinen Treiber, da kannst du die DLL ansprechen.

Geschwindigkeit war (für mich damals) ausreichend um Grafik-LCDs am PPort zu betreiben.

OPTREX 128x128 an Parallelport (Video)

und

OPTREX 640x200 Animation (Youtube)

[Rumgucker]

Du kannst mit einer DLL die Interrupts im Betriebssystem nicht unterbinden, Christian. Interrupts sind aber nicht erlaubt, wenn ich in Echtzeit steppen will.

[christianw.]

Da hast du Recht.

[Rumgucker]

Zitat:Original geschrieben von christianw.
Da hast du Recht.

So schnell gibst Du auf?

Sind das schon erste Anzeichen chronischer Resignation ob meines Altersstarrsinns?

Mach Dir nichts draus. Haben schon viele erfolglos versucht, mich aus meiner geistigen Dunkelheit ans Licht des Wissens zu führen. Es gelang nur in seltensten Ausnahmen. ;baeh

[kahlo]

Zitat:Original geschrieben von Rumgucker
Will eigentlich jemand die Weichware haben, wenn fertig?

Der Bedarf für Win98-Software dürfte nicht soo gross sein... Ich habe zwar noch ein Museumsstück mit Win98, aber das taugt nicht für schmutzige Umgebungen.

[voltwide]

Zitat:Original geschrieben von kahlo

Zitat:Original geschrieben von Rumgucker
Will eigentlich jemand die Weichware haben, wenn fertig?

Der Bedarf für Win98-Software dürfte nicht soo gross sein... Ich habe zwar noch ein Museumsstück mit Win98, aber das taugt nicht für schmutzige Umgebungen.

Du bist also Schornsteinfeger!

[Rumgucker]

Zitat:Original geschrieben von kahlo
Der Bedarf für Win98-Software dürfte nicht soo gross sein.

Auch wenn ich das Teil Windows 8-kompatibel verfasst hätte, wäre der Bedarf überschaubar. Bandre und Du haben ja schon geeignete Software. Und mehr Maschinenbesitzer gibts hier IMHO nicht.

Meine Frage ans Forum war daher eher eine Höflichkeitsfrage.

[christianw.]

Zitat:Original geschrieben von Rumgucker
So schnell gibst Du auf?

Sind das schon erste Anzeichen chronischer Resignation ob meines Altersstarrsinns?

Mach Dir nichts draus. Haben schon viele erfolglos versucht, mich aus meiner geistigen Dunkelheit ans Licht des Wissens zu führen. Es gelang nur in seltensten Ausnahmen. ;baeh

Bin ich Missionar?

[Rumgucker]

Ich hab ein Problem.

Es strullt ein Vektor nach dem anderen in den Treiber. Gut. Klar.

Aber wie mach ich die Rampensteuerung? Es genügt nicht zu wissen, ob da noch ein weiterer Vektor folgt. Man muss auch wissen, in welchem Winkel der Folgevektor weitergeht. Ist der Winkel zu steil, so muss ich ne Rampe fahren. Ist der Winkel flach, so kann ich mit vollem Tempo weiterlaufen.

Das Problem tritt bei Kreisen auf, die üblicherweise aus vielen kleinen Segmenten zusammengesetzt sind. Wenn ich da jedesmal starte und bremse, dann wirds träge.

[christianw.]

"Look-Ahead"?

Wenn du deine Befehle pufferst (bspw. 3 Zeilen im Vorraus) kannst du ja "gucken".

[Rumgucker]

Ja... so in die Richtung werde ich wohl gehen müssen. Mist. Daran hatte ich im Vorfeld nicht gedacht.

[christianw.]

Du kannst natürlich am Anfang die Anzahl der Zeilen parsen und die gegen die aktuelle Nummer laufen lassen.

[Rumgucker]

Ach.... könnte das ganz simpel machen.

Es geht ja um die Verkettung gleicher Befehle (z.B. "PA 47,11; PA 147,13; PA 168,22;"....).

Einen PA-Befehl speicher ich zwischen und plotte nichts.

Erst beim nächsten Befehl weiß ich, was zu tun ist. Und zwar MIT Rampe, wenn der aktuelle Befehl kein "PA" ist oder wenn der neue Winkel zu groß wird.

Wenn der aktuelle Befehl wieder ein "PA" ist, so wird er wieder zwischengespeichert. Alle andersartigen Befehle (z.B. "PU", "PD", "SP"...) werden ebenso gleich ausgeführt.

-----------

Prompt gibts allerdings das nächste Problem: während eines Vektors fahre ich in voller Fahrt mit 70us pro Step. In 70us hab ich aber nicht den nächsten Befehl vorliegen. Da lieg ich auf meinem langsamen Notebook im zweistelligen Millisekundenbereich. Während dieser Pause hält der Motor. Sobald der Vektor vorliegt, startet der Motor dann wieder. Ggfls mit voller Pulle. Es gibt also einen Knall.

Tja... das geht nicht.

Also alles zurück. JEDER Vektor muss eine Rampe fahren.

[Rumgucker]

...so wars natürlich leicht.

Im Kern bin ich fertig.

Gleich mal ersten Probelauf mit echten Daten....