New beta firmware 2.02beta1

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.

zerspaner_gerd

What does the new M703 command do?
Wiki is not completely understandable to me!

wilriker

@zerspaner_gerd The filaments have a new entry in the context menu. Besides load and unload macros you can now also define a filament specific config. M703 will check if such a config had been setup by the user for the currently loaded filament and execute it. It will do nothing (especially no error) of no config exists.

EDIT: Use-case: If you have e.g. different retraction settings for your different filaments (and use firmware retract) you could add these settings in the config and load it as part of your start GCODE via M703. (That's how I actually use it)

brunofporto

Ok,

I tested the DAA function... First time I thought I had great results, until turn it off and print the same gcode and had the same result....

Then I tested my maximum acceleration until I had to miss steps (2500mm/s²) to be sure and printed some single perimeter hollow cubes at three different speeds with the DAA turned off to check if my frequencies where close to the DAA setting.

Well... They are always around 40Hz and the DAA was set to this frequency.

I could see no improvement (the ripples are already very subtle before it anyway)

Am I doing something wrong or the test subjects had features that does not benefit from the algorithm? Is there a test model to use as a common reference?

I used a 20mm simple cube and this (printed hollow, single perimeter, etc) : https://www.thingiverse.com/thing:277394

Thanks!

Phaedrux

@brunofporto can you post a photo of the ringing? Perhaps it's not actually ringing at all.

burtoogle

Some more F593 testing...

I printed https://www.thingiverse.com/thing:277394 without (left) and with M593 F40 (right) on my Kossel XL with flex3drive extruder.

On this example, the ringing is maybe a little reduced but not everywhere and also the piece on the right has some noticeable roughness which can be seen as a shiny area downstream of sharp corners.

So M593 actually makes this print worse for me.

zerspaner_gerd

@wilriker Nice, I did not see that. I can do something with that. Thank you

dc42

@burtoogle said in New beta firmware 2.02beta1:

...On this example, the ringing is maybe a little reduced but not everywhere and also the piece on the right has some noticeable roughness which can be seen as a shiny area downstream of sharp corners.

So M593 actually makes this print worse for me.

Reduced acceleration will cause the head to spend more time near corners. On a Bowden extruder, that will make it more important to use the correct pressure advance setting.

burtoogle

@dc42 said in New beta firmware 2.02beta1:

On a Bowden extruder, that will make it more important to use the correct pressure advance setting.

It's not a Bowden extruder, it's a flex3drive.

dc42

A Flex3drive might require pressure advance to compensate for the torsional elasticity of the Bowden cable. I've never used one, so I don't know whether this is the case or not.