After closer examination of a potential layout as described in posts #17, 18, & 19, I have come to the conclusion that I was being unrealistic in stacking numerous G251X drives on top of each other, especially for those seeking the full potential of the drive, being 3.5A, because at this point, the drive needs a heatsink and fan, and it would literally become a tower of drives, which doesn't seem like a nice design to me.
However I am still sticking with the master and slave protoboards as outlined. In the case of a 5 or 6 axis machine, especially those requiring heatsinks and fans for the stepper drives, please refer to the photo shown in post #25. The enclosure above the power supply is a 4 X 4 X 24 NEMA 1 enclosure, which houses both a master and slave proto board, (8) - G251X drives, as well as an lcd screen, piezo, numerous pushbuttons, (2) - DB9 connectors, and several rotary switches. Considering that the pushbuttons and rotary switches extended well into the enclosure, the available space was quite cramped. However at this point, I am now considering this option again, although there should not be a need for quite so many switches. For those that might be considering such a project, especailly those that need heatsinks and fans, I would suggest that you also consider this option, however a 6 X 6 X 24 would be much more accommodating.
1 - 4 X 4 X 24 NEMA 1 Enclosure
3 - G251X Stepper Drives (2 more required for my project, although I may rob one from another contraption)
4 - Applied Motion NEMA 17 Hi Torque Stepper Motors with dual shafts (3 - HT17-275D and 1 - HT-075D) (1 more HT17-275D required)
Various Molex SIP headers
Cable Chain (although I may not use it)
As indicated in the parent thread, I already have most of the materials necessary for building the main components of the 3D printer, with the exception of the wood necessary for the cabinetry, and as you can see, very shortly, I should have most of the electrical components, with the exception of 1 or 2 drivers, and an additional motor. I thought I had the additional parts needed, but I was wrong.
As indicated in the stepper selection, I have a NEMA 17 HT17-075D, this will be the motor that I will be using for the extruder, because for a NEMA 17, this baby is pretty darn strong, and I don't exactly know where I am placing the spool just yet, so I may need the extra torque for pulling the filament.
In the parent thread, I refered to my 3D printer project as "El Cheapo", when in fact, it is far from being cheap, at least electronics and motor wise. This baby will have 48VDC coursing through its viens when I am finished. Okay perhaps a bit of overkill, but hey you only go around once.
I will have to get off my keyster and start building soon. To be perfectly honest, I am looking forward to this new challenge.
I should have most of the electrical components, with the exception of 1 or 2 drivers, and an additional motor. I thought I had the additional parts needed, but I was wrong. :frown:
LOL... Talk about a brain flatus... Even though I had a smiley, I would have been stressing and sweating over the missing parts until I got them.
Good thing that math was never my best subject.
X Axis - 1 motor required +
Y Axis - 1 motor required +
Z Axis - 1 motor required +
E Axis - 1 motor required =
_______________________
Total 4 motors required *Gee, that is the total number of motors I have available - DUH
So that leaves me with one missing G251X stepper drive. After visiting the Gecko website and seeing that the price of these stepper drives have gone up, I believe I will just scavenge one from an idle machine for now, which should put me in very decent shape to start building the printer.
The primary focus of this thread pertains to a CNC/3D printer controller and the software needed to run it. Since it will probably be a little while before I actually get back to the controller or software, I am now going to shift my focus back to the primary thread, where I will be discussing the actual construction of the 3D printer. To keep abreast of the developments, please feel free to visit the parent thread (http://forums.parallax.com/showthread.php/154883-A-New-CNC-Build-3D-Printer-El-Cheapo) and poke around.
The parent thread has numerous pages of idle talk, however there is some good information buried deeply within that thread. Dependant upon the actual level of my ambition, the parent thread should now be taking a new turn and become much more serious. I will be discussing the construction of some critical components, as well as revealing my successes and/or failures.
I will return back to this thread, when I reach this stage of the build process.
Hi Bruce,
My original scope was to get a 3D printer firmware implemented on one Propeller, possibly with an SD card reader. And Teacup is primarily a reference for what should be a useful library of G-code calls. I am going to wander away as that remains the scope of what I desire to achieve. If I can manage to port all the features that Teacup has to offer into one Propeller and achieve reasonable performance, I will be quite pleased. I am also comparing Teacup to GRBL to get how different authors structure the control of the stepper motors in coordinated movement with features of acceleration/deceleration and lookahead. GRBL has pretty good supplimental information.
On the other hand, you have your own work in progress of defining the scope of what you desire. Your approach is likely to be more feature rich.
I cannot seem to find the time to follow along with your various threads and get anything done with my own project. So I will just plod along with trying to create a Teacup-ette for one Propeller.
On the other hand, you have your own work in progress of defining the scope of what you desire. Your approach is likely to be more feature rich.
Yes, I have a nice vision, but it could end up being another total failure. There is still a lot of hard work and thought that must go into this project, and then I may still fail to succeed.
I have said all along that my primary goal is to test my actuators, however I truly want the project as a whole to succeed. Besides the actuators, there are still major obstacles in front of me concerning circuit design and software. Choosing an existing solution for circuit design and software would probably be the wise thing to do, but then we still do not have a solid Propeller CNC solution. My secondary goal is to outline a fairly versatile CNC controller, being hobbled together by various components and circuit boards, which can later be trimmed down to design an actual versatile CNC controller circuit board. To be perfectly honest, it would be nice to see a Propeller controller board, where you could simply plug in the proper amount of Pololu stepper drivers for your particular CNC equipment and upload the proper source code, and if the Pololu drivers do not supply enough amperage or voltage for a particular CNC project, then hardwire the appropriate drivers to the board..
To me, the software, is independent, because CNC machines vary, but there are some very basic requirements for the hardware. Considering all the possible variations of hardware and multi-axes CNC machines, it would be very difficult to satisfy all the software requirements, if not impossible, so my focus on software will strictly pertain to 3D printing, at least for this project.
Others have disagreed, but I believe that both you and I are both putting the cart before the horse with software issues. In my opinion, the Propeller controller should come first.
Here is my propeller cnc controller. It has switchable inputs from parallel port to USB, so Mach3 or other P port app can drive the steppers, or the prop can drive them(with PC data). 4 axis, 4 mosfets for switching devices on, home switch input. All extra inputs and outputs are on the board. IMO It takes less time to make a proper board and send it off to order than it does to hack various boards together. You cannot easily duplicate the hodgepodge for others to contribute. TC has shown in other threads that ordering a proto board is very cheap with osh. 12 day turn. Mach3 has options for 3d printing that are working. I would opt for incremental stages of development versus all or nothing. Mach3 is almost free and driving the steppers and extruders is already worked out. This allows getting the machine part dialed in with low investment on the software/gcode side of things. After the machine works, then if the goal is a true prop>gcode engine, tackle that as a separate entity with a known working machine. The goals of the final machine can help decide what is best for the overall design. If the goal is to make a Prop run gcode, that is one thing. If it is to have a 3d printer to play with with minimal effort, that is another.
IMO It takes less time to make a proper board and send it off to order than it does to hack various boards together. You cannot easily duplicate the hodgepodge for others to contribute.
Hmmmm....
I would have to disagree. I know for a fact that I can receive a Proto Board in the mail and within an hour or two, with the proper stepper drivers in hand, I can have four stepper motors rotating simultaneously at different speeds, in either forward or reverse, and have them stop individually with the appropriate input. I do not know of anyone who can create a circuit board that fast to run four stepper motors, not including the 12 day turn around.
Additionally, to design a controller board of that magnitude, a person would have to have a very high level of skill in circuit design and board layout, which would eliminate a high percentage of forum members as well as visitors.
@T Chap
I trying not to get caught up in long discussions of pro and con.
My own feelings are that having your board ready to go and being supported by Mach 3 may be an excellent alternative for 3D printing on the Propeller. It certain seems an easier, less steep learning curve as an entry point. And there is plenty to learn with 3D printing.
My point of entry was simply a rather naive choice based on knowing next to nothing, and desiring to not have to commit to purchasing any software. But building up 'sweat equity' is rather steep in approaching it my way. I just have plenty of time and no real need to rush an actual printer into operation.
Talk about "Freaky Fast" delivery, my Parallax order has already arrived
This order was not supposed to arrive for another two days. Sometime the US Postal Service can be quite effective.
Anyhow there is nothing quite like the look of a brand new Proto Board to spark my interest, and now I have twins
As for the Propeller Memory board, there is really not much to it, but as usual, the quality of this Parallax board is outstanding. I am almost half-tempted to break out the Propeller BOE and toy with this board a little.
It has been a while since I have had anything to add to this thread. As usual, progress is slow, but I now have an extruder design that I would like to build and test. However I don't want to move to quickly and screw up one of my new proto boards. The overall scheme has been laid out in previous discussion, but I would now like to start hammering out some of the finer details.
As previously mentioned, I want the slave proto board to run the machine, so this board would control any extruder. To control the extruder appropriately, I need to know the temperature of the hot end, at any given point in time. To obtain this temperature, I will be using a thermistor, which will be attached to the hot end, and to retrieve the temperature for the Propeller, I will be using a MCP3208 ADC. It only stands to reason that since the thermistor is part of the machine, the ADC should be mounted to the slave proto board. However, before I get too carried away with soldering the ADC to the slave, I at least want to have a fair idea of what pins and cogs will be necessary for the slave to control the machine.
I already know that I will get some grief for this list, because some of the items may be combined and switches may or may not be needed. It is my intent to atempt to foresee every possible oversight regarding IO pin assignments, so this list may or may not be accurate, but it does account for some items that probably won't be utilized by me or this machine. Anyhow here is a list of required pins for a single extruder 3D printer:
According to this list, I will need the following:
25 IO pins
2 Possible future IO pins for cooling fans
2 ADC channels
Alright, so now we are ready to start figuring out the necessary cogs. Once again, I want to make sure that I have plenty of resources to accurately run the machine. With this in mind, I will dedicate a cog to each stepper motor utilized, the ADC will have a cog of it's own, full duplex serial requires a cog, and I believe the main program should have a cog, which totals 7 cogs. To maintain the arrangement of this post, here is a list of the required cogs:
Cog 0 - Main program
Cog 1 - Full duplex serial
Cog 2 - X axis
Cog 3 - Y axis
Cog 4 - Z axis
Cog 5 - Extruder
Cog 6 - ADC, thermistors, and heaters (monitor and control)
At first glance, with a little rearrangement of the pins required for home and over travel sensors, the slave board should be able to easily adopt and carry the burden of a second extruder. Perhaps the use of all these cogs is a bit of overkill, but at least I know they are there if I need them. Besides, it all looks pretty good to me at this point.
It is now time to figure out just exactly where I want to place the ADC on the slave proto board.
I don't see how you are going to gain any advantage by having the X and Y axes on separate cogs. The linear or curvilinear interpolation requires that both work closely together.
And since the Z axis is only called into play when a new slice is to be added, you might as well have the X, Y, and Z all on the same cog.
That leaves the question of whether there is any advantage to the E stepper that feeds the filament having a separate cog. I doubt there is any advantage. It needs to be in synch with just about everything.
My gut feeling is that this all would best be done in PASM and signed integer maths. The Arduinos seem to blithely use floating point that can increase code overhead and slow down speed.
I would have a special cog for an output buffer than would include the printer head accelleration/deceleration. Not yet sure where to put the 'look ahead' feature that some code tries to use.
I have also running into some CNC setups that not only have minimum and maximum limit switches. They have sensors for a home position as well. This could be the 0,0 for starting printing, or it could just be the center of the printer bed that is easier to search for without banging your machine out of calibration by hitting extremes. The sensors are hall-effect.
Of course that would need another 3 i/o pins, but I do like the idea of seeking a starting position in the middle. And then moving off of it in any direction you choose to begin to print. It would be extremely easy to add a line in G-code to do this if your slicer software doesn't provide the code.
I don't see how you are going to gain any advantage by having the X and Y axes on separate cogs. The linear or curvilinear interpolation requires that both work closely together.
And since the Z axis is only called into play when a new slice is to be added, you might as well have the X, Y, and Z all on the same cog.
That leaves the question of whether there is any advantage to the E stepper that feeds the filament having a separate cog. I doubt there is any advantage. It needs to be in synch with just about everything.
Surely, you must be joking.
All the drives must be sychronized for interpolation. How could you do it efficiently all in one cog? I don't even begin to see that as the least bit possible, okay maybe possible. Each stepper motor will have different timing that must remain in sync with the other motors to make the completed move at the same time. Each motor will likely have different amount of steps that it must make, etc...
It most certainly is a multi-thread proposition, at least to be efficient.
If you did attempt it with one cog it would be so slow, because you would have to tell one motor to take a step and make all the other wait their turn. Each motor would have to take a step then wait until it was it's turn again.
I strongly suspect that gaining performance (fast throughput) might better be achieved by feeding g-code with a 115,200 baud serial port input with XON and XOFF control and having a single buffer for coordinated stepper output that assures each G-1 call is executed flawlessly.
Initially I considered having separate cogs for X, Y, Z, and E; but the interpolation seems to snag that scheme. X and Y have to derive a coordinated series of steps for every entry of G-1 codes. How fine the steps are is dictated by configuration issues of [a] the mechanics involved, and the selection of a particular micro-stepping. These configuration parameters spill over into determining how large an output buffer must be.
I am a bit concerned that the buffering may bog down everything. Either the buffer is all in hub ram or a dedicated cog that gets the X, Y, Z, and E parameters passed to it.
What you propose seems to me that 4 cogs will handle the output buffering for an individual stepper. That would limit the buffer size to remaining cog ram, unless something creative was done (such as having 32 bit longs store a series of 32 bits of step sequence and use shifting to stream STEP bits out).
How do you propose to coordinate 4 output buffers?
I don't have an exact answer just yet, but it will be something like this:
PC sends G-code to the master proto board.
Master proto board interprets G-code command. Simple commands are simply sent to a holding area for slave processing, while complex commands, such as G1, the master will perform all the necessary math, to establish the number of steps, timing, direction, etc.... and then this data is also sent to the holding area for slave processing. While the slave is busy performing machine tasks, the master is figuring slave tasks ahead of time. If the slave is faster at processing the tasks, as compared to the master figuring the task, then the slave must wait until the figuring has been completed, but I highly doubt this will be a problem, especially since the master is pretty wide open for resources.
The slave retrieves tasks from the master in a FIFO fashion. When it comes across a complicated task, such as coordinated movement, the math will already be figured, and the data will be broken up according to the axis. The code will then be executed to make the coordinated move.
OBJ
X_Axis : "StepperDriver"
Y_Axis : "StepperDriver"
Z_Axis : "StepperDriver"
Extruder : "StepperDriver"
PUB Main
X_Axis.Start( ) '''New cog started'''
Y_Axis.Start( ) '''New cog started'''
Z_Axis.Start( ) '''New cog started'''
Extruder.Start( ) '''New cog started'''
''' Miscellaneous code for full duplex serial initialization and code for retrieving data from the master.'''
''' Data is held in variables to be passed to the stepper drivers.'''
''' At this point, I forget exactly how cog sync is done, but I have that information stored somewhere. Anyhow'''
''' I believe it goes something like this.'''
''' 1. Obtain CNT
''' 2. Add time to CNT to make a point in the future and store the result in a variable, such as "ExecutionBegin".'''
''' 3. After getting a future time, necessary for syncronizing several cogs, pass all the data to the stepper drivers.'''
X_Axis.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps)
Y_Axis.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps)
Z_Axis.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps)
Extruder.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps)
''' The first instruction of the Move method of the StepperDriver object would have a WAITCNT instruction, where the'''
''' future time of "ExecutionBegin" would be inserted.
''' I believe it is something very similar to that.'''
Of course, this is just a simple example and does not account for ramping of the stepper motors, but I believe you will get the idea.
Several minutes after writing my last response to this thread, I had an epiphany......
The master protoboard is only required in situations where the CNC machine or 3D printer is not directly attached to a PC. In situations where a PC is utilized, the PC becomes the master.
Referring to Post #41, there should be plenty of resources available, with the slave directly connected to the PC. The PC would contain a program that interprets G-code commands, stores data, and sends serial information for machine control to the slave. I like this plan because it eliminates one proto board and the Propeller Memory Board, and I am sure it will be much faster.
Yes, indeed!!! Nobody has an exact answer until the code gets written and tested.
Though I started with the Arduino C code examples, they are a bit frustrating. Nonetheless, my impression is that the G-1 commands are pretty well tied to one task that needs to be fully coordinated between X, Y, Z, and E. Each line of G-1 is a complete packet.
Breaking out into parallel codes for X, Y, Z, and E control may seem ideal, but that is 4 cogs tied up.
I suspect that if speed is essential, less cogs might be made to perform better.
If the throughput of one G1 processing cog was too slow, the exact same code could be loaded into two cogs that alternate taking on the task. The output would process in half the time. If it is still too slow, a third cog could be called into play and fed in rotation. This would cut the processing time to 1/3, but have the complete coordination of calculations done by one CPU in each case. You may never need to tie up that 4th cog.
This isn't pure 'parallel processing', but better be described as a Gattling Gun approach to parallel processing.
I hate the idea of have the X and Y axis cogs slogging away slowly while the Z cog is not called 95% of the time and the E cog spends most of its time waiting for the X and Y to get finished. If any division by motor is warrentted, it may be to clump the XYZ together and have the E separate. The E cog could alternative between feeding and monitoring the print head temperature status.
You do have to have a cog doing SPI interface for the MCP3208 that is your ADC. Some of your pin allocations seem to have forgotten that you have 8 ADC inputs available. If you are only using two for temperature monitoring, the other six could actually monitor limit switches on the 3 axes.
++++++++++++++++
I won't bother to go into my learning curve gripes with porting Aduino 3D printer code to the Propeller, but I haven't given up trying to produce something.
I have learned a lot ... especially about 'What is C++, and Arduino code, compared to C?'
I was naive as I thought that I could just limit my learning to ANSI standard C, circa 1989.
While the comparison is a topic that I did want to learn, I must say there are some interesting and annoying suprises. Mostly in the weird distortion that Arduino users seem to think of as Arduino code as being just C.
Arduino code is really written in C++ and you can't add new libraries without being adept in C++, but the average user is buffered in such a way as they tend to write C code without realizing it is being used in a C++ compile environment. All this is nicely hidden by the Arduino IDE which is written in Java.
In sum, the average Arduino user has no idea what is real C or C++. And I am still learning how to unsnarl all that.
And then there is the reality that C was written for computers in the days where they really were 'business machines' or 'university research publication managers'. So 'Floating point' and 'String manipulation' are a main focus. Input and Output are not offically any part of C... that is for the libraries to provide.
For a CNC g-code parser, all that is pretty much distraction. I am absolutely sure that on the Propeller, this could be better coded in PASM for optimal performance.
You do have to have a cog doing SPI interface for the MCP3208 that is your ADC. Some of your pin allocations seem to have forgotten that you have 8 ADC inputs available. If you are only using two for temperature monitoring, the other six could actually monitor limit switches on the 3 axes.
That is a brilliant idea!!!! Thanks for that one Loopy!!!! That opens the door for another extruder or axis.
I do not think I agree with you on the cogs though. They are there, so why not use them for parallel processing, instead of letting them sit idle?
Well I am still working on a one Propeller solution, so my budget of available cogs is tighter.. along with i/o pins. I believe that Leonardo da Vinci claimed that small spaces discipline the mind. I tend to feel that fitting code into tighter chip space creates a better understanding of how to get the most out of everything. Everyone has gotten on the more RAM, faster CPU parade for decades; but most have no idea of how to properly use the capacity on hand. The Propeller has 32K bytes of RAM and 8 CPUs. My first computer was an IBM360 that took punch cards, had only 64Kram and one CPU. It also required the university to build a separate building to house it. In its day, it did all the work for the university and was used additionally for student classes.
PCB with one Propeller and one MCP3208 (should provide 4-5 axis support)
PC software which contains a G-code interpreter and provides serial communication to the PCB (maybe Mach 3 can be a direct connection, I will have to research this)
I believes this handles all problems associated with IO pins and cogs, and I believe this will be the fastest possible resolution. Additionally, it would be a Propeller solution.
Apparently some people are using Mach 3 for 3D printing, however I am now thinking about specialty software tied to the board, instead of relying on Mach 3. Perhaps porting the Teacup firmware to PC software, might be a simple task.
Well, you seem to be wandering in various directions. I have tried to stick to one simple plan as I knew I was getting into a lot of new topics. So, I am still trying to figure out a way to get my Teacup-ette into one Propeller that is initially fed g-code via a serial terminal download from a desktop. And then I hope to have an SDcard version. Those have been my goals and still remain the same.
For me, it has been slow going because I needed some reference code to start with and that all seemed written for the AVR chips in C or Arduinio's version of C++. But at least I now understand the building blocks that are required. But it seems that the Propeller will make deployment of the same features a bit different.
I still can't see how to really use GCC to get individual cogs to do what I want. It all feels as though I am programing for an emulation of a single CPU device and with the LMM adding a bit of a slow down to the Propeller. So a direct port of Arduino code into the GCC quickly becomes a loosing battle.
I have just focused on trying to make Tonokip_with_Serial work as an exercise to teach me to see everything I need to know about reading C or C++. I do admit that I am a slow learner with it... tried to ignore reading Arduino documents and C++ documents for a long time.
Yes, one thing I have learned over the years, is that ideas evolve, and the first solution, usually is not the best solution. My plans are always changing, first I have a concept, then I try to make it better or more efficient.
Between my epiphany and your brilliant idea, we have made leaps of progress today. Now if only I could convince you that the Teacup firmware needs to be ported to PC software, we would be on our way to a real nice Propeller solution for 3D printing. And with a few other tweaks, perhaps the PC software could run a CNC router with the same board.
I would be interested on working towards this solution with you. As a plus, you would receive a lot more help and support, because my heart would be in it, and I am heading in that direction. I could benefit from your knowledge and you could benefit from mine. If you have an old PC around, that has WIN 98 to WIN XP, then I have Microsoft Visual C++ 6.0 Standard Edition that I would let you have. Back in the day, this was high quality software for developing C/C++ programs. Believe me, it will blow your doors off. I have similar software that I use, only it is the Professional Edition. Either way, we could share files that would be compatible, and quickly develop a software solution. Besides newer editions of Visual Studio, you will not find better software for developing C/C++ programs.
I spent some more time in the Teacup firmware this morning and started deleting files
As I see it, there are 14 files of the utmost importance, when going the route that I suggest. 13 of these files would be ported to the PC serial software and 1 file would be ported to the Propeller. Here is a breakdown of the files that I deem necessary, for the route I suggest:
Besides porting the software, the biggest trouble that remains is sending the information to the Propeller in a timely fashion and in a manner that the Propeller can decipher the information received. Communication between the PC and the Propeller is no serious issue, because Full Duplex Serial and the PC software already take care of these matters. From the PC, the Propeller will receive simple commands (simple g-code commands) and complicated commands (complex g-codes, such as G1), although the Propeller will not be expected to interpret g-code commands, because that will be the job of the PC. As previously stated, the PC will be in charge of interpreting g-code and perfoming all the necessary math to achieve coordinated movement, except ramping. As an example, to achieve coordinated movement for a G1, without ramping, the PC would serially send the following information to the Propeller:
X - Number of steps
X - Direction of rotation
X - Pause between steps
Y - Number of steps
Y - Direction of rotation
Y - Pause between steps
Z - Number of steps
Z - Direction of rotation
Z - Pause between steps
Extruder - Number of steps
Extruder - Direction of rotation
Extruder - Pause between steps
As mentioned, this is a simple example, and does not include ramping of the stepper motors. Ramping would make it much more complicated, but ramping is definitely a necessity, so this will have to be figured out at a later time, once the simple stuff is complete. As I see it, ramping will have to be computed by the Propeller, after receiving the general G1 parameters from the PC, however I could be wrong, and perhaps ramping could and should be computed by the PC.
Loopy has a point here. A cog running PASM can loop through a program for stepping all 3 or even 4 motors far faster than the motors can physically move. Pass the cog step rates for all 4 motors and it can easily do it.
All the drives must be sychronized for interpolation. How could you do it efficiently all in one cog? I don't even begin to see that as the least bit possible, okay maybe possible. Each stepper motor will have different timing that must remain in sync with the other motors to make the completed move at the same time. Each motor will likely have different amount of steps that it must make, etc...
It most certainly is a multi-thread proposition, at least to be efficient.
If you did attempt it with one cog it would be so slow, because you would have to tell one motor to take a step and make all the other wait their turn. Each motor would have to take a step then wait until it was it's turn again.
+1 - Why use a second chip when you don't have to. If a little planning gets it down to one propeller you have not only saved the cost of the chip, but have avoided the extra software complications coordinating two chips entails.
Well I am still working on a one Propeller solution, so my budget of available cogs is tighter.. along with i/o pins. I believe that Leonardo da Vinci claimed that small spaces discipline the mind. I tend to feel that fitting code into tighter chip space creates a better understanding of how to get the most out of everything. Everyone has gotten on the more RAM, faster CPU parade for decades; but most have no idea of how to properly use the capacity on hand. The Propeller has 32K bytes of RAM and 8 CPUs. My first computer was an IBM360 that took punch cards, had only 64Kram and one CPU. It also required the university to build a separate building to house it. In its day, it did all the work for the university and was used additionally for student classes.
BTW, one adc channel could be used to sense several switches by putting a pulldown resistor on the adc input and different value pullups on each switch.
Loopy has a point here. A cog running PASM can loop through a program for stepping all 3 or even 4 motors far faster than the motors can physically move. Pass the cog step rates for all 4 motors and it can easily do it.
Please excuse me for being a "doubting Thomas", but I would have to hear the overall strategy and the grand scheme of things, from PC to a Propeller coordinated movement of 4 axes all in 1 cog. I believe in order to do that, the math and algorithms would have to be in that code. A simple explaination in Spin would be suffice.
+1 - Why use a second chip when you don't have to. If a little planning gets it down to one propeller you have not only saved the cost of the chip, but have avoided the extra software complications coordinating two chips entails.
I am assuming this comment was intended for me, if it was, I have already come to the conclusion that it can be handled by one chip when connected to a PC, but if not connected to a PC, then I believe there will be a need for a second chip, because you still need a machine interface of some sort, and that will require a fair amount of resources.
BTW, one adc channel could be used to sense several switches by putting a pulldown resistor on the adc input and different value pullups on each switch.
I thought Loopy's idea was brilliant, but that trumps his idea, providing the surplus channels can be used elsewhere.
Odd, I can't quote previous posts on my phone so this ifs a reply to the doubts as to whether all the steppers can be controlled with one cog.
Everyone else does it with a single threaded process so the idea of doing it with multitasking is actually the exception to the rule.
Doing it with no acceleration is trivial.
Doing it with basic acceleration takes more effort.
Marlin has some really snazzy functionality such as examining series of points and determining if it's an arc. If it determines yes, it uses its own calculations as opposed to the g-code provided. HUGE quality increase on curves.
Lastly, tinyg calculates not only velocity (feed rate) but acceleration (backlash prevention) but also rate of change of acceleration.
This additional treatment means my 3D printer at 200-300mm/s no longer tries to self destruct with vibration.
Unfortunately tinyg doesn't have 3D printer support.
Here it's our opportunity for ourselves and parallax.
If we could implement tinyg algorithms on a propeller based 3D printer board you would be AHEAD of the competition and not playing catch-up.
Hello, I follow this thread with interest, as it touches some problems I face. I engaged in this project http://www.tbone.cc/ not because I want to use a arduino or linux, but because I know that steppers are not made to move ;-) Steppers are motors driven in stall mode and that means: you command a different stall position and hope that the driven mechanics will follow, what they mostly do grumbling. Like moving a car with a hammer. One of the advantages of the chips used in this project is dynamical control of motor current to have exactly the torque needed what means: less power consumption and less oscillation. There are also chips doing the acceleration processing. I do not know, how it will work, but I'll find it out. And I will definitely not try to fit everything into one propeller, as working with parallel processes is not a paradigm, that ends at 8 processes and should not. In this community I miss solutions that have buildung blocks connected via a standardized protocol. My plan is to make a pcb that fits to a quickstart, has 3 stepper drivers and footprints for local propeller chips to distribute task. Every P1 chip used is a donation to have the P2, so why must we save chips?
Odd, I can't quote previous posts on my phone so this ifs a reply to the doubts as to whether all the steppers can be controlled with one cog.
Everyone else does it with a single threaded process so the idea of doing it with multitasking is actually the exception to the rule.
Doing it with no acceleration is trivial.
Doing it with basic acceleration takes more effort.
Marlin has some really snazzy functionality such as examining series of points and determining if it's an arc. If it determines yes, it uses its own calculations as opposed to the g-code provided. HUGE quality increase on curves.
Lastly, tinyg calculates not only velocity (feed rate) but acceleration (backlash prevention) but also rate of change of acceleration.
This additional treatment means my 3D printer at 200-300mm/s no longer tries to self destruct with vibration.
Unfortunately tinyg doesn't have 3D printer support.
Here it's our opportunity for ourselves and parallax.
If we could implement tinyg algorithms on a propeller based 3D printer board you would be AHEAD of the competition and not playing catch-up.
The question really is not whether all steppers can be controlled in one cog, but more along the lines if it is easier and faster to parallel process 4 steppers with 4 cogs. As far as being the exception to the rule, well in my opinion, tradition can often be a hindrance. Additionally, I have not learned PASM yet, so my solution will be SPIN.
Pertaining to TinyG, if they do not provide 3D printer support, why in the world would I want to use their algorithms? Sounds like I would be going BACKWARDS instead of getting AHEAD.
Comments
However I am still sticking with the master and slave protoboards as outlined. In the case of a 5 or 6 axis machine, especially those requiring heatsinks and fans for the stepper drives, please refer to the photo shown in post #25. The enclosure above the power supply is a 4 X 4 X 24 NEMA 1 enclosure, which houses both a master and slave proto board, (8) - G251X drives, as well as an lcd screen, piezo, numerous pushbuttons, (2) - DB9 connectors, and several rotary switches. Considering that the pushbuttons and rotary switches extended well into the enclosure, the available space was quite cramped. However at this point, I am now considering this option again, although there should not be a need for quite so many switches. For those that might be considering such a project, especailly those that need heatsinks and fans, I would suggest that you also consider this option, however a 6 X 6 X 24 would be much more accommodating.
I just placed an order with Parallax for the following items:
1 - Propeller Memory Card (http://www.parallax.com/product/40004) @ $17.99 = $17.99
1 - 2 GB Micro SD Card (http://www.parallax.com/product/32319) @ $7.99 = $7.99
1 - 8 Channel ADC (http://www.parallax.com/product/604-00062) @ $5.99 = $5.99
3 - G251X Stepper Drives (2 more required for my project, although I may rob one from another contraption)
4 - Applied Motion NEMA 17 Hi Torque Stepper Motors with dual shafts (3 - HT17-275D and 1 - HT-075D) (1 more HT17-275D required)
Various Molex SIP headers
Cable Chain (although I may not use it)
As indicated in the stepper selection, I have a NEMA 17 HT17-075D, this will be the motor that I will be using for the extruder, because for a NEMA 17, this baby is pretty darn strong, and I don't exactly know where I am placing the spool just yet, so I may need the extra torque for pulling the filament.
In the parent thread, I refered to my 3D printer project as "El Cheapo", when in fact, it is far from being cheap, at least electronics and motor wise. This baby will have 48VDC coursing through its viens when I am finished. Okay perhaps a bit of overkill, but hey you only go around once.
I will have to get off my keyster and start building soon. To be perfectly honest, I am looking forward to this new challenge.
LOL... Talk about a brain flatus... Even though I had a smiley, I would have been stressing and sweating over the missing parts until I got them.
Good thing that math was never my best subject.
Y Axis - 1 motor required +
Z Axis - 1 motor required +
E Axis - 1 motor required =
_______________________
Total 4 motors required *Gee, that is the total number of motors I have available - DUH
The primary focus of this thread pertains to a CNC/3D printer controller and the software needed to run it. Since it will probably be a little while before I actually get back to the controller or software, I am now going to shift my focus back to the primary thread, where I will be discussing the actual construction of the 3D printer. To keep abreast of the developments, please feel free to visit the parent thread (http://forums.parallax.com/showthread.php/154883-A-New-CNC-Build-3D-Printer-El-Cheapo) and poke around.
The parent thread has numerous pages of idle talk, however there is some good information buried deeply within that thread. Dependant upon the actual level of my ambition, the parent thread should now be taking a new turn and become much more serious. I will be discussing the construction of some critical components, as well as revealing my successes and/or failures.
I will return back to this thread, when I reach this stage of the build process.
My original scope was to get a 3D printer firmware implemented on one Propeller, possibly with an SD card reader. And Teacup is primarily a reference for what should be a useful library of G-code calls. I am going to wander away as that remains the scope of what I desire to achieve. If I can manage to port all the features that Teacup has to offer into one Propeller and achieve reasonable performance, I will be quite pleased. I am also comparing Teacup to GRBL to get how different authors structure the control of the stepper motors in coordinated movement with features of acceleration/deceleration and lookahead. GRBL has pretty good supplimental information.
On the other hand, you have your own work in progress of defining the scope of what you desire. Your approach is likely to be more feature rich.
I cannot seem to find the time to follow along with your various threads and get anything done with my own project. So I will just plod along with trying to create a Teacup-ette for one Propeller.
Later we can let others compare the results.
Yes, I have a nice vision, but it could end up being another total failure. There is still a lot of hard work and thought that must go into this project, and then I may still fail to succeed.
I have said all along that my primary goal is to test my actuators, however I truly want the project as a whole to succeed. Besides the actuators, there are still major obstacles in front of me concerning circuit design and software. Choosing an existing solution for circuit design and software would probably be the wise thing to do, but then we still do not have a solid Propeller CNC solution. My secondary goal is to outline a fairly versatile CNC controller, being hobbled together by various components and circuit boards, which can later be trimmed down to design an actual versatile CNC controller circuit board. To be perfectly honest, it would be nice to see a Propeller controller board, where you could simply plug in the proper amount of Pololu stepper drivers for your particular CNC equipment and upload the proper source code, and if the Pololu drivers do not supply enough amperage or voltage for a particular CNC project, then hardwire the appropriate drivers to the board..
To me, the software, is independent, because CNC machines vary, but there are some very basic requirements for the hardware. Considering all the possible variations of hardware and multi-axes CNC machines, it would be very difficult to satisfy all the software requirements, if not impossible, so my focus on software will strictly pertain to 3D printing, at least for this project.
Others have disagreed, but I believe that both you and I are both putting the cart before the horse with software issues. In my opinion, the Propeller controller should come first.
Hmmmm....
I would have to disagree. I know for a fact that I can receive a Proto Board in the mail and within an hour or two, with the proper stepper drivers in hand, I can have four stepper motors rotating simultaneously at different speeds, in either forward or reverse, and have them stop individually with the appropriate input. I do not know of anyone who can create a circuit board that fast to run four stepper motors, not including the 12 day turn around.
Additionally, to design a controller board of that magnitude, a person would have to have a very high level of skill in circuit design and board layout, which would eliminate a high percentage of forum members as well as visitors.
I trying not to get caught up in long discussions of pro and con.
My own feelings are that having your board ready to go and being supported by Mach 3 may be an excellent alternative for 3D printing on the Propeller. It certain seems an easier, less steep learning curve as an entry point. And there is plenty to learn with 3D printing.
My point of entry was simply a rather naive choice based on knowing next to nothing, and desiring to not have to commit to purchasing any software. But building up 'sweat equity' is rather steep in approaching it my way. I just have plenty of time and no real need to rush an actual printer into operation.
This order was not supposed to arrive for another two days. Sometime the US Postal Service can be quite effective.
Anyhow there is nothing quite like the look of a brand new Proto Board to spark my interest, and now I have twins
As for the Propeller Memory board, there is really not much to it, but as usual, the quality of this Parallax board is outstanding. I am almost half-tempted to break out the Propeller BOE and toy with this board a little.
As previously mentioned, I want the slave proto board to run the machine, so this board would control any extruder. To control the extruder appropriately, I need to know the temperature of the hot end, at any given point in time. To obtain this temperature, I will be using a thermistor, which will be attached to the hot end, and to retrieve the temperature for the Propeller, I will be using a MCP3208 ADC. It only stands to reason that since the thermistor is part of the machine, the ADC should be mounted to the slave proto board. However, before I get too carried away with soldering the ADC to the slave, I at least want to have a fair idea of what pins and cogs will be necessary for the slave to control the machine.
I already know that I will get some grief for this list, because some of the items may be combined and switches may or may not be needed. It is my intent to atempt to foresee every possible oversight regarding IO pin assignments, so this list may or may not be accurate, but it does account for some items that probably won't be utilized by me or this machine. Anyhow here is a list of required pins for a single extruder 3D printer:
- X_AXIS_STEP (IO pin required)
- X_AXIS_DIRECTION (IO pin required)
- X_AXIS_DISABLE (IO pin required)
- X_AXIS_HOME_SENSOR (IO pin required)
- X_AXIS_OVER_TRAVEL_SENSOR (IO pin required)
- Y_AXIS_STEP (IO pin required)
- Y_AXIS_DIRECTION (IO pin required)
- Y_AXIS_DISABLE (IO pin required)
- Y_AXIS_HOME_SENSOR (IO pin required)
- Y_AXIS_OVER_TRAVEL_SENSOR (IO pin required)
- Z_AXIS_STEP (IO pin required)
- Z_AXIS_DIRECTION (IO pin required)
- Z_AXIS_DISABLE (IO pin required)
- Z_AXIS_HOME_SENSOR (IO pin required)
- Z_AXIS_OVER_TRAVEL_SENSOR (IO pin required)
- EXTRUDER_STEP (IO pin required)
- EXTRUDER_DIRECTION (IO pin required)
- EXTRUDER_DISABLE (IO pin required)
- EXTRUDER_HEATER (IO pin required)
- EXTRUDER_THERMISTOR (ADC channel)
- FUTURE EXTRUDER_AUX_CORE_FAN (Possible IO pin required)
- FUTURE EXTRUDER_HOT_END_FAN (Possible IO pin required)
- TABLE_HEATER (IO pin required)
- TABLE_THERMISTOR (ADC channel)
- ADC_MCP3208_CS (IO pin required)
- ADC_MCP3208_CLK (IO pin required)
- ADC_MCP3208_DATA_IN/ADC_MCP3208_DATA_OUT (IO pin required)
- FDS_RX_FROM_MASTER (IO pin required)
- FDS_TX_TO_MASTER (IO pin required)
According to this list, I will need the following:- 25 IO pins
- 2 Possible future IO pins for cooling fans
- 2 ADC channels
Alright, so now we are ready to start figuring out the necessary cogs. Once again, I want to make sure that I have plenty of resources to accurately run the machine. With this in mind, I will dedicate a cog to each stepper motor utilized, the ADC will have a cog of it's own, full duplex serial requires a cog, and I believe the main program should have a cog, which totals 7 cogs. To maintain the arrangement of this post, here is a list of the required cogs:- Cog 0 - Main program
- Cog 1 - Full duplex serial
- Cog 2 - X axis
- Cog 3 - Y axis
- Cog 4 - Z axis
- Cog 5 - Extruder
- Cog 6 - ADC, thermistors, and heaters (monitor and control)
At first glance, with a little rearrangement of the pins required for home and over travel sensors, the slave board should be able to easily adopt and carry the burden of a second extruder. Perhaps the use of all these cogs is a bit of overkill, but at least I know they are there if I need them. Besides, it all looks pretty good to me at this point.It is now time to figure out just exactly where I want to place the ADC on the slave proto board.
And since the Z axis is only called into play when a new slice is to be added, you might as well have the X, Y, and Z all on the same cog.
That leaves the question of whether there is any advantage to the E stepper that feeds the filament having a separate cog. I doubt there is any advantage. It needs to be in synch with just about everything.
My gut feeling is that this all would best be done in PASM and signed integer maths. The Arduinos seem to blithely use floating point that can increase code overhead and slow down speed.
I would have a special cog for an output buffer than would include the printer head accelleration/deceleration. Not yet sure where to put the 'look ahead' feature that some code tries to use.
I have also running into some CNC setups that not only have minimum and maximum limit switches. They have sensors for a home position as well. This could be the 0,0 for starting printing, or it could just be the center of the printer bed that is easier to search for without banging your machine out of calibration by hitting extremes. The sensors are hall-effect.
Of course that would need another 3 i/o pins, but I do like the idea of seeking a starting position in the middle. And then moving off of it in any direction you choose to begin to print. It would be extremely easy to add a line in G-code to do this if your slicer software doesn't provide the code.
Surely, you must be joking.
All the drives must be sychronized for interpolation. How could you do it efficiently all in one cog? I don't even begin to see that as the least bit possible, okay maybe possible. Each stepper motor will have different timing that must remain in sync with the other motors to make the completed move at the same time. Each motor will likely have different amount of steps that it must make, etc...
It most certainly is a multi-thread proposition, at least to be efficient.
If you did attempt it with one cog it would be so slow, because you would have to tell one motor to take a step and make all the other wait their turn. Each motor would have to take a step then wait until it was it's turn again.
EDIT: Certainly not a task for the BASIC STAMP
Initially I considered having separate cogs for X, Y, Z, and E; but the interpolation seems to snag that scheme. X and Y have to derive a coordinated series of steps for every entry of G-1 codes. How fine the steps are is dictated by configuration issues of [a] the mechanics involved, and the selection of a particular micro-stepping. These configuration parameters spill over into determining how large an output buffer must be.
I am a bit concerned that the buffering may bog down everything. Either the buffer is all in hub ram or a dedicated cog that gets the X, Y, Z, and E parameters passed to it.
What you propose seems to me that 4 cogs will handle the output buffering for an individual stepper. That would limit the buffer size to remaining cog ram, unless something creative was done (such as having 32 bit longs store a series of 32 bits of step sequence and use shifting to stream STEP bits out).
How do you propose to coordinate 4 output buffers?
I don't have an exact answer just yet, but it will be something like this:
OBJ X_Axis : "StepperDriver" Y_Axis : "StepperDriver" Z_Axis : "StepperDriver" Extruder : "StepperDriver" PUB Main X_Axis.Start( ) '''New cog started''' Y_Axis.Start( ) '''New cog started''' Z_Axis.Start( ) '''New cog started''' Extruder.Start( ) '''New cog started''' ''' Miscellaneous code for full duplex serial initialization and code for retrieving data from the master.''' ''' Data is held in variables to be passed to the stepper drivers.''' ''' At this point, I forget exactly how cog sync is done, but I have that information stored somewhere. Anyhow''' ''' I believe it goes something like this.''' ''' 1. Obtain CNT ''' 2. Add time to CNT to make a point in the future and store the result in a variable, such as "ExecutionBegin".''' ''' 3. After getting a future time, necessary for syncronizing several cogs, pass all the data to the stepper drivers.''' X_Axis.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps) Y_Axis.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps) Z_Axis.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps) Extruder.Move(ExecutionBegin, NoOfSteps, DirectionOfRotation, PauseBetweenSteps) ''' The first instruction of the Move method of the StepperDriver object would have a WAITCNT instruction, where the''' ''' future time of "ExecutionBegin" would be inserted. ''' I believe it is something very similar to that.'''Of course, this is just a simple example and does not account for ramping of the stepper motors, but I believe you will get the idea.
The master protoboard is only required in situations where the CNC machine or 3D printer is not directly attached to a PC. In situations where a PC is utilized, the PC becomes the master.
Referring to Post #41, there should be plenty of resources available, with the slave directly connected to the PC. The PC would contain a program that interprets G-code commands, stores data, and sends serial information for machine control to the slave. I like this plan because it eliminates one proto board and the Propeller Memory Board, and I am sure it will be much faster.
Though I started with the Arduino C code examples, they are a bit frustrating. Nonetheless, my impression is that the G-1 commands are pretty well tied to one task that needs to be fully coordinated between X, Y, Z, and E. Each line of G-1 is a complete packet.
Breaking out into parallel codes for X, Y, Z, and E control may seem ideal, but that is 4 cogs tied up.
I suspect that if speed is essential, less cogs might be made to perform better.
If the throughput of one G1 processing cog was too slow, the exact same code could be loaded into two cogs that alternate taking on the task. The output would process in half the time. If it is still too slow, a third cog could be called into play and fed in rotation. This would cut the processing time to 1/3, but have the complete coordination of calculations done by one CPU in each case. You may never need to tie up that 4th cog.
This isn't pure 'parallel processing', but better be described as a Gattling Gun approach to parallel processing.
I hate the idea of have the X and Y axis cogs slogging away slowly while the Z cog is not called 95% of the time and the E cog spends most of its time waiting for the X and Y to get finished. If any division by motor is warrentted, it may be to clump the XYZ together and have the E separate. The E cog could alternative between feeding and monitoring the print head temperature status.
You do have to have a cog doing SPI interface for the MCP3208 that is your ADC. Some of your pin allocations seem to have forgotten that you have 8 ADC inputs available. If you are only using two for temperature monitoring, the other six could actually monitor limit switches on the 3 axes.
++++++++++++++++
I won't bother to go into my learning curve gripes with porting Aduino 3D printer code to the Propeller, but I haven't given up trying to produce something.
I have learned a lot ... especially about 'What is C++, and Arduino code, compared to C?'
I was naive as I thought that I could just limit my learning to ANSI standard C, circa 1989.
While the comparison is a topic that I did want to learn, I must say there are some interesting and annoying suprises. Mostly in the weird distortion that Arduino users seem to think of as Arduino code as being just C.
Arduino code is really written in C++ and you can't add new libraries without being adept in C++, but the average user is buffered in such a way as they tend to write C code without realizing it is being used in a C++ compile environment. All this is nicely hidden by the Arduino IDE which is written in Java.
In sum, the average Arduino user has no idea what is real C or C++. And I am still learning how to unsnarl all that.
And then there is the reality that C was written for computers in the days where they really were 'business machines' or 'university research publication managers'. So 'Floating point' and 'String manipulation' are a main focus. Input and Output are not offically any part of C... that is for the libraries to provide.
For a CNC g-code parser, all that is pretty much distraction. I am absolutely sure that on the Propeller, this could be better coded in PASM for optimal performance.
That is a brilliant idea!!!! Thanks for that one Loopy!!!! That opens the door for another extruder or axis.
I do not think I agree with you on the cogs though. They are there, so why not use them for parallel processing, instead of letting them sit idle?
I am now convinced that the solution is this:
- PCB with one Propeller and one MCP3208 (should provide 4-5 axis support)
- PC software which contains a G-code interpreter and provides serial communication to the PCB (maybe Mach 3 can be a direct connection, I will have to research this)
I believes this handles all problems associated with IO pins and cogs, and I believe this will be the fastest possible resolution. Additionally, it would be a Propeller solution.Hmmmmm.....
For me, it has been slow going because I needed some reference code to start with and that all seemed written for the AVR chips in C or Arduinio's version of C++. But at least I now understand the building blocks that are required. But it seems that the Propeller will make deployment of the same features a bit different.
I still can't see how to really use GCC to get individual cogs to do what I want. It all feels as though I am programing for an emulation of a single CPU device and with the LMM adding a bit of a slow down to the Propeller. So a direct port of Arduino code into the GCC quickly becomes a loosing battle.
I have just focused on trying to make Tonokip_with_Serial work as an exercise to teach me to see everything I need to know about reading C or C++. I do admit that I am a slow learner with it... tried to ignore reading Arduino documents and C++ documents for a long time.
Yes, one thing I have learned over the years, is that ideas evolve, and the first solution, usually is not the best solution. My plans are always changing, first I have a concept, then I try to make it better or more efficient.
Between my epiphany and your brilliant idea, we have made leaps of progress today. Now if only I could convince you that the Teacup firmware needs to be ported to PC software, we would be on our way to a real nice Propeller solution for 3D printing. And with a few other tweaks, perhaps the PC software could run a CNC router with the same board.
I would be interested on working towards this solution with you. As a plus, you would receive a lot more help and support, because my heart would be in it, and I am heading in that direction. I could benefit from your knowledge and you could benefit from mine. If you have an old PC around, that has WIN 98 to WIN XP, then I have Microsoft Visual C++ 6.0 Standard Edition that I would let you have. Back in the day, this was high quality software for developing C/C++ programs. Believe me, it will blow your doors off. I have similar software that I use, only it is the Professional Edition. Either way, we could share files that would be compatible, and quickly develop a software solution. Besides newer editions of Visual Studio, you will not find better software for developing C/C++ programs.
Just think about it.
As I see it, there are 14 files of the utmost importance, when going the route that I suggest. 13 of these files would be ported to the PC serial software and 1 file would be ported to the Propeller. Here is a breakdown of the files that I deem necessary, for the route I suggest:
dda.c
dda.h
dda_lookahead.c
dda_lookahead.h
dda_maths.c
dda_maths.h
dda_queue.c
dda_queue.h
gcode_parse.c
gcode_parse.h
gcode_process.c
gcode_process.h
Besides porting the software, the biggest trouble that remains is sending the information to the Propeller in a timely fashion and in a manner that the Propeller can decipher the information received. Communication between the PC and the Propeller is no serious issue, because Full Duplex Serial and the PC software already take care of these matters. From the PC, the Propeller will receive simple commands (simple g-code commands) and complicated commands (complex g-codes, such as G1), although the Propeller will not be expected to interpret g-code commands, because that will be the job of the PC. As previously stated, the PC will be in charge of interpreting g-code and perfoming all the necessary math to achieve coordinated movement, except ramping. As an example, to achieve coordinated movement for a G1, without ramping, the PC would serially send the following information to the Propeller:
X - Direction of rotation
X - Pause between steps
Y - Direction of rotation
Y - Pause between steps
Z - Direction of rotation
Z - Pause between steps
Extruder - Direction of rotation
Extruder - Pause between steps
As mentioned, this is a simple example, and does not include ramping of the stepper motors. Ramping would make it much more complicated, but ramping is definitely a necessity, so this will have to be figured out at a later time, once the simple stuff is complete. As I see it, ramping will have to be computed by the Propeller, after receiving the general G1 parameters from the PC, however I could be wrong, and perhaps ramping could and should be computed by the PC.
I am assuming this comment was intended for me, if it was, I have already come to the conclusion that it can be handled by one chip when connected to a PC, but if not connected to a PC, then I believe there will be a need for a second chip, because you still need a machine interface of some sort, and that will require a fair amount of resources.
Everyone else does it with a single threaded process so the idea of doing it with multitasking is actually the exception to the rule.
Doing it with no acceleration is trivial.
Doing it with basic acceleration takes more effort.
Marlin has some really snazzy functionality such as examining series of points and determining if it's an arc. If it determines yes, it uses its own calculations as opposed to the g-code provided. HUGE quality increase on curves.
Lastly, tinyg calculates not only velocity (feed rate) but acceleration (backlash prevention) but also rate of change of acceleration.
This additional treatment means my 3D printer at 200-300mm/s no longer tries to self destruct with vibration.
Unfortunately tinyg doesn't have 3D printer support.
Here it's our opportunity for ourselves and parallax.
If we could implement tinyg algorithms on a propeller based 3D printer board you would be AHEAD of the competition and not playing catch-up.
The question really is not whether all steppers can be controlled in one cog, but more along the lines if it is easier and faster to parallel process 4 steppers with 4 cogs. As far as being the exception to the rule, well in my opinion, tradition can often be a hindrance. Additionally, I have not learned PASM yet, so my solution will be SPIN.
Pertaining to TinyG, if they do not provide 3D printer support, why in the world would I want to use their algorithms? Sounds like I would be going BACKWARDS instead of getting AHEAD.