New highly experimental firmware 0.80-delta-dc42

I have made a new firmware binary available via [github.com] (note this is in the 'delta' branch, not my usual dev branch). The main changes in this release are:

Quote

1. The step-generation code has been completely rewritten. The old code used the Bresenham algorithm to generate step pulses at approximately the correct times, but for diagonal movements the step pulses were generated at irregular intervals. The new code generates step pulses at precise times (modulo interrupt latency), calculated to better than 1us, by solving the equations of motion in real time. This makes for smoother movements.

2. The lookahead code has been rewritten. The old code used a cosine approximation, which was generally satisfactory at normal printing speeds, but in some situations led to sharp movements and possibly missed steps. The new code always ensures that no drive is forced to try to change velocity by more than its InstantDv value. This should mean the end of acceleration bugs.

3. The movement code no longer uses the InstantDv values to enforce a minimum speed. You can go as slow as you like. The M566 command sets the InstantDv values as it has always done.

4. Optional compensation for Bowden elasticity. The Bowden extruder system is modelled as a spring, which gets compressed by the extruder back force, and that force is assumed to be proportional to the extrusion rate. So the extruder is commanded to make extra steps when accelerating the extrusion, and fewer steps when decelerating - in fact, it will take reverse steps if decelerating fast enough.

5. Added command M572 Pn Sm to set the elasticity compensation, where the P parameter is the drive number (e.g. 3 for the first extruder) and the S parameter is the compensation factor (measured in seconds). S is zero by default (i.e. no compensation). Sensible compensation values probably lie between 0.01 and 0.1.

6. The parameter to the M111 command can now selectively enable debug output for any combination of modules. A parameter value of 1 will enable debugging for all modules, for backwards compatibility. Otherwise, the parameter is interpreted as the bitwise-or of values relating to each module, as follows: Platform=2, Network=4, Webserver=8, Gcodes=16, Move=32, Heat=64, Dda=128 (this one is temporary).

7. Fixed a bug whereby unless auto-saving of parameters to flash memory was enabled, after a software reset occurred the software reset reason and free memory at the time were not correctly reported by the M122 command.

The compatible web interface is still version 1.04. I am hopeful that this release gets rid of the remaining (rare) acceleration bugs. Nevertheless, I advise caution when using it. I suggest you don't use it for large or unattended prints until you have gained some experience with it, especially if you enable the elasticity compensation. If you don't want to be on the bleeding edge, then I suggest my 0.78za-dc42 release instead, available at [github.com].

Note that elasticity compensation requires making step changes to the extruder speed. Like all other changes, these are limited by the configured InstantDv value. In practice, this means that the higher the elasticity compensation you configure, the more the extruder acceleration (and hence general acceleration in moves involving extrusion) is reduced. Also, I find that the default InstantDv values for the X and Y axes are too high to give smooth movement. So I am currently using the following commad to set the InstantDv values:

M566 X5 Y10 E20

On my printer, the X axis seems to fare less well with sudden jerks than the Y axis. I have a theory that the sudden pull by the belt twists the X-carriage and causes the X idler bearing the lose contact with the X-arm and then bounce back on to it. Your build may differ. I increased the E value so as to allow higher elasticity compensation values with less effect on acceleration. You may be able to use higher InstantDv values on your build.

Also note that elasticity compensation often causes the extruder to go backwards a few steps at the end of a move, and this obviously requires low-backlash extruder gears.

In the test prints I have done so far, the effect of enabling elasticity compensation has been disappointing. But I have only gone up to a compensation factor of 0.02 so far, because of the effect of higher compensation on acceleration and hence printing speed. Ideally, compensation would be used only when doing perimeters and top infill.

Edited 2 time(s). Last edit at 12/27/2014 02:47PM 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].

Merry Christmas David, and Thank You ever so much for all you hard work and support of the group, where would We (and RepRapPro) be without You, Me, I would have send the Ormerod back in a box long time ago - yes I can fiddle with the mechanics but bits and bytes not so much

3470 supporting posting in a year is quite an achievement and must have left You with very little time for revenue producing activity

Looking forward to test the new firmware next print (ver. 0.78v installed and printing perfectly)

Thanks, Erik

Hi Dave

Thanks for the new firmware release the improvements seem to be very interesting. I am looking forward to test the firmware as time permits.

