RADDS work now stable with RepRap Firmware

Hello,

Dan Newmann has make an amazing Job.

I will looking for guys who would like to test it and can give us a Feedback.
For the first 3 Tester I will give a RADDS v.1.5 and 4xRaps128 + a RADDS LCD-Display for free.
You have to look for the Shipping cost + the Arduino Due (UDOO Quad ...).
Thank you in advance.

[github.com]

[www.youtube.com]

---

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

Amazing!
I have a arduino DUE and would be glad to test RADDS on RepRapFirmware.
My printer currently running Mega+RAMPS setup, I was thinking about an upgrade. That's why I bought Due board.
I don't mind paying shipping.

i will try it now on my udoo Radds combination.
I am still struggling with my serial communications (flaky, difficult to find why)

Not sure if i should put it here, but think it is relevant because it will make the testing off RADDS on Udoo easier.

Anybody who knows a combination of software that works with Udooquad and RADDS?
i would like to use the new reprap firmware.

problem1: the RepetierServer 0.65 doesn't know the reprap firmware.
problem2: The alternative for RepetierServer, Octoprint will not install on Udoobuntu 2 (Udoobuntu 1v1 gives problems with the serial connection which are almost non existent with the UdooBunto2 beta 2)

so which combination should work? i can do a commandline install on linux but the moment i have to rebuild kernels etc, or manual have to solve missing dependencies, i am lost.

Any help would be appreciated.

thanks,

Pieter

Hi Pieter,

have you tried with the images for "Debian Wheezy armHF" or "Ubuntu 12.04 LTS" ?

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Hi,

I have the reprap firmware installed and configured on my printed, but i have some remarks/problems to report:

-the upload of the firmware in my arduino due (is a clone) board only works using the native port. But In the documentation is explicit indicate is necessary to use the programming port.

-The pronterface only connect using native port. Pronterface do not work very well with the firmware, is there a better one?

-Most of the times the connecting process fail. To connect correctly is an process of try and error. I need to shutdown the printer, disconnect the usb from the pc and try again, only have success 1 in 2 or 3. Any clue what i doing wrong?
The error i get:
[ERROR] Could not connect to COM7 at baudrate 115200:
Serial error: could not open port COM7: [Error 2] The system cannot find the file specified.
i have added the line of gcode "M106 S255 P1 "in my config.d file to start at max the fan of the hotend, found that sometimes the fan do not start when power up the printer. When this happen i can not connect the printer. Other time the fan auto start when i power and the connection work. It appear that sometimes the firmware do not read the configuration in the sd card. I have the sd card in the micro sd of the board.

-I have 3 min and 3 max endstop, when i do M119 only appears 3 endstop! There is the option to have the 6?

-to configure my printer i using was base the script in the folder "sys-CoreXY", the homey.g and homex.g script that do the homing of x and y has movement of the z, why? I have removed the gcode of the z axis, but there is any reason that have them?

-in pronterface when i click in SD to make an SD print, no file appears. I have 2 files *.gcode. I missing something? is necessary to put the gcode is some special folder or the SD functionality is not working? Already try to put in an folder called gcode and on the root of the SD card, none have worked.

-I have an led light connected to the hotend 2, i using on repetier gcode M355 to ON/OFF. Any similar option in reprap?

Edited 7 time(s). Last edit at 10/17/2015 05:43PM by filipeCampos.

... check and/or log the voltage levels of the Due and the USB-port - could be, you have shorts or spikes, which reset the controller or cancel the communication ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I haven't used the RADDS port of RepRapFirmware, but I will answer your points as best I can. Others who are familiar with the RADDS port may be able to provide better answers to some of them.

Quote
filipeCampos
-the upload of the firmware in my arduino due (is a clone) board only works using the native port. But In the documentation is explicit indicate is necessary to use the programming port.

On boards other than RADDS, RepRapFirmware is uploaded via he native port using the bossac program.

Quote
filipeCampos
-The pronterface only connect using native port. Pronterface do not work very well with the firmware, is there a better one?

In what way(s) does Pronterface not work very well with it? There are other USB host programs, e.g. Repetier. Most users of RepRapFirmware use the web interface through the Ethernet port, but you don't have that on the RADDS board.

