by noreply@blogger.com (Dan Heeks) at January 30, 2012 11:58 PM
A plate for holding 76 mm x 26 mm glass slides in the microscope. My first ever 'real' drawing with LibreCAD (that website has been down for two days now, so try also librecad on sourceforge).

Drawing in PDF: chamber_holder
Drawing in DXF: plate_v2.dxf
Yay! Lazzored some octocats at the #Metalab --@beanieboi
Some days ago two more pairs of helping hands joined PyCAM’s development: Paul Bonser and John Wiggins from the ATX Hackerspace (hopefully I did not forget someone).
Quickly a lot of progress happened:
Update: Here is "VX" with FreeSerifItalic. There is overlap in LibreOffice also.

For the most part truetypetracer produces valid and nice input data for testing openvoronoi. But sometimes I see wiggles, and now this:

It is frustrating to try to track down bugs in downstream algorithms that take this as input, and assume all line-segments are non-intersecting when in fact the are not!
I seem to have only 13 .ttf files in my /usr/share/fonts/truetype/freefont folder, but maybe there are more elsewhere. I should find a font that is properly designed without wiggles and without overlaps. The other approach is to write a pre-processor that looks at input data and either rejects or cleans it. Looking for all pair-wise intersections of N line-segments is a slow N^2 algorithm - at least for a naive implementation (without bounding-boxes or binning or other tricks).
Unlike the wiggles, this overlap doesn't happen in Inkscape:

Here is G-code generated with ttt-4.0 and drawn in LinuxCNC:

