Repetier Firmware + Duet

Hi,

Since there is no official thread for the Repetier FW for the Duet ARM board, here it is...

Duet electronics looks very promising given the manufacturability of the board (SMDs, etc.) and a design which I would prefer to RADDS given the potential EMI issues with THD components - it's also an all-in-one solution with some cool features like ethernet plug and an expansion board for more extruders . I noticed that there is already some discussion on using Repetier's products on the ARM electronics, e.g.:
Thread: A faster ARM controller
Thread: Repetier-Host V0.90D for RepRapPro Ormerod printer
Google Groups Discussion: Now printing with Repetier firmware on the Arduino Due

Is there going to be an official release of the Repetier Firmware for the Duet in the near future? I believe this is done fairly easily since the firmware already supports ARM Cortex M3 CPU architecture (aka Arduino Due), and RADDS in particular. If it's just a matter of changing the pin configuration, then it's a piece'o'cake. Or do we need to consider something else?

Yes, duet seems to be nice all in one board and there are several others like the smoothieboard which are based on arm.

The big problem is, that the folder contains the due name for a reason. It uses the Arduino arm infrastructure for the hardware layer and the hardware abstraction layer is optimized for that board. The nice thing is, that it already prooves the code is runable on arm infrastructures. So for add-on boards like RADDS or RAMPS-FD it is only modifying the pins.h.

So all we need is a new hardware layer for each board or each ARM processor type. I guess all the different available arm types need some modifications to the available registers/ports.And the Arduino IDE will not work any more, so we also need a working and free compilation queue for it.

So if someone owns a duet and feels like writing/adopting the due HAL-files, I will include that in the main github branch.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

As far as I can tell, the support for RADDS and RAMPS-FD are already implemented - at least the online configuration tool for the firmware has such options + pins.h have the entries for these boards.

RADDS, RAMPS-FD and Duet are based on Arduino Due, i.e. the same ARM CPU for all boards (Duet is based on Arduino Due according to Duet Wiki). IMHO this implies that no new hardware layer except changing the pins.h would be required, right?

If I am right, then why do we need to adapt the HAL-files for the Duet?

(The case of a Smoothieboard, which is based on a different ARM CPU (LPX..) is a totally different story.)

Hi andin

The Duet uses some pins which are not defined in the Ardunio Due variant, look in your arduino directory:
hardware\arduino\sam\variants\arduino_due_x\
variants.h
variants.cpp

In the short terms I worked around this with a library which is available from github:
[github.com]

In the longer term it will be better to define a different variant for the Duet.

The Arduino Due also does not support the high speed SD card and ethernet functionality that the SAM3X8E has built in, We have libaries for these as well:
[github.com]

along with the libraries needed for the Digipot to set the stepper driver current.

I would be very happy to assist where I can with getting Repetier expanded to work on the Duet, its a little more work than just changing pins.h but not a huge amount. I dont have the time to do the port myself though, Repetier (is it Marcus?) if you like I can send you a Duet - PM me.

Cheers

Tony

---

DuetWifi.: advanced 3d printing electronics

I simply did not know that Duet is based and compatible to due, also the name should suggest that. In that case it simply adding a new pins.h section with correct settings for it.

So we need a volunteer to dig through the docs and find the pin usage and test it on his board:-)

BTW: Do you know if the duet supports a eeprom like RAMPS-FD and RADDS?

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hi Repetier

It does not have EEPROM, but you could write to flash

---

DuetWifi.: advanced 3d printing electronics

I am currently finishing my work on a dedicated controller board for the extruder which has some really cool features and talks with the main board (currently megatronics) over serial. I have used a processor, not in the Arduino list, and I therefore needed to define a separate variant in order to program it from the Arduino IDE. I have no experience with ARM so far, but I think creating a different variant for Duet should not be a big deal.

I will try adapting the pin.h and writing the variant. I really need the power of ARM (additional serial, more steps and other ideas I am working on).

Writing to FLASH: yes, but only when required- otherwise the flash will not last long. Maybe use an SD card for the settings?

Hey Andin

Using the SD for the settings and allowing all settings to be set by G-Code is the long term goal of RepRap firmware

Tony

---

DuetWifi.: advanced 3d printing electronics

Hi Tony,

sounds like a good plan. Alternatively, you could put an EEPROM-chip on board, but doing this with an SD-card is probably better for the end-user since the settings can be uploaded easier from the host-sw.

So far, I have wrote all the code for controlling my extruder board within the Repetier FW and seem very happy with how it works so far. Repetier has already implemented some nice features like servo control, z-probing, extruder change GCode, etc. which I use in my custom 3d printer. Porting all of this to another Firmware feels like more work - and this is just when I start to see the results of my efforts...

I am happy with the idea of the Duet - in my opinion it is a step forward beyond RADDS/RAMPS-FD which IMHO ignore potential EMI problems (ARM clock speeds + Through-hole components = trouble). It would be awesome if you could use the DRV8825 driver instead of the old allegro stepper driver. Exchanging them should not be a big deal, but would provide more power; thus more acceleration and higher speeds for printing.

RepRap Firmware seems like a next generation firmware, specifically designed for ARM which is awesome. How far is the development?

By the way, ErikZalm is already developing an all-in-one ARM board for the Ultimaker based on ChibiOS, and it looks awesome so far:
Marlin II

