I finally got it! An self-contained app for OSX of our host software!
Just uncompress it, and double click!
Windows EXE file coming next!! 😉
« Posts by hradec
Realtime Slicer proof of concept using GPU
It’s being a while since my last update on our software, but I got some exciting progress to report at least…
Images are better than any description, so check it out for yourself:
httpvh://www.youtube.com/watch?v=ydT8HXTou2U
This video shows my first successful test on slicing a model in realtime using GPU shaders!
I’m cleaning up my code right now and you should be find the first public version of the CS1 host software on our github by today afternoon!
https://github.com/hradec/chemshapes
or you can download a “zipball” of it directly by clicking here
I invite everyone to download it and give it a try! I really wan’t to known how the GPU code will behave in different computers with different setups, to see how feasible it will be to rely on GPU for our base software. From what I known, GPU shaders is something very common on hardware these days, and it has being for a few years now, so I’m hopping you guys computer setup already have a reasonable good video board that will support GPU shaders. Maybe not as fast as a computer game would need, but fast enough to slice and display slices in realtime. But to confirm that, I need you guys to test the software asap!
To download the software, theres a big “DOWNLOAD” button on the github page. Download it as “.zip”. After uncompress it, go to “host” software, and if running Windows, just double click on:
“Click here to run Chemshapes Host Software.cmd”
and it should launch it.
If you find any issues, bugs or suggestions, please report it on this page: https://github.com/hradec/chemshapes/issues
The host software can read booth .obj or .stl files… please try it out and let me known!
The viewport camera has some issues, like not automatically adjusting the frustum and clipping planes when loading new geo, so keep in mind that you may have to zoom in/out to see a model you just load, in case it won’t show up automatically!
Apart from the slicing demo, the communication with the electronics also works, and it connects successfully with the reprap Sprinter firmware, and should connect fine with any other reprap/gcode compatible firmware over serial port.
If your electronics is arduino based, I strongly recommend you to install our fork of the Sprinter firmware, found at:
https://github.com/hradec/Sprinter
have fun!!
Jon Watson powerpoint macro/mach3 solution video!
Pretty cool!! Jon got his software solution working using a powerpoint macro and mach3 CNC software!!
check it out:
Experience of a 3D Stereo Lithography System Operator
On a comment on “A little bit about UV Curable resins…” post, Traumflug shared some really amazing information that I thought deserved to be blogged on its own, for future easy reference when people start trying some UV curing of they own:
“Here I can talk a bit about my experience as an operator of a 3D Systems stereolithography system. Early SLA resins were all clear, and they produced quite even layer thicknesses. So, coloring the resin isn’t essential at all.
When you expose UV-curable resin to light, it starts hardening at the top (where “top” = “closer to the light source”) and the more light you bring in, the thicker this layer gets. However, the exposure has to be above some threshold to work at all. Not enough light and no hardening takes place.
To find out the relation between exposure and layer thickness, simply expose just one layer, then take this single layer out, postprocess (wash) it as normal, and you can measure the thickness. The minimum layer thickness is very low, like 0.01 mm. Much lower than you can reasonably handle.
Minimum layer thickness also isn’t essential to build accuracy or layer thickness. It’s no problem to advance in 0.1 mm steps, but to expose for 0.2 or 0.3 mm. This way, parts of the resin get exposed twice or three times, wich doesn’t hurt at all.
After all, the SLA slicing algorithm makes the bottom layer (here the top layer) intentionally extra thick, to achieve better build accuracy. More accuracy, because the first layer is more mechanically stable (think of overhangs). The drawback is, this introduces some complications in the slicing algorithm to compensate for this extra thickness. In other words, you have more fun creating a good slicing software.”
Thanks again for sharing this, Traumflug!!!
A little bit about UV Curable resins…
I was looking for ways to mix UV blockers into epoxy resin (to mix an UV blocker into the solarez zerovoc – the cheapest UV resin I found so far), and I found this: http://www.dymax.com/pdf/pds/3069.pdf
Nothing new here… an adhesive from Dymax that cures fast on UV and blue light… but what catch my eye was the second page… the 2 graphs showing the depth of cure relation with time of exposition and light intensity… And then I realize:
If this product has a depth/exposion time relation, it means that it already partially blocks the light from penetrating deep into the material, which means that we MAY be able to control the cure by just adjusting the exposure time per layer… If we do the math right, we may be able to cure JUST the amount we want from the bottom, by doing really quick expositions, specially if the material is NOT SO FAST to cure… actually, the slower it is, the more difficult it would be to cure a ticker layer… which is EXACTLY what we want! 🙂
We could also experiment with adding SOLVENT to the mix instead of a blocker, just to make it HARDER to form the reaction that cures the material, increasing the chances of curing just a tiny layer… just some more to think about it and experiment once we get a prototype working!
Last, but not least, in case someone runs into figuring what viscosity “cP” is, this is a nice useful table to figure how viscous a material is:
| Some typical viscosities (cP at 20°C) | |||
| air | 0.02 | motor oil SAE 20 | 125 |
| acetone | 0.3 | motor oil SAE 50 | 540 |
| methanol | 0.6 | castor oil | 986 |
| water | 1.0 | glycerin | 1490 |
| ethanol | 1.2 | pancake syrup | 2500 |
| mercury | 1.5 | maple syrup | 3200 |
| linseed oil (raw) | 28 | treacle | 20,000 |
| corn oil | 72 | peanut butter | 250,000 |
| olive oil | 84 | window putty | 100,000,000 |
A Really Nice Resource about UV cure
http://www.uvabcs.com/uvlight.php
Lots of information there to learn a bit more about UV curing materials, techniques and more…Also, find this really nice supplier of UV adhesives in Canada (yeah… I’m in Canada), which is really hard to find: http://www.ellsworthadhesives.ca/
They have a really nice search system, were you can refine the list by selecting different aspects of the material, like viscosity, cure time, etc. Unfortunately, theres no prices whatsoever… everything has to be quoted! =(
Our forum is up and running…
just click on “ChemShapes R&D forum” on the “links” section right here on the left to join us…
Config Save/Load upon exit/start of software…
Just finished the config file saving and loading, so now when exiting the host software will save the current state of the software.
The next time you run it, it will restore everything the way it was!
Latest version of the host software, running on windows and moving the axis stepper in “live” mode.
I made this video to show everyone the development evolution. The host software now detects the available serial port devices, list it on the combo box. Select the right one and hit “connect”. It connects successfully to the Sprinter firmware running on the arduino.
httpvh://www.youtube.com/watch?v=5yQbOFnh4co
From there, the host software just need to send GCode over the serial device and that’s it! Now I’ll work on the homing procedure, the refill procedure and next, I’ll “glue” skeinforge into it to slice an object. The print procedure is also done, but in a separate script. I’ll try to “copy and paste” in the host software so I can record a small preview of a “print” simulation!
host software is getting along…
Our software is all being done in python script language.
We are using skeinforge as the main slicer engine and standard REPRAP GCode to control the electronics. We will be adding some custom GCode commands to control some aspects of the projector, like turning it on/off and switch input lines.
The electronics are also largely based on the REPRAP RAMPS 1.2 board (essentially using an Arduino Mega and a Pololu driver), and uses a standard RAMPS firmware.
We are currently using the Sprinter ramps firmware (old carukilp firmware), which has being re-written from the ground up especially to take advantage of the pololu driver capability. This new ramps firmware also allows much faster axis movement with much less noise than any other reprap firmware available.
The UI is all done in QT, a well known and very reliable multi-platform UI library developed by Nokia.
OpenGL is also used for the realtime preview of the model to be printed, and also during the print itself, since OpenGL is extremely efficient to deal with double-buffered page flipping and Vertical Synchronization, minimizing possible glitches in the curing process during slice switch.
One of the main goals of the software is to be multi-platform from day one, hence the choices of using OpenGL, Python and QT. It’s being constantly tested on OSX, Windows and Linux, as it’s being developed and, so far, no big issues!
Recent Comments