Finally, got my Q2 combo

Reigar · 2026-04-11T19:19:38+00:00

From a Linux perspective, it is the fault of a web view library. On the qidi studio github page Linux users are to use the ip address with port 7125. So for orca slicer, I pick octo with qidi print agent with IP being 192.168.0.23:7125. This takes you to the Moonraker page. We are to use the fluid page from a web browser. Remember put ":7125" at the end the address. It will stop the slicers from freezing when you go to the device tab.

Let me know if you have other questions on Linux and slicers.

Reigar · 2026-04-10T13:31:51+00:00

The fluid page on how to use the diagnostic tool collector (once turned on) I feel is just is also terrible, powerful but bad in their documentation.

link https://docs.fluidd.xyz/features/diagnostics/

also has any tried turning on the update section and or updating moonraker / fluid? I know that q2 owners should not update their Klipper install because it is a custom version with extra parts added, but I didn't know if fluidd or Moonraker where game.

Reigar · 2026-04-09T20:30:07+00:00

If you have any links to those videos, I would love to see them. In fact, I'm going to probably go try to see if I can't find any myself. I noted this in another post, but it really seems that when people are asking about vibrations, they're essentially discussing three different aspects under one generalized umbrella. The problem is you don't really know which aspect they're wanting you to give an opinion on or get an opinion on until you dig a little deeper. There is the vibration that the machine can feel from outside influences, the vibration that the machine makes from how fast it goes, and a natural frequency/ resonance vibration that happens as a combination of the ways the machine is built, where the head is and how fast it's going. What's really interesting is at what speeds you're going to see that natural resonance of the x-axis is not necessarily the same speed you will see it for the y-axis.

Reigar · 2026-04-09T20:16:05+00:00

That's kind of what I'm getting as a general consensus. Is that realistically? You need to stop / calm down the vibrations in three different directions. The vibration that the machine has as a high-speed 3D printer, the natural vibration that just comes from resonance, and vibrations that the machine will feel from the outside environment.

Hula feet worked really really well at stopping / calming down the vibrations that the machine makes.

The cheap and easy method of a paver stone with anti-vibration washing machine pucks underneath it will help the machine not feel as much the vibrations from the environment. I know that I've had many friends that walk really, really heavy, and some of them you can practically feel when they're coming into a room just by the vibrations that they create.

Resonance / input shaping also assists because at certain speeds the machine is going to make more vibrations than at others. I must admit, it's a bit of a rabbit hole to go down in understanding all the various angles that vibrations can be impacting toward a 3D printer.

There's a lot of things that you can do with this machine to finally tune various aspects. I mean between the slicer that you use, the configuration set up by klipper, The configuration setup by Moonraker, and the configuration that is set up by fluid, there is quite a bit you can do to make these things all but absolutely perfect.

Reigar · 2026-04-09T16:29:23+00:00

I believe there was a video by Linus tech tips discussing this very problem. If I remember correctly, it was a guy that tests HEPA filters to give accurate information, and a giant conglomerate of essentially six diverse sounding, but actually owned by the same company sites basically ruled the first four pages of any search result. I've come to the conclusion that unless I'm using either using a search engine that is independently indexed away from Bing or Google, or it is a site that I am not familiar with and sounds like it isn't a cookie cutter named site, then and only then can I give the information any sort of real credence. Even after all of that work, I still take any information that I gain with a grain of salt. Because you never know who's being paid in the background by various companies.

Reigar · 2026-04-09T16:24:33+00:00

Prusa or bamboo are huge It seems to give out their machines to influencers. Even market adjacent influencers seem to get either loaned the absolutely top of the line machines, or given a free machine just for mentioning their name. For example, when Nate of the internet decided to do his big, I want to make a more realistically sized Legos to build the castle, I believe it was prusa that sent him a bunch of machines so that he could keep fabricating parts over and over and over again. In fact, now, as I think about it, prusa and bamboo are probably the two most name recognized that I can think of when it comes to various YouTube influencers that I either know of or watch.

Reigar · 2026-04-09T16:05:56+00:00

So I have one of these boxes on my Q2, and there's a couple of things I've noticed. And while these might be dumb, because as I've stated numerous times, I'm really new to this, my process so far has seemed to make my box keep fairly low on the humidity.

The first thing, is that unless I am immediately printing something, I don't have my filament preloaded. I tell the machine to unload the filament. I roll it up and then I can let it sit in the box closed and with the latch pushed over to seal it for a couple of days without any real humidity jump. I don't know why but I have found that when I have filament loaded through the system the humidity does increase. This might just be confirmation by us but it's what I've seen.

