Posts made by ardenpm

Does your slicer have a place you can enter code during a retraction? Some of them do.

@fcwilt I don't believe PrusaSlicer has custom G-code for retraction.

That would solve the speed problem as you could set the extruder speed to the max for extrusion and in the retraction handler up the speed during retraction and then put it back to normal.

I don't really see doing the above as too big a problem in any case since it's only for these specific priming moves which already have a fairly large amount of Gcode scripting around them, so it's just a few extra lines.

If B and E are not kept in sync how do you see that working? Would E just continue to run after B is done?

@fcwilt That's actually the issue, it does attempt to keep them in sync and it thinks on the extruder side it has enough headroom to run it all the way up to my configured maximum speed of 3600mm/m for extruders, where as my extruders can handle more like only 300mm/m without skipping.

The reason the extruders are configured to allow a speed much higher than they can actually extrude is because of retractions, which happen at a much faster speed than extrusions. So by limiting the extruder temporarily to the limit for practical extrusion it should force the movement axis to slow down further to say in sync.

@deckingman I prefer to restore the feedrates to their previous value rather than a hard coded value when done so if I change my configuration I don't need to hunt for values in my different macros. However that should be pretty straight forward, something like this.

var defaultSpeed0 = move.extruders[0].speed
var defaultSpeed1 = move.extruders[1].speed
var defaultSpeed2 = move.extruders[2].speed
var defaultSpeed3 = move.extruders[3].speed

M203 E{param.F}
G1 B{param.B} E{param.B} F{param.F}
M203 E{var.defaultSpeed0}:{var.defaultSpeed1}:{var.defaultSpeed2}:{var.defaultSpeed3}

Which is definitely still simpler than the first macro I had there. Definitely lots of ways to skin this particular cat.

@gloomyandy It is in DWC, however the console output approach above is just to simplify it for the reproduction case so it could be run without having to move or print. In the real case where I encountered the issue there were moves and extrusion so it was pretty obvious it had stopped since nothing was moving or extruding.

@deckingman Yes, that’s true I could also do that. I’ll need to use the object model to find the current tool to apply it to the right extruder motor so that should be possible. I haven’t confirmed that limiting the extruder instead of the movement axis has the same affect but I would assume it must. I would still set the limit of the extruder though to the feedrate I actually want since otherwise it would just always run at 300 (I have multiple steps at different feedrates in my case). But limiting the extruder is simpler and shouldn’t hit the other minimum speed issue. I’ll definitely give that a go.

@deckingman Excellent question. Could the minimum feedrate be referring to the "tool" rather than the individual axes?

@gloomyandy No, because I don't want to limit the E axis to that feedrate, I want it to run at the specified rate but the B axis much slower than normal. Without this the E axis will run up to its limit to try and sync with the short B axis move time. Without doing this I need to slow down the E axis too much.

So putting this together now that it is clear what's going on, I'm using a small macro which takes the same B, E and F parameters as my G1 calls but computes the feedrate limit for me, changes it then sets it back to the original value. This seems to be working well and I can now do a nice smooth drop of my priming platform while extruding at the needed rate. Obviously fairly specific to my use case but in case it's helpful to anyone else here it is.

var defaultSpeed = move.axes[4].speed
var extrusionTimeMinutes = param.E / param.F
var newSpeed = abs(param.B - move.axes[4].userPosition) / var.extrusionTimeMinutes
echo {var.newSpeed},{move.axes[4].userPosition},{param.B}
if var.newSpeed < var.defaultSpeed
  M203 B{var.newSpeed}
  G1 B{param.B} E{param.E} F{param.F}
  M203 B{var.defaultSpeed}
else
  G1 B{param.B} E{param.E} F{param.F}

Thanks all for the lively discussion.

I'm having an issue with some Gcode scripts I have setup which are calling each other but stopping execution for no apparent reason with no errors. I believe it can be reproduced with the following:

test_a.g

if true
  echo "Yes"
else
  echo "No"

test_b.g

if true
  M98 P"test_a.g"
  M98 P"test_a.g"
  M98 P"test_a.g"

If I then run:

M98 P"test_b.g"

I get only a single "Yes" printed to the console. If I edit test_a.g to be:

if true
  echo "Yes"
else
  echo "No"
echo "Done"

I get then then expected three "Yes" strings output (and of course three "Done" strings as well). The above example is a cut down minimal reproduction case from a much more complex script.

Note that in test_b.g, if the M98 calls are not inside an if clause then they do work as expected. So it appears to be something to do with the nesting of the if statements across nested macro calls.

The absence or presents of a final newline has no effect on the issue. Note also the failure is silent, there are no errors it just stops executing code.

