New beta firmware 2.02beta1

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!

Phaedrux

@brunofporto said in New beta firmware 2.02beta1:

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

For jerk you can kind of tune by ear. I try and keep it low enough so that motion is still smooth but quick. Ie no noticeable pauses at direction changes and it doesn't sound like it's shaking the machine apart. X600 Y600 is a good starting point. A delta can probably get away with more than a cartesian. CoreXY in the middle.

For acceleration you can do a test print and start with a low value and increase it every 20 layers or so. a 100mm cube is a pretty decent model to test with. You can use the formula from the Periodicity of Ringing thread to try and measure your results and find a more suitable acceleration value.

https://forum.duet3d.com/topic/5951/periodicity-of-ringing

wilriker

@phaedrux said in New beta firmware 2.02beta1:

For acceleration you can do a test print and start with a low value and increase it every 20 layers or so. a 100mm cube is a pretty decent model to test with. You can use the formula from the Periodicity of Ringing thread to try and measure your results and find a more suitable acceleration value.

I was always wondering what is the upper limit I am looking for with accel? Or put another way: how do I recognize the upper limit of what is possible with my machine? I still have the values set that I took from Marlin config and never really touched this topic yet.

dc42

@phaedrux said in New beta firmware 2.02beta1:

You can use the formula from the Periodicity of Ringing thread to try and measure your results and find a more suitable acceleration value.

Dynamic Acceleration Adjustment does that for you. So all you need to do is find out how high you can set the acceleration without any risk of missing steps.

brunofporto

@dc42 said in New beta firmware 2.02beta1:

@phaedrux said in New beta firmware 2.02beta1:

You can use the formula from the Periodicity of Ringing thread to try and measure your results and find a more suitable acceleration value.

Dynamic Acceleration Adjustment does that for you. So all you need to do is find out how high you can set the acceleration without any risk of missing steps.

That is what I loved about this update I'll test it ASAP.

@dc42 Is it possible to use stall detection and some macro sequence to "auto-tune" max acceleration and/or jerk? Not now, but as a future improvement

For now, I'll use @Phaedrux tuning macro collection to tune them. But would be nice if the firmware was able to automatically tune those settings like we already do with PIDs from heaters.

dc42

@brunofporto said in New beta firmware 2.02beta1:

@dc42 Is it possible to use stall detection and some macro sequence to "auto-tune" max acceleration and/or jerk? Not now, but as a future improvement

The problem is that so-called "stall detection" doesn't actually detect motors stalls, what it detects is abnormally high loads that may indicate an approaching stall.

garlicbread

Just like to say thanks to dc42 (I think Dave) and the other firmware developers for all they're hard work.

I've recently managed to get my Anycubic Kossel Delta to work with the new duet board. It took a little while to figure out but I've got a lot more confidence in the bed leveling now than the original Marlin board.

I plan on writing up some docs on my blog at some point with a more step by step guides to try and simplify the setup process, and list some of the things / quirks I've noticed.