Input Needed - Combining Propeller Proto Board, Prop DIP 40, and ADC for 3D Printer
idbruce
Posts: 6,197
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:
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.
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
- Will I be able to utilize the Propeller Proto Board crystal for the additional Prop DIP 40 without any major complications?
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.
Comments
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
Here's an example using a QuickStart but the idea is the same.
Very, very, interesting and helpful. I cannot wait to look at your work more in depth. Thanks for sharing.
Bruce
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.
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.
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.
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.
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.
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.
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.
@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
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:
- Setup for 3A or under, with no heatsinking required.
- 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:
The master Proto Board really needs a Propeller Memory Card (#40004) :
Product Page - http://www.parallax.com/product/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.
- 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-DiscussionAdditionally, 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.
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.
Thanks for your reply.
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.
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.
Well thanks, I appreciate that comment a lot, because I think it is evolving nicely.
Now I need to order:
1 - MCP3208
1 - Propeller Memory Card
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.
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.
- 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: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.
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.
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
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.
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.
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...
One thing is certain, I don't have it all figured out
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:
The SRAM of the Propeller Memory Card could be used as the staging area for the slave
My main thread, which applies to the making of a 3D printer prototype can be found here:
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
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;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.