Just in case someone finds this in the future. I went the recommended route and manually extend the allowed area in bed.g like this:

bed.g

[...]
M208 Y{global.minY}:{global.maxYMesh} ; extend allowed space for probing near the edge of the bed
G29 S0
G1 X400 Y{global.maxY} F20000		          ; Park
M208 Y{global.minY}:{global.maxY}     ;reset safe moving space to normal

In config.g I create the referenced globals from above:

[...]
; Axis Limits
global minY = -149
global maxY = 72
M208 X-146:159 Y{global.minY}:{global.maxY} C0:250 Z0:290 ; set axis minima & maxima
[...]
global minYMesh = global.minY
global maxYMesh = 115
M557 X-146:150 Y{global.minYMesh}:{global.maxYMesh} P10  ; define mesh grid
[...]

This works fine and is maintenance free in terms of having to maintain hardcoded coordinates in multiple places.

@sputnikoc3d said in Filament Material Changes without Load - Unload ???:

@fcwilt said in Filament Material Changes without Load - Unload ???:

@sputnikoc3d said in Filament Material Changes without Load - Unload ???:

my goal isnt to improve my load and unload routines ... which I can do at a later time.

I just change the filament "by hand" and then select the newly loaded filament from the DWC.

Frederick

Wait ... wuuuutt ?

Why do I have to load and unload ... obviously Im doing something wrong. I want the ability to do just what youre doing - lol wth ..

Frederick probably just means that he has no code in the load/unload macros, that way, DWC doesn't do anything when "loading" or "unloading filaments, other than showing a different string in the interface.

@siam Finally managed to get the accelerometer connected... I'm currently using about 3m of USB 3 extension cable and that seems to work ok, was just a lot of pain to wire up...
It looks like shielding is way more effective here than just twisted wire pairs (which I tried before and didn't work on its own)

On my custom toolchanger I have seen similar super slow moves while changing tools. I think they are related to the current position being out of the normal limits, if I set the tool macros to leave the active tool within the allowed area after tfree, it works as expected.

Do you move your tools outside the normal limits for parking by any chance?

Oh wow, I think i finally figured out what's going on. At least something that is going on.

My hotend holder is deforming under the pressure from the extruder... This tilts the whole hotend, moving the nozzle in Y and Z.

I just noticed this very extremely when going from first to second layer, the first layer is fairly slow (30m/s) and the second is twice as fast.
The higher speed deformed the holder a lot more, giving an explanation for the perfect first layer and then the sudden issue with layer 2.

I'm not sure yet why it would cause issues during the first layer as it still sometimes does, but right now I'm printing beefier holders and then see if that helps.
T1 was also less affected since it's using a 0.4mm nozzle vs the 0.3mm on T0...

Fingers crossed that this is purely a hardware issue on my side and no obscure firmware thing

The currently loaded filament(s) are stored in sys/filaments.csv. You can edit this file by hand and restart the Duet to apply the changes.

@jayjay Why would any reseller announce the new version if they still have the old one in stock? They want to sell those first of course...

You seem very upset about this, but rest assured, this is industry practice and nothing out of the ordinary...

@dc42 said in Software package 3.3beta3 released:

@diamondback said in Software package 3.3beta3 released:

@siam Finally managed to get the accelerometer connected... I'm currently using about 3m of USB 3 extension cable and that seems to work ok, was just a lot of pain to wire up...
It looks like shielding is way more effective here than just twisted wire pairs (which I tried before and didn't work on its own)

The SPI frequency is currently 4MHz. I'll try reducing it, that may make it easier to use long cables.

Thanks for looking into this. Is there any advantage to the higher frequency in practical use? If so, maybe offer te higher speeds as an option still?

Yea, I think this was indeed the problem. After installing much stronger parts for the hotend holder, the nozzle does not dive anymore. (Btw these weren't stupidly small parts or bad filament, they were printed in carbon fiber reinforced nylon, which is much stiffer than anything else I have around, so that really wasn't on my radar...)

@jayjay Oh well, sorry, not going to participate in a passive aggressive discussion with you, I have better things to do
You seem to be purely here for the attention and not looking for a productive conversation with people that actually explain you the reasoning.

@sputnikoc3d said in Filament Material Changes without Load - Unload ???:

@fcwilt said in Filament Material Changes without Load - Unload ???:

@sputnikoc3d said in Filament Material Changes without Load - Unload ???:

my goal isnt to improve my load and unload routines ... which I can do at a later time.

I just change the filament "by hand" and then select the newly loaded filament from the DWC.

Frederick

Wait ... wuuuutt ?

Why do I have to load and unload ... obviously Im doing something wrong. I want the ability to do just what youre doing - lol wth ..

Frederick probably just means that he has no code in the load/unload macros, that way, DWC doesn't do anything when "loading" or "unloading filaments, other than showing a different string in the interface.

The currently loaded filament(s) are stored in sys/filaments.csv. You can edit this file by hand and restart the Duet to apply the changes.

Further info on this: Even with the homing of C as the very first part of homeall.g it doesn't always work. I've run into multiple homing failures already and only noticed when the toolhead crashed into the tool with a non-open coupler...
Can't tell any patterns yet...

@fcwilt said in Feature Request: Ability to de-select tool after filament change:

@diamondback said in Feature Request: Ability to de-select tool after filament change:

@fcwilt Thanks for the thoughts. It would probably be an "ok" workaround, but I'm not really positive about this being an actually good solution...

I would love to get some more control over what exactly DWC executes when pressing the filament related buttons, could be as easy as defining some "end" code/macro, either via file or a setting within DWC.

I meant it only as a work around until such time that your need is addressed by the progammers.

Frederick

Yea, it's definitely a smart idea, maybe I'll mess around with a little.

@fcwilt Thanks for the thoughts. It would probably be an "ok" workaround, but I'm not really positive about this being an actually good solution...

I would love to get some more control over what exactly DWC executes when pressing the filament related buttons, could be as easy as defining some "end" code/macro, either via file or a setting within DWC.

@fcwilt I'm running a Toolchanger that loads its filament by purging a bunch of it.
So in order to do that, the correct tool is being selected by DWC when clicking the load button, it then executes the load macro of the specific filament, which moves the tool to the purge location and then purges a bunch.
Ideally, it would now store the tool away by deselecting it.
I want this to happen as quickly as possible after purging is done since my parking position includes a silicone strip that blocks the nozzle and avoids any oozing while the tool cools down.

When doing this manually, I either have to sit there while it's purging (which takes some while to finish) carefully watching the process and hit the deselect button in DWC as quickly as possible, or accept some oozing, which makes the silicone blockers kinda pointless.

If RRF/DWC was able to have a T-1 as the last step of the filament load, I would be able to fully automate this.

Any news on the feasibility of this? @dc42
Would still love to get support for this and clean up my tool/filament configuration by putting it all in a nice array instead of many many files distributed across /macros

@dc42 Is this still on the list for things to look into? The behavior still exists as described on the latest 3.4b3.

Any news on this? Would love to get the "change" functionality back... @chrishamm @dc42

Any idea @dc42 @chrishamm ?