Marlin auf Arduino-Due mit RADDS / RAPS128

Hallo,

ich habe meinen Rostock-Mini-RGB jetzt auf RADDS 1.2 mit RAPS128er Treibern umgebaut (ich muß ja meine Hardware auch mal "richtig" testen ). Repetier läuft wie erwartet . Mit Marlin und THB6128-Treibern (Silenciosos und diversen China-Boards) gab es aber in der Vergangenheit Probleme, die sich in Schrittverlusten zeigten. Diese sind bei meinem ersten Würfel nicht aufgetreten .

Allerdings ist die Bobc-Marlin Version noch weit von der gewohnten Marlin-Qualität entfernt. Was geht und was nicht:
1. LCD, Encoder und SD-Karte laufen (Back-Taste noch nicht)
2. Delta läuft (in der Pins.h müssen die max-Endstops eingetragen werden, was im Kommentar dabei steht)
3. Max. Microstepping = 1/32 (oder sehr langsam auch mehr).
4. Maximale Step-Frequenz = 40 kHz (wie beim AVR-Zweig)

Die Punkte 3. und 4. sind vermutlich auf das nicht vorhandene "fast-IO" in der Datei fastio.h zurückzuführen. Während beim MEGA eine sehr ausgereifte direkte Port-Programmierung erfolgt, verwendet die Due-Version digitalRead() und digitalWrite() aus der Arduino-IDE, was unsäglich langsam ist.

LG, Willy

---

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

Es wird noch ne Weile dauern, ehe es dort Ergebnisse gibt, aber im Moment ist ein großer Umbruch innerhalb der Marlin-Github-Community zu spüren, es wird versucht den Code aufzuräumen, alle Bugs auszumerken um eine stable-Version mit fester Versionsnummer zu schaffen.
Nicht Primär, aber doch zumindest auch Ziel der Aktion ist es, den Code soweit zu verschlanken, das auch eine Portierung auf 32-Bit Controller möglich sein soll. Wie lange das noch dauert ist fraglich, aber es steht zumindest schonmal auf der Todo-Liste.

---

LG

Jonas

Zu 4.:
Afaik geht Marlin wenn man die Frequenz hochsetzt auf bis max 65535 Hz. Zumindest ist dann bei den unsigned shorts Ende im Gelände. Manuelles hochsetzen der step_rate auf Long hat leider unschöne nebeneffekte. Kurz läuft alles aber dann geht wohl der Speicher oder sonstwas voll und man muss die Kiste reseten.

Quote
Willy
Die Punkte 3. und 4. sind vermutlich auf das nicht vorhandene "fast-IO" in der Datei fastio.h zurückzuführen. Während beim MEGA eine sehr ausgereifte direkte Port-Programmierung erfolgt, verwendet die Due-Version digitalRead() und digitalWrite() aus der Arduino-IDE, was unsäglich langsam ist.

Ich hab mir mal die fastio.h von Repetier angeguckt und da sehe ich so auf den ersten Blick bisher nichts für unseren SAM.

2-mal bearbeitet. Zuletzt am 28.12.14 18:19.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

65535 Hz bei Quadstepping. Das ist aber immer noch viel zu wenig für 1/128 Microstepping.

> Ich hab mir mal die fastio.h von Repetier angeguckt und da sehe
> ich so auf den ersten Blick bisher nichts für unseren SAM.

Aber auf den zweiten Blick . Statt digitalWrite(IO-Pin, v) mit v = HIGH oder v = LOW verwendet Repetier folgendes, was deutlich schneller ist:

