Fix a bug that wipe tower has missing extrusions when ramming is disabled

[SoftFever]

Description

Fix a bug where the wipe tower has missing extrusions when ramming is disabled.

Additionally, this update improves the logic for the 'Enable Filament Ramming' feature. We no longer need to set the cooling parameters to 0 to completely disable ramming.
Update: there is a issue, you still need to set "Filament Parking Position" to 0 if you want to turn off ramming.

Screenshots/Recordings/Graphs

Before:

After fix:

Tests

[igiannakas]

Works beautifully (at least with SEMM and ramming disabled :))

[igiannakas]

Sorry to be a pain but there is one more thing - with SEMM, shouldn't the prime all printing extruders be "invisible"?

[SoftFever]

Sorry to be a pain but there is one more thing - with SEMM, shouldn't the prime all printing extruders be "invisible"?

Good point.
Changed!

[igiannakas]

Awesome thank you!

[igiannakas]

One more thing - what I didn't notice is that it is "purging" in the wipe tower before the filament swap

I dont think this was the case in the old version. While this is not an issue per se, its unnecessary material purge - ideally the actual purge area should be expanded to cover those areas or these omitted?

Sorry I haven't deep dived in that code segment so dont know exactly why this is happening :( Appreciate this is a) not a big deal and b) the wipe tower logic is pretty harsh to read code wise :)

[igiannakas]

Also there because it stops that pre-purge routine half way through the tower, when resuming after the tool change we get a tiny blob (depending on how well Happy Hare is configured) on the purge tower itself. I've noticed this leads to slight blobs on the surface of the tower, vs. in the past where the print resume would always happen at the edge of the tower.

[igiannakas]

Ok there definitely is something wonky with the prime tower and ramming when ramming is disabled:

It looks like it's extruding on the last layer over the prime tower but not on it if that makes sense, even though ramming is disabled in the printer settings. @SoftFever

[igiannakas]

I've got my hands tied right now to help code a fix - upgraded to sequoia and while the project compiles I get a ton of runtime crashes when debugging - seems like the compiler in the latest Xcode toolset is more restrictive in allowing slight "errors" during runtime :(

[SoftFever]

I've got my hands tied right now to help code a fix - upgraded to sequoia and while the project compiles I get a ton of runtime crashes when debugging - seems like the compiler in the latest Xcode toolset is more restrictive in allowing slight "errors" during runtime :(

yeah, that's nasty. Probably need to rebuild deps.

[igiannakas]

Already done so - deleted repo and re-cloned and rebuilt. The odd thing is running the build script (.sh) works just fine and the executable in the end is OK. But when running the debugger on Xcode it just errors out on (legitimate) issues that were not causing a complaint before. Mostly around out of bound vectors (eg in my IOI code of all places) and threading copy operations (in the expand bridges section). Prob the new build chain is more restrictive with assertions in the base libraries (vector for example).

Fixed this using "resize" instead of "reserve", then I get this:

Looks like some code changes are needed, which slipped through the radar before as the build chain was more "chill" with memory access

[SoftFever]

Also there because it stops that pre-purge routine half way through the tower, when resuming after the tool change we get a tiny blob (depending on how well Happy Hare is configured) on the purge tower itself. I've noticed this leads to slight blobs on the surface of the tower, vs. in the past where the print resume would always happen at the edge of the tower.

I don't get what's the issue from the screen shot.
Do you mind to explain what is wrong there?

[SoftFever]

Looks like some code changes are needed, which slipped through the radar before as the build chain was more "chill" with memory access

I'm using latest xcode as well.
Everything thing is fine.

I use relwithdebinfo to debug though.

[SoftFever]

I do find an issue about this part:
Additionally, this update improves the logic for the 'Enable Filament Ramming' feature. We no longer need to set the cooling parameters to 0 to completely disable ramming.

There is a issue, we still need to set "Filament Parking Position" to 0 if you want to turn off ramming.

[igiannakas]

Same here - I use relwithdebinfo and this started happening when I deleted the orca git folder and cloned again for a "fresh" base. Really not sure why they are happening but the errors do seem to make some sense. The debugger just didn't seem to mind before. I've raised a PR for these three instances here: #6932

For the wipe tower - yeap sure thing -

V2.1.1

v2.2

Notice the line above the prime tower. Filament ramming is disabled, cooling tube position, length, parking position and extra loading distance are all 0

Project file:
debug.3mf.zip

V2.1.1

Toolchange point:

V2.2

Toolchange point:

Notice the below issues:

