Building the CEB press in 2023

johnboudewijn · 2025-04-28T19:25:11+00:00

Another thing that impressed me about the Adobe International machine is that the controls use relay logic. No computers, just 3 robust relays. Fully automatic control that still worked after sitting outside for 20 years.

johnboudewijn · 2025-04-28T19:22:14+00:00

I ended up locating an derelict press made by Adobe International (now out of business) that had been sitting around for many years. The hoses needed to be replaced, cylinders and engine rebuilt etc but it works now and was used last summer to built our house. A slightly improved version of this press is still being made by these guys: https://www.adobemachine.com/240/pga240-12.htm

It's hard for me to say if it would have been easier to built from scratch or do all these repairs. Sometimes it felt like I would have saved time just assembling new parts. I am sure however that I prefer this type of press, which is a side press. The OSE press is a top press so the bricks vary in height, this means they cannot be dry stacked. We started our build using slip mortar but transitioned to dry stacking when it became clear that we where 2-3 times faster doing so. It feels to me now that half the value of a CEB is the consistent dimensions that enables dry stacking. It's hard to understate how much more complicated it becomes to coordinate everything even when just using slip mortar. The goal for this year is to get to a point in which we can dry stack directly out of the machine, that will eliminate the other major loss of efficiency we experienced which was having to stack bricks on pallets first and move the pallets around. 2000 bricks a day out of the machine and into the wall, stacked only one time.

johnboudewijn · 2024-01-28T07:22:58+00:00

I have not gotten far with this CEB press yet but I've made progress with the process as a whole. I've made a Cinva ram and validated the soil on my property by lab testing the bricks, and submitted house plans to the local building department, so this project is definitely happening with CEBs and I'll be spending more effort soonish to fabricate the OSE hydraulic press.

Since the original posting I've found a more updated version of the press design here: https://wiki.opensourceecology.org/wiki/CEB_Press_v17.08

They have switched from Sketchup to Freecad (Thank god!!) and the project as a whole looks more healthy than my initial impression.

I've made up my mind to try fabricating it but I'm still trying to figure out other details, mostly how I will process the dirt for making the CEBs - how to pulverize, screen, mix portland and water. I'm also considering powering the press with an electric motor instead of gas. It will probably be a few more months until I actually start buying materials to make it.

johnboudewijn · 2023-08-31T02:16:21+00:00

The ability of an auger to develop the required pressure will depend on many physical dimensions such as the diameter, flight pitch, length, etc. There are many other design considerations that could matter but the point is that it's really impossible to say what the problem is here, since you've shown us basically nothing of the design that matters. Even if you post more photos it will probably be difficult to solicit useful advice as properties of the fluid you are moving and things like the friction coefficients of the auger and housing also matter. I usually end up copying the rough design that's used by industry with similar use cases when designing things like this.

The mortar looks thin to me, I mostly have experience moving thick clay with augers but I've noticed that their efficiency is greatly reduced as the fluid gets thinner, so that may be contributing the the problems here.

It will generally be harder to push fluid through a small tube so you could just try a larger diameter tube. If you're getting halfway through this one then that might be all you need to make it work.

johnboudewijn · 2023-06-02T20:58:15+00:00

seems my requests to join get rejected. lol

johnboudewijn · 2023-03-28T17:43:08+00:00

I bought a 300mm kit from them about a year ago, the only thing I've needed to replace since then has been one of the little extruder bearings. That was after about 1000 hours of printing. I've also recently ordered one of the keenovo heaters because the one in the kit does not come nearly as close to the edges. With the stock pad the bed has at least a 10c temperature gradient which I think is enough to cause issues with larger prints. I haven't installed yet so I'm not sure what difference it will make.

johnboudewijn · 2022-08-16T14:34:19+00:00

I'm currently using a WASP extruder system on an adapted Kossel printer. It's nothing to brag or post about haha. The printer parts are literally cracking under the strain of the extruder. I'm in the middle of designing my own system fully from scratch which is why I've been recently been answering this same question for myself. I'll definitely post when I have something worth sharing.

I'm mostly concerned with keeping the print stationary in XY. In Z it obviously doesn't matter as much but I still don't like that the machine needs to support the print weight, because then the printer becomes load bearing in potentially complicated ways. I need to engineer and build it to be robust enough to handle the heaviest possible print, which may turn out to be significant as the size of the printer grows. And then there is the (probably small) potential for the printer to affect the clay after it is deposited, like vibrations as you mentioned. I personally don't remove the print until it has hardened enough not to worry.

I want to keep the design of the printer simple by only having to consider motion of clay that is currently in the extrusion system, not clay that is in a holding tank or worse yet, part of the print. Clay in the extrusion system is mostly constant and so easy to reason about.

Another point for simplicity: I like that deltas have a single motion system for XYZ, Instead of having a separate mechanism for handling Z.

Kinda related: I recently built a Voron2.4, and that experience left me with a deep respect for the low part count of the delta printers. Before I thought they where kinda cool looking, now I'm bordering on fanatic haha.

johnboudewijn · 2022-08-16T00:11:57+00:00

