Welcome! Log In Create A New Profile

Advanced

RADDS work now stable with RepRap Firmware

Posted by angelo 
Re: RADDS work now stable with RepRap Firmware
March 02, 2017 12:21AM
The code to support the 2nd SD card slot is present in the RADDS build, but I don't know if anyone has tested it.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: RADDS work now stable with RepRap Firmware
March 02, 2017 03:48PM
You dont really need a second SD card slot, the pinout are there to just hook another one to replace the inboard one, Off course you dont put a card in both at the same time.

I did it on my radds cause the sd slot have problem even after less than 100 remove/insert, I hook a full sd card slot to the pinout of the onboard one and its working fine.So my guess is you hook your panel due sd card line to those pinout and that will replace the onboard. Unless I miss something there no need to have 2 functional sd card at the same time.
Re: RADDS work now stable with RepRap Firmware
March 03, 2017 11:43AM
Hi everyone,
Sorry for the delay....

The upgrade to 1.18A2 worked perfectly with M997 S0 from octoprint.

Big big thanks to DC42 to support RADDS like you do !
Re: RADDS work now stable with RepRap Firmware
March 10, 2017 09:49PM
I am not sure if I should report this as a bug to octoprint, here, to the github or it might be my sore brain – in octoprint I cannot see any SD card contents. I tried to switch to different M555 modes and toggle "automatic firmware detection" feature of octoprint. I can see the files if I manually send M20 command.
Also, octoprint freaks out if M555 is in native mode (no ok sent?).
Re: RADDS work now stable with RepRap Firmware
March 10, 2017 11:39PM
There is a setup in the folder section to specify which devices are shown.
I tried to send files to RADDS-SD-Card but that is painfully slow, so I only use Octopi's SD-card now.



Edited 1 time(s). Last edit at 03/11/2017 12:01AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
March 11, 2017 12:59PM
I dont know if its made it the the main fork of octoprint but I use another one that can detect the radds sd card file, someone I dont remember post a link in this thread about that couple month ago, the main fork was not detecting the content of the radds sd card so someone did a modification for us radds user.

Since then I dont upload ( took too much time with streaming anyway) or store thing in octoprint sdcard but only in radds sd card, less risk of a failure and complex print with circle are better directly from the radds card.

PS: if you want to do that, hook yourself a full size sd card reader because the radds one will fail on you.
Re: RADDS work now stable with RepRap Firmware
March 11, 2017 01:41PM
I have snapped many microSD cards in RADDS's poor quality slot (not helped by my fiddling blind under delta) so have now plugged in one of those cheap extender ribbon cables. I designed a simple holder to attach it to the frame:
[www.thingiverse.com]
Re: RADDS work now stable with RepRap Firmware
March 11, 2017 10:41PM
Has anyone found another pin that works as z-probe input than PWM3? I grilled mine yesterday and it seems both other pins RRF can use with Duet boards are occupied on RADDS.

Can I use Z-min endstop as probe input? How do I tell RRF to use this pin? ( M558 P? )
Re: RADDS work now stable with RepRap Firmware
March 11, 2017 11:48PM
Quote
o_lampe
Has anyone found another pin that works as z-probe input than PWM3? I grilled mine yesterday and it seems both other pins RRF can use with Duet boards are occupied on RADDS.

Can I use Z-min endstop as probe input? How do I tell RRF to use this pin? ( M558 P? )

If you cant find a replacement for that pin or compile a new firmware with a new pin. At least you dont have to change the whole board but just a due, it suck but your mistake did not cost you a complete board. I got an original due but I saw clone due a very low price. Burning a pin on a all in one board must suck, replacing a MCU is a hard thing to do I did it one time by hand in one of my R/C TX and its a pita. With the low price of due clone you don't have to do that but it still an option.
Re: RADDS work now stable with RepRap Firmware
March 12, 2017 03:48AM
The pin assignments for RRF on RADDS can be seen here [github.com]. For RADDS these are Arduino Due pin numbers.

HTH David


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: RADDS work now stable with RepRap Firmware
March 13, 2017 01:11AM
Thanks to both of you,
it seems, I have to compile RRF myself for the first time. Wish me luck winking smiley
Re: RADDS work now stable with RepRap Firmware
March 13, 2017 02:10AM
Quote
GroupB
You dont really need a second SD card slot, the pinout are there to just hook another one to replace the inboard one, Off course you dont put a card in both at the same time.

