RADDS work now stable with RepRap Firmware

PWM on the Duet can always be expressed as either 0 to 1 or 0 to 255. A value greater than 1 is assumed to use the 0 to 255 scale.

The reasonable range for F is about 1 to 50000. You only need to set F once.

The Pins_radds.h file has the following table for special pin numbers:

// Definition of which pins we allow to be controlled using M42
// Spare pins on the Arduino Due are
//
//  D5 / TIOA6  / C.25
//  D6 / PWML7  / C.24
// ### Removed: now E0_AXIS endstop D39 / PWMH2  / C.7
// D58 / AD3    / A.6
// D59 / AD2    / A.4
// D66 / DAC0   / B.15
// D67 / DAC1   / B.16
// D68 / CANRX0 / A.1
// D69 / CANTX0 / A.0
// D70 / SDA1   / A.17
// D71 / SCL1   / A.18
// D72 / RX LED / C.30
// D73 / TX LED / A.21

// M42 and M208 commands now use logical pin numbers, not firmware pin numbers.
// This is the mapping from logical pins 60+ to firmware pin numbers
const Pin SpecialPinMap[] =
{
	5, 6, 58, 59,
	66, 67, 68, 69, 70, 71, 73, 73
};

// This next definition defines the highest one.
const int HighestLogicalPin = 60 + ARRAY_SIZE(SpecialPinMap) - 1;		// highest logical pin number on this electronics

Logical pins 60 to 71 correspond to the Arduino Due pin numbers in that table. So if you want to use Arduino Due pin 66, that would be logical pin 64.

HTH David

Edited 2 time(s). Last edit at 03/20/2017 04:09AM 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].

... could be, you have to set the F-value only if you change the speed ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I found a bug in my rewritten png_2_gcode translator and eagerly started a test-engraving.
I also made the same print with Rumba/Marlin on the same printer/laser etc...

The left is Rumba/Marlin, the right is RADDS. An preview pic in the middle to compare the result.



RRF is able to change PWM on the fly, but there is a certain delay in it. Marlin OTOH is spot on ( using M106 Sxxx)

All I did, was changing this python line in the png_2_gcode program.

str(255 - matrice_BN[y][x+1]) ; original greyscale 1..255

str((255.0 - float(matrice_BN[y][x+1]))/255.0); scaled down to 0.0..1.0

To be fair, I also made some very nice b/w engravings with RADDS/ M571, but in that case there is no redefinition of the S-parameter in every other line.

... looks good!

What was the engravin time with the triangle and the Marsupilami?

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

What actually happens with RRF is that M106 fan speed changes are executed immediately instead of being delayed to sync with moves in the move queue. Chrishamm has already done a fix for this in his fork, but he doesn't have a RADDS build. I'll look at including his code in the 1.18 release.

---

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

That's really good news David!
I might end up with a Duet board anyways, because RADDS SD-card is the bottleneck in grayscale printing.

It took ~ 60min to print the 140x250mm marsupilami at 2500mm/min, but the laser was on 50%.
Greyscale is even slower. The Escher triangle is 140x140mm and speed was 1200mm/min. A full size 140x250mm grayscale image can have 100MB and more.

... a year ago I was starting a project for a "drum-engraver" for high resolution printing plates/sheets - they were up to DIN-A4 or -A3 and with dot-resolutions of 1000dpi or 6000dpi and the printing time should be something between 30min to an hour ... now calculate the file sizes and "pixel-speed" to get this running! ... my smaller test images were around 2GB big

With my first test without speed optimzing and an ArduinoDue as controller and fast microSD for the data I've got 60kHz pixel-clock ... was optimizing for up to 100kHz, but then the customer delayed the project

Have the prototype components for DIN-A4 at home and a bigger variant for -A3 or bigger in the company ... so could be, I'll reactivate this on my own for another application

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I know the DUET boards have a significant higher USB-speed than Due. I hope that this is also true for SD-Card?

Last year we had a discussion about Gcode compression. That would make perfect sense for such use cases. At least, when the CPU has some spare time to translate the compressed Gcode?
Imagine you want to build a galvo-based laser engraver ( which is how much faster??? ) and your print speed is limited by SD-Card serial Baud rate

