@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

@t3p3tony Sorry to intrude, but does the Driver 0 TMC2209 look odd to you? Looking at 2 separate photos, the text line above GERMANY looks odd on that one driver.

@egon-net Thanks I'll hold off for now then, but great work on the product!

@egon-net Out of interest. What would the cost be per board, delivered to the UK? Do you think they could be assembled with a fine tipped soldering iron, or only hot air?

@dc42 said in Is non-linear extrusion worth bothering with?:

@nexxcat said in Is non-linear extrusion worth bothering with?:

From my data and tests, I see a maximum of 2% under-extrusion when really pushing the filament, but by that point the quality of the plastic coming out of the nozzle has degraded greatly. By the time I see 4-5% under-extrusion, the BMG extruder is skipping.

IMO, 2% under extrusion at the maximum flow rate you want to use is not worth worrying about. If it was 10%, then nonlinear extrusion might provide some benefit.

It seems likely to me that dual-drive extruders may exhibit less nonlinearity than single drive extruders.

Yeah, that pretty much matches my data, but thank you for taking the time to give your thoughts @dc42, I know you are very busy

@droftarts said in Is non-linear extrusion worth bothering with?:

@nexxcat the guy who designed the Orbiter extruder did some volumetric flow tests with different filaments at different speeds. See halfway down the page, here: https://www.thingiverse.com/thing:4725897

Ian

That is a super useful link. Thank you very much @droftarts. Again, it matches my data, so I know what I've done is correct!

@phaedrux Thank you, that's kind of what I figured from the data I got when calculating maximum volumetric flow.

Appreciate the input, I'll drop the idea of adding it

Quick question for anyone who feels like chipping in their thoughts

I'm working on a project which currently can do the following:

• Full automatic calibration of an extruder steps/mm value
• Check for extruder consistency
• Calculate the maximum volumetric flow for the hot end

This is all achieved using a small piece of hardware I've designed (and which will all be open source when it's done), plus a GUI application written in Python and Qt.

One person said that is would be an excellent tool for calibrating non-linear extrusion, and adding it wouldn't be too difficult (once I get my head around the formula), but it seems no firmware other than RRF supports the feature. Further, it doesn't seem very well documented on how to calculate the A, B & L values from a given set of data (feed rate vs over / under extrusion).

From my data and tests, I see a maximum of 2% under-extrusion when really pushing the filament, but by that point the quality of the plastic coming out of the nozzle has degraded greatly. By the time I see 4-5% under-extrusion, the BMG extruder is skipping.

Do people still use it? Is it one of those features that RRF will eventually drop for extra code space?

Thanks for reading!
Simon

@r123 said in macros in Simplify3d:

@nexxcat ah, then I should be giving my macros a ".g" extension in the name which also appears in DWC?

so call mine "Dock_Wipe.g" in DWC?

It's worth a try

@r123 said in macros in Simplify3d:

@nexxcat and you have added a ".g" to the filename. When I tried that in DWC it didn't accept it? So is the syntax different when sending from the slicer?

Not sure why DWC wouldn't accept that. All my macros have a .g extension.

Here is my full start gcode from S3D, if that helps

G28					; Home all
M190 R[bed0_temperature] 		; Heat the bed to temperature
G4 S60					; Sleep for 60s to allow heat soak
M290 R0 S0				; Reset baby-stepping to 0
G32					; Level the bed
G28 Z					; Re-home Z
G29 S0					; Probe the bed
G1 X-100 Y-100				; Move XY back to home
G10 P0 S[extruder0_temperature] R160	; Heat nozzle to print temperature
M116					; Wait until temperatures are reached
M98 P"0:/macros/prime_nozzle.g"		; Run nozzle prime macro

@r123 Simplify3D uses commas as a newline character when storing the profile and in the gcode header. Those should be fine.

I'm running a macro in my S3D start gcode using the following syntax:

M98 P"0:/macros/prime_nozzle.g"		; Run nozzle prime macro

Perhaps try removing the spaces from the macro file name?

@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.