Monday, July 25, 2005

 

It is an ex-glue gun. It has ceased to be.

We're picking up subtle hints that our "$2 Shop" glue guns may not be suitable for prolonged use. This, our second victim, is an ex-gluegun. It has ceased to be:



It is not pining for the fjords, and it wouldn't go voom if you put ... hang on, it did go >FOOOOM!< at 220V. No lab personel were injured in the explosion, though nearby an unrelated syringe was shot dead by armed police.

Vik :v)

Comments:
I figure you are using a glue gun to get the feed mechanism for the stick, do I understand that right?

Why not use the heating element off of a soildering iron instead and just heat the tip of the glue gun rather than trusting the wiring on a cheap glue gun. You might be able to reuse the feed mechanism off of the broken gun.
 
Heh, bummer.

On an unrelated note, I remember hearing you were going to use Blender 3D for your 3D blueprints? Could you perhaps use a semi-standard file format instead - .obj? That file format is included, by default, in every modeler out there. This would allow everyone to be able to construct objects without having to learn new software (which means dealing with different and often times bad tools, compared to what we were used to).

Just wondering =)
 
I'm not using the feed mechanism that came with the gluue gun - I've built a motorised one out of Meccano and removed the old mechanism entirely to stop it getting in the way.

Soldering irons proved difficult to control - they want to reach a higher temperature. I may wind a 12V heater from nicrome, but there may not be much poiint with Adrian's new extruder being only weeks away.

As for Blender 3D, no I'm not using it. I'm using ArtOfIllusion together with some handy AoI scripts for joining shapes, editing polymeshes, and designing gearwheels.
 
replying to the unrelated note:
the blender I have installed (v2.36) hast support for exporting for "VideoScape with Vertex Colors (.obj)" and "Wavefront (.obj)". Is anyone of those usable?

Mattes
 
For myself, I find both formats rather ugly, and would much rather have a higher-level text part description language (preferably with macros...) and a "compiler" for that language that converts it into a set of codes for the machine.
.stl files look to be a rather messy hack to me, and .obj files seem to be nearly on par with them for this purpose - possibly good for raytracing/rendering, but not so nice for engineering.
But then, I use vim for everything from poking at the kernel through doing print layout to writing povray scenes, so I'm hardly the average.
But I can't see any issue with running the machine from multiple sorts of programs, so if I do end up scratching that particular itch I don't see any issue with interoperation.
 
We'll need something more dynamic for later versions, that's for sure. People will want to manufacture from different stock parts according to what is locally available, or whichever suits their production needs. Making a system that allows this degree of interchangeability at all levels is going to be an awesome task.

Vik :v)
 
Blender is a good choice because it's just about the only high quality 3D modeller that's OpenSourced and widely used.

It can export about a dozen common 3D formats (including '.obj') - and there are 3rd party plugins for a bunch of other formats.

It's not going to be difficult to allow a huge range of input formats though. The hardest thing to do when interconverting polygonal surface representations is ugly issues of data hierarchy, colours, transparencies, textures, etc.

However, for RepRap, you don't need those things. You only need the shape of the object - and that's easy to extract reliably from a huge range of file formats.

The biggest effort will be in converting these inherently *SURFACE* representations into *SOLID* form - and deducing what order to replicate it in, where to add support structures, etc.

Doing that robustly is fairly tricky for a variety of arcane reasons.

Compared to the amount of work in getting that part going, supporting a range of file formats should be a snap.

Personally, I think we should consider inventing a custom '.xml' format that translates directly into RepRap 'rendering' commands - and converting polygonal forms into that in a Blender plugin.

Then people can model their 3D objects normally and naturally and store them in any format they like - then hitting the 'export to RepRap' button to convert surface representation to solid, add support structure and generate rendering commands.
 
Just one thing. ArtOfIllusion has the capability to render in SVG format, including filled patterns. Rendering slices of the scene gives the raw input for a RepRap in vector format files.

How would one do this with Blender?

Vik ;v)
 
this will probably never be read, as it was posted much later than the others.

Have you looked at the pov-ray scene description language? Seeing as you like doing everything as text, it would suit you very well. Pov-ray is a high-quality raytracer that uses textfiles defining simple objects combined using basic boolean operations to create a mathematical representation of the objects. It does all of it's objects with mathematical formulas instead of polygons, so it looks stellar.

Also, object definitions are a breeze.

sphere { <0,0,0>, 2 }

that defines a sphere of radius 2 at the origin.

The objects are inherently solid, so you can use "constructive solid geometry" to add and subtract things from each other. You can write code loops, and define objects made out of a set of operations to make things easier.

The only problem with it is that you can't just "draw" your items. You have to break them down into various primitives.

Anyway, I was thinking you might be interested, and maybe a version of that language could be made suitable for reprap. I'd be interested.
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]