I did it on my radds cause the sd slot have problem even after less than 100 remove/insert, I hook a full sd card slot to the pinout of the onboard one and its working fine.So my guess is you hook your panel due sd card line to those pinout and that will replace the onboard. Unless I miss something there no need to have 2 functional sd card at the same time.

Like GroupB, I use an external full SD Card Slot (not a mini one). I have already posted the pin configuration.
It works very well for me.
I don't use anymore the onboard reader, because I can't access it with my Kossel XL.
Re: RADDS work now stable with RepRap Firmware
March 13, 2017 04:34AM
edit2: Stupid me:
During the initial probe-tests; I had set the T parameter for travel speed to 500.
M558 P4 X0 Y0 Z1 I1 R1 H8 F300 T500
Later, when I got more confident, I wanted to change it back to 5000, but instead changed the P parameter of this line: G31 X0 Y80 Z0 P5000

Of course the probe doesn't change then
eye rolling smiley




Quote
o_lampe
Has anyone found another pin that works as z-probe input than PWM3? I grilled mine yesterday and it seems both other pins RRF can use with Duet boards are occupied on RADDS.

Can I use Z-min endstop as probe input? How do I tell RRF to use this pin? ( M558 P? )

...and the journey continues:

I've flashed a virgin Due board with RRF1.17d and it does the same: ignoring the probe input.
I beeped the traces of RADDS and the signal passes through to the Due board.
I can read 3V on the PWM3 pin, which means the cpu-pin is in " input_pullup" mode.

I went through my config file and undid all the changes I made according grid size.
I even checked the config_override file and commented out the three G31 lines. But the probe doesn't do anything.

; Z probe parameters
;G31 T1 P400 X0.0 Y0.0 Z0.70
;G31 T3 P400 X0.0 Y0.0 Z0.70
;G31 T4 P400 X0.0 Y0.0 Z0.00

I played around with the I and R parameters expecting to see any change, but nothing.
; Z probe

I don't get it, why did bed probing work 3 times, but not anymore ( with no obvious hardware fault )

Did I mess up the RADDS Eeprom? How can I reset that? Is it the classic "M502 & M500 " way?

Edited 3 time(s). Last edit at 03/13/2017 04:53AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
March 13, 2017 05:20AM
Please confirm that you are using the correct pin. M558 P4 should use the "E0 endstop" input which is Arduino Due pin 39. M558 P1 (analog probe) or M558 P5 (digital probe) should use Arduino Due pin 5.

What type of Z probe are you using?

M500 writes to config-override.g on the SD card, not eeprom. The config-override.g file is only used if you use the M501 command to invoke it, usually at or near the end of config.g.

Edited 1 time(s). Last edit at 03/13/2017 05:23AM by dc42.

Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: RADDS work now stable with RepRap Firmware
March 13, 2017 05:21AM
I've just released the RADDS build of RRF 1.18beta2 on github.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: RADDS work now stable with RepRap Firmware
March 16, 2017 03:26AM
I'd used Ramps/Marlin to engrave and laser cut before and wanted to try this on RADDS/RRF1.17d too.
But the fan output ( with a resistor voltage divider to TTL level ) doesn't seem to offer a clean on/off signal.

So I searched for unused I/O pins I could control with M42 Pnn S0..1 to trigger the laser-driver.

The Wiki offers a list of pins, but I could only manage to use two of them ( with wrong pin assignments according to the RADDS doku )

Then there are a few pins, I tried to trigger, but got a warning message on Octoprints terminal, like" pin can't be used for writing"
Also there were a few pins, I could write to, but couldn't find a pin on RADDS, that showed any change.

Here's a list with the results so far:



I'm not complaining, just want to publish my findings for others.
VDX
Re: RADDS work now stable with RepRap Firmware
March 16, 2017 03:47AM
... for a discussion in another forum I've made an image, comparing a basic RADDS+RAPS128 board (in the bottom-left corner) with our "RADDS-compatible" industry-grade controller:




It does essentially the same (can even run with RAPS128 instead of the big stepper-drivers) ... only with the difference of 24 Volt level I/O's with optocouplers and 44 Volts for the stepper drivers winking smiley


