Kaufentscheidung CNC Steuerung

PeterD

User
j-o-j-o sucht 'n stepper treiber, kein servo.

Aufwendige arbeit, respekt.
Aber doch'n tip.
Hab mir nen wolf gesucht und keine "daten" gefunden. Lediglich der im RAR "versteckte" schaltplan gibt ein paar anhaltspunkte.
Währe nett die hauptdaten des kontrollers irgendwie als übersicht zu finden.

gruss Peter
 

PeterD

User
...
aber ich denk es wird diese hier werden:

Aus genanntem Grund
Die boards mit TA8435 sind strommässig zu begrenzt und praktisch nicht einstellbar.
Hab vor 1/2 Jahr auch 'n TA8435 board gekauft, ich würde heute aber eher die TB6560 vorziehen.

P.S. Bei 60€ lohnt garantie/gewärleistung kaum.
 

Steffen

User
Moin Peter,

der TA8435 ist genauso bis 40V spezifiziert wieder der TB6560. Ich betreibe beide mit 36 Volt.
Die Spannungseinschränkung der Chinesenboards liegt nur im 5V-Regler begründet, der mit höheren Spannungen nicht zurechtkommt.

ich habe hier beide in Betrieb gehabt und abgesehen vom höheren Strom ist der 8435 (bisher) angenehmer. Vor allem habe ich den 6560 im Decay-Modus nicht zum Schrittverlustfreien Betrieb bekommen. Die Schrittverluste lagen eindeutig auf der logischen Seite und waren nicht in den Griff zu bekommen.
War aber evtl. nur ein Layoutfehler, allerdings hatte ich nach Specsheet gebaut.

Was meinst Du mit 'praktisch nicht einstellbar'?

Gruß, Steffen
 

PeterD

User
Moin Peter,

der TA8435 ist genauso bis 40V spezifiziert wieder der TB6560. Ich betreibe beide mit 36 Volt.
Die Spannungseinschränkung der Chinesenboards liegt nur im 5V-Regler begründet, der mit höheren Spannungen nicht zurechtkommt.
Du weist was absolute maximum rating ist ?

Die recommended operating conditions sagt ~26V für TA8435, 34V für TB6560.
Bei den maximum ratings hab ich mich aber wohl vertan, die sind gleich.

ich habe hier beide in Betrieb gehabt und abgesehen vom höheren Strom ist der 8435 (bisher) angenehmer. Vor allem habe ich den 6560 im Decay-Modus nicht zum Schrittverlustfreien Betrieb bekommen. Die Schrittverluste lagen eindeutig auf der logischen Seite und waren nicht in den Griff zu bekommen.
War aber evtl. nur ein Layoutfehler, allerdings hatte ich nach Specsheet gebaut.
Der TB6560 hat da noch konfigurationspins für die decay modes. Ausserdem sind die OSC frequenzen anders.
Da sind wohl die auslegungen unterschiedlich ausgefallen.

Moin Peter,
Was meinst Du mit 'praktisch nicht einstellbar'?
Ausser du lötests andere widerstände ein gehts bei TA8435 gar nicht. TB6560 kann 100%, 75%, 50% und 20% per setting.

aber der Suport in Landesprache fällt hier doch deutlich leichter.

Also wen du einen Preislich ähnlichen Vorschlag aus D hast dann immer her damit
Nix gegen den deutschen händler, aber wo soll der support herkommen wenn die chinaböller alle vom selben hersteller kommen und ohne oder mit mangelnder doku abgeliefert werden.
Glaube kaum das Lethmate da selber analysiert um die fehlenden daten zu decken.
Lass mich aber gern vom gegenteil überzeugen.
 
Hallo zusammen,
.... und noch einer, der angefangen hat, sich mit der Materie zu beschäftigen. Meine Wahl würde auf die GWR-Elektronik fallen, was ist davon im Vergleich zu Lemathelösung zu halten, vom Preis mal abgesehen?
Dann hätte ich noch ne Frage. Mein PC hat keinen Parallelport. Läßt sich so eine Steuerung auch mit einem USB to Parallel Kabel betreiben, ich habe in den Beiträgen nichts darüber gesehen?
 

PeterD