I'm on RRF3.4.1, not sure if this is definitely a bug and whether I should file it on Github or not so hoping for a sanity check here.

@deckingman From my tests it does appear to default to 30mm/m per the documentation, however it can be changed by the user so to be generic I'd like to be able to query the current value to be able to restore it. For my specific case of course I know if I have changed it so can live without it but would be nice to have when writing things that someone might use on another machine.

When I tried to do a move slower than 30mm/m it definitely did not behave as expected until I issued an M203 Innn low enough. So for example if I just did G1 X10 F1 I'd expect it to take around 10 minutes, but it actually takes about 20 seconds, once I lower the minimum feedrate to 1 as well it takes the expected amount of time. I also don't really see the reason for the default minimum overall feedrate being 30mm/m, though I think Marlin has something similar from memory.

Is there a way to find the minimum and maximum feedrates for a given axis?

I took a look through the document model and for maximum feedrates it looks like I can use move.axes[].speed which is great. However for the minimum feedrate set by M203 I30 for example, I don't see a way to find the current value for this so I could fetch it into a variable.

The minimum feedrate is shared by all axes I believe so wouldn't be in the per axis information but I don't find it anywhere else in the object model and don't see a Gcode to query it.

My use case is that I want to temporarily limit the feedrate of an axis and that might require me to temporarily also change the minimum feedrate to make it slow enough. When done I want to restore them to the previous values so I want to store the current ones first.

No, I'm not assuming anything. I had a similar query regarding the speeds of my UVA and B axis which run concurrently with X and Y but not necessarily over the same distances. This is how it was explained to me by @DC42 and he writes the firmware so he should know.

Great, that is what I was trying to ask (perhaps clumsily), I wasn't sure if this was known expected behaviour of the firmware or what you were trying to deduce from my explanation of what I was seeing (which could have meant a bug). Obviously if David says that's how it works, then that's how it works.

However I need to calculate the expected time of the extrusion move, determine how slow to limit the movement axis to to make it take the same time and then limit its feedrate (then restore it afterwards).

I've already told you how to that.

Yes, and that's exactly what I used to do it, which was a very helpful idea (I just threw together a spreadsheet to do it by hand but should be able to put that into Gcode pretty easily as well). I only now had the opportunity to test it out. It also took me a few read throughs to fully grasp what was being proposed. I was just reiterating that what is needed is possible but requires some of the juggling you mentioned.

But hey, if you don't want to believe what I say, that's fine. I just wish I hadn't wasted so much of my time trying to help....

I'm not sure what gave that impression, your explanation and idea were definitely of help and appreciated.

@gloomyandy Mmm, this adds to the confusion for me since that description matches what my original assumption was:

Moves with a nonzero X, Y, or Z component: the feedrate is an ideal, desired speed in 3 dimensions, possibly limited by the max feedrates of each axis (including E) individually, as well as their acceleration profiles.

Specifically they say it is limited by the max feedrates of each axis, including the extruder. Though I guess since I am commanding it to move at a feedrate that is below all axes limits the moves are not limited at all, so the extruder is running up to its 3600mm/m limit. That lines up with what @deckingman was assuming as well.

In some testing now I can see if I artificially limit my movement axis speed limit the extruder can then keep up then I'm able to get a smooth axis movement over the length of the extrusion. However I need to calculate the expected time of the extrusion move, determine how slow to limit the movement axis to to make it take the same time and then limit its feedrate (then restore it afterwards). This does seem to work though.

