New extruder Design

Just a quick update on the EMC controlled extruder. Here is a quick video :

http://www.youtube.com/watch?v=txx586M2r9s

Extruder Tempuratue Control

So I have been spending some time trying to fully implement PID heater control for my EMC based repstrap. As part of that I needed to get all the bugs worked out of the heater design. I'll post of pictures of my new compact extruder heater a little later, I left my USB cable at home.

Well I have reduced the mass of the extruder greatly and attached my thermocouple inside of the heater. By doing this I was able to reduce the warm up time, from 20 C to 220 C, to about 18 seconds. I'm using a 16 ohm resistance heater with a 24VDC supply, so about 36 watts max. Here is the responce shown in the Hal scope:

I'm using a maxim MAX6675 thermocouple to SPI interface (read by a mesa 7i43 anything I/O FPGA board running hostmot2). The Max 6675 chip requires about 100ms to perform a conversion, so I'm sampling it at a little less than 10hz. I have tunned the PID parameters so that the responce time is fast, but there is little overshoot (1-2 degrees) and high disturbance rejection.

For you EMC guys, right now I'm using the hm2 raw interface with a custom realtime component to do the SPI communication. Hopefully somtime soon we will be able to have a formal SPI interface for hm2. I used comp to make the rt component, it is attached to hm2 in the hal.

Here is the dirty awefull code for the comp file:
// This is a component for EMC2 HAL
// Copyright 2009 Jon George
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of version 2 of the GNU General
// Public License as published by the Free Software Foundation.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
component SPI "Drive my SPI thermcouple amp";

//Setup the pins
pin in u32 raw_read_data "Raw Read data";
pin out u32 raw_write_data "Raw Write data" ;
pin io bit raw_strobe "strobe the raw write";
pin out u32 raw_write_address "raw write addres";
pin out u32 raw_read_address "Raw read adderes";
pin out float temp "Current Temp";
pin in u32 CD "the all mighty channel descriptor";
pin in u32 timer ;

//Initialize a variable to store the iteration number
variable u32 iteration=1;// "used to store the interation before configuration"

function _;
license "GPL";
;;
FUNCTION(_) {
raw_read_address=0x1104;
//Select the correct case based on the current iteration
switch(iteration){
case 1: {
// Set up the DDR for the port
raw_write_address= 0x1104;
raw_write_data= ((raw_read_data | 0x3B000) & 0xFFBFFF);
raw_strobe=TRUE;
raw_read_address= 0x1204;
break;
}
case 2: {
//Set up the alt source stuff
raw_write_address= 0x1204;
raw_write_data= raw_read_data | 0x3F000;
raw_strobe=TRUE;
break;
}
case 3: {
//Set up the DBSPI chanell descriptor
raw_write_address= 0x5900;
raw_write_data= CD;
raw_strobe=TRUE;
raw_read_address=0x5800;
break;
}
case 4: {
// The regular running type
//Request the data
raw_read_address=0x5800;
raw_write_address= 0x5800;
raw_write_data= 0xFFFFFFFF;
raw_strobe=TRUE;
break;
}
case 5: {
// Actually read the data on the next cycle
// Read the data
// Note-The data is one cycle old by now!!!!
temp =((raw_read_data & 0x7ff8)>>3)/4.0;
break;
}
}
iteration++;
if(iteration > timer) iteration =4; //only return to case 4
}

Anyhow, I hope this makes us a little step closer to having a really fantastic Reprap interface for EMC.

Basic HM2 SPI driver

So lots of this is what the guys on #emc have been saying from the beginning. I now see the light and see why you would not want to support lots of devices right in the HM2 driver. So I think that all that the only information that the hm2 driver needs is what SPI channels you plan to use and how many "frames" to put on each SPI port. This is what SWPadnos suggested for something similar:

SPI=4,-1,5,-1

Meaning 4 frames on port 0, port 1 OFF, 5 frames on port 2, and port 3 OFF. This would create a set of HAL pins for each frame. They are as follows:

CD (U32) This is the channel descriptor for the frame
SEND (U32) This is pin for the bits to send, the length in bits is specified in the channel descriptor.
RECEIVE(U32) This is a pin for the resulting bits from the frame
READ(BIT) This is a bit that specifies if the frame should be sent during the hm2 read or write functions. If the bit is set, then the frame is sent during the read function.
ENABLE(BIT) Enable or disable the frame.

A driver could then be made for each device. There isn't really anything to difficult to do here. I believe that a simple realtime component could be written for any new device. Then the HAL pins connected and the interface should be very flexible. The device drivers should even be able to send internalization data to devices without any special features from the HM2 driver.


Let me know if I've got something wrong here. Of course I haven't address anything about how HM2 will actually do any of this, but it appears that a conclusion about this stuff needs to come first.

Possilbe HM2 SPI Hierarchy

Do you think this would work? Ignore the fact that it is XML. All the attributes, shown in read are HAL pins. Use config parameters to set how many of everything. Input a bit, float, int, scaling and length transform this into the proper bits to send to the SPI buffer. I know lots of details are missing.

SPI serial interface for MESA Anything I/O Cards

Ok, so I have been spending some time working on developing some hardware, and software for running serious RepRap machine using EMC2. I have to admit that I see lots of advantages of using EMC over the Arduino or Sanguino core controllers. I have been using a MESA 7i43 (www.mesanet.com) FPGA card running Hostmot2 firmware to control a three axis gantry mill. I'm working on adding RepRap capabilities to this machine.
The electronics are great, and I can use servo motors with encoders or stepper motors and still have tons of I/O available to do what I want. However, there is one hold up. I would like EMC to be in complete control of the RepRap machine including the extruder. The only problem with the MESA cards is that they have no analog inputs built into them. I have been talking with the EMC developers trying to determine if it is reasonable to add the SPI serial interface onto the MESA cards to read A/D converters, or a SPI thermocouple interface to measure the temperature. EMC already has PID controller with full feed forward control loops built in. Anyway, this post is geared toward the EMC developers.

Well now that is all done, we have been talking about the SPI driver for the Hostmot2, it has been determined that the hardware portion of the interface is very doable. The hard part seems to be creating a way to describe how to talk to the devices on a BSPI channel, and how to interpret the resulting data. As I have described, I'm not terribly knowledgeable in the way of all the EMC internals. I have been doing lots of reading in the last couple of weeks, but I still have a ton to learn.
Currently the way that the Hostmot2 driver is customized to a specific set of modules (encoders, PWM, stepgen, ect...) is with "config" mod parameter (please forgive me on the terminology) that are basically command line parameters. This is apparently quite difficult to program, but looks like the best way to setup the driver. Today on the IRC I asked if an XML file describing the configuration would be any easier to use. Because of the realtime nature of the driver, this would require lots of "messy" code working directly with the kernel. So not good.

I just kept thinking that we could easily describe how to talk to a device and interpret the results using a XML file. So, here is another one of my crazy stabs at this whole SPI driver mess:

• Create an XML file that gives the hierarchy of the SPI channel and describes how each device talk. It would be nice to have a GUI, but not really necessary.
  
• Develop a script that parses the XML file for errors and conflicts, and then generates the source code for a new SPI driver for the attached devices.
  
• Compile the driver prior to EMC runtime, do all the stuff that I don't know how to do to make the driver work.
• And somehow make it work with the current Hostmot2 dirver...um...I don't know how to do that.
  

Naturally what I'm suggesting is crazy, after all I'm the one saying it. However, I hope that this may spark some ideas of how this might work. Here is a view of a possible XML tree for an BSPI channel:
And here is the raw XML:

There are lots of different SPI devices, but of most interest in this application is A/D converters, D/A converters, and GPIO deceives. The script I talked about would have to know how to handle different types of devices. For A/D, we would need a type that takes the right N bits and creates a scaled, or unscaled, number out of them. The opposite for D/A. For GPIO, the data would need to be mapped to and from the bits.