#define _WRITE(IO, v) do { if (v) {DIO ## IO ## _WPORT |= MASK(DIO ## IO ## _PIN); }
else {DIO ## IO ## _WPORT &= ~MASK(DIO ## IO ## _PIN); }; } while (0)

LG, Willy

---

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

65kHz ohne Quadstepping, aber auch mit nicht schneller.

Wenn das mt der fastio so ist, kann man die fast 1 zu 1 von Repetier übernehmen.

1-mal bearbeitet. Zuletzt am 29.12.14 14:54.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
65kHz ohne Quadstepping, aber auch mit nicht schneller.

Hast Du das ausprobiert? Mit digitalWrite() kann ich mir trotz Due kaum 65 kHz vorstellen.

> Wenn das mit der fastio so ist, kann man die
> fast 1 zu 1 von Repetier übernehmen.

Sollte gehen. Blöderweise wollten die Github-Marlin-Wächter (oder so ) in der Vergangenheit partout keine Due Version und jetzt wird der Code gerade überarbeitet. Dadurch wird es zunehmend mühsam, die Änderungen von Bobc als ersten funktionierenden Ansatz zu übernehmen.

LG, Willy

---

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

Ja hab ich getestet. Aber da ich so extreme Temperatur-Probleme habe kann ich nix längeres testen.

Bei Marlin versuche ich mich gerade auch ein wenig mit einzubringen. Ggf. gibt es nen Due-Branch.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
... da ich so extreme Temperatur-Probleme habe kann ich nix längeres testen.

Das lese ich in Deinen Beiträgen mit, doch mir fällt dazu nicht wirklich etwas ein.

Ich habe jetzt 2 Drucker mit RADDS 1.2 und RAPS128 am laufen und bei beiden ist die Temperatur nicht so stabil wie bei MEGA-basierten Elektroniken aber durchaus ausreichend. Ich verwende für das Heizbett schon immer Bang-Bang (auch bei MEGAs) und für den Extruder die Totzeit-Regelung (rund 4 s bei 40 W Heizpatrone). Bang-Bang beim Heizbett ist fast wie PWM, da die gemessenen Temperatur-Schwankungen zu relativ schnell aufeinander folgenden Schaltvorgängen führen . Sinnvolle PID-Parameter habe ich noch nie gefunden - außer dass der I-Parameter nahe unendlich liegen sollte .

Quote
Wurstnase
Bei Marlin versuche ich mich gerade auch ein wenig mit einzubringen. Ggf. gibt es nen Due-Branch.

Warum 2 Branches? Die paar Compiler if-Abfragen sind doch eher harmlos und werden den AVR-Code wohl kaum "verderben"

LG, Willy

---

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

Ja mal sehen. Ich fang erst an mich mit dem Code auseinander zu setzen. Allerdings ist Marlin nicht wirklich gut aufgeräumt.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Mal nen Auszug aus Repetier:

#if CPU_ARCH==ARCH_AVR
#include "fastio.h"
#else
#define	READ(IO)  digitalRead(IO)
#define	WRITE(IO, v)  digitalWrite(IO, v)
#define	SET_INPUT(IO)  pinMode(IO, INPUT)
#define	SET_OUTPUT(IO)  pinMode(IO, OUTPUT)
#endif

Aka Marlin wie Repetier haben kein fastio für den Due.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Schon lustig, wie unterschiedlich wir beide die FW interpretieren

Ich hab' mal nach #include "fastio.h" in meiner Due FW vom Nov. 2014 (vermutlich work 0.92) gesucht und bin nicht fündig geworden. Dann habe ich die fastio.h umbenannt und das Compilieren funktioniert noch. Insofern hast Du recht, dass der Due die fastio.h nicht verwendet. Dann habe ich nach digitalWrite gesucht und ein paar mal gefunden - aber nicht an zeitkritischen Stellen. Das beim Due verwendete WRITE() ist vermutlich folgende Zeile in der HAL.h:

#define	WRITE(pin, v) do{if(v) 
    {g_APinDescription[pin].pPort->PIO_SODR = g_APinDescription[pin].ulPin;} 
  else 
    {g_APinDescription[pin].pPort->PIO_CODR = g_APinDescription[pin].ulPin; }}while(0)

LG, Willy

Edit: Jahreszahl von 2013 auf 2014 korrigiert.