@deckingman Yes I understand your description but my understanding was that is what you were assuming what is happening rather than what is intended to happen. To me it is surprising that the extruder limits are overridden by the axis limits, to me that is a fundamental property of G1 that should be describe somewhere (if it isn't already).

Testing just now I think what I am definitely seeing is the extruder racing up to its limits in order to try and match the movement axes, exactly as @deckingman describes. To me this seems counterintuitive and I would have expected the slowest axis to dictate the movement regardless of whether it is the extruder.

On review I am also seeing some skipping at 480mm/m which I didn't notice before so I'll probably cap that at 300mm/m, though even at that speed the axes are two far out of sync to stop the extruder racing away.

One option might be to reduce the maximum speed on the B axis temporarily in my prime Gcode to prevent this, I guess I can work out how much time the extruder needs to properly extrude the amount of filament I want then work out the fastest I can allow that axis to move while covering the distance needed.

@tfjield looks like you are correct, I just dropped minimum down with M203 I1 and did a move of 1mm and that now takes around a minute as expected instead of 2 seconds. So if G1 was working how I originally though (which it seems it is not) then it would have only been able to slow the axis to 30mm/m at the most, which is still pretty slow but no where near slow enough to extrude 50mm of filament.

I'm glad I'm not going crazy and that what goes on behind a G1 is actually more complex that it first seems, enough to provoke some discussion.

@tfjield I believe the G1 feedrate cap only applies to CNC mode doesn't it, i.e., if you have issued an M453 to switch to CNC mode? That should not affect the Duet if in regular 3D printing mode.

@deckingman to answer your question G1 E50 F3600 will absolutely grind filament. However extruder feedrate maximums are often set much higher than the maximum printable feedrate so that a higher rate can be used during retraction, which isn't subject to the same pushing plastic limitations. I don't recall if there is a seperate retraction limit that can be set somewhere.

8mm/s is doable on a Hemera with a 0.4mm nozzle, though probably not across a whole print, for priming into air it does fine though, much higher will have issues in my experience.

My (possibly incorrect) assumption was that in a G1 move, the movements of the axes would need to be slowed down to accommodate the slowest of any axis (including the extruder) and not just the movement axes. If this is not the case then it would explain why the short travel move forces the extruder to go faster, though I do not believe it is reaching 3600mm/m as that would make a huge honking noise and mess as it grinds away.

I think it comes down to the fundamental question, what is the expected behaviour of G1 when the extruder is commanded to move a distance that is greater than the movement axes with such a feedrate that the axes move would complete prior to the extruder move if not slowed down.

To my thinking this issue could come up when using a very wide extrusion width with a large nozzle as well, though I haven't looked at that. I guess in those cases you're probably printing more slowly (in movement speed, of course volumetric flow would be higher) anyway.

More testing to come though. I'll switch to pure tests in air over the bed and the X-axis just to remove some more variables.

Of course, in the end, for my use case I can just slow down, priming at 250mm/m instead of 480mm/m is going to make no real difference, however I do want to get to the bottom of what is happening just for my own understanding.

@deckingman I will do some further experiments tomorrow when back at my printer. I have all direct drive Hemera extruders, thsoe under test do have 0.4mm nozzles however I haven't had any issues extruding that amount of filament at 480mm/m into free air when not including the other axis in the movement. I will try this again to double check though. Unfortunately since it's not a bowden I can't easily take the hotend out of the equation. I will say though that when the Hemera skips steps, it's usually fairly obvious. I could temporarily connect a bowden to that axis to be sure of course.

@fcwilt I can certainly test on U, though if it does the same thing with the X axis it seems unlikely that would make a difference. It's a bit of a pain to switch over given all of the config but will test.

@tfjield @deckingman Yes, correct, it's on a DuetX5 which is why the high motor number. Relative positioning is not really appropriate for my use case since I would then need to track the current position between tool changes due to differing tool heights. It's not an issue to keep track of with absolute since the tool change scripts are always moving the axis back to the same position and offsets are then used between tools.

Full configuration is attached below.

config.g

At least I think I am doing that right. This is how my B-axis is defined:

M584 B9 R0 S0

@fcwilt I configured B as a linear axis already though and as mentioned I can reproduce on X so I don't believe that is the issue. Was definitely one of my first thoughts as well.

I have a small purging platform on my B axis which I want to move down by about 1-2mm during the time I am extruding over the top of it. So I might have a command like this (let's say B is at 44 and E is relative as usual):

G1 B42 E50 F480

I would expect this to pull in 50mm of filament over the time it takes for the B axis to move from 44mm to 42mm, however I am seeing significantly less than this being pulled in by the extruder (and I am not skipping steps). The feedrate requested is well below the limit of both the B axis and the extruder. If I slow it down with:

G1 B42 E50 F250

Then the extruder pulls in about the correct amount. I can reproduce the same type of behaviour with just the normal X axis extruding into air so it doesn't seem to be specific to my B axis.

It's obviously an unusual amount of filament to extrude with such a small change in axis position however this is for a purge and is exactly what I need to be doing. Is there are setting somewhere that is imposing a limit I'm not aware of?

My guess is I am also fundamentally misunderstanding something about how G1 moves are made. I would have thought, if I am positioned at X0 Y0 and call G1 X10 F1 the extruder would move at a maximum of 1mm/m so the move should take at least 10 minutes (likely longer due to acceleration etc). However the moves are much faster than that, it is of course very slow but doesn't take anywhere near minutes to complete).

What I'm trying to achieve is moving my B axis through that 2mm in about the time it takes to extrude 50mm of filament at an extrusion rate which would be reasonable for my extruder. Right now I am having to fake this somewhat by moving the E and B axis independently a bit at a time due to the above issue.

I'm on RRF 3.4.1 and I haven't configured pressure advance so that shouldn't be affecting it (I assume it defaults to being off).