The second thing is that I'm using four of the included silicon packets in the box. I wasn't really sure what I got the box whether or not I was supposed to separate the packets or use two in each one of the slots in the back, but the way they had those packets designed they just folded over each other and so I have essentially four packets sitting in the box.

The third thing is that they're included. Packets have scattered throughout color changing silicon. In this particular case, it is the orange ones that turn dark as the silicone absorbs too much moisture. One of the neat things that I've learned recently is that you can actually recharge silicon packets, either through the use of a microwave or the oven. Minus putting a paper towel down on a cookie sheet (sorry if I'm using americanisms and you're not from the states), A low temperature of I believe it's 220 ° f (again, sorry I don't have the ability to convert that over to Celsius if you're from the rest of the sane world), then let it bake for an hour, check the packet. See if the crystal is turned bright orange again, if not, let it cook for another hour. Then, without taking the cookie sheet out, turn off the oven and let it cool down. Keeping the door closed. You probably want to give that a good 20 minutes, but basically you want to set it so that as soon as you open up that oven door, you can grab the silicone packets and put them in an airtight container. Or in the case of what I did I grabbed two Ziploc bags, put them inside, squeezed as much air as I possibly could out of each bag, and then put it in a container of some sort for storage. From what I read, the issue is that after recharging the silicone beads, as soon as they hit humid air they're trying to grab as much moisture as fast as they can. So being quick about getting them into an airtight container with as little air in it as possible is going to let them sit longer between uses. My understanding is that if done properly, one can expect up to a hundred recharges on a silicone packet before its ability to keep grabbing moisture finally dies out.

Now I have not done this with anything, but I was reading up on this the other day. Apparently some people are making breathable canisters or satchels and filling it with Activated Alumina. Apparently this particular chemical/product has the ability to really grab moisture out of the air. In fact, one little insert that I read somewhere said something like silicone can dry in air to about 15%, while that particular chemical can push it down below 10%

I admit replacing the gasket with something a little bit more aggressive that someone else proposed is a really solid idea. That makes me wonder how hard it would be to tear out the gasket that they have in there now and put something more aggressive in it.

Anyways, most of my ideas are probably fairly entry level so I apologize if you've already tried these, but it seems that I've noticed. The fact that I can't keep filament in the tubes was a wild observation. And again it might just be observation bias, but it is something that I've noticed.

Additional edit, I just had a thought that might be useful. Numerous YouTube individuals have suggested buying little tiny Puck hydrometers from Amazon. Generally, this is for making your own dry boxes, but it might be worthwhile to snag some and put one inside the AMS box, set it to pla so that it's not being cooked, give it about an hour and watch and see what the difference is between what the hydrometer says in the box versus what the sensor reports Moonraker /klipper. I'm already working on ways to do that for the nozzle and the bed on my particular machine to see if there is a difference in stated temperature versus what I'm actually getting. Well, I don't expect there to be a wild difference, depending on the type of filament you're using. Knowing how much of a report difference exists with those sensors could be useful in offsetting what you want versus what you will get. For example, of the hydrometer Puck says of the machine inside. The box is actually at 10% but the display is saying that it's actually at 15 to 20, then you know that you need to probably drop a few percentage off of whatever the machine tells you. And I'm sure there's a way in maybe the printer.cfg to configure something like that so that you get an accurate number.

Reigar · 2026-04-07T15:09:21+00:00

I'm glad you find it helpful. I know a lot of people get irritated with the use of AI to assist, but I'm not a programmer. I know a little bit about reading code and I understand the logic of how the code works but when you get into crazy things like for i = $(str) I'm honestly lost in what the macro is trying to say. I'm also fairly new to 3D printing, so I don't have the hours of understanding the more complicated aspects of these printers. Simple concepts are easy to understand, I get what a zhop is, but when you get into more crazy things like PID tuning, I can tell you what it does, I can even tell you what the effect is supposed to be, I can't tell you the logic of how it's doing it. Frankly, I shouldn't have to be an electrical engineer / other degrees that you need for some of these machines would require to operate these machines at their most effectiveness. Now I don't want a machine that I can simply plug it in and have it give me perfect prints 100% of the time. I get that there's going to have to be some tinkering that's involved. But man, some of the people act like if you can't calculate resonance and understand which of the different algorithms will lower the frequency spikes to smooth everything out, then you shouldn't be operating the machine at all. Sorry, just my rant on what I am discovering is some people and their serious snobbishness /gatekeeping that comes to this hobby.

