geo01005-ideas

This is a collection of ideas I have for the reprap project as well as general ideas for other things.


  1. Just a quick update on the EMC controlled extruder. Here is a quick video :
    http://www.youtube.com/watch?v=txx586M2r9s
  2. 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.
  3. 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.

  4. 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.
  5. 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.