Marlin4Due

Hi all,

I spend last weeks a lot of time. And now most parts works.
Marlin4Due works with RADDS (also the RADDS-Display with the Back-Button) and also should work with RAMPS-FD V1/V2 (but not tested!).

All the extras which are new in the main-fork are implemented in Marlin4Due.

• Delta Autobedleveling
• up to 4 Extruders
• Filamentsensor
• improved Autobedleveling (G29 RLFB P V) for cartesian printers
• and many other things...

Have fun with it.

Many thanks to bobc for a great starting point!
Also many thanks to all Marlin-developers!

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hi,
Many thanks for your good work.
I'll be testing Marlin4Due in a few days, as soon as I get the couple of Due boards I have ordered (they are in the mail right now).
I'll report back in this thread.
Cheers,
Andrew

Which shield do you want to use?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I am going to use a standard RAMPS 1.4 shield hacked to allow for the 3.3V logic levels from the Due. Yes, I know it's a dirty hack but the RAMPS 1.4 costs less than $7 nowadays so I am quite comfortable with cutting traces / resoldering things etc...

You could then also try to resolder some 1k ohm instead of 4k7 for the thermistors. There are allready some temperature-tables for 1k pullups. This should make high temperatures much more stable, because the 3.3v are not that much for the ADC.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
You could then also try to resolder some 1k ohm instead of 4k7 for the thermistors. There are allready some temperature-tables for 1k pullups. This should make high temperatures much more stable, because the 3.3v are not that much for the ADC.

Thanks, will do that!

And the mailman just delivered the Due, so I should be testing your firmware very soon!

Quote
Wurstnase
You could then also try to resolder some 1k ohm instead of 4k7 for the thermistors. There are allready some temperature-tables for 1k pullups. This should make high temperatures much more stable, because the 3.3v are not that much for the ADC.

Bad idea. The SAM3X8E processor used in the Due has rather high ADC offset voltages. The resistors used on Duet electronics were originally 1K, but quite a few boards had to be replaced because the offset voltages were so high (but within the MCU specifications) that at room temperature the firmware could not tell the difference between a disconnected thermistor and room temperature. Duet electronics now uses 4K7 series resistors.

Why is Marlin4Due still using thermistor tables? Other 32-bit firmwares can handle any thermistor, all you need to provide are the R@25C and B values.

Edited 1 time(s). Last edit at 03/20/2015 11:10AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

OK, I downloaded the zip file for Marlin4Due from GitHub and extracted it, and installed the Arduino IDE version 1.6.1 on my Ubuntu 14.04 Linux box.

I then launched the new Arduino IDE, opened the Marlin.ino file, and proceeded to verify that it compiles fine, which it does.

I have just downloaded the compiled file to the Due using the programming port, and that too went fine.

Question: do I now have to switch the USB cable to the native port to use the Due as a printer controller?

@dc42

I believe Marlin uses tables for the thermistors simply because it's faster than calculating values, and the tables do not take a lot of space in flash.