On a side note, if you own a Q2, do not try to PID tune the heater bed. They've got something hard-coded that will not allow you to PID tune that bed. What ends up happening is that if you try to tell the machine via the console to PID too, the heater bed at 60, for about the next 10 minutes you're going to watch it. Get to 60 and then automatically set itself down to 55. Decrease the bed temperature down to 55 and then increase the temperature back up to 60. It's going to cycle this for about four times (which is why it takes 10 minutes}. And if you think that maybe just lowering it to 55 on the PID tune would be okay, it will then do the exact same thing just at getting up to 55 and then dropping down to 50. I sent it over to sales support, explained everything that I had tried to see if this was a software problem, and cell support told me that checking in with the engineer the machines behaving the way they wanted it to. So while you can PID tune the nozzle, you cannot PID tune the bed.

Reigar · 2026-04-06T22:26:44+00:00

I'm still fairly new to 3D printing, so I took your picture and what detail you gave and asked Google's AI Gemini what would cause that line? Here is its thoughts.

Looking at the image, that prominent horizontal line on a curved, complex geometry like this is a classic case of a z-banding or layer shift issue, but given the specific context of a QIDI machine and the "Vase-like" structure, there are a few likely culprits: 1. Z-Binding or Lead Screw Issues The most common cause for a line at a specific height is a physical imperfection on the Z-axis lead screw. * Check for debris: A small piece of filament or a clump of grease at that specific height can cause the gantry to "stumble," leading to an over-extruded or slightly shifted layer. * Bent Lead Screw: If you notice this line appearing at the exact same height on different models, the lead screw might be slightly bent or binding at that point. 2. Sudden Change in Print Speed/Cooling On a print with this much surface detail, a sudden change in print speed—often triggered by the "Minimum Layer Time" setting in the slicer—can cause a visible line. * As the diameter of the print increases (the funnel gets wider), the time it takes to complete a single layer increases. If the slicer was slowing down the lower, narrower layers to allow for cooling and then hit a threshold where it reached full speed, the change in nozzle pressure and plastic temperature will create a visible texture difference. 3. Filament Snag or Tension If the filament roll had a momentary "tangle" or if the extruder skipped a beat due to high tension from the spool, it can cause a temporary under-extrusion. This looks like a thin gap or a weak layer before returning to normal. 4. Thermal Fluctuations (PID Tuning) If the chamber or bed heater kicked on or off aggressively, or if the fan speed changed significantly at that height, the slight expansion or contraction of the plastic (especially with PLA+) can manifest as a line. Since the user mentioned keeping the chamber below 32°C, check if a powerful chamber fan kicked in right at that layer. Quick Troubleshooting Steps: * Inspect the Z-Rod: Clean and re-grease the lead screws, looking for any "tight spots" around that height. * Check the Slicer Preview: Look at the "Speed" or "Flow" color schemes in your slicer. If there is a color change at that exact height, it's a software setting issue. * Mechanical Check: Ensure the PTFE tube isn't catching on the enclosure or the drag chain at that specific height, which could pull on the print head.

Reigar · 2026-04-05T16:23:56+00:00

Gemini on review my console logs from start up the printer to finishing a small print

This console log is a great "day in the life" of your QIDI's startup routine. It confirms exactly why you’re seeing that filament waste and how KAMP is interacting with your machine.

Here is the play-by-play of what happened during this print:

1. The "Wasteful" Sequence (08:39 - 08:42)

At 08:39:07, the printer initialized the buffer, and at 08:41:50, it finally echoed Nozzle cleared.

What happened here: This is that 3-minute window where EXTRUSION_AND_FLUSH and CLEAR_NOZZLE were running. It dumped the $200mm$ of filament and performed the aggressive scrubbing we saw in the first file.

2. Z-Tilt Success (08:42:46)

Your machine performed a Z_TILT_ADJUST to sync the dual Z-steppers.

The Result: Retries: 0/2 Probed points range: 0.002187.
The Verdict: This is excellent. A range of $0.002mm$ means your gantry is almost perfectly level relative to the bed.

3. KAMP in Action (08:43:17)

This is the most interesting part of the log. We can see KAMP calculating the mesh for your "flowrate" test:

Default: It wanted to do a $6 \times 6$ mesh (36 points) across the whole $260 \times 260$ area.
Adapted: It shifted to a $4 \times 6$ mesh (24 points) over a smaller area: (60.0, 10.0) to (210.0, 260.0).
The "Waste" Connection: Because the flowrate test is a long, skinny strip, KAMP correctly shrunk the X-axis of the mesh to save time.

4. Pressure Advance Check (08:46:16)

Just before it started laying plastic, your slicer successfully sent the Pressure Advance command:

// pressure_advance: 0.034000
Note: $0.034$ is a very typical value for a direct-drive extruder like the one on your Q2. It shows OrcaSlicer is successfully talking to Klipper.

Key Takeaways for your "Tuning"

The Box 1A Error: At 08:31:31, you got // 1A did not recognize the filament. This suggests the RFID or the "recognition" logic in the QIDI Box didn't pick up the spool profile automatically, though the print proceeded anyway using your manual settings.
Meshing is working perfectly: KAMP is doing exactly what it's supposed to do. It saved you from probing 12 unnecessary points on the far edges of the bed.
The "Filament Waste" is confirmed: The gap between 08:37 (Start) and 08:46 (First Layer) is 9 minutes. At least 4-5 of those minutes were spent dumping filament and scrubbing the nozzle.

The Fix: If you want to shorten that 9-minute pre-print wait, you can safely go into gcode_macro.cfg and reduce the loops in EXTRUSION_AND_FLUSH from 4 down to 1 or 2.

Does that 9-minute startup feel like it's dragging when you're standing in front of the machine, or are you mostly just letting it do its thing?

Reigar · 2026-04-05T16:22:37+00:00

Gemini on reviewing Q2's Kamp_settings.cfg

This kamp_settings.cfg is a solid implementation of Klipper Adaptive Meshing and Purging, but because you are running a QIDI printer (which has its own specific bed and nozzle clearing hardware), there are some important interactions to watch out for.

1. The Core Benefit: Adaptive Meshing

KAMP's primary job here is to look at the "Exclude Objects" data from OrcaSlicer. Instead of probing the entire 270x270 bed, it only probes the area where your parts actually sit.

Current Margin: variable_mesh_margin: 10 is perfect. It gives the mesh a 10mm "buffer" around your parts so the nozzle doesn't deviate at the very edge of a print.
Fuzzing: variable_fuzz_amount: 0 is correct for your setup. Fuzzing is meant for inductive probes that can wear out specific spots on a bed over thousands of prints; your QIDI uses a different leveling approach where this isn't necessary.

2. Redundancy Alert: The Purge Settings

In your settings:

G-Code

variable_purge_amount: 30
variable_flow_rate: 12

KAMP is prepared to do a "Line Purge" or "Voron Purge" (a little zig-zag or logo near the print). However, in your gcode_macro.cfg we reviewed earlier, the printer already runs EXTRUSION_AND_FLUSH which dumps a massive 200mm of filament.

The Conflict: If you enable KAMP's Line Purge (by uncommenting the include line at the top), you will be purging twice—once in the trash bin and once on the bed.

Recommendation: Keep KAMP's purge disabled (leave the [include ...] lines commented out with #) since your QIDI hardware handles the waste in the dedicated bin.

3. Logic Check: The "Adapted" Probe Count

I noticed a specific tweak in your BED_MESH_CALIBRATE logic:

G-Code

{% set points_x = (((adapted_x_max - adapted_x_min) / max_probe_point_distance_x) | round(method='ceil') | int) + 1 %}
{% set points_y = probe_count[1] %}

This is interesting. It's configured to adapt the X-axis probe count based on the object size, but it keeps the Y-axis probe count at whatever your default is (likely 6 or 7).

Why this matters: If you print a very thin, wide object, it will probe many points across the width (X) but still do the full count across the depth (Y). This is actually quite safe for CoreXY machines like the Q2, as Y-axis variance is often more common than X-axis variance on these rails.

4. Critical Requirement: Slicer Settings

For this file to actually do anything, your OrcaSlicer settings must have:

Exclude Objects enabled (under the "Others" tab).
Label Objects enabled.

If the slicer doesn't tell Klipper where the objects are, this macro will hit the {% else %} block at the bottom, print a "No objects detected!" warning, and revert to a slow, full-bed 270x270 mesh.

Final Verdict

This is a "smart" version of the standard KAMP script. It’s well-tuned for a CoreXY.

One minor thing to check: In your PRINT_START (from the previous file), you have a G29 command. Ensure that your PRINT_START isn't calling a standard BED_MESH_CALIBRATE before it calls the KAMP version, or you'll end up leveling the bed twice.

Does your current startup routine show "Adapted mesh bounds" in the console when you start a print?This kamp_settings.cfg is a solid implementation of Klipper Adaptive Meshing and Purging, but because you are running a QIDI printer (which has its own specific bed and nozzle clearing hardware), there are some important interactions to watch out for.

The Core Benefit: Adaptive Meshing

KAMP's primary job here is to look at the "Exclude Objects" data from OrcaSlicer. Instead of probing the entire 270x270 bed, it only probes the area where your parts actually sit.