Viktor
Re: RADDS work now stable with RepRap Firmware
March 16, 2017 04:55AM
My engraving results with M42 are the same as with M106. The laser doesn't seem to switch off reliably...

With lots of fantasy you can see where the dots should be ( compare with CNC-view below ), but there are several lines where the pin should be off.



...and a sample of the Gcode:

; Generated with:
; "Raster 2 Laser Gcode generator"
; by 305 Engineering

G21; Set units to millimeters
G90; Use absolute coordinates
G92 ; Coordinate Offset

M42 P66 S0		;init D66 as output

G00 X134.3 Y13.7 F2000
M42 P66 S1
G01 X134.0 Y13.7 F2000
M42 P66 S0
G00 X128.0 Y13.7 F2000
M42 P66 S1
G01 X127.0 Y13.7 F2000
M42 P66 S0


Re: RADDS work now stable with RepRap Firmware
March 16, 2017 06:05AM
Just to report that 1.18beta2 is working great for me. The new PID autotune seems to have fixed the temperature instability problems I experienced with the previous autotune. Thanks to dc42 for the ongoing RADDS builds. Every RADDS user kept within the RRF ecosystem is, I believe, a potential future Duet user.
VDX
Re: RADDS work now stable with RepRap Firmware
March 16, 2017 07:58AM
@o_lampe - AFAIK this M42-switching of I/O-pins isn't accurate synchronized with the XY-moves -- I'm using the Extruder CLK-pin to generate the pulses for my laser-modules ... and an Arduino integrated into the laser-module to set the pulse-lengths according to the set power ... mostly something between 5 microseconds for engraving and up to 300 microseconds (with then slower moves too) for cutting.

The ArduinoDue pulses are normally 500 nanoseconds long, so not working with common laserdiode drivers ...


Viktor
Re: RADDS work now stable with RepRap Firmware
March 16, 2017 09:20AM
Quote
VDX
...
The ArduinoDue pulses are normally 500 nanoseconds long, so not working with common laserdiode drivers ...

I'm using the Extruder CLK-pin to generate the pulses for my laser-modules

Currently I try to use a simple ON/OFF signal and it's not the ON time being to short, but the OFF doesn't work. Marlins has it's roots in grbl, that seems to work better with such I/O stuff.

#extruder -stp pin
I read that before and have a few questions. I'd like to discuss this in the laser forum, because it's no longer Radds specific but of general interest.

@DC42
Using PWM signal to control laser power is pretty dangerous with RRF: Sending M42 Pxx S1 means full power to the LED, but I thought 1 would be the smallest PWM duty cycle.

To avoid this, it would be better to use S0.0-1.0 for fractions of 100% and S0..255 without decimal point for oldscool PWM.

Edited 2 time(s). Last edit at 03/16/2017 10:00AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
March 16, 2017 01:04PM
Quote
VDX
@o_lampe - AFAIK this M42-switching of I/O-pins isn't accurate synchronized with the XY-moves

That's correct - which is why we recommend using M571 to control the FAN0 output according to extruder commands. I may improve the synchronisation of M42 with movement in the 1.18 firmware release.

btw RRF 1.18beta3 for RADDS is now on github.

Edited 1 time(s). Last edit at 03/16/2017 01:04PM by dc42.

Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: RADDS work now stable with RepRap Firmware
March 16, 2017 11:57PM
Thanks David,
I'll give M571 a try. The frequency specified by the F parameter extends the ON time too? ( like 50/50 ) Or is it still 500nanosec ON?
Anyway, my driver had no problem switching on so far...
Re: RADDS work now stable with RepRap Firmware
March 17, 2017 01:47AM
Here's my best attempt to use M571 to control a laser. But the diode only flashed once at the beginning of the first G01 track.
I expected pin 66 would switch on whenever there is a Exx in the line.

;
G21; Set units to millimeters
G90; Use absolute coordinates
G92; Coordinate Offset

M302 P1			; allow cold extrusions
M567 P0 E1.0:0.0		; set mixing ratio (for multiple hotend only)
M568 P0 S1			; mixing on
T0				; select tool 0
M42 P66 S0			; set P66 as output
M571 P66 S1.0 F500	; trigger Pin 66 when extrusion happens

M92 E10:10			; set extrusion-steps/mm