Connected the Due (without RAMPS, I still have to hack it) to my OctoPrint box using the Due Programming Port at 250 000 baud, and it was recognized:

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: /dev/ttyACM0
Connected to: Serial(port='/dev/ttyACM0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Recv: start
Recv: echo:Marlin1.0.2
Recv: echo: Last Updated: Mar 20 2015 16:30:33 | Author: Marlin4Due
Recv: Compiled: Mar 20 2015
Recv: echo: Free Memory: 90848  PlannerBufferBytes: 1344
Recv: echo:Hardcoded Default Settings Loaded
Recv: echoteps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z4000.00 E500.00
Recv: echo:Maximum feedrates (mm/s):
Recv: echo:  M203 X300.00 Y300.00 Z5.00 E25.00
Recv: echo:Maximum Acceleration (mm/s2):
Recv: echo:  M201 X3000 Y3000 Z100 E10000
Recv: echo:Accelerations: P=printing, R=retract and T=travel
Recv: echo:  M204 P3000.00 R3000.00 T3000.00
Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
Recv: echo:  M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00
Recv: echo:Home offset (mm):
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echoID settings:
Recv: echo:   M301 P22.20 I1.08 D114.00
Recv: echo:Filament settings: Disabled
Recv: echo:Z-Probe Offset (mm):
Recv: echo:   M851 Z0.00
Recv: First start for temperature finished.
Send: M105
Recv: ok T:141.3 /0.0 B:0.0 /0.0 T0:141.3 /0.0 @:0 B@:0
Changing monitoring state from 'Connecting' to 'Operational'
Send: M21
Recv: ok
Send: M105
Recv: ok T:141.3 /0.0 B:0.0 /0.0 T0:141.3 /0.0 @:0 B@:0
Send: M105
...

(btw the smileys in the log above are a problem with the Phorum software)

Obviously the temperature reading are incorrect, etc... This was just a test to see if the communications part of the firmware was working, and indeed it is working.

Next step is to hack and install the RAMPS, apply 12V to it and check that I don't get smoke, then:

1. Connect an LCD controller
2. Install DRV8825 stepper drivers and test steppers
3. Install thermistors and test
4. Check the MOSFETS
5. Check that I can turn on an ATX PSU from the RAMPS

Each step is a little challenge...

Quote
AndrewBCN
@dc42

I believe Marlin uses tables for the thermistors simply because it's faster than calculating values, and the tables do not take a lot of space in flash.

That may be a valid reason for firmware that has to live with the limited calculation speeds of an 8-bit processor as in Marlin for Arduino Mega/RAMPS, but IMO it's a silly thing to do on a 32-bit processor, because it means that in order to support a new thermistor type, you have to construct a new table. 32-bit processors have more than enough power not to need tables.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

True, but Marlin already supports:

// -2 is thermocouple with MAX6675 (only for sensor 0)
// -1 is thermocouple with AD595
// 0 is not used
// 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup)
// 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup)
// 3 is Mendel-parts thermistor (4.7k pullup)
// 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !!
// 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup)
// 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup)
// 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup)
// 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup)
// 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup)
// 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup)
// 10 is 100k RS thermistor 198-961 (4.7k pullup)
// 11 is 100k beta 3950 1% thermistor (4.7k pullup)
// 12 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed)
// 13 is 100k Hisens 3950  1% up to 300°C for hotend "Simple ONE " & "Hotend "All In ONE" 
// 20 is the PT100 circuit found in the Ultimainboard V2.x
// 60 is 100k Maker's Tool Works Kapton Bed Thermistor beta=3950
//
//    1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k
//                          (but gives greater accuracy and more stable PID)
// 51 is 100k thermistor - EPCOS (1k pullup)
// 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup)
// 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup)
//
// 1047 is Pt1000 with 4k7 pullup
// 1010 is Pt1000 with 1k pullup (non standard)
// 147 is Pt100 with 4k7 pullup
// 110 is Pt100 with 1k pullup (non standard)

And there is a python script to build new tables...

Well, sure it could calculate it. But helps this with accuracy? I port that part only and it works perfectly.
Also, you have problems with room temperature? Did you ever print at 270°C or ~0.1V ADC? 3.3V aren't much for high temps.

Btw. I run Marlin with 1/64um with 320steps/mm at 300mm/s on a coreXY and there is air to more. With that kind of stepper driver the system is silent that you can here the plastic melting

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

New Question please: can I get higher baud rates than 250 000 baud if I switch to the native USB port to connect the Due to the PC?

Edited 1 time(s). Last edit at 03/20/2015 05:45PM by AndrewBCN.

Quote
Wurstnase
Also, you have problems with room temperature? Did you ever print at 270°C or ~0.1V ADC? 3.3V aren't much for high temps.

The SAM3X processor in the Due has a 12-bit ADC, compared with the 10-bit ADC of the atmega2560, so it is capable of better resolution at high and low temperatures. Some time ago I calculated that the ideal series resistor for 3D printer electronics would be about 3.3K, based on a temperature range of 0C to 300C, and suggested this to RepRapPro (who commissioned the Duet electronics design). So the 4.7K they chose to switch to is IMO higher than optimum.

If you have the thermistor ground connected to analog ground (not shared ground), and the series resistor connected to the analog reference voltage, it makes no difference whether you are using 3.3V or 5V. Unfortunately, the Arduino Due (like all the other Arduinos) was evidently not designed by professional electronics engineers, because it fails to provide a separate analog ground pin. The Arduino team has had years to learn this lesson, but have failed to do so. Nevertheless, by dedicating one of the several Arduino Due ground pins to serve as analog ground, you can get close to that ideal.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Marlin4Due runs with a 12bit ADC already. And yes I know your electronics and firmware...
Aref is no option on the Due as you know.

If I'm right, RADDS use the ground pins. But I'm not the right man to dispute. I start with bobc/Marlin and port the complete new code from 8bit and makes some modifications, so Marlin, as you had said just is an 8bit system, runs now top at high speed.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

@ dc42:

You are probably aware that Marlin4Due is a port of Marlin, which has been developed until now on the 8-bit AVR architecture. So it would be quite annoying and would really pollute this thread if you keep posting such remarks as "... but IMO it's a silly thing to do on a 32-bit processor..." and keep comparing Marlin4Due on RAMPS-FD/RADDS/hacked RAMPS 1.4 to RepRapPro firmware on Duet.


Let's think positive here, if you want to contribute some code I am certain that you know already how to fork the code on GitHub and make some pull requests. Or keep working on your code for the RepRapPro firmware, I'll be sure to give it a try in a few months time.

I added a pins.h file for the hacked RAMPS 1.4 board, and edited a couple of files as well as Configuration.h.
I am attaching the modified files to this post.
I reflashed the Arduino with the new firmware and I am now able to connect to it with OctoPrint and the temperature readings are correct on the two thermistors which I have temporarily hooked to the board, and I checked that they indeed respond to temperature changes by holding each thermistor between my fingers.

Next step is to connect a 12V supply and test one of the steppers. Oh, and also a Graphics LCD.

In case anybody is curious about the hacks, they are really simple, I have posted details and pictures in the Electronics/RAMPS subforum.

One more thing: apparently the SD card reader on the LCD Graphics controller uses a few pins from the Mega2560 which are not connected in the Due, if anybody knows more about this I would appreciate some hints about what to do.

Hi Wurstnase,

I am getting a compiling error if I enable the LCD support:

in dogm_lcd_implementation.h, this include fails: #include "dogm_font_data_ISO10646_1_Marlin.h"

It seems this file is generated by a Windows batch file in the /fonts directory, and that creates a dependency on Marlin4Due being compiled in Windows, whereas I believe standard Marlin can be compiled on any OS?

Could you please take a look into this?

Thanks,
Andrew

Maybe I deleted to much. Just brought back the u8glib.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I gave up on the Graphics LCD for now and tried the 2004 LCD Controller:



Contrast was really bad so I had to adjust the trimpot all the way, but... it's working! The backlight is a little bit dim because of the 3.3V supply, but it works, so I quite happy with that too.

The kill switch also works, however the rotary encoder and the buzzer are not working (yet).

The SD card reader would require some extra wires coming directly from the Due and I don't print from the SD card anyways, so I am not going to implement or test it.

I disabled SD card support in the configuration but had to make a number of small changes to ultralcd.cpp to get the conditional compilation fixed. I am including both files.

Next step is to get the rotary encoder and buzzer working, then another go at the Graphics LCD.

For your info: "Note: use hardware SPI only, soft SPI not supported"
while I'm visiting your pins_RAMPS.h.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Sorry, I forgot to upload the updated pins_RAMPS_14_HACKED.h. Here it is.

SPI is used by Marlin to access the SD card reader on the LCD Controller board, however unfortunately the standard RAMPS 1.4 avoids using the ICSP header which sits smack in the middle of most Arduinos, it uses the MEGA2560 pins 50 to 53 for this. The Due does not. So to use hardware SPI in the Due I would have to install an extra connector sandwiched between the Due and the RAMPS, and I am thinking that since I rarely if ever use the SD card on my printers (I use OctoPrint), it's just not worth the trouble.

One can see the extra connector used in the RADDS board:



I may investigate a software SPI implementation later, but at this stage I have simply disabled SD card support in Configuration.h (by commenting out #define SDSUPPORT).

I was one of those guys that didn't read the reviews before buying a Ramps-FD V1 RevA. Now that I have one ,along with an Arduino Due, I would like to see how I can help others in the same boat. Wurstnase I will upload your Marlin4Due Firmware and try it out. Is there anything I need to consider on the hardware part of this board before I load the firmware?

Yes, please check the inverted heater. This should work now, but maybe I miss something. So please upload the firmware without power of your power supply and check this first.

Also there is no EEPROM on RAMPS-FD if I'm right. This will be the next part for Marlin4Due but I need some time to rewrite this part to use the flash instead.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
AndrewBCN
I may investigate a software SPI implementation later, but at this stage I have simply disabled SD card support in Configuration.h (by commenting out #define SDSUPPORT).

You can also use #define SDSS 4 as this is the microsd-slot from the Due.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Any known problems with the delta configs? I pulled this down and can build the default config cleanly, but the delta configs (from examples) fail with undefined symbols, IIRC, mainly centered on Z_DIR_PIN, although the X and Y equivalents do not error. I'm going to dig into it, but figured I'd ask first in case this might be known due to a recent change.

I can post the detailed error if desired, but not on that system at the moment . . .

- Tim

OK, got that worked through . . . the example*/deltas/Configuration*.h files are definitly not for this version, or viable as they sit, despite the relatively recent update as per git. The above problem was corrected by correcting the omission of "Conditionals.h" from "Configuration_adv.h". The next issue is a missing definition of a z axis offset, that is normally set with auto bed levelling, and which is apparently mishandled when that is undefined. Defining levelling then throws errors from SanityCheck that no Z limit is set . . . .

Getting there, and hopefully this helps. I note that the baseline configs are labelled as for Marlin 1.3, and these are 1.2 . . . does this port run clean 1.3 config files, or have other changes been made? IE, would finding a set of co fig files for a delta on1.3 be a shorter path to a viable config?

Thanks,

- Tim

Looks like I may be good to go! I pulled example_configurations from the current mainstream GIT, and got the 1.3 dev delta configs. The only thing that was unreferenced in the Marlin4due port was "MEDIAN_COUNT" in Configuration_adv.h, which I added, and now have a delta config that compiles cleanly!

Next, to try to put my config in and see if it still compiles! But at least I have a good start!

Also, I suggest that the delta sample configs in the Marlin4due GIT branch be updated . . . What's there now is not usable . . .

- Tim

Last update - config is in, builds cleanly . . . Now I justs need to get hardware since I know it builds, and test for real . . . Hopefully, I'll have the Due tomorrow, and need to order the RAMPS-FD . . .

Looks good so far, though . . . Hopeful for use on my Kossel . . .

- TIm