Topics created by Joel

@OwenD

That's easy enough to say, the change lists are sometimes quite long. Unless you have something in mind or it happens to pop in your head while "browsing" through those lists that something might affect you...

Basically, you don't know, what you don't know.

In any case, your pointer was right and I was able to sort it out.

Thanks!

@Joel said in M501 stays busy, 3.5.1:

@Phaedrux

OK, but it still leaves open what changed? Is there an issue with file handling?

3.5 is a very large update to RRF, particularly with multiple gcode streams, so I'm not surprised that some things will behave a bit differently. @dc42 would have to advise on what exactly may have changed here.

I think I found my issue,

In my Z-offset routine, when I was restoring the probe type, I did not restore the Z trigger height.

Once I fixed the G31 command, the height map works as expected.

@T3P3Tony

I think I'm actually OK with it working the way it does. I moved my build surface back so the far edge is at the end stop. I then gave myself some overhang at the front. Now when I start a print I move the nozzle off the build surface at the front and prime. When I start the print, any ooz gets sliced off.

Thanks For the help

@dc42

I'll take a look

@Joel said in Bed leveling driving tool beyond limits:

Though I'm curious it would still try to move beyond the limits.

See the "Caution" here: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#description

I do mean the Duet 3 main board 6HC. I will look at the methods suggested.

Thanks
Joel

@Joel I suspect the plugins take a long time to load. I have plans to load them asynchronously in 3.5, but the issue isn't as significant there because the plugin sizes have been reduced quite a bit since 3.4 anyway.

@phaedrux

That's the thing, it did not trigger at the last point. It flagged the error, but it should have moved the table away from the nozzle before going to its homing point and not assumed anything about where the nozzle was.

@phaedrux

yes, is still present in 3.4 beta

Here are the files

homez.g
homey.g
homex.g
homeall.g
config-override.g
config.g
bed.g

@phaedrux

I did do the macro thing, I don't recall if I did all the steps as described by DC42 ( missing step would have been the M588 S"*".

Using DWC I did everything except the M588 S"*", I should have tried it but was thinking I would get disconnected.

In panel due, yes, I had to break it up because of line length.

Hopefully if this ever comes up for me again, I remember what I learned here.

The routine does not use the probe to measure. In the routine, I move the Z axis to get the nozzle to table clearance I want and set that to be the new Z0 position. I do find this changes based on bed temperature used. I find the probe OK but since doing this Z offset before every print, I have very few print failures cause by poor first layer.

Before a print I like to,

Bring bed to temperature
Do bed level
Do mesh level
Bring nozzle to temperature
Do Z offset

Then print

These steps have given me very good and repeatable results. Do I have to do this, maybe not, but it takes no time and the results are consistent.

@Joel.......and yet one more "for what it's worth". When I converted to Duet 3, I never got around to setting up the fan I fitted behind the main board. This one runs Nema 23s at 2.4 amps as is necessary to throw my 3Kg extruder gantry around. During testing, I periodically checked the driver chips with a finger tip and they barely got above ambient. So the fan still sits behind the board but I've never got around to connecting it. The board is open and not in an enclosed case so YMMV.

@Phaedrux I'm on 3.1.1. Fortunately this is not a huge issue, got into the habit of just cycling power between prints. Things are back up before the bed cools down much.

I'll try the straws, I'm not sure what else either.

Hi,

Sorry I wasn't clear. Yes you would use this in place of the normal filament sensor feature.

On my printer I have some 750mm of filament from the filament sensor to the hot end.

I could afford several seconds of delay and require 5 or 10 consecutive readings. This would reduce the odds of a false activation to almost zero.

Assuming the docs are complete the action on a filament sensor detecting an filament issue is to pause the print and alert the use.

This can, of course, be done in the daemon.g with appropriate handling to insure it only happens once per filament issue.

Frederick

Yep, that didn't register. But, I still think a better way then would be, if a home command is executed, only clear the "homed" flags IF the homing failed.

For now, I did add a return macro which is working fine.

@deckingman said in Z crash but not into nozzle:

@Joel Suggest you read my post again for the reason. But I'm only guessing. I'm just an end user like you and trying to help.

I do have a Duet laser sensor and was thinking of maybe doing one of these two mods

https://forum.duet3d.com/topic/10042/indirect-bearing-laser-filament-monitor-concept

https://forum.duet3d.com/topic/15799/laser-filamant-sensor-with-switch-housing

@ViralTinker said in Thanks!!!:

I thank you to 😉

But Start using/calibrating/get used to duet is not easy compared to Marlin.Hopefully I will overcome my hurdles

Thanks

Marlin is difficult too until you are used to it.

I am using 2.04 for Duet WiFi and DWC.

I have no issue with just using my macro. I was playing with various features of DWC when I noticed the pull down way to run the bed mesh and it did not work the same way.

Thanks
Joel