New beta firmware 1.20beta8
-
Any thoughts on the probing issue DC? I only ask as the difference in results between firmware versions is so stark there has to be something going on? I've replicated that now on two different machines.
Thanks for the reminder. I've made a note to look at it next week.
-
Just installed the 1.20beta8+1 and noticed right away that while printing my always on fan for my hot end is no longer always on. As the hot end moves, it revs up and down. The only change made to the printer was to update the firmware.
-
I worked the issue and determined it was a break in the fan connector or wiring somewhere that happened at the same time I updated the firmware. Checked further and found a broken ground wire at the board connector for the hot end fan.
-
Question about the stall detection (I'm still in 1.19, so this is a theoretical question, not a bug report). I'm having issues since couple of prints ago with motors loosing steps, and of course, layer shifting. This is not happening always though. My suspect is that X carriage bushings has a problem, but I wasn't able to reproduce it, as it only happens from time to time.
Yesterday I was executing the mesh bed levelling, and I heard how the X carriage was stuck, and it checked twice the same point, assuming that it moved… Anyway, here my question, if the stall detection is enabled, and for any reason some steps are missed during the mesh bed levelling... what happens? is the procedure cancelled? it will home again and continue?
Regards
-
Currently, stall detection will only pause or rehome when you are printing from SD card.
-
Currently, stall detection will only pause or rehome when you are printing from SD card.
Ok, thanks
-
Any thoughts on the probing issue DC? I only ask as the difference in results between firmware versions is so stark there has to be something going on? I've replicated that now on two different machines.
I just ran your file on my delta with the smart effector, and I added the results in a new column on your sheet. Looks OK to me. Probing speed is 1000mm/min, which is 16.7mm/sec or 16.7um/millisec. As the Z probe is only sampled once per millisecond, a range of commonly 15us and occasionally just over that is to be expected.
I am running a later build than 1.20b8+1, so things may have changed.
-
Thanks for having a look David. And for appending the results. For now if I am using my corexy as a sensor test rig then I'll just flash 1.19 temporarily. I'll test with whatever the latest edge build is and see if the behaviour changes when they're released.
-
btw in the next 1.20 beta there will be a new Z probe type 8, which is the same as type 5 without filtering, so faster response (no 1ms sampling). I've just tested it with your file again:
x16 microstepping, F1000: 25 instances of -0.166mm, 5 instances of -0.171mm
x32 microstepping, F1000: 1 instance of -0.158, 2 instances of -0.166, remainder -0.161 or -0.163.If you want to try this version, the Duet WiFi build is at https://www.dropbox.com/s/tr3be3v9o5iqxxa/DuetWiFiFirmware.bin?dl=0.
-
Thanks I will try it now, that sounds right up my street.
-
Probing is much more accurate now, thanks David this really helps, now that z-probes are a whole new league more accurate than before.
Did have one heavy contact on kossel XL during autocal, just wanted to see if this more precise probing improves calibration, oddly it doesn't seem to make any difference (just goes to show we're getting more into the "physics" of these sensors, not the engineering, they're plenty accurate for 3D printing). Its quite reassuring from a sensor accuracy point of view that the calibration doesn't improve once you reach a certain level of accuracy, as the mechanics are not changing and the sensors are accurate enough.
I'll try a few more (with lower motor current) and just see if it happens again. Interestingly my hotend temp shot up to 51 deg C when it crashed the bed, a wire had come loose.
I'm finding my results at 1/32 less accurate than at 1/16th with interpolation.
-
would Z probe type 8 also affect piezo probing?
-
-
If by affect you mean possibly make it appear more accurate then yes.
It's very interesting using RRF when doing probing tests usually you will see the minimum unit is 0.005mm/5microns. I think raising your microstepping above 1/16 will reduce this minimum unit. But when you are looking at a device with accuracy around 10-15 microns, but each micostep is (at 200steps/mm) just 5 microns, and only the best machines can be expected to actually move (or stop) on one single microstep, then, to be honest, the validity of comparison is limited at best.
This change removes ?some/all of the signal processing, sharpening up the response to the probe triggering, and in theory increasing the accuracy. As I said above the fact that my delta doesn't suddenly start calibrating more accurately confirms that with piezo probes and smart effectors, both very precise systems, you really are measuring your machine's abilities, its frame rigidity, the smoothness of its linear motion components, the stiffness of carriages, axes, and beds etc, not the accuracy of the probe.
I tested my corexy with this new firmware using direct electrical contact an got 10 microns range (using 1/16th microstepping) and 3 microns std deviation. With our prototype Piezo20 V2 unit that we are working on at present, we get 15 microns range and 4 microns deviation. So the probes are affecting the accuracy by 5 microns compared to electrical contact which should in theory be as good as it gets.
Given that a 1st layer might be at most extreme 100 microns, but more than likely 200-300 microns, the effect of 5 microns either way when probing will undetectable in terms of printing (or bed leveling/grid levelling/calibration).
-
Could Z probe type 8 also be beneficial for BLTouch users?
The short pulse of the BLTouch that gets sent is already logic-level - so no filtering should be necessary AFAIK. -
I'd love to see some detailed results from BL touch, both with P8 and without, at varying probe speeds, with varying microstepping. Does the Bltouch deploy and retract for each probing dive, or just once at the start and end of probing?
The reason why I ask is that my hypothesis is that most systems with a deploy/retract, suffer poor repeatability between sessions as they fail to re-deploy at exactly the same height each time. Th exception being the systems using optical endstops/IR boards above fixed above deployable metal probes since the metal probe is fixed length and the opto sensor is fixed to the print head, in theory, although they have to deploy/stow there is no repeatability issue. They are still often offset from the nozzle though.
-
I'm happy to give it a try on the weekend with my BLTouch-clone on a corexy.
Well, re-deploy is the whole point of a BLTouch. The little pin drops down. The bed hits it and pushes it back up, until the hall-effect sensor or whatever detects it. Then it fires the trigger signal and re-deploys (drops down the pin) by itself.
If I understand the inner workings correctly, the height to which the pin drops down is not crucial. The point at which it detects that it is back up is important. -
That should make it more accurate and repeatable, but I've not heard great things, 50microns accuracy is the number I've heard from people. Now that is going to make a difference. I am sure you can tell the difference in your first layer between one babystep up and down, thats 50 microns.
Looking forward to your results.
