RADDS work now stable with RepRap Firmware

Is there a running printer with the newest RRF_dc42 native USB driver on RADDS and made a successful connection to a RasPi with Octoprint?
My impression is, that the raspian/octoprint firmware can't detect the native port.
Or it is my cheap Arduino Due board with the faulty? erase circuit.

I have that config right now (well Dan's RAADS port of the dc42 firmware) working successfully. You have to get a special cut of Octoprint for it to work with RRF though, and install a custom Octoprint plugin. I outline this here:
[www.akeric.com]

Hi everyone,

About Z probe configuration : what is the maximum voltage that can accept the PWM3 pin ?
5V or 3.3 ?
And what is the minimum required current to have a good signal ? 1mA is it enough ?

I will use a capacitive sensor Ljc18a3-h-z/bx.

Thanks

Quote
AK_Eric
I have that config right now (well Dan's RAADS port of the dc42 firmware) working successfully. You have to get a special cut of Octoprint for it to work with RRF though, and install a custom Octoprint plugin. I outline this here:
[www.akeric.com]

Eric, do you know if Octoprint will upload config files in the future, like the Duet Web interface can do ?

Quote
shofman

Quote
AK_Eric
I have that config right now (well Dan's RAADS port of the dc42 firmware) working successfully. You have to get a special cut of Octoprint for it to work with RRF though, and install a custom Octoprint plugin. I outline this here:
[www.akeric.com]

Eric, do you know if Octoprint will upload config files in the future, like the Duet Web interface can do ?

I don't know, but based on my limited understanding of all these bits and pieces, I'd doubt it: Octoprint is completely different independent software. That being said it is quite extensible with user defined plugins, so conceptually someone external to that development could author something.

Edited 1 time(s). Last edit at 07/19/2016 10:55AM by AK_Eric.

That is actually a going point I was about to join the ride and load RRF in my RADDS byt I'm using Repetier-Server on a Raspi.
It has the same "problem" it is now using the programming USB port.

Does anyone has this setup up and running?

Quote
shofman

Quote
AK_Eric
I have that config right now (well Dan's RAADS port of the dc42 firmware) working successfully. You have to get a special cut of Octoprint for it to work with RRF though, and install a custom Octoprint plugin. I outline this here:
[www.akeric.com]

Eric, do you know if Octoprint will upload config files in the future, like the Duet Web interface can do ?

I was looking into this as well. Writing a config file to the SD card shouldn't be a problem. Just use an M559 Gcode command. The problem is there is no Gcode command to read a file from the SD card that I can see. If you cannot read it there is no good way to get the current configuration short of pulling the SD card, sticking it into a computer, and reading. You can try maintaining two config files, but that sounds like a good way for them to get out of sync. It would be nice if there was an option to M559 (or some other Gcode) to read the current config.

Quote
AK_Eric
I have that config right now (well Dan's RAADS port of the dc42 firmware) working successfully. You have to get a special cut of Octoprint for it to work with RRF though, and install a custom Octoprint plugin. I outline this here:
[www.akeric.com]

Thanks for sharing Eric
If I understand it correctly, this dev-version doesn't exactly solve the native_port_problem, but uses the programming port instead? Or was it just your personal decision to use it?

Quote
o_lampe

Quote
AK_Eric
I have that config right now (well Dan's RAADS port of the dc42 firmware) working successfully. You have to get a special cut of Octoprint for it to work with RRF though, and install a custom Octoprint plugin. I outline this here:
[www.akeric.com]

Thanks for sharing Eric
If I understand it correctly, this dev-version doesn't exactly solve the native_port_problem, but uses the programming port instead? Or was it just your personal decision to use it?

I can't use the programming port at all (independent from Octoprit or otherwise), I have to use the native port for all things RRF. When I used Repetier I could use the programming port, fyi.
I blogged about the issues behind this here:
[www.akeric.com]

RRF is written to use the native port. The programming port doesn't exist on the Duet which RRF was written for, and doesn't have flow control. So even on RADDS it doesn't make sense to use it, because you get the same throughput limitations as you do with RAMPS etc. because of having to wait for an OK response after sending each gcode command.

Most good host programs have the option to use driver level flow control (sometimes called hardware flow control) so as not to have to wait for the OK response.

---

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
shofman
Hi everyone,

About Z probe configuration : what is the maximum voltage that can accept the PWM3 pin ?
5V or 3.3 ?
And what is the minimum required current to have a good signal ? 1mA is it enough ?

I will use a capacitive sensor Ljc18a3-h-z/bx.

Thanks

I'm running capacitive sensor but I don't have z probe enable as I don't use ABL at the moment so I have my sensor power straight from 12v and just signal to z endstop like it was on ramps, seems to work fine for me

however I have minor problem is with the retraction

I swap over from Ramps 1.4 Mega2650 to Radds 1.5 Arduino Due (genuine not copy)

everything seems perfect on first flash except when retracting, extruder motor skip badly, no current changes from ramps to radds, had a look in the firmware max speed was 50mm/s on extruder so I reduced it to 25mm/s and it all seems good for printing except at the start of the print wher it retract before print, which I dont know why, never did it before, and when using filament change option, it skips very bad, I ended up pulling out the filament and feed it by hand instead, other than that, it prints beautifully and more quiet, seems a little faster

also I have no way of controlling from repetier host, just from lcd alone

but I'm running latest repetier firmware not RRF

p.s. think I found the line in configuration.h to change it from 40mm/s to 30mm/s

Edited 3 time(s). Last edit at 07/30/2016 07:25PM by deaconfrost.

Repetier don't use the same configuration with the Z probe.
With RRF, we must use the PWM3 pin. The PWM3 seems 5V, so my question.... As nobody answer me, I still use 3.3v, with 1mA signal.

What steppers do you use ?
DRV8825 are very bad my RADDS.

I see, I haven't try RRF yet so I don't know about that yet

I'm using the old A4988 still as I don't really need to upgrade them yet, one thing at a time

putting on the Chimera after I get the retract sorted today, its easier to rule out any issue when doing it one at a time

Hi everyone,

DC42 has made a new version 1.15 beta 6 :
Changelog :
Add support for second SD card on SPI bus for Duet WiFi including


Is the SPI bus supported on RADDS with 1.14 or older ?
I have tried to connect a Micro SD SPI module with no luck. (the CD pin was not used)
When the module is connected, the RADDS can not read the SD card, even in the integrated slot.

Someone has ever tried ?

Quote
shofman
Hi everyone,

DC42 has made a new version 1.15 beta 6 :
Changelog :
Add support for second SD card on SPI bus for Duet WiFi including

That's a change for the Duet WiFi and unrelated to the RADDS. Of course, SD SPI works on the RADDS since that's the only way to access the SD card on the RADDS -- via the SPI bus. It has worked since day 1.

Quote

I have tried to connect a Micro SD SPI module with no luck. (the CD pin was not used)

If you add another SPI device, then you of course need to write the necessary code in the firmware to support it. Did you add code to support yet another SPI device?

Quote

When the module is connected, the RADDS can not read the SD card, even in the integrated slot.

It probably interferred with SPI bus comms. I know that when I attach the RADDS LCD module and try to use its SD card slot there's problems. Hence why the RADDS LCD module is not yet supported.

Quote
dnewman
Did you add code to support yet another SPI device?

No I have not done any modification.
It is not possible do have the 2 SD reader supported ?
For example at the boot test if a card is present on the integrated slot, if not test the external reader ?

Quote
shofman
It is not possible do have the 2 SD reader supported ?
For example at the boot test if a card is present on the integrated slot, if not test the external reader ?

Sure it's possible. Someone would need to write the code. I'm not volunteering though.

Dan

Sorry but I don't know how to do this...

Quote
shofman
Sorry but I don't know how to do this...

Understood and no need to apologize. My point was merely that it's not trivial and someone (with the necessary skill set) would need to step in and write and test the code. Adopting what was done for the Duet WiFi may or may not work: its "normal" SD card is not on SPI in the first place. It's on the high speed, SD card bus that exists on that chip but which the Arduino Due does not expose. So, for Duet electronics to support a second SD card which is on SPI means that it is really only running one SD card on SPI. For RADDS, it would be running two SD cards on SPI. That then means diving into the SD card library's SPI support to see if it will truly handle two SD cards on SPI and not just one. Duet and RADDS are currently using it to just handle one SD card on SPI, not two. So, it's breaking new ground using two SD cards on SPI. May just work, or may required code changes, or may even require debugging.

The way I added the SPI card support should make it very easy to support a second SPI SD card socket. However I am in the middle of some other changes in that area, so I advise waiting until my next commit before anyone tries to 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].

Random question: Is the concept of 'Z babystepping' possible in RRF? I recently encountered a bed level issue where it would have been really nice to manually tune the z-height during the first layer. Or is something similar available via a custom macro?
thanks!

Edited 2 time(s). Last edit at 09/08/2016 05:39PM by AK_Eric.

Quote
AK_Eric
Random question: Is the concept of 'Z babystepping' possible in RRF? I recently encountered a bed level issue where it would have been really nice to manually tune the z-height during the first layer. Or is something similar available via a custom macro?
thanks!

It's not implemented yet but it is on the wish list. Meanwhile, if you always use the same first layer height, you can use a macro. For example, if you use 0.2mm first layer height, then to increase the Z height by 0.05mm you can use this:

G1 Z0.25
G92 Z0.2

---

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

Thanks for the info DC42!

Next question: The relay I had controlling my 12v MakerFarm 12"x12" bed just had a meltdown (literally).
After discussion \ research, I just ordered one of these:
[www.ebay.com]
A nice little board with mosfet, heatsink, plus, PID control. I've been using bang\bang historically. PID on the bed sounds nice.

Any suggestions as a starting point for how I should configure my config.g to take advantage of this? Currently, the only configuration for my bed is this line:
M305 P0 T100000 R4700
I presume I need to do something via M301 to get the bed PID working? Currently I'm not doing anything with it, presumably just using the defaults.

Any thoughts appreciated.

It depends on which firmware version you use. Is 1.15c available for RADDS yet? If so then you can auto tune it, see [duet3d.com] for details. If not then you use M301 to specify the PID parameters manually.

---

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

Pretty sure I'm on that version, but if not I'll upgrade.
Thanks for the links, that sounds great.

Looks like I'm on 1.13a... and Dan has a version for 1.4 here:
[github.com]

Maye I'm SOL for 1.15 since I'm on RADDS, unless Dan finds a buch of spare time laying around. I'll give the manual method a shot!

Edited 1 time(s). Last edit at 09/17/2016 12:27AM by AK_Eric.

Today I thought I try upgrading from 1.13a to 1.14. I followed Dan's steps here:
[forums.reprap.org]

Copied the below RepRapFirmware-1.14-radds.bin file to the sd cards /sys folder, renamed it RepRapFirmware.bin :
[github.com]

I placed the iapradds.bin file in the /sys folder as well:
[github.com]

After insetting the card I turned on the power supply, plugged in the USB, connected to it, and entered M997 S0
I got this::

SENT: M997 S0
SENT: M105
READ: Heat class exited.
READ: Move class exited.
READ: Move class exited.
READ: Updating main firmware
SENT: M105
WARNING: Device unplugged while connected to port

I waited a minute or so, reconnected, issued a M115, and it said I was still on 1.13a. Both the above files were still present in the /sys folder, and based on the instructions I would have expected them to go missing if the install was successful? or at least the .bin file?

Any thoughts as to what isn't working right here? I tried it a second time for good measure with the same results. It's not like I need to be on 1.14 right now, but now I'm perplexed as to why the upgrade steps aren't working.
thanks!

Edited 1 time(s). Last edit at 09/17/2016 12:16AM by AK_Eric.

That you got the "Updating main firmware" message means that you had files with the correct names in sys/.

However, I've always done this while talking directly to the board over USB without some program which will periodically send commands at the same time to the board. That is, you're using some control software which is also sending other commands to the board at the same time (e.g., trying to read the temp with M105 commands). While I don't think that should cause a problem, I cannot guarantee that. You might try again after first turning off temp readings and other periodic commands from whatever the tool it is you are using.

Anyone have problem with they onboard sd card socket ?

Mine starting to get me mad, when I put a new file on the sd card and reinsert it it always take a good 15 minute of remove and insert it before it finally detect the files. Im thinking about using a full size external sd card reader but the one I got do not have a CD pin on it, will it work if I just hook the CD pin of the radds to ground ? do reprapfirmware use the CD pin will it work without it ?

Im not impress with the socket so far, I have maybe less than 50 reinsert of the card on it! the first 3 month I did not even remove the card I was streaming my file in the radds.

AFAIK, the CD pin is not on the full-SD card adapter, but in the housing where it normally would be inserted.
Same for the micro-SD-Cards. The CD pin is a blank metal latch that got pressed against the grounded housing.
If your RADDS has a flaky SD-socket use a jumper wire to gnd the CD-pin.

Do at your own risk, maybe you better use contact spray
-Olaf