Posts made by littlehobbyshop

@t3p3tony for me, per drive would be best independent of the mix ratio. I think retraction as per the mix ratio doesn't really allow for difference in material properties that would affect retraction.

I'm mixing a paste with a pigment. So I have the paste in a large syringe and it has a very different viscosity to the pigment. The pigment is in a much smaller syringe and I would want to avoid retracting that more than absolutely necessary so that I'm not pulling paste up into the pigment. I hope that adds some context.

@jay_s_uk I'm aware of that. As per the title I have multiple extruders on a single tool for mixing using M567 mix ratios.

It would be great to have independent control of retraction of each extruder on a tool. My application for this is a mixing paste extruder. My extruders have very different characteristics and could really do with different retraction settings, looking through the documentation before the build this appeared to be possible but I obviously misread/misunderstood.

In the object model "retraction" seems to belong to the tool rather than the extruder which I find a bit odd as it is a movement exclusive to an extruder.

So I'd really like to be able to use something like the following

M207 P0 S0.5:0.8 F600:120 Z0:0.5

OK, so have quickly checked on the Duet2 Wifi. Same behaviour.

I did find this reference https://forum.duet3d.com/post/265794
Where the M200 behaviour is described as resetting to linear extrusion when a print file starts. I did another check with a macro and found that M200 volumetric extrusion only lives as long as the macro itself. It's unexpected behaviour tbh but appears to be deliberate and the same is being applied to the tool change macros.

Macro looked like this:
M200 D1.75
M200

Which resulted in this console output, the first M200 being manually sent via the web console.

I'm not able to test yet but it would seem if you're wanting to run a volumetric extrusion job and have tool changes, you might have to call M200 after each tool change? Or perhaps it persists because the tool change is being called as a "sub macro" of the print file? I don't know, if it's documented somewhere I can't find it.

This behaviour needs documenting in the GCODE Dictionary really. Since the move to WikiJS I'm not sure how to contribute.

@jay_s_uk I have a Duet2 Wifi machine so will check on there also, also running 3.3. Might be helpful, should've thunk of that earlier! Will move to the discord if it's not a problem on the Duet board.

@jay_s_uk OK, I might give it a try this weekend but there's no changes listed to M200 in the changelog

@jay_s_uk Thanks I did check that yesterday and considered it but it's still listed as an unstable build and I'm mid build on this slightly experimental machine so was a bit wary of throwing possible firmware problem shenanigans into the mix.

I'm going to have to update soon though I'm going to need the tool independent retraction update to M207.

@phaedrux Sorry, missing the basics. I'm on 3.3 at the moment, due to it being the STM32 version from TeamGloomy running on a BigTreeTech GTR. Latest release from them. It's a self build paste extruding machine (syringes).

M200 is applying when run within a macro or from config.g. So far it seems only the tool change files are the issue.

I am trying to set filament diameter in either tpre or tpost files. Neither actually sets the filament diameter and sets volumetric extrusion. When I run the same command in the web console, it applies just fine?

@thekm That script is fantastic! Works a treat for me. Please create a post of it's own if you haven't already.

Edit: Oh you already did. Very nicely done!

@oliof Ah OK, that makes sense. I need to look into the procedure closer. More than that I should really just grab an accelerometer and give it a go!

@oliof That's exactly my point. The accelerometer will pick up that movement whether it affects the print or not and potentially make a mess of the input shaping calculation.

Edit: An extreme example: A printer hanging from a rope and swinging like a pendulum.
That swinging motion will be detected by lone accelerometer and end up included in any calculations intended for input shaping despite that pendulous motion having no bearing on the print head moving across the print surface. To compensate we would need to measure the pendulous motion separately and compensate for it by subtracting it from the acceleration measured at the print head while it's moving. IMO we ideally want to measure the motion of the print head relative to the print surface, not the print head alone in space.

Would accounting for printer chassis movement give better results for accelerometer based input shaping?

I ask this having only followed the conversation on input shaping, I don't have an accelerometer yet but am planning on getting one and giving input shaping a go. So if I've overlooked something, please forgive and move on with your day.

It seems to me that the current method of mounting an accelerometer to the print head covers the machine as a whole at the print head. I would think what's more important is the movement of the head vs the printer frame or more specifically the bed.

My printer definitely moves and vibrates whilst printing, and I deliberately allow it to. I don't want to pin the printer down solid and have all those vibrations transfer to my workbench which works wonderfully as an amplifier. So, the whole machine is moving by the amount measured by an accelerometer at the head. Would it not be better to take measurements both at the head and on the bed then deduct the former from the latter to get the difference?

I would still think this important on both fixed and moving bed machines where I suspect the total vibrations of the machine may change measurably with z height regardless of whether it's the bed or print head that moves in Z. I'm curious about opinions.

I've only just discovered this and it works great, however the M564 command at the end needs to be changed to

M564 S1 H1

Otherwise the printer can still be moved outside of the axis.

@chrishamm This seems a great step forward in bringing plugins together for visibility. Am I right in thinking developers will be encouraged to merge their plugins to this repo?

Adding to what @3dML said...

This macro has been tested and works nicely, change tool no./layer height/increment value to suit. It also covers the case where you want to start from a value other than 0, simply change the first M572 parameter.

;Increase pressure advance by 0.005 every 5 layers
if job.layer == 0
	M572 D0 S0 ; starting value
	echo "Layer " ^ job.layer ^ " started"
	echo "Pressure advance reset to " ^ {move.extruders[0].pressureAdvance + 0.000}
elif mod(job.layer, 5) == 0 ; no. of layers
	M572 D0 S{move.extruders[0].pressureAdvance + 0.005} ; increment
	echo "Layer " ^ job.layer ^ " started"
	echo "Pressure advance = " ^ {move.extruders[0].pressureAdvance + 0.000}

Interestingly the "+ 0.000" is required to force the console to print 3 decimal places, otherwise it rounds down to 2.

Take a look at this: https://github.com/DanalEstes/MultiDuetWebMonitor

This and other community projects here: https://duet3d.dozuki.com/c/Community_Projects

Updated today to include relative extrusion which is not available elsewhere in the UI or apparently in any other post processor.

Just a sanity check on whether the nozzle diameter set by M404 is available in the object model before I raise a request issue on Github. I had a good dig but couldn't find it.

Having that available would be incredibly useful for setting movement/extrusion behaviours for different nozzles:
if nozzle diameter = 0.4;
set pressure advance to this
else if nozzle diameter is 1.2;
set pressure advance to this
etc.

I would handle a nozzle change by manually changing M404 in the tool post file.

Whilst on my browsing of the object model I noticed that filament was under the move.extruders node, I think this makes more sense under the tools node as it's not movement related.

Conversely, retraction is under the tools node but perhaps should be under the move.extruders node as it is extruder movement related. I'm not sure what the determining factors for the location of these parameters is.