User
Meine Wahl würde auf die GWR-Elektronik fallen, was ist davon im Vergleich zu Lemathelösung zu halten, vom Preis mal abgesehen?
GWR ist etwas solidere technik und besser dokumentiert.
Ausserdem besser konfigurierbar (stromeinstellung).
Die Chinaböller haben auch ein paar designschwachpunkte (billige stromabsenkung, überlastete schutzdioden und 5/12V regler).
Das sollte bei GWR nicht vorkommen.
Man bekommt also was man bezahlt.

Dann hätte ich noch ne Frage. Mein PC hat keinen Parallelport. Läßt sich so eine Steuerung auch mit einem USB to Parallel Kabel betreiben, ich habe in den Beiträgen nichts darüber gesehen?
ABSOLUT KEINE chance.
Es gibt keine echten USB->LPT kabel. Die sind eigentlich USB->PRT, nur für drucker. Es gibt dann keinen "LPT port" den man ansprechen kann.

Hast'n freien PCI slot dann PCI LPT karte rein und gut.
Sonst anderen PC suchen.

Peter
 

Steffen

User
Du weist was absolute maximum rating ist ?
klar, und die sind bei beiden gleich.

Ausser du lötests andere widerstände ein gehts bei TA8435 gar nicht. TB6560 kann 100%, 75%, 50% und 20% per setting.
ok, die habe ich mehr als variable Sleep-modi verstanden. kann man natürlich auch gemischt verwenden.

Ich habe übrigens den TB6560HQ nicht AHQ, der hat auch recommended 26V

und da habe ich halt erhebliche Probleme, die nicht sauber in den Griff zu bekommen waren.

im Moment bin ich daher wieder bei den 8435, die laufen super, stabil und unkritisch in der Anwendung.

ABSOLUT KEINE chance.
Es gibt keine echten USB->LPT kabel. Die sind eigentlich USB->PRT, nur für drucker. Es gibt dann keinen "LPT port" den man ansprechen kann.
Naja, da wäre noch ein Smooth-Stepper, wenn man mit Mach3 arbeiten will.
ich habe mir gerade zwei bestellt :)

Gruß, Steffen
 

PeterD

User
Naja, da wäre noch ein Smooth-Stepper, wenn man mit Mach3 arbeiten will.
ich habe mir gerade zwei bestellt :)

Gruß, Steffen
Das sind dann aber hardwarecontroller mit eigener trajectory software, nix mit einfacher step/direction control mehr.
USB ist ein gift für jede realtimesteuerung. Da gibt der PC nur noch die zielkoordinaten vor und der USB controller macht die eigentliche steuerung autonom.
Da braucht man eigentlich Mach3 oder EMC nicht mehr wirklich.
 

Igab

