Is the new Arduino Due compatible with RAMPS 1.4?

According to an article in wired, the Arduino Due goes on sale tomorrow for $49.

"The long-awaited Arduino Due just hit the market, replacing the 8-bit, 16MHz brain of the popular Uno microcontroller prototyping platform with a 32-bit, 84MHz processor, while augmenting inputs and capabilities all around."

And an article in hackaday says:

"The board looks strikingly similar to the already common Arduino Mega. That’s no mistake; the DUE is compatible with existing shields, so connecting a RAMPS board for your 3D printer should be a snap."

So it sounds like there is a good chance it will be compatible. The logic voltage changed to 3.3V from 5V, but my amateur's reading of the Pololu stepper driver specs indicates that should still work. But will the voltage change screw up some other aspect of interfacing with RAMPS? Will standard firmware still work with the Arduino Due? Will it really be as simple as swapping out the Arduino Mega for an Arduino Due?

I know Josef Prusa has one, but I have no idea if he's tried it yet.

FWIW: The only issues I can think of are:
Thermistors (maybe different tables, or have some sort of scaling mechanism?)
Pololus (which would be fine)
Input voltage (can the Due adequately dissipate that heat with a shield like RAMPS sitting on top of it)

IMO none of these should be show-stoppers.

Note: Things like the SD card add-on, thermocouple drivers and LCD boards may require some changes, as at least many of the LCD setups use 5V (though most can use 3.3V). You'd want to check that each of those will work fine with a 3.3V setup.

The thermistors and endstops would need to be run at 3.3V, to avoid sending an out-of-range signal back to the Due; probably the easiest way to do this would be to replace the RAMPS 5V supply by 3.3V throughout.

The heater control MOSFETs may also require changes, as too low a control voltage will only partly turn them on, causing them to overheat.

Firmware that only used the Arduino libraries would work, but I don't know whether this exists; firmware that directly uses AVR features won't work.

You're on the right track, rebecca.palmer. At least the MOSFETs need replacement.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I can see many MOSFET choices for low RDSon at Vgs=2.5V that may work: [ec.irf.com] but most are SMD.

The FDP8860's also have a low Vgs (2V from memory) so they should be fine too.

Greetings all,

From the schematic http://www.reprap.org/mediawiki/images/3/3f/Arduinomegapololushieldschematic.png
The MOSFETs for the three heater/fan channels are part# STP55NF06L whose datasheet is available online at [datasheet.octopart.com]

Figures 3 and 4 give the most relevant data. Figure 3 indicates that with Vgs = 2.5 volts, the Max current (drain to source) is just above 15 Amps. (2.5 volts is conservative, but we cannot guarantee 3 volts from an I/O pin driven by logic with a 3.3 volt supply.)

Since the X axis of Fig 3 is in volts and the vertical axis is in Amps, the initial slope of the 2.5 Vgs curve is its resistance in ohms. By eyeball, that appears to be on the close order of 3 volts / 30 Amps, thus an effective resistance R_ds of 0.1 Ohms. On one hand, this is large compared to the effective resistance if the gate were to be driven to a full five volts (or even a diode drop below.) However, what we really care about is (1) how much voltage drop does the MOSFET "steal" from whatever it's driving and (2) how much power is dissipated in the MOSFET (namely, will it get too hot.) From the R_thj_a value of 62.5 deg. C / Watt (and ambient temp @25 and max junct temp of 150 {conservative, the datasheet says it can handle up to 175 deg. C}), we have P_max_noHeatSink = (150 -25)/62.5 = 2 Watts max. Now P = i^2 R. From this, i_max is sqrt(20) == 4.47 Amps. That's plenty for fans, but not enough for max power through a nominal PCB heated bed (0.8 ohms, which would draw 15 Amps from 12 volts.) A heated bed with a higher resistance, namely 3 ohms (12 volts / 4 Amps) and up ought to work with the original MOSFET.

I know I found at least one MOSFET with a nice low Vgs, suitable for 3.3V logic. Now I have to search for it again. If I find it, I'll post the part#.

