New beta firmware 2.02beta1

dc42

I have just released this at https://github.com/dc42/RepRapFirmware/releases/tag/2.02beta1. This release introduces some major new features:

Dynamic Acceleration Adjustment (DAA). This is an experimental feature that adjusts the acceleration and deceleration of moves independently, to minimise excitation of mechanical resonance at a specified frequency, thereby reducing ringing. By default this feature is disabled. Use the M593 command to enable and configure it.
Control of laser power using the G1 S parameter when the machine is configured for use as a laser cutter or an engraver using M452.
Re-assignment of fans to different fan pins and to heater pins. Use the M106 A parameter to configure this. For example, if you want to use an air pump having a brushed DC motor instead of a normal print cooling fan, but the starting current surge of the pump is too high for the fan mosfets, you can use a spare heater output to drive the pump.
Direct configuration of TMC2660 and TMC2224 stepper driver off-time

There are several other smaller feature additions and a number of bug fixes. See https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the full change list.

Also included with this release is chrishamm's Duet Web Control 1.22.1.

IMPORTANT! If you use this firmware to control a laser cutter or engraver, be sure to read the upgrade notes, and test it very carefully in case the laser turns on unexpectedly!

burtoogle

Just trying this out now and the file progress estimate is wildly different from the others. More often it's the layer time estimate that is different from the other two.

burtoogle

And now, a couple of minutes later...

I know! you're using the same algorithm as was used in the Windows copy file utility, the estimated completion time in that used to go up and down like a yoyo!

burtoogle

The first test of the ringing reduction feature has completed. I used M593 F40 and printed exactly the same gcode as I did previously with no other changes to printer settings. I don't think I can get a photo good enough to show the differences so I will describe them:

1 - the ringing downstream of the model's sharp corners is reduced quite well. It's still just about visible in some places.

2 - the sharp edges could possibly be marginally fatter than before (like you see when using low acceleration) but that could be simply because the ringing is less visible the eye is drawn to the nearest artifact!

3 - I get an overall impression that the result is slightly rougher than before. This is most noticeable on the corner of the model that is downstream of the numbers. Whereas that downstream corner was fairly straight before, it now has more kinks and bumps in it. The're tiny but visible. Also the surface area between the numbers and that corner does look rougher than before. It's almost as if the effector is suffering from some stiction and not travelling to the right position immediately after finishing the digits?

So, a very promising first test. I need to experiment with the F value to see how critical that is.

dc42

The print time estimation algorithm hasn't changed between 2.0 and 2.02beta1. The layer time estimate has always been the least accurate one, unless you are printing something like a cylinder or square tower that is basically the same all the way up. The one I find odd is the estimate based on file progress, which has gone from lower than the other two to much higher.

wilriker

First print running with the new firmware. I had a layer shift but that definitely is a mechanical problem I was hesitating to fix but I will have to disassemble my Y axis - again.

Anyway everything looking good so far. I very much like the new M703 so thanks @chrishamm for this. I was replicating something similar manually but this builtin approach is very handy!

Also adjusted my config for M569 Fnnn and G0/1 Hnnn already. I like change!

@dc42 Not sure if you have overlooked it or if you are just too busy with upcoming TCT: I fixed my other PR according to your comment - I just did mess (up) with the regular PR update process.

burtoogle

Another test of the anti-ringing feature - interesting results.

The part on the right was printed recently using an earlier firmware. The part on the left is using M593 F40. The part is basically rectangular with a couple of holes as you can see. Noteworthy points are:

1 - the ringing downstream of the corner at the top of the picture is pretty much the same for both parts. The side upstream of the corner is long enough to let the nozzle reach the requested print speed.

2 - The ringing downstream of the holes is much reduced using M593. Presumably the nozzle velocity was still quite low as the hole isn't deep compared to the depth of the whole part.

3 - The leading edge of the holes is "fattened" using M593.

dc42

Thanks for sharing your results. It's interesting that the ringing downstream of the corners wasn't changed much, but the ringing around the hole was reduced.

Are you using pressure advance? It should help control the fattening around the hole.

burtoogle

@dc42 said in New beta firmware 2.02beta1:

Thanks for sharing your results. It's interesting that the ringing downstream of the corners wasn't changed much, but the ringing around the hole was reduced.

Are you using pressure advance? It should help control the fattening around the hole.

No, I have never managed to use pressure advance satisfactorily. I shall have another go sometime.

dc42

I have been thinking about how come the ringing wasn't reduced at the corners. Perhaps your acceleration limits were set too low to allow the optimum acceleration to be used there. What perimeter printing speed did you use, and what were your M201 X and Y acceleration limits? Did you have any M204 limit set? I assume you are using Cura, but I don't know whether Cura adds a M204 command to the G-code prologue the way some versions of Slic3r do.

burtoogle

@dc42 said in New beta firmware 2.02beta1:

I have been thinking about how come the ringing wasn't reduced at the corners. Perhaps your acceleration limits were set too low to allow the optimum acceleration to be used there. What perimeter printing speed did you use, and what were your M201 X and Y acceleration limits? Did you have any M204 limit set? I assume you are using Cura, but I don't know whether Cura adds a M204 command to the G-code prologue the way some versions of Slic3r do.

