On
27 November 2024 at 09:25 JasonB Said:
Ever wondered how G-code is translated into the job and cutter movements needed to make an object by subtracting metal from a block of stock?
Dave
If you take a look at my early answer where I showed the G-code that can be used as a source for the co-ordinates you will see that the code is the result. In the case of the hole pattern it is actually the post processor within the CAM that has done the calculations to transfer the holes in the 3D model into the G-code. Gets a bit different when the G-code tells the cutter to move in an arc or at an angle between two points.
The Post processor is just like the online PCD calculators, the CAD programs circular feature, the DRO’s PCD function they all do it for you so no need to start working out formula for a spread sheet or go downloading multiple other programs.
We’re still not on the same page Jason! Your hole examples only cover the simple case, where most of the holes are equally spaced around a common radius. As this is trivially easy to solve with eyeball methods, practical man shouldn’t be too pleased with himself! I’m addressing the wider issue raised by the thread title, which is how to solve coordinate problems where the hole angles and radii are not equally spaced by angle around a common radius. For that, it’s time to engage theory.
Jason says “The Post processor is just like the online PCD calculators, the CAD programs circular feature, the DRO’s PCD function they all do it for you so no need to start working out formula for a spread sheet or go downloading multiple other programs.” True, except that’s a conceptual step behind what I’m failing to explain.
Perfectly reasonable for a practical man to see the post-processor and other programs as black-boxes that magically do the needful without him having to understand the underlying theory. But someone had to design the post processor, CAD/CAM weren’t delivered by a stork. This is engineering at a higher level requiring applied mathematics, building on centuries of smart theory.
Practical workshop experience doesn’t help here because the tools and methods used by software engineers are different, and they’re obliged to solve seriously difficult logic problems. For example, when calculating the tool-path needed to cut a part from solid stock, it’s not possible to simply direct the tool by the shortest route, which is easy to program. What’s needed is an algorithm that ensures the tool won’t crash into the stock or remove metal in transit that’s going to be needed later. It has to maintain the integrity of the finished shape. Much more difficult.
Most of what I do in the workshop stands on the shoulders of giants whose genius is taken for granted. I used HV6 index wheels as an example of something a program can do very simply, and the same code can be tweaked to do index wheels for other rotary tables. Except I cheated by not tackling the maths! I dodged the maths by copying the number of holes required from the manual.
The HV6 has a 90:1 worm and is indexed by 3 wheels each with 6 rings of equally spaced holes. Wheels needed:
AWheel = [15, 16, 17, 18, 19, 20]
BWheel = [21, 23, 27, 29, 31, 33]
CWheel = [37, 39, 41, 43, 47, 49]
The number of holes in each ring is calculated to provide all the common angles from a 90:1 table. As it’s not obvious how angles are wound out, the HV6 comes with a table showing which wheel, ring and clock setting are needed to do the necessary division. A problem with this system is the indexer can only do integer arithmetic, so some angles are approximations, and many others not available. OK for most practical purposes, but a stepper motor driven by a microcontroller does better and is easier to use.
An engineer who can do the maths, calculated the minimum number of wheels and holes needed to produce a useful range of angles. HV6 wheels won’t work on a 60:1 or 48:1 rotary tables so the sums have to be done again for them. Woe if an indexers table is wrong or lost, because Practical Man is unlikely to have the skills to work it out himself!
Specifying the gears needed to cut a given range of threads on a lathe is a similar problem. Smallest number of wheels possible, they have to fit on the banjo, and the number of teeth have to generate the required ratios. Again, practical man only has to follow a table, which is fine until the table is lost, or a second-hand machine is bought with missing or incorrect gears.
If Practical Man runs into an indexing or gear set-up problem, his best hope is a forum friend having the information. Otherwise, he has to tackle the maths, which is intimidating. Don’t care for it myself, but see the value, and am prepared to have a go.
I’m fascinated equally by practical and theoretical engineering. Apologies if my excursions into theory offend those who enjoy hands-on more than thinking, but I’m not going to write ‘Up Jumped Baby Bunny” posts just to please them. I’d rather understand than be ignorant, and believe most Model Engineers are like minded. Also believe engineers should strive to do better, which might mean learning new tricks, and changing their minds. Change is horrible I know, but anyone who finds that unacceptable has no obligation to read my posts.
Dave