Programming CNC machines in Haskell

While I like the general idea, it seems this project didn't go far enough.

What I think would be cool is to develop are DSLs that compile to g-code. For example, putting my hacker hat on, I think it might be fun to build a DSL for describing mechanical (analog) computers, this will compile into g-code for cams, shafts, gears etc. that could then be manufactured using CNC machines and/or 3D printers...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

This is a bigger subject than CNC control.

I've been sweating over a very similar problem myself lately. I've been trying to design a useful, flexible, reasonably abstract language for just describing complex physical things.

Formal verification of CNC programs to build things is a fine goal, but I think that before it can be useful we need to be able to fully and flexibly describe the things to be built. CNC is a type of assembly language very dependent on the local device; it should be emitted, not by humans, but by compilers.

What we want to do is build particular objects. But we want some flexibility (undefined behavior?) to allow for differences in locally available materials and processes. And, depending on the object, different qualities may be important to us.

Color, for example, may be an important material property for a toy bunny. For a bushing that holds an axle inside a sealed box, not so much. So we want to stop the build of the toy bunny if the right color isn't available, but go ahead and make the bushing green instead of white because we really don't care what color it is. Likewise, the exact measurements and tolerances of the bushing matter to us a lot, but the toy bunny, not so much. So we want to stop the build of the bushing if the local hardware can't produce tolerances within 0.01 mm, but let the toy bunny go ahead and get built.

It isn't enough to say what material you want to build it out of and what shape you want it. You also have to specify manufacturing tolerances, margins of error, dimensional constraints, acceptable substitutions if any and their effect on design, interfaces between volumes made from different materials (like conductors and insulators), and (this is important) which properties are the *salient* properties of the materials.

Consider the humble plastic interlocking brick, beloved of children worldwide. So, do you take your CNC file and build it out of whatever type of plastic you have available? Or whatever plastic your local fabber can handle? NO! If the plastic has the wrong degree of resilience and elasticity, you get bricks that take excessive force to snap together, bricks that break instead of snapping together, bricks that don't snap together tightly enough to build things out of, bricks that chip and break in normal use, etc.

You can adapt the design to work with most common kinds of plastic. It needs different wall thicknesses at crucial points in the sockets and/or pins where bending has to happen for the snap-together action to work. So how do we describe that to allow a local fabber can figure out what the "correct" pattern and manufacturing process for its particular grade of plastic might be? Not with CNC codes. CNC just tells the machine what shape to cut, and doesn't allow for any adaptation to locally-available materials or local capabilities.

Now consider the variety of manufacturing processes out there. There is everything from electrostatic machining to injection molding to CNC cutting to plasma welding to layered deposition to sand casting to vacuum forming to stamping to selective sintering. Most of these can be used to make an interlocking brick in a standard size. But the processes are so fundamentally different that there is not a single instruction in common in the controls for these devices. And even within each family of devices, different machines use fundamentally different control paradigms. Describing the manufacturing process in detail for such devices is like writing programs in machine code -- it is tightly tied to a specific hardware and incompatible with all other hardware. And that's because it's all about specifying process (do this, cut here, turn twenty degrees, cut that, etc) rather than result (I want a plastic brick that I can snap together with other plastic bricks made from the same pattern).

What I want is a language for describing objects, which I can use to make programs for producing those objects portable across different manufacturing devices and different kinds of manufacturing devices. I want to feed this program to a "compiler" that knows the local capabilities and how to control them, which determines whether it's locally buildable and if so develops a construction plan (which may entail emitting CNC or other "assembly-level" instructions) suited for the local devices.

The objects resulting from running the program would be slightly different depending on available materials, available manufacturing technologies, etc, but for practical purposes they should work "the same way" or be "the same kind of object."

This is exactly the same kind of abstraction over machine code that was provided by programming languages in the first place.

For the lego bricks I would

For the lego bricks I would have a physics model. To find a working brick with the materials provided I would start with the default shape and tell the program to change things like the wall thickness until the force required to shove them together was below a certain figure and the force required to take them back apart was above minimum and below maximum, within tolerance.

The program which takes a 3d model and turns it into instructions on how to make it with that machine seems achievable and practical, has it already been done?

I really like your idea of a language that describes exactly what is important in any given object. I think I will try to figure out a description of the comfortable chair. Dynamic properties seem like they would be very useful to specify.

