Qidi XMax 3 going crazy

strantor

Active User
Registered
Joined
Oct 29, 2012
Messages
1,328
Any idea what's going on here? I am wasting a lot of expensive filament and a lot of time that is more valuable.


If it was at the same layer each time I would suspect a corrupt gcode file. Maybe it still is ? it did fail twice on the same layer after all... puzzling.

So I re-sliced it with slightly different settings and tried again. This time it happened at a different point. about 20 layers in.
 
I just found there is a firmware update available. Will try that and see if it helps.
 
It appears that the x or y, or maybe both x and y steppers missed some steps.

Any recent changes to your max speeds or accelerations?

My first guess would be that your speeds were changed to a value in excess of what the motors are capable of doing, so when it tries to do a rapid travel move, it misses steps. After which, it no longer knows where the toolhead is, hence the drastic offset after the missed steps.

My second guess would be that there is something amiss, perhaps on your linear bearings that cause some binding, again resulting in some missed steps. Or, maybe a combination of speeds/accel too high and linear bearings not lubed, binding, dirty, etc.

Definitely looks like missed steps on a motor though. I had the same thing happen when I first built my Voron, because I inadvertently assembled a linear bearing shuttle incorrectly. It still moved freely, but had more drag than it should. It worked fine at low speeds, but whenever it tried to do a 300mm/s rapid move, the motor couldn't handle it and missed steps.


Edit to add:

I thought I had posted about the missing steps issue in the Voron thread. Here was the post :D
That was several days of frustration that I thought I had cured several times, and just kept coming back.

 
Last edited:
It appears that the x or y, or maybe both x and y steppers missed some steps.

Any recent changes to your max speeds or accelerations?
No. I have been running with these settings for days with no issue.
My first guess would be that your speeds were changed to a value in excess of what the motors are capable of doing, so when it tries to do a rapid travel move, it misses steps. After which, it no longer knows where the toolhead is, hence the drastic offset after the missed steps.

My second guess would be that there is something amiss, perhaps on your linear bearings that cause some binding, again resulting in some missed steps. Or, maybe a combination of speeds/accel too high and linear bearings not lubed, binding, dirty, etc.

Definitely looks like missed steps on a motor though. I had the same thing happen when I first built my Voron, because I inadvertently assembled a linear bearing shuttle incorrectly. It still moved freely, but had more drag than it should. It worked fine at low speeds, but whenever it tried to do a 300mm/s rapid move, the motor couldn't handle it and missed steps.


Edit to add:

I thought I had posted about the missing steps issue in the Voron thread. Here was the post :D
That was several days of frustration that I thought I had cured several times, and just kept coming back.

Note that the video is real time, I did not speed it up or slow it down at any point. It shouldn't have been going any faster than 18mm/s. I am using a 0.8mm nozzle, with 0.64mm layer height and the maximum 375% height:width ratio (2.4mm width), which works out to 28mm³/s volumetric at 18mm/s. My extruder is running near its limit at this linear snail's pace. My travel is set to 250mm/s I believe, with conservative acceleration.

I have been studying my sliced file, the video, and the two parts which failed at the same layer, and either drawing more informed conclusions or talking myself into more elaborate conspiracy theories; not sure which yet.

I don't have an abundance of experience in 3D printing but I have been working with steppers for unrelated projects for a while and I agree that there was the sound of missing steps in there, but it seems to me like what happens when you apply a modest speed pulse train directly, with no acceleration. Like if you plug in a step/dir signal cable while the controller is already sending pulses. I think X and Y were hit with an instantaneous blast of pulses and that trip out into left field actually happened on the decel ramp, when the motors finally caught up to the pulse train.

In re-watching the video I notice that as soon as it got back around to the seam and finished that outer perimeter, instead of proceeding to start the next layer it went to warp speed directly away from where it should have gone. The other one that failed on this layer, seems to have done the same thing. That last layer is complete, includes the final outer perimeter. I think they both did exactly the same thing at exactly the same spot in the g-code. My layers are so tall and extrusions so thick that I can actually count the layers and rings and be reasonably confident about this.

But I have two other failure specimens that didn't fail at that spot; one that failed prior to it, and one that made it past that point and failed at about 95% completion. So what gives? I am not 100% sure that all 4 failures were from the exact same gcode file. I think I ran the same file 4 times but I have been working on printing this part for a couple of days now, among other parts and another printer, and I have 2 versions of the file. Since I can't say beyond a reasonable doubt, I am striking those two prior failures from the record and focusing on the two I know for fact were the same file and which failed at the same layer.

Going back to slicer, there is something special about that area. I added a layer height modifier near there because I wanted the bottom layers to have more resolution because there is a bearing race at the bottom.

20231130_230254.jpg


This failure happened not on layer which transitions from high resolution to low resolution, but just after it; I think it failed on the very next layer, hard to tell. But I think the layer height modifier is the culprit. I suspect (conjecture warning) that the slicer told the printer to do something that it misinterpreted as "teleport to Taco Bell and finish printing this in the parking lot" and it did its best to comply.