Anyhow, I'm done going crazy now. let me know what you all think. I'm almost certain to hear that this idea is not the best because hey, Hal drivers are suppose to be static. This of course is just the opposite of standardized components.

Exturder Thermal Model

So yesterday I cooked up a simple 1 dimensional, lumped mass thermal model for Nop head's latest extruder. I wanted to develop a thermal model so that we can predict what the temperature profile in an extruder will be without actually making the extruder. Please note, this model is a steady state model, however, later similar models could be used to study the transient behavior of the extruder.

The model I made has some simplifying assumptions that make it really easy to solve. I looked at the thermal resistance of the conduction in comparison to the convection and decided that assuming there is no convection or radiation was a good assumption. The model is a lumped mass model, meaning that the extruder is split up into a bunch of little pieces. The extruder is sliced into disks along it's longitudinal axis. Each slice is given an effective inside diameter and outside diameter and material properties. Each mass is treated as a thermal resistance and connected in series. The extruder is treated as a constant temperature heat source and the cold end is treated as a constant temperature heat sink. This model requires some design judgment to determine if the results mean anything. Anyhow, if you want more details, let me know.

The results are a pretty good match to Nop Heads measurements. The model is split up into 1mm slices, but it could be split into much less. Really only one slice is needed for each part where the cross sectional area and material properties are the same because the convection is assumed to be zero. I didn't do anything make my model fit Nop's data, it is just right out of the model. Just to mention the model also gives the same prediction for heat loss out of the end of the extruder.

Now the reason for developing the model is to see what we might be able to do to predict what would happen if we made some changes in the design. Now if we look up the glass transition temperature for ABS, we can see that it is right about 100 degrees C. The glass transition temperature is the point where the plastic starts to deform under light loads, and just above that temp it might start sticking the the walls of the extruder.

Lets consider design changes to make the temperature go down below the glass temperature quickly. The following figure shows the results if the necked down portion's outside diameter where simply to be reduced to 3.8mm. I know that is a thin wall, but it is steel, it should still be plenty strong. As you can see the temperature fairly quickly heads below 100 degrees C. The predicted heat loss to the "heat sink" in this design is .85 watts. For simplicity this may be the best design, or something like it. However, it is not the best performance in terms of quick temperature drop and low heat dissipation.
Lets see what might happen if we used a design where the stainless steel is a constant diameter:
Here we see what we expected, a linear temperature distribution, that would lead to lots of sticking on the walls. Also the heat dissipated is about 1.75 watts. Not really the best design.

Now we consider Nop's previous design. Lets pretend for a moment that no bolts are needed to connect the heater to heat sink portion. Just a PTFE tube 5mm OD, 3MM ID, 5mm long. Lets have a look see at what the distribution would look like:


Now, that is the kind of stuff we wanted to see. However, it should be noted that under these condition the assumption that convection is zero is no longer quite as valid. A more realistic curve would not be so abrupt and the aluminum portion would be a little warmer, I think... well not really. Anyhow, what this shows us it that if we have a short portion with very low conductivity then the temperature distribution will have a quite drop. Ok, by the way the heat dissipated in the design is .13 watts. Note that this is without the screws!. If we can just get rid of the low resistance of those screws!

Here is a design that nearly eliminates the heat flow in the screws. Just about any screw material would work, but stainless steel would be marginally better than others. The Insulation doesn't have to be PTFE, I have suggested drywall board and hard board before. I think you will get the point though. Let me know if you have any questions. I understand that Nop is currently working on insulating the extruder end, but I don't know about the heat sink end. Insulating both would reduce the heat flow, but I don't think that it will have a large impact on extrusion performance.

Harmonic Linear Drive

Has anybody seen this before? This is a really neat, neat, neat, neat speed reducer!

http://www.oemdynamics.com/hld_animation/hld_intro.html
http://www.oemdynamics.com/

Unfortunately Animatics products are generally quite expensive. They say they have patent applications for this drive in 30 countries, I can't find the patent. It sure would be neat to be able to use it on the reprap.

Let me know what you think.