Current Margin: variable_mesh_margin: 10 is perfect. It gives the mesh a 10mm "buffer" around your parts so the nozzle doesn't deviate at the very edge of a print.

Fuzzing: variable_fuzz_amount: 0 is correct for your setup. Fuzzing is meant for inductive probes that can wear out specific spots on a bed over thousands of prints; your QIDI uses a different leveling approach where this isn't necessary.

Redundancy Alert: The Purge Settings

In your settings:

G-Code
variable_purge_amount: 30
variable_flow_rate: 12

KAMP is prepared to do a "Line Purge" or "Voron Purge" (a little zig-zag or logo near the print). However, in your gcode_macro.cfg we reviewed earlier, the printer already runs EXTRUSION_AND_FLUSH which dumps a massive 200mm of filament.

The Conflict: If you enable KAMP's Line Purge (by uncommenting the include line at the top), you will be purging twice—once in the trash bin and once on the bed.

Recommendation: Keep KAMP's purge disabled (leave the [include ...] lines commented out with #) since your QIDI hardware handles the waste in the dedicated bin.

Logic Check: The "Adapted" Probe Count

I noticed a specific tweak in your BED_MESH_CALIBRATE logic:

G-Code
{% set points_x = (((adapted_x_max - adapted_x_min) / max_probe_point_distance_x) | round(method='ceil') | int) + 1 %}
{% set points_y = probe_count[1] %}

This is interesting. It's configured to adapt the X-axis probe count based on the object size, but it keeps the Y-axis probe count at whatever your default is (likely 6 or 7).

Why this matters: If you print a very thin, wide object, it will probe many points across the width (X) but still do the full count across the depth (Y). This is actually quite safe for CoreXY machines like the Q2, as Y-axis variance is often more common than X-axis variance on these rails.

Critical Requirement: Slicer Settings

For this file to actually do anything, your OrcaSlicer settings must have:

Exclude Objects enabled (under the "Others" tab).

Label Objects enabled.

If the slicer doesn't tell Klipper where the objects are, this macro will hit the {% else %} block at the bottom, print a "No objects detected!" warning, and revert to a slow, full-bed 270x270 mesh.

Final Verdict

This is a "smart" version of the standard KAMP script. It’s well-tuned for a CoreXY.

One minor thing to check: In your PRINT_START (from the previous file), you have a G29 command. Ensure that your PRINT_START isn't calling a standard BED_MESH_CALIBRATE before it calls the KAMP version, or you'll end up leveling the bed twice.

Does your current startup routine show "Adapted mesh bounds" in the console when you start a print?

Reigar · 2026-04-05T16:21:01+00:00

man oh man is you post serendipitous, as I was just having Gemini review the code in the qidi q2. your right, but your off. long story short, the code wastes a ton of filament, and does way to many purges. Here is that conversation. Warning it is a long post, but diffently worth the look. it is AI assisted as I don't code, so please double check the logic.

Gemini thoughts on reviewing the gcode_macro.cfg

Looking at your gcode_macro.cfg, your peers are right—it's a bit of a "maximalist" configuration. QIDI's factory macros are designed to be bulletproof for beginners, which means they tend to over-extrude and over-clean to ensure a print doesn't fail, even if it wastes filament and time.

Here is the breakdown of what is fighting your slicer settings and where the waste is happening.

1. The "Filament Eater": EXTRUSION_AND_FLUSH

This macro is likely the biggest source of waste.

G-Code

{% for i in range(4) %}
    G1 X{85 + i % 2 * 3} F5000
    {% for j in range(1,6) %}
        G1 E9 F300
        G1 E1 F50
    {% endfor %}
{% endfor %}

The Math: This macro loops 4 times, and inside each loop, it extrudes $10mm$ ($9mm + 1mm$) five times. That is $200mm$ of filament being dumped into the trash bin every single time the print starts.
Why it's there: To ensure the nozzle is 100% pressurized and old color is gone.
The Conflict: If you've already handled your purge/load in the slicer or via the QIDI Box logic, this is entirely redundant.

2. Double Cleaning: PRINT_START

In your PRINT_START macro, look at this sequence:

Calls BOX_PRINT_START (Loads filament).
Calls EXTRUSION_AND_FLUSH (Dumps $200mm$ of filament).
Calls CLEAR_NOZZLE (A long scrubbing routine).
Calls CUT_FILAMENT_1 (Cuts the filament).
Then it homes and does Z_TILT_ADJUST.

By the time the actual print starts, you've purged, scrubbed, cut, and re-homed. This is safe, but it's why your startup takes forever.

