Fighting with computers

Computers are not always friendly.

Friday, August 15, 2014

Reading binary STL files in Java

I liked the source code from MaskedRetriever user on github and I assumed it would work ok. It seems it was an attempt to create a self-contained tool for 3D printing but somehow it was left at an early stage. But I liked the fact that source code was documented.

My needs were to read STL files and to slice them. As usual you need to get familiar with the different classes involved but it took me not much to get it going. I stripped most of the classes as I was not interested on 3D printing nor on having a GUI for such a tool. However, as soon as I draw the output of the slice process I noticed something was wrong.

While the proper slice looked smooth like the image below:

What I was obtaining was a bit of a mess, though the general ideal was correct. As it was my first attempt I was not sure where the error might be.
After a few tests I realized that the same code would work ok if STL file was ASCII-based but it will fail as above if a binary STL was used instead. 

I had a look at the code and I could see reading a binary STL file involved obtaining float values out of 32-bit IEEE 754 encoded values on the file. It seemed it was there when error was made in the conversion.

Googling around I realized there was a library function in Float class called intBitsToFloat that will turn the 32 bit number into the proper float value. I only needed to get that 32 bit number out of the four bytes read from the file, easy peasy ... or not?

Well, if that were C, and you have b[0..3] unsigned chars, the expression could be something like 
 b[3]<<24 | b[2]<<16 | b[1]<<8 | b[0]  

However Java language considers byte data-type as a signed 8-bit field (-128 to 127). And there is a nasty effect with the sign extension that may make you waste a fair amount of time. In summary, the C version won't work if negative values are involved, and they are most of the time (half of the time I would say). So one way of obtaining the proper 32 bit number in Java would be a bit longer : 

 (b[3]<<24)&0xff000000 | (b[2]<<16)&0xff0000 | (b[1]<<8)&0xff00 | b[0]&0xff  

Tuesday, August 05, 2014

More on delta 3D printers

It's been quite busy around here lately. Still, I have managed to build a couple of delta 3D printers with heated beds and develop a couple of ideas that seemed worth trying.

One of these ideas is the use of a heated bed. While I can see that some people are moving away from ABS to use just PLA plastic, I do not see how I can use a PLA-only solutions for environments where temperature can be high, like inside of a car or near a hotend or heated bed.

Two different types of extrusions and carriages were tested: wheeled carriages over the extrusion resulted in a quieter and more accurate system than rails. But the IGUS guides used had quite play by design. After watching the videos of them working I am not sure they are a good choice for this particular use, though printed parts do not look bad after all.

While Johan pioneered the use of force sensing resistors on the bed for probe-less bed detection, I was not pleased with the additional cost these FSR sensors would add, so I turned to the same idea Brook did with the metal Printrbot Simple: the use of inductive proximity detectors (as I am using aluminum heated beds). As I wanted to add the sensor to the effector and to use magnetic couplings instead of Traxxas ball joints, I designed a few new parts.

I am very happy with these plastic parts for creating a Kossel Mini using 2020 extrusions. And the guys from Mecaduino provided me a set of parts for making a Kossel Mini using their metal parts (however I did print some plastic parts to use magnetic coupling and inductive proximity probe with it too.

With the magnetic couplings, with I liked more than ball joints, as they have zero slop, if you set the acceleration too high (in my case higher than 1500mm/s^2) the rods will fall apart on any fast movement, that will never happen with a ball joint. I am using 10mm steel balls and 6mm-diameter 8mm-long N35 magnets. I guess stronger magnets will allow you higher effective accelerations.

The second innovation I have been testing is the auto-calibration firmware I mentioned in a previous post by Rich Catell. While the first time I used in a 3DR printer with a mechanical switch the firmware converged quickly, these two other printers gave me hell and did not converge to a valid calibration all the time. Maybe part of the problem was due to not so accurate build of these deltas but another reason could be associated with the way measurements are performed. Once I switched to the median filter code by Brad Hopper the results of auto-calibration improved notably on both printers. 

Now it seems I am getting good prints from both printers and start to feel a bit more confident about this type of printer, so I guess I am venturing in a new type quite soon: Ingentis/Eustathios are next.