1-mal bearbeitet. Zuletzt am 03.01.15 13:06.

---

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

Wenn die 4 Zeilen den Ausschlag geben. Ich schaffe es leider immer noch nicht mehr als 16bit für die step_rate zu nutzen. Hab schon an ein paar Hebeln versucht zu drehen, aber leider läufts nicht.
Also entweder 1/64 mit 204.79mm/s oder 1/32 mit genug speed.

Das Temperaturproblem liegt sicherlich an den 3.3V?!? Könnte man dort nicht nen andere Pullup setzen, zwischenpacken oder sonstwas? Man müsste dann ggf. halt die Temperaturtabelle anpassen.
Soll 250°C IST 248° bis 254°. Das bei eigentlich relativ guter Regelung. Mit Angelo hab ich es letzte Woche zumindest hinbekommen bei 240° bei +/- 1° waren.

Temperaturschwankungen von 6° sind mir viel zu viel. Da kann man nichts gescheit einstellen und die Ausdrucke sehen aus als ob man Z-Wobble hat, was aber an der Temperaturregelung liegt...

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

> Ich schaffe es leider immer noch nicht mehr als 16bit für die step_rate zu nutzen

Da bist Du jetzt aber wieder bei Marlin?

> Das Temperaturproblem liegt sicherlich an den 3.3V?!?

Vermutlich nicht nur. Auch zuviele DC/DC-Wandler und hohe Taktfrequenzen der RAPS128 könnten eine Rolle spielen, was ich aber bisher nicht feststellen konnte. Eine Sache ist mir aber auch schon aufgefallen: Wenn der DUE mit RADDS (ohne Motoren) über USB versorgt wird und statt eines Thermistors ein Widerstand verwendet wird, dann ist der berechnete kOhm-Wert geringer, als bei einer Versorgung über ein externes Netzteil. Es mag zwar sein, dass die 3,3V etwas von der Art der Versorgung abhängig sind, doch die Analog-Digital-Converter (ADC) setzen die vorhandenen 3,2 - 3,4 V als 100% und dürften bei einem Spannungsteiler keine unterschiedlichen Werte ausgeben . Leider muss man beim Due einen 0-Ohm-Widerstand umlöten, um den Aref-Pin nutzen zu können - sonst hätte ich mal die 3,3 V vom RADDS zurück an den Aref-Pin gegeben.

Wenn sonst nix hilft, könnten wir Repetier bitten, die Mittelwertbildung der Temperaturmessung über deutlich mehr Werte als bisher zu machen (auch der MEGA schwankt etwas - daher ist die Mittelwertbildung ohnehin vorgesehen).

LG, Willy

---

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

Quote
Willy
> Ich schaffe es leider immer noch nicht mehr als 16bit für die step_rate zu nutzen

Da bist Du jetzt aber wieder bei Marlin?

Jupp, ist ja eigentlich das Thema.

Quote

> Das Temperaturproblem liegt sicherlich an den 3.3V?!?

Vermutlich nicht nur...

Ja, an eine Mittelwertbildung oder nen Median habe ich auch schon gedacht. Kann es ggf. auch an den Due-Nachbau liegen, dass die Schwankungen so hoch sind?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Kann es ggf. auch an den Due-Nachbau liegen, dass die Schwankungen so hoch sind?

Tendenziell wohl eher nicht - der ARM-Chip ist ja auch bei den Nachbauten von Atmel (zumindest sehr wahrscheinlich). Ich vermute eher eine "ungünstige" ADC-Konfiguration. Allerdings habe ich nicht so richtig eine Chance, den Repetier-Code zu verstehen. Beispielsweise soll die Zeile

ADC_MR_PRESCAL(AD_PRESCALE_FACTOR) |

in der HAL.cpp den Prescaler auf 255 (= 1 MHz Sampling-Frequenz) setzen. Dabei ist AD_PRESCALE_FACTOR = 41 (warum nicht 42 ) und eine Funktion ADC_MR_PRESCAL finde ich nicht ...