I think the Pololus will have the wrong logic threshold unless you power them from 3.3V rather than 5.

---

[www.hydraraptor.blogspot.com]

I got this from the Pololu website about the A4988:

"The driver requires a logic supply voltage (3 – 5.5 V) to be connected across the VDD and GND pins..."

Does that mean it will work on a 3.3V system, or does that mean it just needs 3V to run, and still needs the 5V for a signal? Either way, it explicitly says on the DRV8825 page that they work on 3.3V or 5V logic.

Oh, just looked up the pins on the Due and the RAMPS layout, and I see what you're saying nophead; it looks like all the VDDs are connected to a 5V pin that's still 5V on the Due. I had assumed they were connected to IOREF.

Quote
TopherMan
Does that mean it will work on a 3.3V system, or does that mean it just needs 3V to run, and still needs the 5V for a signal? Either way, it explicitly says on the DRV8825 page that they work on 3.3V or 5V logic.

I think that means their logic level is the same as their power level (i.e. if you power them at 3.3v, then 3.3v logic will work, if you power them at 5v, then 5v logic will work). -- Which is weird, because most TTL logic is just 0 = "below 0.7v", and 1 = "above 0.7v".

I'm kind of late to the party here, but so, is there a new RAMPS board for the Arduino Due (or other ARM compatible board)?

RAMPS is OLD. It's not by default compatible with the Due.

There are no plans as far as I'm aware for an updated RAMPS. It also has an issue with heatbeds running at >16V, due to the use of a PTC fuse that is only rated to 16V. It's an old design that has probably had its day.

A few people have made RAMPS-like boards that work with the Due (eg: RADDS). Note that RAMPS-FD is not really well supported, and the default ones being shipped are usually V1's, which need mods to make them work reasonably. Especially if you're not someone who understands code AND/OR new to electronics, I would definitely avoid RAMPS-FD.

FWIW: There have been a few bad experiences with some of the online distributors selling stuff that was still in development and not finished/not ready (notably RAMPS-FD). Many have been asked to withdraw them from sale and stop producing them but they carry on regardless. All we can do at this point is to make sure people are aware and avoid buying them.

BTW: Just so we're clear, I helped bobc with some of the work on RAMPS-FD. Both bobc and myself stopped working on the project, and we both agree it's probably not worth anyone picking it up again.

FYI, there is a Due port know as Marlin4Due which supports RADDS, and both versions of RAMPS-FD . . . The FD v1 support is very good and works . . .

- Tim

The big design flaw of the Arduino Due IMO it that it uses an Ethernet-capable chip, but doesn't provide the Ethernet port. By the time you have added RADDS or RAMPS-FD and good quality driver modules to an Arduino Due, I suspect that you could have bought a Duet or MKS-SBASE board for less. Both these boards have the advantages of software-controlled stepper motor current, on-board SD card socket, and on-board Ethernet. Both are available for $60.

Edited 1 time(s). Last edit at 07/29/2015 04:41AM 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].

I don't see any advantage to have ethernet on an embedded system.
When I want a connection to my infrastracture at home I would prefere a wifi-module. I use a raspberry pi II where I can also connect a webcam. Also the upload speed of gcode is much faster.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Wurstnase
Realtime CPU (Arduino Due) has only to support the 3d-Printer (Motor, Thermistor, Endstops, SD-read ...).
All other addons reduce the realtime CPU power.

All other Feature maybe with an Raspi, UDOO Quad a normal PC or an 8" Windows Tablet ..

---

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

Quote
Wurstnase
I don't see any advantage to have ethernet on an embedded system.
When I want a connection to my infrastracture at home I would prefere a wifi-module. I use a raspberry pi II where I can also connect a webcam. Also the upload speed of gcode is much faster.

Lots of embedded systems provide a web interface. The web interface is a huge improvement on using a USB host program, and it allows me to use my printers in a room without a PC. Uploading gcode takes 6 seconds per Mbyte, which I find fast enough, although there is work in progress to improve it.

