RADDS work now stable with RepRap Firmware

Quote
dnewman
I've uploaded a 1.13a-dc42-radds.bin file. I've temporarily disabled the core part of the new MCU temp monitoring code. Namely the lines

For the time being, avoid 1.13 for RADDS since, additionally, a change made to the core libraries has the Tool 0 heater output working as bang-bang. In investigating what's up with 1.13a and RADDS, the fact that PWM support was removed for the pin it happens to be on was made clear to me. That change dates back to early April. I'll restore it -- PWM support for that pin -- but we're still investigating the earlier issue mentioned above with 1.13a on RADDS whereby enabling the CPUs internal temp sensor and reading it appears to be having some impact on Tool 0's heater outputs. (None of these issues exist on Duet hardware which uses different pins from RADDS.)

Quote
dc42
If you have two Z motors connected in parallel, try connecting them in series instead. Connecting them in parallel is only a good idea if they are low-current high- (relatively) voltage motors.

I wonder why this hasn't been done by the board manufacturer right away? They provide two stepper connectors on Z axis and extruder3 as well, but they are routed in parallel.
Other board manufacturers made the same "mistake".
-Olaf

@Nandox7 :
With my 12v setup, I use SD6128's, and I have them dialed in about .75v, they behave well there.
I recently tried swapping to the RAPS128's, and that same voltage was super under-powered, I had to bump it up to around 1.1v to get them to move.

Quote
AK_Eric
@Nandox7 :
With my 12v setup, I use SD6128's, and I have them dialed in about .75v, they behave well there.
I recently tried swapping to the RAPS128's, and that same voltage was super under-powered, I had to bump it up to around 1.1v to get them to move.

For others reading this thread

Panucatt SD6128: current limit = 2 x Vref = 1.5A current limit @ Vref=0.75V
RAPS128: current limit = 0.9125 x Vref = 1.0A current limit @ Vref=1.1V

I just got my RADDS and Due board. I uploaded the firmware to the board through the programming port:

c:\Users\mikec\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.6.1-arduino>bossac --port=COM5 -e -w -v -U false -b RepRapFirmware-1.13a-radds.bin
Atmel SMART device 0x285e0a60 found
Erase flash
done in 0.031 seconds

Write 195708 bytes to flash (765 pages)
[==============================] 100% (765/765 pages)
done in 37.646 seconds

Verify 195708 bytes of flash
[==============================] 100% (765/765 pages)
Verify successful
done in 34.503 seconds
Set boot flash true

I have connected to the Due's Native USB port and changed the driver to the Duet.inf. On the SD card I put the sys-Prusai3 folder and changed it sys. In sys/config.g I have removed the lines for the network and the motor current. When I load pronterface, I set it to the COM port for the board and 115200 baud then hit connect. The terminal stays at "Connecting...."

I have tested the Due by flashing Blink and AnalogReadSerial to it. Both work fine. I also took the AnalogReadSerial sketch and changed the Serial object to the SerialUSB object and connected to the Native USB port. That also worked fine.

At this point I am at a loss as to what could be wrong. Any help would be greatly appreciated. I am thinking about flashing the 16u2 with the latest firmware as there doesnt seem to be a good way to tell which revision of the firmware is running on it, but I do not have a spare Arduino at the moment.