After thinking about reducing gcode, I came to a solution that will help the planner to concentrate on the essential things:
It reduces file size by ~30% and hopefully raises the possible engraving speed.

;
G21; Set units to millimeters
G90; Use absolute coordinates
G92; Coordinate Offset
G0 F3000
G0 X11.7 Y6.0
M106 S3
G1 F1500
G1 X11.8
M106 S16
G1 X11.9
M106 S29
G1 X12.0
M106 S43
G1 X12.1
M106 S56
G1 X12.2
M106 S66
G1 X12.3
M106 S53
G1 X12.4
M106 S39
G1 X12.5
M106 S26
G1 X12.6
M106 S13
G1 X12.7
M107
G0 F3000
G0 X12.7 Y6.1
M106 S33
G1 F1500
G1 X12.6
M106 S67
G1 X12.5

... my Due-based "high-speed" driver uses compressed "pixel-map" files on SD - so one Byte is either 8 BW-pixels in a line (with fixed spacing), or a 0-255 value for a single pixel in analogue mode.

My galvoscanners have fast moves with up to 50m/s and 16bit-resolution for the XY(Z) coordinates, so a working area of max. 65536x65536 pixels ...

Edited 1 time(s). Last edit at 03/21/2017 03:42PM by VDX.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
o_lampe
I know the DUET boards have a significant higher USB-speed than Due. I hope that this is also true for SD-Card?

The Duets use a 4 bit interface to the SD card running at 20Mbytes/sec. Every other controller electronics I know of that is on the market uses SPI, usually running at 0.5 to 1.0 Mbytes/sec. So yes.

---

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
dc42
So yes.

That's a mild understatement David
It's more like YESS

Quote
VDX
... my Due-based "high-speed" driver uses compressed "pixel-map" files on SD - so one Byte is either 8 BW-pixels in a line (with fixed spacing), or a 0-255 value for a single pixel in analogue mode.

So you set up the engraver to scan over a given area and fire the incoming bits in sync. That's way faster than gcode.
But with grayscale you'd still hit a wall. Because every pixel is a byte, even if there are huge uni-colored areas.

I'm wondering if you could add a byte that expresses the number of equal pixels in a row?
So the data stream would be grayscale/length/grayscale/length.... For most pictures this would save some bytes.

... I was testing with different methodes and "pixel-compressing" - the 60kHz pixel-clock rates were with analogue 1-Byte reading and not optimized for faster DAC output for the laser power ... BW-raw-encoding will be much, much more than 8x faster, because there's no need to read or set analoque ports

This was built and programmed "from scratch" as test/mockup, so I've made the simplest possible system with maybe 50 lines programm code on the Due and preparing the image data with a plugin in Gimp ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

... another idea for a "simple raw" greyscale output with BW/pixel data only for greyscale images -- if you configure you system for super high pixel-resolution per line, so that the 8 pixels in a byte will represent a line in the image of let's say 0,05mm and with 0,1mm line spacing, then there's no need for analogue setting the laser power - the "analogue" byte value of a pixel will simply be pulsed in a hex "raster", and by overlapping the pulses (8x burning a spot of 0,1mm diameter over a line of 0,05mm length will burn a single hole with 0,15x0,1mm size) it will result in "averaged energy density" with the more darking/burning for higher byte vaues

But you have to convert the binary values to a corresponding bit-raster -- e.g. a Byte value 3 will pulse 2x, while 4 will pulse only 1x! - so set a table with bit values like:
1% = "00010000"
(10)% = "01000100"
(20)% = "01010010"
(30)%= "01010101"
....
100% = "11111111"

(the steps have to be calculated and distributed for homogene representation)

Then you have to convert the greyscale values to your table ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I tried to use the DAC0 ( D66 ) pin to trigger the laser driver. I thought a analog output would be the same as a PWM pin. Maybe I was wrong and the delay resulted on choosing the wrong pin?

David mentioned D66 is logical pin 64, but according to the official Due pinout diagram I can't see that?
Also I wasn't able to write to any of the PWM pins, although they weren't "occupied" by any other function.
I'll give the Fan1 output a chance...



Edited 1 time(s). Last edit at 03/22/2017 09:57AM by o_lampe.

