Just trying to cut some known files on Tarkin and the resulting cuts are about 4-5mm too small (width).
The entire piece seems to be scaled down
Is there some scaling factor setting somewhere that’s been set?
Sadly I just missed Danny leaving to ask about this.
Edit - cut the same file on Dorian and the cut part is the correct size. Should taking get red-tagged for this?
Coming up there to check it out. Thank you for posting!
@NickE I presume since the laser is not tagged in Skedda at this moment that everything checked out? I have a session tonight that will be very scaling-sensitive.
We’re up here trying to solve it now.
As is it’s cutting everything on the x axis ~1% short.
OK. I’ll still come in at 8… I might be able to work with a 1% scaling. Had hoped to do some large-format cuts, though.
This has me baffled. The Y is correct, the X is short by about 1%.
Thing is, these are set by timing pulley tooth ratios. It can’t gradually change. The only way the travel per step changes in any way is to change the tooth count on pullies.
Large backlash problems will manifest as being “short” when you change directions, which would be similar. But there’s no evidence of backlash on this magnitude- bidirectional rastering will be totally wrecked as the leftgoing and rightgoing lines won’t match up at all. That’s not happening. Any kind of slack or slipping or “lost steps” is going to cause more noticeable effects in other areas and that’s not happening. I went looking for any place where a backlash compensation could be set because that compensation, if inaccurate, will create the same sort of error.
The config has the correct value for travel per step, I pulled up older config files that get burned onto the Ruida and they don’t perform any differently. I temporarily linked Dorian’s LB installation to access Tarkin to send a job from a different install of LB, the prob is still there.
In the end I just reduced the configured travel per step in the config by 1%, and its X axis cuts measure up correctly. That’s restoring its accuracy overall, so it should be fine for the user- it’s not the right way to do it, but I just don’t see what is causing it.
Yeah, that does sound odd. I’m glad y’all could at least find a workaround.
FWIW, I can add a data point that the “x-axis 99%” issue has apparently been in effect since Thursday, Feb 27. My current project happens to involve cutting multiple copies of identical pieces that are 8-12" across. The ones I cut last Thursday are indeed scaled down along only one axis. It’s not super-critical for this project, so really just noting the experience in case it provides any clues to root cause.
OK found the prob. The linkage belt on the x axis wasn’t just slipping, it was walking smoothly over the teeth and basically ignoring them and acting more like a tire than a timing belt.
Crazy it was as repeatable as it was. I had it make a ruler with vector ticks, then raster awhile at max speed and accel and the raster didn’t show any slipping or shifting and I re-ran from there and it put the second set of ruler tick marks right into the first
I had a spare belt for that, but it was 15mm while the pullies were actually 12mm. A few minutes with a pair of scissors and now it identifies as a 12mm
Reset the scale and everything measures up as what it’s supposed to be
Hooray! Thanks for checking it out so quickly.