In a similar vein ...

I thought about a more abstract language to describe analog computers (not limited to a mechanical (or hydraulic/pneumatic) realisation, but also with standard electronic circuits, be it ICs, discrete solid state devices or vacuum tubes) also for the fun of it and to try out different strategies of mapping the high level description to a given technology which in turn is described by a sub language. Apart from the hacking value of this undertaking it bears some similarities to analog modelling languages like Verilog-A, but with a slightly different scope. I bet such a language given that it provides a rich enough toolbox (translation to languages like SPICE for electronics, g-code for mechanical parts, etc.; as well as the possibility of simulating mechanical devices) could also make a fun toy for educational purposes for almost all levels (not only universities).

As for building something that would be accepted by the industry, I am doubtful. Engineers and designers dealing with building machines and circuits already have many tools and languages at their disposal and most often the deciding factor is being able to integrate a given tool into an existing or planned workflow. But I strongly agree that analog computers and mechanics could make for a very rich source of case studies for DSLs apart from the well known examples.

What I had in mind is much

What I had in mind is much more modest. I just want to be able to compile a description of a function (say f(x)=1/(x+1) in range 1..10) to a cut path for producing an appropriate cam, for example, and be able to deduce which parts will be needed (assuming an appropriately restricted language for describing functions).

Generating cam outlines

That should actually be pretty easy. If restricted to functions of one variable (as apposed to ones with two variables which probably could be realised using spheres with radius varying based on longitude and latitude) the cut path would be fully described by a function from current rotational angle of the cam to radius. Given one function from the argument to the function to be realised to cam angle and one mapping from the function's value to the cam's radius at that angle, you'd have a nice commuting diagram. The function's curvature would also be limited by width of the "head" that traces the cam's outline. And then there's the question of normalizing the function's range to something that fits application and manufacturing constraints with an appropriate read-out mechanism (scale) that reconstructs the intended function values. There will be some more analytical constraints imposed on the function, but the key problem here is that I am not sure wether a syntactic restriction on acceptable functions is enough (or indeed to constraining). May be just me: It's sunday and I'm the kind of pereson who always wants his real or complex functions with first, second, third, and sometimes fourth derivative. ;-)

That should actually be

That should actually be pretty easy.


I am not sure wether a syntactic restriction on acceptable functions is enough

Why does it have to by syntactic?

I am not sure wether a

I am not sure wether a syntactic restriction on acceptable functions is enough
Why does it have to by syntactic?

It need not be, the (abstract) syntax would just be the first thing that imposes constraints by simply leaving out some arithmetic expressions while allowing others. At least that is where I would probably end up starting when implementing such a program.

That problem wants a design tool, not a programming language.

I think the reason that you don't see any existing implementations of this is that what you want isn't a language; it's a design tool -- especially if you're asking for a real-world cam design that's part of a mechanical system moving at speed with real loads, rather than a demonstration piece. In order to produce a cam design of that sort, you need to provide a lot more information beyond the function; you need to specify the amount of load (and its dynamic characteristics), the operating speed, and mechanical constraints of that nature.

Here's the first Google result for "cam design tool", which I expect does almost exactly what you're asking for, though you may need to convert arbitrary functions (such as 1/(x+1)) into a piecewise-polynomial approximation:

(There are, of course, also domain-specific tools for converting arbitrary functions into piecewise-polynomial approximations, to handle that part of the problem.)

Design tools

I agree that for real world use you have to take into account the physical side of things, but that was not the original point as I understand Ehud's idea. In addition I am quite sure that the physical constraints (e.g. speed/vibration, load) are less tight when designing a cam for use in an analog computer as opposed to, say, a car engine; or at least are sufficiently different. Speed in analog computation devices appears to be limited by operating procedures which in turn are based on calculations taking into account the whole of the mechanism. Before you get into regions where speed is of importance for cam design, I believe that already other parts (interlocking gears, component solvers, etc.) of the analog computer would have locked up (based on viewing the US Navy instructional videos on fire control computers posted here some time ago).

The most interesting part of the site you mention for me is This book seems to provide detailed information about which functions are acceptable for cams and which are not. This is directly related to the original question of which constraints are necessary for a naive cam design program.