Hmm. SVG, a vector format? Your inkjet cartridges create a 2 dimensional raster of dots, so any image format would probably be more appropriate. There are slicers out there that generate images, GIFs for example (lossless compression in 1 bit or more). And there are a bunch of simple OpenSource readers available, too. BMP is another oh-so-simple format.
To reduce noise (which is difficult with the way steppers work and with a hollow wooden body), you can glue rubber mats to the worst offending surface (from the inside). There are mats for cars, but they dampen the high frequencies of metal sheets. I had some success with the heavy rubber mats that you can get at hardware stores to put under washing machines. They can easily be cut to size with a box cutter by bending them at the same time. But I assume there is no priority to this anyway
Image formats do not generally have multiple layers in one file and the header to say how it is built up. Just having the grid of pixels is not enough, the printer needs to know resolution. It also either needs to be readable enough that a microcontroller can handle it or I need a PC in between, which I refuse at this point. I want my machines to run stand alone.
While at first SVG may seem a bit counter intuitive, it has some real advantages. Especially coming from slic3r, it is an extremely easy file format to read (I got 90% of the reading functions done in one sunday). It also holds all layers in one file. The layers in an SVG are coordinate based, so I do not need any headers to say DPI and location. All I need to do is read a layer, note all the points where the line of the SVG crosses my nozzles, and starting from one side turn the nozzles on and off whenever I reach one of those points. It also scales to other printers without any modifications.
It is temporary though, until I have figured out how to do a better file format that also supports full color, is not too bulky and is preferably universal to any open inkjet printer. SVG is mostly an experiment that I really wanted to try, even though I know I will replace it in the future.
For silence I was going to install silent stepper drivers on all motors first. I probably also need rubber dampeners on all motors to isolate them from the case. It is indeed not much priority yet, as it still has to work first, but it is always good to have a few ideas ready.
I have been programming as fast as I could to get Oasis to print from raw SVG files. It took quite a few more functions than I had planned (hence the delay) but I am now somewhat capable of printing. All the framework for 3D is already in place, but not currently active. I will do that this or next week. First I want to optimize the output.
The output is not yet perfect. There is tiny lines where the firmware has missed and I suspect that there is some bigger, rarer issue hiding, but for now the output is acceptable.
(Edit. A teeny tiny tweak (replacing < with <=) already took care of 95% of the random lines seen in the video)
Fun fact. The small delays at the end of each sweep is where the printer is calculating the next line to print. This is mostly the reading from the SD card that is slow. This can be improved in the future, but for now it is fine.
Hey dragonator, is your "spreader roller" meant to move up and down or just at a fixed height and move where ever the y axis takes it while printing? I've seen machines with the rotation, what is the benefit of that exactly?
Also, how important is the piston seal for the build chambers? Do you just rely on small tolerance or something else?
The spreader does not move up or down, it rotates in the opposite direction it is moving at. This creates a smooth and compacted layer of powder. The pistons do generally move up and down depending on whether the spreader needs to interact with that piston. If the spreader does not interact with that piston, the piston moves down 0.5mm or so.
A seal of sorts is not mandatory, but the gap needs to be small enough that gypsum powder does not leak past it much. On older machines that used runny powders, I had enough leak past the pistons that corners were unusable. Depending on what I am building I either depend on tight tolerances or have some sort of flexible seal to keep the powder in.
I have put my color voxel slicer software up into the OpenSource at github. The slicer can generate output from meshes with texture maps for all kinds of 3D printers, including powder/binder machines. Since it is OpenSource, it's easy to add a module that outputs command sequences that the Oasis controller would understand. Let me know if this is useful and how it can be expanded.
This version is a very early demo that focusses on FDM machines, but the entire image generation code is already in the system and will be activated in the next release in a few days or so.
I have a software that sends to code to the printer. It is not really perfect, but it works. I am almost at the point of modifying the code. Right now it runs from bitmap formats (it takes all pixel formats), but it needs a 3D input of sorts. I was going to use slic3r SVG files for this, but right now I most certainly can be persuaded to use what you have. I will still probably need my own software to send it to the printer (it needs 2 serial connections to work) but it might be very usable to modify 3D files to 2D layer, with color in the future.
I have a few questions. Iota only makes the files right? It still needs to be sent to a machine. If this is true, I would need to think how best a file could be stored so I can send it later. The layers I get when I move the slider do not match the part completely. They are weirdly hollow and the outlines do not match. Is this some visual glitch or is the how the software interprets the files?
Extruded aluminium Oasis looks great! Very nice. Congratulations!
The Iota version you checked out is already a few days old and optimized for colored FDM printing which needs this "overhang" to read the correct colors. This can of course be switched off. Maybe you can send me the STL and I can see if anything else went wrong.
By now, I improved the STL importer and added export of PNG image slices with alpha channel. Also, the default resolution for the voxels is set to 1024x1024. In a specialized version, it would be set to the resolution of your printer. Lastly, yes, serial port communication will absolutely be part of Iota. I am much to lazy to launch yet another program to get my files printed.
Every printer type stores their own file(s). For powder/binder, that would be four component png's (RGBA). After generating the print files, a second task will be able to send the data through the network, through serial ports, or to an SD card or USB stick.
If any of this is helpful for you, and if you have somewhat sorted documentation on the data streams that your printer needs, I can add Oasis as a writer to my app. I would love to see Iota creating an inkjet output in 3D. This is what Iota was originally written for. It can generate GCode for FDM by now, but the color resolution is very different.
I will still take you up on that offer, but I do have a temporary solution that has turned out to work quite well so far. I made a log on the Hackaday page. I can read Slic3r SVG's, and I already have the software that controls both controllers. My solution is not perfect though, it is a bit fragile and limited, so a future better solution would be desirable.
The basics of my solution are this.
1. There is an Uno with a CNC shield running GRBL. This one controls all pistons and the gantry. In hindsight a RAMPS might have been more practical, but it is working. To this I send ordinary Gcode to move all axes. I also look at the status, because I will wait until the previous block of motions is done before I send the next, to prevent desynchronization.
2. Is my HP45 standalone controller. This takes a specialized code in blocks limited to 64 bytes to make it more efficient for the hardware buffer in the teensy. the looks something like this:
"SBR -BGa9t //////////////////////////////////////////////////"
-The first block is the command, always 3 letters, and in this case 'send buffer raw'
-The second bit is the small value. It is in Base64, and is negative in this case.
-The last bit is the long value, and is used to send over which nozzles are on. / is 63, or B00111111. 50x '/' is all 300 nozzles on.
-The line is ended by a carriage return or new line (I forgot which one)
-A lot of commands are either the command block, or the command block with a small value.
Base 64 was chosen so I can send and buffer in ascii, and have the highest density while having reserve for non-value characters like spaces and \cr. The entire list of command I still need to put somewhere.
Oasis is controlled by talking to both controller at the same time. I send all possible code to the HP45 driver, and then send the movement for a single sweep to the CNC shield. The controllers will do the rest. There is also some stuff required to handle sending code to the HP45 standalone while moving, but in python that gave issues. I now print from my 1000 line buffer in the HP45 driver.
Meanwhile in Enschede, oasis is progressing nicely. It now is capable of 3D printing. I will finish up on the documentation in the next few weeks. Then I will see what I will do next.