RADDS work now stable with RepRap Firmware

BTW,

printing is impossible. Also after homing, i.e. the main print part, I see regularly moves that are not executed because of a startspeed or endspeed equal to NaN. If this happens RRF loses track of the head's position.

At the same time I'm confident that the firmware should be OK, sufficient people are using it. The RADDS board doesn't look relevant as the problem occurs in the calculation part.

Something wrong in the configuration sounds more plausible.

I can provide more debugging output if case this helps.

Edited 2 time(s). Last edit at 07/08/2016 08:10AM by turboproc.

---

Prusa I3 | E3D hotend | RAMPS 1.4 | Printing PLA directly on glass
Eustathios | E3D Volcano hotend | RADDS 1.5 / Arduino Due | Printing PLA directly on glass

Quote
shofman
Ok thanks.

About steppers : is there any interest to use 1/64, 1/128 or 1/256 configuration ?
My motors are : 17HS16-2004S

I usually run my Kossel at 1/16 microstepping with interpolation to 1/256, but I've run it at 1/128 microstepping too and it works well. I haven't tried 1/256 yet, I need to get the dynamically variable microstepping working to do that otherwise the step pulse rate for fast travel moves gets stupidly high. The machine uses 17HM19-1684 motors, which are slightly less powerful than yours.

Edited 1 time(s). Last edit at 07/08/2016 08:42AM 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].

Your motors are 0.9°, and mine are 1.8°
So if i use 1/32 and you use 1/16, we are in the same configuration ?

So I suppose this kind of tune is not very important ?

Quote
shofman
Thanks Dnewman... I will stay with M569 because it just works.

About the RAPS128 : is there any interest to use 1/64 or 1/128 configuration ?
My motors are : 17HS16-2004S

I went down to 1/64, because I'm using 0.9° steppers and want to print ( read laser engraving ) at 250mm/s. That wasn't possible with 1/128.
They are still very quiet, I hear the linear rails rattling louder than the steppers.

the user guide says to power RADDS by 24V the diode used in the default 12V setup have to be
replaced by three Zener diodes (4 V and 1.3W).

is 4.3v 1.3w ok?

[edited to change 25V to 24V. 25V was a typing error.]

Quote
deaconfrost
the user guide says to power RADDS by 24V the diode used in the default 12V setup have to be
replaced by three Zener diodes (4 V and 1.3W).

is 4.3v 1.3w ok?

Somewhere you should also find amongst the RADDS documents that you do not need to do that for the v1.5 RADDS electronics. That's my recollection at least. I use 24V with my v1.5 boards and I've never made that mod.

Edited 1 time(s). Last edit at 07/09/2016 09:40AM by dnewman.

Quote
shofman
Your motors are 0.9°, and mine are 1.8°
So if i use 1/32 and you use 1/16, we are in the same configuration ?

So I suppose this kind of tune is not very important ?

Our systems are not really comparable, because I am using a Duet WiFi with a 120MHz SAM4 processor, you are using 84MHz SAM3. Increasing the microstepping from 1/16 without interpolation (which is what I was using when the machine was controlled by a Duet) has made the printer much quieter.

---

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
dnewman

Quote
deaconfrost
the user guide says to power RADDS by 24V the diode used in the default 12V setup have to be
replaced by three Zener diodes (4 V and 1.3W).

is 4.3v 1.3w ok?

Somewhere you should also find amongst the RADDS documents that you do not need to do that for the v1.5 RADDS electronics. That's my recollection at least. I use 25V with my v1.5 boards and I've never made that mod.

That's great, thanks

I'm about to order the Radds with Due and LCD together

do I need to plug in power to the Due like the mega on ramps? or does Radds provides power to the Due, or can it be wired up to the Radds for power, so one plug in the mains?

Edited 1 time(s). Last edit at 07/09/2016 03:53PM by deaconfrost.

radds provide power, you just need to enter your 24V or 12V into the 2 connector , check the wiring instruction

That's great, have them ordered waiting for delivery should be in a couple days