Auch die Arduino-Programmierer hatten mit dem ADC etliche Probleme, wie die release-notes zeigen ...

LG, Willy

---

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

41 ist fast 42

Hier was ich gefunden habe:

 * -#   Set ADC clock by setting ADC_MR_PRESCAL bits in ADC_MR, the clock is
 *      calculated with ADCClock = MCK / ( (PRESCAL+1) * 2 )

Mit MCK bei 84MHz macht das mit (41+1)*2 = 84 aka 1MHz

Die ADC_MR_PRESCAL-Geschichte versteckt sich in der component_adc.h.

Vielleicht hilft es den Sensor eher mit 12bit aufzulösen?
Wohl keine gute Idee: [www.djerickson.com]

Macht es vielleicht Sinn den Prescal auf 83 zu setzen und mit 500kHz zu arbeiten?!?

Allerdings wenn ich das hier sehe: [frenki.net] dann weiß ich auch nicht weiter warum das ganze so daneben ist.

3-mal bearbeitet. Zuletzt am 05.01.15 09:48.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Also ich hatte ja die Marlin schon drauf und temp war immer stabil
Die hatte nie Probleme gemacht.
Eher die beschleunigungsrampen.

---

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 hatte einmal nen üblen Aussetzer bei Marlin und RADDS. Da ging die Temp um 10° höher und wurde dort geregelt...
Aber Marlin geht auch nen eigenen Weg was ADC geht und nimmt nicht die Standard-Bibliothek wie Repetier, wenn ich das auf die schnelle richtig überblickt habe.

Mit den RAPS128 gehen auch die Rampen gescheit. Aber da gibt es dann die Einschränkung mit den 65.535 Step/s hartkodiert.

1-mal bearbeitet. Zuletzt am 05.01.15 12:58.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Vielleicht hilft es den Sensor eher mit 12bit aufzulösen?
Wohl keine gute Idee: [www.djerickson.com]

Ich habe versucht () die djerickson-Seite zu verstehen, sehe aber nicht, dass er von 12 Bit Auflösung abrät. So wie ich das verstehe sagt er nur, dass man nicht mehr als 11 Bit erwarten sollte. Was ja schon ziemlich gut wäre .

LG, Willy

---

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

Gut, dann hast du schonmal mehr verstanden als ich Aber jetzt kann ich es auch rauslesen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ich wühle mich mal wieder durch bobc-Marlin durch. Vielleicht habe ich was gefunden.

293 #elif defined(ARDUINO_ARCH_SAM) 
294   timer = HAL_TIMER_RATE / step_rate; 
295 #endif 
296 
 
297   if(timer < 100) { timer = 100; MYSERIAL.print(MSG_STEPPER_TOO_HIGH); MYSERIAL.println(step_rate); }//(20kHz this should never happen) 
298   return timer;

HAL_TIMER_RATE ist 84MHz/32

Bei 80.000 steps/s kommen wir auf einen timer von ~32 und würden dadurch ja das ding da oben auslösen?!? Demnach dürfte ich maximal 26.250 steps/s haben?!?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

> Demnach dürfte ich maximal 26.250 steps/s haben?!?

Wenn die step_rate der Wert ohne 2x oder 4xStepping ist, dann kann das bei der "normalen" Marlin-Version ja sein.

LG, Willy

---

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

Ja, ohne Quadstepping etc.
Aber halt für den Due! Beim Avr wird der Timer über den Assembler/speedLookUpTable berechnet.

1-mal bearbeitet. Zuletzt am 07.01.15 05:09.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Willy
Schon lustig, wie unterschiedlich wir beide die FW interpretieren

Ich hab' mal nach #include "fastio.h" in meiner Due FW vom Nov. 2014 (vermutlich work 0.92) gesucht und bin nicht fündig geworden. Dann habe ich die fastio.h umbenannt und das Compilieren funktioniert noch. Insofern hast Du recht, dass der Due die fastio.h nicht verwendet. Dann habe ich nach digitalWrite gesucht und ein paar mal gefunden - aber nicht an zeitkritischen Stellen. Das beim Due verwendete WRITE() ist vermutlich folgende Zeile in der HAL.h:

