New firmware 1.21RC1 available
-
Not sure if I understood hoy the multi-touch works, I think it does two, and if the tolerance is less than the configured, then it moves to the next one, if the tolerance is bigger, it repeats until A is reached (or the tolerance is lower than the configured).
That's correct.
One improvement that should be easy, can you add to the Error message ("Error: Z probe readings not consistent") the tolerance? in that way you can check how far you are…
Which value(s) should it print? Perhaps the difference between the minimum and the maximum heights read?
-
I hate to be bearer of bad news but DHCP still don't work on my 0.6 board. However, the status printout varies a bit. I have two different causes of watchdog triggers. First status message blames the platform module as the culprit. See below
[[language]] (16:48:43.802) M122 (16:48:43.938) === Diagnostics === (16:48:43.938) Used output buffers: 1 of 32 (1 max) (16:48:43.938) === Platform === (16:48:43.938) RepRapFirmware for Duet version 1.21RC1 running on Duet 0.6 (16:48:43.938) Static ram used: 44836 (16:48:43.938) Dynamic ram used: 40772 (16:48:43.938) Recycled dynamic ram: 408 (16:48:43.938) Stack ram used: 3520 current, 4316 maximum (16:48:43.938) Never used ram: 7972 (16:48:43.938) Last reset 00:00:38 ago, cause: software (16:48:43.938) Last software reset time unknown, reason: Stuck in spin loop, spinning module Platform, available RAM 8032 bytes (slot 2) (16:48:43.938) Software reset code 0x2040 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f00f, BFAR 0xe000ed38, SP 0x20087e04 (16:48:43.938) Stack: 000c0f57 00000001 fffffff1 00000001 20087e5c 20070fe8 00000001 20087e5c 000a7583 000a7e54 2100003a 00000000 0000012c 00000123 00000000 2007376c 200737a8 2007a938 00000127 2007aea8 000000f0 2007a938 01c8a8c0 2007376c (16:48:43.938) Error status: 0 (16:48:43.938) Free file entries: 10 (16:48:43.938) SD card 0 detected, interface speed: 21.0MBytes/sec (16:48:43.938) SD card longest block write time: 0.0ms (16:48:43.938) MCU temperature: min 23.7, current 25.3, max 25.5 (16:48:43.938) Date/time: 1970-01-01 00:00:00 (16:48:43.938) Slowest main loop (seconds): 0.000399; fastest: 0.000100 (16:48:43.938) === Move === (16:48:43.938) MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0 (16:48:43.938) Scheduled moves: 0, completed moves: 0 (16:48:43.938) Bed compensation in use: mesh (16:48:43.938) Bed probe heights: 0.000 0.000 0.000 0.000 0.000 (16:48:43.938) === Heat === (16:48:43.938) Bed heaters = 0, chamberHeaters = -1 -1 (16:48:43.938) Heater 1 is on, I-accum = 0.0 (16:48:43.938) === GCodes === (16:48:43.938) Segments left: 0 (16:48:43.938) Stack records: 2 allocated, 0 in use (16:48:43.938) Movement lock held by null (16:48:43.938) http is idle in state(s) 0 (16:48:43.938) telnet is idle in state(s) 0 (16:48:43.938) file is idle in state(s) 0 (16:48:43.938) serial is ready with "M122" in state(s) 0 (16:48:43.938) aux is idle in state(s) 0 (16:48:43.938) daemon is idle in state(s) 0 (16:48:43.938) queue is idle in state(s) 0 (16:48:43.938) autopause is idle in state(s) 0 (16:48:43.938) Code queue is empty. (16:48:43.938) === Network === (16:48:43.938) Free connections: 16 of 16 (16:48:43.938) Free transactions: 24 of 24 (16:48:43.938) Locked: 0, state: 2, listening: 0x0, 0x0, 0x0 (16:48:43.938)And the usual cause…
[[language]] (16:51:17.869) === Diagnostics === (16:51:17.869) Used output buffers: 1 of 32 (1 max) (16:51:17.869) === Platform === (16:51:17.869) RepRapFirmware for Duet version 1.21RC1 running on Duet 0.6 (16:51:17.869) Static ram used: 44836 (16:51:17.869) Dynamic ram used: 40772 (16:51:17.869) Recycled dynamic ram: 408 (16:51:17.869) Stack ram used: 3520 current, 4316 maximum (16:51:17.869) Never used ram: 7972 (16:51:17.869) Last reset 00:00:02 ago, cause: software (16:51:17.869) Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 8032 bytes (slot 3) (16:51:17.869) Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087e64 (16:51:17.869) Stack: 000c0f57 200711f8 fffffff9 00000000 20087ebc 20070fe8 200711f8 20087ebc 000a756d 000a7e62 21000000 2007a9ac 0000012c 00000123 00000000 2007376c 200737a8 2007a938 00000127 2007aea8 000000f0 75207369 01c8a8c0 2007376c (16:51:17.869) Error status: 0 (16:51:17.869) Free file entries: 10 (16:51:17.869) SD card 0 detected, interface speed: 21.0MBytes/sec (16:51:17.869) SD card longest block write time: 0.0ms (16:51:17.869) MCU temperature: min 25.3, current 25.5, max 25.6 (16:51:17.869) Date/time: 1970-01-01 00:00:00 (16:51:17.869) Slowest main loop (seconds): 0.000378; fastest: 0.000100 (16:51:17.869) === Move === (16:51:17.869) MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0 (16:51:17.869) Scheduled moves: 0, completed moves: 0 (16:51:17.869) Bed compensation in use: mesh (16:51:17.869) Bed probe heights: 0.000 0.000 0.000 0.000 0.000 (16:51:17.869) === Heat === (16:51:17.869) Bed heaters = 0, chamberHeaters = -1 -1 (16:51:17.869) Heater 1 is on, I-accum = 0.0 (16:51:17.869) === GCodes === (16:51:17.869) Segments left: 0 (16:51:17.869) Stack records: 2 allocated, 0 in use (16:51:17.869) Movement lock held by null (16:51:17.869) http is idle in state(s) 0 (16:51:17.869) telnet is idle in state(s) 0 (16:51:17.869) file is idle in state(s) 0 (16:51:17.869) serial is ready with "M122" in state(s) 0 (16:51:17.869) aux is idle in state(s) 0 (16:51:17.869) daemon is idle in state(s) 0 (16:51:17.869) queue is idle in state(s) 0 (16:51:17.869) autopause is idle in state(s) 0 (16:51:17.869) Code queue is empty. (16:51:17.869) === Network === (16:51:17.869) Free connections: 16 of 16 (16:51:17.869) Free transactions: 24 of 24 (16:51:17.869) Locked: 0, state: 2, listening: 0x0, 0x0, 0x0 (16:51:17.869) -
Which value(s) should it print? Perhaps the difference between the minimum and the maximum heights read?
LOL, that's a good question, I was thinking about the value that you use to decide whether to continue or to reject (not sure if it's the mean or the deviation) , but maybe the min and max are interesting values too.
-
The firmware looks for 2 consecutive readings to differ by no more than the tolerance. So perhaps the best figure to show is the lowest difference seen between consecutive readings.
-
I have just updated from 1.20 to 1.21RC1 and not sure why the mesh bed compensation shows a rectangular bed instead of a circular bed for my delta. I didn't change my config.g, maybe I missed something that I should change?
I have M558 P1 R0.4 X0 Y0 Z0 H1.5 F100 T3000 I0 in my config.g and M557 R100 S15 in my bed.g
-
The firmware looks for 2 consecutive readings to differ by no more than the tolerance. So perhaps the best figure to show is the lowest difference seen between consecutive readings.
Sounds good
-
Maybe should add: All working fine here as far as I can see on my Dual E3D BigBox. 1.21RC1 with DuetWifi 1.0 and duex5.
-
Maybe should add: All working fine here as far as I can see on my Dual E3D BigBox. 1.21RC1
Thanks for the feedback.
-
Would it make sense to use the new multi-tap feature and modify it to do e.g. 3 taps and average them?
My BLtouch has quite large variance in its probe distance. So I think taking the average of multiple points could be used to counteract this - or am I missing some important math/statistics here? -
Installed on corexy running duetwifi printing now no issues. Printed fine, also installed on delta no issues.
-
Not sure if this is a bug or that is intended, but it's something that worked differently to what I was expecting
I've noticed that G31 Z is not adjusted "live" even if I change it, I mean, I setup a Z offset (while printer is idle), then I do a mesh level (G29 S0), and I make a test print… if I stop because I want to change Z offset, that Z offset is not applied until I do a new mesh level or I restart the printer, even though the machine properties reflect the new offset.
This is not new to this RC, I noticed it during some testing I was doing several days ago, but I wasn't sure until today, when I performed a test (configure Z at -0.14, print, check, stop print, configure Z at -1.14, print, check<<same result="">>, refresh mesh, print<<1mm higher than before>>).
Regards</same>
-
You are correct, changing the G31 Z values has no effect until you probe again. To make a temporary change to Z offset, use baby stepping.
-
You are correct, changing the G31 Z values has no effect until you probe again. To make a temporary change to Z offset, use baby stepping.
Just the Z probe is required, or do I need to do the complete mesh?
-
Just finished a 30h print with 1.21RC1 on my corexy+BLTouch+single v6+Titan printer. No problems.
-
Hi, im new to the duetWifi board.
Did a update of the Firmware today.FW dirst..then Duet Wifi then the Web interfache from the page of Christian HAmmacher..Versions are now:
FW: 1.21RC1
WiFi: 1.21RC1
Web: 1.20I read something about to simulate the print but cant find anything in the Web interface…wrong version of the Interface? or something that i have to activate?
-
Hi, im new to the duetWifi board.
Did a update of the Firmware today.FW dirst..then Duet Wifi then the Web interfache from the page of Christian HAmmacher..Versions are now:
FW: 1.21RC1
WiFi: 1.21RC1
Web: 1.20I read something about to simulate the print but cant find anything in the Web interface…wrong version of the Interface? or something that i have to activate?
In the G-code file menu, navigate to the file you want to simulate. RIGHT click it. Select simulation.
-
lol..thx alot…looked for a button all day long..sometimes its can be so complicated
-
Would it make sense to use the new multi-tap feature and modify it to do e.g. 3 taps and average them?
My BLtouch has quite large variance in its probe distance. So I think taking the average of multiple points could be used to counteract this - or am I missing some important math/statistics here?My first interpretation of the function was that the "A" set the number of measured values to average and the "S" tolerance was the max allowed difference to include the measured swarm… But that would only work if you had one more parameter which is maximum retries and a smart algorithm to handle the fault cases that:
-
no number, are within the tolerances
-
some but not all, are within the tolerances
Suddenly this is not a small simple function. This is not unsolvable but will require much more work and at least for me this is a good middle way.
I really like the SMD version of the Z IR sensor you can buy on there page. Running the repeat-ability script really shows how nice this is. If the BL-touch is not as repeatable I would seriously consider changing it to something with better repeat-ability.
I think this is a good start (if not good enough), maybe this function could be improved. Especially when bed leveling, more important to be accurate than fast in my book.
Just compared a reason print to one very early in my BB life… It is amazing what i rise in quality I made since switching from Marlin to Duet. Thank for the good work.
-
-
I agree: if BLTouch doesn't give reproducible results, don't use it. Or find a slower probing speed or harder bed surface or a better make (if you are using a clone) or whatever it takes to get consistent readings from it. Trying to use a Z probe that doesn't give sufficiently consistent results when you probe the same point repeatedly is a waste of time. Except that if it's only the first probe after deployment that is out, you can do a dummy probe after deployment or use the multi-cap functionality to allow for that.
However, as there is currently no mechanism to abort G32 bed probing and whatever may have called it if probing fails, I'll probably change the next RC firmware version to print a warning but take the average of all readings, if the maximum count was reached without being within the tolerance.
-
I've been noticing some oddities with bed leveling, even before this release.
I run compensation, and average level is above 0, run it again, it's below, run it again, it's above, etc. It's like it's using old values every time it runs. I tracked this down and fixed it with G29 S2 at the top of bed.g, but shouldn't bed leveling disregard old values anyway?
also great work w/ the new bed leveling averaging. Going to test the pressure advance stuff for stupid slicers now. I've been harassing simplify3d to fix their broken g-code, but they're dense.
