IDEX XY Offset drift (VC4)
My Vcore 4 prints well so far. But while printing a large multi-colour model, I noticed a problem. My XY offset drifts on higher models. While it is perfect on the lower part of the print, it drifts more and more until (in this case) it overextrudes areas and the toolhead loses steps when hitting it.
At first I thought it was some sort of thermal expansion etc, but this happened when printing PLA with all the panels off.
Any ideas? I'll do some more testing tomorrow.
84 Replies
have you measured with calipers in the areas i have marked , they should be the same if not +/- .1 mm would be good
also what does the back side look like
The issue is only on the X axis.
I also tried ABS with a 2h+ preheated chamber. Did not fix it.
I have a few question.
1) What happens if you only use the second color near the top of the print the last 5 layers ??
2) Does the part show a twist if you put it on a flat surface?
3) Have you checked to see if every part is tight on all three z axis motors??
(see image attached)
I should give a quick update. I printed 1kg+ just for multicolour test towers.
At first I thought it was some sort of thermal expansion issue, so I tried various things with ABS heat soaked for several hours and pla completely open and cooled.
I then measured the angle to the print bed at a precise angle. I found that both were drifting. So Im pretty sure this is neither a driver nor a motor issue.
I then printed a single tower with only one tool head. This was perfectly 90° to the bed. At this point I was pretty sure it was a software issue/bug. I completely reinstalled ratos and did the configuration.
I started a print yesterday (ABS) which came out perfectly this morning. I printed it again to check the results. Calibrated VAOC (without Z) and re-generated the gcode in the slicer. I did not change anything else... and again... the issue is back.
Also tested all corners
1. This is also on my test todo list.
2. It is "straight" and not straight. If you just use a flat ruler and put it against the surface, it looks straight because of the almost perfect fade. But measured against the top/bottom it is not straight.
3. It's not a problem with the Z axis, because that would twist both tool heads. The angle check also shows that there is no problem.
Would it be possible for someone to print my test on ther VC4 IDEX? I just want to make 100% sure there is no slicer issue.
the 3mf is for the lates Orca version.
So now I have tested even more things:
I tried the original Prusaslicer profile without any changes.
I completely flashed RatOS again, updated everything. I even flashed it a third time without updating to see if it was a post-processor problem.
I tried different microstepping values, disabled driver tuning, removed the wipers, reduced max speed and acceleration, re-tuned input shaper...
I printed the tower using only the left and right tools. In this case I cannot measure any drift at all. It's perfectly 90° to the bed.
I can't find the problem.
Also, the problem is really inconsistent. Sometimes I have almost no drift, sometimes a few millimetres.
I don't have enough experience with idex but I believe the problem is somewhere in the Z offset/Home/bed tilt per tool head.
My friend on the other hand
Thinks if it's inconsistent then it's a mechanical problem.
Seems like the volume does not affect the issue.
AFAIK there is no toolhead dependent z tilt or bed mesh. So this does not change during tool switches.
Here are some more updates:
I made around 100 manual tool changes in mainsail and checked with VAOC to see if my offset had changed, but this seems to work just fine. Everything is within the acceptable range.
I did another test print yesterday. I printed a tower and cancelled it using CANCEL_PRINT_BASE. This way, the motors stay on and I can check the offset with VAOC. There is definitely a T1 offset, but T0 seems fine, which does not match my angle tests.
I let everything cool down, but it seems like the offset doesn't recover.
Cold:
I then swapped the MOTOR4 driver for a BTT V1.2 2209 that I had lying around, but nothing changed.
Next, I'll check if the offset changes if only T0 or T1 prints. This time, I'll use VAOC, which is far more accurate.
Can you check the set screw on your X axis motors to make sure that at least 1 of the 2 set screw are hard set into the flat of the shaft , see image below.
Already checked this
Another small update.
A few more things I tried:
Removing a Y belt. The idea was to see if there was some sort of Y axis desync that would cause the Y axis to twist and result in X movement of both tool heads.
Unfortunately I still had the known issue.
I then tried heating the printer and checking the offset via VAOC. While the offset did move a little, this was done intentionally with the bed at 115°C and the bed fans on. So I don't think this should be a problem when printing with PLA.
Here are the VAOC results:
Before heat soaking
after 10 min
after 45 min
I then tried to readjust all the belts. This time using the maximum tension I feel comfortable with for a 9mm GT2 belt.
Some updates:
I moved the printer into a warmer room this weekend, as my basement is only ~10°C.
-> No fix or effect.
I wrote some simple gcode to test toolchanges outside of a print file, using conditions as close to a print as possible, like hotend temp (150°C) and heated bed temp (60°C).
The gcode looked something like this
T0
G0 X0 Y0 F48000
G0 X300 Y0
G0 X300 Y300
G0 Y0 Y300
G0 X150 Y150
T1
G0 X0 Y0 F48000
G0 X300 Y0
G0 X300 Y300
G0 Y0 Y300
G0 X150 Y150
...
After ~170 tool change cycles (T0 -> T1 -> T0, actually more like 340) I checked the offset via VAOC. There was no drift at all.
So my guess is that there is some kind of compensation that is only active during printing and stacking, which causes this drift.
While I'm familiar with Klipper, I don't know much about how RatOS works in the background or how the post-processing script works.
And another update...
I disabled the post-processing script and dried another print.
-> Same result.
I reinstalled RatOS completely and configured the absolute minimum for printing. This means no IS, no E-steps, no LED light etc.
-> Same result.
At this point I'm not sure what to try next. I could start replacing all components step by step, but since T0 or T1 sometimes drifts, I think it is very unlikely that a stepper is defective.
___
Here are some more test results I forgot to post:This is INVALID! I printed the same file that had been modified by the post-processor!
No post-processing script
-> T0 drifts
Test at room temperature
-> T1 drifts
Single print with T1 only
-> No drift
Single print with T0 only
-> No drift (negiable)
i think you should start fishing around in other chats for someone with a green name that can help you.
This is a good idea. But I think I have finally found something. I just need to do some more tests.
I found my issue! At least sort of.
The test I did before without the post-processor was invalid because the file had already been printed once with the post-processor.
With a fresh file directly from Orcaslicer and no post-processing the issue is gone.
I think the actual issue is not the post-processed gcode itself, but the toolshift feature which is only enabled when using post-processed gcode.
Maybe @miklschmidt or another dev can help me with this?
Here is the VAOC check after printing:
The test tower:
You will get random results as long as you don't properly calibrate the pixel per mm as instructed in the documentation.
The inner circle is supposed to match the nozzle orifice, the outer circle should match the outer ridge of the flat part of the nozzle.
I calibrated the pixels per mm. The nozzle only has a small chamfer on the inside. But yes, the outer diameter is not set correctly. But I think this is not the problem, as the VAOC calibration itself works perfectly. My problem is that the offset drifts during printing when using the toolshift function.
I know it's a lot, but have a look at the first few messages and pictures.
I should also give a proper explanation of how I use VAOC here for testing:
First I calibrate VAOC, then I start a print (test model). After ~300 layers I stop and cancel the print with CANCEL_PRINT_BASE so that the steppers don't turn off. Now I can start the VAOC calibration again and check the drift after the print. That's what all the pictures I posted here are for.
I agree, you really need to look at the first few messages
Since the last debug zip is over 3 weeks old, here is the latest one. I haven't changed much, but I don't think it's a good idea to debug with old files.
That's indeed strange, however i'm not following the conclusion that it's a software related toolshift issue, if it was you should be able to reproduce it on a cold printer by simply toolshifting enough times, no printing, no movement in Z.
i would also expect everyone to have the same problem.
Indeed this is what thermal expansion looks like. This is dependent on your belt equalization, if they're not the same exact length between attachment points and tensioned equally they will drift in different ways. Y's need to match and X/DC needs to match.
Another thing you can try is reversing the hotend cooling fan.
But since that last test is without heating the hotend (right?) it points to belts.
I would not expect that much expansion shenanigans with the panels off printing PLA though, however it's still a thing.
I think the actual issue is not the post-processed gcode itself, but the toolshift feature which is only enabled when using post-processed gcode.I still think this is unlikely, the offset code is essentially the same. Can you reproduce it with a different slicer, eg. PrusaSlicer?
Thermal expansion was also my first idea. I tried retentioning the belt 3 times. I also did a heatsoak at ABS temps with VAOC checks. But still after 45min there was no drift. https://discordapp.com/channels/582187371529764864/1332474133598044281/1337874370475065384
Yes, I was able to reproduce it with Prusaslicer, completely stock profiles without a single change.
I’m seeing quite a lot of drift in that test
Yes, there is definitely some drift, but not nearly enough to give the print results I got.
The difference between 10 and 45 is illustrating (at least part of) the problem
I assume your gantry was parked at the back the entire time?
Also this drift continues past the 1 hour mark
No i parked it few mm above the bed to also heatsoak it
Did you return to that position after each vaoc check?
yes, after VAOC it moves the head to the middle. I just lowered it again
Okay good. Do you have any theory as to why noone else is seeing this issue if you can reproduce it with stock PS profiles?
I'm also wondering why only I have this issue tbh. I have no idea.
Imo that makes it difficult to argue that the toolshift code itself is causing the issue
Unfortunately, since this is a first, it’ll require that someone can reproduce it to help figure out what’s going on.
I will link this thread internally and see if the other devs have any ideas
OK, thank you!
I'll continue my tests and try to narrow down exactly when this happens.
I have done some more testing and want to share the results.
Setup:
- I changed the extruder & extruder1 rotation distance to 999999999999, which "disables" extruder movement
- Set min extruder temp to 0
- VAOC calibrated before each test
What I have tested:
- Simply printing with no heaters (Bed, Hotends), to be 100% sure there is no thermal issue.
Please note that I did not cancel each print at the exact same height.
Post Processor enabled -> Toolshift - Test 1
Post Processor enabled -> Toolshift - Test 2
- Post-processor enabled
- Edit already post-processed file:
- replaced
T0 with T0;
- replaced T1 with T1;
-> This will comment out the XYZ coordinates that the post processor adds to the toolswap, thus disabling the toolshift feature.
For some reason I also got Y-drift. Unfortunately I am really struggling to get a repeatable pattern on the tests.
But I think this shows that there is a issue with the toolshift feature at least on my setup.
@Helge Keck any idea what's going on here?
skewed gantry and/or uneven belt tension
try to realign the gantry and the y rails
I have tried to tighten my belts from "scratch" 3 times now. I also checked the gantry by unscrewing all 4 belt tensioners. Tbh, I'm not sure I should be messing with it when it's currently running smoothly and is square, as it took me 1.5 hours to get it perfectly aligned when I built it. Much more difficult than the Vorons I built before.
But I can check everything again today.
the error you described here with the offset is very likely coming from a skewed gantry or uneven teniosned belts or belt length
its a common issue
make sure the gantry isnt skewed when the belts are attached
if you cant make it work just use the klipper skew compensation
the toolshift and VAOC will take it into account
after the skew calibration you ened to redo VAOC
Ok, I'm not sure how a screwed gantry can cause drift that increases linearly with each layer, only when toolshift is enabled, but I'll try it anyway.
At least it makes no sense to me.
i have seen this behaviour before, and it was always mechanical alignment issues
the toolshift software part doesnt make anything magic, it jsut moves two motors at the same time, there is basically no way that this is software rleated
I started a test remotely out of curiosity.
Postprocessor and toolshift enabled, but toolchange speed limited to 100mm/s and 1k accel.
WRONG!: I have a rough idea why the problem does not occur when toolshift is disabled.
I'm not sure if I remember the belt paths / motors correctly, but when a toolhead switches it applies a twisting force to Y (belt pulls on one side) which the hybrid Y belts counteract.
If both heads switch and accelerate at the same time, this force doubles, causing enough friction (in combination with the other stuff like bearings) to lose single steps (afaik you can't lose microsteps, right?).
Just a theory. I'll check it out when I get home.
If it's belt tension / skewed gantry, why is it only mucking things up when using toolshifts?
the normal _SELECT_TOOL stuff applies the offsets as well
You can't loose single steps either, you'll loose at least 4 full steps.
I don't understand it either. My theory I posted earlier is wrong btw. toolshift actually cancels out the forces and should therefore be better than single swap.
I checked my gantry again. X has no resistance at all and Y is also good I would say. I didn't remove the belts so it's hard to show on video.
I also checked the gantry and there is no skew, referenced to the front stops.
Also if you lose at least 4 steps (did not know this before) there would be a lot more stepping to the drift.
I'm not sure if I've mentioned this before, but I also checked to see if the gantry "unskews" or something when the motors are disabled. I noticed nothing of the sort.
I continued my tests.
Replaced the psu with a Meanwell LRS-350, disconnected all unneeded wires like LEDs etc and checked all wires.
Also checked my gantry again.
Nothing I do changes the issue.
The last idea is to replace the whole mainboard.
Again, if I disable toolshift, the issue is gone.
At this point I have pretty much tried everything, whether it makes sense or not.
@miklschmidt, how much effort would it be to add an option to disable toolshift? I've been working on this problem for a month now, spending several hours a day on it. I think I spend 2-3 times the time trying to fix this issue than actually building the printer. At this point I am willing to accept the compromise to finally be able to print usable parts after 400h of just printing tests.
i wouldnt give up right now. you could first enable the debug mode, reproduce the issue and then share the debug.zip file
just to rule out any macro bugs, but i still believe its not
you ca also monitor the debug outout from the toolshifts while printing in the console, when enabling the debug mode
it spits out all kind of data you can use to find out if the software is the issue
it tells you the applied offsets for every toolshift
it could also be something completely different like a partly loose oldham coupler on one of the arms
or some kind of custom gocde commands in your slicer layer change or filament gcode
or poorly aligned z rails
Sure, I can share the debug.zip of the next print.
I checked the Z axis. Did not find anything wrong. Even if it was a Z problem, the tower as a whole would be tilted unless it was changing direction with each toolchange.
I did a complete reinstall twice with the bare minimum setup acording to the guide. No extra macros, config changes etc.
Also tried stock VC4 IDEX Prusaslicer profiles with the bare minimum setup. Same issue
Luckily I found a old Octopus in my electronics box. I'm currently swapping the board.
I have just finished printing with the other board. Still the same issue.
I think after swapping the psu, mainboard and drivers I can say its not an electronic problem.
Here is the debug.zip after the last test print.
did you enabled the debug mode?
yes
I canceled the print because I could already see the drift. Since I already wasted ~2-3 kg for printing test towers I try to minimize the waste 😅
please share the 3mf file
Orca V2.2.0
so from your log, RatOS does everything correct
i have checked the critical output from your history and ratos is always using the correct values
So its been some days. I again spend many hours trying stuff. Here a short list:
- I compledtly dissasembled my X Gantry. and realigned the Y linear rails. I think I got it pretty much as good as it gets, considering the rails have some resistance from the grease (see vid). It's a tiny bit better than before.
- I checked every single bearing and belt
- I completly disassebled both hotends and reasebled them. Changed the thermistor on T1 from Generic 3950 back to PT1000 (had a broken one)
- Switched out all umbilical wires to the toolhead and changed to a igus CF9 power wire.
Nothing of this changed anything regarding the issue. Idk what to try next.
Is there an easy way to disable Toolshift? Maybe by disabling part of the post processor.
I want to try more complex/longer prints with toolshift disabled, but replacing stuff by hand (especially on larger files) is not a good/reliable solution.
@miklschmidt, can you maybe give me a hint on how to disable toolshift?
in your toolhead config macros add thsi here
Okay, thanks. I'll try this.
Following, interesting issue. I can try and print your model on my idex on sunday 👍
Thanks, would be great
Tried adding this to both toolheads. But it does not disable toolshift when its set to 0 as long as XYZ is provided. Not sure if this is how it should be.
When XYZ is set to the default it almost behaves as expected. For some reason Z does not travel up after a z hop (only purge tower)
Fixed it by adding to layer change gcode:
T{next_extruder}
G0 Z{layer_z} F1500 ;move down after z hop
[gcode_macro T0]
gcode:
{% set x = params.X|default(-1.0)|float %}
{% set y = params.Y|default(-1.0)|float %}
{% set z = params.Z|default(0.0)|float %}
{% set s = params.S|default(1)|int %}
{% if printer["gcode_macro _SELECT_TOOL"] is defined %}
_SELECT_TOOL T=0 X=-1 Y=-1 Z=0 TOOLSHIFT=0
{% endif %}
Have you been able to do any testing yet?
Im currently running a 1d print and already 17h in with no drift issues so far.not yet but thank you for the reminder, will start it now