Now that the laser is firing all the way through the beam path and the path can be controlled by the computer, we're down to the detail:
Controlling the Laser
I don't have too much to say here because I got incredibly lucky and someone else did all the heavy lifting for me.
Users on Buildlog.net have done lots of work making it possible to control the laser from EMC2. User BenJackson has published his configuration files and adapting them to my machine was a piece of cake.
His configuration file includes a custom HAL component that does PPI (pulse per inch) control. With this configuration, I have three "knobs" I can turn to adjust how the laser cuts or engraves material.
By playing around with these three, I've found I can go from drawing a light brown line on a piece of paper all the way up to burning clear through 5mm wood or 1/4" acrylic! Very Nice! I've got plenty of learning still to do but it's looking good.
Cooling
The basic buildlog setup is a 5 gallon bucket of water, and an aquarium pump. I need to tidy up my setup but it's working for now. The only part I'm missing is a flow switch. The control card has an input for a switch that is tied into the safety interlock. It should prevent the laser from firing if the water isn't flowing. I don't have a switch yet so I've hotwired around it. Not good.
Shroud
The glass tube hanging off the back makes me nervous. I'm not sure if there's any dangerous radiation emitted from the sides of the tube, but I'm not taking any chances. Besides, it's just a matter of time before I drop the broom handle or something else on to the tube and bust it. I had a local sheet metal shop bend and weld up a shroud that fits over the tube and screws to my mounting rails. After painting it, I think it came out nice.
Exhaust
When the laser is burning anything, and especially plastics, it puts off a lot of smoke and foul smelling crap. I have a big dust collector for the CNC machine. I'll add a drop near where the laser will end up so I don't have a dryer hose trailing across the floor.
And the results? This is 1/4" plywood cut through.
lazzzored a longcat keychain for @jaymecochrane at the #Metalab --@beanieboi
A first try at v-carving, with toolpaths produced by the ttt2medial python script.
I tried cranking up (10-fold) the number of line-segments that are used when approximating conics and cubics with lines. The results are mostly OK, but sometimes "wiggles" or "S-curves" appear, which cause problems for the medial-axis filter. This "P" is an example:
The medial axis on the right does not look correct. If we zoom in it's clear that there's an "S-curve" in the input geometry, which causes a LINELINE edge (drawn in darker blue), which the medial-axis filter doesn't think should be removed:
For the letters "EMC" it looks mostly OK, but there's a similar wiggle in "E"
Increasing the number of line-segments further causes even stranger things. Here's a zoom-in at the top of "P" that shows both the wiggle that was visible before, but also a strange inward bulge:
Hopefully this is a bug in how conics/cubics are converted to line-segments in ttt, and not an issue with how FreeType fonts are represented.
by noreply@blogger.com (Dan Heeks) at January 20, 2012 10:34 PM
by noreply@blogger.com (Dan Heeks) at January 19, 2012 10:34 AM
by noreply@blogger.com (Dan Heeks) at January 19, 2012 08:15 AM
sudo /usr/sbin/hciconfig hci0 class 0x5a020c
After this, I was able to transfer using the facilities built into gnome; I got a bunch of ".vcf" files in ~/Downloads.
Apparently the Remarq won't transfer to a device that is "Unknown"; this sets the computer to a "phone" bluetooth device.
I'm not sure whether this setting will "stick" or be required before each transfer, after a reboot, or what…
by noreply@blogger.com (Dan Heeks) at January 17, 2012 06:59 PM
I hacked together a few python-scripts that can be run as "filters" in EMC2. They are opened/run from AXIS and produce G-code into EMC2.
The first one is ttt2ngc which simply demonstrates my C++ port of Chris Radek's truetype-tracer. The original code is a rather monolithic C-program while my C++ port is divided into smaller files and offers python-bindings and more options (for example arc, cubic, conic output can be turned on/off independently).
The seconds script is ttt2offset which takes ttt-geometry, builds a VD, and produces offsets. By reversing the list of points from ttt either inwards or outwards offsets can be produced. Currently the toolpaths are machined in the order they are produced, i.e. in order of increasing offset value. An improvement would be to order the loops so that for e.g. pocketing the innermost loop is machined first, and rapid-traverses are minimized.
The third script is ttt2medial. Here the VD is filtered down to an (approximate) medial-axis, and the edges of the medial axis are chained together into a toolpath. The chaining-algorithm could probably be improved much, again to minimize rapid-traverses.
If this is run with a V-shaped cutter with a 90-degree angle we can push the cutter into the material by an amount equal to the clearance-disk radius of the edge. This is a "V-carving" toolpath which should produce a cut-out very similar to the outline of the font. For added effect choose a material with contrasting surface and interior colors.
It would be interesting to know if this v-carving g-code is anywhere near to correct. If someone has a cutting-simulator, or is adventurous enough to run this on an actual machine, I'd be very interested in the results! (here is the g-code: emc2_vcarve.ngc)
Here is a metric version. The max depth is around -3mm, so a 10mm diameter 90-degree V-cutter should be OK. The text should be roughly 100mm long: emc2_vcarve_mm_ver2.ngc
Disclaimer: This is experimental code. Warnings, Errors, and Segfaults are common.
I've put together two graph filters that can be applied to the VD.
The first one detects the interior or exterior of a polygon. When the VD is constructed the polygon boundary must be input in CW order, and any islands inside the polygon in CCW order (or vice versa). This allows running other downstream algorithms only on the parts of the VD that pass the filter. Like these exterior and interior offsets:
The other filter looks at the interior VD and tries to produce an approximate medial axis. We can start with the complete interior VD, such as this "J":
By definition the medial axis consists of "the set of all points having more than one closest point on the object's boundary". The separator edges shown in purple above can clearly be eliminated, since their adjacent/defining sites are an open line-segment and the segment's endpoint. Removing separators gives us this:
Now we can either finish here, or try to filter out some more edges to make it look better. Since we approximated smooth curves with line-segments we should try to detect which parts of the boundary are really distinct curves, and which are merely many consecutive line-segments approximating a single smooth curve. I've compared the dot-product (angle) between two consecutive segments, and applied an arbitrary threshold:
For the whole alphabet it looks like this.
The choice of threshold value for the angle-filtering is arbitrary. In many cases such as "x" and "m" it results in small or large left-over branches. This could probably be avoided by (1) tuning the angle-threshold, (2) approximating smooth curves with a larger number of line-segments, (3) eliminating branches below a certain length, or (4) choosing a font that's made for v-carving (are there any?).
Although it's probably not right to call it a "medial axis" , the same filter applied to the exterior VD also looks interesting. It divides the plane into organic looking shapes around each letter. It could probably be used for a lot of shape analysis. For example in a smart pocketing routine to find large areas that can be cleared with a large cutter, before a smaller cutter is required for the details. Note that in addition to the geometric shape of all the blue-ish edges the diagram also holds distance-information at each point of an edge. The distance stored is a clearance-disk radius, i.e. we can draw a circle at any point of an edge with this radius, and no input geometry (in yellow) will intersect the circle.
PyCAM is – as the name implies – based on the scripting language Python. Python is a very efficient tool from the developer’s point of view: even complicated features can be implemented quickly and cleanly in a structured way. The downside of this ease of development can be a source of annoyance for users: number crunching applications are not as ressource efficient as their compiled counterparts. But today PyCAM gained a useful feature to fight its own ressource hunger.
Once we have a VD it is almost trivial to calculate 2D offsets. While the VD for n line-segments takes O(n*log(n)) time to calculate, the offset-generation is a simple "march" that takes O(n) time. In this "A" example it takes 24 milliseconds to calculate the VD and less than 1 millisecond to produce all the shown offsets. Input geometry in yellow, VD in blue. Offset lines in light-green and offset arcs in slightly darker green.
Here is a larger example where VD takes 1.3 seconds, and all offsets shown take 99 milliseconds in total to produce. It would be interesting to benchmark this against libarea or other open-source 2D offset solutions. (here all line/arc offsets in one green color, for simplicity)
Here is a third picture with offsets for a single offset-distance:
Since my tube mount is completely custom, I have to manually align the tube with the first mirror. The C02 laser is invisible (and dangerous) so aligning it correctly can be a trick. I saw a solution on buildlog that I thought was a very clever hack. The guy used a reprap to print out two disks the same diameter as the tube. One disk has a very small center hole, the other has a hole that exactly fits a laser pointer. He mounts them in the brackets and adjusts the laser to shoot through the small hole, into the first mirror. Once the alignment is correct, he loosens just one screw to remove the disks and insert the tube. At that point, the alignment should be very close.
I have a reprap but I had some time to kill before Christmas while I was waiting for my power supply to arrive and needed some lathe practice. I turned these two 'cookies' and bored one to fit a cheap laser pointer I have.
When I started trying to align the tube, I found I couldn't get even close. Eventually I realized that in the original configuration, this plate screwed directly to the end of the RF tube. That would ensure that the first mirror was perpendicular to the axis of the laser. Without those screws, this whole periscope, bends out of alignment. You can actually see it tweaked back a bit in the picture below when I was test fitting the tube.
I'm sure this is a completely ugly hack, but I added a piece of aluminum angle with holes drilled and tapped to match two of the holes on the periscope bracket. I attached it to my mounting rails. By turning the screws, I can pull the periscope back toward square and by turning one or the other, I can slightly twist it.
After playing around, I eventually got the cookie, laser pointer, bracket arrangement to fire the laser all the way through the beam path.
Next I carefully mounted the tube and connected everything up. With safety glasses on, I carefully hit the test button while holding a piece of paper over the mirror path. Once it was hitting the center of the first mirror, I adjusted the mirror angle until it went all the way down the beam path. After aligning with the cookies, it only took about 45 minutes to have it hitting very accurately all the way.
I got a few GPX-tracks from last Friday's rogaining event and drew them with OpenLayers.
Over here: http://www.anderswallin.net/loppiaisrogaining2012/
OpenLayers has a nice set of examples online. Browsing and copy/pasting from examples is much better than trying to read & understand formal documentation.
There was an issue with handling collinear line-segments, which is hopefully now fixed. OpenVoronoi seems to deal OK with most characters from ttt now.
I am still getting some Warnings about numerical instability from LLLSolver, possibly related to these high-degree vertices which don't look quite right (this is a zoom-in inside the circular dot of "j" in the picture above):