Quote
filipeCampos
-Most of the times the connecting process fail. To connect correctly is an process of try and error. I need to shutdown the printer, disconnect the usb from the pc and try again, only have success 1 in 2 or 3. Any clue what i doing wrong? The error i get:
[ERROR] Could not connect to COM7 at baudrate 115200:
Serial error: could not open port COM7: [Error 2] The system cannot find the file specified.

There is a bug, probably in the Windows driver stack for the Arduino Due, that has the following effect. If you are connected to the printer, then you shut down or reboot the printer without first doing Disconnect in Pronterface, then Pronterface will eventually auto disconnect. But after that, it will always fail to connect, with that error. To reconnect, you need to disconnect and reconnect the USB cable, or if that doesn't work, unload and reload Pronterface. To avoid the problem, always do Disconnect in Pronterface before switching off or rebooting the printer. btw the baud rate is ignored because it is a native USB port.

Quote
filipeCampos
i have added the line of gcode "M106 S255 P1 "in my config.d file to start at max the fan of the hotend, found that sometimes the fan do not start when power up the printer. When this happen i can not connect the printer. Other time the fan auto start when i power and the connection work. It appear that sometimes the firmware do not read the configuration in the sd card. I have the sd card in the micro sd of the board.

Possibly the RADDS port needs to allow a little more time for the SD card to initialize. Try a different SD card.

Quote
filipeCampos
-I have 3 min and 3 max endstop, when i do M119 only appears 3 endstop! There is the option to have the 6?

No. Like most firmwares, RepRapFirmware uses the switches only for homing. Once the printer has been homed, axis movement is limited by the soft endstops configured by the M208 command.

Quote
filipeCampos
-to configure my printer i using was base the script in the folder "sys-CoreXY", the homey.g and homex.g script that do the homing of x and y has movement of the z, why? I have removed the gcode of the z axis, but there is any reason that have them?

It's to avoid dragging the nozzle over the bed if it is already touching the bed. It's up to you whether to have it or not.

Quote
filipeCampos
-in pronterface when i click in SD to make an SD print, no file appears. I have 2 files *.gcode. I missing something? is necessary to put the gcode is some special folder or the SD functionality is not working? Already try to put in an folder called gcode and on the root of the SD card, none have worked.

Put them in a folder called /gcodes on the SD card.

Quote
filipeCampos
-I have an led light connected to the hotend 2, i using on repetier gcode M355 to ON/OFF. Any similar option in reprap?

See [reprap.org].

Edited 1 time(s). Last edit at 10/18/2015 03:32AM 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

Quote
filipeCampos
-the upload of the firmware in my arduino due (is a clone) board only works using the native port. But In the documentation is explicit indicate is necessary to use the programming port.

On boards other than RADDS, RepRapFirmware is uploaded via he native port using the bossac program.

I was pointing this was a problem because in the next documentation radds is indicate to connect the usb to the programming port of the computer.
I lose more than 1 hour to solve this because i was sure that i was using the correct usb port, someone must correct the documentation to the other person do not have the same problem.

Quote
dc42
There is a bug, probably in the Windows driver stack for the Arduino Due, that has the following effect. If you are connected to the printer, then you shut down or reboot the printer without first doing Disconnect in Pronterface, then Pronterface will eventually auto disconnect. But after that, it will always fail to connect, with that error. To reconnect, you need to disconnect and reconnect the USB cable, or if that doesn't work, unload and reload Pronterface. To avoid the problem, always do Disconnect in Pronterface before switching off or rebooting the printer. btw the baud rate is ignored because it is a native USB port.

Tested and your are correct. My main problem was to shutdown the printer without disconnecting before.

Quote
dc42
Possibly the RADDS port needs to allow a little more time for the SD card to initialize. Try a different SD card.

I using an class 10 8gb sd card, tested with an class 4 and same problem. Is easy fixed by power again the printer until the fan start correctly. Any suggestion about the SD card that must use?

Quote
dc42

Quote
filipeCampos
-in pronterface when i click in SD to make an SD print, no file appears. I have 2 files *.gcode. I missing something? is necessary to put the gcode is some special folder or the SD functionality is not working? Already try to put in an folder called gcode and on the root of the SD card, none have worked.

