Dem kann ich aber nicht im mindesten zustimmen.
Die Architektur von Mach3 bereitet die Daten sehr umfangreich vor, ein USB-Gerät an Mach3 benötigt nur eine relativ eingeschränkte Intelligenz.
Ein USB-Gerät mit einem FTDI wäre durchaus denkbar und der kann wirklich nicht viel, ausser zeitgerecht IO-pins zu bedienen.
Genau das funktioniert mit USB nicht mit standart OS wie windows oder Linux.
USB ist nicht zeitgerecht da dort einige treiberebenen in den stacks und dem OS mitspielen.
Es gibt ein paar realtime fähige USB stacks im embedded bereich.
Die lassen sich die hersteller aber gut bezahlen.
Nix davon unter Windoof.
Mit standart OS sind die latencies deshalb mit USB unkalkulierbar.
Ein versuch mit FTDI dürfte deshalb seeeeeehr frustrierend werden.
Bei 100Hz stepfrequenz dürfte das noch gehen.
Bei 20..40KHz hast du da KEINE chance mehr.
Da wäre ich mir nach meinen bisherigen Erfahrungen auch nicht so ganz sicher.
Die Hardwareeinschränkungen gelten für beide Systeme, Windoof ist erst im Nachteil, wenn es gar nicht geht. Solange es unterhalb des kritischen Zustandes bleibt, kann ich keine Vorteile für EMC feststellen.
EMC verwendet einen echten realtime kernel. Lediglich einige hardware treiber sind nicht kalkulierbar (wozu auch das USB subsystem zählt). Zumindestens hat man bei Linux die möglichkeit das system treibertechnisch drastisch zusammenzustreichen.
Windoof ist defakto nicht realtimefähig.
Mach3 trickst da wohl mit hardware interrupts rum.
Sobald aber das OS benötigt wird (USB !) ist das aber nicht deterministisch.
Die foren von Mach3 sind voll von derartigen merkwürdigkeiten
Noch mal: Realtime heist das gesammte system (!) hat determinierte reaktionszeiten.
Wir reden hier von 1..20µs !
Das ist bei Windoof praktisch unmöglich. WinCE hat hier ansätze, ist aber auch nicht hard realtime fähig.
Bei Linux gibt es mitlerweise echte realtime versionen.
Hier gab es in den versionen nach 2.4er kernel ernste versuche deterministische latency zeiten zu erreichen. Ist aber auf kernbereiche des OS beschränkt.
Schon ein "falsches" filesystem kann die latencyzeiten explodieren lassen.
Sobald aber GUI, USB oder andere netzwerktechnik ins spiel kommen oder gar closed source treiber von diversen hardwarelieferanten zugegen sind gibt es einschränkungen.
Ansonsten braucht es nun mal ein richtiges embeded RT OS.
Ein USB controller macht NUR mit eigener trajectory control sinn.
Bei Windoof die einzige professionelle möglichkeit ein robustes profisystem zu designen.
Ein port expander mit FTDI ist noch problematischer als ein LPT port unter windows zeitgerecht anzusteuern.
Was denkst du warum professionelle maschinen grundsätzlich immer hardwarecontroller mit eigener trajectory control benutzen statt einen PC mit Windoofs ?
Wenn man >40Khz stepfrequenz haben möchte wird ein hardware controller fast unumgänglich.
Mach3 ist nun mal immer noch nur hobbytechnik.
gruss Peter
P.S. für die praktiker hier (@ j-o-j-o):
Ein USB (Hardware) controller ist eine gute (aber eben auch teurere) möglichkeit die latency des PC zu umgehen.
Aber eben weil der kontroller die echtzeitverarbeitung komplet übernimmt, der PC wird zur bedienkonsole degradiert.