I agree that WiFi would be better for most users. Yes you can do the same by adding a Rpi to the system (although an Rpi doesn't have WiFi either), but IMO the extra complexity is not worth it unless you want a webcam as well.

---

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

Quote
Wurstnase
I don't see any advantage to have ethernet on an embedded system.
When I want a connection to my infrastracture at home I would prefer a wifi-module. I use a raspberry pi II where I can also connect a webcam. Also the upload speed of gcode is much faster.

Exactly what I think. Which is why I created this page in the wiki: OctoGoatBox

A 100MHz ARM single core M3 or M4 CPU simply does not have enough processing performance to handle WiFi and 3D printer controller tasks simultaneously. In the end you always end up with a multi-CPU architecture as the most efficient way.

Note that it does not have to be an RPi 2 quad-core to handle OctoPrint, you could use anything with the CPU processing performance of an Cortex A8 and above (the original RPi is a little bit underpowered imho). It's just that the RPi 2 is the most practical solution these days and one of the least expensive ones too.

Edited 1 time(s). Last edit at 07/29/2015 01:03PM by AndrewBCN.

You may be right in asserting that a 100MHz M3 processor has insufficient processing power to run WiFi, but it certainly has enough power to serve web pages over wired Ethernet. Even an Arduino Uno can do that. For WiFi, a board with its own processor is probably a better option. The $2 ESP8266 may or may not be able provide a good web interface on a 3D printer. I intend to research it.

Now that multicore CPUs are so cheap, it would be interesting to dedicate one core of a 4 core processor to real time tasks, and run Linux and Apache on the other 3 cores. Do you know of any Linux distros that allow one core to run separately from Linux in this way?

Edited 1 time(s). Last edit at 07/29/2015 03:06PM 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].

@dc42

The hardest to overcome issue is that the Linux kernel itself does not support RT, and there is no way (that I am aware of at least) to have it "release" one core in a multi-core setup to load another OS or embedded task. Then of course there are many other far from trivial issues such as memory bus contention, shared memory and caches management, power management of separate cores, shared peripherals (DMA controller, timers, etc), etc.

The simplest solution is to have two CPUs, one of them being for example a $4~$6 ARM M4 SOC with internal flash, eeprom and RAM, and the other a standard $5~$10 multi-core ARM A7, with external RAM, EEPROM or EMMC and a WiFi module. If you have them on the same board it would be nice to have them exchange data over a low latency serial interface which is very easy to program.

Basically this boils down to putting an OctoGoatBox on the same board as the 3D printer controller, which may or may not be a good idea in terms of reliability, electrical noise, etc.

The ESP8266 module is really not practical as a WiFi interface for 3D printer controllers because of its excessive command/response latency and rather low bandwidth.

@AndrwBCN, thanks for your reply. It's a shame Linux isn't flexible enough to support this configuration.

I am aware that with the standard firmware, the ESP8266 is nowhere near adequate for this application. The question is whether it would be adequate with better firmware. At 80MHz the CPU core should be fast enough, and the 96K of RAM is has should be plenty for the packet buffers. Some variants of the ESP8266 break out the SPI pins, which should be able to provide better bandwidth to the chip than the standard async serial interface.

Edited 3 time(s). Last edit at 07/30/2015 12:41PM 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].

Quote
dc42
@AndrwBCN, thanks for your reply. It's a shame Linux isn't flexible enough to support this configuration.

Well actually it's not the Linux kernel, which is comparatively quite flexible in and of itself. It's because what you are asking for is almost impossible to program. I am not aware of any OS/kernel that implements RT and separate core management for multi-core CPUs.

Quote
dc42
I am aware that with the standard firmware, the ESP8266 is nowhere near adequate for this application. The question is whether it would be adequate with better firmware. At 80MHz the CPU core should be fast enough, and the 96K of RAM is has should be plenty for the packet buffers. Some variants of the ESP8266 break out the SPI pins, which should be able to provide better bandwidth to the chip than the standard async serial interface.