1. It is printing the previous filament before invoking a tool change. In the previous version the toolchange did not require the previous filament to be used before emitting Tx
2. It is stopping printing the previous filament mid width of the tower. Then it invokes Tx. In the previous release the Tx command was invoked with the head parked on the side of the tower, vs. in 2.2, which its invoked when the head is parked over the middle of the tower.
3. In 2.2 the print resumes after the tool change and starts purging at the middle of the tower . In 2.1.1 it resumes at the edge of the tower.

Number (2) and (3) are an issue because when invoking Tx mid way through an extrusion you get a bit of ooze from the nozzle. When you then go to resume mid way through the extrusion you get a small "bulge" that is printed on the tower. In 2.1.1 these little bulges were at the perimeter of the tower and did not matter as the nozzle de-retracted right outside the tower and started printing the purge lines with a clean nozzle.

Basically we should be printing complete layers like 2.1.1 and not purge the previous material on the tower at all when ramming is disabled.

Project file above should showcase these differences between 2.2 and 2.1.1

[igiannakas]

Basically the CP Toolchange unload routine should not be executed when ramming is disabled

[igiannakas]

Hey I think I see the fix:

I think its this:

float ramming_depth = (int(length_to_extrude / width) + 1) * (m_perimeter_width * m_filpar[old_tool].ramming_line_width_multiplicator * m_filpar[old_tool].ramming_step_multiplicator) * m_extra_spacing_ramming;

This needs to check whether ramming is enabled or not - it currently doesnt, so it retains some volume on the purge tower to do the ramming, hence leading to the gaps.

Plus this:
const bool do_ramming = m_semm || m_filpar[m_current_tool].multitool_ramming;
in this:
void WipeTower2::toolchange_Unload(

Needs to be checked against whether ramming is enabled - currently it runs the unload process every time there is a SEMM printer selected.

With these two changes manually set to false/0 (just quickly to test it out)

I've got my debugger running, I can try making those changes if you want?

[SoftFever]

Hey I think I see the fix:

I think its this:

float ramming_depth = (int(length_to_extrude / width) + 1) * (m_perimeter_width * m_filpar[old_tool].ramming_line_width_multiplicator * m_filpar[old_tool].ramming_step_multiplicator) * m_extra_spacing_ramming;

This needs to check whether ramming is enabled or not - it currently doesnt, so it retains some volume on the purge tower to do the ramming, hence leading to the gaps.

Plus this: const bool do_ramming = m_semm || m_filpar[m_current_tool].multitool_ramming; in this: void WipeTower2::toolchange_Unload(

Needs to be checked against whether ramming is enabled - currently it runs the unload process every time there is a SEMM printer selected.

With these two changes manually set to false/0 (just quickly to test it out)

I've got my debugger running, I can try making those changes if you want?

That's awesome.
Please go ahead with your changes 👍

[SoftFever]

Notice the below issues:

1. It is printing the previous filament before invoking a tool change. In the previous version the toolchange did not require the previous filament to be used before emitting Tx
2. It is stopping printing the previous filament mid width of the tower. Then it invokes Tx. In the previous release the Tx command was invoked with the head parked on the side of the tower, vs. in 2.2, which its invoked when the head is parked over the middle of the tower.
3. In 2.2 the print resumes after the tool change and starts purging at the middle of the tower . In 2.1.1 it resumes at the edge of the tower.

Number (2) and (3) are an issue because when invoking Tx mid way through an extrusion you get a bit of ooze from the nozzle. When you then go to resume mid way through the extrusion you get a small "bulge" that is printed on the tower. In 2.1.1 these little bulges were at the perimeter of the tower and did not matter as the nozzle de-retracted right outside the tower and started printing the purge lines with a clean nozzle.

Yes, there is a slight behavior change.
But I'm not sure if this In the previous release the Tx command was invoked with the head parked on the side of the tower is true.
I believe if you have multiple color changes in same layer, it will call Tx in the middle of the tower regardless. But I haven't checked it yet

[igiannakas]

I'm pretty sure it always went to the edge to tool change - haven't noticed before even with multiple color changes the "in the middle of the tower" tool change. I'll make the changes on ramming and will do some deeper inspection next :)

[igiannakas]

Another issue found when fixing the one above:

In 2.2:
Purging from white to grey - z height: 18.280

Purging from grey to white - z height 18.280!!!

So the last purge will crash the nozzle on the tower.

I'm readying the fix for the first issue and then I can take a look at this one.

[igiannakas]

OK, found why the nozzle crash issue -
13ddb38

This is forcing a Z move to the wrong layer height. @SoftFever any hint why this was added?

[igiannakas]

OK amended the PR above to include fixes for both. But for the nozzle crash I am really not sure whether that is the right fix.... :)

#6934