Put them in a folder called /gcodes on the SD card.

Works..

Quote
dc42

Quote
filipeCampos
-I have an led light connected to the hotend 2, i using on repetier gcode M355 to ON/OFF. Any similar option in reprap?

See [reprap.org].

I do not undestand, the link point to ativation of pins. My led is connected to the hotend 2. Can you provide more info?

A new question: I using an relay, is there an option to configure the bed controllo using an bangbang with delay?

Edited 1 time(s). Last edit at 10/18/2015 05:48AM by filipeCampos.

As to the programming port to use, that's really outside the scope of the RADDS board. It's 100% an issue with the Due. And I and others program the Due using the programming port with no difficulty. Indeed, it is easiest to use the programming port since then you do not need to press the reset or erase buttons. You can, of course, use the native port if you prefer but that's up to you. However, I'll stress that this isn't a RADDS issue per se: this is an issue with uploading code to an Arduino Due.

> A new question: I using an relay, is there an option to configure the bed controllo using an bangbang with delay?

No, you cannot configure the heater manager as you can with Repetier. Note that RepRapFirmware (dc42 port at least) has additional PID parameters you can adjust.

As to turning an LED on/off, the point is you can connect it to one of several unused digital I/O pins and then control it via M42. The unused I/O pins presented by the RADDS are the Due pins indicated in the link dc42 provided,

On RADDS hardware running RepRapFirmware-dc42, the supported Arduino Due pin numbers and their names are:

5 TIOA6
6 PWML7
39 PWMH2
58 AD3
59 AD2
66 DAC0
67 DAC1
68 CANRX0
69 CANTX0
70 SDA1
71 SCL1
72 RX LED
73 TX LED

Now, if those pins cannot supply enough power for the LED lights, then you might want to use the Fan1 output on the RADDS and turn it on and off with

M106 P1 Snnn

where nnn is a 0 - 255 PWM duty cycle with 0 OFF and 255 ON 100%.

As to your SD card issue, I do not have any good advice: I myself am not seeing issues with my SD cards on RADDS using the microSD slot on the RADDS board itself. It's not something I'm in a position to diagnose. But it does sound like on occasion your sys/config.g file isn't being accessed. If you're connected via the USB native port when reseting the board, some basic diagnostics will appear telling you if config.g could be processed or not. You can connect to the port using the Arduino app @ 115,200 baud (IIRC).

As an alternative to powering the machine off and on until it manages to read the SD card, try just pressing the Reset button on the Duet if you can reach it. That way, the power to the SD card will already be stable. Otherwise, I can't really help, because the SD card interface on the RADDS is not the same as the one on the Duet that I am familiar with.

---

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

Additional comments

1. The documentation for uploading the RRF firmware for RADDS to the Due was missing the "-U false" switch needed when directly driving bossac and using the programming port. I've updated the documentation with that information,

https://github.com/dcnewman/RepRapFirmware/blob/dev/doc/RADDS-v1.5.md

Note that the documentation is for using the programming port since the Due's ERASE button is inaccessible when the RADDS shield is mounted to the Due. When using the native port, you need access to that button as well as the RESET button. For the programming port, you only need access to the RESET button. (And if you use the RRF for RADDS build system, then you do not even need to use the RESET button; the build system will automatically toggle DTR on the port for you.)

2. The SD card issues. We have not yet tested the LCD UI interface. We have not yet tested the SD card slot on the LCD UI board. There may be a race condition when using it between the pin change interrupt placed on the SD "detect switch" and the code which asserts the pullup resistor on the GPIO pin attached to that line. We don't know; attaching the LCD UI board is not yet supported. As I write this, I am working on that code and should start testing it within a week. Use the microSD slot on the RADDS board for now and disconnect the LCD UI board.

We have also seen issues with the SD card after uploading firmware. A reset (or power cycle) would be needed to get the SD card working after some firmware uploads. This likely relates to the SD card being attached to SCLK, MISO, and MOSI. During the upload, if the cards CS line goes sufficiently low, then the SD card may wake up and get into an odd state. That's just a guess.

