1/128 Microstepperdriver für RADDS

---

Mein Club: [hackerspace-ffm.de]
RADDS-Shield -> Commercial [max3dshop.org]

Quote
Le-Seaw
Also Versatz liegt an Marlin

Habe es auch identisch, nur kann ich keinen Unterschied feststellen egal welche Schrittzahl immer das selbe. Immer Richtung Endstop.
hatte es erst darauf geschoben das ich 1024 Schritte habe bei 1/128 aber selbst mit 512 oder 256 identisch alles.

Und an den Kabeln liegt es nicht, Testaufbau war mehr als chaotisch

Interessant ist auch, das der Versatz größer ist bei geschlossenen Top/Bottom Layern und kleiner bei beispielsweise 10-20% infill. Mache dir mal einen Testkörper mit 2mm dicken Top/Bottom

Katastrophal wird es komischerweise, wenn du mal testweise auf 1/32 runtergehst. Da liegen dann die Perimeter nebeneinander. Das läuft allerdings konträr zur Vermutung "mehr XSteps = mehr X-Schieflage"

naja das würde bedeuten das es einen Fehler in konstanten Steps gibt, der wird natürlich dann grösser in mm je weiter du Richtung fullstepping kommst.

Wäre unheimlich interessant den Step pin mal zu messen wärend dieser Phase

1-mal bearbeitet. Zuletzt am 29.08.14 07:39.

Quote
mantus
Marlin ist wohl in china gerfertig worden ..... sorry das musste jetzt sein

wirklich interessant wäre jetzt noch wie man Repetier auf einen K8300 zum laufen bekommt,
und zu messen was genau passiert bei Layerchange mit Marlin und bei Repetier.
*marlinrunterlad*

Leider habe ich nicht die passende Meßtechnik, dort tiefgreifend zu analysieren. Man müßte einen Logger dranhängen und einen G-Code jeweils durch Repetier und Marlin schicken und mal schauen was am Stepper ankommt. (Pulse zählen)

Ja ich leider auch erst wieder in 1-2 Wochen.

Speicher Osci mit Trigger am Z-Step Pin müsste das ganz gut einfangen können. was sich auf den 3 Leitungen zum Treiber so tut während dieser Phase.
Evtl sollte man die Posts mal in einen eigenen Thread raus ziehen und einen "Bug Report" schreiben.

den gibt es schon bei marlin.

mal sehen habe da so eine ahnung das da was passiert in nächster zeit

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

Quote
Le-Seaw
den gibt es schon bei marlin.

mal sehen habe da so eine ahnung das da was passiert in nächster zeit

Hoffentlich, ich habe da gestern Nacht vor Verzweiflung auch noch einen Text druntergeschrieben. Habe jetzt dort nochmal quergelesen und gemerkt, dass du ja schon seit ein paar Tagen damit kämpfst Ich würde da gern beim debuggen helfen, kann aber nur testen und nicht (elektronisch) messen.

also was mir aufgefallen ist

DRV8125 enable:
Logic high to disable device outputs and indexer operation, logic low to enable. Internal pulldown.
THB6128 enable:
Output enable signal input

d.h. der DRV8125 zählt die STEP inputs NICHT weiter wenn Enable = OFF
der THB6128 zählt die STEP inputs weiter und schaltet nur den Ausgang nicht weiter, wenn enable wieder auf ON geht "springt" er dann zum Zielpunkt

aber da sollten ja die Enable Leitungen garnicht umgeschalten werden in der Zeit?

2-mal bearbeitet. Zuletzt am 29.08.14 08:43.

Also die Stepper werden nicht abgeschalte solange die config so aussieht

// Disables axis when it's not being used.
#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z false
#define DISABLE_E false // For all extruders
#define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled

Beim K8200 ist da normalerweise auf Z ein true. Das habe ich aber im Zuge meines Threadless Z schon entfernt, wegen der höheren Steigung (ggü. M8) und "fallen auf Vollschritt"

