RADDS work now stable with RepRap Firmware

Quote
dnewman
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.

That makes complete sense Dan: I was doing this from Simpify3D that's always trying to ping it for temperature readings.
Tried again via the Arduino IDE (that's a pretty safe bet, right?), and get this after I enter M997 S0 :

ok
Heat class exited.
Move class exited.
Move class exited.
Updating main firmware

I wait a few minutes, reconnect to the machine, and I'm still on 1.13a. Tried it a second time for fun, same results.
Any other thoughts? Again, not a deal breaker, but it'd be cool to get it working.

Quote
o_lampe
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

I know its on the socket, I never talk about using any adaptor, Its just the full size socket I have dont have the cd pin switch on it, so im thinking about grounding that CD pin to ground, all the pin that go to the internal sd card are expose right next to it.

Anyone know of any negative side effect to have the CD pin ground all the time ?

Edit: After checker the socket careful there is a cd pin on it but its just not hook to the pin header, so its all good. Ill cut some trace to isolate a spare header pin and hook the cd pin there. I just hope a full size latch socket will last longer than the push type that the radds use.

Edited 1 time(s). Last edit at 09/18/2016 07:46PM by GroupB.

So is someone has sucessfully used an external SD card reader with RADDS ?
If yes, can you explain your configuration and firmware version ?

Thanks

I answer myself :
Connect these PINs :
CS1 <-> CS
MOSI
3.3V
GND
CLK <-> SCK
MISO
CD <-> GND

Done !
Thanks to GroupB.

Edited 1 time(s). Last edit at 10/17/2016 03:40PM by shofman.

I'm going to attempt hooking up a LJ12A3-4-Z/BY inductance z-probe proximity sensor. I've read every post on the subject in this thread, whew. I want to use it to do 5-point bed-leveling on my 12" aluminum plate.
What I know:
* I need to use the PMW3 pin
* Most of the gcode/macro stuff.

What I don't know:
* PMW3 is... 5v... right? The sensor says it needs 6-36v min: This means (I presume) I need to drive it off 12v (does RADDS even have surplus a 12v out? or do I need to pull that off my PSU?) and use a voltage divider on the signal to get it back down to 5v for input? I've been reading up online and it seems like doing the voltage divider on these things is a popular method.
* Or can I hook it up to the 12v and just be done with it? I'm getting all sorts of conflicting reports online. I don't want to fry anything.
* Does this work in conjunction with my Z-endswitch, or does it replace it? Meaning, when I home does it use the Z-switch, and then when I start a print it runs the bed.g leveling code? Or when I home it now ignores the z endswitch and always uses the sensor?

Any info on how to wire this thing up would be greatly appreciated, thanks!

Edited 3 time(s). Last edit at 10/20/2016 11:59PM by AK_Eric.

Hi AK_Eric,
You have to make a voltage divider board to use this kind of probe, directly to your PSU. See here : [talk.smartfri.odns.fr]

Or this kind of thing :
[www.reprap-france.com]

This probe is used only when you call G32... it's not an endstop ! (I have made the bad try...)

Edited 2 time(s). Last edit at 10/21/2016 11:00AM by shofman.

Thanks shofman, that confirms what I was thinking, good info!

After much work, I've got the bed leveling probe working. It is better than without it. But, it's still not level. I did a before\after comparison with a box the size of my build volume: The back-right corner was too high, nearly causing extrusion to stop.
Now, the back right corner looks 'correct', while the rest of my bed is now 'too low', so things aren't sticking quite right. Basically, it's like it just adjusted the whole bed slightly down, but didn't do any sort of actual transformation to it based on it not perpendicular with the nozzle using the 5 point sample space.

Here's my code if it'll help anyone notice if anything is amiss. I measured the distance of my probe from nozzle with calipers: X49, Y52 (it's behind and to the right, my bed zero is front left), and did the whole calibration sequence to determine the probe height offset from nozzle.

config.g:

; Z Probe
M558 P4 X0 Y0 Z1	                ; Set probe type + which axes should use the probe.
G31 X49 Y52 Z.5 P500           ; Set the XY probe offset from toolhead, + Z height and trigger threshold (put your own values here)

bed.g

M561                            ; Clear any bed transform, otherwise homing may be at the wrong height
G28                             ; home the printer
G30 P0 X49 Y52 Z-99999                ; Four...     - Front Left
G30 P1 X49 Y305 Z-99999               ; ...probe points... - Back Left
G30 P2 X299 Y305 Z-99999              ; ...for bed... - Back Right
G30 P3 X299 Y52 Z-99999               ; ...leveling - Front Right
G30 P4 X149 Y152 Z-99999 S5           ; 5th probe point + store the leveling - Center
G1 X0 Y0

I had to embed those offsets into al the G30 commands, or it'd try and drive the toolhead off the buildplate.

Got help in another forum: Switching the G30's in bed.g to M557's in config.g made all the difference. Properly leveling itself now.

Your original version should have worked. Can you try both versions and tell us what bed equations it reports?

The M557 commands in config.g will only be used if there is no bed.g file.

Edited 1 time(s). Last edit at 10/24/2016 02:19AM 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].

I'll give it a shot again tonight, and thinking back through my process, I bet your right : I had changed my microstepping from 1/16 to 1/32 during the time I soldered in the header to my radds board: I had forgotten to double my microsteps on the extruder when I was doing my first test, so it was only extruding half as much as it should.
I fixed the microsteps at the same time I switched from the bed.g to the M557's in config.g : Which is a bad thing for a tester to do, changing two variables at once.
Now that it's extruding the correct amount, the previous issues are gone. At the time I thought it was the bed.g/M557 switch, but I bet it's not: I think that by only extruding half the filament, it was really showing off the little bit the bed was still out of plane, even with the probe compensation. With full extrusion, it all looks good.

Anyway, I'll switch back to bed.g again and report my findings.

My findings:

G32 with M557 and no bed.g:

READ: Bed equation fits points [49.0, 52.0, 0.794] [49.0, 305.0, 0.635] [299.0, 305.0, 0.203] [299.0, 52.0, 0.552] [149.0, 152.0, 0.655]

G32 with bed.g and no M557:

READ: Bed equation fits points [49.0, 52.0, 0.798] [49.0, 305.0, 0.639] [299.0, 305.0, 0.205] [299.0, 52.0, 0.555] [149.0, 152.0, 0.657]

So only off by a few thousandths. I did it a second time with the same modes in place, and different numbers came up, so I'm guessing they're probably slightly different every time based on homing variance.

I reprinted my big calibration cube again with bed.g enabled, and now it's working fine, which confirms what I was thinking: The crazy under-extrusion was throwing thing off.

bed.g it is then. So awesome to have this functionality enabled!

Thanks for confirming this.

---

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

dc42: per the reprap wiki gcode docs, I saw that you can specify up to 5 points with G30 for Cartesian/core-xy bots, and 7 for delta: Is it possible to specify more for core-xy? And would it help/would you want to?
My 5-point setup is working fine (one in each corner, plus the center), but I've learned other firwmare can specify up to 9 (like a grid of 9 points).
Also, I'd love feedback on proper point location: Is there any logic behind where on the bed they should be placed? Currently I have the 4 corner points placed about 1.5" from all edges (on my 12" build plate). Wasn't sure if this mattered. Just trying to learn more about it.

Thanks

Bed compensation using a grid with more points is planned for release 1.17. Your corner points sound good, they just need to be somewhere near each corner.

---

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. But since I'm on RADDS, unless Dan finds it in the goodness of his heart to make that firmware port, I'll be sticking with what I got.
Beggars can't be choosers, but I'll still beg a little...
Maybe a DuetWifi will show up for Christmas....

We cant also expect dan to do it at each update too.. Maybe when they will be enough new things that we all want in the firmware or a major update we can all pitch in and give a little cash to dan to make it happen and to thanks him for the work he did on prev build.

I understand that is quite a job to port each update since dc is very active with his update.

Its sad but there no duet that can replace the radds , no duet with socket for driver. Im sure if a version with socket get made it will convert a lot of user to reprapfirmware those 8 bit that have a bunch of driver already will have a option that cost less to switch to the firmware we all like. Lot of ppl come from ramp and like the option of removable driver vs all in one board. Myself I dont feel comfortable with all in one board, if one driver crap the entire printer is down for weeks.

Imagine a duet mix with a radds , removable driver and marlin support and a little cheaper price (no driver cost) this will bring lot of ppl to reprapfirmware, they have the option of marlin if they scare or switching firmware right away but once they try reprapfirmware they will stick with it for sure its so simple to setup vs others firmwares and use the power of 32 bit (just looking at marlin config file give me a headache). With more RRF user around its will become then main choice for 32bit and will probably result in more boards sale at the end, all in one or not.

What you are forgetting (or maybe didn't know in the first place) is that on board drivers are vastly more reliable than plug-in drivers as well as being able to handle higher currents. You can't get enough PCB area to cool the chip properly on a plug-in driver, nor is there room for the capacitor needed to absorb the energy generated by the motor during deceleration. The way you have to set the motor currents using those fiddly pots instead of in software also means that many users end up with inappropriate motor currents. These are the reasons why high end boards like Duet and Smoothieboard use on-board drivers.

RAPS128 drivers are better than most plug-in drivers though because they use a modified chip that is is designed to be cooled from the top instead of the bottom, so heatsinks on the top actually help rather than hinder cooling.

---

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 that dc42: I've heard that repeatedly myself... it's slowly staring to sink in

Back when I bought my rep1 (5ish years ago now?) I had a 'botstep' fail almost immediately: This made me super paranoid of a board where you couldn't replace them. I had something similar happen on an old Rumba board. But from what I read (and you say) the chance of that happening with a board that has them built in should be far less. It's just been a hard paranoia to get over.

The external drive sockets do give some options. I would like to try mechaduino servo motors.

You can connect up to 4 external drivers to the expansion connector of the Duet, and 5 on the Duet WiFi.

---

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 David,

I get the new Raps128 named Raps128-NG.
I changed the THB6128 wit the new LV from ON Semiconductor.
We have modify the Pcb and so we have double the Chopping frequency from THB6128 (Raps128) 50 KHz to LV8728 (Raps128-NG) 100 KHz and add a larger Heatsink (14x14x14mm)
A little more less Vibration (noise) and i test it approximately10 mm/s faster Printing with same good Printresult.

Here the Datasheets:
[www.onsemi.com]
[data.stoutwind.de]

I will send you 10 pcs. for testing ..
In the new Year 2017, if tests was fine I would like to offer it for the other repraper :-)

Can you give me a Feedback for this , please?

Ps.: our PanelDue is verry cool. Thank you for this.
We can recomanded for RADDS and we have documentate it.
[doku.radds.org]

Thank you for your great Jobs, David

Angelo

---

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

Great news angelo a better driver is always welcome, unless DC will take over DAN with radds firmware you better send a kit to DAN too in case he come back with more update of RRF for the radds.

BTW since you are the creator of the RADDS are you doing something about the firmware side of thing ? if dan never make another RRF port are you not afraid your sell will go down? duet have dc42, smothie make they own, radds... nothing on that side except rely on marlin repetier and now older rrf version. The future look bad for the radds right now.

I like the duet and also the new DuetWifi.
www.duet3d.com. Looks very great.

Duet is more an All in One solution and Radds more modular depends for your printer Setup.

This time we try to adapt the Radds for the arduino Star otto at first with Repetier Firmware. Repetier Is a our first partner for the Firmware and he speak also german :-). Maybe also with Marlin and then also with reprap Firmware. We will See . Need many time for this.