It's not the performance of the CPU in the ESP8266 modules that is questionable nor the amount of RAM available (btw the 96k of ram is almost entirely used by the WiFi functionality, there are just a few k's left for user programs afaik), the fact is that the WiFi protocol itself is not designed for low latency communication. Also, there are some G-code commands that you cannot or should not buffer too deep, etc.

An OctoGoatBox works very well to provide WiFi connectivity for a 3D printer because you basically download the entire STL or G-Code file to the OctoGoatBox and then it does its job, sending the G-code commands in real-time to the printer controller on a relatively low-latency serial link. There is no way to reproduce the same setup using an ESP8266 module, even if you undertake the rather arduous task of reprogramming its firmware.

Linuxcnc code seems to show that Linux and RT tasks are quite compatible. In fact some people are using Beagle Bone Black (that also includes a RTU) for controlling 3D printers or CNC machines while it can deal with TCP/IP and/or wifi at more than reasonable performance out of a single ARM processor.
[www.element14.com]

Of course all that does not have much to do with the original question on this thread :-)

Edited 1 time(s). Last edit at 07/30/2015 01:24PM by misan.

Ahem... yes indeed the BeagleBone Black includes an AM335x 1GHz ARM® Cortex-A8 [beagleboard.org] SOC and that specific SOC has a pair of 200MHz Real-Time Units (PRUs), which are really separate RISC CPUs with their own instruction and data RAM blocks [www.ti.com]. So, yes indeed the Cortex A8 @ 1GHz is able to handle the various OctoPrint/WiFi/G-code parsing duties and the RTUs can handle the steppers-related RT tasks fine.

Which is all nice and good until you check the prices... The BB-Black is more expensive than an RPi 2 despite being a lot less powerful, and the BB cape is terribly expensive (over 100€). And you still need a rather specific proprietary SDK to develop the code for the RTUs.

Linuxcnc unfortunately uses an outdated Linux 2.6 kernel patched with real-time extensions, that only works on 10-year old PC x86 hardware (ARM is not supported at all) *.

It is not easy to find an Open Source real-time Posix kernel for the ARM architecture with proper support for current SOCs and with an Open Source toolchain. I am not an expert in this area but I try to be reasonably informed nonetheless, and I am not aware of any.

So all this brings us back to the inexpensive (around $45), proven, easily put together and Open Source solution of adding an OctoGoatBox to any existing 3D printer controller.

And indeed all this has nothing to do with the original question in this thread!

* Edit: Misan has pointed out to me that indeed there are experimental versions of LinuxCNC/Machinekit for ARM, using unofficially supported Linux kernel patches that implement real time functionality. See [www.machinekit.io] for more information. Machinekit is a 2014 fork of LinuxCNC. LinuxCNC as far as I know remains x86 only: [www.linuxcnc.org]

Edited 2 time(s). Last edit at 07/30/2015 04:46PM by AndrewBCN.

Quote
AndrewBCN
It's not the performance of the CPU in the ESP8266 modules that is questionable nor the amount of RAM available (btw the 96k of ram is almost entirely used by the WiFi functionality, there are just a few k's left for user programs afaik), the fact is that the WiFi protocol itself is not designed for low latency communication. Also, there are some G-code commands that you cannot or should not buffer too deep, etc.

An OctoGoatBox works very well to provide WiFi connectivity for a 3D printer because you basically download the entire STL or G-Code file to the OctoGoatBox and then it does its job, sending the G-code commands in real-time to the printer controller on a relatively low-latency serial link.

What I am looking to do is to get a fast enough upload speed over WiFi to the ESP8266 and then by SPI to the printer controller board so that I can upload the file to SD card before printing - just as I do with my Duet-controlled printers (also over WiFi for one of my printers), and much the same as you do on OctoGoat. WiFi latency shouldn't be an issue, the challenge is to get enough bandwidth.

The Duet manages to get the TCP/IP stack, web server and the complete 3D printer control stuff in 96K of RAM. So I would think 96K ought to be enough to fit the TCP/IP stack and the WiFi extra stuff, and probably the web server too. But I haven't taken a detailed look at the ESP8266 firmware yet, so there may be other obstacles.

---

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