naja ENABLE != RESET beim DRV8825 hast du beide Pins von der FW ansteuerbar, beim THB board hast du nur RESET/ENABLE
Oder wie auch immer
ENA+: Offline enable reset signal positive terminal;
ENA-: Offline enable reset signal negative terminal;
zu interpretieren ist, kannst du mal auf deiner Platine nachschauen wie das gelöst ist?

1-mal bearbeitet. Zuletzt am 29.08.14 08:58.

ich glaube wir denken zu kompliziert.
In Repetierfirmware muss man da gar nix eingeben und es geht
selbst Decay habe ich auf 0 gelassen.
Entweder ist Marlin zu schnell oder zu langsam was das angeht.

Angeblich at das schon einer gelöst aber der rückt den Code nicht raus was ich echt Assi finde

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

Kann mir das kaum vorstellen das es zu schnell oder zu langsam ist, weil wenn die Impulse nicht richtig interpretiert werden würden, dann würden Schrittfehler sporadisch auftreten, und nicht immer genau beim Layerchange, und dann wieder exakt für einen Layer kein einziger Schrittfehler .... kann ich mir irgendwie nicht vorstellen.

Quote
Le-Seaw
ich glaube wir denken zu kompliziert.
In Repetierfirmware muss man da gar nix eingeben und es geht
selbst Decay habe ich auf 0 gelassen.
Entweder ist Marlin zu schnell oder zu langsam was das angeht.

Angeblich at das schon einer gelöst aber der rückt den Code nicht raus was ich echt Assi finde

Vermutlich hat er nur nicht verstanden, das Open Source geben und nehmen ist. Verstehe allerdings nicht warum man da ein Geheimnis draus machen muß. Er kann ja schlecht fertig geflashte Controller verschicken (falls es ein Händler ist) Und Binärfiles gehen ja auch nicht. Und nur für sich 1/128 zu nutzen um sich einen drauf ........ macht auch einsam

Vor etlicher Zeit hatte ich auch mal so einen Fehler: Layerversatz. Seitdem verwende ich Repetier .

LG, Willy

1-mal bearbeitet. Zuletzt am 29.08.14 09:18.

---

3D gedruckter Messerschärfer +++ RADDS für den Arduino-Due +++ Meine Drucker

@Le-Seaw: im Git meint jemand, dass nach DIR Wechsel 5µS Delay sein müßte. Hattest du das schon getestet? Mßte in der stepper.cpp ab Zeile 353 sein. Immer hinter den WRITE. Ich würde das sonst heute Abend mal probieren.

ich lese mit

Nur verwechseln die auch die Treiber.
DM und THB sind anders.
DMT brauchen plus vom ramps oder ähnlichem, die THB -

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

Ich habe es getestet. 5µS Delay nach Wechsel des DIR Pegels (s. Git) bringen gar nichts. Ich hatte das befürchtet, will mir aber nicht vorwerfen lassen, nicht alles versucht zu haben.

[github.com]

darauf sollte man aufbauen
dann stimmt es beim layerwechsel aber läuft sehr undrund und nicht sauber durch

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

Quote
Le-Seaw
[github.com]

darauf sollte man aufbauen
dann stimmt es beim layerwechsel aber läuft sehr undrund und nicht sauber durch

Das ist im Kern ja nur ein Delay nach dem Step Pin. Hier werden 25! µS Delay eingeschoben (schleife läuft 5x und wartet entsprechend 5 x 5µS). Kein Wunder das das unrund läuft. Tut so ein langes Delay not?

 void step_wait(){
     for(int8_t i=0; i < 6; i++){
+               delayMicroseconds(5);
     }
 }

Zudem ist da auch noch ein Fehler, da bei 2 Motoren pro Achse glatt 50µS Delay gemacht wird was völlig unnötig ist

         if (counter_y > 0) {
           WRITE(Y_STEP_PIN, !INVERT_Y_STEP_PIN);
+          step_wait();
 		  
 		  #ifdef Y_DUAL_STEPPER_DRIVERS
 			WRITE(Y2_STEP_PIN, !INVERT_Y_STEP_PIN);
+			step_wait();
 		  #endif
 		  
           counter_y -= current_block->step_event_count;
           count_position[Y_AXIS]+=count_direction[Y_AXIS];
           WRITE(Y_STEP_PIN, INVERT_Y_STEP_PIN);
+          step_wait();
 		  
 		  #ifdef Y_DUAL_STEPPER_DRIVERS
 			WRITE(Y2_STEP_PIN, INVERT_Y_STEP_PIN);
+			step_wait();
 		  #endif
         }

