VAOC Calibrated, But Totally Off Next Time Tool Runs

(This is on a 500) Been reading about the VAOC issues here and not sure my problem fits exactly into the more recent discussions, wondering if anyone would have guidance -- I can run through a VAOC calibration, everything looks good but when I do a multi color print, no good, x offset is quite large. >3-4mm. In trying to understand further, if I do a complete VAOC calibration and save, go back and home the machine, do a z-tilt, if i go back to a VAOC calibration, everything is way off. So it's not that it appears to be calibrated and it's printing incorrectly, it seems like my calibrations get out of whack basically as soon as it's saved. I've validated all screws are tightened, and belts are maybe a little loose but seem in accpetable range. when homed, bottom belts at 105hz and top belts at 98hz. Both sides are at same frequency. Only thing I am not sure on belts is length. All 4 are same length, but Im unsure how that all plays into how much belt is after each clip. If you follow what Im saying do I need to have the exact same number of teeth after the clips (in each toolhead) and I guess on either side of the mouting block for the hybrid belts? That Im not exactly mirrored, could that be an issue? Any guidance on best troublehshooting steps? Comissioning guide really doesnt have much for troubleshooting there. I'll say the x offset in my ratos-vars is perfectly within the values mentioned I should have:
idex_applied_offset = 0
idex_xcontrolpoint = 212.1980545886675
idex_xoffset = 0.07108125106864804
idex_ycontrolpoint = 525.8256643003863
idex_yoffset = -0.3824471495563557
idex_zcontrolpoint = -0.2948406250028259
idex_zoffset = -0.025159374997174577
idex_zoffsetcontrolpoint = -2.725862499884027
nozzle_expansion_applied_offset = 0
nozzle_expansion_coefficient_multiplier = 1.0
nozzle_expansion_coefficient_t0 = 0.052393750006730855
nozzle_expansion_coefficient_t1 = 0.06588125000502831
t0_filament = ('', '', 0)
t1_filament = ('', '', 0)
idex_applied_offset = 0
idex_xcontrolpoint = 212.1980545886675
idex_xoffset = 0.07108125106864804
idex_ycontrolpoint = 525.8256643003863
idex_yoffset = -0.3824471495563557
idex_zcontrolpoint = -0.2948406250028259
idex_zoffset = -0.025159374997174577
idex_zoffsetcontrolpoint = -2.725862499884027
nozzle_expansion_applied_offset = 0
nozzle_expansion_coefficient_multiplier = 1.0
nozzle_expansion_coefficient_t0 = 0.052393750006730855
nozzle_expansion_coefficient_t1 = 0.06588125000502831
t0_filament = ('', '', 0)
t1_filament = ('', '', 0)
24 Replies
rms497
rms497OP•4mo ago
Also to add there I've done a compelte thermal expansion calibration and the Z offset calibration. After fixing the Chube hoteds, Z offset is correct and within good range (0.03)
rms497
rms497OP•4mo ago
An example -- I have completely calibrated / aligned in VAOC and then just went back in. This is the intial view of T0 nad T1. I guess the misalignment seems almost exactly the same so I feel like that is saying somehting easy, But Im unsure what that is.
No description
No description
MDFPereira
MDFPereira•3mo ago
Did you run the CALCULATE_DC_ENDSTOP command during the commissioning guide?
rms497
rms497OP•3mo ago
Yessir 🙂 I have followed, to a T, the commisisoning guide. I ended up discovering a mechanical issue yesterday during a print with the largest object I've attempted to date. Ended up having to completely unmount the left hybrid motor and belt, fixed and remounted. Im hoping I have better luck after this 🙂
billyd
billyd•3mo ago
On the idex the belt tensions and length have to be precisely correct to operate well. Also the frame and gantry must be made perfectly square. I suggest going to printables.com and searching for "gravity assisted tensioning system" and follow the instructions on that page very carefully.
ArgueForSport
ArgueForSport•2mo ago
Had the exact same problem, chasing belt tension, squareness, gantry alignment, etc for months. Replaced the X rail and carriages with a Hiwin and the Y rails with ones from @Budz (PD3D) at PeeDee3D. Repeatability solved, and it holds the values.
Still suffered the same T0/T1 offset issue many other have, being off on the X by around 0.5mm, but that was solved with manually adjusting the X offset value in ratos-variables.cfg. At least it became consistent and holds the value.
rms497
rms497OP•2mo ago
Thanks for the input. I think I had probably read some posts by you (or someone else with similar issue) mentioning this. I ended up getting high quality rails with proper preload as my last attempt and they are scheduled for delivery (after almost a month) for tomorrow. It's my last gasp before I give up on this printer. It's so frustrating and RatRig as a company has some of the poorest support I've ever encountered. The IDEX support and the large format of the printer were the primary reasons I purchased it and getting the IDEX system to work, at least in my experiences, is not a simple a process.
ArgueForSport
ArgueForSport•2mo ago
Cannot really argue with that. IDEX is really, really hard. Support is primarily user-to-user, and not Ratrig to user. For me, that was a huge surprise and disappointment. It seems those who have machines running well have mostly violated the laws of nature and bent RatOS into doing what was needed, in addition to hardware upgrades and mods. The VAOC is definitely buggy, and the machine is just so darned sensitive to anything being less than perfect.
Quite a few have abandoned IDEX and gone single toolhead. That leaves one with just an expensive large, single toolhead printer. Like you, I did mine for IDEX, which is the only reason I persevered. I'm still doing tuning, lol. My life's work has become turning electricity and rolls of filament into test, tuning, and calibration parts in lots of different materials. But I'm getting better at it, thank goodness
rms497
rms497OP•2mo ago
I started to get real nervous when I realized there isn't even so much as a support email address on the RatRig website. In retrospect I should have cancelled my order at that point. But the idea and concept of the printer are incredible. I wanted very badly for all the misgivings I was having to be wrong, was just fooling or lying to myself. What really is ridiculous is how they use this forum. It's "not the place for official support" when it suits them and the next minute they will direct you to it for support. Anything to shirk responsibility is the feeling I get dealing with them.
billyd
billyd•2mo ago
On the idex it is mandatory to use high pressure rails, machined xy joiners and hybrid belt bodies, and GATS to tension the belts in my opinion. Even then many of us still end up with an xoffset error of -0.5mm. My guess is the fact there are three floating datum points on the x axis. The T0 endstop, the T1 endstop and the vaoc camera location. None of these datum points are fixed relative to one another precisely and can vary in location from printer to printer depending on manufacturing and building tolerances. My guess is if these three locations could be precisely placed relative to one another, the problem wouldn't exist. But there is no simple way to do that. You'll notice on the y axis there is only one endstop at y minimum. So determining the y location of the vaoc precisely is a trivial matter. That is why the calculated y offset is usually exact and it's always the x offset that has the error.
rms497
rms497OP•2mo ago
I got the Z1 rails last night, cleaned them and greased them this morning and Im installing this weekend. I really hope this does the trick. Though I was also realizing last night, aside from the extrusions for the frame and the electronics on the back, I've replaced more/less every major component that came the kit. Haa! 🙂 I've sunk so much money into this thing I guess Im pot committed and can't give up until it's working.
billyd
billyd•2mo ago
I would imagine there will be a v5 version of the idex that will likely include these hardware upgrades. I also think they need to figure a way to get rid of the T1 endstop and do everything off of T0's endstop
rms497
rms497OP•2mo ago
One other I think that is a big miss is the power supply. On big 500s, if you go the IDEX route you basically have no additional power on the one they send. I added 1 additional device, a camera, and my power supply started failing. And replacing that was f*ing giant pain in the ass post install. That's funny you mention that as the closest I have been able to get the IDEX stuff working is ditch the CALCULATE_DC_ENDSTOP values and play with them myself along with manual updates to the config data in ratos-variables.cfg. Definitely that lines up with my experienced that's a) it's always the X that is offset, y is always fine and it's the data for the DC offset, for the T1 endstop, that screws everything up
billyd
billyd•2mo ago
I suddenly thought of something and it very well could be the reason for the problem on X offset. What do you suppose is the triggering error in physical distance on these endstops. Maybe they are only accurate to +/- 0.25mm. That would account for the 0.5mm variation given we are dealing with two endstops on the same axis.
rms497
rms497OP•2mo ago
right, the tolerances in where the switches gets mounted to the toolhead could easily be causing the problem. The only thing close to working I have gotten is messing aournd witht he values of where the endstops are manyually I have found that if I subtract between 0.5 and 1mm from either side, I can a) have a bigger offsset than 1mm and it's much more closely aligned
billyd
billyd•2mo ago
Well not so much that as the actual endstop itself and where the triggering signal gets sent from one button press to the next.
rms497
rms497OP•2mo ago
oh I see, well something in that system seems to have more variability than they believed when they created it. or at least appears that way.
billyd
billyd•2mo ago
That is the problem with using two endstops. I don't believe it is accurate enough I've even read that there can be variations in klipper's response electronically to when the endstop is triggered vs when the x value is calculated. It is very complex. So when you take two different readings on a single axis to determine relative toolhead location, it is basically impossible to get an accurate value.
rms497
rms497OP•2mo ago
Oh I see. you are saying even if the position was consistent, getting that value translated into klipper may not be consistent. I mean it would be completley inline with all my expereinces that RatRig doesn't properly QA their systems. I doubt they have full regression or long term testing setups. They do not seem to be a real company, or at least what I would know as a normal/real/proper/whatever company selling technology products. The fact there is no path for support and customers have to rely on sending individuals inside the company emails is freaking crazy. No ticketing system, no nothing like that.
billyd
billyd•2mo ago
If you think that's bad, buy a Tesla
rms497
rms497OP•2mo ago
haaaa! i actually do own some Tesla stuff, a solar system and it's generally hands off, but I did have to get support once. It was a fucking nightmare and it appeared to be impossible to interact wihtn anything other than some shitty AI agent that was basically useless. if it's like that for their cars, damn I'd be pissed.
billyd
billyd•2mo ago
Yes the cars are fine. Just kneel down in prayer before contacting them for service. You will need divine intervention to get them to respond and actually do something.
Nocare
Nocare•2mo ago
Correct me if you think I am wrong but; End-stops shouldn't matter for anything except not having to do VAOC every single time. Which is outside the intended use case for V-core 4, they specifically want you to run VAOC before each and every print. Was too much of a pain in the ass for me so I got OpenCV to do it for me automatically as part of the print start procedure. But given the kinematics involved, as long as the toolheads do not hit each-other when going to VAOC and as long as they have enough room to park without crashing. given error in the end-stop position. There is nothing stopping the system from functioning with even really bad end-stops. My offset x-offset was -0.17 with only the x-gantry tube being changed out for a titanium one since I have a heated chamber. Guess I got lucky. Though a lot of my 3-printed parts were replaced with carbon-fiber nylon so that could also contribute to my mostly stock frame doing well. -Obviously not holding position when you leave the VAOC and go back is a problem. (assuming motors stayed powered) -Having your offsets drift not stay consistent across the entire bed is also a problem. That's why the tolerance is +/- an entire millimeter though. Because so long as those above two conditions are not happening, it doesn't matter if you x-offset is large. So long as you run VAOC right before a print and have no mechanical issues causing position drift. Its good. If you leave VAOC and come back and the position is not the same then your motors are skipping steps, belts are stretching, or something physical is bending. Otherwise the nozzle would have to come back to where it was since belts, steppers, and frame constrain its movement entirely. End-stop position shouldn't matter at all so long as the motors stay powered.
billyd
billyd•2mo ago
I am guessing as to what the problem is as I said. It seems to me it is obvious that the multiple datum points on X is the source of the issue that I and many others have. Whether it is the endstops, klipper, the endstop locations or some other factor I've left out or haven't thought of, the fact remains that almost no one has Y offset issues (assuming a good build), but everyone that has a consistent error in the print alignment is struggling with the calculated x axis offset with y offset perfect. The range seems to be from .5 to -.5mm out, with the caveat that the error is consistent everywhere on the print bed. If it isn't consistent, that is a separate problem. The only difference between caclulating the X offset and Y offset is the number of endstops involved. The Y location of the VAOC relative to each toolhead nozzle is trivial to calculate, since it is being measured against a single datum point (endstop) at Y=0. The x location of the VAOC relative to the nozzles of T0 and T1 is much more complex. This is because the exact relative locations of the min endstop and max endstop (as well as the x location of the VAOC) to each other are not known due to manufacturing, print, and build tolerances. So perhaps dead reckoning is used like on a ship. The ship knows where it is though. The VAOC doesn't. Ps you don't really have to run VAOC every time you print. I do it about once a month without issue. So I only have to modify the ratos-variables.cfg once a month at most after running VAOC.

Did you find this page helpful?