Auto-Squaring UCCNC

[Kitwn]

When I recently moved from using LinuxCNC to UCCNC it was said that it is not possible to auto-square a two-motor axis using software settings in UCCNC as it is in LinuxCNC. I've done some test today to show that this is not the case.

When using UCCNC to drive a two-motor machine, the long, dual-motor axis is designated as X (or Y if you prefer for some odd reason) and another axis (typically A) is slaved to it. The screengrabs below show the setup for my machine. Separate limit sensors are used for homing the two sides of the gantry and a "Back off" distance specified for each. You should aim to make your machine square itself as accurately as possible with the two back off distances set equal. This is done by adjusting the position of one of the limit switches. However, axis A does not become a complete slave to X until after the back off move is completed which means that fine adjustment of the squaring can be done by making the back off distances slightly different. UCCNC will only let you enter back off distances to an accuracy of 0.1mm which is probably adequate for most of us. If not then I'm sure we could pester the makers to allow an extra decimal place.

Tests were done today by fixing the X back off and making small changes to the A value then re-homing the machine and confirming that A moved to a different finishing position and X stayed the same. Changes in multiples of 0.1mm were confirmed possible.

Kit

[Soyb]

Thanks for a useful post, I am in the process of building a twin Y axis gantry machine and one of my questions was going to be about how to square the axis, either use one limit switch and check the gantry against the frame of the machine and manually adjust one of the ballscrews or use two limit switches and have different back off values.

[JAZZCNC]

When I recently moved from using LinuxCNC to UCCNC it was said that it is not possible to auto-square a two-motor axis using software settings in UCCNC as it is in LinuxCNC. I've done some test today to show that this is not the case.

Think that was me who told you that and strictly speaking it doesn't work like Linux CNC because it doesn't have the flexibility in that you can control each motor separately in the positive or negative direction which is what I was mostly meaning. But as you have found it can be done in a round-about way and still end up with similar results but I strongly urge people to square the gantry manually rather than rely on offsets that twist other components like ball-screws and place binding on linear rails etc.

When you get into the bowls of UCCNC and its powerful scripting then you can make it do pretty much whatever you want. (provided you can program in C#)

[Kitwn]

Think that was me who told you that and strictly speaking it doesn't work like Linux CNC because it doesn't have the flexibility in that you can control each motor separately in the positive or negative direction which is what I was mostly meaning. But as you have found it can be done in a round-about way and still end up with similar results but I strongly urge people to square the gantry manually rather than rely on offsets that twist other components like ball-screws and place binding on linear rails etc.

When you get into the bowls of UCCNC and its powerful scripting then you can make it do pretty much whatever you want. (provided you can program in C#)

I'm with you 100% on getting the basic mechanism squared within a fine tolerance and that doesn't just mean using two motors with separate homing and tweaking the position of the sensors as I wrongly suggested above. Having given this some more thought, the accurate matching of the position of the two homing sensors is also critical in maintaining squaring and preventing strain on the machine. Errors in sensor position will strain and twist other components in exactly the same way as adjusting the back off distance. I don't recall seeing this stressed in past discussions of using two motors with separate homing. What matters is that the gantry must sit square on it's bearings and relax naturally into something very close to the correct alignment before we start doing any homing. The sensors then need to be placed to maintain this alignment when the two motors stop during homing and adjustment of back off distance then used to correct the last sub-millimetre errors.

I'd suggest that the correct sequence of alignment for this kind of machine is:

With motors disabled let the gantry relax into it's natural position.I check this by disabling the motors and manually turn one screw while holding the other one fixed. You soon feel one screw tighten up and can set the central relaxed position.

Re-enable the motors (without doing a new homing sequence!) and check squareness. Adjust the gantry mountings until you're as close as you can get.

If you're not confident of the accurate matching of your two sensor positions try creeping the machine towards the sensors and check they trigger at the same time. Adjust as required.

Only now should you use tweaks of back off distance to correct remaining sub-millimeter errors which could be in the gantry or the relative sensor positioning.

I had a quick go at aligning my machine today and needed a noticeable shift of the gantry on it's mountings to get good alignment in the relaxed position before homing. I didn't check the sensor positions but ended up with the back off distances different by 0.5mm which is well within the strain tolerance of the round rails I'm using and suggests the sensors are not too far out.

The as-bulit homing in UCCNC is less flexible than in LinuxCNC but doesn't need quite as much reading of the instructions to get it working. I particularly liked the Linux way of moving quickly onto the sensors to find them in a short time then backing off a few mm and moving on again more slowly before the final back off. This makes homing both quick and accurate. As it must be the best part of 20 years since I had a brief play at programming in C# I'm not about to try and Make UCCNC do the same, though I'm sure it's possible.

Kit