On RADDS Hardware side is now All fine and nothing more to do.

Make me proud, if 32bit is now Standard for good 3d printing :-). Other repraper like it also. We are not more alone with 32 bit :-)

Thank you
Angelo

---

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

Hi Angelo,

I'm agree wiith GroupB : RRF is a great improvement for RADDS... and it's a shame that you don' want to invest for update it on RADDS.

DC42 : the all in one concept is the reason why I have not bought Duet hardware.

If I combine these 2 ways, I have made a bad choice...
As I think RRF is incredible, maybe I should go to Duet next time...

Edited 1 time(s). Last edit at 11/02/2016 03:40AM by shofman.

I love my radds and my new raps128 they perform great, Im in process of building 3-4 printer probably coreXY/delta for friends and family (After seeing my delta they want a 3d printer of they own they are hook) But for those I have a hard time to convince myself to chose radds even if I like the removable driver and modular, Mainly cause I want to stay RRF since its easy to setup are real 32 bit firmware and is getting a high user base now, marlin and repetier are not real 32 firmware, they adapt to 32 bit but are not made for 32 bit in mind yet.

At least duet fix the #1 problem I had with them ( the 1/16 driver only) so it make more sense to go with them next since DC42 is pushing the duet so much and RRF is the only firmware for them, maybe he is getting some money for each board sale and wont stop the update/support for those board... maybe im wrong and he doing this free and if this the case he want to push RRF to mainstream for 32 bit. ( and its pretty much done, since every 32 bit board question this year was between smoothie and duet, and must of them gone duet even if smoothie offer cheap china board with removable drive as an option).