Only suggestion I have is to power up the board, wait a couple of seconds, press the reset button on the Due board, then try connecting over USB. A number of users have reported startup problems with RADDS when first powering up the board from their 12 or 24V supplies. It seems that the 3.3V regulation is slow to stabilize (relative to the ARM's speed). The issue isn't specific to the firmware; people see the same thing with Repetier. I've had no issues communicating with the board from Windows using the Arduino app. And from Mac and Linux I've never had any issues. Ditto for Octoprint on a Raspberry Pi. I don't use Prontrface.

Thanks for the quick response. I have done that multiple times. It did not work.

I just loaded Repetier firmware onto the board and that it is working fine. I did not have to hit the reset button or anything. I can get read and write to the SD Card and can read and write to the EEPROM so I am pretty sure the RADDS board is not the issue.

When I plug it into my Linux box when running RepRapFirmware I get this in dmesg:

[imgur.com]

When I connect to /dev/ttyACM0 via minicom I get:

[imgur.com]

I cannot type any commands in minicom though. Sorry for the images my Linux PC doesnt have a working NIC at the moment.

Edited 1 time(s). Last edit at 06/22/2016 12:56PM by ICanBeRobot.

Looks like minicom expects to receive CR as well as LF, which I find unusual for a Linux program. Can you configure minicom to treat LF as newline, so that it doesn't need the CR?

---

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

[Edited to indicate that this was on Windows 7 x64]

Out-of-the-box, Pronterface and Arduino both connect fine to the RADDS board with RepRapFirmware 1.13a-radds. I didn't have to make any changes to Pronterface. Arduino defaulted to 9600 baud and no line terminators so I did have to set those appropriately. See the snapshots below. Running Windows 7 x64 as a virtual machine.

Screen Shot 2016-06-22 at 11.06.14 AM by dnewman2010, on Flickr
Screen Shot 2016-06-22 at 11.03.05 AM by dnewman2010, on Flickr

Edited 1 time(s). Last edit at 06/22/2016 02:12PM by dnewman.

Having dealt with modems and other serial devices quite a bit, most actually expect \r\n which is why minicom expects that. Other firmwares I have used send both.

Anyways I did that and now I get:

[imgur.com]

and stays there. If I type random keys I eventually get this error, "Error: G-Code buffer length overflow" but I cannot actually issue Gcode commands and get any results back. As I said Pronterface and the arduino serial monitor get no output either. I suspect by the time I get either of these interfaces connected to the COM port the above text has long since past.

I do not have anything actually connected to the RADDS board as I wanted to make sure I got the firmware flashed properly before I switched my RAMPS board for it. Is that my mistake or should the board be able to handle this scenario?

Quote
ICanBeRobot
Having dealt with modems and other serial devices quite a bit, most actually expect \r\n which is why minicom expects that. Other firmwares I have used send both.

Anyways I did that and now I get:

[imgur.com]

and stays there.

That's normal. Particularly if you don't have any thermistors connected.

Quote

If I type random keys I eventually get this error, "Error: G-Code buffer length overflow" but I cannot actually issue Gcode commands and get any results back.

Type valid commands, terminated with a LF. E.g.,

M115

(CRLF termination may work as well; I've not looked much at that code myself.) And the RADDS board won't echo what you type. At any rate, it sounds like you typed enough to fill the input buffer but there was no line terminator transmitted in what you typed.

One of my coworkers really knows Linux serial consoles. He said minicom was screwed up on the Linux box so he did this:

[imgur.com]

He basically configured the TTY and then used cat to send the output to a file and put that process in the back ground. He then echoed M115\n to the tty. Then read the file.

So it is working properly. At this point the issue must be with my PC. I will mess around with that. Thank you for your help.

Bad USB port on my PC.

Yesterday I uploaded a new 1.13a RRF binary for RADDS,

RepRapFirmware-1.13a-radds.bin

Some notes about this version,

1. dc42 has dropped '-dc42' from the names of the binary files. I've followed suit. This is in keeping with the dc42 fork of the RepRapFirmware now being the de facto RepRapFirmware distribution. All of my RADDS ports have been based upon the dc42 fork.
2. As mentioned previously, to improve USB performance, the USB device is now built as solely a USB CDC device. This is a change from the 1.09 and earlier releases where the USB was built as a USB combo device and appearing identical to the normal Arduino Due Native USB port. With this change, Windows users will need to load the "Duet" device driver in order to communicate with the board over USB via the Native USB port.
3. RADDS only: The new processor temperature monitoring code is disabled for the RADDS port. It appears that there is an undocumented SAM3X8E behavior whereby enabling the special ADC channel for the internal temperature sensor, channel 15, disables Due Pin D13 (SAM3X8E PB27) as an output. (It still works as an input.) Possibly the SAM's peripheral I/O controller (PIO controller) is usurping the output line in order to enable the internal temperature sensor as an ADC input?
4. RADDS only: In the 1.09 releases, the RADDS port did bang-bang control on the extruder heater outputs as they were not on PWM-capable outputs. In 1.13a and later, hardware-based PWM is performed for RADDS heaters 0 and 1 using the timer counter functionality of those pins. This is a significant improvement as hardware-based control will be safer than either software-based PWM (e.g., Repetier, Marlin) or bang-bang control which has the same issue/concern as software-based PWM. (The issue with software-based PWM is that a processor hang can leave the heater on full if the watch-dog fails or isn't used.) HOWEVER, bang-bang style is still used for RADDS heater 2. While it too is on a timer counter pin, there's no code support at present to manage two different PWM duty-cycles on the same timer. (Heater 1 and 2 are on the same timer.) The bed heater uses PWM in 1.09 as well as 1.13. (Note RADDS heaters 0, 1, and 2 are as per the silkscreen labels on the underside of the RADDS board.)
5. As per a previous post, once 1.13a-radds is installed, future firmware updates can be done via the SD card. See this post for details.

Awesome Dan, can't wait to give it a shot.

To bad David skipped the dc42 part of the .bin file name.
How are we users suppose to know it's made for delta or CoreXY or Cartesian?

Quote
o_lampe
To bad David skipped the dc42 part of the .bin file name.
How are we users suppose to know it's made for delta or CoreXY or Cartesian?

Ah, but one of the many beauties behind RepRapFirmware is that you configure it at run-time instead of compile-time. That is, you do not conditionally build it for different hardware configurations like Marlin or Repetier. Instead it's all there and you select the machine/hardware config in sys/config.g on the SD card.

Ah,
didn't know that. Always thought David's work was delta_only because of the different math behind the XYZ towers...

Quote
o_lampe
Ah,
didn't know that. Always thought David's work was delta_only because of the different math behind the XYZ towers...

It doesn't just do Cartesian and Delta, it does CoreXY too. But not Scara or polar yet.

---

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

Guess what
The replacement Due board arrived and has the same fault then the previous: The native USB port is shown as Bossa programming port immediately.
I'm glad I found a solution for me, but I'm not sure what happens, when the 16U2 chip tries to send a software "erase signal"
I better not try to use the native as program port; ever. Or I'll add a pulldown resistor to keep the T3 transistor from shorting to GND.

I think the problem will be you wont be allow to use the native to connect to the due, send gcode and stuff more than wont be able to flash it. In my case I flash on programming port ( still need to hit erase) and communicate with native.

Your board must be a clone I guess, if its not and you pay a good amount for it ( pay mine 50$ Cad) this is unacceptable and should ask for a refund.

You should tell us where you got it so if ppl read this and want to go radds they wont buy from the same place and end up with the same problem.

As I said, it's labelled R3.
The difference between the board and the "official" schematics is the missing R99 ( 10k ) and the transistor T3 which is twisted 90° according to the eagle files.
The pictures you see in online stores often don't show what you get. My source is just a german reseller. He's not responsible for the faults on the board.

The closeup pic of the "problem zone" may help others to identify the suspicious board.

Maybe GroupB can post a pic of his board too?

I'll rewire the new Due and post pics about that, but I have to test it first, so don't hold your breath

Mine is a original due r3-E by arduino.org ( only 2 made the original , arduino.cc and arduino.org) came in a arduino carton box, you can see the picture on they website I guess, Bought it on robotshop.ca

Sorry but I dont want to remove it from the radds to take picture. but my reset button is grey and all my arduino pin connector are also grey.

You just got unlucky I guess, your the first one that come forward with this kind of problem on a clone and I bet 3/4 of the ppl who own a radds have a clone but none got your kind of problem a least you manage to fix it.

I was looking at arduino.org did you guy notice this new board [www.arduino.org]

kinda like an arduino due but with wifi but a different cpu STM32F469, I wonder if with the mod to the firmware this can work on radds replacing the due and giving us wifi..sdcard everything we need but I dont know what kind of interface the sdcard work on.. is it faster than serial one we have right now?

Edited 2 time(s). Last edit at 06/26/2016 04:42PM by GroupB.

Thanks everyone for their input.

@dc42, how would I connect them in series? The board already has the pin headers to plug the 2x Z steppers.

Quote
Nandox7
Thanks everyone for their input.

@dc42, how would I connect them in series? The board already has the pin headers to plug the 2x Z steppers.

Google "connect stepper motors in series" and you'll find lots of diagrams etc.

---

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

Nandox7 I will do my best to explain the process. A stepper has two coils in it, a A coil and a B coil. The coils have two leads which I will call + and -. So there is an A+, an A-, a B+ and a B- wire. The control board also has four pins. One for each coil wire. So lets say Pin1 is for A+, Pin2 is for A-, Pin3 is for B+, and Pin4 is for B-.

In a parallel configuration A output from the control board gets split and goes through both A coils on both steppers merges back together and then back into the control board. The B output from the controller splits as well and goes through both B coils on both steppers and back into the board. So you want the wiring to look like this (C stands for the controller pins, S1 for the first stepper wires, and S2 for the second stepper wires):

C-A+ <--------> S1-A+
          |
          \---> S2-A+
		  
          /---> S2-A-
          |
C-A- <--------> S1-A-

C-B+ <--------> S1-B+
          |
          \---> S2-B+
		  
          /---> S2-B-
          |
C-B- <--------> S1-B-

To wire a two steppers in parallel you wire Pin1 to both steppers A+, Pin2 to both steppers A-, Pin3 to both steppers B+, and Pin4 to both steppers B-. Now most control boards make this easy by putting a double header on the Z output with two header pins tied together for each actual pin output. This way you can just plug the two stepper cables side by side into the control board and it will put them into parallel for you.

In series the output from the control board does not split. The A output goes through the A coil of the first stepper and then through the A coil of the second stepper and then back to the board. The B output also does not split and goes through the first steppers B coil then through the second steppers B coil then back to the board. So you want the wiring to look like this:

C-A+ <--------> S1-A+
           /--> S1-A-
           |
           \--> S2-A+
C-A- <--------> S2-A-

C-B+ <--------> S1-B+
           /--> S1-B-
           |
           \--> S2-B+
C-B- <--------> S2-B-

Now to wire two steppers in series you need to wire Pin1 to the first steppers pin A+. Then you take the A- of that stepper and wire it to the A+ of the second stepper. Then you take the A- of the second stepper and wire it to Pin2 on the board. Then you take Pin3 on the board and wire it to B+ on the first stepper. Then you take B- on the first stepper and wire it to B+ on the second stepper. Then you take B- on the second stepper and wire it to P4. By doing it this way the signal from Pin1 goes through the first steppers A coil then through the second steppers A coil and then back to the board. Same thing with the B coil on both boards.

The way I normally handle wiring steppers in series is to make a Y cable. I get one 4 pin female dupont connector and two 4 pin make dupont connectors. The female I will refer to as F and the males as M1 and M2. So to wire it up you want something like this:

F1 <--------> M1-1
         /--> M1-2
         |
         \--> M2-1
F2 <--------> M2-2


F3 <--------> M1-3
         /--> M1-4
         |
         \--> M2-3
F4 <--------> M2-4

This way I can plug the female connector into the board and one stepper into one male connector and the other stepper into the other male connector. It makes it so you do not have to completely redo your wiring harness if you want to switch back to parallel.

I hope this makes sense and that I did not goof anything.

Quote
GroupB
I was looking at arduino.org did you guy notice this new board [www.arduino.org]

This looks similar to T3P3 and dc42's processor on the new Duet WiFi. At least it's also a Cortex M4 CPU...
It might be possible to adapt it to RADDS and RRF firmware

Edited 1 time(s). Last edit at 06/27/2016 03:03PM by o_lampe.

If its not that hard to do , it could be a great thing... onboard wifi will make the duet web interface compatible with the radds, so you get best of both.. a duet with more stepper and output and with modular stepper... the new duet is cool, a least they replace the 1/16 micro step but its still solder on the board so no changing the driver there.

Plus the new board have a camera port... maybe there enough juice to have a cam like octoprint so we can remove our raspberry board and use only one board.

off course if the sd card of the new board is the same as the due ( slow) there no real value in this cause I know there a way to hook a ESP8266 to a due, some ppl did it but I hear its slow.

Just an FYI my update to 1.13a-radds went off without a hitch: I used the "popsicle stick" method to access the reset button... and hopefully with this update I'll never have to do that again

Quote
AK_Eric
Just an FYI my update to 1.13a-radds went off without a hitch: I used the "popsicle stick" method to access the reset button... and hopefully with this update I'll never have to do that again

Great! Thanks for the followup, it is appreciated.

Don't forget to put iapradds.bin into the sys/ folder.