G00 X134.3 Y13.7 F2000
G01 X134.0 Y13.7 E10 F2000
G00 X128.0 Y13.7 F2000
G01 X127.0 Y13.7 E10 F2000
G00 X118.9 Y13.7 F2000
VDX
Re: RADDS work now stable with RepRap Firmware
March 17, 2017 02:12AM
... have you set the Extruder to "relative"? - if not, it will only extrude, if you give it a greater/different value than for the previous move.

Then you should "accumulate" the E-steps -- e.g. "G1... E10 ...", then for the next 10 pulses: "G1 ... E20 ...", and so on.


Viktor
Re: RADDS work now stable with RepRap Firmware
March 17, 2017 02:22AM
Great, I knew I forgot something. grinning smiley
Re: RADDS work now stable with RepRap Firmware
March 17, 2017 04:33AM
It seems there is a minimum extrusion threshold to trigger M571?
I wanted to use the least amount of E-steps as possible, so even the shortest line wouldn't slowdown the printer.
But I had to raise e-steps until I noticed a little stuttering before the laser finally turned on.

Here are the added lines to make RRF work as laser engraver. ( Mixing ratio lines are not necessary for everyone )

M83 				; Set extrusion to relative
M208 E15000:15000	; raise max. E speed
M302 P1			; allow cold extrusions
M567 P0 E1.0:0.0		; set mixing ratio (for multiple hotend only)
M568 P0 S1			; mixing on
T0				; select tool 0
M42 P66 S0			; set P66 as output
M571 P66 S1.0 F500	; trigger Pin 66 when extrusion happens

M92 E1000:1000			; set extrusion-steps/mm

G00 X134.3 Y13.7 F2000
G01 X134.0 Y13.7 E0.001 F2000
G00 X128.0 Y13.7 F2000
G01 X127.0 Y13.7 E0.001 F2000
G00 X118.9 Y13.7 F2000
G01 X118.9 Y13.7 E0.001 F2000

Edited 2 time(s). Last edit at 03/17/2017 04:38AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
March 18, 2017 04:19AM
M571 doesn't seem to work with S1..255 parameters. I tried to engrave a 256 grayscale image, but everything above S1 seems to be 100%.

@dc42
do you plan to extend the functionality of M571 like M42 is already working?

THX
Olaf
Re: RADDS work now stable with RepRap Firmware
March 19, 2017 03:32PM
Quote
o_lampe
@dc42
do you plan to extend the functionality of M571 like M42 is already working?

THX
Olaf

lt already does, except that the I parameter is not implemented, see [duet3d.com].

The S parameter should work provided you have chosen a PWM-capable pin.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: RADDS work now stable with RepRap Firmware
March 19, 2017 11:56PM
I made a test and sent these lines via terminal:

M571 P66 S127 F500
G1 F100 E100

I would've expected to see a lower voltage on the output pin, but it shows 3.3V. ( Don't have a 'scope so a multimeter should do )
I did the same with M42 P66 S127 and it worked.

1. Maybe F500 was to low?
2. What is the reasonable pwm frequency range anyway?
3. The wiki doesn't say anything about S1..255 functionality

Quote
duet3d-wiki
The S parameter sets the value of the PWM to the output. 0.0 is off; 1.0 is fully on.

I was busy over the weekend and tried to rewrite the png_2_gcode translator and the output is scaled from 0.0 to 1.0 now:

...
M571 P66  S0.176470588235
G1 X186.1 Y28.4 E0.01 F800
M571 P66  S0.235294117647
G1 X186.2 Y28.4 E0.01 F800
M571 P66  S0.270588235294
G1 X186.3 Y28.4 E0.01 F800
M571 P66  S0.286274509804
G1 X186.4 Y28.4 E0.01 F800
M571 P66  S0.298039215686
G1 X186.5 Y28.4 E0.01 F800
M571 P66  S0.305882352941
G1 X186.6 Y28.4 E0.01 F800
M571 P66  S0.309803921569
G1 X186.7 Y28.4 E0.01 F800
M571 P66  S0.305882352941
G1 X186.8 Y28.4 E0.01 F800
...

It does some grayscaling now, but I'm not sure, how many digits are useful and don't know how to truncate it.

4. Do I have to set the F value in every M571-line?
It is set to F5000 once in the beginning of the file.

Edited 1 time(s). Last edit at 03/19/2017 11:59PM by o_lampe.
Sorry, only registered users may post in this forum.

Click here to login