Shop OBEX P1 Docs P2 Docs Learn Events
Input Needed - Combining Propeller Proto Board, Prop DIP 40, and ADC for 3D Printer — Parallax Forums

Input Needed - Combining Propeller Proto Board, Prop DIP 40, and ADC for 3D Printer

idbruceidbruce Posts: 6,197
edited 2015-04-17 05:27 in Propeller 1
Hello Everyone

UPDATE: Post #121 on Page 7, contains the result of the discussion within this thread.

As many of you know, I already have several threads running that pertain to 3D printing, however this topic will be very specific to the Propeller, so I am posting it here. As mentioned elsewhere, I do not want to be struggling for pins or cogs when it comes to a controller. And since I want the controller to be Propeller driven, I want to build the controller with readily available Parallax products.

My goal in this thread will be to combine a Propeller Proto Board, a Prop DIP 40, and a multi-channel ADC, and still have enough room on the Proto Board for all the other additional circuitry needed. I don't know if it will be possible, but this thread will be about investigating the possibility.

Several years ago, Ken Gracey was kind enough to provide board layouts for the Propeller Proto Board, and I will most likely be referencing those drawings several or many times throughout this discussion. If you intend to follow along with this thread, those files and drawings can be found at this location, but more particularly Post #10: Since this thread is just starting, I just want to provide a couple notes and ask a couple questions. I am sure these questions have been answered elsewhere in the forums and probably more than once, so I apologize ahead of time.

Anyhow this is what I know for sure so far:
  • The two Propellers will be able to communicate with full duplex serial.
  • Sockets will not be used for the ICs to preserve precious board space
My main question at this point is:
  • Will I be able to utilize the Propeller Proto Board crystal for the additional Prop DIP 40 without any major complications?
Like I said, this is just starting, and hopefully many of you will participate in this thread.

EDIT: It should be noted that since the Propeller Proto Board already has provisions for PC com as well as many IO traces available, the main board chip will be primarily in charge of motor control and various IO, as well as serial comms with the PC. Additionally it is worth noting that my intention will be to provide commands with a serial interface, as compared to providing provisions for an SD card adapter.

EDIT: If the on-board crystal can be utilized for the Prop DIP 40, one of the biggest problems I see is getting the DIP close to the crystal.

EDIT: Additionally, I should also mention that I will be installing all resistors vertically to preserve board space.
«13456