So müßte das richtig.

         if (counter_y > 0) {
           WRITE(Y_STEP_PIN, !INVERT_Y_STEP_PIN);
 		  
 		  #ifdef Y_DUAL_STEPPER_DRIVERS
 			WRITE(Y2_STEP_PIN, !INVERT_Y_STEP_PIN);
 		  #endif
 +	step_wait();		  
           counter_y -= current_block->step_event_count;
           count_position[Y_AXIS]+=count_direction[Y_AXIS];
           WRITE(Y_STEP_PIN, INVERT_Y_STEP_PIN);
 		  
 		  #ifdef Y_DUAL_STEPPER_DRIVERS
 			WRITE(Y2_STEP_PIN, INVERT_Y_STEP_PIN);
 		  #endif
+	step_wait();
         }

1-mal bearbeitet. Zuletzt am 04.09.14 06:57.

das ist nur wenn du dual y hast, haben die meisten aber nicht
kannst ja mal mit delay 1 probieren.
ob es dann runder läuft

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

Naja, Doppel Z ist jetzt nicht soooo selten

Das klettert dann so treppenstufenweise hoch wenn die Stepper 25µS nacheinander angesteuert werden. Ich habe die Controller noch von gestern abend dran. Ich werds mal testen.

1-mal bearbeitet. Zuletzt am 04.09.14 10:06.

Ich habe mal eine modifizierte steppers.cpp angehangen. Ich habe dort an 4 Stellen einen wait eingefügt. Ich weiß nicht wie der code so wirklich funktioniert. Allerdings steckt das alles in einer Schleife. Der wait wird nur beim ERSTEN Schleifendurchlauf ausgeführt. Danach scheint das nicht mehr nötig zu sein.

if(i==0) step_wait();

In die config muß noch irgendwo folgendes rein

#define STEPPER_DELAY_MIKROSECONDS 4

Das ergibt einen wait von 20 Mikrosekunden was bei mir ausreicht. Ich habe mich von 1(5µS) aus rangetastet und bei 4(20µS) wirds gerade. Die wait sind nur auf X und Y

Es läuft ein wenig "ruppig" aber vielleicht ist es für den Entwickler ein Ansatz auf den er aufbauen kann. Wenn scheinbar nur der erste Pegel lang sein muß, kann man das eventuell auch irgendwie eleganter lösen.

1-mal bearbeitet. Zuletzt am 04.09.14 16:06.

wenn ich ehrlich bin versteh ich die Änderung nicht.
Du hast jetzt die Step pulse verlangsamt, aber er versteht die StepPulse ja richtig sonst würde er ja die layer selbst schon nicht richtig machen.
eigentlich sollte es an etwas anderem liegen.

Wenn ich ganz ehrlich bin: Ich verstehe es auch nicht so wirklich. Deshalb habe ich auch diese Bedingung auf den ersten Takt noch eingefügt. Vielleicht ist es wirklich wie Willy oben sagte, das sich da erst noch ein Kondensator aufladen muß. Wie das final gefixt wird, muß der Entwickler entscheiden. Zumindest habe ich versucht Anhaltspunkte zu liefern. Die insgesamt 40µS machen sich schon als zucken bemerkbar. Bei 5µS merkt man noch nichts. Ich werde heute Abend nochmal mit dem Wert der fallenden Flanke experimentieren. Vielleicht kann man da noch runtergehen. Ohne aber wirklich Hintergrundwissen ist das nur Try&Error

Aus dem Datenblatt gehen auch nicht wirklich Timings hervor oder ich kann sie nicht interpretieren. PDF ich kriegs leider nur als google link [www.google.de]

1-mal bearbeitet. Zuletzt am 05.09.14 02:49.