Hi,

Adding -U false to the line command and using programming port was worked.

About the SD card problem i only tested using the microSD of the board, i do not have an lcd for the radds to make the test. Using the reset power of the radds board solve the problem.
Most of the time the problem do no happens, but when is happens pronterface do not connect to the board. I telling this because i not sure if is correct to assume the problem is related with the micro SD reader. If the problem was only the sd reader, then the firmware was up and pronterface will connect correctly?

Today i have make the next print using radds and reprap firmware.
Darth Cader
It was printed at 0.15 resolution, speed 60mm/s. I have put the gcode in the SD card, connected the printer to pronterface, started the SD print and disconnected the printer from the computer.
The print take 5 hours and there was no problem, the overall print quality is fine. But because i have an relay, it was 5h of bang bang bang bang...

I have tested octoprint and there are some functionality that are not compatible, like for example the default fan ON/OFF buttons.

Edited 2 time(s). Last edit at 10/18/2015 03:32PM by filipeCampos.

Quote
filipeCampos
Hi,

Adding -U false to the line command and using programming port was worked.

Good.

Quote
filipeCampos
If the problem was only the sd reader, then the firmware was up and pronterface will connect correctly?

I no longer use pronterface myself. I do not know offhand how well it does or does not work with RepRapFirmware. It's entirely possible that the problem is something else. Did you build the firmware yourself from the github repo or did you install the RepRapFirmware-1.09k-dc42-radds.bin file from the repo? I ask as I did have a bug a while back whereby there was a race condition at startup and the firmware could hang but that is fixed in the 1.09k .bin file. I have also encountered at least one case where declaring a "pin" to be non-existent by setting it to -1 in the Pins_radds.h file caused the firmware to hang. It would ALWAYS hang so that's not what you are seeing. But if you are building the firmware yourself, then is it up-to-date? If it isn't up-to-date, then you could be seeing that race-condition bug which I had fixed (and was solely in the RADDS-only code).

Quote
filipeCampos
I have tested octoprint and there are some functionality that are not compatible, like for example the default fan ON/OFF buttons.

1. Foosel and Mark Walker have fixed this in the dev branch of Octoprint. At issue is that Octoprint was issuing "M106" to turn the fan on and not the more complete "M106 S255". That works with some firmwares but not all: some firmwares assume "S255" while others do not (e.g., Teacup, RepRapFirmware, MachineKit). You can add your own control to the control panel which does "M106 S255", you can check out the dev branch of Octoprint and use that, ochange the underlying templates in Octoprint to include "S255", o wait for the next release of Octoprint.

2. You will also find that Octoprint intercepts M0 and just pauses the printer. For RepRapFirmware that is not appropriate as M0 for RepRapFirmware actually turns the heaters off, disables the stepper motors, closes all open SD files, and likely some other things as well. Foosel and crew are working on a new comms layer which will likely address that. In the meantime, Mark Walker made a new Octoprint plugin to prevent Octoprint from intercepting a M0,

https://github.com/markwal/OctoPrint-RepRapPro

That plugin may not yet be in the plugin repository in which case you need to install it manually if you want to use it. Or, you can not use M0 for the time being. Since you were using Repetier before, I'm guessing you were not using M0 for your end gcode. But in case you were, that's one workaround. Another workaround is to manually turn all heaters off and manually disable the stepper motors.

As to the bang-bang-bang-bang, at present RepRapFirmware only provides PID-based PWM heater control. I do not know if the maintainers of the core RepRapFirmware have considered adding bang-bang style heater control. There are safety considerations with software-based heater control in which a heater is repeatedly turned on 100% full during the course of the entire print. Fortunately, RRF has a working watch dog timer. But, bang-bang style heater control may have been considered and intentionally not added. I myself do not know. It might be worth posting in the firmware forum here.

Edited 1 time(s). Last edit at 10/18/2015 10:37PM by dnewman.

@filipeCampos

I just uploaded a new build of 1.09k of the RepRapFirmware for RADDS,

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.09k-dc42-radds-a.bin