User
PeterD;1607651 USB ist ein gift für jede realtimesteuerung. [/QUOTE schrieb:
???

Im Gegensatz zum Parallelport kann USB unter Windows Realtime, daher verstehe ich den Satz nicht!
Oder meintest Du Parallelport ist ... ?
Ich arbeite mit NC-Easy und USB-Controller und hatte vorher weder unter DOS noch unter Windows eine so sauber laufende Maschine.
 

PeterD

User
Im Gegensatz zum Parallelport kann USB unter Windows Realtime, daher verstehe ich den Satz nicht!
Oder meintest Du Parallelport ist ... ?
Das ist eine fehlinterpretation von "Realtime"
USB kann grundsätzlich KEIN realtime, liegt am nichtdeterministischen protocollstack.

Alles was wirklich realtime ist läuft bei dir innerhalb des USB controllers ab, OHNE kommunikation zum PC. Sobald USB wieder "kommuniziert" wird wieder "gewartet".
D.h. der controller an sich ist der Realtime-kernel. Mach3 liefert dann nur noch die endkoordinaten des nächsten NC befehls.

Normalerweise hat Mach3 einen realtime kern der die trajectory kontrolle macht.
Also z.B. einen kreis in einzelne winzige steps zerlegt.
Das geht mit USB nicht.
Der USB controler bekommt nur die kreis-parameter und macht das dann komplet selbst.
Windoof hat dann GARNIX mehr mit realtime zu tun. Das macht der USB controller dann autonom.

"Realtime" heisst du hast definierte reaktionszeiten.
Das ist bei allem was über USB geht nicht garantiert (nicht deterministisch).
Das liegt am protocoll stack der USB implementierungen.

Ein LPT ist exact deterministisch. Die delayzeit vom schreiben des ports bis der pin sich bewegt ist genau vorhersehbar. Hier ist dein betriebssystem (Windoof) das eigentlich problem.

Mach3 und EMC2 sind Realtime-erweiterungen (Mach3 'n bischen schlechter als EMC2 wegen Windoof ;-) ).
Wenn aber ein hardwaretreiber (aka USB stack) sich zeit lässt und die interrupts sperrt hat auch EMC2 keine chance. Dann verpasst das system den akuraten zeitpunkt für den nächsten step. Bei 20..40kHz reichen dafür schon ein paar microsekunden die irgendwer trödelt und das OS sperrt und der step geht daneben (schrittfehler).

gruss Peter

P.S. mit USB controller braucht man genaugenommen Mach3 gar nicht mehr wirklich.
Da muss nur jemand den NC code zeilenweise in den code des USB controllers umkodieren.
Das ist genaugenommen nix als ein etwas aufwendigeres batch-program.
Eine "steuerung" brauchst du dann auf'm PC nicht mehr, weil das macht der USB controller autonom.
 

Steffen

User
Moin,

P.S. mit USB controller braucht man genaugenommen Mach3 gar nicht mehr wirklich.
Da muss nur jemand den NC code zeilenweise in den code des USB controllers umkodieren.
Das ist genaugenommen nix als ein etwas aufwendigeres batch-program.
Eine "steuerung" brauchst du dann auf'm PC nicht mehr, weil das macht der USB controller autonom.
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.
Die Trajektorien sind dann bereits komplett vorbereitet an den FTDI zu liefern.
Letztendlich eine reiner Sequenzausgeber.

Nichtsdestotrotz gibt es natürlich solche Geräte.

(Mach3 'n bischen schlechter als EMC2 wegen Windoof ;-) )
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.

Zugegebenermaßen ist meine EMC-Erfahrung aber deutlich niedriger als zu Mach3 ;)

Gruß, Steffen
 

PeterD

User
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.
 

Steffen

User
Peter, dir ist aber schon klar, dass man für die Schrittausgabe kein vollständig deterministisches System benötigt?

Für den Ausgabejob reicht weiche Echtzeit nämlich vollständig aus.

Woher nimmst Du die Aussage, dass der FTDI nicht gehen kann? Nach den Datenblättern kann er das sehr wohl. Es geht nur darum, genug Puffer im FTDI zu haben und damit die Zeitunsicherheiten von USB abzusichern.

Der Kontakt der Wirtssoftware muss dann nicht Zeiteng am FTDI hängen.

Ich meine nicht Serial-Modus der FTDI, sondern den bitbanging IO-Modus



Ach ja: das mehr über Mach3 in den Foren steht, liegt das an mehr Problemen, oder mehr Installationen oder weniger erfahrenen Anwendern?

Es gibt ein paar realtime fähige USB stacks im embedded bereich.
Es kann mit USB prinzipiell keine harte Echtzeit im USB-Stack des Wirtes geben, darin sind wir uns doch sicherlich einig, oder?


@j-o-j-o:
im Rahmen der billigen Steuerung ging es aber auch um die Frage, wie man ohne Parallelport steuern kann.

Und an einer Diskussion über die Bezeichnung Windoof beteilige ich mich eh nicht, behaupte auch nicht, dass Mach3 oder windows besser als Linux mit EMC ist, nur sind die ewigen anti-Windoof-Geschichten oft nicht so ganz der Wahrheit entsprechend.


Gruß, Steffen
 

PeterD

User
Peter, dir ist aber schon klar, dass man für die Schrittausgabe kein vollständig deterministisches System benötigt?

Für den Ausgabejob reicht weiche Echtzeit nämlich vollständig aus.
Preisfrage: wenn sich bei 50kHz schrittfrequenz ein schritt wegen latency um 20µs verzögert passiert genau was ?

SCHRITTFEHLER

Ganz schlimm wirds wenn durch latencyverschiebungen die setup und holdzeiten der stepper treiber nicht mehr eingehalten werden.
Z.B. T1(schritt) ist korrekt, T2 ist um 20µs verschoben, T3 (richtungswechsel !) kommt wieder pünktlich. Dann ist plötzlich die setupzeit bei T3 verletzt und der stepper dreht nicht um.
Das sind dann elektrische schrittfehler die nur schwer gefunden werden.

Es ist also genau das ausgabesystem das harte echtzeit benötigt.
Macht3 macht das wohl im timer interrupt.
EMC2 benutzt dazu auch timer getriggerte tasks.

Im EMC handbuch gibt es detailierte kapitel zu taktfrequenz und latency für verschiedene ansteuerungen. Sollte man auch als Mach nutzer mal durchlesen um zu verstehen was es für probleme mit latency auf sich hat. Glaube kaum das sich hier die konzepte von Mach und EMC wesentlich unterscheiden.

Woher nimmst Du die Aussage, dass der FTDI nicht gehen kann? Nach den Datenblättern kann er das sehr wohl. Es geht nur darum, genug Puffer im FTDI zu haben und damit die Zeitunsicherheiten von USB abzusichern.
Der puffer verhindert kein jitter der ausgabesignale.
Oder kann der FTDI zeitkoordinierte ausgaben über zeitstempel ?
Jitter im step/direction setup&holdzeiten ist problematisch da es im gegensatz zu mechanischen schrittfehlern sich erst kummulativ äussert. Das findet man sehr schwer beim testen.
Selbst wenn die setup/holdzeiten bei der gepufferten ausgabe eingehalten werden kann der jitter noch mechanische schwingungen auslösen die dann mechanische schrittfehler bewirken. Also ganz so einfach ist das nicht über USB.

Steffen;1608687 Es kann mit USB prinzipiell keine harte Echtzeit im USB-Stack des Wirtes geben schrieb:
In der kommunication über USB nicht, aber wenigstens stört der USB stack dann nicht noch das restliche system. Bei EMC2 konnte ich beobachten dass schon das anstecken eines USB sticks die latency von 10..15µs auf 1ms hochschnellen liess. Also ohne das der USB wirklich "benötigt" wird. Seidem wird von USB abstand gehalten und die treiber sind nicht mehr geladen.
Bei den realtime linux kernels wird auch nur dafür gesorgt das der kernel und die treiber auch in kritischen momenten nicht blockiert.
Mach3/Windows hat auch eher diese probleme mit hintergrundprozessen die "ohne grund" blockieren. Der eigentliche "realtimeprozess" ist zwar timer getriggert, kommt aber dann nicht zeitgerecht dran.

gruss Peter
 

Steffen

User
Preisfrage: wenn sich bei 50kHz schrittfrequenz ein schritt wegen latency um 20µs verzögert passiert genau was ?

SCHRITTFEHLER
Das Problem ist mir auch klar, wobei das nicht unbedingt zum Schrittfehler führt, man muss den Folgeschritt dann ja nicht auslassen, sondern gibt ihn später aus.
Ob das einen Schrittfehler bewirkt, liegt daran ob der vorliegende Jitter oberhalb der Beschleunigungsgrenze der Maschine liegt.
Es führt aber zu schlechterer Laufruhe der Maschine.

Der puffer verhindert kein jitter der ausgabesignale.
Oder kann der FTDI zeitkoordinierte ausgaben über zeitstempel ?
Zeitkoordiniert: ja
Zeitstempel: jein, nur eine Erkenntnis, zum wievielten Clock welcher Pin was macht.
Echte Zeitstempel braucht es auch nicht, braucht nur eine Zeitfolgenkenntnis.

Schau Dir doch mal die FTDI-Doku zum Bitbanging und zum FIFO an, dann können wir nochmal darüber sprechen, ob das geht oder nicht.
Aber wohl eher privat, sonst gibt's wieder Mecker, dass das offtopic sei, weil sie nicht folgen können ;)

Bei EMC2 konnte ich beobachten dass schon das anstecken eines USB sticks die latency von 10..15µs auf 1ms hochschnellen liess. Also ohne das der USB wirklich "benötigt" wird.
Da sage ich jetzt mal lieber nix zu. :D

Zum Thema billige Steuerung: wenn ein FTDI wirklich geht, würde man an der PC-Seite eine Menge Geld sparen können, hätte aber supersaubere Signalfolgen. Der etnscheidende Punkt ist nur, ob der Puffer im FTDI groß genug ist um sicherzustellen, dass der nächste Datenschub rechtzeitig kommt, bevor der Puffer leer ist.

Der Shop ist aber sehr interessant, den werde ich mir genauer ansehen, ich brauche da demnächst was stärkeres als die 6560 ;)
Aber ein US-Shop ist das eher nicht ;)

Gruß, Steffen
 
Ansicht hell / dunkel umschalten
Oben Unten