ja das Datenblatt ist eher schwach.
Ausser das der Step/Clk Eingang Flanken-gesteuert ist, und das die interne Logik trotz Enable off, die Steps weiter zählt, und nur den Output ausschaltet lässt sich ned viel unterschied rauslesen.

1-mal bearbeitet. Zuletzt am 05.09.14 05:22.

Vermutlich "verschluckt" er nur den ersten oder den letzten Puls. Ich werde mit den waits mal noch ein bisschen rumexperimentieren. Vielleicht kann man das vordere wait auch weglassen und nur das hintere verwenden. Oder mit den größen noch experimentieren. Ohne Mess Equipment ist das Ergebnis aber eher zufällig. zum Testen muß man immer 20-30 Layer drucken. Nervig ist nur das andauernde geflashe, was auf dem Netbook ewig dauert.

Okay, weitere Tests haben ergeben, das das jeweils zweite wait entfallen kann. Nur der erste WRITE muß gefolgt sein von einem 20µS delay.

Quote
turbotommi
[Datenblatt]. PDF ich kriegs leider nur als google link

... hier ist (m)eine "Quelle"

BUILDLOG.NET ... building CNC Machines...


THB6128 Test-Board Instruction.pdf
THB6128 IC Instructions.pdf

@Reinhold: Danke für die Links. Aber so wirklich neues steht da auch nicht, leider.

Ich habe jetzt nochmal einen Test mit 1/64 gemacht. Das Verhalten ist das selbe, wie bei 1/128. Die bewegung ist seidenweich aber bei kurzen travels springt der Drucker quasi vom Tisch. Es sieht aus, als ob die mikrosteps, die während des 20µS Delay gemacht werden sollten alle auf einmal gemacht werden und die Position knallhart angefahren wird. Das klappt ein paar mal und hört sich nur häßlich an aber irgendwann gibt es genau an der Stelle einen Schrittverlust. Es ändert auch nicht wirklich was, wenn ich den Drucker am Display auf 20% Speed runternehme. Wenn ich den Delay wieder rausnehme, ist der harte Sprung weg, aber leider die Schieflage wieder da. Somit habe ich glaube das Problem weitestgehend eingekreist. Mehr kann ich von meiner Seite aus nicht tun. Um gerade zu drucken, reicht ein Delay von 20µS hinter dem ersten WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN); Nur beschwört dies halt das Problem herauf, das kurze Travel mit hoher Wahrscheinlichkeit zu Schrittverlusten führen. Komischerweise fahren lange Travel (Auto Bedleveling - anfahren der Meßpunkte) auch seidenweich.
Irgendwie weigere ich mich auch daran zu glauben, das der Mega zu lahm ist. Ich habe das jetzt nicht bei 1/32 getestet, aber ich gehe fest davon aus, das das Problem dort das selbe ist. Leider fehlt mir der Gesamtüberblick über die Firmware. Somit kann ich nicht wirklich einschätzen wodurch das Verhalten auftritt und ob/wie man das fixen könnte. Solange das aber nicht getan ist, kann man den THB6128, als Chip egal auf welchem Treiberboard und von welchem Anbieter, unter Marlin nicht verwenden.

Ich muß mich korrigieren. Mit 1/32 funktioniert es einschließlich Delay. Ergebnis ist ein gerader Druck. befriedigend ist das selbstverständlich nicht. Man nimmt ja keinen THB6128 wenn man dann nur 1/32 drucken kann. In jedem Fall ist die Bewegung auf X/Y allein durch die Decay Regelung geschmeidiger als alles was ich von den anderen Treibern kenne. Der Unterschied 1/32 zu 1/128 ist aber trotzdem nochmal gewaltig. Wenn es mit der Repetier FW funktioniert, sollte es auch mit Marlin umsetzbar sein. Da ich das aber nicht fixen kann und auch sonst mit meinem Latein am Ende bin, werde ich als nächstes nochmal versuchen die Repetier FW auf dem 3drag Board zum laufen zu bekommen. Wer mir dabei helfen kann - herzlich willkommen. Prinzipiell geht nur das Display und die SD Karte nicht