Rehome absolute coordinates on 32ft x 16ft x 9ft gantry-style 3D printer

More
09 Dec 2016 23:42 #83860 by russ.northrup
Long time user (10+yr), first time poster...I'm looking for ideas and suggestions outside the box.

A group of us built a 32ft x 16ft x 9ft gantry-style machine for 3D printing. Yes, feet.

We have a small drift of the absolute coordinate system in the positive X direction which changes with length of the print path.

I'm not so concerned with 0.1 inch error over 32ft, but an accumulated error over 100 layers is 10 inches.

It would be nice to just rehome absolute X after each layer. But everything I've seen on the forums says I can't home to the switches inside the G code.

This seems arbitrary. It's certainly software-enforced.

- Could I parallel connect the X limit switches to motion.probe-input in the .hal file? Then run a G38 and a G10?
- Is it possible to do something like this in python?
- I suppose I could mod G28. (last resort)

We've already reduced this problem by an order of magnitude. We're just looking for something so we can move forward with bigger issues and revisit this later.

Any ideas?

Thanks!

Please Log in or Create an account to join the conversation.

More
09 Dec 2016 23:51 #83863 by andypugh

We have a small drift of the absolute coordinate system in the positive X direction which changes with length of the print path.

Rather than work round this, can you solve it? Do you have any idea where it is coming from?

- Could I parallel connect the X limit switches to motion.probe-input in the .hal file? Then run a G38 and a G10?

I think that the idea has some merit, but in practice would fail on the details.
You could temporarily make the limit switch not trigger the limits, but it is harder to persuade LinuxCNC to exceed the soft limits to find the probe,
A better (and easier) plan would be to add an extra switch/sensor inside the limits and probe to that.

But better still would be to eliminate the drift problem. Is this a stepper system or something with encoders?

Please Log in or Create an account to join the conversation.

More
13 Dec 2016 16:32 #84042 by russ.northrup
We are actively addressing eliminating this issue, and have reduced the problem by nearly a factor of 10. It's just that we don't want to halt programming, live testing, etc.

This line of investigation is purely a stop-gap to continue to move forward.

FWIW, we believe the problem to be asymmetric loading, complicated by the overall size of the machine.

...I mean, children are building gantry devices with Lego, how hard can it be to make one a couple orders of magnitude larger? :)

Thanks!

Please Log in or Create an account to join the conversation.

Time to create page: 0.072 seconds
Powered by Kunena Forum