alexjx

Interesting, I've been using DXU for a month, but didn't notice the issue mentioned here. I recognize mark2 is a great design, and what makes other solutions like DXU possible. However, it doesn't make sense to rule out other also good solutions. The heat breaker that DXU uses also works well enough to handle two nozzles. I could use a stronger fan to cool them. I'm using the 2510 variant and observed the cooldown time is much shorter than the original head. I printed regular PC in one head @ 290C, and loaded PLA in another, with an enclosure. Under this situation, the PLA in another head didn't deform enough to jam it. As the leaking, I think Cura's standby temperature did a great job. We are talking about modifications, there is a trade-off. The thing I believe mark2 made is space. The extra head will take up a much larger space than what DXU takes. I think the downside of DXU is really the source of material... It is not so easy to get as mark2.

Doesn't ChangeZ alter the feedrate factor instead of the "speed" itself? So it affects all the "speed" with a ratio. Could you look at if the output gcode has M220 in it? If there is, please check if your firmware has M220 support.

I'm afraid not... since one of the walls is already much less than 1mm thick.

For what it worth, here is what I measured. The diameter of the hole for the heater is 4.05mm and 16mm deep. So maybe for 4mm heater. The diameter of the PT100 hole is 3.3mm also 16mm deep.

Interesting, what firmware r u using? As far as I know G92 will be "reset" once homed.... so unless you print second one without homing.... the z offest will be gone...

I asked a similar question recently, I guess that's because the red one is your first nozzle. If you also using 3.6 then this is the trade-off made to make sure the prime tower stable. I guess Cura developer consider most people are using the second extruder for support, therefore different material. So Cura will generate a tower with a shell that always printed by the first nozzle even if there is no this color in this layer. In this case, I think it makes sense, but it sacrificed cases that we print different color of the same material. I have started using Cura since 3.6, but I heard the old one that has a different implementation of this. But it has another problem. Unfortunate the developers consider dual color minor and providing an option to toggle the old and new will make them maintain two variants of the implementations. And that is something they choose not to.

I think I used the wrong words... it works as intended. but just not my expectation. It does travel within the gaps. regarding this, the avoid distance doesn't seem to work. Please see the attached image, I tried to set an ... really large distance, but it still travels within the gap. What I expected was following, when I set to "Within Infill" or "Off".

Thank you all. Combing does have an impact on this. It's interesting to find out. "Not in skin" does not work in this case, since the spiral path is "skin" after all. @smartavionics I agree that there should be an upper limit. I thought the "Max Comb Distance With No Retract" was the limit... but it seems it only impact the "retraction"... not the travel...😂

I would suggest trying to change the line width, the yellow is the infill but it has to follow the infill pattern instead of the shell's. But I think what you are trying is to make it the same as shell?

Hi all, Thank you for reading this. I'm trying to understand the travel pattern of Cura. I'm using 3..6, trying to print a spring of a toy bike. What I understood (I hope) is that cura tries to print the inner wall then infill, so it has to move around. But, why it has to move in the pattern as if it's trying to avoid the printed parts??? And even more... it dosesn't matter if I disable the "avoid printed parts when travel" option. Thanks in advance. Jia Additional info: This is a snapshot of the first layer.

Thank you for your fantastic work. I really liked this compact and efficient design. The documentation is thorough and the design is well thought. It's not difficult to print and assemble. I printed it with transparent PC, so it has its style. I got pretty good results with it. And most of all, the DXU itself look really good. 😎

I once hit this issue before, while my UM2+E was set to run in MARLIN instead of ulticode. The plugin inserted the recovery instruction as "M220 S-1". However, the UM2.1 firmware doesn't work correctly to handle the negative value so it turned out to be extremely slow.