I think every radds user in this thread probably agree with me saying that RRF is the future and marlin and repetier (sadly too little too late in the 32 bit firmware) are from the past and they will slowly disappear.

I don't know if Marlin & Repetier will disappear... But i'm sure that RRF is THE firmware for 32 bits hardware.


So the question is : who can continue to maintain it for RADDS for a long way ?

Angelo, if you can't find the answer, the future of RADDS will be cloudy....
If I want to stay with Repetier, I return to less expensive hardware !

To clarify a couple of points:

- I get paid a share of the profits on sales of Duet WiFi, in return for my contribution to the hardware design and the development and support of the firmware. That's the only reason I can afford to spend so much time on it. I don't get paid for supporting RRF on the Duet 0.8.5 but so far it uses the same source files (mostly) as the Duet WiFi, so I build, test and release for the Duet 0.8.5 too.

- My fork of RRF includes conditional compilation directives for RADDS in response to requests I received from Dan. I am happy for that to continue and to add further conditionals where they are needed. Some firmware releases I do don't need anything special added for RADDS, but perhaps 1 in 3 major releases does.

---

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 DC42 for your clarification.

Dan, do you have any information about the next release for RADDS ?

I'm pretty happy with the RRF version1.13 I'm running on my RADDS. I didn't miss a feature yet; it's bug free AFAIK, what else do I need??
RADDS only drawback compared to the duet is, it doesn't fit under my deltas heated bed