Although, without our firmware it will probably freeze after the first slice, since a normal ramps firmware have no concept of feedback when an axis movement is finished.
Right now our firmware only works with our shield, since the pinage is different. I’ll see if I can add a ramps version, but unfortunately, our firmware will be imcompatible with ramps very soon since we have a dc motor controller and opto-switch for a simple encoder that controls the vat-release tilt.
I suppose we could even keep a simpler RAMPS version of the firmware, if necessary, but without vat-release. Will see!
This video was done by Henrique Muringa, another Brazilian who is starting to help on the Host software development. He recorded this test video on his Windows 7, were he tests the host comunication layer by connecting to his Prusa printer.
He also demonstrates the slicing speed on his AMD HD 3200 Video Board, which has a GPU unit compatible with OpenGL 2.2. Also, the HD 3200 is a fairly low-end GPU of the AMD line, which demonstrate that the host software doesn’t require too much GPU power to achieve really good results.
Unfortunately, the recorder software couldn’t capture as fast as the host software can slice it!
Windows and OSX executables are not ready yet, but if you’re running Linux, just download the latest TRUNK from the svn depot at google code and type “make” in a shell!
Load “happy.stl” and simulate a slice!
The Host software requires a video board with a GPU that supports OpenGL version 2.0 at least, at the moment. Make sure to update the video drivers in case the host software fails to run on the first try.
Make sure you have these packages installed in your linux distro:
PIL (if you want to save slices as PNG)
Keep in mind that when saving PNG images it won’t be as fast as just simulating due to the I/O time it takes to save the image buffer to disk!
In case you run into trouble, please report any issues through google code issue tracker, and please make sure you do the following to speed up the support:
always attaching the log_<computer name>.html file created by the host software. I’ll find that file in the same folder after trying to run it.
specify your system specs, including:
OS name and version
video board name and brand
video driver version
We’ll do our best to give as much support is possible. Keep in mind that, as this is an open source software, we only have our spare time to work on it, as well as to give support, so please be patient!
So, just a quick note on the host software side: We decided to move over to Google code as our main depot instead of github!!
The reason being I (Hradec) personally CAN’T WORK WITH GIT ANYMORE!! I think I’m getting to old or something, but I simple can get my head around git, to the point I have lost some code a few months back due to wrong/bad submissions.
Since then, I have being working with all the host software code in my personal Subversion depot, and now that we’re finding some people willing to help, I’m moving it back to the open, but this time at google code.
It’s now on good and old subversion, which is what I known best…
The host is maturing, and I have sorted a lot of issues in it and have finally centralized the rendering code into one place, so booth viewport preview and print/slice is calculated from the same place.
Also, all OpenGL rendering is deferred (yep, deferred rendering, like most games these days), which means I can finally make use of lots of image processing power give to us from the mighty GPUs theses days to get our realtime slicer up and running.
Stays tuned for the Windows/OSX releases which should come up really soon… by the way… WITH SLICING OUTPUT TO FILES, to start with!!! So you guys can start using it for testing with your own slideshow/firmware setup (including with Jon Watson Macro for mach3 to control powerpoint!!)
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:
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:
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.
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!