Quote
VDX
... another idea for a "simple raw" greyscale output with BW/pixel data only for greyscale images -- if you configure you system for super high pixel-resolution per line, so that the 8 pixels in a byte will represent a line in the image of let's say 0,05mm and with 0,1mm line spacing, then there's no need for analogue setting the laser power - the "analogue" byte value of a pixel will simply be pulsed in a hex "raster", and by overlapping the pulses (8x burning a spot of 0,1mm diameter over a line of 0,05mm length will burn a single hole with 0,15x0,1mm size) it will result in "averaged energy density" with the more darking/burning for higher byte vaues

But you have to convert the binary values to a corresponding bit-raster -- e.g. a Byte value 3 will pulse 2x, while 4 will pulse only 1x! - so set a table with bit values like:
1% = "00010000"
(10)% = "01000100"
(20)% = "01010010"
(30)%= "01010101"
....
100% = "11111111"

(the steps have to be calculated and distributed for homogene representation)

Then you have to convert the greyscale values to your table ...

Why create a new bit pattern? Just take the hex value of the byte and count the pulses. A binary 3 then are three pulses and a binary 4 are 4 pulses. With such a short line of 0.15mm it looks like a single spot, but with different degrees of brown.

... it's the speed, what's critical here - any change in speed or syncing will be seen as "Moiré" pattern in the image, so all steps, pulses ant timing has to be identical.

With binary to hex conversion you'll get different reaction times with different values, so a "pure binary" approach with identical timing per bit is to prefer.

Even with the ArduinoDue I'm limited in max. pixel clock and syncing - 2MHz isn't this fast, when in need for super high accuracy at reasonable speeds

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

... and for the DAC0 - in my actual controller buildup for a customer machine I'm using the pin D66 for setting the analogue value 0 - 3.3V as 1 - 100% and the D25 to D31 as digital outputs or pulse-source without problems.

Look into the "pins_RADDS.h", if the not accessible pins are set for the extruder pins or such.

For moving-synchrone pulsing I'm wiring one of the extruder step pins to the laser pulse input -- with my setups I'm using E1 and E2 for the tools (dispenser or laser), and E0 to deactivate the output when using the camera for teaching and simulating geometries ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
o_lampe
I found a bug in my rewritten png_2_gcode translator and eagerly started a test-engraving.
I also made the same print with Rumba/Marlin on the same printer/laser etc...

The left is Rumba/Marlin, the right is RADDS. An preview pic in the middle to compare the result.

[attachment 92198 triangle_comparison.jpg]

RRF is able to change PWM on the fly, but there is a certain delay in it. Marlin OTOH is spot on ( using M106 Sxxx)

All I did, was changing this python line in the png_2_gcode program.

str(255 - matrice_BN[y][x+1]) ; original greyscale 1..255

str((255.0 - float(matrice_BN[y][x+1]))/255.0); scaled down to 0.0..1.0

Please try with firmware 1.18RC1. That version includes the code to sync M106, M42 etc. with the move queue.

---

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
dc42

Quote
o_lampe
I found a bug in my rewritten png_2_gcode translator and eagerly started a test-engraving.
I also made the same print with Rumba/Marlin on the same printer/laser etc...

The left is Rumba/Marlin, the right is RADDS. An preview pic in the middle to compare the result.

[attachment 92198 triangle_comparison.jpg]

RRF is able to change PWM on the fly, but there is a certain delay in it. Marlin OTOH is spot on ( using M106 Sxxx)

All I did, was changing this python line in the png_2_gcode program.

str(255 - matrice_BN[y][x+1]) ; original greyscale 1..255

str((255.0 - float(matrice_BN[y][x+1]))/255.0); scaled down to 0.0..1.0

Please try with firmware 1.18RC1. That version includes the code to sync M106, M42 etc. with the move queue.

Will do as soon as my new laser diode arrives. I have taken the chance to disassemble the CoreXY and do some design changes as well.

Thanks David for supporting the RADDS community

Edited 1 time(s). Last edit at 03/29/2017 03:31AM by o_lampe.

HI,

I decided to try reprap firmware on the RADDS as I am using it on the Duet wifi annd soon to come Duet ethernet.