I got this working, but not the way I want. This is what looks like happened if I had to venture a guess:
* Something went bad with either the endswitch, or wire itself, which initiated this problem around the time I switched to 1.13.
* I bought a new endstop, and completely rewired it, making it NC instead of NO.
* Regardless of what S0/S1 setting I set in M547, I couldn't get it to detect the 'closed' state: It was "always open" no matter what when I ran a M119 depressing it or not.
* Using my ohm meter, I could clearly detect the switch, at the terminal where it plugs into the board, was switching open/closed correctly.
* I rewired it back as NO, and it started working again as expected.
These are the switches I picked up: [www.amazon.com]
My guess is that even though you can wire them as NC, possibly because they have an LED on that pin, it screws things up. Not sure.
Gladly take any suggestions for NC endstops that are known to work with RRF.

Regardless, now all the funky behavior is gone: Homing works fine pre/post gcode printing.

Quote
AK_Eric
@GroupB : My bot is core-xy, and the build volume and offsets are correct in S3D. Same settings I've used in there for Marlin, Repetier, and now RRF.

@DC42 : My endstops are 'normally open' microswitches: If I depress the X-endstop and enter a M119 I get

SENT: M119
READ: Endstops - X: at min stop, Y: not stopped, Z: not stopped, Z probe: not stopped

And the endstop is definitely hit before anything else.

@truboproc : My config.g looks very similar.

So, it's the morning: I power my bot on and issue:
G28 X0 Y0
And it works just fine, as expected. But, if I start a print, if I execute that at the end of my print in gcode, or if I execute that over a serial connection at the end of a print, it'll smash.
Below is the header and the footer of the gcode that causes it, if anyone can spot a problem?

Edited 1 time(s). Last edit at 07/12/2016 12:30AM by AK_Eric.

Hello, I have the same problem than you with my endstops.
The Mechanical Endstop Module V1.2 are NO, and I don't understand why I can't use them in NC mode.

I can wire only Signal and Ground, but it does not change anything.

So my solution : If you want NC, you must change the endstops...
This model should work NC mode : [www.ebay.fr]

Edited 1 time(s). Last edit at 07/12/2016 03:14AM by shofman.

Ordinary microswitches work just fine as NC. If you use the fancy ones mounted on a board with a LED, then you should connect all 3 wires to the electronics in the way the designer intended, and not worry about whether they are NO or NC.

I personally don't see the point of LEDs next to the microswitches. They are much more useful on the electronics.

Edited 2 time(s). Last edit at 07/12/2016 04:28AM 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].

This posting serves two purposes: explaing why the RADDS port of RRF will not support the Atmel SAM3X8E internal mcu temperature sensor, and to document this otherwise undocumented SAM3X8E issue.

When the SAM3X8E's internal AD15 input is enabled to sample the chips internal temp sensor, the digital output capability of SAM3X8E pin PB27 is disabled (Due pin D13). More specifically, to internally route the analog signal from the internal mcu temp sensor to the internal AD15 input, the internal digital output line for PB27 is usurped, rendering PB27 useless as a digital output. The RADDS board uses PB27 for the heater 0 output. So, to use the chip's internal mcu temp sensor means abandoning use of one of the RADDS' heater outputs.

This behavior has been confirmed by Atmel engineering in Case 00042100 - "[enabling] internal temperature sensor, PB27 becomes unusable as a digital output - ATSAM3X8E". There is no workaround to this issue. It is presently an undocumented SAM3X8E limitation.

does the RADDS board works with mega2560? just wondering, got the RADDS delivered but waiting for the DUE

Quote
deaconfrost
does the RADDS board works with mega2560? just wondering, got the RADDS delivered but waiting for the DUE

No; entirely different microprocessor and instruction set.

Just checking what the current state of RADDs + DRV8825s + RRF is right now? I see that GroupB was having some issues with it and was going to test 1.14 but hasn't given an update since.

I did not test it, in fact I did not even put on the rasp128 I got, I have to rewire in 24V set up a control box with all my electronics and im kind of busy with something else those days. I got to find the time to do that soon.