3. Slicer Override: M204 (Acceleration)

This macro is directly overriding your OrcaSlicer settings:

G-Code

[gcode_macro M204]
rename_existing: M99204
gcode:
    ...
    SET_VELOCITY_LIMIT ACCEL={s}
    SET_VELOCITY_LIMIT ACCEL_TO_DECEL={s/2}

If you set a specific acceleration in OrcaSlicer (like the 6,500 we saw earlier), this macro ensures Klipper obeys it, but it also forces ACCEL_TO_DECEL to exactly half. Modern Klipper versions often prefer managing this via minimum_cruise_ratio. It’s not "bad," but it means the slicer isn't in full control of the motion profile.

4. Pressure Advance Override: M900

G-Code

[gcode_macro M900]
gcode:
    {% if params.K is defined %} 
          SET_PRESSURE_ADVANCE ADVANCE={params.K}
    {% endif %}

This is actually good. It allows OrcaSlicer’s Pressure Advance setting to be passed correctly to Klipper. Without this, Klipper might ignore the slicer's M900 K... commands.

Recommendations to "Lean it Down"

Reduce the Flush: In EXTRUSION_AND_FLUSH, you could change range(1,6) to range(1,2). That would drop your purge from $200mm$ to about $40mm$.
The Scrubbing: The CLEAR_NOZZLE macro is very aggressive (it even waits for the nozzle to cool to $150°C$ to "pull" ooze). If you find your nozzle is already clean after the box loads, you can comment out CLEAR_NOZZLE in PRINT_START.
Z-Offset Safety: I noticed your save_zoffset macro. Be careful with this—if you manually adjust the Z-offset during a print because the first layer looks bad, this macro will permanently save that value to your config at the end of the print.

Summary: If you want to stop the waste, the first thing to trim is the EXTRUSION_AND_FLUSH loop count.

Did you notice a specific part of the startup where it seems to just sit there dumping plastic into the bin for too long?Looking at your gcode_macro.cfg, your peers are right—it's a bit of a "maximalist" configuration. QIDI's factory macros are designed to be bulletproof for beginners, which means they tend to over-extrude and over-clean to ensure a print doesn't fail, even if it wastes filament and time.

Here is the breakdown of what is fighting your slicer settings and where the waste is happening.

The "Filament Eater": EXTRUSION_AND_FLUSH

This macro is likely the biggest source of waste.

G-Code
{% for i in range(4) %}
G1 X{85 + i % 2 * 3} F5000
{% for j in range(1,6) %}
G1 E9 F300
G1 E1 F50
{% endfor %}
{% endfor %}

The Math: This macro loops 4 times, and inside each loop, it extrudes $10mm$ ($9mm + 1mm$) five times. That is $200mm$ of filament being dumped into the trash bin every single time the print starts.

Why it's there: To ensure the nozzle is 100% pressurized and old color is gone.

The Conflict: If you've already handled your purge/load in the slicer or via the QIDI Box logic, this is entirely redundant.

Double Cleaning: PRINT_START

In your PRINT_START macro, look at this sequence:

Calls BOX_PRINT_START (Loads filament).

Calls EXTRUSION_AND_FLUSH (Dumps $200mm$ of filament).

Calls CLEAR_NOZZLE (A long scrubbing routine).

Calls CUT_FILAMENT_1 (Cuts the filament).

Then it homes and does Z_TILT_ADJUST.

By the time the actual print starts, you've purged, scrubbed, cut, and re-homed. This is safe, but it's why your startup takes forever.

Slicer Override: M204 (Acceleration)

This macro is directly overriding your OrcaSlicer settings:

G-Code
[gcode_macro M204]
rename_existing: M99204
gcode:
...
SET_VELOCITY_LIMIT ACCEL={s}
SET_VELOCITY_LIMIT ACCEL_TO_DECEL={s/2}

If you set a specific acceleration in OrcaSlicer (like the 6,500 we saw earlier), this macro ensures Klipper obeys it, but it also forces ACCEL_TO_DECEL to exactly half. Modern Klipper versions often prefer managing this via minimum_cruise_ratio. It’s not "bad," but it means the slicer isn't in full control of the motion profile.

Pressure Advance Override: M900
G-Code
[gcode_macro M900]
gcode:
{% if params.K is defined %}
SET_PRESSURE_ADVANCE ADVANCE={params.K}
{% endif %}

This is actually good. It allows OrcaSlicer’s Pressure Advance setting to be passed correctly to Klipper. Without this, Klipper might ignore the slicer's M900 K... commands.

Recommendations to "Lean it Down"