You might want to give that a try and see if it improves the SD card issue. (However, immediately after uploading firmware to the Due, I often find the SD card not working and have to do a power cycle. Again, I believe that's caused by the SD card also being on the SCLK / MISO / MOSI lines.) I made one simple but possibly important change. Before hanging a pin change interrupt on the SD card detect switch, the RADDS-specific code was configuring the GPIO pin setting it as an input. However, it was not enabling the internal pull-up resistor. Later, in the lower level SD card code, the pull-up was then enabled. But, not being enabled initially before the pin change interrupt was established may have led to sporadic behavior, sometimes causing the SD card to appear to not be present (GPIO pin caught floating low). This would not explain issues with pronterface but might explain issues you saw with the SD card. You can see the change in the 18 October 2015 github commit.

RepRapFirmware already supports bang-bang control of heaters, and it is the default for the bed heater. You can switch between PID and bang-bang using the M301 or M304 command. A negative P term selects bang-bang control.

---

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

Hi,

I have tested using the already compiled RepRapFirmware-1.09k-dc42-radds.bin file, today at the end of the day i will try your new version and check if solved the problem of the SD card.

I still using an 40A relay because before i was using an ramps board, but now with radds or duet board not sure if the relay is necessary. I think i will simply remove it, connect the bed directly to the board and start to use pid control.

I have only made simples test with octoprint, like moving the axis, hotend and bed temp, fan, etc.. Still have not try to make an complete print with octoprint, but im planning to use it only to start sd print.

Quote
dnewman
@filipeCampos

I just uploaded a new build of 1.09k of the RepRapFirmware for RADDS,

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.09k-dc42-radds-a.bin

You might want to give that a try and see if it improves the SD card issue. (However, immediately after uploading firmware to the Due, I often find the SD card not working and have to do a power cycle. Again, I believe that's caused by the SD card also being on the SCLK / MISO / MOSI lines.) I made one simple but possibly important change. Before hanging a pin change interrupt on the SD card detect switch, the RADDS-specific code was configuring the GPIO pin setting it as an input. However, it was not enabling the internal pull-up resistor. Later, in the lower level SD card code, the pull-up was then enabled. But, not being enabled initially before the pin change interrupt was established may have led to sporadic behavior, sometimes causing the SD card to appear to not be present (GPIO pin caught floating low). This would not explain issues with pronterface but might explain issues you saw with the SD card. You can see the change in the 18 October 2015 github commit.

I have installed this new version and the problem was not solved. If the usb stay connected to the usb port of the pc and i power on and off the printer the problems never happen. It appears it only occur when the arduino board is shutdown too. The reset of the radds boad immediately solve the problem. Other test i have made is to check if giving power to the arduino first and them power to the printer solves this, but no, the problem occur.

Maybe an issue with the Due?!? [forum.arduino.cc]

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Maybe an issue with the Due?!? [forum.arduino.cc]

I using an cheap chinese clone arduino, the board quality is not the best and it can be some hardware problem. But so far i never have this connection problem when using repetier firmware.
The problem is only on the startup and only happens sometimes, far to be consider a big issue.

Is there are some way to get log information or something similar that can help to understand the reason?
I am the only one reporting this problem?

Repetier doesn't attempt to use the SD card when it boots. RepRapFirmware does; RepRapFirmware attempts to load its configuration from SD at boot. That is a major difference. And if the SD card doesn't appear to be functioning at boot, then it will be marked as unusable until the SD card detect switch indicates that it has been removed and re-inserted (RADDS port of RepRapFirwmare). However, the RADDS board itself does not have a SD CD switch so there is no way for the firmware to know that the SD card has been removed and re-inserted. At that point, your only recourse is to reset the processor with the RESET button on the Due.

If the Due is powering off of just USB power, then that's a max of 0.5A out of a computer. That may not be sufficient current for the Due, the RADDS with its stepper drivers mounted, and the SD card? So, if the problem happens when powering just over USB that *may* be an issue. However, from my Mac things work fine with the Due, SD card, 6 stepper drivers, a 4.3" TFT LCD, and a second ARM chip driving the LCD display. Different computers may allow different max currents over USB though.

However, if your PSU is a soft-start which doesn't provide full voltage/current for the first 100ms or so, then that could be an issue: the USB power will be locked out by diodes but insufficient initial PSU current may be available initiially. In that case, the SD card reads may not work owing to the low voltage. Doing a reset once stable power is established and finding things working does suggest a problem with the initial power.

Quote
filipeCampos
Is there are some way to get log information or something similar that can help to understand the reason?
I am the only one reporting this problem?

If you're connected via the native USB port when the RADDS boots, you'd see it logging an inability to read config.g from the SD card if that is happening. If you're in a position to build the firmware yourself,

https://github.com/dcnewman/RepRapFirmware/blob/dev/INSTALL.md

then you could see if increasing the delay at

https://github.com/dcnewman/RepRapFirmware/blob/dev/src/MassStorage.cpp#L90

helps. The sd_mmc_init() call just sets up GPIO pin configurations. Its the later sd_mmc_check() call which then tries to communicate over hardware SPI (using DMA) with the SD card. Trying delay(100) or delay(200) there might be informative.

As to anyone else seeing this issue, not many people are using RepRapFirmware on RADDS. This port of RepRapFirmware to RADDS is very new and only a handful of people have begun using it on RADDS. It's very stable and well established on the Duet board but that board is a single board with the SAM3X8E built in and uses the SAM3X8E's high-speed SD comms interface. The Arduino Due does not expose that interface and the much slower hardware SPI interface must instead be used. I myself have not seen this issue with my two RADDS boards, both of which also communicate with PanelDue's over TX1/RX1 (AUX1 connector) and Raspberry Pi 2 model B's over the native USB interface. The power supply is a 24V supply, Meanwell SE-350-24. I've simply never had a problem EXCEPT right after downloading new firmware over the programming port. Then, and only then, I sometimes see the SD card not responding and I have to power cycle the Due. However, I'm only one data point.

Edited 1 time(s). Last edit at 10/19/2015 07:23PM by dnewman.

Hi,

I have installed pyton 2.7 and scons 2.4, but in the command line when i type scons it not reconize the program.
scons installer was not set corretly my ambient variables? What i doing wrong?

I will try compile the firmware using eclipse.

Make a new terminal window and try the scons command again. (Or refresh your environment.)

If that doesn't work, then scons is not in your PATH and you need to either add it to your PATH or give the full path to it to run it. Are you using Windows by any chance?

Setting up Eclipse is a bit of a chore as you then have to get everything all properly defined in the project. And do NOT use Mars. Use the prior eclipse release. Too much stuff is not yet working correctly with the Mars release.

Using windows 10 and is cmd.
I do not know pyton language and not familiar how it works.

Scons install some lib in pyton directory, where is the exe path?
I have installed mars and after reading your last post already removed.

Sorry, I don't use Windows myself. Hopefully someone else reading this is familiar with how scons and python bolt themselves onto Windows.

You definitely do not want to mix Mars and the Arduino Eclipse Plugin without first verifying if a very nasty bug in the Arduino Eclipse plugin has been fixed. It was a bug which, when doing a "clean" of your project's build area, would start deleting every file on your computer.... I hit that bug myself. Fortunately, I had backups of my system. It may now be fixed. So, just to be safe, don't use the Mars version. Use Luna instead.

I have made more testing and i think the problem i reporting was nothing to do with the firmware.

I have changed repetier firmware to start with an led light ON. Uploaded repetier and made same test of switching on/off the printer and cheching if the light is on. Well, i found it produce an similar problem. Sometimes the light is not on and is not possible to connect to the printer.

Knowing i using an cheap chinese arduino due clone, i almost sure the board is causing this. After i found this i have ordered an better quality arduino due (sainsmart) from ebay. When i receive the board i will make the replacement and check if the problem still happens. For now i think the best is ignore this issue.

---

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

Hi,

Next printscreen is pronterface printing from an SD card, in the console it output no stop "Not SD printing", this is some bug?

There is a known bug in some versions of RepRapFirmware that in response to the M27 command (which is flagged as deprecated), it reports "Not SD printing" when it should report "SD printing", and vice versa. So I wonder whether your version of Pronterface is sending M27 repeatedly? The version of Pronterface I am using (Printrun 2014.08.01) doesn't do that.

---

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