I would expect things like this to happen if I was using a crowdsourced slicer with a DIY printer but I am using the slicer that was supplied with the printer. But technically this is still a (re-branded) crowdsourced slicer and the difference between DIY and commercial is often just aesthetic. Maybe I am being too accusatory, too early. I will try tomorrow to print the whole thing with consistent layer height and new firmware, see where that gets me. I would like to test those two things separately but I have already lost 2 days on this one part.

EDIT: oh yeah, and the linear guides have been oiled twice since I got it just over a week ago. No crunchy grindy noises.
 
Last edited:
. But I think the layer height modifier is the culprit. I suspect (conjecture warning) that the slicer told the printer to do something that it misinterpreted as "teleport to Taco Bell and finish printing this in the parking lot" and it did its best to compl


Did you get this sorted out? Just curious as to what was the issue and what fixed it?
 
Curiously, I had printer failure on or near the transition to variable layers. Totally different printer Prusa MK3S+ and slicer PrusaSlicer2.6. Happened three times in a row. In my case, it deposited some sizable boogers and then next go around the head slammed into them. This knocked over the part, causing the head to jam into the part. Melted a good size hole in the part. I had resliced the part, but still, it would fail.

I got rid of the variable layers and it printed fine.

Think there's a bug somewhere in the variable slicing and or transition. Might want to try using an earlier version of the slicer to see if it does the same thing? Maybe use some cheap filament while you are debugging?
 
Curiously, I had printer failure on or near the transition to variable layers. Totally different printer Prusa MK3S+ and slicer PrusaSlicer2.6. Happened three times in a row. In my case, it deposited some sizable boogers and then next go around the head slammed into them. This knocked over the part, causing the head to jam into the part. Melted a good size hole in the part. I had resliced the part, but still, it would fail.

I got rid of the variable layers and it printed fine.

Think there's a bug somewhere in the variable slicing and or transition. Might want to try using an earlier version of the slicer to see if it does the same thing? Maybe use some cheap filament while you are debugging?

PETG?

That stuff seems particularly susceptible to boogers and blobs.
 
PETG?

That stuff seems particularly susceptible to boogers and blobs.
Yeah, PETG. I just tried a new roll of Overture PETG and so far it is ok. Used the identical settings as for Prusament PETG. But I haven't tried variable layers. Probably will try variable layer, but with a less big model - fail fast as they say, rather than fail at the end.

I don't have an enclosure yet, so can't really print anything exotic at this point. Slowly printing the pieces for the enclosure. Too bad they take over 100 hours... Then I'll need to modify the enclosuer to put in some decent filtration. Seems I'm sensitized to whatever is released during printing - so I have to print stuff in short runs and wait for my symptoms to stop, typically a few days later.
 
Did you get this sorted out? Just curious as to what was the issue and what fixed it?
Sorry, I personally hate it when people just evaporate in the middle of something and never come back to deliver closure, so I try not to do it myself. I thought I remembered posting an update but that was on the youtube video.

I have attached an email conversation I had with Qidi tech support in case you're interested, and at the bottom of it is a link to the files in question in case you're further interested. I must say that buying this printer came with an unexpected bonus: decent tech support. I am used to slogging through the mire of DIY dealing with companies that don't offer any means of contacting them or have pathetic outsourced tech support. So my first instinct isn't to pick up the phone, it's to run to the internet and if I can't find the answer, post publicly. This should have been my clue to change up my tactics and not default to online blasting:
20231204_153841.jpg


Anyway, there is a bug in the slicer with my layer height modifiers in bearing2.3mf which does... something, not sure, but looking at bearing2.gcode in a 3rd party gcode viewer might shed light on it. Qidi has not exactly confirmed that it is a "bug" but they did confirm that the layer height modifier is the problem. They indicate that the perimeters I chose in the layer height modifier did not jive with the perimeters I chose in the main settings. If I make a nonsensical selection (not sure why it's nonseniscal but whatever) then the software should generate an error, not go forward with generating nonsensical gcode and uploading it to the printer. In my world we call that a "bug."

Curiously, I had printer failure on or near the transition to variable layers. Totally different printer Prusa MK3S+ and slicer PrusaSlicer2.6. Happened three times in a row.
...
I got rid of the variable layers and it printed fine.

Think there's a bug somewhere in the variable slicing and or transition.
Thanks for contributing this data. As Qidi slicer is just rebranded PrusaSlicer, I am not surprised we had the same experience. I was actually curious if PrusaSlicer users had experienced this or if it was an issue that Qidi introduced. Since it seems it wasn't Qidi's fault then I suppose I won't hold my breath waiting for Qidi to fix it. It will get fixed when PrusaSlicer gets fixed (or, slightly later probably).
 

Attachments

  • Qidi tech support email.pdf
    1.3 MB · Views: 67
ALSO:
I think that the first two failures (the one near the start and the one near the end) were not related to the two which failed in exactly the same spot. I think the first two failed due to overextrusion, boogers, the normal way. So I re-sliced the file with new settings and that's when the bug got in. I just lumped them all together as at the time they seemed obviously related.
 
Back
Top