One solution I prefer for the eeprom problem is a 4k ram array which fakes the eeprom. So it gets first initalized like a new eeprom with wrong eeprom mode copying data from Configuration.h. Then if a sd card is detected it would try to open a eeprom image file (lets name it eeprom) and replaces content in ram with it. Now we could work with it like we had eeprom thanks HAL virtualization. All we need is a command to write back the EEPROM-RAM to sd card incase we want to keep data. That would greatly reduce write cycles so the sd card will live much longer. EEPROMs have a quite high live expectancy compared to flash ram. Thinking about this, a load/save command for eeprom would be great even for avr, so we could backup it. Just no autoload in that case.

For porting I see only the extra pins as a problem. With a new variant like done with other arduinos this should be fixable. The digipot is already supported since it is included in the RAMBO board. Ethernet is not used anyway. For sd card we use an other library. If the duet uses SPI for communication it should still work even if not using the fastest modes. Still fast enough for printing. Otherwise we would need a complete new abstraction layer for sd cards and edit all usages of sd cards so we could switch between different libraries.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

andin - the RepRap firmware is working well and is under heavy development - but currently only for cartesian printers. I am using it with the Kraken hotend in a 4 colour/material setup:

[blog.think3dprint3d.com]

As far as the eeprom/flash/ram debate is concerned the requirement for saving alot of settings is reduced if you use gcode to set everything - then you can have a "config.g" that is read from the SD card. Also settings can be prepended to each print file if you like using the start gcode function in slic3r and other slicers. That said repetier your suggestion of adjusting settings and save back to config.g would be a good addition but is the really a need to emulate an EEPROM in RAM? Is this just for backwards compatibility? Maybe have a test to say EEPROM present-> save to EEPROM, EEPROM not present -> save to config.g

All the pins are defined in the library I linked above so creating a new variant should be easy. The main reasons I have not done so is its marginally easier for a new user to add a library than a new variant, and the current solution is working.

The Duet uses the newer SD specification (HSMCI) not SPI to interface with the SD card, this supports SD2.0 cards (SDHC) which are common now, also the SPI bus is free for other things. There is a fully working library and implementation in the RepRap Firmware I linked above.

Edited 1 time(s). Last edit at 03/01/2014 09:55AM by T3P3.

---

DuetWifi.: advanced 3d printing electronics

The eeprom thing is more a question how variables get initalized. All functions assume them in some ram storage reachable with the HAL-EEPROM functions. So I either have to rewrite the whole firmware to use a different variable getting approach or make a virtual EEPROM and I can keep using the existing functions. So it more logical to use this approach.For some values there is even no config storage at all. They are always taken from eeprom or default values are used.

With the sd card it is a bit difficult. I need to virtualize the sd library so I can switch between different libraries. I do not assume both are interface compatible. So the hard part would be to include the other sd library as well.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Quote
T3P3
andin - the RepRap firmware is working well and is under heavy development - but currently only for cartesian printers. I am using it with the Kraken hotend in a 4 colour/material setup:

[blog.think3dprint3d.com]

Heavy development sounds awesome. Does it also support a CoreXY or H-Bot coordinate systems? Is it also heavily tested in the community? Is it in the beta-stage or do you already have a release version?

I already looking into your blog - nice setup! I am using E3D hotends and I am a huge fan. However, I am still reluctant to using the bowden-setup - I don't think it can still cope with a direct-feed extruder in terms of printing accuracy. IMHO multiple nozzles (in this case 4!) would exacerbate the problem with retraction and oozing of the bowden-setup. It would be awesome if you can prove me wrong with your tests!

I will be hiring someone who will be in charge of electronics. I will ask him/her to look into RepRap Firmware and check how it fits with other electronics we have in our printer. Does it support a Display and do you already have some vendor-specific libraries for some of the displays out there (e.g. the full graphics display from RepRapDiscount)?

(I apologize for asking questions which are off the initial topic)

Hi Andin

Its for "standard" cartesian printers only at this stage but that mainly because no one has started working on Delta, or Hbot yet - I sure that will come in time.

As for its use in the community it is used in the RepRapPro Ormerod (check out the Omerrod area of these forums). The make use of the IR bed levelling proble, axis compensation, ethernet web interface etc but only on a single extruder printer right now. Alot of the firmware development is driven by users on Ormerod part of the forums, especially upgrades to the web interface.

A bowden setup does inherently have more opportunity to ooze but a lot of this can be overcome with retraction and choosing the right printing strategies. As for multiple nozzles, ooze is still a problem for me, but I have reduced it by using the Slic3r features of building a skirt around the object and by cooling the inactive hotends. The downside of the cooling is that it adds to print time.

I want to add a display but the code is not yet in the firmware - another area for development! I designed the Panelolu2 to be compatible across a variety of older electronics (Sanguinololu, RAMPS, Melzi, Printerboard) and I am considering adding support - right now time is the big factor!

Cheers

Tony

Edited 1 time(s). Last edit at 03/03/2014 08:31PM by T3P3.

---

DuetWifi.: advanced 3d printing electronics

Hi Tony,

thanks for the info.

I just feel that IR-probe sounds like a lot of noise: dust on the bed, temperature variations, ambient light are notorious enemies of such sensors. I have tried it myself for z-probing and not happy with the precision. But as always, I like traditional views being proven wrong, so I will follow the development of the Ormerod! Community always finds a work-around

For start, you could try implementing a TFT display with a serial interface such as uLCDs from 4D-Systems- super easy to program and communicate to.

Will stay tuned for your progress!

Best,
Andi