Although the queue is not 100% completely finished, it is pretty darn close, so I figured I would post what I have for commentary, just in case I may be overlooking something.
queue.c
#include <stdbool.h>
#include "simpletools.h"
#include "fdserial.h"
#include "queue.h"
#include "gcode_struct.h"
// cog variables
static int queue_cog = 0;
static int queue_stack[60]; // stack size will need increasing
static int queue_head = -1;
static int queue_tail = -1;
static GCODE_STRUCT queue_array[QUEUE_SIZE];
static GCODE_STRUCT received_struct;
static char received_struct_array[sizeof(GCODE_STRUCT)];
static bool update_current_gcode = false;
// declare volatiles
volatile GCODE_STRUCT current_gcode;
// declare the queue_receive cog function
void queue_receive(void *par);
// start the queue
void queue_init()
{
if(queue_cog == 0)
{
queue_cog = 1 + cogstart(&queue_receive, NULL,
queue_stack, sizeof queue_stack);
}
}
// stop the queue
void queue_stop()
{
if(queue_cog > 0)
{
cogstop(queue_cog - 1);
queue_cog = 0;
}
}
// serially receive queue items in seperate cog
void queue_receive(void *par)
{
uint32_t index;
fdserial *processor;
char Char;
bool bEndOfStruct;
processor = fdserial_open(2, 0, 0, 230400);
do
{
// proceed the struct with a '<' for STX
// STX = start of text
// STX can be anything that will not be included in your data
// STX must be the same on the transmitting end
if(fdserial_rxTime(processor, 500) == '<')
{
index = 0;
bEndOfStruct = false;
memset((void*)&received_struct, 0, sizeof(GCODE_STRUCT));
memset((void*)received_struct_array, 0, sizeof(GCODE_STRUCT));
while(bEndOfStruct == false)
{
Char = fdserial_rxTime(processor, 500);
// follow the struct with a '>' for ETX
// ETX = end of text
// ETX can be anything that will not be included in your data
// ETX must be the same on the transmitting end
if(Char != '>')
{
received_struct_array[index] = Char;
index++;
}
else
{
bEndOfStruct = true;
}
}
memcpy((void*)&received_struct, (void*)&received_struct_array, sizeof(GCODE_STRUCT));
queue_add_struct(received_struct);
}
}
while(queue_cog > 0);
}
// empty the queue, emergency stop.
void queue_flush()
{
queue_head = queue_tail = -1;
}
// add a struct to the queue
bool queue_add_struct(GCODE_STRUCT strct)
{
// check if the queue is full
if(is_queue_full())
{
// replace return with loop and waitcnt
return false;
}
// increment queue_tail index
queue_tail++;
// add struct to the queue
queue_array[queue_tail % QUEUE_SIZE] = strct;
return true;
}
// pop a struct off of the queue
void queue_pop_struct()
{
GCODE_STRUCT strct;
// check if the queue is empty
if(is_queue_empty())
{
// clear the current_gcode struct
memset((void*)¤t_gcode, 0, sizeof(GCODE_STRUCT));
}
else
{
// increment queue_head index
queue_head++;
// fill the current_gcode struct
current_gcode = queue_array[queue_head % QUEUE_SIZE];
}
}
// is the queue completely empty
bool is_queue_empty()
{
return (queue_head == queue_tail);
}
// is the queue completely full
bool is_queue_full()
{
return ((queue_tail - QUEUE_SIZE) == queue_head);
}
// wait for the queue to empty
void queue_wait_for_empty()
{
while(is_queue_empty() == false)
{
}
}
// update the current_gcode struct
void update_current_gcode_struct()
{
update_current_gcode = true;
}
queue.h
#ifndef _QUEUE_H
#define _QUEUE_H
#include <stdbool.h>
#include "gcode_struct.h"
// define maximum size of the queue
#define QUEUE_SIZE 8
// declare external volatiles
extern volatile GCODE_STRUCT current_gcode;
// start the queue
void queue_init();
// stop the queue
void queue_stop();
// empty the queue, emergency stop.
void queue_flush();
// add a struct to the queue
bool queue_add_struct(GCODE_STRUCT strct);
// pop a struct off of the queue
void queue_pop_struct();
// is the queue completely empty
bool is_queue_empty();
// is the queue completely full
bool is_queue_full();
// wait for the queue to empty
void queue_wait_for_empty();
// update the current_gcode struct
void update_current_gcode_struct();
#endif /* _QUEUE_H */
There is no real advantage to adding 1 to the cog id returned by cogstart. You can just store it directly and use ">= 0" as your test instead of just "> 0". This adding one is a holdover from how it is typically done in Spin programs and only tends to obscure what is going on.
As I work on this project and try to get a better vision of it working the way I want it to work, I keep seeing the need for more data in the GCODE_STRUCT, which will be passed from the parsing Propeller to the processing Propeller. As it stands now, I have added two additional members to the GCODE_STRUCT, which are char previous_fileline[100] and uint32_t valid_fileline_counter.
char previous_fileline[100] was added to make it easier to establish the current location or just as a holder for the last command issued. This member will most likely be utilized to simply display the current location on an LCD display or a display terminal, in combination with the current_fileline member, which will represent the target location. Considering that the queue utilizes full duplex serial, the forementioned members could be fed back to the parsing Propeller, if a more elaborate terminal were set up for that Propeller chip.
uint32_t valid_fileline_counter was added as an error checker, to help ensure that a command was not missed and I am certain that it will come in handy for other uses on the processing Propeller. So the GCODE_STRUCT now looks like the following:
There is no real advantage to adding 1 to the cog id returned by cogstart. You can just store it directly and use ">= 0" as your test instead of just "> 0". This adding one is a holdover from how it is typically done in Spin programs and only tends to obscure what is going on.
Thanks for the heads up on that, I appreciate it. Now if I can only remember that later, because there are several files that will need to be changed, and I am not up to it now.
When a person begins thinking outside of the box, they must also consider the ramifications, and such is the case with this project.
As many of you know, I hop around quite a bit, because I get bored easily, while performing tedious and mundane tasks. For my latest round of effort on this project, I did not feel like soldering or finishing up the processing queue, so I decided to start preparing some of the processor code. As I was working on this code, I came to the realization that I had overlooked quite a few serious ramifications, by thinking outside the box. For instance, there are consequences to seperating the parser and the processor, such as all measurement calculations must be performed by the parser, not just some. Example given, will the coordinates be relative or absolute... Are distances measured in inches or millimeters... While working on the parser, I briefly thought about this, and I figured my main goal would be to achieve absolute positioning measured in millimeters, but now, after working on the processor, I realize that the parser neeeds a bit more work on the code to support relative positioning and inch measurement. On the surface, I suppose this appears to be no big deal, especially if you are creating your own GCODE, however, when using someone elses GCODE, this could be a major issue. Considering that I do not want to write or alter GCODE for every item that I want to create, I will now have to modifying the existing parser code to support relative positioning and inch measurement. Adding inch measurement support really should not be that big of a deal, but I am really uncertain how relative positioning support will affect the current code base.
Additionally, there are also ramifications pertaining to stepper motor control, that must be taken into consideration on both the parser and the processor end of things. Such as the speed when homing and searching for limit switches, etc... Beyond any doubt, the stepper driver and parsing code, will need quite a bit of modification.
Just sharing thoughts..... One baby step at a time
I finally got up enough ambition to go ahead and finish the modifications on the controller board, While working on the modifications, I deviated a little from the plan laid out in Post #75, which I may update later. I must say that the modifications came out looking much better than I had anticipated. Honestly, I thought the board would look like trash afterwards, but you can hardly tell that any serious repairs had been made. The controller still looks a lot like the pic shown in Post #3, but there are now some major differences, such as additional support for five more switches, provisions for full duplex serial communication with another propeller, and a couple of spare IO pins.
With that board now out of the way, soldering up the primary board should be a cake walk. Several headers here and there, a little wire, and perhaps about ten resistors, and that board should be ready also.
I am beginning to have a positive outlook once again Pretty soon, I will be working hard on the firmware, trying to make it functional
As always, I like to draw up a generalized plan of my intentions, so before starting on the parser board, that is exactly what I have done. In the illustration below, you will will see a generalized layout of the parser board.
As I was reorganizing some of the firmware this morning, I had a thought, and I believe it was a good one.
First off, let me state for the record, that I believe the dual Prop setup is the ticket, because it gives me everything I want for a controller, plus I have left over IO for both boards, for any expansion that I may need to do. I further believe that splitting the parser and the processor, and sending a GCODE_STRUCT between the two Propellers, is also a good idea. However, I also believe that I may be approaching this incorrectly. Since I freely admit, that running four seperate cogs, for four seperate steppers, may or may not work, or may not be easy to achieve, therefore a definite possibility of failure exists. As I see it, the one thing that is actually limiting my possibility of ultimate success, is the passing of too much stepper information in the GCODE_STRUCT. While I believe it is beneficial to calculate the stepper direction and the number of steps needed, on the parsing Propeller, I now believe that all stepper speed calculations, should be performed by the processing Propeller. By moving the speed calculations to the processing Propeller, a variety of stepper control theories can be applied, as long as the control code and calculations fit within the available memory, of the processing Propeller.
To sum it up, I now believe the GCODE_STRUCT should be changed once again, as follows:
I apologize for wearing the subject of the GCODE_STRUCT a little thin, but as I work on the code and since I now have two boards, I am starting to see things a little differently, so I am coding it differently. And since the GCODE_STRUCT is of the utmost importance to this project, I want to make sure that everyone understands.
As briefly mentioned earlier in this thread, the "travel" information for the various axes was included in the struct for calculation purposes only and it really is of little use afterwards. So instead of having it in the struct and transmitting it to the processing Propeller, I rewrote portions of a function, to make these variables local to that function, hence they are no longer needed in the struct.
Additionally, during the parsing process, I was storing text based characters within the struct to represent the various GCODE fields. Once these characters have been turned into numeric format, these characters are also no longer needed, so I have removed them also, and added them locally to a function.
Alright.... I just have to ask..... What is a focus sheet? And does it have zoom capabilities?
Very primitive drawing outlining what it is I'm trying to do. And after I complete each section, I take a photo of it and put the graphics inside the focus sheet to indicate that part is finished. Very soon, the sheet is all filled up with graphics. And there is nothing left to do.
Unfortunately, I cannot upload any of my focus sheets to the forum. Parallax has some sort of size limit, that restricts me from uploading what I use.
So, I'm forced to slice and dice and upload small sections of my focus sheet.
Very primitive drawing outlining what it is I'm trying to do. And after I complete each section, I take a photo of it and put the graphics inside the focus sheet to indicate that part is finished. Very soon, the sheet is all filled up with graphics. And there is nothing left to do.
Unfortunately, I cannot upload any of my focus sheets to the forum. Parallax has some sort of size limit, that restricts me from uploading what I use.
So, I'm forced to slice and dice and upload small sections of my focus sheet.
... Tim
Nice, I see how that could be a big help in organizing a project, especially in the early stages.
I do something kind of like that when I'm coding. I write plain-language sentences that describe the tasks to be performed from a high-level. Then I start replacing the sentences with more detailed bullet-points, and this continues until I have enough detail to actually code something. It works a lot like essay writing where you have "Opening statement", "body", and "conclusion", but instead I use "Initialize everything", "Main loop", "shutdown", and then expand those into things like, "read sensors", "compute motor outputs", and so on.
Very primitive drawing outlining what it is I'm trying to do. And after I complete each section, I take a photo of it and put the graphics inside the focus sheet to indicate that part is finished. Very soon, the sheet is all filled up with graphics. And there is nothing left to do.
Unfortunately, I cannot upload any of my focus sheets to the forum. Parallax has some sort of size limit, that restricts me from uploading what I use.
So, I'm forced to slice and dice and upload small sections of my focus sheet.
I do something kind of like that when I'm coding ... I use "Initialize everything", "Main loop", "shutdown", and then expand those into things like, "read sensors", "compute motor outputs", and so on.
J
Ditto ... my technique I use exactly! Also, helps me estimate how long this will take me to complete. For those who want an update.
For this 3D Printer Controller, I'm not sure how applicable this may be? Since the hardware maybe already completed ... If that's the case, you're just looking at software. But, the diagram still assists me even in my software development.
I do something kind of like that when I'm coding. I write plain-language sentences that describe the tasks to be performed from a high-level. Then I start replacing the sentences with more detailed bullet-points, and this continues until I have enough detail to actually code something. It works a lot like essay writing where you have "Opening statement", "body", and "conclusion", but instead I use "Initialize everything", "Main loop", "shutdown", and then expand those into things like, "read sensors", "compute motor outputs", and so on.
J
I do something like that for coding. I write descriptions for each function/subroutine (old school in an asterisk box) as I outline the initialization, main loop, and shutdown code. Of course once I start coding there are usually several iterations of rethink, reoutline, and recode.
I think Tapperman's idea for organizing the top level of the project rather than the coding though. It is good for showing the relationship between all the subsystems in a project.
OK, last post on this distraction material ... When I posted one of my focus sheets, I wanted to post the original along with it. But I hunted everywhere and couldn't find it. But at last, I found it. As you can see, they are drastically different.
Over the last couple of days, I have not been able to spend much time on writing code, however, I have managed to get some code written.
As many of you know, I am now working with two Propellers, instead of one, so it has become necessary to split the code into two seperate sections. I have slowly, but surely, been working on both sections, with my main focus being on the code for the parser Propeller. As mentioned in a previous post, it was my intention to add support for imperial measure, as well as support for relative positioning, and that support has now been achieved, or at least I believe it has. In the attached code, perhaps you will notice quite a few changes of items that I have mentioned in previous posts. This portion of code is now geared more towards an actual application, instead of an example application, so most of the "print" commands have been removed.
Please keep in mind that the following code has not yet been tested.
As indicated in my previous post and upload, at this point in time, my focus is primarily on the code for the parsing Propeller. Although many may not agree with the use of two Propellers, that is the route that I have decided to go. With that thought in mind, I would like to proceed in a manner, which would make my efforts useful to those willing to adapt a two Propeller setup.
As mentioned several times, I would like this effort to be useful to both 3D printing and CNC applications, although it is not my intention to write all the code for both types of applications. More or less, I would prefer to simply create a template, that includes all the important stuff, such as parsing, a queue, and movement, whereas supported commands could be added or removed, according to user expertise.
With my focus being primarily on the parsing Propeller at this point, I would like to share my thoughts and hopefully get some feedback, so that while I write my code, I can make my efforts more useful to interested parties.
At this current point in time, there are eight pushbuttons and three LEDs, which make up my user interface for the 3D printer, this is not including the two programming ports, the LCD display, or the SD card adapter. Of the eight pushbuttons, two are them are dedicated, one for power on and off, and the other to stop all machine activity. Of the three LEDs, one of them is hardwired without IO, simply to indicate that the boards are powered up. In reality, this is a bit of overkill for the particular application that I am working on, but I always like to have options. Basically all I really need is maybe an LED or two, a power on button, and a stop button. I have simply provided this information as the scenario, but will elaborate a little further as I continue.
Also as indicated numerous times, I would like to provide support for both SD and serial GCODE input. Now the way that I see it, the SD support is already coded and an SD file can be parsed for GCODE commands, but considering the size of available SD cards, numerous GCODE files could be contained on a single SD card. So I was thinking about using my extra buttons to traverse the SD card file system and selecting the appropriate file to run. I believe this would be a good setup for most home built 3D printers. However, when it pertains to CNC equipment control, I believe serial GCODE input would be the best option. Instead of attempting to add keyboard, mouse, and terminal support to the parsing Propeller, I believe the best option for serial input would be the use of IO pins 30 and 31, and a custom application for sending the GCODE to the parsing Propeller, especially since there are not enough pins to support the previously mentioned items.
Anyhow, those are my thoughts, and if you are interested in this project, I would like to hear your thoughts.
... I believe the best option for serial input would be the use of IO pins 30 and 31, and a custom application for sending the GCODE to the parsing Propeller, especially since there are not enough pins to support the previously mentioned items ... and if you are interested in this project, I would like to hear your thoughts.
I'm not sure how much help I can be in your project? I am only just beginning to learn C programming. But, since I have injured my foot, I have more time to inject my opinions than I did before. LOL, lucky you.
So here is my question, "are you using the serial input output lines at the same time you're using the SD chip for your GCODE?"
are you using the serial input output lines at the same time you're using the SD chip for your GCODE?
Nah, it would be an either this or that situation.
As I was saying, the SD would most likely be used for 3D printing, where the SD card could hold multiple printable objects, however it could most certainly be used for various CNC as well. Simply pick a file and run.
Where as the serial option, would allow command line input, as well as file input, which would provide a much greater amount of control over the machine. However with the serial option, an application would still need to be created, for communicating with the parsing Propeller, but that would be easy breezy.
EDIT: Additionally, with the serial option, there would be a terminal, keyboard and mouse.
Well, you got a couple extra pins then. As long as the SD chips CS pin is not active, you could nest serial communication on the data and clock pins.
I suppose that could be done and that is a handy piece of information, if IO pins become scarce. However, in my case, as it stands now, pins 20, 21, 22, 23, 24, 25, 26, and 27, are up for grabs on the parser board, and for those folks that would not be using a Propeller Memory Card, but just an SD card adapter, there would be an additional two IO pins.
I do not know if you caught my thread, "Panel Mount PropPlug Hits The Runway", located here: http://forums.parallax.com/showthread.php/156671-Panel-Mount-PropPlug-Hits-The-Runway, but there will be two of these Panel Mount PropPlugs on my setup, one for the parser board and one for the processor board, providing they don't give me problems with reset. Anyhow, of course these will be used to program both of the Propeller chips. After programming the chips, the PropPlug going to the parser chip could be used for attaching a serial interface.
A while back, I was working on a new serial terminal for the Propeller, but I never finished it. Although not completed, this very same project could easily be turned into a serial interface for a CNC controller. Upon completion of this project or a similar one, a machine could be controlled with this software by simply plugging into the panel mount PropPlug of the parser chip. Information and code pertaining to this serial interface can be found here: http://forums.parallax.com/showthread.php/133979-Project-In-Progress-New-Serial-Terminal-Taking-Suggestions
... in my case, as it stands now, pins 20, 21, 22, 23, 24, 25, 26, and 27, are up for grabs on the parser board, and for those folks that would not be using a Propeller Memory Card, but just an SD card adapter, there would be an additional two IO pins.
and a custom application for sending the GCODE to the parsing Propeller, especially since there are not enough pins to support the previously mentioned items.
Comments
queue.c
#include <stdbool.h> #include "simpletools.h" #include "fdserial.h" #include "queue.h" #include "gcode_struct.h" // cog variables static int queue_cog = 0; static int queue_stack[60]; // stack size will need increasing static int queue_head = -1; static int queue_tail = -1; static GCODE_STRUCT queue_array[QUEUE_SIZE]; static GCODE_STRUCT received_struct; static char received_struct_array[sizeof(GCODE_STRUCT)]; static bool update_current_gcode = false; // declare volatiles volatile GCODE_STRUCT current_gcode; // declare the queue_receive cog function void queue_receive(void *par); // start the queue void queue_init() { if(queue_cog == 0) { queue_cog = 1 + cogstart(&queue_receive, NULL, queue_stack, sizeof queue_stack); } } // stop the queue void queue_stop() { if(queue_cog > 0) { cogstop(queue_cog - 1); queue_cog = 0; } } // serially receive queue items in seperate cog void queue_receive(void *par) { uint32_t index; fdserial *processor; char Char; bool bEndOfStruct; processor = fdserial_open(2, 0, 0, 230400); do { // proceed the struct with a '<' for STX // STX = start of text // STX can be anything that will not be included in your data // STX must be the same on the transmitting end if(fdserial_rxTime(processor, 500) == '<') { index = 0; bEndOfStruct = false; memset((void*)&received_struct, 0, sizeof(GCODE_STRUCT)); memset((void*)received_struct_array, 0, sizeof(GCODE_STRUCT)); while(bEndOfStruct == false) { Char = fdserial_rxTime(processor, 500); // follow the struct with a '>' for ETX // ETX = end of text // ETX can be anything that will not be included in your data // ETX must be the same on the transmitting end if(Char != '>') { received_struct_array[index] = Char; index++; } else { bEndOfStruct = true; } } memcpy((void*)&received_struct, (void*)&received_struct_array, sizeof(GCODE_STRUCT)); queue_add_struct(received_struct); } } while(queue_cog > 0); } // empty the queue, emergency stop. void queue_flush() { queue_head = queue_tail = -1; } // add a struct to the queue bool queue_add_struct(GCODE_STRUCT strct) { // check if the queue is full if(is_queue_full()) { // replace return with loop and waitcnt return false; } // increment queue_tail index queue_tail++; // add struct to the queue queue_array[queue_tail % QUEUE_SIZE] = strct; return true; } // pop a struct off of the queue void queue_pop_struct() { GCODE_STRUCT strct; // check if the queue is empty if(is_queue_empty()) { // clear the current_gcode struct memset((void*)¤t_gcode, 0, sizeof(GCODE_STRUCT)); } else { // increment queue_head index queue_head++; // fill the current_gcode struct current_gcode = queue_array[queue_head % QUEUE_SIZE]; } } // is the queue completely empty bool is_queue_empty() { return (queue_head == queue_tail); } // is the queue completely full bool is_queue_full() { return ((queue_tail - QUEUE_SIZE) == queue_head); } // wait for the queue to empty void queue_wait_for_empty() { while(is_queue_empty() == false) { } } // update the current_gcode struct void update_current_gcode_struct() { update_current_gcode = true; }queue.h
char previous_fileline[100] was added to make it easier to establish the current location or just as a holder for the last command issued. This member will most likely be utilized to simply display the current location on an LCD display or a display terminal, in combination with the current_fileline member, which will represent the target location. Considering that the queue utilizes full duplex serial, the forementioned members could be fed back to the parsing Propeller, if a more elaborate terminal were set up for that Propeller chip.
uint32_t valid_fileline_counter was added as an error checker, to help ensure that a command was not missed and I am certain that it will come in handy for other uses on the processing Propeller. So the GCODE_STRUCT now looks like the following:
gcode_struct.h
#ifndef _GCODE_STRUCT_H #define _GCODE_STRUCT_H #include <stdint.h> typedef struct { char valid[10]; char previous_fileline[100]; char current_fileline[100]; uint32_t valid_fileline_counter; uint8_t g_num; uint8_t m_num; uint8_t t_num; uint16_t s_num; uint16_t p_num; double x_num; double y_num; double z_num; double e_num; double f_num; double x_travel; double y_travel; double z_travel; double e_travel; uint8_t x_dir; uint32_t x_start_stop_speed; uint32_t x_total_steps; uint32_t x_ramp_up_steps; uint32_t x_running_steps; uint32_t x_ramp_down_steps; uint32_t x_ramp_inc_dec; uint8_t y_dir; uint32_t y_start_stop_speed; uint32_t y_total_steps; uint32_t y_ramp_up_steps; uint32_t y_running_steps; uint32_t y_ramp_down_steps; uint32_t y_ramp_inc_dec; uint8_t z_dir; uint32_t z_start_stop_speed; uint32_t z_total_steps; uint32_t z_ramp_up_steps; uint32_t z_running_steps; uint32_t z_ramp_down_steps; uint32_t z_ramp_inc_dec; uint8_t e_dir; uint32_t e_start_stop_speed; uint32_t e_total_steps; uint32_t e_ramp_up_steps; uint32_t e_running_steps; uint32_t e_ramp_down_steps; uint32_t e_ramp_inc_dec; } GCODE_STRUCT; #endif /* _GCODE_STRUCT_H */Thanks for the heads up on that, I appreciate it. Now if I can only remember that later, because there are several files that will need to be changed, and I am not up to it now.
Wait.... That is why comments are handy
Thanks David
As many of you know, I hop around quite a bit, because I get bored easily, while performing tedious and mundane tasks. For my latest round of effort on this project, I did not feel like soldering or finishing up the processing queue, so I decided to start preparing some of the processor code. As I was working on this code, I came to the realization that I had overlooked quite a few serious ramifications, by thinking outside the box. For instance, there are consequences to seperating the parser and the processor, such as all measurement calculations must be performed by the parser, not just some. Example given, will the coordinates be relative or absolute... Are distances measured in inches or millimeters... While working on the parser, I briefly thought about this, and I figured my main goal would be to achieve absolute positioning measured in millimeters, but now, after working on the processor, I realize that the parser neeeds a bit more work on the code to support relative positioning and inch measurement. On the surface, I suppose this appears to be no big deal, especially if you are creating your own GCODE, however, when using someone elses GCODE, this could be a major issue. Considering that I do not want to write or alter GCODE for every item that I want to create, I will now have to modifying the existing parser code to support relative positioning and inch measurement. Adding inch measurement support really should not be that big of a deal, but I am really uncertain how relative positioning support will affect the current code base.
Additionally, there are also ramifications pertaining to stepper motor control, that must be taken into consideration on both the parser and the processor end of things. Such as the speed when homing and searching for limit switches, etc... Beyond any doubt, the stepper driver and parsing code, will need quite a bit of modification.
Just sharing thoughts..... One baby step at a time
With that board now out of the way, soldering up the primary board should be a cake walk. Several headers here and there, a little wire, and perhaps about ten resistors, and that board should be ready also.
I am beginning to have a positive outlook once again
It is now time to go and solder it all together
First off, let me state for the record, that I believe the dual Prop setup is the ticket, because it gives me everything I want for a controller, plus I have left over IO for both boards, for any expansion that I may need to do. I further believe that splitting the parser and the processor, and sending a GCODE_STRUCT between the two Propellers, is also a good idea. However, I also believe that I may be approaching this incorrectly. Since I freely admit, that running four seperate cogs, for four seperate steppers, may or may not work, or may not be easy to achieve, therefore a definite possibility of failure exists. As I see it, the one thing that is actually limiting my possibility of ultimate success, is the passing of too much stepper information in the GCODE_STRUCT. While I believe it is beneficial to calculate the stepper direction and the number of steps needed, on the parsing Propeller, I now believe that all stepper speed calculations, should be performed by the processing Propeller. By moving the speed calculations to the processing Propeller, a variety of stepper control theories can be applied, as long as the control code and calculations fit within the available memory, of the processing Propeller.
To sum it up, I now believe the GCODE_STRUCT should be changed once again, as follows:
From:
#ifndef _GCODE_STRUCT_H #define _GCODE_STRUCT_H #include <stdint.h> /// Structure for holding GCODE fileline data typedef struct { char valid[10]; char previous_fileline[100]; char current_fileline[100]; uint32_t valid_fileline_counter; char g_char[3]; char m_char[3]; char t_char[1]; char s_char[5]; char p_char[5]; char x_char[9]; char y_char[8]; char z_char[8]; char e_char[8]; char f_char[8]; uint8_t g_num; uint8_t m_num; uint8_t t_num; uint16_t s_num; uint16_t p_num; double x_num; double y_num; double z_num; double e_num; double f_num; double x_travel; double y_travel; double z_travel; double e_travel; uint8_t x_dir; uint32_t x_start_stop_speed; uint32_t x_total_steps; uint32_t x_ramp_up_steps; uint32_t x_running_steps; uint32_t x_ramp_down_steps; uint32_t x_ramp_inc_dec; uint8_t y_dir; uint32_t y_start_stop_speed; uint32_t y_total_steps; uint32_t y_ramp_up_steps; uint32_t y_running_steps; uint32_t y_ramp_down_steps; uint32_t y_ramp_inc_dec; uint8_t z_dir; uint32_t z_start_stop_speed; uint32_t z_total_steps; uint32_t z_ramp_up_steps; uint32_t z_running_steps; uint32_t z_ramp_down_steps; uint32_t z_ramp_inc_dec; uint8_t e_dir; uint32_t e_start_stop_speed; uint32_t e_total_steps; uint32_t e_ramp_up_steps; uint32_t e_running_steps; uint32_t e_ramp_down_steps; uint32_t e_ramp_inc_dec; } GCODE_STRUCT; #endif /* _GCODE_STRUCT_H */To:
#ifndef _GCODE_STRUCT_H #define _GCODE_STRUCT_H #include <stdint.h> /// Structure for holding GCODE fileline data typedef struct { char valid[10]; char previous_fileline[100]; char current_fileline[100]; uint32_t valid_fileline_counter; char g_char[3]; char m_char[3]; char t_char[1]; char s_char[5]; char p_char[5]; char x_char[9]; char y_char[8]; char z_char[8]; char e_char[8]; char f_char[8]; uint8_t g_num; uint8_t m_num; uint8_t t_num; uint16_t s_num; uint16_t p_num; double x_num; double y_num; double z_num; double e_num; double f_num; double x_travel; double y_travel; double z_travel; double e_travel; uint8_t x_dir; uint32_t x_total_steps; uint8_t y_dir; uint32_t y_total_steps; uint8_t z_dir; uint32_t z_total_steps; uint8_t e_dir; uint32_t e_total_steps; } GCODE_STRUCT; #endif /* _GCODE_STRUCT_H */As briefly mentioned earlier in this thread, the "travel" information for the various axes was included in the struct for calculation purposes only and it really is of little use afterwards. So instead of having it in the struct and transmitting it to the processing Propeller, I rewrote portions of a function, to make these variables local to that function, hence they are no longer needed in the struct.
Additionally, during the parsing process, I was storing text based characters within the struct to represent the various GCODE fields. Once these characters have been turned into numeric format, these characters are also no longer needed, so I have removed them also, and added them locally to a function.
And so the GCODE_STRUCT will now look like this:
#ifndef _GCODE_STRUCT_H #define _GCODE_STRUCT_H #include <stdint.h> /// Structure for holding GCODE fileline data typedef struct { char valid[10]; char previous_fileline[100]; char current_fileline[100]; uint32_t fileline_number; uint8_t g_num; uint8_t m_num; uint8_t t_num; uint16_t s_num; uint16_t p_num; double x_num; double y_num; double z_num; double e_num; double f_num; uint8_t x_dir; uint32_t x_total_steps; uint8_t y_dir; uint32_t y_total_steps; uint8_t z_dir; uint32_t z_total_steps; uint8_t e_dir; uint32_t e_total_steps; } GCODE_STRUCT; #endif /* _GCODE_STRUCT_H */I use a focus sheet. I hop around quite a bit myself, but never lose focus or get bored and always reach my goal quickly.
... Tim
Alright.... I just have to ask..... What is a focus sheet? And does it have zoom capabilities?
Very primitive drawing outlining what it is I'm trying to do. And after I complete each section, I take a photo of it and put the graphics inside the focus sheet to indicate that part is finished. Very soon, the sheet is all filled up with graphics. And there is nothing left to do.
Unfortunately, I cannot upload any of my focus sheets to the forum. Parallax has some sort of size limit, that restricts me from uploading what I use.
So, I'm forced to slice and dice and upload small sections of my focus sheet.
... Tim
Nice, I see how that could be a big help in organizing a project, especially in the early stages.
J
I like it.
What Model of MB do you have?
Mike
I'm using the same one as 'idbruce' ... Proto.
... Tim
Yeah. I wish they will build them again. I really liked the prop in the center and that there is no USB on them.
Mike
Ditto ... my technique I use exactly! Also, helps me estimate how long this will take me to complete. For those who want an update.
For this 3D Printer Controller, I'm not sure how applicable this may be? Since the hardware maybe already completed ... If that's the case, you're just looking at software. But, the diagram still assists me even in my software development.
... Tim
I do something like that for coding. I write descriptions for each function/subroutine (old school in an asterisk box) as I outline the initialization, main loop, and shutdown code. Of course once I start coding there are usually several iterations of rethink, reoutline, and recode.
I think Tapperman's idea for organizing the top level of the project rather than the coding though. It is good for showing the relationship between all the subsystems in a project.
I like the extra prototyping area of the Project Board but there are times when I wish it was a serial interface rather than the onboard USB.
... Tim
As many of you know, I am now working with two Propellers, instead of one, so it has become necessary to split the code into two seperate sections. I have slowly, but surely, been working on both sections, with my main focus being on the code for the parser Propeller. As mentioned in a previous post, it was my intention to add support for imperial measure, as well as support for relative positioning, and that support has now been achieved, or at least I believe it has. In the attached code, perhaps you will notice quite a few changes of items that I have mentioned in previous posts. This portion of code is now geared more towards an actual application, instead of an example application, so most of the "print" commands have been removed.
Please keep in mind that the following code has not yet been tested.
As mentioned several times, I would like this effort to be useful to both 3D printing and CNC applications, although it is not my intention to write all the code for both types of applications. More or less, I would prefer to simply create a template, that includes all the important stuff, such as parsing, a queue, and movement, whereas supported commands could be added or removed, according to user expertise.
With my focus being primarily on the parsing Propeller at this point, I would like to share my thoughts and hopefully get some feedback, so that while I write my code, I can make my efforts more useful to interested parties.
At this current point in time, there are eight pushbuttons and three LEDs, which make up my user interface for the 3D printer, this is not including the two programming ports, the LCD display, or the SD card adapter. Of the eight pushbuttons, two are them are dedicated, one for power on and off, and the other to stop all machine activity. Of the three LEDs, one of them is hardwired without IO, simply to indicate that the boards are powered up. In reality, this is a bit of overkill for the particular application that I am working on, but I always like to have options. Basically all I really need is maybe an LED or two, a power on button, and a stop button. I have simply provided this information as the scenario, but will elaborate a little further as I continue.
Also as indicated numerous times, I would like to provide support for both SD and serial GCODE input. Now the way that I see it, the SD support is already coded and an SD file can be parsed for GCODE commands, but considering the size of available SD cards, numerous GCODE files could be contained on a single SD card. So I was thinking about using my extra buttons to traverse the SD card file system and selecting the appropriate file to run. I believe this would be a good setup for most home built 3D printers. However, when it pertains to CNC equipment control, I believe serial GCODE input would be the best option. Instead of attempting to add keyboard, mouse, and terminal support to the parsing Propeller, I believe the best option for serial input would be the use of IO pins 30 and 31, and a custom application for sending the GCODE to the parsing Propeller, especially since there are not enough pins to support the previously mentioned items.
Anyhow, those are my thoughts, and if you are interested in this project, I would like to hear your thoughts.
I'm not sure how much help I can be in your project? I am only just beginning to learn C programming. But, since I have injured my foot, I have more time to inject my opinions than I did before. LOL, lucky you.
So here is my question, "are you using the serial input output lines at the same time you're using the SD chip for your GCODE?"
... Tim
Nah, it would be an either this or that situation.
As I was saying, the SD would most likely be used for 3D printing, where the SD card could hold multiple printable objects, however it could most certainly be used for various CNC as well. Simply pick a file and run.
Where as the serial option, would allow command line input, as well as file input, which would provide a much greater amount of control over the machine. However with the serial option, an application would still need to be created, for communicating with the parsing Propeller, but that would be easy breezy.
EDIT: Additionally, with the serial option, there would be a terminal, keyboard and mouse.
Well, you got a couple extra pins then. As long as the SD chips CS pin is not active, you could nest serial communication on the data and clock pins.
... Tim
I suppose that could be done and that is a handy piece of information, if IO pins become scarce. However, in my case, as it stands now, pins 20, 21, 22, 23, 24, 25, 26, and 27, are up for grabs on the parser board, and for those folks that would not be using a Propeller Memory Card, but just an SD card adapter, there would be an additional two IO pins.
I do not know if you caught my thread, "Panel Mount PropPlug Hits The Runway", located here: http://forums.parallax.com/showthread.php/156671-Panel-Mount-PropPlug-Hits-The-Runway, but there will be two of these Panel Mount PropPlugs on my setup, one for the parser board and one for the processor board, providing they don't give me problems with reset. Anyhow, of course these will be used to program both of the Propeller chips. After programming the chips, the PropPlug going to the parser chip could be used for attaching a serial interface.
A while back, I was working on a new serial terminal for the Propeller, but I never finished it. Although not completed, this very same project could easily be turned into a serial interface for a CNC controller. Upon completion of this project or a similar one, a machine could be controlled with this software by simply plugging into the panel mount PropPlug of the parser chip. Information and code pertaining to this serial interface can be found here: http://forums.parallax.com/showthread.php/133979-Project-In-Progress-New-Serial-Terminal-Taking-Suggestions
And here is a screen shot
I was confused by this part earlier.
You confused me ... which isn't hard to do BTW.
... Tim
I had not ... but I followed your link and saw the dual prop plug port and now I'm beginning to connect the dots.
... Tim