#define	WRITE(pin, v) do{if(v) 
    {g_APinDescription[pin].pPort->PIO_SODR = g_APinDescription[pin].ulPin;} 
  else 
    {g_APinDescription[pin].pPort->PIO_CODR = g_APinDescription[pin].ulPin; }}while(0)

LG, Willy

Edit: Jahreszahl von 2013 auf 2014 korrigiert.

Da hast du recht. Das könnte man in der fastio.h von Marlin reinpacken. Sollte genauso funktionieren.
Edit: Hier noch nen netter Link dazu [www.kerrywong.com]

An der Interrupt-Geschichte bin ich mich gerade am einlesen und sehe da auch noch viel Potential.
Atm arbeitet Marlin mit nem Prescaler von 32. Also 2.625MHz. (Mega-Marlin 16MHz/8 = 8MHz) Da wir hier ja auch 32bit-Counter haben sollte auch nen Prescaler von 2 gut funktionieren.

1-mal bearbeitet. Zuletzt am 30.01.15 06:29.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

So. Teil 1 mit WRITE/READ läuft. Marlin ist gefühlt noch ruhiger geworden.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

2ter Teil läuft theoretisch auch. Konnte eben mit 300mm/s fahren bei 3000mm/s^2 und 320steps/mm.

Einziges Manko, beim Beschleunigen auf ~10000 mm/min ruckt es ein wenig.

Wenn ich morgen zeit finde, werde ich das mal im github hochladen.

1-mal bearbeitet. Zuletzt am 31.01.15 18:41.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Das Ruckeln hatte ich beim Delta mit Marlin (alte bobc-Version) auch beobachtet. Hast Du eine Idee woran es hängt?

LG, Willy

---

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

Also bei mir liegt es anscheinend am Trapezoid. Die Beschleunigungsphase läuft ruhig. Die Haltephase auch. Nur der Übergang zwischen Beschleunigung und Halten der Geschwindigkeit macht gerade Probleme.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Nochmal zum Trapezoid. Ich arbeite mittlerweile mit 32bit. Da gehen manche Zahlen bis 2^32.

Aber bei der Timer-Berechnung ist da nen MultiU24X24toH16.

// Calculate new timer value
    unsigned long timer;
    unsigned long step_rate;
    if (step_events_completed <= (unsigned long int)current_block->accelerate_until) {

      MultiU24X24toH16(acc_step_rate, acceleration_time, current_block->acceleration_rate);
      acc_step_rate += current_block->initial_rate;

Die Initialisierung sieht so aus:

#define MultiU24X24toH16(intRes, longIn1, longIn2) intRes = ((uint64_t)(longIn1) * (longIn2)) >> 24

Leider steig ich da noch nicht so durch...


Hier ist mal meine bearbeitete Version.
[github.com]

Das Ding ist ganz böse Alpha! Nix für den normalen Gebrauch. Wer sich damit auskennt, bitte mal drüber schauen und gucken was man ändern könnte/kann.



Modifikationen:
- Low-pass Filter für T0
- Moving Average für T_bed
- viele Variablen von Short auf Long geändert. Für 32bit sind short zu kurz
- ISR für stepper auf 42MHz
- ISR für temp auf 656kHz
- paar Delays eingefügt von Marlin-8bit (Ich glaube aber das die in nem Interrupt nicht funktionieren)
- READ/WRITE jetzt deutlich schneller

1-mal bearbeitet. Zuletzt am 01.02.15 08:24.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Gäääähn... Marlin läuft mittlerweile mit bis zu 4*46.000 Hz.

Irgend nen Timer läuft noch nicht über 16bit hinaus (CoreXY: sqrt(2)*46k = 2^16). Da bin ich noch am suchen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.