Welcome! Log In Create A New Profile

Advanced

Printer Homing (microswitches and delta peculiarities)

Posted by Trakyan 
Printer Homing (microswitches and delta peculiarities)
November 27, 2017 06:29AM
I'm designing a GUS simpson derivative printer right now, and I've managed to minimize wiring mess, with all but the hotend wiring fitting and staying under the build platform. The one hiccup with that is that are the microswitches which need to be put around the elbow of each arm joint. While this is the perfect excuse to add some drag chains which I personally think add +15 awesome to any printer, I've recently changed my mind on this matter. I started this build with the intention of making it cheap, this led to the idea of a minimum viable product, and then removing unnecessary parts and assemblies, and trying to make the machine dead simple to assemble (and then calibrate). Micro switches while not expensive or hard to include and assemble seem like a prime candidate for trimming to keep with the philosophies I've established.

A while ago, I saw a HaD article about the trinamic drivers with missed step detection, and the writer mentioned their potential for use in homing a machine's axis. This seemed like a great idea to me, with no downside other than the extra cost for the drivers over the typical reprap stepper drivers. Prusa has also recent decided to use them to eliminate microswitches on their machines. My question more or less boils down to are there any other neat ways to implement endstopless homing, or what commercially boards support this (ideally at lower cost end)? I know ramps can, with some additional jumpers but I'd like to avoid the mess. For the record, I'm aware of the idea of just running each axis in the homing direction for a while to crash into its home location, and it doesn't particularly inspire me with confidence.

Another question, is specifically about homing deltas. From what I've hear the end stop positions need to be at the same height (or have some kind of offset calibrated) in order for the thing to function properly. It's entirely possible that I've misunderstood, but some clarification would be nice. On the GUS simpson design, I suspect this would be analogous to the maximum extension of the arms. I have some ideas for auto calibration to take care of this and save the end user the trouble of calibrating these.
Re: Printer Homing (microswitches and delta peculiarities)
November 27, 2017 07:11AM
Quote
Trakyan
A while ago, I saw a HaD article about the trinamic drivers with missed step detection, and the writer mentioned their potential for use in homing a machine's axis.

This is implemented in the current beta series of RepRapFirmware. There are some limitations on using stall detect for homing, described at [duet3d.com]. In summary, if you are not looking to implement resume-print-after-power-fail, then it's entirely practical for the X and Y axes of a Cartesian printer and for the towers of a delta. If you want resume-after-power-fail too, it's trickier.

Quote
Trakyan
My question more or less boils down to are there any other neat ways to implement endstopless homing, or what commercially boards support this (ideally at lower cost end)?

If the printer has a Z probe, it can be used for Z homing instead of a microswitch. The RepRapPro printers used the IR Z probe to do X homing too, by having a tab at the end of the X axis that the sensor detected. So they needed just a Y microswitch.

Quote
Trakyan
For the record, I'm aware of the idea of just running each axis in the homing direction for a while to crash into its home location, and it doesn't particularly inspire me with confidence.

It's not so bad if you reduce the motor current while homing, to prevent the belts jumping. RepRapFirmware has provision for doing this (M913 command). However, the homed position will only be known to the nearest multiple of 4 full steps. This may not be a problem if you have good auto calibration, because once cycle of auto calibration is probably enough to determine and compensate for the uncertainty.

Quote
Trakyan
Another question, is specifically about homing deltas. From what I've hear the end stop positions need to be at the same height (or have some kind of offset calibrated) in order for the thing to function properly.

That's right. Normally the offsets are calibrated in software these days, instead of providing mechanical adjustment.

Edited 2 time(s). Last edit at 11/27/2017 07:12AM by dc42.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Printer Homing (microswitches and delta peculiarities)
November 27, 2017 05:20PM
By doesn't inspire me with confidence, I meant more that I didn't really like the look or sound of the motors slamming into and continuing to barge against the hard stops for a while. I have no doubts that it works, it's just not something most people will want to see or hear from their printer and new users will probably think something is wrong. And I think with proper belt tension the motor will just skip steps rather than the belt skipping teeth.