DVR8825 are not very good, if you can you should avoid them, specially if you have a delta, everything that do slow and short movement.


If the 1.14 modification is whats they did for my special 1.09r firmware , im sure its will work ok

Quote
GroupB
If the 1.14 modification is whats they did for my special 1.09r firmware , im sure its will work ok

It's not quite the same because you have to configure the step pulse timing in the config.g file, see [reprap.org]. For DRV8825 drivers, a T parameter of 2.0 should work.

---

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

GroupB - I keep seeing you reference DVR8825s. You do mean the DRV8825s right? I am planning on replacing mine eventually, but for now they're what I have. They have worked fairly well on my RAMPS setup.

dc42 - Thanks was wondering how to configure these. Does having an increased pulse effect over all RRF performance in any way?

Quote
CthulhuLabs
dc42 - Thanks was wondering how to configure these. Does having an increased pulse effect over all RRF performance in any way?

It reduces the maximum step rate a little, and hence the maximum speed.

---

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

anyone familiar with this?

MarlinKimbra4due

Quote
deaconfrost
anyone familiar with this?

MarlinKimbra4due

Yes. Become really messy. I made the optimization for DRV8825. But you can't do the same in RRF. Marlin4Due reaches 100kHz in Single-Stepping. With that you can start a step before the calculations and end the steps after them. Afaik RRF doing something like that, but the calculations are much more expensive there and you can only reach 15kHz?!? or so. To get full speed you step any stepper 2 or more time after any calculation. And with a SAM3x this is too fast for the DRV8825. The driver needs min. 2μs high signal.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase

Quote
deaconfrost
anyone familiar with this?

MarlinKimbra4due

Yes. Become really messy. I made the optimization for DRV8825. But you can't do the same in RRF. Marlin4Due reaches 100kHz in Single-Stepping. With that you can start a step before the calculations and end the steps after them. Afaik RRF doing something like that, but the calculations are much more expensive there and you can only reach 15kHz?!? or so. To get full speed you step any stepper 2 or more time after any calculation. And with a SAM3x this is too fast for the DRV8825. The driver needs min. 2μs high signal.

what do you mean by messy? the code itself or the numbers of dev on it??

Currently, RRF switches to double stepping at 15kHz on Duet and RADDS, and at 20kHz on Duet WiFi. But that is to handle the worst case on a delta, which is always moving 3 motors at the same time and the calculations involve 1 or 2 square roots per motor per step. On Cartesian printers we could continue single stepping to higher frequencies, because there are 0 or 1 square roots calculated per motor per step and the Z motor is generally moving slowly if at all. But there is very little point, because 20kHz is getting close to the chopping frequency of the stepper driver anyway.

---

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
deaconfrost

Quote
Wurstnase

Quote
deaconfrost
anyone familiar with this?

MarlinKimbra4due

Yes. Become really messy.

what do you mean by messy? the code itself or the numbers of dev on it??

I only took a look inside the stepper.cpp. This is not maintainable anymore.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase

Quote
deaconfrost

Quote
Wurstnase

Quote
deaconfrost
anyone familiar with this?

MarlinKimbra4due

Yes. Become really messy.

what do you mean by messy? the code itself or the numbers of dev on it??

I only took a look inside the stepper.cpp. This is not maintainable anymore.

thats not good

Quote
deaconfrost

Quote
wurstnase

Quote
deaconfrost
what do you mean by messy? the code itself or the numbers of dev on it??

I only took a look inside the stepper.cpp. This is not maintainable anymore.

thats not good

Maybe a bit harsh. Kimbra should be able to read the code.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase

Quote
deaconfrost

Quote
wurstnase

Quote
deaconfrost
what do you mean by messy? the code itself or the numbers of dev on it??

I only took a look inside the stepper.cpp. This is not maintainable anymore.

thats not good

Maybe a bit harsh. Kimbra should be able to read the code.

I might give it a try sometime, keeping track on how RRF progress here and I think I stick with repetier for the mean time