As previously mentioned, my particular machine will rely upon SD card access for obtaining the necessary GCODE. So for the past couple of weeks, I have been working on the necessary code, for navigating an SD card file and directory structure, through the use of several pushbuttons and an LCD display. For those that may be interested, you can find the details of that effort at this location: http://forums.parallax.com/showthread.php/160923-C-SimpleIDE...-Directory-Listing-of-SD-Card-Files
To be perfectly honest, I was a little worried about getting that code to fit on the parsing Propeller chip. I am happy to announce
IT FIT!!!
Not only did it fit, but it fit without trimming any code, and I have still have some memory to spare. And eventually, this added code will be conditionally compiled, so there will be the possibilty of much more memory available.
As it stands now, I still need to provide conditional compiling support, for a serial interface to supply GCODE. Additionally, I also need to modify the parsing Propeller board and the processing Propeller board, one more time, in an attempt to allow both boards to access the LCD display. For more information about this endeavor, visit this link: http://forums.parallax.com/showthread.php/160825-What-Are-My-Options-Of-Two-Props-Outputting-To-The-Same-Display
In the near future, I will be uploading the updated source code for the parsing Propeller.
Additionally, I also need to modify the parsing Propeller board and the processing Propeller board, one more time, in an attempt to allow both boards to access the LCD display.
Even though Parallax no longer sells the Proto Board, I am updating my documentation, to show the most recent modifications to the controller board, and I do believe this is an accurate representation of the controller board in its current state. I still need to update and upload an illustration for the parser board.
EDIT: I should note that this illustration does not depict the transistors necessary for grounding the disable pins on the G251X Gecko stepper drivers. There are (4) - 2N3904 transistors on the actual board, which are not shown in the illustration.
With the modifications on the parser and processor boards now complete, I worked on the parser code for a while.
Although not tested, because I have a couple of more things to figure out, I believe the parser code is now somewhere between 99.0 and 99.5% finished. Since my last upload, I have added a few more defines, a couple more functions, and reorganized a bit of code. The additions were made to accommodate provisions for serial GCODE input and I think the parser code should now be able to handle input from either an SD card or from a serial interface, based upon two defines within config.h, which are: USE_SD_GCODE and USE_SER_GCODE. At this point in time, it is either one or the other, however, I may later add support to select input at runtime.
Anyhow, here is the latest update to the code for the parser chip. As time permits, I will now be working on the code for the processor chip.
EDIT: With the SD card access code and a fair amount of calculations being performed by the parser chip, I believe a fair amount of GCODE commands can now be supported by the processor chip. As mentioned previously within this thread, I decided to move the actual movement code to the processor chip, so that a variety of movement schemes could be attempted. For the moment, I am content moving forward with my current movement scheme, but I believe I may have run out of cogs, and I may have to choose a different scheme.
Before diving deep into the code for the processor Propeller, I just wanted to share a few thoughts, and perhaps get an idea or two from interested parties.
As mentioned in the previous post, I believe I have already run out of cogs on the processing chip, and I haven't done any serious programming for this chip yet Oh well, one step at a time, in baby steps. I am going to begin this discussion with the main, the queue, and futher computational code for movement. I am basically shooting from the hip at this point, so please bear with me, because my ideas are evolving.
For the newcomers, allow me to set the scene.
There are now two Propellers, a parsing Propeller and a processing Propeller. The parsing Propeller basically handles user input, it has the ability of accepting GCODE from an SD card or serially, it turns the received GCODE into numeric form, it performs a few initial computations on the received GCODE, it store the GCODE data in a GCODE_STRUCT, and it sends GCODE_STRUCT(s) to the processing Propeller.
The processing Propeller accepts GCODE_STRUCT(s) and performs additional computations, it maintains a movement and command queue, it monitors limit and homing switches, and it is responsible for machine movement.
Alright, so the main begins by initializing important variables and cogs. As it stands now, and as it should be, I believe this should be command central, which includes, examining and executing commands held within the queue.
It was my intention, to have a seperate cog receive GCODE_STRUCT(s) from the parsing Propeller and immediately add them to a queue for further processing, however I am now beginning to think that this is a bad strategy, especially since further computations must be made. My current line of thinking is to perform the necessary computaions immediately, upon reception, before adding them to the queue. Furthermore, I am now thinking of adding another struct, such as COMMAND_STRUCT, which will hold all the data after the additonal computations have been made, and it is this struct, that should be added to the queue.
I suppose this should all be fairly easy to accomplish, BUT the additional computation code, will most likely have a big impact on the COMMAND_STRUCT, or perhaps not. Much of this will depend on the movement code itself. As I see it, the movement code has now become the most crucial section of remaining code. In addition to a basic movement scheme, I also believe that the movement code should include LOOKAHEAD for 3D printing applications.
As it stands now, I believe I could have functional firmware in a short period of time, by combining a cog or two, eliminating motor ramping, and by not offering LOOKAHEAD support, however I believe motor ramping and LOOKAHEAD support should be mandatory.
Anyhow, like I said, I am just sharing a few thoughts. Please feel free to share your constructive thoughts and/or ideas.
With the exception of the motion control code, I believe I now have a workable design for a CNC controller, which should be able to support several or numerous G and M commands, and one that will satisfy my needs and desires for a controller. I also believe that the firmware is now heading in the right direction. To me, I suppose this was the biggest challenge facing a Propeller controller.
As I was drinking my early morning coffee, and researching motion control schemes, I came to the conclusion that I should now set aside some time to finish up the remaining hardware, before proceeding on the firmware. I still need to complete the Z axis, the heated build platform, and several other items, before I can perform any actual testing, of any firmware that I may create.
My failed attempt at porting the Teacup firmware, set me back a month or two, and changing over to a two Propeller design, set me back even further. I was hoping that all firmware and electronic issues would have been resolved by winters end, but that was simply not the case. Anyhow, my work environment is now warm and comfortable enough to proceed and finish the remaining hardware issues, and I believe that is exactly what I should start doing. Additionally, I have other fences that need mending, so progress with this project may be a little slow going for a while.
I am not abandoning this thread, just reorganizing my priorities a little. I will keep you posted as progress occurs, or as discussion warrants.
Comments
To be perfectly honest, I was a little worried about getting that code to fit on the parsing Propeller chip. I am happy to announce
IT FIT!!!
Not only did it fit, but it fit without trimming any code, and I have still have some memory to spare. And eventually, this added code will be conditionally compiled, so there will be the possibilty of much more memory available.
As it stands now, I still need to provide conditional compiling support, for a serial interface to supply GCODE. Additionally, I also need to modify the parsing Propeller board and the processing Propeller board, one more time, in an attempt to allow both boards to access the LCD display. For more information about this endeavor, visit this link: http://forums.parallax.com/showthread.php/160825-What-Are-My-Options-Of-Two-Props-Outputting-To-The-Same-Display
In the near future, I will be uploading the updated source code for the parsing Propeller.
Even though Parallax no longer sells the Proto Board, I am updating my documentation, to show the most recent modifications to the controller board, and I do believe this is an accurate representation of the controller board in its current state. I still need to update and upload an illustration for the parser board.
EDIT: I should note that this illustration does not depict the transistors necessary for grounding the disable pins on the G251X Gecko stepper drivers. There are (4) - 2N3904 transistors on the actual board, which are not shown in the illustration.
I certainly hope these latest changes will be the last changes to these two boards.
Although not tested, because I have a couple of more things to figure out, I believe the parser code is now somewhere between 99.0 and 99.5% finished. Since my last upload, I have added a few more defines, a couple more functions, and reorganized a bit of code. The additions were made to accommodate provisions for serial GCODE input and I think the parser code should now be able to handle input from either an SD card or from a serial interface, based upon two defines within config.h, which are: USE_SD_GCODE and USE_SER_GCODE. At this point in time, it is either one or the other, however, I may later add support to select input at runtime.
Anyhow, here is the latest update to the code for the parser chip. As time permits, I will now be working on the code for the processor chip.
EDIT: With the SD card access code and a fair amount of calculations being performed by the parser chip, I believe a fair amount of GCODE commands can now be supported by the processor chip. As mentioned previously within this thread, I decided to move the actual movement code to the processor chip, so that a variety of movement schemes could be attempted. For the moment, I am content moving forward with my current movement scheme, but I believe I may have run out of cogs, and I may have to choose a different scheme.
As mentioned in the previous post, I believe I have already run out of cogs on the processing chip, and I haven't done any serious programming for this chip yet
For the newcomers, allow me to set the scene.
There are now two Propellers, a parsing Propeller and a processing Propeller. The parsing Propeller basically handles user input, it has the ability of accepting GCODE from an SD card or serially, it turns the received GCODE into numeric form, it performs a few initial computations on the received GCODE, it store the GCODE data in a GCODE_STRUCT, and it sends GCODE_STRUCT(s) to the processing Propeller.
The processing Propeller accepts GCODE_STRUCT(s) and performs additional computations, it maintains a movement and command queue, it monitors limit and homing switches, and it is responsible for machine movement.
Alright, so the main begins by initializing important variables and cogs. As it stands now, and as it should be, I believe this should be command central, which includes, examining and executing commands held within the queue.
It was my intention, to have a seperate cog receive GCODE_STRUCT(s) from the parsing Propeller and immediately add them to a queue for further processing, however I am now beginning to think that this is a bad strategy, especially since further computations must be made. My current line of thinking is to perform the necessary computaions immediately, upon reception, before adding them to the queue. Furthermore, I am now thinking of adding another struct, such as COMMAND_STRUCT, which will hold all the data after the additonal computations have been made, and it is this struct, that should be added to the queue.
I suppose this should all be fairly easy to accomplish, BUT the additional computation code, will most likely have a big impact on the COMMAND_STRUCT, or perhaps not. Much of this will depend on the movement code itself. As I see it, the movement code has now become the most crucial section of remaining code. In addition to a basic movement scheme, I also believe that the movement code should include LOOKAHEAD for 3D printing applications.
As it stands now, I believe I could have functional firmware in a short period of time, by combining a cog or two, eliminating motor ramping, and by not offering LOOKAHEAD support, however I believe motor ramping and LOOKAHEAD support should be mandatory.
Anyhow, like I said, I am just sharing a few thoughts. Please feel free to share your constructive thoughts and/or ideas.
As I was drinking my early morning coffee, and researching motion control schemes, I came to the conclusion that I should now set aside some time to finish up the remaining hardware, before proceeding on the firmware. I still need to complete the Z axis, the heated build platform, and several other items, before I can perform any actual testing, of any firmware that I may create.
My failed attempt at porting the Teacup firmware, set me back a month or two, and changing over to a two Propeller design, set me back even further. I was hoping that all firmware and electronic issues would have been resolved by winters end, but that was simply not the case. Anyhow, my work environment is now warm and comfortable enough to proceed and finish the remaining hardware issues, and I believe that is exactly what I should start doing. Additionally, I have other fences that need mending, so progress with this project may be a little slow going for a while.
I am not abandoning this thread, just reorganizing my priorities a little. I will keep you posted as progress occurs, or as discussion warrants.