I have installed RepRapFirmware-RADDS-1.18.1.bin on the RADDS and am running a test. I am using RAPS128 drivers and steps are correct for movement and extrusion. The problem is is really jerky/stuttering while printing the skirt outline and not so smooth on arcs. I probably need to tweak the jerk settings. The surface finish is terrible with little zits left all over from the jerking. I'm printing using USB and repetier host but have also tried direct from SD with the same result.

My config is below. Anything jump out at anyone as obviously wrong?

thanks,
Brendin

M111 S0                             ; Debug off

M555 P2                             ; Set output to look like Marlin

; Movement section
M569 P0 S1 R1                         ; Drive 0 goes forwards (change to S0 to reverse it)
M569 P1 S1 R1                         ; Drive 1 goes forwards ; Inverted enable
M569 P2 S1 R1                         ; Drive 2 goes forwards ; Inverted enable
M569 P3 S1 R1                         ; Drive 3 goes forwards ; Inverted enable
M574 X1 Y1 Z1 S0					; set endstop configuration (X and Y endstops only, at low end, active high)
M201 X800 Y800 Z15 E1000            ; Accelerations (mm/s^2)
M203 X10000 Y10000 Z600 E3600       ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20              ; Minimum speeds mm/minute
M208 X300 Y300 Z380					; set axis maxima (adjust to suit your machine)
M208 X0 Y0 Z0 S1					; set axis minimum (adjust to make X=0 and Y=0 the edge of the bed)
M92 X160 Y160 Z800      			; Set axis steps/mm
M92 E837	                    	; Set extruder steps per mm
G21                                 ; Work in millimetres
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves

; Heater and thermistor section

M305 P1 R4700 H0 L0					; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
M301 H1 P10 I0.10 D100 T0.50 S1.0	; PID settings for extruder 0
M570 S120							; Increase to allow extra heating time if needed

; Tool definition section
M563 P0 D0 H1                       ; Define tool 0 to use extruder drive 0 and heater 1
G10 P0 S0 R0                        ; Set tool 0 operating and standby temperatures

; Epilogue
T0									; select first hot end

Edited 2 time(s). Last edit at 04/20/2017 12:01AM by xnaron.

I'd try to use lower M566 values at first.

Are you sure the jerking isn't a result of belt flexing x mechanics stiction?

I got it, you are using your old config.g with the new firmware. That is problematic in some ways, like the thermistor definition.
You should download the whole github folder and use the newest config.g from the sd-image folder.

Edited 2 time(s). Last edit at 04/20/2017 03:15AM by o_lampe.

It's normal to see stuttering when printing a skirt that has been generated by S3D, it's because of the way that S3D generates skirts. If it's stuttering during curves in the print as well, you probably need to increase the M566 X and Y jerk settings.

---

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
dc42
It's normal to see stuttering when printing a skirt that has been generated by S3D, it's because of the way that S3D generates skirts. If it's stuttering during curves in the print as well, you probably need to increase the M566 X and Y jerk settings.

Thanks I'll try that.

I recently installed some LED strips on my CoreXY and wanted to switch them by an unused MOSFet. I already have P0 and P1 working for extruder and part fan, but I can't switch P2.
I tried all three unused MosFet terminals, but narda. Trying to switch P3 leads to an error message like: Only P0-P2 available for fans...

I have defined three extruders, but they all use the same heater output H1. ( Diamond Hotend )
Is it a bug? Does RRF occupy three MosFets for the extruders, although only one is needed?

Is there a m-code to unlock the terminals?

The pin definitions in RRF for RADDS include this:

Quote

// Use a PWM capable pin
const size_t NUM_FANS = 2;
const Pin COOLING_FAN_PINS[NUM_FANS] = { 9, 8 }; // Fan 0, Fan 1

so only 2 fans are supported. But you can use M42 to control unused pins, see [duet3d.com].

---

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 have tried to install the latest firmware 1.9beta9 and I am unable to connect via usb or panel due,
has anybody had the same problem?

Do you have the latest Duet-driver installed?
It's on the same github page as RRF.
I also attached my latest download, but not sure if it's the newest...

Thanks for the reply, I have a radds board, on linux.
I can connect with 1.8 both with the usb and the panel due but when I update to 1.9 I cannot!