Hi David, all of the walls are being printed at 40 mm/S. No M204 in the gcode. Other params as shown here:

M201 X3000 Y3000 Z3000 E400		; Accelerations (mm/s^2)
M203 X18000 Y18000 Z18000 E1200		; Maximum speeds (mm/min)
M566 X300 Y300 Z300 E10			; Maximum instant speed changes

This Kossel XL is fitted with a flex3drive extruder, hence the low extruder accel and jerk.

In the older print, the ringing downstream of the hole is visible for almost as far as the ringing that's downstream of the corner which implies that the ringing amplitudes are similar?

burtoogle

I should add that the wall (not shown in image above) that precedes the corner at the top of the image is approx 50mm long so there's plenty of time for the nozzle to reach the commanded velocity (in the direction normal to the surface we are looking at). By contrast the holes are only about 4mm deep so I would expect the velocity to be quite low still by the time it reaches the edge.

dc42

At 40mm/sec and trying to cancel 40Hz ringing, the optimum acceleration at the corners should be 1600mm/sec^2 or less, depending on how much jerk you have configured. So if there is definitely no M104 command either in config.g or in the code generated by the slicer, that doesn't explain it. You can run M104 without parameters to check.

The interior perimeters of the holes may be being printed at a lower top speed if the holes do not go right through the cube, in which case the optimum acceleration when printing them will be lower.

burtoogle

M204 query gives:

Maximum printing acceleration 10000.0, maximum travel acceleration 10000.0

T3P3Tony

@dc42 a question from a github conversation "Do you also adjust the laser pwm depending on x/y acceleration and deceleretion (like Grbl in M4 mode)?"

https://github.com/LaserWeb/LaserWeb4/issues/500#issuecomment-412592499

keyz182 created this issue in LaserWeb/LaserWeb4

closed Duet Support #500

dc42

@t3p3tony said in New beta firmware 2.02beta1:

@dc42 a question from a github conversation "Do you also adjust the laser pwm depending on x/y acceleration and deceleretion (like Grbl in M4 mode)?"

https://github.com/LaserWeb/LaserWeb4/issues/500#issuecomment-412592499

Not yet, but I plan to do so before the 2.02 release. It does adjust the laser power if for any reason the actual top speed of the move is slower than the requested speed.

mdfverona

Tried a few prints on the beta and was working well, but I just had a print stop half way through but claim to be compelted. The web interface makes it look like it was completed, but there is about 1/2 a file of gcode left. Only message in the console was:

"Finished printing file 0:/gcodes/corners.gcode, print time was 2h 48m"

I downloaded the gcode file from the web interface to check and it seems okay and a simulator has the full print.

Here is the gcode downloaded from the web interface: https://drive.google.com/open?id=1_dRimJ3CkYL3QDAyAvLwodNUpNk8j5s7

Anything else I should look at?

M122 right after it happened is:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02beta1(RTOS) running on Duet WiFi 1.02 or later + DueX2
Board ID: 08DGM-9568A-F23SD-6J9DL-3SJ6R-K9RRH
Used output buffers: 3 of 20 (14 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 98404 of which 12 recycled
Exception stack ram used: 532
Never used ram: 3648
Tasks: NETWORK(ready,328) HEAT(blocked,1192) MAIN(running,1660)
Owned mutexes:
=== Platform ===
Last reset 07:21:25 ago, cause: software
Last software reset at 2018-08-11 18:28, reason: User, spinning module GCodes, available RAM 5740 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 94.0ms, max retries 0
MCU temperature: min 43.0, current 43.2, max 56.1
Supply voltage: min 23.8, current 24.0, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/236
Driver 1: standstill, SG min/max 0/257
Driver 2: standstill, SG min/max 0/1023
Driver 3: standstill, SG min/max 0/255
Driver 4: standstill, SG min/max 0/271
Driver 5: standstill, SG min/max 0/1023
Driver 6: standstill, SG min/max 0/1023
Expansion motor(s) stall indication: yes
Date/time: 2018-08-13 17:02:34
Slowest loop: 132.81ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 145, MaxWait: 2403580ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: mesh
Bed probe heights: -0.003 -0.003 -0.006 0.003 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Segments left: 0
Stack records: 4 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 125.06ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address 2c:3a:e8:0b:17:81
WiFi Vcc 3.45, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 16600
WiFi IP address 192.168.86.38
WiFi signal strength -45dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===
DueX I2C errors 0

dc42

Your M122 report is clean and I didn't spot anything wrong with the GCode file.

brunofporto

@dc42 said in New beta firmware 2.02beta1:

Dynamic Acceleration Adjustment (DAA). This is an experimental feature that adjusts the acceleration and deceleration of moves independently, to minimise excitation of mechanical resonance at a specified frequency, thereby reducing ringing. By default this feature is disabled. Use the M593 command to enable and configure it.

That is just wonderful....

Please, does anyone have a good methodology to tune base jerk and acceleration settings?

Phaedrux

This post is deleted!