I should write a class for extracting offsets next. Then perhaps medial axis (if anyone is interested in v-carving toolpaths).
Took part in an 8h rogaining event yesterday. Very wet in the forest with a lot of fallen trees due to the storms over the last few weeks.
We planned a ca. 20km long route (straight lines between controls), assuming we would walk up to 50% more, i.e. around 30km, which would be OK for 8 hours.
This event had a 1:25000 map which was much easier to read compared to the 1:40000 one last fall. No problems in the beginning, we fould 23 -> 21 -> 31 -> 41 quite easily. The first digit of the control-numnber indicates how many points you get for the control. The next control 51 was worth five points, and they are usually harder to find. Not this time, since it was at the very top of a hill, and people before us had already left tracks in the snow.
Then comes the big mistake of the day. We follow another faster group west down the hill from 51 towards 32. For some inexplicable reason we then completely mis-place ourselves on the map and although we are practically within reach of 32 we make a slow detour south before we realize where we are. Update: I have since learned that our confusion most probably was caused by a brand new road in this area, which was not marked on the map!
Probably annoyed by the first mistake, the second mistake of the day comes on the very next control: between 32 and 37 we take the wrong path north-east and decide to head back when we realize that.
So far we had stuck to the plan, but looking at the watch at 37 we decided to cut 39 from the route. Walk north along the road to 26, and then more walking along a big and then a small road to 57. At 57 we had some discussion about whether to walk back along the road, or try to find the electric lines north of 57 and let them guide us to the road. We had used 4 hours, or half of the total time here. We chose the latter route, and a straight northward pointing bit of our path after 57 indicates where we walked under the electric lines. Close to 53 the plan was to follow a path to the right of the hill and then the ditch to the control. Things didn't go to plan and we ended up to the left of the hill, but found the control with the help of tracks in the snow and voices/lights of others. A walk along the lake-shore to 55. And further north to a road.
So far we had roughly followed the plan. But now we had less than 3 hours left, and it was already dark making orienteering in the woods without clear paths or roads much harder. We decided to forget the plan and walk mostly along roads towards the finish, taking controls close to roads/paths along the way. A long bit of walking first south and then northeast to 49. Another long bit of walking all the way to 24. Here the image shows double GPS-paths because I switched from the 405cx watch to the Edge800 I use on the bike. We still had 45-50 minutes left at 24, so with a close eye on the clock we find 33 quite easily and 22 with a little more effort. We finished with about 12 minutes to spare.
About 90 teams (either solo, or in teams of 2-4 persons) took part.
Update, here's our route again (in red), compared to another slightly faster team's route in blue:









by noreply@blogger.com (nophead) at January 07, 2012 05:57 PM
Update: Now all the capital letters work!

I wanted to test my VD algorithm on font-outlines. So I ported Chris Radek's truetype-tracer to c++ and added some python bindings. Here: https://github.com/aewallin/truetype-tracer
Because my VD code cannot handle circular arcs yet, I took some old code from TTT 3.0 and made converting conics and cubics, the native output of FreeType, as well as arcs into line-segments optional.
Predictably, OpenVoronoi crashes in many cases, but here is an "L" that works:

Anne Lander visited Metalab and lazzzor cut her Cubist Fidel Castro! (Sketch, T-Shirt)
[Reposted from metalab]
Der Sonntag der Kosmonauten - Immer Montags im Stattcafe @ Stattbad Wedding - 18:00
Ab nächster Woche gibt es im Stattbad Wedding immer Montags den 'Sonntag der Kosmonauten' - Diverse Funktionen sind mit der Veranstaltung verbungen:
I've been hacking away at openvoronoi, adding support for polylines and polygons.
The code I had in November works with individual non-intersecting line segments, like this:

Note how each vertex in the figure above is of degree three, i.e. there are three edges incident on each vertex. There's something about the number three, or triangles, or both, that makes planar graphs of degree three particularly nice to work with.
Here's the same figure with some notes describing the elements. The line-sites are drawn in yellow, and are associated with their left R(L+) and right R(L-) regions. The purple lines are called separators, and they define the region associated with the start- or end-point of a line-site. The three possible edge-types are also shown: LineEdge between two point-sites, LineEdge between two line-sites, and a Parabolic (PointLine) edge between a point-site and a line-site.

Now, things get more complicated when we want to 'glue' two line-segments end-to-end in a polyline, or glue three or more line-segments together to form a polygon. Vertices are not necessarily of degree three any more. In fact the vertex degree is essentially unbounded, as you can start/end arbitrarily many line-segments at the same vertex. The solution I am using is to introduce what I call a null-face with zero-length null-edges around each point-site to which more than one line-segment connects. The mental picture is much like that of a key-chain, or mountaineering carabiners that are hooked-in to a loop. When we want to use the a vertex as a start/end-point for a segment we 'hook-in' to the null-face:

This introduces a number of new rules and associated code for how vertices should be created, removed, and moved around a null-face, but it seems to work somehow now:

Note how these null-faces and the circular null-edges around each end-point result in degree three vertices, which are much nicer to deal with in the algorithm. For example, the null-face around vertex "0" is 40->85->86->41->39. Without the null-face construction this vertex would be of degree five. Here is an annotated version of the same picture:

This image shows how the diagram divides the plane into regions associated with endpoints such as R(0) and with the right/left side of a line-segment such as R(0-29) and R(29-0). The null-edges that form null-faces around each end-point are drawn in white.
Of course, these null-edges are only a topological construction. Geometrically we can position each vertex on a null-face at the location of the encircled point-site. This effectively contracts away the zero-area null-faces, and the result is the diagram we want:

The code now runs for a few select test-cases. To be continued...
Update: The code now seems to work also for random polygons with a large number of vertices. Here is one with 400 vertices:

and 3200-vertices:

Ok, nachdem sich die Fragen in letzter Zeit weiter gehäuft haben. Hier der Verweis auf die neue Situation der Schrauber-Pauschale in der Raumfahrtagentur. Die Schrauber-Pauschale ist traditionell der Beitrag den jeder Aktive in der Raumfahrtagentur monatlich bezahlt. Für 2012 wünschen wir uns noch weitere Mitstreiter, die ein Interesse an unserer Infrastruktur haben und eigene Projekte realisieren wollen. Es ist letztes Jahr einiges dazu gekommen und wir haben auch noch ein paar kleine Plätze für neue Maschinen und Einrichtungen. Schaut euch die Agentur einmal an!
---
Verschafft euch einen Überblick.
Ihr findet gut was wir machen? Habt viel in der Agentur entdeckt und Spaß an der Sache? – werdet ein Freund der Agentur!
Regelmäßig bei uns an Board? Werde ein Kosmonaut!
Ohne einen harten Kern ist es nicht möglich eine solch große Werkstatt mit all ihren Maschinen, Einrichtungen und Möglichkeiten zu finanzieren. Ein kleiner Kern, der teils auch kommerzielle Projekte aus der Agentur heraus startet legt noch einen drauf, erst das macht die komplette Liste an Features die wir hier genießen möglich.
¹ Gilt für den Maschinenbetrieb von camgeeks und die Nutzung unserer CNC-Fräse. Rabatte werden nicht aufsummiert.
² Für externe die nicht schon seit langen Jahren zu den Freunden der Agentur gehören gibt es erst mal mind. 6 Monate den Modus Nr. 3. Eine gewisse Vertrauensbasis muss sich angesichts der ganzen Infrastruktur erst aufbauen. Wir können weitestgehend unbekannten nicht direkt einen Schlüssel in die Hand geben. Bitte habt dafür Verständnis. – Ein Verzicht auf den Schlüssel zum, wir nennen es mal ‘Selbstschutz’, ist grundsätzlich möglich.
Not much to say about this. It's scary cool! The tube glows pinkish purple and the wood block ignites instantly. The only thing I've seen ignite faster was the imagination of my 12 and 10 year old sons. Something about that glow inspires a guy to try stupid stuff. Fortunately eye-protection was the order of the day and no injuries were reported.
by noreply@blogger.com (nophead) at December 30, 2011 06:58 PM
First Ultimaker Print
Uniqx brought his new Ultimaker to the lab :) and yesterday he printed a replacement part for his faucet.
Unfortunately there was some problem with the usb connection and it stopped 5 minutes before it would have been finished...but it should be already functional :)
New Ultimaker at Metalab!
Uniqx brought his Ultimater to the lab :)
Yesterday we did some skeinforge parameter tuning and we already got some decent parameters but it should be possible to move and extrude even faster ;)
[Reposted from wizard23]
Acrylic parts for a Motorized Skirt
A student from "die Angewandte - digitale kunst" laser cut some of the parts he needs for his current project - a motorized skirt...sounds promising!
[Reposted from wizard23]
Lazzzor cut fabric
Tamara cut the patterns for her sewing project with the lazzzor :)
Once you get it to lay flat fabric is a very good material for laser cutting.
[Reposted from wizard23]
by noreply@blogger.com (nophead) at December 29, 2011 10:26 PM
The 28C3 "behind enemy lines" is up and running! In parallel we'll have a party at raumfahrtagentur 29th the 3rd day of the congress. We want to invite all visitors from all over the world who are related to some kind of hackerspace project!
Just show up we have some music, a bar, and many stories to tell Public/VisitRaumfahrtagentur - The bar is open starting from 8pm.
Lineup
by noreply@blogger.com (Neil Underwood) at December 27, 2011 06:04 PM
Hi all, it has been a long time, but I have something to show.by noreply@blogger.com (Bart Anderson) at December 26, 2011 09:41 PM
Yes, Berlin's hacker-space, the Raumfahrtagentur - not only focused on hardware-hacking, is open during 28C3. We decided not to move every maschine to bcc, so you are invited to join us. Between our laser-cutter, RepRap and audio-studio, a Volxküche (public-kitchen), a bar (including Chunk and MateMartini) and a projector for streaming is waiting for everyone interested.
We try to achieve 24/7 availability - but don't hesistate to contact us first.
For details check the wiki events/28c3PeaceMission
by noreply@blogger.com (nophead) at December 25, 2011 11:27 PM
Kay made this cool Metalab cookie cutter :) via @wizard23
Everyone loves Batman
It's always fun to show the lazzzor to people that haven't seen a laser cutter before :)
Suddenly everybody wanted a Batman logo...luckily it only takes a minute to lazzzor one ;) --@wizard23
Attached here is the .config file I used to build Backfire (10.03.1, r29599) for this device.
Files attached to this page:
| dot.config | 93.8kB |