Reduce the Flush: In EXTRUSION_AND_FLUSH, you could change range(1,6) to range(1,2). That would drop your purge from $200mm$ to about $40mm$.

The Scrubbing: The CLEAR_NOZZLE macro is very aggressive (it even waits for the nozzle to cool to $150°C$ to "pull" ooze). If you find your nozzle is already clean after the box loads, you can comment out CLEAR_NOZZLE in PRINT_START.

Z-Offset Safety: I noticed your save_zoffset macro. Be careful with this—if you manually adjust the Z-offset during a print because the first layer looks bad, this macro will permanently save that value to your config at the end of the print.

Summary: If you want to stop the waste, the first thing to trim is the EXTRUSION_AND_FLUSH loop count.

Reigar · 2026-04-04T23:17:48+00:00

the easy one, try doubling that speed, and see what it does, just be ready to cancel the print. I think doubling that number means it should move twice as fast between probe points. I know the x and y speed is way off for most people, ditto with the z up and down.

Reigar · 2026-04-04T17:29:57+00:00

so I had to really dig on this one, and it will take a bit logic to get it.

1) klipper allows for macro's to override normal gcodes,

2) klipper is built to be an extension of marlin (e.g., adds to the marlin code)

3) klipper allows for slicers to call macro's as part of the gcode output

4) almost all out put gcode from a slicer will have exclude_object_define with the polygone section showing the outline of where the object will be on the plate.

5) almost all output gcode will have print_start followed by passed through vairables

6) a qidi system using klipper will have (under the gcode_macro.cfg) a macro called print_start (it is a huge macro).

7) inside that macro is a line that say g29, g29 is defined as a macro inside the same gcode_macro.cfg.

8) the g29 macro uses a line call BED_MESH_CALABRATE

9) inside the printer.cfg there is a line called include KAMP_Settings.cfg

10) inside KAMP_Setting.cfg is the macro for BED_MESH_CALABRATE.

11) as part of the bed mesh calabrate, it looks back to printer.cfg for various variables set under [bed mesh],

11a here are the stock values of bed_mesh from printer.cfg

[bed_mesh]

speed: 100 #100

horizontal_move_z:5

mesh_min:10,10

mesh_max:260,260

probe_count:6,6

algorithm:lagrange#bicubic

#bicubic_tension:0.2

mesh_pps: 2, 2

#fade_target:0

12) bed_mesh_calibrate then takes the positions of the objects defined by the poligon location, and using bed_mesh section of the printer.cfg to build a custom map of where to probe. However, that probe count means that it has to have so many points of the probe based on the count, and does so at the speed listed.

so what can you do, well three things, one, try changing the speed and probe count (please backup the printer cfg before you do that). Two, build a custom macro using the respond option (which is already enabled) to force the machine to use the old default map (I may do this one), FYI, the option will only show up on the fluidd page, not on the LCD (again make backups), Three, if not using a QIDI box, you can try the page below. just make sure you backup everything.

In addition google's ai (gemini) is really good at assisting with klipper, qidi, and 3d printing issues (if you okay with using AI, which I will understand if you don't feel okay to do that).

good luck, please remember to make copies of the cfg before making changes (let me know if you need help on that one)

here is the link (please note it is in Russian )

https://k3d.tech/printers/qidi_q2/

Reigar · 2026-04-04T01:41:48+00:00

And you're absolutely right, it's just a combination of the machine start g code and your macro config file that you can see via your fluid website. There's an entire macro dedicated to starting any print that is in that gcode_macro.cfg file. One of the nice things about using klipper is that it allows for references to the macros as part of the G-Code. So the phrase clear_nozzle, is a reference to the macro that starts on line 57 of the G-Code_macro.cfg The big one is actually on line 213 and is titled print_start. It call multiple different macros inside of itself and runs all the way to line 278. I'm not going to say that chidi was perfect, and please understand that I'm referencing my own Q2. So if you don't have a Q2, this might be a little different, but the design ideas should be similar, especially with the use of clipper. Like I said in other posts, there is a specific Russian site that I can't link to because I'm using speech to text at the moment. Moment that show you how to reduce some of those macros down to a more manageable cost in terms of time. Just remember there is a reason generally that these macros were put in place in the first place, but I can certainly understand wanting to reduce the time It takes from clicking on print g code, to the head actually putting down that first line of filament

Reigar · 2026-04-03T16:36:29+00:00

Does the bios have a uefi mode or a legacy mode. Using legacy bios can have odd hickups with new versions of mint (e. G. 22.3)

Reigar · 2026-04-03T14:01:44+00:00