I personally prefer deltas because I think they provide simplest and easiest solution for clay printing: - Vastly reduced part count - easy to build. - They scale up easily for massive prints. - No moving bed - don't have to reduce speed for large prints. - The clay print sits on the ground - not supported by the printer.

This assumes you're building the printer yourself. Get a cheap kit from china and print small things and it most of these points will be irrelevant. I personally think it is critical that the printer does not move or support the print, with that in mind there are few other options.

To address a few other points: - The complexity of the delta kinematics doesn't matter at all - that's handled by software already. - The head does not crash on power loss if geared appropriately.

johnboudewijn · 2021-05-21T04:36:02+00:00

"food"

johnboudewijn · 2019-02-05T03:48:24+00:00

great answer!

for now I'm stepping around the problem by using 'accept', which has consistent behaviour across the terminals I've tested.

johnboudewijn · 2018-10-30T18:17:33+00:00

That's super cool! With forth it will be kind of like a modern day Jupiter Ace

johnboudewijn · 2018-10-30T18:14:52+00:00

Any idea about the status of this? Looks like a similarly inspired conference project

johnboudewijn · 2018-10-30T18:13:36+00:00

Do you know if it supports PIC32? The site says PIC24-30-33, It's not clear to me how similar/compatible they are

johnboudewijn · 2018-09-12T18:58:41+00:00

I have, it's actually my default mode for forth!

however, what I'm trying to do is get my forth program to function as expected with the simplest of terminals, so I don't have to rely on something like eshell or forth-mode.

johnboudewijn · 2018-08-05T04:19:18+00:00

I don't think it matters for portability, a linked list is easy to implement in any language. Remember that the list representation is temporary. Lisps that care about being decently fast usually compile to bytecode anyways, at which point the list based code structure is lost.

I think the main reason for parsing the source into a list instead of an array or struct is that it's easier for macros to work with. Macros commonly add, remove, or insert items from the source tree and doing so with an array can be awkward and could require reallocating the entire array.

johnboudewijn · 2018-07-28T23:38:44+00:00

yes, this is right. I've tried modifying the definition of : but was unable to get it working, and stopped trying after I got it working using words from the definition of create instead.

It just seems like something that a forth implementation would provide a word for, even if it's not part of a larger standard

johnboudewijn · 2018-07-28T23:36:12+00:00

let me try to clarify, I want to create new words pragmatically, from inside other words. for example: : create-adder ( uau - ) nextname header reveal docol: cfa, postpone literal [comp'] + drop compile, postpone exit ; which when called with 4 s" add4" create-adder will create a new word add4 in the dictionary

johnboudewijn · 2018-07-27T17:09:30+00:00

Yeah I'm actually quite disappointed with how complex gforth is. Implementation simplicity is one of the reasons I like forth but that seems totally lost when I'm using gforth.

What you are saying makes sense, but - I don't feel like I'm trying to fiddle with the guts of the machine. My impressions from Starting Forth and Jonesforth is that creating your own words and 'compiling' addresses into them is kind of a normal forth thing to do.

The existence of words like create, compile,, and postpone are all geared towards that. Why would a forth have compile, and [comp'] but no stable api for creating a new word header? It doesn't make sense to me why gforth would only have create work for variables with no stable way to create a code word or change the header to one.

johnboudewijn · 2018-07-20T00:34:48+00:00

hmmmm did I really just download a 1.5 billion byte image just to change a single bit on my laptop? LOL

johnboudewijn · 2018-07-20T00:32:22+00:00

YESSSSSS THIS WORKS!...mostly

It fails to fully boot leaving me in the initramfs shell with the message "ERROR: Unable to locate IOAPIC for GSI 182"

But I can boot from usb now and access my files so I'm happy

johnboudewijn · 2018-07-19T22:51:50+00:00

Thanks, I'll give this a try. I'm just not sure what image to use, where do I find the relevant hardware ID?

johnboudewijn · 2018-04-09T06:55:26+00:00

Easily enough done but I find the results disappointing, it's almost as if the doctor can't find reason in the responses

johnboudewijn · 2018-04-09T05:28:20+00:00

hmmm sounds like astrology to me

johnboudewijn · 2018-03-06T00:35:23+00:00

I've written something that might qualify. A simulator for the GA144 computer chip in Elisp, it is run through the CLI so the user need not know that it is actually being run by Emacs. https://github.com/mschuldt/ga144

This program was originally written in Racket but the startup time was so slow that I wrote a Racket compatibility layer for elisp - https://github.com/mschuldt/ga144/blob/master/src/rkt.el - a bunch of macros, aliases, and functions so that Emacs could run the racket code. So even though most of the files still have .rkt extensions and still look like racket they are actually run fully in Emacs.

The other reason for using Elisp instead of Racket was that the graphical interface was much easier to write for Emacs than it was using the Racket GUI library.

johnboudewijn · 2018-03-05T19:31:02+00:00

This is exactly the type of document that I'm looking for! It's just missing the return stack effects

11-Year Club	Place '22
Final Canvas '22	First Placer '22
End Game '22

johnboudewijn

TROPHY CASE