I'm planning to make spikes (red ones) and other attachments. But now (because I have 2 boys modelling monsters with at least 4 eyeballs and 10 teeth per monster) I'm in desperate need of extra extra extra eyeballs and teeth.
Here you can find the tooth and eyeball stl files.
Agree to the terms, download them and scale them according to your monster dimensions and make the best monster you can think off.
After finding some time (actually it was so simple that I'm still asking myself why I didn't make time sooner) I finally got to changing the velocity extrusion logic.
My previous posts about velocity extruding and wire-laying were about how I changed the extrusion position (the E0-axis in reprap or A-axis in Machinekit) being calculated by the slicer to a situation where the extruder velocity is a result of the actual nozzle velocity. The big advantage is that tweaking the flow of plastic can be done real-time by adjusting the flow parameters. Because of the pressure in the nozzle due to the filament speed, and as a resulting compression force of the filament (and other causes) the flow of thru the nozzle will have a hysteresis.
You can notice this when you accelerate to a high speed with a high velocity, the nozzle will have to build up pressure. There will be stringy parts of the path that is being printed. So until a new equilibrium is formed, the flow will lag.
Then decelerating the pressure is too much, with respect to the lower velocity, and thus there will be an abundance of plastic. Resulting in wider paths and blobs when standing still.
Some of you will say: "But I can't see those stringy lines in my printer!" That's because I think that the pressure will in some cases be always too big so you don't notice. What you probably would notice though is that if you print only lines at various speeds the lines will not always be equally thick at the acceleration and deceleration positions.
This movie shows that with the lines I print the thickness is equal, at various speeds.
For the velocity extruding my workflow is as follows:
Slice with Slic3r with ALL line widths the same width and ALL line heights (layer heights) the same height. (I'm in the process of overcoming this obstacle, but that task is not finished yet).
Run a script to change the Slic3r generated code to suitable g-code. This link still links to the configuration files (including script) I used with my BBB rev B and BeBoPr-Bridge. I'll do a separate post regarding the script at a later date.
Have Machinekit installed with a suitable configuration for the velocity extrusion.
Print the product.
So how does the new velocity extruding work? This week I thought: "Let's make a nice graph with Graphviz visualising the way the calculations are done...". So I started to type, and after 3 lines of adding nodes and edges in Atom with .dot syntax and graphviz preview package installed I was thinking this would be a loooooot of work. And I had already done it in my .hal file.
I searched and ultimately found this post from Jeff Epler which explains how to generate a .dot file from a running hal instance (or hal configuration file). Such a shame I didn't search for this before because it would have made the work a lot easier.
Resulting in this file. I've exported it to a .pdf document so you'll be able to zoom in and explore. I've highlighted some nodes and below I'll explain what is done at that point.
because I have the linear delta kinematics, the velocity of the axes are measured as joint velocities. Not x, y and z in cartesian space, but the speeds of the tower carriages. This needed to be converted to cartesian because that's not standard in LinuxCNC yet. I shamelessly took the part of the kinematics file that handles the part of calculating x, y and z from the carriage positions and from this I made a hal-component.
This component takes the square root of the total of the squared velocities... meaning
The nozzle speed gets multiplied with the cross section area of the line, and further on divided by the cross section area of the filament to get to the extrude rate of the extruder.
these four take care of the retraction and pre-charge. These happen when the extruder velocity is coupled with the nozzle velocity and the time is set at greater than zero.
The magic happens here! This lincurve takes the speed as an input, and gives a offset value as an output. This curve now consists of 5 values. Anything in-between will get interpolated.
The final result is the position the extruder should have when it is compensated for the hysteresis of the filament. The derivative is taken from the (changing in time) position, resulting in a speed, which is being fed into (end of our journey):
which is input for the step generator for the extruder motor.
There's probably more that I forgot to mention, so if you've got questions or remarks leave a comment and I'll try to answer. Or else leave a message at the Machinekit group which I closely follow.
I'll publish the config files after I have cleaned up the unused artefacts of the previous velocity extruding. Here are the config files.
As an added bonus, for reading this far, here's a movie of the printer printing this part (for you who have a 3D printer and kids a must-have). I'm pretty happy with the result. There's room for improvement. Especially my mechanical setup. Due to the acceleration my hot-end overshoots. As a result the corner of the overhang at approx 4 minutes into the movie is a not as should be. Furthermore, at the end of the movie when I turn the connector around you'll notice little blobs.
I think that this is due to the way the extruder starts and ends. When starting the line, the nozzle will extrude and start to move. When that happens, the plastic is flowing in every direction without a preference. So an equal amount going to the side as, as to as the front and back. When the nozzle has speed, the plastic will become a straight line. Don't know how to solve that one yet. :) Probably when I improve the script for transforming the generated g-code. Then I'll be able to use different extrusion widths again.
This post is not a tutorial on MachineKit/LinuxCNC. There is actually a lot of information about that on linuxcnc.org
Take some time to read about LinuxCNC and what it actually does. At the very least know that of the HAL manual and the Integrators Manual. No need to ask questions if you haven't looked up these, and at the very least read the Contents to know where to look.
When you have set up all the connections (physically wired the sensors, heater, endstop, motors, power etc.) from your printer to hardware side you're ready to do the configuration of your machine, meaning the HAL wiring in the .hal file and setting your machine properties in the .ini file
What's HAL??? The HAL is the Hardware Abstract Layer, and is in fact a way of connecting the software to the correct physical pins. This is done by "virtual" wires. Like in the real world, when you make an electronically cabinet for a machine, the wires get numbered and have a name. Same goes for the HAL. There are wires connecting software pins to hardware pins (and the hardware pins differ per electronics).
What is hard to understand at first is the way it is written. Take this for example:
net emcmot.01.enable axis.1.amp-enable-out => [PRUCONF](DRIVER).stepgen.01.enable
When in doubt forget <= or => and remember:
net signal source target1 target2
what above means is that axis.1.amp-enable-out is the source, [PRUCONF](DRIVER).stepgen.01.enable is (one of) the target(s), and emcmot.01.enable is the name of the signal.
You can make it a little more readable by first naming the signal and it's source and on other lines specifying the targets where the signal connects to. Again, <= and => are just for readability. Result:
net emcmot.01.enable <= axis.1.amp-enable-out
net emcmot.01.enable => [PRUCONF](DRIVER).stepgen.01.enable
Enough of that, just put these memories in your /swap or save them to ~/knowledge
go ahead to the next page to start writing your actual values in your .ini file.
After making my machine suited for the "Velocity Extruding" I wanted to go one step further in using Additive Manufacturing. I recently tested printing over a copper wire, and since I've had this idea for a long time I needed to get it out of my head.
The basic idea is that there should be a slew-ring rotating in the direction of the movement. This rotation will put a wire always right in front of the nozzle, just before being covered with plastic. Then you'd be able to manufacture PCB's in an additive way. You lay the wire (or equivalent) where you need one. strange shaped coils? RFID/NFC antennae?
I have bought a BeBoPr-Bridge a while ago, and when I met Bas Laarhoven (another Bas) the maker of the BeBoPr, he pointed me to the already available expansion for a fifth axis. The BeBoPr can be expanded with the "PEPPER" which are in fact 5 stepper drivers on one board, current adjustable via software, and also decay mode depending on the activity. That means when the machine is idle, the current in the motor is lowered so the friggin noise is less. One problem, I didn't have one at the moment.
First thought was that I could access the pins for the PEPPER and add an external stepper driver. There was one problem, and that was that the already mounted stepper drivers needed to have the "enabled" pin removed, since those signals were used for the STP and DIR pf the fifth motor. (I actually got this info from Bas-L. Below is the quick version, in real life it took a little more time).
See picture below, I bent one pin of a 8 way header, and routed the enable pin from the stepper driver to my breadboard to enable later on:
The addition of this header in between elevates the stepper driver so that there now is room at the J5 connector to connect wires.
Below is the end result. Wires from the enable pins on the stepper drivers, as well as the ENABLE pin, B_DIR pin and B_STP pin (J5.15, J5.4 and J5.5) going out at the right of the picture.
Now the 5th stepper driver is wired, I needed 12V, 5V and GND and looked at the bottom side of the board. It's all there.
Last but certainly not least, the wired breadboard.
This was the electronically hardware part, The mechanical hardware part was also quickly finished, at least with the normal engineering iterations. Last point on the list was getting the slew ring to rotate in the direction of the movement.
For this the direction of travel is needed. Since I have a linear delta machine, I cannot take the positions of the towers (joints) since they are not the actual x, y and z (cartesian) coordinates.
Turned out that the HAL pins I needed from Machinekit/linuxCNC did not exist, at least the reading of x, y and z position is in a branch that has yet to be merged, and I decided not to wait for that. So I took the calculation of the x-y-z position from the kinematics file and put it in a component I can then use in my HAL file. Not the most refined way, but speed is paramount.
This component produces x-y-z coordinates, That position gets a derivative (speed) and is fed into a component that calculates the angle of movement with respect to the positive x-axis. That in turn is used for generating a position command for the slew drive.
See it in action?
As you can see, there needs to be more functionality, cutting of the wire, connecting the wire to components, homing, fine-tuning etc. But that are just "details" and with time and engineering those issues can be solved.
I hope it's some use to you. Don't hold me accountable for the machine you make. Before you can easily make things with this there needs to be some new kind of software, but that's not something on my list for the near future, because that will take up too much of my time for now.
I release this idea under the CERN OHL 1.2 licence. I need to clean up the code and the 3D models, but once done I'll do a pull request for Machinekit, and put the CAD models somewhere for download. I'll update this post when I do.
If you have applications or ideas you can use with this or other technology, publish them and generate prior art. Keep that technology free to use and share so the bad companies can't patent all the logical and sensible things and prevent you using it, now or in the future.
Flexible PCB's (FPC's)
embed tubes and other filament types into plastic or other materials, like starch, organic printable stuff etc. etc.
Use dissolvable PVA as an intermediate to bring wire/chips into tissue
Last week I wrote a post about how I use Machinekit with velocity extrusion and its pressure adjustment to make parts without the blobs (or at least less blobs).
Another thing that's easy to do with this configuration is the making of G-code programs from scratch. And really, just like Scratch, put the pen down, put the pen up type of programming.
See the picture below how easy it is to experiment and verify ideas. I've tensioned 2 wires (0.10 and 0.15 mm) of enamelled copper over a mirror and covered them with PLA.
It's a wish of me to have a device that can print PCB's, but not wit conductive materials, but with good old copper. Like the traces on a real PCB. But instead of making this by removing (etching) all the copper and making a lot of unfriendly waste we could make a device which puts the wire just in front of the nozzle.
You can then also have multi-multi-layer PCB's... How's that? There's no software for this yet, but that should not stop us now. :)
I'm working to finish my device for keeping the wire just in front of the nozzle, rotating in the direction of movement as the nozzle progresses. Also I need to add some functionality to LinuxCNC (calculating the angle of the slew drive from the nozzle movement vector). That will take some days and I'll show you how it works when it's finished.
Here is the movie of the actual covering of the 2 wires.
update: see this post how you can lay down wire in a pattern
It's been a while since my last post, so it's about time for an update.
Since I stopped with the Opiliones project I've still been working on my 3D printering. I'll call it an Additive Manufacturing machine (AM) because I think the name 'printer' indicates it's as simple as pushing a button and having a physical product within the minute. And that's simply not true, It's manufacturing and not printing.
I've been working with LinuxCNC, a BeagleBone Black and a BeBoPr-Bridge board (Cape) since end of december last year. LinuxCNC (and it's recent fork Machinekit) is software for controlling machines...
Recently there has been a lot of development in this area, IMO one very important one is the blending of many short lines (very common output of slicing software) into smooth motion. This is important because when you are making a product, the quality of the extrusion benefits from a smooth constant motion.
I've been hacking away recently in making the configuration files fit my machine. One thing that I use when setting up a machine is adjusting the flow rate during running a program. But this is difficult if the extrusion is controlled by position. You'd have to remember the current position and from that point on you'd need to multiply the positions from that offset point. A lot of calculations and it's currently not available. During the discussions on the Machinekit group the idea came to make the extrusion dependant on the actual nozzle speed.
One of the fun things about being open (source) is that when you want to have extra functionality you can add it yourself. It takes some learning curve sometimes (LinuxCNC, linux, working with git, pull requests etc) but in the end you can actually improve and have exactly what you (think you) need.
So I ended up with:
Changing the configuration files so that LinuxCNC calculates speed of the extruder based on the nozzle speed (the extruder axis is velocity controlled instead of position controlled).
Adding functions for setting width of the line being extruded and the height of that line (the current layer).
(Un)linking the extruder with the nozzle velocity.
Writing scripts that post processes the slicer g-code output (remove all A-axis positions) and inserts the dimensions into the g-code.
Now you don't necessarily have to slice, you can draw on your bed, like with Logo Turtle on the MSX 1 (If you don't know what an MSX 1 is, you probably are a lot younger than me) put the pen down, draw a line, put the pen up (but in G-code).
What's so extremely powerful is the HAL module. You want something added? Then take the blocks you need, multiplying, limiting, etcetera and virtually rewire your machine behaviour.
Because the HAL is so powerful it took little effort to add the bonus function: Live nozzle pressure adjustment. An extra adjustment of the extruder for the current speed. Why? Because inside the nozzle there is a pressure depending on the extruding velocity. So when you start extruding (v=0) you have to build up pressure (having too little plastic while accelerating) and when decelerating you have too much pressure, resulting in a release when you are stopped. This is something you frequently see on sides of the product. See picture below of standard blobs, with plain and simple extrusion. The 3 lines at the bottom makes an "S" movement with disconnecting the extruder speed with the nozzle on the vertical movement, but without retracting. The top 3 lines is the "S" movement, but with retracting.
Because it just takes some virtual rewiring of the HAL i've added the derivate of speed function (ddt) and used that as an input for a lookup table (lincurve, thanks Andy) which adds velocity when accelerating, adds none during constant speed, and subtracts velocity while decelerating. Effectively taking care of the pressure hysteresis inside the nozzle. Want to have other/more specific/finegrained control then you just insert points in the lookup table. Imagine doing that to a elastic bowden extruder? I have my extruder mounted on the effector, with just 8 cm between the drive wheels and the nozzle of my E3D hot-end but even there this phenomenon is there. See result below after adjusting, no blobs at the end of the lines.
here's a comparison of the "normal" extruding at the left, and the "pressure adjusted velocity controlled extrusion" at the right.
And last but not least velocity controlled extrusion in action.
update 1: see this post how you can use this for PCB additive manufacturing
update 2: see this post how you can lay down wire in a pattern
update 3: I've updated the velocity extruding. Go here if you're interested
Gisteren heb ik met Kees Koese op een mini beurs over 3D printen gestaan. Bij het opbouwen de avond ervoor was er nog een tafeltje vrij direct bij de ingang. hebben we toen maar direct bezet. Erg veel positieve aandacht gehad. Het staat in de Tubantia en De Gelderlander te staan. Leuk hoor!
Ik heb recentelijk weer een 3D printer tot mijn beschikking, en om de extruder met m'n nieuwe filament te finetunen had ik een onderwerp nodig. Dit had ik al een tijdje willen maken als voorbeeld van wat je met een 3D printer kan printen.
First I'd like to give due credits to Kees Koese who started with the idea of the magnetic ball joint and made the original design of the effector plate. Give his website a visit to have a look at his multispindle drilling machines. Technicians will like it :)
This post is a how and why about the geometry of the ball seat in the effector plate. Since the original effector plate was made with SLS printing we wanted to be able to print this with FDM printing (both being entirely different processes).
During the first test prints there was still manual rework needed. I wanted to end up having to do nothing at all regarding removing filaments, grinding etc. I think making geometry only with the printer without having to rework it is why 3D printing can be such a fantastic way to manufacture.
Before going into details I was amazed how rewarding and exciting it is to draw your thought/improvement in your favourite CAD program (mine is SolidWorks) and having it on your desk in 30 minutes... Every engineers dream.
The picture below shows the original geometry Kees drew a few (almost 6) months ago. It depicts the ball seat with the area (cylinder) where the magnet needs to fit. Because of the original being SLS printed there were virtually no limits regarding overhang or printing resolution. Notice the second (bigger and lower) sphere that ensures the ball will fit in the topmost seat.
When initially printing this test piece to check if the resulting dimensions were good enough to fit the cylindrical magnet (this situation needs a ∅10.5 mm diameter to result in a snug fit of the ∅10 mm magnet) I had a lot of problems printing because of 2 non-printing areas coming together in mid-air. Also the points where the 2 areas merged were sharp so the filament kept sticking to the nozzle on it's way back. (a lot of words for saying the result was horrible...)
What to do... Make sure there were no pointy encounters so that meant closing the gap between the seat and the cylinder volume. See below:
This was not the way to go. The wall thickness was so thin (wall thin-ness) that it could not be closed (and the ugly thin-ness needed to be drilled away manually... bah...). Because the overhang is at a 15 degree angle there is not enough previous layer to adhere to. Improving (but not really) solving) this could be done by adding wall thickness. But alas... Every solution frequently introduces it's own problem... The distance between magnet and ball was getting so big the magnet lost it's force-field on the ball... Thanks for nothing Master Yoda!
There had to be a way to ensure a minimal gap between magnet and ball without the overhang problem and without wall-thinness situation... If you have something you don't want: (re)move it... See below:
All that's needed is a defined sphere and a axial constraint preventing the magnet being pulled onto the face of the ball (creating friction when the ball is turning). If you add a partial ceiling coming from the side (instead of bottom or top) of the cylindrical hole then during printing you will see a very gentle alteration of the contour of the non-printing area. Then there is enough support from the previous layer to create the overhang.
Final measurement and test were done with calliper (measuring the distance over Ball and Magnet, subtracting the ball diameter and length of the magnet) and multimeter.
I measured a gap of 0.1 - 0.15 mm and when doing the beeeep testing for I got no beeeep. (measuring short circuit between ball and magnet).
This evening Master Simon helped me taking a picture of the actual force of the ball joint connection. Result: One connection can pull 1690 gram. Take that Master Yoda?
Below some pictures of the test, some prints and last but certainly not least the geometry of the connection.
Pulling water in Sigg bottles. I am holding the blue printed part.
Resulting weight being pulled:
Seat of ball with magnet underneath (view from top):
Fit of magnet in area under steel ball (view from bottom):
Misprints being mentioned in this post, next to the result:
Finally after having bored you to death the resulting geometry. First the cut-revolve of seat and magnet volume:
Second the cut-extrude at ∅10.5 with a width of 8 mm. Seen from above. This prevents the magnet from getting in contact with the ball. I also added a radius of R1 at the inside of the cylinder making the sliced contour even more printer friendly.