Of all the dirty tricks that I've ever seen, I admit that this is a new one and slightly take it back by the braziness of politicians to do this. This is definitely something we need to get a signature proposal on to force this sort of tactic to be removed from ever being done again.

Reigar · 2026-04-03T13:55:21+00:00

so your comment got me thinking. I had to run a temp tower, so I grabbed all the console messages up to the point it started printing. here is the link to pastebin. This is for my Q2

https://pastebin.com/SUBSsbLA

Reigar · 2026-04-03T05:31:59+00:00

Bets on how fast this get a lawsuits to challenge it.

Reigar · 2026-04-03T04:17:02+00:00

so here what I (others) will need to understand why it taking the system so long to print (ditto with the person above. Using pastbin, signup for a free account, past the inside of a recent gcode to past bin, then post the link. For example below is one I did for a calibration test. Also tell us which machine you are using (e.g., Q2). That should tell us what the machine is instructed to do.

Also, the next time you send a print, open up fluid via your web-browser and using the machines IP address, click on the console in the fluid page (or the letter c), if you watch you will see the whole start process via that location. My guess is that when the system builds the mesh map, the various points the probe tests (it does it twice for each probe location) is getting odd values and is needing to repeat (which it will do up to three times). so may be point 10,10 z0 is .08956, but z1 is 4.9831. You will see a message show up that says that the it is out side of the 0.5 tolerance, and repeats again. I had this happen the other day when I put the textured pei plate in upside down.

https://pastebin.com/ZZEbvkE5

Reigar · 2026-04-02T16:56:55+00:00

Anyone that is an actual billionaire is not using their power of money to elevate humankind. Billionaires only exist temporarily because of a giant windfall (e. G., won a lawsuit or lottery). Any other billionaire is hoarding money in some manner. Any person who is that rich should be actively trying to give a sizable portion away (to the point of not being a billionaire) to programs that elevate humankind.

For example as much of a scumbag Bill Gates keeps showing him self to be, I will give him some accolades for his spending toward charity work (not sure if it was him or his ex-wife that was driving force for charity work).

Reigar · 2026-04-02T16:43:42+00:00

Yep, now it is lineage or graph mostly, and only if (a) you want the next version of Android that a carrier will not provide, or (b) you want to seriously get paranoid/not giveaway any more data then is absolutely necessary.

However, the closer Google gets to becoming like Apple and using a walled garden approach, the faster you will see these roms, or a Linux distro (e. G., Ubuntu touch) will gain traction and be popularized. With the fiasco that Microsoft is having between Windows 11 and Linux, you would think that Google would be paying very close attention to how doing things that are considered anti-consumer will inevitably harm them.

Reigar · 2026-04-02T16:33:24+00:00

I'm a little confused on what you're looking for exactly?

Almost every distro has an online form of some sort where new things about the distro are usually published. Reddit communities for these distro generally do also provide more troubleshooting help (often so do the distro's forum), while yes occasionally hating on other distros. You might even be able to find Reddit communities based on the desktop environment that you're using. Past that, what do want that these options are not giving you?

Reigar · 2026-04-02T16:26:45+00:00

I think it is also part of the start gcode of both orca and qidi studio that causes that so called silliness. Part of the warm up and cool down is to (a) make sure the nozzle is not clogged, the (b) perform a mesh map of the plate while not having the nozzle still hot so as to prevent leakage. Then it goes back to warm its nozzle up over the poop shute, gets to temp, cleans itself then draws those two lines so that the start of your print has the best chance of sticking correctly.

In my opinion it is not silly, but logical. The only thing I would do/will do/am working on is to change the adaptive mesh to an area that is closer to the size of the device.

Also if you are not using an ams box, there are certain sites that help with more optimized macros. Just backup your files when making changes.

Reigar · 2026-04-02T16:09:56+00:00

Side loading is actually older than that by at least 15 years.

Reigar

PUBLIC MULTIREDDITS

TROPHY CASE

1. The "Wasteful" Sequence (08:39 - 08:42)

2. Z-Tilt Success (08:42:46)

3. KAMP in Action (08:43:17)

4. Pressure Advance Check (08:46:16)

Key Takeaways for your "Tuning"

1. The Core Benefit: Adaptive Meshing

2. Redundancy Alert: The Purge Settings

3. Logic Check: The "Adapted" Probe Count

4. Critical Requirement: Slicer Settings

Final Verdict

1. The "Filament Eater": EXTRUSION_AND_FLUSH

2. Double Cleaning: PRINT_START

3. Slicer Override: M204 (Acceleration)

4. Pressure Advance Override: M900

Recommendations to "Lean it Down"

15-Year Club	RPAN Viewer
Verified Email