I'm aware of using a bed sensor as the z axis limit switch, but the idea of using it for the X axis is new to me. On a printer that moves the head in x and y this could home all three axis.

4 full steps isn't a big issue, I just want the printer to be in a more or less known position when homing. I don't intend to use them as reference positions as that would require calibration from the user. I'm planning on checking the arm lengths against some known distance (i.e. bed length) to set a reference for their maximum extension. I've run into a hiccup though as the relative arm lengths for a given XY position vary with z height (on a linear delta all three carriages move up by the desired height, their relative positions stay the same) which means the z height at which I'm probing is important. So if I found the end of the bed in XY, that would be a different arm extension depending on at what height it was probed. I could get the user to measure the z height of the effector, but at that point they might as well calibrate the end stop positions.
Re: Printer Homing (microswitches and delta peculiarities)
November 27, 2017 06:49PM
Quote
Trakyan
By doesn't inspire me with confidence, I meant more that I didn't really like the look or sound of the motors slamming into and continuing to barge against the hard stops for a while. I have no doubts that it works, it's just not something most people will want to see or hear from their printer and new users will probably think something is wrong.

I agree, it's not a nice thing to see.

Quote
Trakyan
I'm aware of using a bed sensor as the z axis limit switch, but the idea of using it for the X axis is new to me. On a printer that moves the head in x and y this could home all three axis.

To home Y as well as X this way you would need to work out a sequence such that you always know which tab the sensor is picking up. Something like:

- Raise head 5mm (to make sure the sensor isn't triggering on the bed)
- Move head +10mm in the Y direction (to make sure it is clear of the Y homing tab)
- Use sensor to home X
- Move head to X+10 to get it clear of the X homing tab
- Home Y
- Move head to centre of bed
- Home Z

Quote
Trakyan
4 full steps isn't a big issue, I just want the printer to be in a more or less known position when homing. I don't intend to use them as reference positions as that would require calibration from the user. I'm planning on checking the arm lengths against some known distance (i.e. bed length) to set a reference for their maximum extension. I've run into a hiccup though as the relative arm lengths for a given XY position vary with z height (on a linear delta all three carriages move up by the desired height, their relative positions stay the same) which means the z height at which I'm probing is important. So if I found the end of the bed in XY, that would be a different arm extension depending on at what height it was probed. I could get the user to measure the z height of the effector, but at that point they might as well calibrate the end stop positions.

From the little I know of the GUS Simpson, I think that you could use motor stall detection to find the maximum raised position of the arms to within 1 full step, then use a Z probe and least squares auto calibration in firmware to correct the positions.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Printer Homing (microswitches and delta peculiarities)
November 27, 2017 11:20PM
I know it's probably a complicated matter, but could you give me a quick overview of how least squares works and what it actually calibrates for?

As for the GUS Simpson, I've got a calibration routine in mind that involves homing each arm to the same (but unkown) length required to reach the opposite edge of the bed. From there by probing a known XY coordinate I should be able to use the ratio of the arm lengths to solve for the height of the effector. I'm still mulling over whether this requires an exact or approximate steps/mm to work. I think an approximate one will work for the first run, and it can be run iteratively until the error between iterations fall below a given threshold. I'm hoping to be able to auto calibrate steps/mm since the steps/mm depends on the printed parts and is likely to vary.

The above should work in theory but requires a known XY coordinate I think, and I can't think of any way to home the effector to a known XY coordinate without knowing steps/mm. Like I said an approximate steps/mm should work for a start and can be improved iteratively I think but I'd like to see if I can come up with something else.

EDIT: What I'm having trouble working out how to calibrate is the height of the effector as I'll need this to work out steps/mm. I've considered estimating both with the above method, then repeating until the error drops below an acceptable threshold, but I'm not sure if the values will actually converge.
EDIT2: If there's a simpler way to work out steps/mm and I'm missing it please let me know.

Edited 2 time(s). Last edit at 11/27/2017 11:45PM by Trakyan.
Sorry, only registered users may post in this forum.

Click here to login