Best posts made by NexxCat

@deckingman I mean no disrespect to you by what I'm about to say, honestly. I've found much of your blog content, posts here and YouTube videos to be interesting and informative, and on one hand I understand your frustration, it is in part of your own making.

Your printer is very advanced, easily one of the most complex CoreXY builds I certainly have ever seen, but if it being in a state is such an issue, why not simply revert back to using the Duet 2 + Duex + RRF2 where it all worked? You spend a lot of time here lambasting @dc42 and the other developers, but from your own admission, everything worked to your satisfaction with the older hardware, no?

I have seen you say multiple times on your own videos that you refuse to try beta or RC firmware, and yet complain when things don't work for you. Problems cannot be found and fixed without assistance from those who suffer from the issues. An issue which isn't reproduceable for a developer is almost impossible to fix, and I say this with a software development background.

Again, if your printer has to be working, why would you have changed from the working electronics? Why not change back to those after all of the issues? I don't understand the your mentality of "it must work the way I want it, even if there is another way that DOES work".

Maybe it's just me, but it's saddening to see the constant attacks from you towards the Duet developers I'm truly sorry if you feel I am attacking you, or your character, but I'm just sharing an opinion from an outside perspective with no bias towards either side.

Just wanted to post an update to this.

Spent today replacing all 12 mini V-wheels on my Predator. I can safely say I found the cause of the noise...

Eight out of the twelve wheels I removed had bearings which were severely grating. I determined this by removing the belts from the steppers and being surprised at the noise of the delta tower carriages moving on their own. All of the wheels have been replaced with genuine OpenBuilds Mini-V delrin wheels. I opted for those over the poly-carbonate as they're generally considered better for non-heavy duty applications.

After getting everything back together, my printer is now much quieter. I've also lowered the currents on all 3 axes down to 1600mA. This still seems more than enough, but more time and tweaking will tell.

Before the change, moving the Z faster than 200mm/s would make unbearable noise. I've now tested it up to 400mm/s (with significantly lowered current to prevent back-EMF) and all is A-OK.

Thanks to everyone for your thoughts and help. Hopefully this post will help others in the future

There's a lot of negativity aimed towards the devs here. I just wanted to say that any time I've had an issue, the community and people like @dc42 and @T3P3Tony have always helped as best they could. No-one knows everything and no-one can be expected to filter through a huge forum and constantly keep track of every bug. Any time I've reported, or seen reported by others, a wide spread problem, it has been investigated and fixed very promptly, far faster than you get from 99% of companies out there.

I used to be a software developer. You can't always replicate a problem right away, and in general if you can't replicate it you can't fix it. That makes the people affected mad, of course, but most times those people are experiencing edge case problems with atypical setups.

You can't honestly expect the devs to have a Duet powered printer on hand for every type of kinematic the firmware supports, especially when you then add the myriad of different supporting electronics into the mix.

When it affects you, I know it feels like your problem is being ignored, but software development isn't easy at the best of times, let alone embedded development of something this complex.

Have you checked that the probe is actually returning repeatable values?

Create a macro with the following in it:

G28
G30 P0 X0 Y0 Z-9999
G30 P1 X0 Y0 Z-9999
G30 P2 X0 Y0 Z-9999
G30 P3 X0 Y0 Z-9999
G30 P4 X0 Y0 Z-9999
G30 P5 X0 Y0 Z-9999
G30 P6 X0 Y0 Z-9999
G30 P7 X0 Y0 Z-9999
G30 P8 X0 Y0 Z-9999
G30 P9 X0 Y0 Z-9999 S-1

What does the console report after the macro runs?

Wouldn't you just need to do the following?

G0 X{move.axes[0].userPosition/2}

Sorry, kinda off topic, but just put 2+2 together and realised @brotherchris was Chris Riley. Love your videos, keep up the fab work

@Carlo
Ok, set that in your config. Then create the bed mesh with G29 S0. Once the mesh is complete, try to print the levelling model.

I know you've done this so many times before, but let's try now we know the nozzle positioning is correct ok? Use the level_test.gcode I have you before, because I know it doesn't have anything in it to mess with the settings.

@Carlo
I can't remember offhand which way to adjust the offset to bring it closer, but try both of these, one will certainly be too high, but the other, does that give you a 0.1mm gap when running the macro I posted?

G31 P100 X0 Y0 Z-0.059

G31 P100 X0 Y0 Z-0.259

@Carlo
Ok, last thing I can think of, just to double check if the actual positioning is being repeatable. Run these commands one at a time, or save it as a macro:

; Disable any baby-stepping and the bed mesh
M290 R0 S0
G29 S2

; Home the effector
G28

; Heat bed to 60C & nozzle to 130C
M104 S130 T0
M190 S60 T0
M109 S130 T0

; Run delta calibration
G32

; Move the effector to 0,0,Max height
G1 X0 Y0 F4500
G1 Z500 F4500

; Move the effector back to 10mm off the bed
G1 Z10 F4500

; Slowly move down to 0.1mm
G1 Z0.1 F600

When the macro is finished, the nozzle is at 0.1 on the Z axis. Use the paper or a 0.1mm feeler gauge and see if the nozzle truly is at 0.1mm