AVOR – a steel-framed medium-size router

[Neale]

Drive system

The drive system on my machine is pretty conventional. Nema 23/3Nm steppers driving the ballscrews through 1-1 pulleys and HTD5 belts.
I fitted pulleys partly because I wondered at the design stage about needing to change pulley ratios. However, given that the critical speed of the X ballscrews is about 900RPM (2005, fixed/floating bearings, although different critical speed calculators give slight variations) and the corner speed of the steppers is about the same, I was designing for a machine rapid speed of about 4500mm/min, which seemed reasonable at the time. Still does, in practice, as I tend to be making small fiddly bits where acceleration is more important to total cutting time than speed. In practice, after playing about with settings, I’m running with a max rapid speed of 5000mm/min which seems to work OK, and I’ve set the Y to be the same just for consistency. I don't see any real need to change pulley sizes.

However, pulleys also allowed me to mount the motors within the overall envelope of the machine rather than protruding, which is useful in a confined workshop where space is important. The motors sit on slotted brackets which allow belt tensioning and in theory the slots are long enough to allow other pulley size combinations.

I spent a long time wondering about two X motors or one bigger motor with a long belt. Two motors is mechanically better on my machine as it leaves one end completely unobstructed without needing multiple pulleys to guide a long belt across. However, I also wanted to use a CSMIO-IP/M motion controller which originally did not support dual motors on a single axis, sending me down the single-motor route. However, before I had finally committed to the single-motor design, CS Labs issued a new firmware update which provided minimal but adequate support for dual motors, so that’s the way I went.

I honestly have no idea how fast my machine will actually cut. Each time I start on a new job, I tend to wind the cutting feed rate up from what I used the last time, but my usual cutting speeds are below my max rapid speed still. I could, in principle, change my 2005/1605 ballscrews for 2010/1610 without too much effort, but I’m not sure if I would be using the increased speeds that should be possible, or whether I would have to compromise on acceleration which would slow down fiddly little jobs.

One issue relevant to the drive mechanism is how to set and then keep the gantry square. In any particular machining session, I have never had the gantry go out of square (as far as I can tell) unless I’ve had to hit e-stop, or had an X motor stall (which only seems to happen if I’ve hit e-stop and rehomed but without checking gantry square – a small out-of-square amount is enough to cause the gantry carriages to bind at full rapid speed). Setting gantry square within close enough limits for woodworking is easy – drill 4 holes at the corners of a square (making sure that you approach each hole from the same direction to eliminate backlash, if any), poke a matching drill shank into each hole, and measure the diagonals of the square. I wrote a little bit of gcode to do this, using a peck drill cycle. I found that a digital caliper was essential for this process as I couldn’t accurately set and read a Vernier caliper while it was on the bed. Adjust via whatever means you have provided, and recheck. Repeat until you get bored, or you’ve achieved the desired degree of accuracy! I had deliberately made the gantry feet mounting holes, where they bolt to the sliding carriage assemblies at each end, oversize to allow for a little bit of tweaking at this stage.

Ok, so that’s the gantry square for the moment – how do you make sure you can rehome to that position? In my case, as the motion controller understands enough to drive two motors in parallel but not enough to home them to separate predefined home positions, I have to do the homing of the slave axis “manually”. I have limit switches fitted to X on both ends of the gantry, although the motion controller only uses one of these. So, I hit “ref all home” in Mach3, and the motion controller will bring the gantry to a home position with just the “master” X axis limit switch tripped. Z and Y home normally with just one switch each, of course. With the gantry still in the home position, I hit e-stop, and power is removed from the motors so I can then turn the slave X axis ballscrew by hand. I tweak it until that side limit switch is just tripped (using the built-in LED in the switch). Then hit reset on the control box, hit “reset” in Mach3, hit “ref all home” once again as Mach3 needs you to rehome after any reset, and I’m ready to go. I should probably just mark the pulley instead of peering at the LED but I never quite get round to doing that kind of thing. Instead, I spent quite a lot of time tweaking the limit switch and its trigger block until it was triggering at just the right point. In practice, I hardly ever need to do this more than once per session, and it only takes seconds. The conclusion is that if the only thing stopping you going down the CSMIO-IP/M route is the lack of ability to properly home a dual-motor axis, then stop worrying about it – the manual approach is really not a big deal. The IP/M has a number of good features and I wouldn’t willingly throw those away. However, if I were starting again today, I would seriously look at, probably, the UC300ETH (I am a big fan of Ethernet for this kind of environment) and a decent BOB to go with it, or possibly the Dynomotion hardware and LinuxCNC.