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.
415 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
@Helge Keck I looked at the _TOOLCHANGE macro in toolchange.cfg.
Only
{% if not is_printing_gcode and not toolshift %} and {% if not is_printing_gcode and toolshift and new_x < 0 and new_y < 0 %} is specified.
There is no {% if is_printing_gcode and not toolshift %}. In this case it switches to {% else %} which always does a toolshift. As far as I can tell with my limited macro knowledge.
This means that TOOLSHIFT=0 will not work during printing.
Not sure if this is intended or just an unspecified case.sorry, you need to set the x and y parameter to -1
I have done this, but then I have problems with the z-hop.
When the head switches to the purge tower, there is no z coordinate to remove the applied z hop.
Adding
G0 Z{layer_z} F1500 ;move down after z hop to orca fixes the mid air printing, but it moves z up before moving to the tower, hitting any object between the head parking position and the purge tower.
I haven't found a way to fix it yet.
Gcode looks like this:
G1 X152.02 Y160.996 E.02961
G1 X151.303 Y160.28 E.04677
;HEIGHT:0.25
;TYPE:Prime tower
;WIDTH:0.5
;--------------------
; CP TOOLCHANGE START
; toolchange #1
; material : PLA -> PLA
;--------------------
; WIPE_TOWER_START
M220 S100
; CP TOOLCHANGE UNLOAD
;WIDTH:1
;WIDTH:0.5
; Ramming start
; Ramming end
G4 S0
G1 E-1.4 F7200
;WIPE_START
G1 F6000
G1 X152.011 Y160.987 E-.6
;WIPE_END
; filament end gcode
T1 X229.716 Y198.271
M106 S0
; filament start gcode
G1 X229.716 Y198.271 F30000
G1 X229.216 Y196.771
G4 S0
G1 Y197.271
; CP TOOLCHANGE WIPE
;WIDTH:0.5
G1 X180.216 E2.2732 F990
G1 X180.966 Y196.771 E0.0418
G1 X229.716 E2.2616 F1125
G1 X228.966 Y196.271 E0.0418
G1 X180.966 E2.2268 F1374
G1 X228.966 F7200
;WIDTH:0.5
; WIPE_TOWER_END
G1 F30000
G4 S0
G92 E0
; CP TOOLCHANGE END
;------------------
G1 X180.466 Y188.771 F7200
;HEIGHT:0.25
;TYPE:Prime tower
;WIDTH:0.5
G1 X229.466 E2.2732 F3000
G1 Y195.021 E0.2900
G1 X180.466 E2.2732the z coordinate is never used
hm ok. Not sure why I only have this issue when disabling toolshift with X=-1 Y=-1
Tuning in with the exact same issue.
Even with a perfect vaoc, the first layer is off by .2mm with a consistent drift.
Checked gantry skew and belts numerous times.
I don't seem to be the only one with this problem. But for me there is no offset on the first layer, just a drift. Do you have a picture of a test print like the tower I use? How bad is the drift?
Printing one now. The extruders start .2mm too close and slowly drift further apart. They line up at around layer 200/50mm and continue to drift apart.
I may have just figured it out.nope
What is your
[gcode_macro RatOS]
variable_bed_margin_x:
It was generated during the "Calculate DC Endstop" step.
the variable_bed_margin_x variable has nothing to do with the offset drift
its just a border variable to make some calculations
x-offset drift is always a mechanical issue
I made .001mm change and my .001mm per layer drift went away.
the variable isnt involved in the offset calculation
what is your variable_bed_margin_x:?
by chaning the variable_bed_margin_x variable you are just changing the x center lcoation
but if it works for you for whatever reason take it
Can i see your DC endstop calculation as a reference?
i did not use the macro, i configured everything manually
but if you want to see it, these are my last values
mine was done with the macro [59.801, 59.800] and manually changed to [59.801, 59.801]
That’s in printer.cfg
Ratos.cfg is 59.8, 59.8
Maybe i need to change everything, ratos.cfg and printer.cfg to 60, 60? if you saw in my first comments, the first layer alignment is always off by .2mm.
This variable does not affect your toolhead offset. It is for something entirely different.
You have to calibrate VAOC before every print. Motors should not turn of between VAOC and the print start
I'm just curious. Have you done the test print yet?
Call it a lucky roll of the dice then because i deleted the .001 from three places within the DC endstop calculation and the drift entirely went away for three consecutive tests. Until voilà, the drift is back the last two prints.
In ratos-variables.cfg, i changed the x and y control points to the same as the [gcode_macro _VAOC] in printer.cfg. I then did Vaoc without making adjustments to T0. Doing just that caused the drift to switch directions...? Within ratos-variables.cfg,I then replaced both idex_xoffset and idex_yoffset with 0.0. The drift has gone away for the last 3 prints. I have now added the necessary toolhead offsets to the slicer and the current print seems perfect.
I may do a few more test prints but after that I will calibrate VAOC like normal and see if the problem returns.
Can you add some photos with your post
200 steps per revolution times 64 micro steps divided by 40mm per revolution equals 320 steps per mm. 1mm divided by 320 equals .003125. Does this not mean every XY measurement needs to be divisible by .003125. With a Vaoc calculated offset of ex:0.03250380904012218 being added and subtracted every single toolshift, is it possible there is a rounding issue?
I did a VAOC calibration like normal and went into ratos-variables.cfg and rounded all the X and Y measurements to a number divisible by .003125. I've had 1/1 successful prints with zero shift.
The control points are only used to position the nozzle in front of the VAOC cam. They don't affect the print in any way.
I also had the direction changed sometimes. I have not found a way to reproduce this reliably. Also the amount of drift seemed really random.
I also thought there might be a rounding error. But that makes no sense as when the toolshift is disabled it is gone. The way it is applied is the same.
Can you share a picture of your test tower?
Yeah, looks like my towers.
I also managed to get some randomly good ones. So you always have to test 2-3 times to be 100% sure.
Does your drift also vary a lot? sometimes just a mm, sometimes several mm.
This one is really bad for example
https://discord.com/channels/582187371529764864/1332474133598044281/1336240518241189948
I think it would be a good idea if more people print this test. I wonder if more people have this issue and just don't notice it.
When this occurs on a not so tall print where the color transition is on a curve its way harder to see than printing those large, flat faced towers.
not quite the same issue, but VAOC would consistently leave me with an offset on the X, so i ended up just using a printable vernier scale to align it
Looks many people have a idex issue of some sort 😅 Have you printed any tall objects yet? Like my tower? Its kinda hard to tell this on a multi color benchy for example.
Same here, but I just got too annoyed and am now boycotting my RR printer 🙂 When I feel better about it, I'll start searching again what's wrong with that stupid machine...
I am printing this item now, I am not having any change at all after 14mm. Should I have seen an issue yet?
I can see a drift after ~30mm, but it really depends. Sometimes there is a lot, sometimes almost none and only noticeable after ~100mm.
I have made some changes to the _TOOLCHANGE macro. It now supports TOOLSHIFT=0 during printing.
In short, adding the T0, T1 and _TOOLSHIFT macros to printer.cfg will disable toolshift.
This fixed the drift for me.
Ok I had to stop because I used your model and orcaslicer which I am unfamiliar with. I recreated a 25.4 square x 50.8 tall object split it in 4 and used prusaslicer to set it up. I use firmware retraction so orcaslicer was making a mess in my printer lol. I am printing it now will let you know.
Here is my model and setup for prusaslicer. I also include the gcode which will work on a VC4-300 IDEX using PLA on both toolheads.
Oh and the setup expects a my_skew_profile so that might throw an error if you don't have one,
And firmware retraction enabled
OK, I have tried standard Prusaslicer profiles before. It doesn't seem to matter which slicer you use. I think if there is an actual software issue its something in the firmware/macros.
I am getting a drift in X. If it is assumed that T0 is correct, T1 is leaning to X+. At about 40mm in Z the gap is about 0.40mm, I am guessing.
Y axis is perfect no drift
Looks like you've uncovered something
Looks exactly like my issue
Yep. I am guessing we either both have the same problem or there is a problem in software somewhere. If it is mechanical on my end, I have no solution. The printer appears perfect in every measurable way. My skew is very low in all axes, the gantry is square at the back and the front of the printer. I have good belt tension and good graphs.
Using the .003125 method on both idex X and Y offsets and both idex park positions has resulted in 6 straight tests without drift. Again maybe a fluke.
I will try it and see what happens on my printer
With that being said, another defect has appeared that i am trouble shooting.
I've been printing single wall with 0 infill to save material.
You could also try disabling Toolshift. Would be interesting to see if this fixes the drift for you as well.
I'll try Brace's method first to keep it isolated.
I will try that as well because imagine that, test number 7 has drift. When i'm done crying i will get started.
Uhoh never mind lol. Maybe I will disable toolshift first haha
Did you add that to printer.cfg? I just copy past that in? Sorry I am not great with macros
yes. It will override the default
Ok I am running it now with just toolshift disabled. What is toolshift used for? What do we lose by disabling it?
Early in the print but looks better already
Toolshift is when the head parks and the other simultaneously moves to print position.
Disabled one head parks first, then the other moves to print
I think it would also be a good idea to get @miklschmidt and @Helge Keck involved at this point.
Because I think its very unlikely that 3 printers are suffering from the exact same problem.
its to 99,99% a mechanical issue
you can easily test if its a software issue by observing the applied offset in the mainsail interfscr
you will see that alwayys the same offset is getting applied
this part of the osftware has been tested and debugged intensivly
you can see the applied offset in the interface
Thanks. It is definitely working. The print looks better as well.
If it's a mechanical issue then there is a design flaw somewhere. Because 3 tests resulting in 3 issues is a pretty high rate for a issue which should be "rare"
its a pretty low rate if you consider how many idex have been built already
my first guess is your y belt tension, people tent to not tighten them enough bc the graphs do look better with loose belts
I have redone my belts like 6-7 times at this point. From lose to tight. Rebuild my gantry 2 times.
The drift is in X on my printer. Y is perfect.
this has nothing to do with that
Disabling toolshift fixed the problem
I think many people just dont notice the issue unless they run a actual test
if the y belts are too loose then every time you change toolheads you apply a niconsistency to the system
also, drift is ALWAYS on x, nevery on y
y cannot drift
That's not right. I had drift on Y several times
if you have drift on y, then your toolheads are not porperly assembled
Toolshift disabled
Both tool heads have already been reassembled.
imagine please what y offset actually is. it is not related to the belts at all, only a slightly different distnce from hotend to rail
its just impossible that y drifts, this would mean your hotneds are moving
if you have drift on both directions you have serious assembly issues
please observe the applied offset in the mainsail interface
I would suggest you run this print test Helge. It's not a typical dual color print and easily exposes a shift if there is one there. I had no idea I had this issue as all the other prints I've done have not even hinted at this problem. They've all looked perfect.
you can run the gcode command
get_positions during printing, this outputs the precise motion system location and offsets for all stepper motors
this will clearly show that the applid offset, no matter on which layer is accurate
i ran similar tests for over a year
i tested every single line of this code for almost a month
just bc i have been at the same situation as you guys
but it turned out it was purely mechanical
please do me a favor and observe the applied offsets, everything else are jsut spekulations
myself and many other people ar eprinting since a long time successful with the idex without any this issue
this pretty much should tell you its not the software
there is of course the possibility that some klipper update messes with it, thats the reason why i ask again that you guys observe the applied offset pleaseOk I'll have to try it again later I've got to head out for awhile.
It's kinda hard to track the cordinates at the right time.
Maybe implemeting get position into the macros is a option.
itts easy, just run the command
get_position while printing
T0
mcu: stepper_x:63975 stepper_y:-3144 stepper_y1:-3144 stepper_z:264526 stepper_z1:264494 stepper_z2:264464 dual_carriage:3157
stepper: stepper_x:304.751911 stepper_y:151.461375 stepper_y1:151.461375 stepper_z:102.537937 stepper_z1:102.537937 stepper_z2:102.537937 dual_carriage:206.470413
kinematic: X:153.290536 Y:151.461375 Z:102.537937
toolhead: X:161.633411 Y:151.027000 Z:102.567000 E:5943.916910
gcode: X:161.473000 Y:151.027000 Z:102.587000 E:5943.916910
gcode base: X:0.000000 Y:0.000000 Z:0.037000 E:5943.650160
gcode homing: X:0.000000 Y:0.000000 Z:0.037000
T1
mcu: stepper_x:-1165 stepper_y:-914 stepper_y1:-914 stepper_z:264126 stepper_z1:264094 stepper_z2:264064 dual_carriage:-66977
stepper: stepper_x:101.189212 stepper_y:158.431034 stepper_y1:158.431034 stepper_z:102.412937 stepper_z1:102.412937 stepper_z2:102.412937 dual_carriage:-12.697503
kinematic: X:145.733531 Y:158.431034 Z:102.412937
toolhead: X:139.469867 Y:154.867909 Z:102.412937 E:6015.342180
gcode: X:139.305376 Y:154.867909 Z:102.432937 E:6015.342180
gcode base: X:0.398376 Y:-0.574091 Z:-0.117063 E:6006.426170
gcode homing: X:0.398376 Y:-0.574091 Z:-0.117063
toolhead: X:161.633411 - gcode: X:161.473000 = 0.160411
toolhead: X:139.469867 - gcode: X:139.305376 = 0.164491
Not sure if this comparison is validIt's not, you want to observe the gcode base/homing for T1 (which is the only toolhead that has x offset applied). That value should be the same for the same toolhead throughout the print.
Another T1
mcu: stepper_x:-2928 stepper_y:-2672 stepper_y1:-2672 stepper_z:287166 stepper_z1:287134 stepper_z2:287104 dual_carriage:-66436
stepper: stepper_x:95.679837 stepper_y:152.921659 stepper_y1:152.921659 stepper_z:109.612937 stepper_z1:109.612937 stepper_z2:109.612937 dual_carriage:-10.996065
kinematic: X:141.925593 Y:152.921659 Z:109.612937
toolhead: X:149.158508 Y:157.353909 Z:109.612937 E:6423.388500
gcode: X:148.991376 Y:157.353909 Z:109.632937 E:6423.388500
gcode base: X:0.398376 Y:-0.574091 Z:-0.117063 E:6415.876060
gcode homing: X:0.398376 Y:-0.574091 Z:-0.117063
Looks ok to meYep, offset is applied properly
Wouldn't too tight or too loose Y belts result in a drift in the XY axis and not in the XZ axis?
the toolhead pos vs gcode pos is your skew calibration (and possibly other klipper compensation stuff.. not controlled by RatOS)
plesase show your y input shaper graphs
too loose belts have a heav negative effect on precision
and in general it is important to make sure to have equal belt tension, on the idex you do not tune for perfect grpahs, you tune for perfectly equal belt tension
Which i believe i did. I did not make any belt adjustments based on graphs.
With all belts removed i made sure travel was smooth and there was zero gantry twist.
I then tightened the x any y belts to an equal tension based on gantry twist.
I don't have graphs on hand atm.
Unfortunately I have to stop here and continue tomorrow. Its already late. But big thanks to everyone helping with this issue!
I tightened the y belts evenly by feel and then printed a line on both sides of the bed from front to back with both print heads. I then adjusted the y belt tensions until the lines from both tool heads were parallel.
From what i could tell that would mean the Y stretch/distance per tooth should match the X/DC belts.
i know this can be frustrating, especailly at the beginning when you built it. but you will get familiar with it pretty fast
IDEX is just another beast and much more sensitive then a normal core xy setup
i have been in the same situation
i can only suggest to retighten the belts and relaign the gantry and y rails over and over again until it fits
But again, why would that effect the XZ axis and not the XY axis. If it were mechanical wouldn't it likely be parts of the print and not either the whole print or none of it?
bc every time you make a toolshift you apply quite some force to the system like the gantry
it looks like a accumulative effect from what i see here
But i'll have numerous prints with tool shift that are perfect and prints with the drift. The drift is in the entire print or none of it.
Its clearly an intermittent issue. But if it were mechanical, i would the think the problem would come and go during a print and not either the entire print or none of it.
If there were step loss, shouldn't the minimum shift be .8mm.
I was thinking the same thing, it's hard to understand the toolhead moving out of position thousandths of mm's at a time due to loose belts, not to mention perfectly linear error. I would expect belt slipping would lead to erratic layer shifts. My toolhead took 200 layers to shift my T1 out of X position by 0.4mm. That is .002mm shift average per layer. And it is very linear. How can belt tension do that?
could also jsut be thermal expansion over time
this can happen if the gantry is a tad too long maybe
again, just observe the applied offset after each toolshift to rule any software issue out
No because reducing the load by disabling toolshift stopped it.
If I had to guess it could be stepper drivers that aren't up to the task
I've preheated the printer with enclosure for hours. Print after print with no chance for it to cool down. VAOC when hot, VAOC when cold, no change.
An illustration of Y axis drift- It would be hard to tell but if the entire tower drifts forward or backwards, that would be a Y axis drift which would also move the toolheads together or apart.
yes, i understand waht oyu mean. but the y-offet cant drift physically
its the whole y-axis that drifts, not the offset
the gantry
the y-offset is fix and cant change physcially, only f the toolheads are not correctly assembled
this looks for me like the typical assembly and / or belt issues
Elaborate how the issue would be perfectly linear with a thousandths per layer shift as we are all experiencing.
as i already said, start a print and run after each toolshift
get_position and copntrol the applied offset
i HIGHLY doubt that this is a ratos software issue
and if its a new klipper issue we can fix it, but first we need this data
i have made thousands of test prints and if i had these issues it was always mechanicalYou seem extremely confident that it mechanical. Explain the linear shift by layer.
im extremly confident bc i developed this machine
and i coded the software for it
i have experienced this witht the first VC3.1 IDEX and with the first VC4 idex
it was always mechanical
i have been in the same situation and thought it was a diftware issue, then i debugged one month every single line of code
just to find out its mechanical
please, before we specualte more, just deliver the data, the data will show if there is a software issue or not
Can you recall what mechanical change you made?
I am away from the printer at the moment
gantry alignment, y rail alignemnt, belt tensioning and overall mechanical alignment
belt tensioning has a big effect on it
whenever you have time, start a print, clean the console output, run
get_position after each toolshift and then share the console output here. 10 toolshifts should be enoughi was wondering if in the image i have attached of the 2 set screws were to be tightened down on the shaft and not in the locking flat then when the rig is under high tore and speed such as traveling to parked position or revers that the it might make the pully slip each time slowly adding up every time there is a tool parking , each time the 1 of the set crews goes over the gap it would have a slightly different reaction but still similar , this would cause some minor random variables that make it seam like it changing.
we had recently the case where a klipper update, for the new input shaper, implemented a invisible offset to the printer and we had to fix it internally
its totally possible that something similar happend here
but without the demanded data its impossible to tell
Unfortunately I am unable to be in front of my printer today. But here are some additional thoughts I've had after sleeping on it: In order for the toolhead to gradually shift, something on the printer has to be physically moving out of position or the offset is being mathematically altered, there is no other possibility. It doesn't seem to impact both extruders though, only their relative position to each other in X is changing, and only T1 is changing (on my printer). How does a mechanical issue only impact one extruder? I also have an issue with X offset in VAOC, in that it is always off by -0.5mm. My Y axis offset is perfect in the VAOC calculation and in this test print. My X axis offset is wrong on the VAOC and it is also problematic on this test print (even with the correct offset manually applied). The issue shown by this test print is resolved by altering the tool shift macro so that only one toolhead is moved at a time (or disabling tool shift). The VAOC also moves both toolheads at the same time, I assume using the same or similar tool shift macro. So it's likely these two situations are connected. It all goes back to the tool shift. By disabling tool_shift on the VAOC, I wonder if my X offset would be correct? The other alternative could be to reduce the speed and acceleration of the tool shift, if the problem is load related that could solve it as well. This alteration of toolshift shouldn't be as detrimental to print times.
I'm not sure, but this looks good to me. I don't know how I should derack the gantry any better.
Maybe tuning the tension of the X to the Y belts. But I don't think this should have a huge effect.
If Toolshift requires this level of fine-tuned gantry to work, I wonder how a person building this as their first printer is supposed to do it.
This is my 11th build, so I thought I should have enough experience for this, but it seems I'm too dump to get it right.
In my opinion, there MUST be at least a setting in RatOS to disable toolshift for people who can't get it to work.
Fixed the TOOLSHIFT=0 issue. Where it was not working during printing.
https://github.com/Rat-OS/RatOS-configurator/pull/74
Adding a new variable to toolhead.cfg like
variable_toolchange_toolshift: False # enable/disable toolshift for printing
And slightly modifying the T0/T1 macro added by the configurator to ratos.cfg
[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(toolshift)|int %}
{% set s = 0 if printer["gcode_macro RatOS"].toolchange_toolshift|default(true)|lower == 'false' %}
{% if printer["gcode_macro _SELECT_TOOL"] is defined %}
_SELECT_TOOL T=0 X={x} Y={y} Z={z} TOOLSHIFT={s}
{% endif %}
- Not tested, just a quick exampleIf Toolshift requires this level of fine-tuned gantry to workit does not normaly
Is there a way to set the speed/acceleration of tool_shift to some percentage of it's current values? Or is it using max travel speed and max printer acceleration? I would like to try your print test with a slightly slower, and lower acceleration for tool_shift and see if the X shift is removed. Unless someone can give me a logical reason why belt tension, not loose enough to skip teeth, can possibly be the cause of .002mm X shift in a layer that is permanent for that print, and additive with each call to tool_shift. It makes no sense at all to me. What has to be happening is the stepper is not able to stop the toolhead in the correct spot at the end of a tool_shift, losing a microstep or more each time it's called. This best fits the facts. I also noticed when tool_shift is disabled the parking/unparking of the toolheads is much less violent while printing, like it is using different speed/acceleration settings.
use the toolshift config macro
TOOLSHIFT_CONFIG
are you maybe still in trainings wheel mode?
or have you already activated the motor performance mode in the configurator?
motor skips are usually more than a microstepIt's in performance mode, that was activated in the beginning after the sanity checks. I don't know 100% that the steppers are skipping but it's the only thing that fits the facts.
it doesnt really fit the fact
a stepper just doesnt skip always a single step or microstep
Would you be willing to implement this in RatOS? Since it looks like this is not a "one time issue".
While I can provide and test the macros, I do not have nearly enough knowledge to mesh with the configurator code. As T0/T1 is specified in the ratos.cfg.
I know this is not a real solution, but after 100+ hours of troubleshooting, disassembling and reassembling, I finally want to make some actual prints.
The filament waste also goes crazy at this point. At least I can say I tried. 😆
@Helge Keck Ok first attempt I re-enabled toolshift and then used the toolshift_config macro to set the toolshift to 400mm/s travel and 5000hz acceleration. The drift did not appear on the test print! What is the default speed and acceleration for toolshift? Does it use the machine maximums? In my case that would be 800mm/s and 12300 hz. Assuming this is what toolshift was using when I had the drift, clearly that is too high for my machine to handle during toolshift, and the drift appears. Now I will try to increase it until the drift reappears on the test and that will tell me how far I can go with it. This is very interesting, to me anyway lol.
800mm/s and 12300 hz is way too much for a idex
you have only one motor per toolhead
Ok the 800mm/s was the default ratos setup after I set performance mode. I revised the accleration to 12300 (from 10000) which was based on the data from my shapers.
So what would be good numbers for IDEX?
by default the toolshift runs 300mm/s @ 5k
exceptn you have made some ninja changes in your prinr.cfg
Ok interesting because my toolshift was FLYING
I don't think I changed toolshift but I suppose I could have accidentally.
Ok well clearly this was the problem in my case.
@Helge Keck Thanks Helge, I am relieved it was something this simple. I will look through my settings and see if I can figure out why toolshift was moving so fast. 300 and 5000 is really timid in comparison to what it was doing. I bet it was doing 800 and 12300. Not sure why.
just for the records, it still points to assembly and/or aligning issues on your setup
i have used toolshifts with much faster speeds and accels like you jsut did, withut having this issue
but if the slower toolshifts fixes it on your side, take it and call it a day
Yes it looks pretty good. In the future I when I have to tear down the printer for maintenance I will go through the whole process again and see if I can get it more squared up than where I am now.
@Helge Keck FYI this is from my unedited RatOS.cfg file:
The TOOLSHIFT_CONFIG defaults do not match the defaults on printer startup. See RatOS.cfg
https://github.com/Rat-OS/RatOS-configurator/issues/71
GitHub
Startup toolshift settings don't match default toolshift settings. ...
What happened The default toolshift settings after startup without performing the TOOLSHIFT_CONFIG macro do not match the default values set in TOOLSHIFT_CONFIG. For example, the speed or Z hop is ...
@Helge Keck any chance of getting this option in RatOS?
I wish my fix was that easy. I started the print at 600, 8000 and when the drift was clearly visible I lower the speed and accel to 200,2000 and the drift continued.
I am not sure mine is fixed completely. I know disabling toolshift works, but lowering the speed made it look like it was ok but when I examined it closer there was still some drift. So my solution for now is to disable toolshift entirely.
I also tried different acceleration/speeds. But only disabling toolshift fixed it completely for me.
It's very strange.
Yeah, I'm really confused too. It would be really interesting to know how many Idex printers actually suffer from this problem. I hope some people print the test.
It might also help us understand what is going on if we find someone without the problem.
+1 having the same issues
I'm following the thread (as I have some strange idex issue, I initially thought is similar), bur I could print the test, just share a link to stl, please, not to search it up the thread.
Yea, this thread is getting quite long. 😆
ok this is interesting
finally got around to printing
and like...?
layer 1 vs layer 2
the cubes themselves are positioned perfectly flat on the bed, and even if I sink them, it still does those two, one layer above the first two
Thats odd. Try this one.
this just imports as a solid block lmao
if I duplicate, I end up with the same results
The file i just sent? You will need to split to objects.
even in prusa, doesn't give the prompt
however duplicated that now made it function so idk but i'll try it
idk what I messed up
Sorry, but obvioulsy not today. I had some issues I've tried to fix for hours. Hopefully I'll have some time on Wednesday,
No rush! I am very grateful to anyone who prints the test.
currently at 40mm of height with no deviation, will update as it progresses
I had the same problem, I ended up making my own model. I think I posted in this thread but discord is not so great for finding things lol
probably some bug with prusaslicer
same issue, slight drifting of idex heads as print get's taller. Unsure which one is drifting
Curious if this could be a thermal issue, rather than a calculation error? It seems that Helge is very confident that there isn't an issue with the code.
I personally can't find anything that's a screaming issue, but then again, Im not all that good with code.
I am attempting a different approach to belt tuning that utilizes VAOC, and re-running the print (albeit a bit smaller this time because 5 hours and 200g of filament was too much for me 😅). I'll keep testing to see if improvements happen with mechanical changes.
Will report back.
I’d keep the same size but print 1 or 2 walls with 0 infill. O top layers.
I actually tested to see if it was thermal drift. There is some drift, but it is not the cause of the problem. I checked this by printing with all heaters off, setting the extruder rotation distance to something like 999999999 and cancelling the print with CANCEL_PRINT_BASE to leave the motors on to check with VAOC afterwards.
This is also a nice way to check what is actually drifting. But for me it's mostly random.
I can confirm that helge is correct. The software is correct according to "get_position"
Yes, I checked that too. Seems OK
yep, trust me when i tell you this has been tested to death :kekw: you have no idea how many sleepless nights this cost me
But why would disabling toolshift get rid of the problem?
hehehe just triple checking! Thank you for hopping in and supporting.
he explained earlier I think that it's a fairly aggressive movement, more than likely exaggerating any mechanical issues
with disabling toolshift you are are putting less force to the gantry and the motion system overall
this is a mechanical issue
100%
do you have any specific mechanical things you'd suggest checking beyond the obvious belts+skew?
the whole motion system, every single part basically
even if you think your gantry is perfectly aligned and your belts are perfectly tenionsed, they are not. even a small uneven belt tension or frame skew or whatever adds incostencies to the stack
I redid my belts and made them much tighter. But how tight can you make the belts on the IDEX? The corexy belts put a lot of torque on the linear carriages because they don't have a counteracting pair of belts like on the regular setup
I don’t see how excessive force during toolshift can be the issue when I’ve slowed it down to 200,2000.
toolshift adds always the double force to the system
no matter how slow you go, its always double
But with 5/5 printers is a pretty high issue rate. I think a option to disable toolshift would be great
and goung slow with mechanical issues doesnt make them go away
ita a pretty low rate if you consider how many idexes are already out there
its not unusual that some people have a simialr issue
you see this with other issues as well
Everyone that does the test is not a low rate.
everyone not, this is absolutely not correct
I don't think its a low rate. Many just don't notice it. Like many here
i know a magnitude of people who do not have this issue
what do you think how manbx idexes ratrig sold, 20?
also, as i already told ya, i owed 2 RatRig IDEX, rebuilt them multiple times, worked with the beta team and making support for almost every idex user
this is definitly not a sistematic issue
I don't mean a total. Just that 5/5 have this problem. That does not mean that everyone has it.
i have made thousands of testprints after rebuilding my 2 idex printers multiple times, and always when i had such issues it was mechanical
i can understand how furstarting thsi can be, but the get_position data doesnt lie, its just a fact. it simply cant be a software issue
@Helge Keck On the belts, do you want all belts tightened to the same tension number? Or just the corexy's equal to one tension and the hybrid Y's equal to another?
forget tension numbers, they are useless
you are tensioning the belts so that your toolheads play well tgether
can that be determined by matching frequency? Or is it purely a print quality artifact that you determine this?
It would be helpful if there was more information on how that is achieved
I've been focusing on making sure the gantry is square at the back and front as I tune
I'd love to see a macro that utilized the T0T1 endstops to measure toolhead drift for properly tightening the Y belts.
you can try to put the T1 endstop on the other side of the toolhead and homing it against T0, klipper allows that scenarion
only way to automated this is with multiple cameras
wait I like this idea
Was thinking multiple cameras and stepper motor driven belt tensioning
hmmm, though t1 endstop on the other side wont fix our drift issue if it's a mechanical issue, it will drift regardless of endstop position
The problem with the endstops and single camera is there are three datum points that have no direct controllable location with minimal tolerance buildup.
You need a single location in the printer that both endstops and camera can be precisely located from. Especially in X
Y is much less prone to tolerance issues
What i am referring to is when the Y belts are overtightened, the toolheads drift inward away from their endstops. if an endstop measurement was taken from the back of the printer and the front of the printer you could use that information to adjust your Y belts accordingly.
you cant
problem is the endstops are routed through the toolboards and the steppers are connected to another mcu
this is the reason the x offset is always a bit ddifferent after homing
as i already said, only way to really automate this is with 3 or 4 cameras, where both nozzle positions can be compared
It would be really cool. I would buy that upgrade fwiw
https://tenor.com/view/sweats-gif-25346666 the raspberry pi seeing your message
if this is a tease for VAOC based belt tuning or other tuning im excited
its not
but getting the x y offset provided is huge
at least from the center of the VAOC
it gives you even the zoffset
I feel that even single camera, VAOC can be used to tune belts to a certain degree. The repeatabiity often correlates to binding, at least from what I've experienced
Could this information potentially be used for Y belt tensioning? X homed at back of plate vs front of plate.
Updated figures after tightening the both Y belts +-1/3 turn.
What are you referring to when you say back of plate or front of plate?
Y position 10 for front 490 for back.
Ok the build bed lol. I was like what plate? I can be dense
I don't personally feel this has anything to do with the XZ drift but would like to find a numerical way of calibrating Y belts. The above adjustments were made with skew disabled.
My previous XY scew was 0.000708474995350995. Now with the above adjustments and the skew set at 0.0, I reprinted the skew test and there is no measurable distance between AC and BD.
once again
helge is correc
I reduced belt tension, and achieved consistent X throughout the print
I'd print a few more to be sure. I'm at about a 50% success rate. I've printed 7 perfect tests one after another only for the 8th to fail with no changes.
I'm really interested to see if anyone here is able to solve this. I will defenetly stop here, because after 100+ hours of disassembling and reassembling, it feels like a waste of time to fix a system that is this picky, so that if you change a component in the future (belt), you can spend another few hundred hours fixing it.
Can you describe what you are doing and looking at to make adjustments?
well making some sort of progress
I've decided that I will now be ignoring IS charts
I tried very low belt tension, and got drift similar to you guys, I tried very high belt tension and reversed the drift (it's now drifting in the opposite direction)
so
2 theories:
1. Uneven belt tension causes some sort of drift for prints. Exaggerated using IDEX as that puts the most load on the motion system
2. There is a specific belt tension that perfectly middles the drift where it doesn't actually drift, I feel like this is less likely however (and also more annoying lol)
I have a belter, so I will see if maybe dropping the values slightly from my "very high tension" and quadruple checking the tensions along with gantry racking across the back will fix the issue
will keep this thread updated
I've had the drift switch directions multiple times without touching the belts.
hm
well that ruins my testing lol
I tried upping the tension, it did nothing. I have the best results with belts that are tight but allow smooth manual motion of the gantry and especially the toolheads, if the motion is uneven or rough imo you are too tight. The corexy belts will cause the linear carriages to run roughly due to the rotational load they put on the toolheads (because there isn't a second pair of belts to counter that rotational loading). So my prints with tighter belts didn't come out as well at all. I also tried ignoring the IS graphs but then my shaper values didn't work well to avoid ghosting.
The answer is to disable toolshift, or find the magical mechanical setup that stops it from happening. I am devoid of magic, so toolshift is disabled.
Had one succesful test print after uber carefully tightening belts. Will print a few more to see if the trend continues
second print after carefully tightened belts, no drift
starting a 3rd print, if this one is good I may run or two more and then call it fixed
3rd no drift 👍
you guys are getting closer
this is the typical learning curve at the beginning
nothing to worry about
What tension measurements did you end up around the printer? I'd be interested to see them.
I've learned how to deal with frustration.
Im currently at 7.2mm on my belter which feels quite tight, however I was able to run 8k accel with no issues on the test prints... More to follow (im not looking at IS 😂)
But i am at EXACTLY 7.2mm of tension on all 4 belts. Measured at the same point, with the motors powered on.
After verifying gantry racking on the back, and running Z-tilt and re-measuring the tension to get all 4 within 0.05mm of tension of each other reported by belter
(z-tilt is to have the gantry system move around and all the tensions to kinda "settle")
I know you've put some great work into tensioning your belts, would you consider trying the 4-equal tensions method? Curious if maybe I fixed something else by either cranking the tension or it's a fluke, or it's actually the real solution
I haven't tried it that tight. How are your carriages on the toolheads? They must feel like they're rolling on broken glass.
Pretty gritty for sure, but they print super nice and clean and havent had any X drift so 😁
I am concerned about bearing life at that tension. I had my 500 really tight like that and after a few dozen prints all the bearings were wiped.
Maybe a 6.8 tension? I think the key is absolute equal tension
First thing I tried but my prints were trash.
I'd retry possibly. What tension are you currently at? Just curious?
6.1 in the Ys and 6.4 in the corexys
But I am trying to get IS graphs that I can actually use.
The amount of times I thought I had it figured out because I had a few consecutive tests without drift is quite embarrassing. After 7 I thought BINGO!! I’ve figured it out!! Only for the 8th to fail.
But you know what, 7.2 might be fine, I might be over sensitive. Truth be told I didn't know what the tension was in my 500 that caused the issue, I may have been higher than that.
But the 500 has two pair of belts on the toolhead so no gravel driveway
I understand...
A: i cant be assed to make 8+ trials to verify
B: the 5 prior test prints that all had it, then now it consistently has good alignment for 4 test prints is good enough evidence for me
I'd try a little higher, for my printer at least, 6-6.5 was a bit too low.
I've been ignoring IS graphs. I think belt tuning and print quality come before IS graphs, and I've been running at 8k accel even though my Y says 3k 😂 and it looks very nice
Again, my opinion/speculation lol
I still haven't had a chance to print with my new belt setup so we'll see. Ran out of time yesterday and today I'll be out all day.
Internal testing suggests the best results are achieved by having the pairs equally tensioned (and have the same length between attachment points). Any deviation from that causes a multitiude of problems, including artifacts and bad resonance. If you make sure the belts are correctly installed (to achieve the same length between T0/T1 and Y/Y1) and tension them equally (Y can be tighter than T0/T1), you're gonna be a lot less frustrated. This isn't new information though. I think people get confused because they use the plucking method which is terribly unreliable, even measuring deflection can be misleading (because belt width and thickness varies very slightly on Gates belts). Recent experiments have shown really good results with this low-tech but very reliable approach: https://www.printables.com/model/1165578-gravity-assisted-tensioning-system-gats-for-v-core
Printables.com
Gravity Assisted Tensioning System (GATS) - For V-Core 4 and 3.1 by...
A streamlined method for precise belt tensioning on the RatRig V-Core 4 and V-Core 3.1 (with front tensioner upgrades). | Download free 3D printable STL models
Agreed, this is the conclusion I've come to but I didnt want to be too confident until others also came to that.
Thanks for the further details :)
Just clarification, pairs equally tensioned meaning ALL belts equally tensioned? Or left and right are the same, but top and bottom sets can be different?
Toolhead pair needs to be equal, and Y pair need to be equal. Toolhead pair doesn't need to be equal to the Y pair.
however going for the same tension force on all of them yields good results.
Anything from 14-40N should be good, i would aim somewhere in the middle.
Thanks Mikl :) super appreciate the insight
Sure thing, hopefully it helps cut down on the frustration. I feel your pain 😄
Also credit to @andersbr for coming up with this. It looks jank in action, but it's beautifully simple. The best exercise in MacGyvering 😄
I use the frequency in input shaper to match the belts, the first mode should be directly proportional to belt tension. Use the X graphs for the corexy belts and the Y for the Y belts.
I use the belter to get them close to start with
I use the frequency in input shaper to match the beltsThis is unreliable if your belts aren't exactly the same length between the attachment points. And even then, it's never going to be as reliable as using the same weight on both belts. (because of the aforementioned issues with belt variance)
Ok I'll have to set up weight tension then thanks for the info. It's been tough to say the least. IDEX is a picky little beast
It's possible to do with resonance measurements alone, but there's just a lot more that can go wrong, so if you're struggling, stick to the method that involves as few variables as possible (the GATS one)
IDEX is a picky little beastYessir, it is by far the hardest to tune, but that's largely down to not having the appropriate tools.
What is a safe maximum belt tension so we don't damage the carriages on the toolheads?
I can understand belt tensions heavily impacting Idex alignment in the XY plane but I don’t understand how the fully independent bed lowering would affect that alignment. I understand the excess forces during toolshift but I’ve lowered the speed/accel to 200/2000 with the exact amount of drift as 600/8000. If something was slipping or steps were being lost, I wouldn’t think the drift would either be the entire print or none of it.
If toolshift brings out drifting due to belt tension, how come mirror or copy doesn't have the same effect? (Since both toolheads are moving at the same time)
It guess it potentially could be but wouldn’t be noticeable unless you did an XZ plane skew test in copy or mirror.
Well one part (at least) should demonstrate drift as an angled vertical wall.
Yes but for the level of drift I have, that would be .4mm at 100mm tall. I sure wouldn't be able to tell from looking at it.
So the real problem is Aone's model LOL
Aone needs to figure out the XY plane before he should even print the tower.
Printing my GATS to tension my IDEX for the millionth time.
Nice one, but not everyone has belts and bearings left. Any idea where to buy them and what model they are?
I have a theory. As the bed moves further from the bed, the gantry gets colder which means the tension decreases and since it's not equal the gantry skew changes.
To test that hypothesis you could try heat soaking the thing (give it ~45 minutes), then start VAOC and make sure T0/T1 is calibrated. Turn off the heaters, and let it sit for an hour, then check the alignment again (without dragging the image).
Unfortunately that’s something I tried weeks before finding this thread. The initial drift was minuscule. Even then, with the printer enclosed I would think the drift would curve and balance out and not continue linearly.
Flanged bearings are F695ZZ, and regular bearing is 695ZZ. Belt is GT2 9mm timing belt. Do you have access to Amazon? They will have everything listed in the hardware section.
In Amazon.de most of these are hard to find, but I'll give it a go...
You could probably get the stuff from ratrig too, although they kill you on shipping
You should also have some of the hardware left over from the build.
Exactly. 10 euros goods and 10 euros shipping is a bit too much 🙂
Unfortunately, nothing left from the kit. I even had to purchases some bolts, that were missing.
The idler pulley comes with bearings. But if you get the flanged bearings and regular bearings that I listed you can make your own idler pulley with them. So it's either or sorry for the confusion this is new to me as I haven't done it yet.
I have some wheels with bearings left from an Ender 3 clone, long ago, so I just might improvise and draw something in SolidWorks myself. That's what I do for a living in the last 25 years, anyway 😉
you get bearings in every home depot or similar shops for little money
Yes you're just picking up weights at the end of the day, it's not rocket science
or you can salvage some bearings from a old broken skateboard for example
if you hate your kids for whatever reason just take their skatebord or inliners
My point was if it doesn't drift in that scenario, that debunks my theory.
Wasn't a "fix" for anything, thought that was obvious 😄
Nice one, but both are getting bigger and stronger than me already (1.90 m) and would be too life threatening for me 😄 Having in mind the healthcare system in Austria, I'd better save myself the pain and suffer....
Once again: I can understand belt tensions heavily impacting Idex alignment in the XY plane but I don’t understand how the fully independent bed lowering would affect that alignment(beyond thermal expansion). I understand the excess forces during toolshift but I’ve lowered the speed/accel to 200/2000 with the exact amount of drift as 600/8000. If something was slipping or steps were being lost, I wouldn’t think the drift would either be the entire print or none of it.
I dont have a reasonable explanation beyond that after adjusting the belts I have no more idex issues...
I also share your confusion on how that'd actually fix it, but it did and Im moving on lol
How many additional tests did you do? Did you move the tower to a different spot every print?
I did 4 total tests after making my "final" belt tension adjust.
I did 4 before that, all the exhibited some form of drift in X (cant measure Y).
For all 8 tests, it stayed in the same position and was the same exact GCODE every single time. I figure it was a bad method adding another variable.
Try moving the tower around slightly. Even just a mm. It’s a variable that technically should make no difference. Not just once but a few times.
One of my belt Y belt clamp body's sheared right along the layer lines. Found it while doing GATS. That may have been one reason I was having trouble. Ratrig is printing too cold or they need to change the orientation of the print.
but I don’t understand how the fully independent bed lowering would affect that alignment(beyond thermal expansion).The expansion (in this case contraction) affects the belt tensioning. Ie, unequal tension becomes more or less unequal as the temperature changes (which changes positioning and gantry skew). That's why it's so important for the X belts to be equal length and equal tension (which is measured by force, not theoretical plucking frequency)
Tapping out. Toolshift disabled.
Well after doing GATS (I used 3.07 KG on each side) and making belt lengths perfect, none of the frequencies match when plucking the belts if that tells us anything about the accuracy of the plucking method (not accurate at all). Ps I used a very accurate scale when making my weights, accurate to .1 gram. Mikl, I think it should be in the commissioning guide that the GATS method must be used when tensioning IDEX. I still don't know if it solved any of my issues though, haven't had the chance to run any tests to see.
none of the frequencies match when plucking the beltsYep, that's what we've observed as well. I've always discouraged the use of vibration frequency and spectrometers because there were too many variables, and GATS makes it abundantly clear.
Mikl, I think it should be in the commissioning guide that the GATS method must be used when tensioning IDEXSomething has to be done about belt tensioning in general in the comissioning guide.
I still don't know if it solved any of my issues though, haven't had the chance to run any tests to see.Let me know how it goes. To reiterate on this, no matter how much people love to obsess about it, the important part here is not so much absolute tension values, it's equality to neutralize gantry and toolhead counter forces even as the frame and gantry expands and contracts. If they're not tensioned with the same amount of force, they will change differently when the temperature changes, and that causes the problems you're all seeing. (gantry gets colder as the bed moves further down throughout the print)
Which would happen every print and not intermittently. The drift would also be a curve and not linear.
Yes. If you're seeing random drift, you're dealing with loose pulleys or skipping motors, that's very different.
The drift would also be a curve and not linear.I'm not sure about that
Tension inequality explains this phenomenon - the one we're discussing.
Both were printed one after another with no changes in an enclosure that was preheated for over an hour.
Expansion is also affected by the toolhead cooling fan blowing on the gantry.
Quite a lot it turns out
you had one toolshift per layer in your test prints, i doubt its the z-ayer height thats the issue here. its jsut a accumulative effect of the toolshifts
and maybe also the thermal expansion
bt definitly nothing with z
Edit, unfortunately started seeing some shifting at about 45mm, greatly improved for my printer but still a technical failure. GATS seems to have resolved this issue on my printer. I am halfway into the print and no shift with toolshift enabled. My printer has never printed this far without some shift showing up with this test print. If anything changes I will edit this post, but it looks good. I will probably re-do GATS with more weight. I did 3.07kg weights but I think I can easily do 3.5kg to 4.0kg weights and the belts will still not be too tight. At 3.07 kg on my 300 I can only get 6300hz for X axis which is too low for a 300 and I think more belt weight (tension) will likely increase that.
if you could translate to BELTER numbers too, although less accurate, that'd be great for reference in the future :)
The 3.07kg weights resulted in Belter readings of around 5.9 to 6.1 which is pretty light. I was looking for about 6.4 or so. This also demonstrates Belter is pretty inaccurate, as 1/2 of 3.07kg (2 belts/pulley/weight) should be about 15 newtons or 6.35 on Belter.
Started seeing some drift at around 45mm. Greatly improved but still there. Tomorrow I will run one with toolshift disabled and see if that changes the result. A failure but also it demonstrates that equal belt tension is important, as this print is much better than before with toolshift enabled.
Just a note, went to microcenter today. They have demo units of multiple bambus as well as the creality K2's.
I plucked all their belts and they are TIGHT. Like if I were to guess belter values, somewhere in the mid to upper 7's
The K2 was the closest to what we have with a 350mm build plate
Have tempted to bring a belter and test their belts to see what the value comes back as
Just remember the IDEX is limited to how tight you can go on corexy due to the rotational load on the carriages from only having one belt pair. Once the x axis feels rough when you move it by hand, the belts are too tight. I would say anything over 20 newtons (4kg weight on a pulley) is probably too tight for the IDEX, 3.5 kg is probably best.
Thank you everyone for being persistent with this. I have been wanting to redo the belts on the 500 IDEX I built for my employer. I used a printed belter and the pluck test and both indicated the coreXY belts were not even, but it was the only way I could keep the gantry from binding. Evidently I may be closer to correct than I realized.
Going to try convincing my boss to let me print the GATS and tune them in that way.
After doing the GATS method, it's the only way to do it. The other methods are walking around in the dark bumping into stuff.
Did the the print with toolshift disabled, no drift. I am seeing something odd with tool 1. When the toolhead change occurs from T0 to T1, as T0 leaves the part, T1 shifts slightly (1mm?) towards X min before T0 parks and T1 makes it's full move towards the print. T0 does not do this when changing for T1 to T0. I never noticed this behavior with toolshift enabled.
this is the x offset from t1
this is normal
this happens when you tell klipper to apply that offset
Well, looks like I have months of work ahead of me to get this printer to a basic level of function. My input shaper graphs look perfect, all other tests from the commissioning guide provide results that say "nearly perfect" or something along those lines. Still have this issue.
Welcome aboard. I am the captain of that ship and it's not a fun cruise.
Yeah I definitely wouldn't have bought this printer if I had properly understood the design flaws. I have it now so I'll get it working, but I wish I had checked the documentation in more detail before purchasing
Very frustrating to be sure. I will avoid the use of expletives to keep the discourse civil and not get banned from discord.
Despite the fact that my input shaper looked basically perfect I'll redo the belt tuning with GATS. All gantry skew calibrations I have done have come out to exceptionally tiny modifications (less than 0.01mm). I genuinely don't understand what else could be wrong
skew calibration won't show you this effect as it's a difference between t1 and t0 positioning caused by uneven tension force applied to the gantry. There are multiple ways that can be hidden when doing skew calibration.
I don't know if you can call this a design issue, it's inherent to the hybrid corexy IDEX kinematics, which is the most common IDEX kinematic on machines with an X/Y static bed, the Voron Phoenix uses the same kinematics for example. It's perhaps poor guidance in the comissioning guide. My advice is to use GATS and save yourself the frustration of trying to tune it via derived values or tangentially relevant measurements like pluck frequency.
The ease of assembly of a product is a core part of its design. While I happen to be a person that is well prepared for mechanical assembly and tuning, I am by no means everyone. Nowhere in the marketing material it noted that this is an extremely complex build with work in progress documentation and assembly instructions. In fact, it's only through comments on the build guide and discord that I was informed there are numerous problems with the instructions. In my opinion that is not acceptable for a commercial product, especially one of this price.
If this was marketed as an early access / still developing project I would have no issues.
To be fair, the build itseld is not that complicated and doesnt differ from a normal corexy printer. but the belt tuning needs obviously more prcesiion since the toolheads need to be synced correctly.
I disagree with your assessment of the state of the product. It's a DIY kit. I guess managing expectations is the part that's failing.
I don't understand this aversion to continuous improvement either.
You'd rather they just didn't try to address concerns?
esepcially at the beginning of a idex i can understand the frustration, but a IDEX confronts you with a new situation and there is a earning curve involved. once you have done it properly the next time will get much faster and easier, jsut as with every other new printer you build
Round and round we go.
That is not at all what I am saying. I am saying that there should be more clarity in the sales pages as to how complex, time consuming, and still beta the commissioning is.
You keep saying "still beta", that is not the case.
Can a person effectively tune their idex printer using the information solely in the commissioning guide? The amount of posts I see about it makes me think that they can't
Yes and many have done so.
There will always be people with problems.
No matter how "perfect" someone thinks it is, someone is going to struggle.
I guess we see things very differently then. If I saw the amount of posts on here for one of my products I would be taking it off the market.
And that's perfectly fine that we don't see eye to eye on that
you have to put that into relation with the already sold and successfully build idex without such issues, its a very small amount of people with that specific issue
DIY will always be "beta" if your perspective is that everyone should have the perfect experience. It's not a thing. DIY is challenging, the level of challenge depends on the person. Everyone is doing everything they can to help those who are struggling. I don't know what more you want.
From what I’ve seen in other groups I can completely agree that 99.99% of the time it’s belt and gantry alignment. Because of this, any chance of it not being that is disregarded.
My point is that DIY does not properly encapsulate the level of difficulty at hand.
I think there was a bit of a hang up over my original wording of my complaint. You said it in the middle of the discussion, “I guess managing expectations is the part that’s failing.”. That is a better way to put what I was trying to recommend fixes to the product page for.
I digress, this is all pointless to this thread. I will try GATS tuning after the parts come in for me to try it. If GATS is going to be added to the commissioning guide, I urge you to include the hardware (extra couple bearings, screws) in the kit in order to perform it.
That is a better way to put what I was trying to recommend fixes to the product page for.There's not much use complaining here about marketing, that should be directed at Rat Rig, send them e-mails. This is a community discord, we can't act on that feedback.
If GATS is going to be added to the commissioning guide, I urge you to include the hardware (extra couple bearings, screws) in the kit in order to perform it.Just to clarify, i'm not a Rat Rig employee (community discord yada yada) 😄
That was absolutely not clear from your discord profile…
Limited characters. I understand how that's confusing. I'm on the external R&D team.
With that being the case, you are absolutely correct with where my points should be directed. My apologies.
Let me fix that, i don't want to give the wrong impression.
Maybe i should just remove it.. To clarify further the external R&D team is a group of long time RR community contributors who advise and work with rat rig to improve and develop products. It's volunteer work.
I’m sure there is a way to make it clear without gumming things up too much. I’d give recommendations but I need to sleep
I removed it, i already have a role for the dev team that shows up in my profile
"Rat Rig Community R&D Team"
That's entirely my bad
The interesting thing about my printer is it prints well for the most part. Where it fails are at the extremes of printing, e.g. printing a tall tower with dual color and seeing if they stay perfectly aligned for the full height of the printer. These are not usual cases for 3D printing. 99% of the time we print objects that are much smaller than the build volume. So we don't print at x, y, or z min and max locations except in rare instances. It's possible that many people are fat dumb and happy about their IDEX printers, having no idea at all that the printer fails at the extreme cases because they've never tried them. I can do dual material, color, or copy/mirror and the prints come out fine. The only reason I even found out I have drift is because I stumbled across this thread and tried it. I had no idea my T1 couldn't print straight along Y at the X min areas until I tried it. It prints fine everywhere else. Essentially I have isolated three issues with my printer. I have drift issues in X as is documented in this thread, my VAOC xoffset value is not being calculated correctly (when compared to reality), and the skewed printed line at the front left of my build plate with T1. I can avoid the drift, because I most likely will never have to print a dual color tower side by side, I can correct the x offset manually using an IDEX test print, and I can avoid the front left of my printer. It just bothers me no end that I can't figure out why it's happening, when every measurable metric of my printer says it's otherwise perfect. I can print copy/mirror with a first layer height of .2mm, I have perfect balance in the belts after using GATS, their tension pulley locations match to withing 0.02mm and my skew calibration now prints with literally zero skew in all three axes w/o compensation. The bed high to low even measured with the magnetic bed is less than .2mm. I don't know what else to do other than to disassemble the gantry and toolheads and examine every component.
my VAOC xoffset value is not being calculated correctly (when compared to reality)the calculated offset is correct for the camera position. its not the calculation thats the issue here. its mechanical if the calculation woudl be off then you would see that in the camera already just for the records
Yes I understand, I should say I have to manually alter what is determined at the camera to align the toolheads in the print area. I have NO idea why it doesn't work.
I am here mostly for the troubleshooting and belt tensioner guidance. T1 prints about 5g of support interface material for the 750g of material printed by T0. End user will likely never see anything wrong.
I greatly appreciate all the work everyone has put into researching these obscure issues as it helps others perfect their machine and helps further refine the next iteration of the design.
In my case I was printing a 300mm tall PETG object with PLA support and interface which requires a tool change every layer. Otherwise I likely would not have noticed the drift on any other print I’ve ever done.
I think mine maxed at 100mm high, but it just barely fits diagonally on the 500mm bed. I see very slight issue on the outer edges, but fortunately it is hidden after it is installed. Even if it wasn’t you have to really know what you are looking at to see the very slight misalignment. Talking not even a layer width.
Maybe if the stepper motors and drivers were replaced with stuff that's double the stock equipment's holding torque it could brute force the printer into staying square everywhere.
this makes no sense
Doesn’t sound like a motor holding force issue, otherwise we would be losing steps and seeing it everywhere.
Probably not. I was mostly joking. I don't understand the problem so I can't offer a real solution.
I have been following this thread, and it seems that this problem could be caused by the asymmetry of the X belt lengths and thermal expansion/contraction of the belts. The stepper motors are what control the position, so lets assume they are fixed in the correct position. The belts stretch due to the belt tension, with the stretch varying linearly with length. The T0 print head has a short belt length to its stepper motor on the left, and a long belt length on the right. If the belt warms up and expands, it will then shift to the left. Conversely the T1 print head has a long belt length to the left and a short belt length to its stepper motor on the right. So it will shift to the right. The y belts are symmetric, so no Y shift will occur with temperature. The X home currently only happens at the beginning of the print. What if the X home was repeated every 10 layers, and the X offset adjusted to compensate for this effect?
We’ve tried extensive heat soaking and Ibot has done a test with bed and hotend off with no improvement to drift when measured through VAOC.
And just speaking of the belts, all pulleys and idlers are stationary, therefor the belt would loose tension and not necessarily expand. If the idler was on a spring that could be the case. I can imagine the extrusions being effected which would then effect belt length but with the heat soaking i would think that would be minimal.
How much should I be able to move my X gantry out of square by hand with no belt tension? e.g. If I gently push on one xy joiner and pull on the other.
I did the force belt tension with 3kg. Seemed to do something.
Had 2 successful tool change prints, but disabled it again just to be safe.
In the last few days I have printed some large models with many toolchanges (1d, ~1.4k changes), 3 of them without toolchange problems, the 4th with drift again, even with toolshift disabled. How can I fix something that is completely random? Maybe I should finally get rid of idex...
4th having drift... Check your tension again. I've had the tension "settle" after tightening once. Needed to be redone after a few prints :) hopefully it's that easy...
Apologies for the delay (only a couple of months 🤣 ), but I had to tune my 400 (now all is fine; skew=0.00 and both colors have no offset in any side/corner of the bed. Helge was right - it's all about belt lengths). I've printed one of these tower files and there is absolutely no drift on its way up. It splitted very easy and evenly too.
Do you have that model? I'd love to test with a tall one
though I guess I can just make the model myself, don't know how to easily set up two filaments at the model level but I can figure it out XD
I think it's one of these two...
Yes, Testtower_1.
tyty
Specifically what you had to do to make it right would be helpful.
I had issues with two heads printing properly in two colors. Perfectly aligned close to the VAOC and 0.5 to 1.0 mm far from each other at the other end. I've checked miltiple times my frame and gantry and was sure I've assembled them good. Next thing was the belts. I even created myself a drawing in SW, to comprehend and simulate what happenes if I move some of the bearing/pullies along X or Y with fixed belt lenght and what happens when I change the length. This proved what Helge said, that there is my issue. Actually it's not that much into the tension, but the equal length of the belts. I've started tuning the tension first, but found out even with big changes/differences, the effect was far less then with only changing the lenght. What I did next:
- Loosened all the belts (took them off the bearings) and took care that my gantry is perfectly flush to the front (and the back), then tightened the 3+3 bolts;
- Took care, that when placing back the belts, all front tensioners are protruding as close as possible in lenght outside their box (less then 1 mm difference);
- Tightened the belts to the toolheads as even as possible, pulling and ringing, same as I did that to my Voron, so I'm really used to that:
- Checked if the gantry is still perfectly flush;
- Here started the long testing and adjusting. I did s shaper graph and if I was OK with it, making small adjustments, I then made a VAOC calibration, Endstop calibration, skew test print. Then I did my test on the far side on the bed, to check if two heads were aligned. If I didn't like the result, I determined which belt is longer and unscrewed the belt fixture to the head and moved a tooth in or out, then tightening again. All that in repeat mode, until I liked the result.
Nice thank you! Can you describe how you determined based on the result, which belt was longer?
It's all time consuming, as after each belt length change I had to go through all of these again. Sometimes I went to the wrong direction, sometimes I had issues with parking going out of range (it took me a while to realise, the skew compensation is sending the head outside of the range). I lost two days in that and trying to figure out why the VAOC calibration is so hard to achieve and why my prints are ending with error.
The last bit was when I found out I'm having two times the endstop calibration text in the printer config and it was ruining my end results. Afterwards it was again the skew calibration, that led me to wrong conclusion. I don't know if I measured it wrong or mistook the two diagonals, but than I just set the skew to 0 and voilà - no more out of range and all dimensions became perfectly fine. I've printed 350x350 square lines, offset by 5 mm and measured the diagonals - less then 1 mm difference, which ment they're squares, not rhombuses. The offset was also perfect between two colors, so the heads were moving paralel.
If you loosen the belt (just choose one of the heads, no matter which one), it's moving far from the other in the far end of the camera.
But as I said it was mostly a trial and error. At the beginning started with changing the anchoring in both heads, and at the end, the final adjustments were with only one head (no matter which one). Only a tooth in or out at a time. The both are still not perfectly aligned and there is something like 0.1 mm difference for 400 mm travel, wich could already be fixed with the tensioning, I just find it good enough for me, and don't whant to bother further.
Yes I would say you definitely don't want skew compensation on as that would cloud the mechanical result
If you manage to square the gantry good enough, the skew is only adding noise to your readings, as the 141 mm square is too small to measure well the diagonals, considering the plastic difference in flow and other issues with it. I know the size is chosen in respect to the calipers, most of which are 150 mms, but it's too less to be precise. I have a lovely Mitutoyo wich is really precise, but it's the plastic that's not that even.
For me it's more precise to determine skew measuring two diagonals of a 350 mm square, than a 141 mm plastic with a caliper.
Yes, especially for the IDEX where issues can appear at the extremes that were not measurable or visible in smaller prints.
Ugh, redid everything and tuned with GATS 3.7kg. My results are now considerably worse than before.
4.7kg on X and the graphs look much more correct. It feels like it still needs to be higher on the Y
There were improvements at 4.7, but it can probably go up to about 5.2ish
5.5kg and Y still needs more
The more weight the closer it gets to good. I'm at absurd amounts though. I could trim down the length of the belts, but that would mean pulling them out of the housing they are in which is a nightmare
I cut them to the right length according to the guide, should make a comment that it's too long
Watch your Y belt bodies they are prone to shearing. It is hard to see if you've damaged them also. Look for layer cracks where the bottom of the Y belts exit the printed part. At your loads, there's a good chance for failure. Mine were damaged at lower levels than that and had to be replaced.
With that load the belts aren’t actually particularly tight. Went tensioning previously without gats I had them tighter. The belt bodies look fine, thanks for the heads up though
I think I flipped numbers when I was cutting them to length. They might just be a bit long