Quote
dc42
In the test prints I have done so far, the effect of enabling elasticity compensation has been disappointing. But I have only gone up to a compensation factor of 0.02 so far, because of the effect of higher compensation on acceleration and hence printing speed. Ideally, compensation would be used only when doing perimeters and top infill.

While i also thought that the bowden has some effects on printing, i have come to the conclusion (from my experiments with improved cooling) that cases with thin walls missing cooling gives effects looking similar as a bowden problem. My explanation is that by missing cooling the layer below is still soft, then the next layer pulls the material a slight bit away from its initial place. This effect adds up with each layer and after a while there is a hole in the wall. But i hopefully i can test if the bowden compensation has anything to do with it.

Speaking of my cooling solution: I am in the process of replacing the lightweight venting flap with a servo controlled one. Is it possible to drive a servo pwm signal from your firmware?

All in all i would say that i am pretty happy with my print quality right now. I can print spare parts for some popular nobbed toys to the delight of some family members :-) .

Best regards
Tim

Quote
DC42
4. Optional compensation for Bowden elasticity

It looks like allesandro has also been working on something like this for slic3r 1.2.2
He calls it "pressure management", might be work to "cross check"
[slic3r.org]

oh and happy festive days to all of you & all the best for 2015
auser

Wow. The movement algorithm sounds great! (Do I dare to try it though though.. I've been out of the loop for a bit so now sure what mods I need to make.)

Anyway this sounds like a great step forward for the Duet!

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Great job indeed. With the risk of making a fool out of myself but how much do i save from the existing files on my SD-card? What settings is required after update?

Thanks
Robert S

Quote
RoSt
Great job indeed. With the risk of making a fool out of myself but how much do i save from the existing files on my SD-card? What settings is required after update?

Thanks
Robert S

If you are running RRP 0.78c firmware or any recent release of my firmware, you can keep your existing files in the /sys folder of the SD card. If you are running RRP firmware, then in order to use mine, you will need to update the contents and subfolders of /www.

---

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 tried to test this new firmware, but it seems to be failing on the G32 step that I usually start with:

1. Power on - ok
2. Connect web interface and confirm firmware version is reported correctly - ok (0.80-delta-dc42)
3. Zero all axes - ok
4. Send G32 - after checking level at first corner, z axis continues to rise indefinitely

In case it matters, here is my config.g:

; Configuration file for RepRap Ormerod 2
; RepRapPro Ltd
;
; Copy this file to config.g if you have an Ormerod 2
; If you are updating a config.g that you already have you
; may wish to go through it and this file checking what you
; want to keep from your old file.
;
M111 S0 ; Debug off
M550 PMy RepRapPro Ormerod 2 ; Machine name (can be anything you like)
M551 Preprap ; Machine password (currently not used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
M552 P192.168.253.14 ; IP address
M553 P255.255.255.0 ; Netmask
M554 P192.168.253.1 ; Gateway
M555 P2 ; Set output to look like Marlin
G21 ; Work in millimetres
G90 ; Send absolute corrdinates...
M83 ; ...but relative extruder moves
M906 X800 Y1000 Z800 E1000 ; Set motor currents (mA)
;M305 P0 R4700 ; Set the heated bed thermistor series resistor to 4K7
;M305 P1 R4700 ; Set the hot end thermistor series resistor to 4K7
M569 P0 S0 ; Reverse the X motor
M92 E430 ; Set extruder steps per mm
M558 P2 ; Use a modulated Z probe
G31 Z2.0 P550 ; Set the probe height and threshold
M557 P0 X55 Y0 ; Four...
M557 P1 X55 Y180 ; ...probe points...
M557 P2 X215 Y180 ; ...for bed...
M557 P3 X215 Y0 ; ...levelling
;xy
M556 S78 X0 Y-1.0 Z-1.25 ; Put your axis compensation here
M201 X500 Y500 Z15 E500 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X1200 Y1200 Z30 E1200 ; Minimum speeds mm/minute
M563 P1 D0 H1 ; Define tool 1
G10 P1 S-273 R-273 ; Set tool 1 operating and standby temperatures

Rkc, thanks for your feedback. I'll check out the G32 behaviour when I get back to my printer. I didn't do a G32 before my test prints because the bed is reasonably level and the prints were small.

---

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 tried printing one of my problem parts without the G32 - the one that was showing missing filament due to extruder skipping.

It looks like that issue is probably resolved with this firmware - good job (though without G32 I am getting some rather uneven widths on my bottom layer - my bed is not as level as it should be!).

I also noticed that the home all axes seems to take longer than it used to - in particular the X axis homing seems to be moving the head very slowly. I'm guessing that this is related to the removal of the minimum speed).

Richard

Thanks Richard, I'm glad the new firmware has solved one problem, even though it's caused another. I'll post an update in this thread when I sort out the G32 issue.

The slow final stage X homing is indeed caused by the removal of the minimum speed. The homex.g and homeall.g files use F200 in the relevant G1 commands AFAIR, whereas the default minimum speed used to be 900. You can edit those files to increase the speed.

---

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've fixed the G32 issue and uploaded a new binary, version 0.80b-delta-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 have done a further update (version 0.80c) to fix a problem that occurred with some types of move.

One issue I have found is that if I use a large amount of elasticity compensation in the M572 command, then the filament tends to develop a slight bulge that gets stuck in the PTFE tube going into the hot end. Compensation of 0.15 is enough to trigger this, while compensation of 0.07 does not. I think it's caused by a combination of retraction while doing elastic compensation, and the normal retraction for non-printing moves configured in slic3r. I currently have that set to 4mm, so I'll try reducing it.

---

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 been trying your (first) delta firmware, but cannot see any difference in behaviour. I tried increasing the compensation to 0.2 seconds but still no discernible difference from earlier firmware.

The command I am using is:
M572 P1 S0.2

And my entire start custom G code is

T1
G21 ; set units to millimeters
M203 X12000 Y12000 Z500 E3000 ; Allow 200mm/s speeds
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 Z5 F200 ; lift nozzle
G1 X2 Y50 F2000; Go to wait for warm position
M116; Wait for all temperatures
M572 P1 S0.2

Which I have verified is at the start of the G-code for my prints.
The settings page of the web browser reports:
Duet Firmware
0.80-delta-dc42
reprap.htm
1.04
reprap.js
1.04


[Added]
My config.sys in case it is relevant:

; RepRapPro Ormerod config
; Standard configuration G Codes modified by dc42 some more

M111 S0 ; Debug off
M550 PDave's Ormerod ; Set the machine's name
M551 Preprap ; Set the password
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
M552 P192.168.1.250 ; Set the IP address

M553 P255.255.255.0 ; Set netmask

M554 P192.168.1.254 ; Set the gateway

M555 P2 ; Emulate Marlin USB output
G21 ; Work in mm
G90 ; Absolute positioning
M83 ; Extrusions relative
M906 X1000 Y1000 Z800 E1000 ; Motor currents (mA)
M563 P1 D0 H1 ; Define tool 1
;M563 P2 D1 H2
G10 P1 S0 R0 ; Set tool 1 operating and standby temperatures
M208 X220 Y220 ; Set bed size
M92 E429 ; Set extruder steps/mm 1.75mm

M558 P1 ; enable differential IR sensor
G31 P500 Z1.80 ; set height and threshold
M305 P0 H18.2 L-14 ; set ADC correction
M305 P1 H18.2 L-14 ; set ADC correction
M557 P0 X35 Y20
M557 P1 X35 Y200
M557 P2 X210 Y200
M557 P3 X210 Y20
;M556 S78 X0 Y0 Z0 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; set accelerations
M203 X15000 Y15000 Z100 E3600 ; set XYZ and extruder speeds
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute


Dave

Edited 1 time(s). Last edit at 01/02/2015 12:55PM by dmould.

Hi Dave,

In the M572 command, P is the drive number. So use P3 for the first extruder and P4 for the second extruder.

I am using the default maximum jerk speeds (aka minimum feed rates in earlier versions of the firmware) except for the extruder, which I have increased (otherwise the acceleration gets limited too much). So to use the elasticity compensation, I send these commands prior to printing:

M566 E100
M572 P3 S0.1

(change S0.1 to whatever compensation factor you want to use).

Edited 1 time(s). Last edit at 01/02/2015 02:08PM 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].

OK, thanks I will try that. I didn't understand what a "drive" was in this context, but now I assume it means a stepper motor. So presumably the X axis motor is drive 0, Y axis motor drive 1 (or vice versa?), Z axis motor drive 2 and the extruder drive 3?

If anything I have been seeing an increase in "blobbing" at the end of infill lines, which I had put down to the fact that I removed the "coast to end" feature in Simplify3D in anticipation of this firmware achieving a similar function. Presumably though, my erroneous command has caused the delay to be applied to the X or Y axis, so that may have exacerbated the blobbing.

Dave

Elastic compensation is only applied to extruder drives, and only when there is XY movement as well as extruder movement. So your Y drive would not have been affected.

---

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 had another go with 0.80c last night, but the results were a little inconclusive. G32 does seem to be fixed now (thanks). My problem piece now prints without the gap (again, thanks). I'm still seeing some slower moves here and there particularly when homing - I adjusted values in the sys/*.g files but I must have missed something - in particular the X carriage movement after a G32 before it starts to print is painfully slow.

I printed a test piece (0.5mm single wall) and the print speed in general seemed to be slower than I remembered it being - in the gcode it looks like the federates are F600 so perhaps this is still slower than the old default minimum speed? I think in general the removal of the lower bound on speeds is causing quite a lot of differences - all probably correct but may need some adjustments in the sys files and maybe the default print settings to change things that were previously slower than optimal but no-one noticed as the minimum speed overrode it.


At one point (sorry, I don't recall the exact steps before this point) I did a home X and the X carriage crashed into the upright.

Switched back to 78y for now...

Hmm - strange. As I was in the middle of a print when I read your reply to my first post, I attempted to try it by pausing the print, sending the two commands you gave by hand (via the "Send GCode" box, and then resuming. The print continued to infill at about 20% speed (i.e. very slowly) until it started on a new perimeter (presumably getting a new speed parameter in the G code), but leaving many gaps in the infill. I decided to stop the print and scrap it, and re-sliced with the correct commands you gave (M566 E100 and M572 P3 S0.1) in the start G-code. I reset everything (power cycled the printer & restarted the web client) before starting the print. All the XY moves were OK, but the extruder would extrude for a line or two of the skirt, then stop extruding completely for a few lines (over a second), then start again etc. Obviously the print was no good at all so I stopped it after a minute or so and re-started with new code that did not have the M572 command as I needed to complete the print.

I'll experiment later today and post my results. Obviously this is not how the firmware behaved in your tests, so it may have been an interaction with the way Simplify3D constructs its G code.

Dave

Dave, were you running 0.80c? There was an issue in 0.80b that could cause the extruder to stop for a while.

rkc, the default X and Y feed rates in 0.78c are 900, so 600 is indeed slower. Regarding the slow head movement after G32 at the start of your print, my guess is that you have a G1 command with no F parameter in your start Gcode soon after the G32, to move the head off the bed while it heats up. Add a suitable F parameter (e.g. F2000) to that G1 command.

Edited 1 time(s). Last edit at 01/03/2015 11:12AM 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].

OK, I had been using the first firmware posted (unlettered, so the "a" version). After updating to the "c" version I sliced a simple cube (40mm X 40mm X 5mm), and experimented with the M572 parameter. With the parameter set to 0.15 it seems to reduce infill edge blobbing, and it reduced corner blobbing slightly. I did not try it on an overhang. Trying to find the optimum setting, I tried setting the M572 parameter far too high (0.5) to see the effect of overcompensation, the idea being that by knowing what both under and over-compensation looks like I could more easily find the most favourable value. To my surprise however, the print seemed to behave exactly the same as it did with a setting of 0.15, both in the final print and in the way the extruder seems to behave. Is there a maximum limit that has been invoked?

It is disappointing, and I'd say at best works no better than Simplify3D's "coast at end" feature (which I had switched off for the first few tests). I tried a test with M572 set to 0.2 with the "coast at end" feature enabled, and there was distinct interaction, with the print slowing down and performing the coasts as noticeably separate moves rather than a single motion as it usually does, and the extruder gear sometimes oscillated back and forth at the end of longer infill lines. Corner blobbing was improved a little, but that could simply be due to the lower speed the corners were printed.

I still think it would be worth trying a simpler approach by just delaying all X&Y moves by a fixed time interval so that the extruder is leading the XY moves. How easy would that be to try in your re-written move code?

Dave

I have not been able to try compensation larger than 0.07 yet because of limited time and because the prints I tried at compensation 0.15 and 0.2 failed due to the issue I mentioned 9 posts ago. I was disappointed with the print at compensation 0.07, which wasn't much better than the one with no compensation.

To get faster printing with higher compensation values, you will need to increase the M566 parameter for the E drive. The firmware default is 20mm/min. I increased this to 100mm/min in my tests. The default in Marlin firmware is 120mm/min, so there may be scope for increasing it further. If you go too high then the extruder drive may lose its grip on the filament.

Having the extruder lead the XY moves would avoid having to reverse the extruder and also avoid the acceleration issues. The danger is that it may start extruding too soon, resulting in blobs at the start of a run instead of the end. It's not easy to implement, because it requires separating the XYZE moves into individual records, instead of keeping them all in a single record. However, there is another (small) advantage to splitting them into separate records, so I may look at this in the future.

---

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.

I had tried your delta firmware and had some issues so i have now reverted back to 78y. However i now have an issue where every time my head moves to the wait for temperatures position the head heater comes on and starts working to reach 235
But when it gets to around 231 the head then turns off every time?

i have attached the config and the g code i am trying to print.

Config:
; Configuration file for RepRap Ormerod 2
; RepRapPro Ltd
;
; Copy this file to config.g if you have an Ormerod 2
; If you are updating a config.g that you already have you
; may wish to go through it and this file checking what you
; want to keep from your old file.
;
M111 S0 ; Debug off
M550 PMy RepRapPro Ormerod 2 ; Machine name (can be anything you like)
M551 Preprap ; Machine password (currently not used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
M552 P192.168.1.99 ; IP address
M553 P255.255.255.0 ; Netmask
M554 P192.168.1.254 ; Gateway
M555 P2 ; Set output to look like Marlin
G21 ; Work in millimetres
G90 ; Send absolute corrdinates...
M83 ; ...but relative extruder moves
M906 X800 Y1000 Z800 E800 ; Set motor currents (mA)
M563 P1 D0 H1 ; Define tool 1
G10 P1 S0 R0 ; Set tool 1 operating and standby temperatures
M92 E412 ; Set extruder steps per mm
M558 P1 ; Use a modulated Z probe
G31 P500 Z2.60 ; Set the probe height and threshold (deliberately too high to avoid bed crashes on initial setup)
M305 P0 R4700 ; Set the heated bed thermistor series resistor to 4K7
M305 P1 R4700 ; Set the hot end thermistor series resistor to 4K7
M557 P0 X38.79 Y19.47 ; Four...
M557 P1 X38.87 Y199.49 ; ...probe points...
M557 P2 X180.76 Y199.49 ; ...for bed...
M557 P3 X180.74 Y19.47 ; ...levelling
M557 P4 X100 Y100 ; 5th probe point for levelling (un-comment this if you are using a dc42 differential IR probe)
;M569 P0 S0 ; Reverse the X motor
M556 S77 X-1.0 Y0.75 Z1.25 ; Put your axis compensation here
M201 X500 Y500 Z15 E500 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute

Gcode:
; generated by Slic3r 1.1.7 on 2015-01-04 at 09:18:23

; perimeters extrusion width = 0.50mm
; infill extrusion width = 1.02mm
; solid infill extrusion width = 0.85mm
; top infill extrusion width = 0.85mm
; support material extrusion width = 0.50mm

G21 ; set units to millimeters
M107
M190 S90 ; wait for bed temperature to be reached
M104 S235 ; set temperature
; layer_height = 0.2

T1
G21 ; set units to millimeters
M203 X12000 Y12000 Z500 E3000 ; Allow 200mm/s speeds
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 Z5 F200 ; lift nozzle
G1 X2 Y50 F2000; Go to wait for warm position
M116; Wait for all temperatures
M109 S235 ; wait for temperature to be reached
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion

Forgot to mention. If i power cycle the system the head comes on as active. If i put the head on standby it will get to temperature and complete a print. Then i would have to power cycle and put the head on standby again to get another print done. I cannot pause then reset to do a print or from just powering on.

Thanks.
Mick.

Edited 1 time(s). Last edit at 01/04/2015 04:52AM by Mick747.

Hi Mick, which version of the delta branch firmware did you use? I am not aware of any problems in 0.80c.

Regarding your hot end issue, it sounds to me that the heater timeout needs increasing. The default is 120 seconds. Add a M570 command in config.g to increase it, see [reprap.org].

---

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 Dave.
Thanks for the response. I had been using 0.80c but the main issue was down to the hot end not getting to temp which is now fixed thanks to you pointing out the timeout setting. Just not sure why this started showing up after moving to your delta builds.

Will re flash 0.80c after my current build has finished and try again.

Many Thanks.
Mick.