Comments

  • ErNaErNa Posts: 1,738
    edited 2014-04-25 05:11
    I used to just connect the XO of the master propeller to the XI of a slave and that worked without any problem
  • idbruceidbruce Posts: 6,197
    edited 2014-04-25 05:34
    ErNa

    Thanks for the reply... That is nice to know.

    I just wanted to start this thread to get it going, but my first priority for the day will be a hot water heater installation. OG this should be a fun and wonderful day :) I want to just go and grab a proto board and a dip and start playing. :frown:
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2014-04-25 06:40
    "hot water heater"
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-04-25 06:49
    You can always just use one of the counters to drive an I/O pin at 80MHz and use that as the clock input to your "slave" Propeller. Do it all the time with PropForth but it's not a Forth thing, it's just a Propeller thing. The only components your "slave" needs is bypass caps on the power and any resistors you choose to use on the serial pins (protection is good).

    Here's an example using a QuickStart but the idea is the same.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-25 08:18
    Rick

    Very, very, interesting and helpful. I cannot wait to look at your work more in depth. Thanks for sharing.

    Bruce
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-04-25 09:26
    Hmmm... a very interesting double Propeller configuration that I have never previously considered. It will be interesting to see how this turns out... especially sharing the same crystal.

    I guess you have already figured out there is enough space for the second Propeller and the ADC, and I guess another Eeprom. Something will have to be done to provide a programing port for the second Propeller.

    This might also work nicely... maybe even more nicely with the Propeller Project Board.
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-04-25 10:12
    ... especially sharing the same crystal....and I guess another Eeprom.

    Something will have to be done to provide a programing port for the second Propeller.

    This might also work nicely... maybe even more nicely with the Propeller Project Board.

    In my example, the crystal is not shared, the master Prop drives the clock for the slave. I don't use a second EEPROM either. The master just loads the slave (in the case of PropForth, the Master resets the slave and then just pretends to be an EEPROM on pins 28 and 29). I imagine a similar arrangement could be developed in Spin or C - there is code floating around to let one Prop load another. If you want a second EEPROM, that's trivial. If you want two programming ports, that's relatively trivial.

    Once you make both Props with EEPROMs and programming access, it's more of a peer-to-peer relationship than a master slave but that may be more a matter of semantics than anything else.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-04-25 10:56
    You can always just use one of the counters to drive an I/O pin at 80MHz and use that as the clock input to your "slave" Propeller
    As a student, I learned enough about skew and jitter to know they exist but not enough to know how to apply the knowledge. Will jitter not be a problem? Will skew be small enough that one could consider the two chips to be "in sync"?

    I like the idea a lot. I guess something that would be very cool to see would be both propeller's running the same program - both output 80MHz clocks. One chip outputting to the second chip's XO/XI and the second chip not connected to anything. And then scope the crystal and both chips' outputs and compare them.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-25 15:39
    Loopy
    I guess you have already figured out there is enough space for the second Propeller and the ADC, and I guess another Eeprom. Something will have to be done to provide a programing port for the second Propeller.

    Actually I have not figured anything out yet, but I soon will. I should have all the necessary parts that I may need, with the possible exception of the ADC, and I may even have one of those laying around, or should I say the most important parts. However I just got finished installing the hot water heater, so I am going to relax a bit :)

    I did not go deeply into Rick's work and documentation, but at first glance, it looks very promising.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-25 16:36
    Okay... Instead of relaxing, I had to dig in the old parts box, and here is a list of the goodies I found for this project:

    1 - ADC0831
    2 - MAX1270ACNG
    2 - 24LC256
    2 - 5 MHz crystal
    2 - P8X32A-D40
    1 - Prop Proto Board

    Not the ideal parts list, but it is a start.
  • kwinnkwinn Posts: 8,697
    edited 2014-04-25 19:03
    I think the propeller project board might be a better choice, it has more useable space on it, but if you want to use the protoboard I would suggest mounting the prop dip vertically to conserve space. Bend all the pins on one side of the prop dip 90 degrees and use a row of header pins next in the next row of holes to connect the other 20 pins. Be sure to align it so the XI of the prop dip is as close as possible to the XO of the QFP prop.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-26 00:58
    I have not really explored the possibilties just yet, but I figured I would share a few thoughts and think outloud.

    As I see it, one Propeller would come very close to controlling a 3D printer very efficiently, however depending upon various switching requirements, the number of extruders, etc...., I believe it would be highly beneficial to rely on two Propellers. So the task at hand is to create a two Propeller setup. Regardless of the board type, Proto Board or Project Board, I believe the goals of the Propeller situated to the main board, should be the Propeller in charge of handling serial input from the PC, parse the g-code, issue commands to the slave Propeller, and basically just be a processor of information. Whereas I believe the slave should take on the role of controlling the 3D printer and have tasks such as, executing g-code by controlling the stepper drives with control software, monitor and maintain heating and cooling with control software, monitor various switches for input and provide data back to the master.

    However by providing full duplex serial with the master, we are losing two of our precious pins on the slave. With pins already going out the window, it must be determined what is of the utmost importance and just exactly what the goal truly is. In all honesty, it would be nice to strive for a setup that could be utilized by various CNC machines. With two Propellers being utilized, I really don't see this as a problem, providing the g-code commands are sent serially from a PC. In fact I am going to go out on a limb here and say that a CNC router or PCB driller probably requires quite a few less IO pins as compared to a 3D printer, however the g-code for a router is probably much more complicated, but I could be wrong.

    And then the question of SD card support arises. I cannot speak about the project boards, because I never fiddled with them, but if SD card support is to be provided with a proto board setup, I cannot think of a better setup than wiggling it into the mouse, keyboard, and VGA area of the protoboard, and have it report to the master. Of course that would be dependant upon finding the necessary circuitry and a nice mounting area somewhere in that vicinity. However by going that route, the possibility of keyboard, mouse, and VGA is eliminated. I personally don't wont or need SD card support for my current project, but for other CNC projects, it may be a valuable asset. And now I question the location, what if mouse, keyboard, and VGA is need for another project? LOL there is only so much space on a proto board. What to do?

    It would be nice to be able to control various CNC machines simply from the IO pins of the DIP 40, but in the case of a 3D printer, especially printers with more than one extruder, I believe it will be necessary to pass some of the work onto the master. At which point, I think that should be the monitoring of the various switches, or should this task be assigned to the master in the first place? Because I believe that information would be sent to the master anyway, but I could be wrong about that also.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-04-26 05:21
    Have you created tables yet that list out what each cog and each pin on each propeller is going to do? That helped me sort out a lot of things with a project of mine.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-04-26 08:49
    idbruce wrote: »
    Okay... Instead of relaxing, I had to dig in the old parts box, and here is a list of the goodies I found for this project:

    1 - ADC0831
    2 - MAX1270ACNG
    2 - 24LC256
    2 - 5 MHz crystal
    2 - P8X32A-D40
    1 - Prop Proto Board

    Not the ideal parts list, but it is a start.

    I would consider ditching the ADC0831 and use an MCP3208 which may directly interface with 3.3 volt power and logic.
    The MCP3208 can have a 5VDC reference if you want more range (take a look at the PropellerASC+ schematic for a good example).

    The MAX1270 also is another 5V chip. So the problem is similar to the ADC0831 with Propeller SPIinterface.

    You may get both to work with SPI by puting a resistor in line to protect the Propeller, but with the MCP3208 it is plain and simple.

    I think we all have a few ADC0831 chips left over from the BasicStamp projects.


    +++++++++++++++++++++++++++++

    Space on the Proto Board seems adequate.. so does power. If you do have a second EEPROM, you may want to put the 40pin DIP Propeller in an upside down position on the board. Of course ALL power lines need to be connected and it will be a bit of a reach to get to the far side of the new Propeller. And fitting by-pass capacitors close to the Propeller will get a bit busy. Not sure I'd bother with a reset button.

    Some 3D printer outputs to heaters have a MOSfet driver as the power is more than any uC might supply. You might want to put a few of these MOSfet power drivers on the board as well.

    I've no idea how to allocate actual processing between the Master Propeller and the Slave Propeller. I am still shooting for a 1 Propeller code solution. I do suppose the Master could support an SDcard reader.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-26 10:49
    @SwimDude0614
    Have you created tables yet that list out what each cog and each pin on each propeller is going to do? That helped me sort out a lot of things with a project of mine.
    Nope, no tables, just think about possible scenarios at the moment. Although I have not completely thought this through, I do know that I want to have full access to all of the available pins on the slave. Perhaps the addition of 74HC595 would be helpful for more outputs to control various cooling fans for the power supply and extruders, but as we all know, chips of that size take up a large portion of board real estate.

    @Loopy

    Thanks for the tip on the MCP3208, don't want or need any unnecessary components. As for the mosfets, perhaps/perhaps not, I believe some experiment will need to be done with the hot end to determine actual requirements. For instance, is PWM really necessary for control, or can control be obtained with a solid state relay? Same thing with the fans. I have used several of the solid state relays in the past and they work great, I like one that can be extenally mounted with two screws and can be triggered by 3.5VDC (which the 3.3V from the Propeller performs just fine), however these relays are quite expensive, so a cheaper alternative may be in order. The nice thing about the relays I use is the fact that it is simply a two pin connector coming from the proto board, which saves on real estate.

    As for the EEPROM, yes I believe the slave should have an EEPROM for the stepper drivers and perhaps some tables, as well as other various routines for controlling a machine, and I believe this EEPROM should have it's own programming port. I believe the memory usage on the master should be kept at the bare minimumum with regards to control. I believe this memory could be better utilized for g-code parsing, serial com, card reading, etc... Keeping it down to the bare essentials, because depending upon the type of machine, the parser may require a lot of room. I think perhaps the g-code parser should be thought of as a secondary task of the master, because the g-code parser will probably alter from machine to machine, and of course an SD card reader should be though of optional hardware, with optional software support. The primary task of the master is simply communication. It must communicate with a pc to obtain commands, and it must communicate with a slave to execute the commands. As mentioned the parser could be altered, so it should be thought of as a secondary task, but with this secondary task, a third task is then assumed for the master, which would be the preprocessing of important data, before it is passed onto the slave. However, I think the parser is the key to it all, because I think it may require a lot of room depending on the type of machine. Over the years, I have written efficient code and certainly a lot of code that could have been written more efficiently. Dependant upon the efficiency of the code, we may all be surprised to see what type of parser we can fit into a single Propeller. Do I think I am the one to do it? No I don't, because there are many programmers better than me, but I think I can write a 3D printer parser to fit the Propeller. My main goal at this point is the hardware of the board.

    I picture a board with several terminals or multi-pin headers that can be used for various machine control. And as you indicate, I should strive for keeping as many 5V items off the board as possible.

    I am also starting to think that it would be nice to have a DIP daughter board that simply plugged into the Proto Board with the DIP oriented in a fashion that one of the sides face downward towards the Proto Board.

    Alright I just came up with a new idea......

    Lets just stack two proto boards... That would eliminate a lot of issues..... Master on the bottom.... Slave on top for all machine connections
    • Both are ready for downloads
    • Board real estate
    • Only comm lines going from master to slave.
    Hmmmmm.......

    EDIT: Additionally, stepper drivers such as the Gecko G251X, could be stacked onto the master as outlined it this thread http://forums.parallax.com/showthread.php/133309-Propeller-Proto-Board-Stepper-Motor-And-G251-Gecko-Drive-Tip, but oriented 180 degrees different than as outlined, so that pin headers could be installed on the back of the slave proto board, so that motor connections, are within 1-3 inches. I am beginning to like this idea a lot.

    EDIT: Ooooppssss.... That would be the wrong end for the pin headers.... Once again.... Hmmmmmmm
  • idbruceidbruce Posts: 6,197
    edited 2014-04-26 18:26
    Okay, I have now convinced myself that (2) - Propeller Proto Boards is the answer for making a compact homemade CNC controller, however I still want to make the best use of the resources available on the boards. Additionally, I am stilled geared toward the Gecko G251X stepper drives. These drives are not the cheapest, but they are also not the most expensive. To provide you with a little more information, here are three excerpts from the G251X datasheet, available from Gecko:
    The motor’s rated phase current must be between 0 amps and 3.5 amps and the current set resistor may be a 1/4 watt, 5% part.
    The G251 needs heatsinking for current settings greater than 3 amps. The case temperature (measured on the bottom plate)
    should not exceed 70 degrees C, and for best life should be kept to 50 degrees C or less. Use heatsink compound between the
    G251 and the heatsink.
    CAUTION! Current settings above 3 Amps without a heatsink will result in damage to the G251.
    The drive must be heatsinked to a piece of aluminum, preferably with fins and a fan to increase heat dissipation and surface area.
    Do not screw the drive directly to the door of your control cabinet, as this will typically not provide adequate heatsinking
    properties.
    There you have it..... 3.5A per phase with adequate cooling. Everyone does not need 3.5A per phase, but it is there just in case you need it.

    For now, let's simply forget about attaching them to the protoboard, we need a mounting plate instead. I am thinking 1/16 - 1/8" thick aluminum plate, having the same dimensions as a Proto Board and having identical mounting holes to match. To begin with, this plate can be mounted to the master Proto Board by utilizing 11/16" or 3/4" standoffs, which will get you above that bulky capacitor on the board. As you might have guessed, your drives are then mounted to this plate.

    As I see it, there are two different setups required, which are:
    1. Setup for 3A or under, with no heatsinking required.
    2. Setup for above 3A, heatsink required, preferably with fins and a fan.
    From this point, it is assumed that anyone contemplating this will have some layout experience. If you require 3A per phase or less, simply start stacking your drives on this mounting plate, adding the necessary standoffs as you go upward, but please make sure to attach your wiring harnesses as you add each drive. If you require above 3A per phase, you will have to be a little more creative to provide proper heatsinks and cooling, using taller standoffs, fans, and such hardware. When finished adding all the necessary drives, secure the slave Proto Board to the driver mounting plate with the appropriate size standoffs. As I see it, the stepper drivers should be centered across the width of the mounting plate, with the connection terminals facing outward from the mounting plate, and the drivers should also be mounted at the rear of the plate for a nice and neat connection to the slave protoboard. However, if you attempt this, you are in charge of your own layout. To make full use of these drives, you will need a signal ground wire, a step wire, a direction wire, and a disable wire. In other words you will need a 4 pin header on the rear of the slave Proto Board for every stepper driver utilized.

    EDIT: While writing this, I did not take the time to think this through completely. I now believe the stacking order should be:
    1. Master Proto Board
    2. Slave Proto Board
    3. Stepper Drive Mounting Plate
    4. Stepper Drives
    Additionally, I think there should be two columns of stepper drives along the length of the mounting plate and the header pins may need to be relocated to the side of the slave proto board as compared to the end, otherwise, there will be a huge tower of stepper drives between the master and slave, especially if using fans and heatsinks. Or arrange them in any fashion that you may deem appropriate :)
  • idbruceidbruce Posts: 6,197
    edited 2014-04-26 19:05
    As it stands now, in theory only, on the master Proto Board. we only have the communication lines necessary for full duplex serial, extending from the master to a slave Proto Board, which leaves us plenty of room for an SD card reader, and the mouse, keyboard, and VGA of the master is unencumbered by unnecessary clutter. So why not add an SD card reader to the master? I will tell you.....

    The master Proto Board really needs a Propeller Memory Card (#40004) :
    This product takes up a whopping 8 IO pins, but the master IO pins are pretty much wide open for easy pickin's. This device would add tremendous capabilities to the master Proto Board. The only problem I see is mounting it flush to the right edge of the of the master and having the board surfaces parallel. I believe that is a minor obstacle for the benefits that can be obtained.

    Additionally, at first glance, it appears that this device will only require one cog from the master.

    EDIT: The downside to this post and the previous post is that to be easily accessible, this setup will require placement at the front of the machinery, but I suppose this is not all bad, especially if you consider user machine input and output such as buttons, lcd screens, etc....

    EDIT: I suppose the front bottom left part of the machine would be the ideal location, considering possible exterior cable connections or the setup could be rotated for front bottom right, if the memory board is switched to the other side of the master.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-27 06:14
    Pertaining to Posts #17 & 18, when striving for a setup as described in these posts, I believe the IO pin requirements for a 3D printer, with one extruder, will be very similar to that which is shown below:
    Master Proto Board
    • PMC_IO0_DI *From PIN 0 on master to IO0/DI on Propeller Memory Card, per code example
    • PMC_IO1_DO *From PIN 1 on master to IO1/DO on Propeller Memory Card, per code example
    • PMC_IO2_WP *From PIN 2 on master to IO2/WP on Propeller Memory Card, per code example
    • PMC_IO3_HOLD *From PIN 3 on master to IO3/HOLD on Propeller Memory Card, per code example
    • PMC_SD_CS *From PIN 4 on master to SD CS on Propeller Memory Card, per code example
    • PMC_FLASH_CS *From PIN 5 on master to FLASH CS on Propeller Memory Card, per code example
    • PMC_SRAM_CS *From PIN 6 on master to SRAM CS on Propeller Memory Card, per code example
    • PMC_CLK *From PIN 7 on master to CLK on Propeller Memory Card, per code example
    • FDS_RX_FROM_SLAVE
    • FDS_TX_TO_SLAVE
    • POWER_ON_SWITCH
    • POWER_ON_LED
    • POWER_SUPPLY_RELAY
    • EMERGENCY_STOP
    • START_BUTTON
    • Various IO pins used as inputs from the user interface, such as pushbuttons
    • Various IO pins used as outputs to the user interface, such as an lcd display and LEDs
    Slave Proto Board
    • X_AXIS_STEP
    • X_AXIS_DIRECTION
    • X_AXIS_DISABLE
    • X_AXIS_HOME_SENSOR
    • X_AXIS_OVER_TRAVEL_SENSOR
    • Y_AXIS_STEP
    • Y_AXIS_DIRECTION
    • Y_AXIS_DISABLE
    • Y_AXIS_HOME_SENSOR
    • Y_AXIS_OVER_TRAVEL_SENSOR
    • Z_AXIS_STEP
    • Z_AXIS_DIRECTION
    • Z_AXIS_DISABLE
    • Z_AXIS_HOME_SENSOR
    • Z_AXIS_OVER_TRAVEL_SENSOR
    • EXTRUDER_STEP
    • EXTRUDER_DIRECTION
    • EXTRUDER_DISABLE
    • EXTRUDER_HEATER
    • EXTRUDER_THERMISTOR *Actually, I believe this would be assigned to a channel of the ADC
    • EXTRUDER_AUX_CORE_FAN
    • EXTRUDER_HOT_END_FAN
    • TABLE_HEATER
    • TABLE_THERMISTOR *Actually, I believe this would be assigned to a channel of the ADC
    • ADC_MCP3208_CS
    • ADC_MCP3208_CLK
    • ADC_MCP3208_DATA_IN
    • ADC_MCP3208_DATA_OUT
    • FDS_RX_FROM_MASTER
    • FDS_TX_TO_MASTER
    As it stands, that is 15 assigned IO pins for the master proto board and 30 IO pins for the slave proto board, however as indicated, I believe the thermistors would actually go to the slave ADC, and the arrangement of the home and over-travel sensors can be rearranged to suit ones particular needs or machine, as outlined in this thread: http://forums.parallax.com/showthread.php/155345-CNC-Homing-And-Over-Travel-Discussion

    Additionally, as you can clearly see, I am now leaning on the master proto board to provide a user interface.

    With careful arrangement of the homing and over-travel sensors, and taking the thermistors to the ADC, the slave proto board may have enough room to support one more extruder.
  • varnonvarnon Posts: 184
    edited 2014-04-27 12:30
    I have been doing a lot of 3D printer research lately. My lab might be purchasing one next week. It saddened me to see no developed Propeller based 3D printers, so I am reading this thread (and the other propeller 3d printer thread) with great interest.

    I think the stacked protoboards design will work well. I know you are trying to conserve space, but I see a lot of the interface I/O on the master board as a good opportunity for shift registers in case you need extra pins. On the slave I think you can connect the MCP's data in and data out to one pin on the propeller. Do you need to connect the disables to an I/O pin or can you leave the devices enabled by default? The design is looking nice. I hope you keep posting, this is an interesting read.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-27 15:14
    varnon

    Thanks for your reply.
    I know you are trying to conserve space, but I see a lot of the interface I/O on the master board as a good opportunity for shift registers in case you need extra pins.

    Yea, that would all depend upon particular machine setups. For anyone that might utilize this thread for CNC design, I am sure they will have their own ideas about a user interface. While moving forward with this thread, my ideas evolve, and my goals change. At this point, I think I have a pretty good concept for a CNC controller evolving, but while trying to describe the basic concept, I am also trying the define a narrow concept for my 3D printer prototype. One of my main goals is to keep the master as free as possible, so that I may utilize the majority of the resources for data processing. However you are correct, there are pins available that can be used for a user interface, as indicated above, and yes it would probably be very wise to use shift registers to keep the pin count down, but that would all depend upon the complexity of the user interface. If there are enough spare pins to create a sufficient user interface, then I would not recommend using shift registers, because it just adds more complexity to the electronics and programming. However, if pins are in shortage, then by all means use shift registers.
    Do you need to connect the disables to an I/O pin or can you leave the devices enabled by default?

    The G251X stepper drivers are enabled by default, so they do not need to be connected, unless you decide that you need to be able to disable the drive. And if I remember correctly, to disable the drive, you simply toggle VSS to that terminal on the drive with a transistor, but don't take my word for it, because it has been a while since I have done it.
    The design is looking nice. I hope you keep posting, this is an interesting read.

    Well thanks, I appreciate that comment a lot, because I think it is evolving nicely.

    Now I need to order:
    2 - Propeller Proto Boards
    1 - MCP3208
    1 - Propeller Memory Card
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-04-28 01:47
    In practice, some have combined all the stepper motor ENABLEs to just one. After all, it is not that critical to save power by enabling and disabling individual steppers. And enabling and disabling them separately actually might just create more code that is not required.

    I wonder if something might be done to consolidate the limit switches as well. Much depends on the response to hitting one. Does the stepper motor reverse direction and back up a given amount of stepper and then wait for a soft reset? Or does the stepper motor call for a disable of all the stepper motors and a reset of the whole system. And I wonder if the limit switches play a role after a Reset to seek a 0, 0, 0 position.

    In other words, with the right vision of what the software does at start up and whenever an overlimit or underlimit occurs, some i/o pins might be consolidated.

    And the biggest advantage of the MCP3208 being 3.3volt is that the DATAIN and DATAOUT can share one Propeller i/o pin. (saves one i/o)
    There might be the need to have the Extruder's stepper motor to have a separate enable just to prepare the printer with material, but I am 99% sure that X, Y, Z can and should share. (saves two i/0)

    Consolidate the six limit switches with logic chips to do two things: [a] trigger a flip-flop that over-rides all the stepper motor Enables, and fed all six switch status to a 8 to 3 chip that can be read as 3 input bits to determine which switches are at their limit. In fact, just polling the 3 bits might be enough to have the Propeller do the emergency stop. Wiring in a flip-flop may not be required. (saves three i/o, and you have 2 more indication inputs for other things ... like an emergency stop button.)

    And so it seems that a bit of clever planning can reduce the i/o demand by six pins.

    ++++++++++++++
    I still think this can all be built on one Propeller Proto Board, but it is definitely going to be a bit cramped and require a few clever tricks to get the buld right.

    Making all the 40 pin DIP Propeller pins available by headers on the underside of the board seems necessary.
    The 16 i/o pins on the right edge of the board may require their 1x8 headers on the underside of the board and soldered to the pads that are one column in from the edge.
    The socket for the actuall 40 Pin Dip Propeller is going to have to use the outer most column of pads.
    The 16 i/o pins on the left edge will also have to have their 1x8 headers installed on the underside fo the board.
    I suppose one will have to solder all four 1x8 headers first and then flip the board over and install a 40pin DIP socket.

    The actual headers might be 1x10 and include a ground and a 3.3V source, with the ground at one side, the 8 pins, and then the 3.3v at the other. Again this adds a bit more wiring to the build.

    It would be much easier to use the newer Propeller Project Board.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-28 03:39
    Loopy

    I am taking a much different approach than you. I am trying to provide all options regardless of pin count, whereas you are trying to reduce pin count by reducing options. There will be people that may not want to reduce their options.

    I freely admit that pin count can be reduced, but why struggle? The current price of a Proto Board is $19.99 and the current price for a P8X32A-D40 is $7.99, for an extra $12, you can eliminate a lot of struggle, gain a lot of board real estate, and have many more available options. There may even be some serious struggle associated with two proto boards, but at least there will be some room to work with. For an extra $12, a lot of the soldering, coding, and pin struggle is overcome. It will be like hitting the "EASY" button at Staples :)

    For a Propeller 3 or 4 axes CNC controller, the easiest possible route for "me" is laid out in Posts #17, 18, & 19. To make it 5 axes, a little pin manipulation must be done.

    Whatever route a person chooses, I do believe the Propeller Memory Card is an absolute must for this type of project, because it opens up many other options for program and file storage.
  • ErNaErNa Posts: 1,738
    edited 2014-04-28 04:06
    Agree! If we realize how much time we spend in the forum and "timeestmoney", as the ancient Romans said, the focus should lie on modular, powerful functional blocks, which can be reused. One of the main issues is to find a common inter-cog communication scheme, that transparently crosses the chip boundaries.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-28 11:51
    Since I now believe that I have a pretty good scheme for a Propeller CNC controller, I now want to discuss another problem that has plagued me over the years, and that would be power supply issues. As it stands now or should I say as it could be with a 5 axes machine, here is how I see potential (for the most part guessing) power supply requirements for the proposed controller concept:
    • 15 - 50VDC, 17.5A *This amperage would all depend upon how many motors are enabled at any given time. 17.5A would be enough for 5 motors pulling 3.5A per phase. However, if this is the case, the power supply should actually supply a little more current than 17.5A.
    • 12VDC, 4 - 8A *12VDC will be required by all fans utilized for cooling, these include fans for the stepper drives, general cooling for the power supply and electronics, as well as any fans used for extruders on 3D printers. Additionally, 12VDC will most likely be utilized for heating each extruder of a 3D printer, however 24VDC is often commonly used, but that would make this process even more painful, by adding another voltage to those already necessary.
    • 7.5VDC, 3A *This is where it gets a little complicated, because the power supply adapter plugs come out near the programming ports for the proto boards. Do I really want to run two power adapters, one for each proto board? Plain and simple, the answer is NO. There will aready be 1 AC power line running to the machine for the main power supply utilized by the stepper drivers. Power supplies can be wound to include several different voltages, which all must be rectified.
    As seen above, numerous voltages and amperages will be required by a CNC machine. For my previous wire bending CNC, I utilized a power supply from Antek, Inc. (http://www.antekinc.com/), more specifically their model PS-8N48R5R12, which when rectified, provided 48VDC @ 16.7A, 5VDC @ 1A, and 12VDC @ 1A. To be perfectly honest, this was still quite inadequate for my needs, but it did allow for some expansion. In my particular case, I used the expansion for another 12VDC @ 1A, which provided me with enough amperage of 12VDC to encase the power supply in a NEMA 1 enclosure and keep it cool with (4) large fans, with just a little amperage left over for other fans elsewhere. My power supply is shown below, however the cooling fans cannot be seen. Please notice all the external power adapters plugged into the face of the NEMA 1 enclosure. These extra power adapters supplied all the additional power requirements of the machine. In all honesty, I like this setup because it supplies a wide array of voltages with sufficient amperage to power almost anything I might devise, but it is far from ideal, especially from an aesthetics point of view, and the cabling is a bit of a pain. It is worth mentioning, that 24VDC and 48VDC are toggled by a Propeller pin and a 120V solid state relay. As shown with the power adapters, but not seen, that power supply can provide:
    • 48VDC @ 16.7A
    • 24VDC @ 1.5A
    • 12VDC @ 4.2A
    • 7.5VDC @ 3A
    ps.jpg


    Idealistically, the NEMA 1 enclosure is an abosulte necessity, because of the 120VAC going into it, but those power adapters would be much better off inside the enclosure, perhaps in the form of a raw board with terminals, rectifiers, capacitors, etc... It would be nice to find reasonably priced high amperage 12V power supplies in board form and I suppose this could be broken down to obtain the 7.5VDC for go into the proto boards. Actually it would be very nice to break down the 48VDC into whater voltage was required.

    Anyhow I am just throwing this out there, not that I have any practical solution just yet.
    456 x 342 - 24K
    ps.jpg 23.7K
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-04-28 12:04
    idbruce wrote: »
    Loopy

    I am taking a much different approach than you. I am trying to provide all options regardless of pin count, whereas you are trying to reduce pin count by reducing options. There will be people that may not want to reduce their options.

    I freely admit that pin count can be reduced, but why struggle? The current price of a Proto Board is $19.99 and the current price for a P8X32A-D40 is $7.99, for an extra $12, you can eliminate a lot of struggle, gain a lot of board real estate, and have many more available options. There may even be some serious struggle associated with two proto boards, but at least there will be some room to work with. For an extra $12, a lot of the soldering, coding, and pin struggle is overcome. It will be like hitting the "EASY" button at Staples :)

    For a Propeller 3 or 4 axes CNC controller, the easiest possible route for "me" is laid out in Posts #17, 18, & 19. To make it 5 axes, a little pin manipulation must be done.

    Whatever route a person chooses, I do believe the Propeller Memory Card is an absolute must for this type of project, because it opens up many other options for program and file storage.

    Well, I suspect that someone that is reading your thread and looking for their own solution might see something useful in my providing alternatives. I keep acknowledging that you will build what you want as you see it being best for you. But the Forums are all about exploring ideas ... inclusive of alternatives.

    If it is praise that your are looking for...
    I do appreaciate the idea of adding a 40 pin DIP Propeller to the Propeller Proto Board. It is something that I completely overlooked as a possiblity.
    I suspect I am going to build one inclusive of the the MCP3208. But I suspect that the end product will be deployed as a complete Forth machine with VT100 emulation via VGA and keyboard. It may or may not ever become a 3D printer solution.

    I am not sure where the Propeller Memory Card might fit in. It is an interesting device, but I am uncertain that I gain much over having just an SDcard reader. It is completely new to me.

    +++++++++++++++
    As far as consolidating i/o pins... Maybe you can only gain 3 pins, not 6. But when you get into the actual software, that might be a necessity to sustain better performance.
    Where is the harm is saying that this is possible? Or that it might even eliminate a few lines of code? Am I really reducing options, or am I creating a few more?

    We still have no idea how big or how slow the code might be.
    +++++++++++++++
    If I didn't already have a few unused Proto Boards, I'd do it all on the Propeller Project Board with a second 40pin DIP Propeller.
    Long ago, I explored stacking Propeller Proto Boards and have decided I dislike that scheme. But if one does need a 2 Propeller solution, the Proto Board for video and keyboard interface combined with a 40pin DIP Propeller is very likeable.

    One might even include an IR sensor to allow for an IR remote control of some of your printing processes.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-28 13:08
    Loopy

    Please don't misunderstand me. Your input is welcome, I am just stating that my approach is different than yours. There is definitely room in this thread to discuss the use of a Prop DIP 40, and a person could learn a lot by going that route. In fact the title includes the Prop DIP 40 :) So by all means please discuss it. If the Proto Board had a little more room available, I may have been a little more inclined to go that route.

    As for Proto Board versus Project Board, the determining factor for me was that the proto board provided mouse, keyboard, and VGA support, whereas the project board only has VGA support, or at least as far as I can see. I am assuming that not everyone will want to use a PC serial interface to talk with their machine, and they may want to create their own interface, so to me, the mouse, keyboard, and VGA support provided by the proto board is a plus for board selection.
    I am not sure where the Propeller Memory Card might fit in. It is an interesting device, but I am uncertain that I gain much over having just an SDcard reader. It is completely new to me.

    Okay this is the way I see it, however I could be wrong, and of course this would also depend upon the interface being used, but in my case, this is it. Since I will be using a PC serial interface to send commands to to the master Propeller, I will be using the master EEPROM to store the g-code parser. Tables specific to my machine will be stored in flash memory, because 4MB is a lot of space to store valuable information. I am hoping that table lookups will be faster than processor computations. The SD card slot could be used to store machine configuration files or lets say constants that could be changed by changing SD cards. As for the SRAM, I am not really sure what I would do with that just yet.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-04-29 00:23
    Putting the G-code parse on the Master Propeller seems a bit awkward to me.

    The vast majority of the G-code calls are to G-1 with related X, Y, Z, E, and F info in floating point decimal. The other codes tend to mostly toggle i/o pins or the software configuration.

    The X, Y, and maybe the Z data require linear interpolation to get a diagonal movement of the steppers, so whatever is done to create stepper motion is interdependent. Some of the 3D printer firmware (Tonokip) uses floating point interpolation until the very last. Others use binary interpolation (which should be faster and less code).

    But it seems to me that the G-code parser should be on the same Propeller as the i/o pins it controls and is dependent upon. This is just a gut feeling at this point.

    I suspect a better approach might be to have the stepper motor configuration ( how many steps per mm) on the Master and have the Master pre-process the G-codes to remove all the decimal values. It can handle a big buffer to assure a steady flow of data into the Slave processor where the interpolation of the movement and the coordinated feed of material get resolved.

    It you are going to have a VGA and a Keyboard and the SDcard on the Master, there isn't going to be much left in available cogs for the 3D printer. So I look at it being primarily a front-end. I am not sure that it would be wise to split the parser between the two Propellers, but there is a natural division between the 'Buffered G-codes' that are at the core of the 3D print head control, and the other G-code and M-codes.

    You might be able to just have the buffered G-codes handled on the Slave Propeller in some intermediate code packed that will allow the inserting of some sort of code to toggle the states in any systems as required (these would likely be mostly operator overrides as once running, the normal course would be to touch nothing).

    I really haven't given a 2 Propeller 3D printer solution much thought. I am still looking for an optimal one Propeller solution.

    My main point is that the G-code Parser is a critical element that can bog down through put, or expedite greater processing speed. To do the latter, one must completely understand how to run every printer slice as a complete run without pause. To understand that, one has to completely understand what the G-1 code is doing to drive the printer head control. Other stuff is support systems.

    Unclear about storing the G-code parser in the Master EEPROM. The serial EEPROM link is comparatively slow. I figure that the G-code parser should be in Hubram and possibly the G1 processing all internal to one Cog for the sake of speed.

    Output form the G1 processing will be the linear interpolated X, Y, and maybe Z movements. That has to be buffered and managed with material feed. Material feed has to be coordinated with accelerated and decelerated head movements if that feature is included. (That is a rather annoying headache to my comprehension of what the printer head is actually doing.)

    And so.. I continue to continue...
  • idbruceidbruce Posts: 6,197
    edited 2014-04-29 05:16
    Loopy

    One thing is certain, I don't have it all figured out :)
    It you are going to have a VGA and a Keyboard and the SDcard on the Master, there isn't going to be much left in available cogs for the 3D printer.
    Putting the G-code parse on the Master Propeller seems a bit awkward to me.

    I tend to agree about the VGA, keyboard, and mouse. I truly don't believe the master should be assigned to handle those tasks, even though I previously stated they could and should handle those tasks. With the Propeller Memory Card and FDS, that would already be three cogs running, which leaves us five to go. The beauty of PC serial communication with the master is that I do not need keyboard, mouse, and VGA. That will most likely be someone elses headache or a problem for another project.

    As for the parser, I tend to disagree. In my case, the g-code will be entering the master from the PC serial terminal, I can't see any point in transferring that raw command data to the slave. Since the g-code will be entering at the master, it only makes sense to start processing that information the moment it arrives. Some codes are no brainers, such as pin toggles, but like you say G1s take some serious processing, so processing should begin immediately, by passing the movement codes onto one or more of the available master cogs and then I believe there will be a staging area for the preprocessed data before it is sent onto the slave. Preprocessed data continues to accumulate in the staging area until the data is passed to the slave in a first in first out fashion. The slave would then parse the preprocessed data and execute the proper code according to the data received. In my opinion, the only true obligation of the slave should be to interpret the prepocessed data from the master and execute the proper code for machine control. So in other words, by the time the slave obtains the data, all the timing and number of steps have already been determined for proper linear interpolation. I tend to believe that the slaves job will simply be machine control through preprocessed data.

    I am not 100% positive, but I believe Teacup does this in a similar fashion, without having a master and a slave, however I will have to examine the Teacup source code in much greater depth to get a more precise view of what is actually occuring and how the data is processed.

    Needless to say that I do not have it all figured out, but I think this discussion is a start to a serious Propeller solution. And I think that the best possible course of action is to basically follow the lead of successful 3D printing software and this can only be determined by close examination of the source code. Overcoming the limitations of available IO pins, cogs, and memory is the first step to a true Propeller solution, because you cannot properly run a machine, without having the proper number of these items available. Once you have the proper number of these items, the rest should be code. So if absolutely necessary or simply convenient, a person could simply stack a third proto board for keyboard, mouse, and VGA support for a whopping $20.

    EDIT:
    As for the SRAM, I am not really sure what I would do with that just yet.
    Preprocessed data continues to accumulate in the staging area until the data is passed to the slave in a first in first out fashion.

    The SRAM of the Propeller Memory Card could be used as the staging area for the slave :)
  • idbruceidbruce Posts: 6,197
    edited 2014-04-29 10:29
    After examining the Propeller Proto Board and the Propeller Memory Card, I have come to the conclusion that there is no good way to attach this board to the Proto Board, except in a vertical position. Attaching the Memory card in a vertical position, would destroy my scheme of stacking the Proto Boards, so I now present an alternative solution and perhaps a better one. The Memory Card contains 13 pins that must be connected, so I now suggest installing a 13 pin SIP header on the master Proto Board, and create a harness for connecting the Memory Card. I believe this could be very advantagous, especially from a layout perspective. Unless there is a restriction of how close the Memory Card must be to the IO pins of the Propeller, the SD portion of the Memory Card could be placed in a convenient location for SD card insertion.
  • idbruceidbruce Posts: 6,197
    edited 2014-04-30 06:22
    Alhough sometimes necessary for proper subject categorizing, creating new threads for a very specific subject, can often lead to numerous threads that actually apply to one main subject, and can often be difficult to follow. In such cases, I will always try to provide cross linking, so that others may find pertinent information that applies to the subject as a whole. This thread is one of those more specific threads, that has branched off of a main subject, which is the creation of a 3D printer. In addition to that, when other people come up with their own ideas, they create their own threads and a new branch begins :) Of course we all know this, but I only mention it, because the main thread has branched off into several different directions, which have lead to some very interesting discussions pertaining to 3D printing/CNC, hardware, and software control.

    My main thread, which applies to the making of a 3D printer prototype can be found here: From this thread, Loopy Byteloose branched off and created another thread, which pertains to the porting of the Teacup firmware, so that it may be used with the Propeller chip. The Teacup firmware is simply CNC software utilized for controlling a 3D printer. This thread can be located here: Since he started this thread, I have tried to follow along, meanwhile also investigating some of the leads that he provided. Of course, with the main lead being the source code of the firmware. In one of his posts (http://forums.parallax.com/showthread.php/155093-Porting-Arduinio-3D-Printer-code-(Teacup-firmware)-into-a-Propeller?p=1258591&viewfull=1#post1258591), he provides a zip file which contains most, if not all the source code. For the last two weeks, I have been periodically examining this source code, looking for answers to various questions, but mostly trying to figure out how to bridge the gap between this software and the Propeller to suit my particular project, in my own particular way. As it pertains to this thread and particularly posts #17, 18, 19, & 30, I believe the most important files out of all the source code, are the following files:
    dda.c
    gcode_parse.c
    gcode_process.c
    Oh and of course the associated header files.

    And out of all of these, the most important is dda.c
    I believe these are the main files which need to be ported, because these are files which plan all the moves, and the master proto board will need similar routines to properly instruct the slave proto board. I believe the rest of the source code is pretty much non-specific to the Propeller, or the type of controller that I am outlining. Many of the variables required by these files will be very machine or Propeller specific, so why not keep the most important files, dump the rest, and fill in the missing blanks? Well I cannot think of a single reason, so that will be a goal of mine.

    dda.h defines the TARGET structure:
    typedef struct {
    // TODO TODO: We should really make up a loop for all axes.
    //            Think of what happens when a sixth axis (multi colour extruder)
    //            appears?
     int32_t      X;
     int32_t      Y;
     int32_t      Z;
     int32_t      E;
     uint32_t     F;
     uint8_t  e_relative    :1; ///< bool: e axis relative? Overrides all_relative
    } TARGET;
    
    To get a good grasp on this software, you must follow the TARGET! You must know where it comes from and where it is going, when it starts moving and when it stops moving.

    I believe the rest may be a lot of hard work, but I believe it will be mostly superficial as compared to properly porting dda.c.
Sign In or Register to comment.