Neat hack to ATX power supply

I have been progressing slowly with my reprap build, spending a little time here and there modifying the electronics so that the wiring is neater. There are some details on the reprap wiki about how hack an ATX power supply to give you a universal power supply. This is my sightly neater solution which is specifically suited to reprap only.

With minimal filing the standard ATX power supply grommet hole can be opened out to fit a standard XLR socket. I used a female socket as opposed to the male socket mounted on the reprap. This is standard practice and ensures that the pins of the socket cannot be touched if the connector is removed. In general the live end is protected and the cold end is not.

Advertisement

Hobbed M4 Insert

After a few helpful comments I was pointed in the right direction for drilling a hole down the middle of my hobbed M4 insert. Unfortunately I didn’t have a drill vice, so I used my trusty Block’o’Wood and a fair amount of extra caution instead.

It really is amazing how well this technique works, the drill bit doesn’t have to be perfectly centered but because the work piece is spinning around a central axis its near impossible not to get the hole dead centre. I guess this is why a metal lathe has the drill bit set-up in the tail-stock.

Here is the hobbed insert with the central hole:

I am very pleased with the result, as it runs nice and true when rotated. All I have to do now is drill the M3 grub screw hole.

Parsing

For the purpose of understanding tools like Bison and Flex, I have been building a parser for RapCAD despite the fact that it will probably one day use a library version of OpenSCAD as the back end. My reasons for doing this are two fold, firstly I have never writtern a parser in Bison or a Lexer in Flex before, I have only writtern a trivial Recursive Decent Parser using .NET and Its something I have wanted to try for a while. Secondly I am interested to see how to implement such things as “variables that will”, and functions with function bodies, so that I might sometime provide a patch for OpenSCAD so that it can also do these things.

Things are moving steadily along, and I am now able to parse a simple test file containing the following:

module foo(a,b=1+2,c=1-2,d=1/2,e=1%2,f=12,h=1*2)
{
}

The parser then reads the text and turns it into an abstract syntax tree representation, which is stored in various objects. The objects all have a toString() method which when called produces following text dump:

Module: foo
Parameters: Param: a Param: b Expression: (Literal: 1 Operator: + Literal: 2 ) Param: c Expression: (Literal: 1 Operator: - Literal: 2 ) Param: d Expression: (Literal: 1 Operator: / Literal: 2 ) Param: e Expression: (Literal: 1 Operator: % Literal: 2 ) Param: f Expression: (Literal: 1 Operator: Literal: 2 ) Param: h Expression: (Literal: 1 Operator: * Literal: 2 )
Done.

So, I am thinking about the parsing of functions now, and its got me wondering about function bodies. There is a problem which I am not sure the best way to resolve. I would like to allow a function to have a function body consisting of statements. It would be meaningless however to have a module instance inside a function body, but for the current grammar to work a module instance is a type of statement. I have two options, either re-write my grammar to make a module instance inside a function body as a syntax error, or the other option which would simply be to make the syntax acceptable, but when it comes to evaluate it it will be a compile error.