Loopy,
Good news , propellerASC came today. I hooked up extruder heater and thermo resistor , sent a M104S200 and the heater turned on, heated up to 200 shut-off and then cycled on & off to maintain temp.
Brian
So the heater control code in Tonokit is right. Teacup attempts to impliment a PID heater control and I suspect that takes up quite a bit more space than a hystersis approach. So referring to the Tonokit heater control might help cut down the size of Teacup.
Tonokit seems to have NOT completed coding its 'timed shut down monitor'. You will see errors in your SimpleIDE compile report related to 'kill(byte debug). And I don't think there is a 'byte debug' to tied it into.
So this is a possible indication that that code for Tonokit is incomplete in some operating sense. How incomplete is hard to say.
Loopy,
I've tried everything I can think of ,pull home switch's high ,pulled them low ,made sure that the extruder was up to temp before sending any g code commands.
You can send it a G1 by itself and it don't lock up and you can send it X1Y1 by themselves and it don't lock up (although It don't look like it's trying to move - per scope on step pins).
Loopy,
I've tried everything I can think of ,pull home switch's high ,pulled them low ,made sure that the extruder was up to temp before sending any g code commands.
You can send it a G1 by itself and it don't lock up and you can send it X1Y1 by themselves and it don't lock up (although It don't look like it's trying to move - per scope on step pins).
Brian
Hi again,
I have been deep into reading the C code for both the Tonokit_with_serial and the Teacup while trying to decide if it is better to upgrade Tonokit to work as a Teacup-ette, or to cut down Teacup to work on the Propeller as a Teacup-ette.
I see a few problems with Tonokit_with_serial.
A. The compile mentions that the 'kill(byte debug)' is not recognized.
B. There is a major loop that is called 'loop( ) which calls three tasks in rotation ---> 1. get _command( ) ; 2. manage_heater( ) ; and 3. manage_inactivity( )
I strongly suspect that manage_inactivity( ) is incomplete or broken and should be commented out to get the loop to not crash. Since the get_command( ) and manage_heater( ) come first, you would get a one-shot behavior of each and then the crash.
C. manage_heater( ) has some awkward code that is tied into manage_activity( ) as the timing for manage_heater is used to determine feed rates for X, Y, Z, and E steppers. Near the end of the function is a call to manage_inactivity( ) and that might require being commented out for further testing.
+++++++++++
In summary, I am say that you really should just get the get_command( ) and manage_heater( ) code working by eliminating the manage_inactivity( ). Once you do that, the called to M1 X1 Y1 may not stall.
BTW, the <space> is very important an inputing X1Y1 might also cause a crash but in [ get_command( ) ] or you might get an Echo:X1Y1... I am not sure which.
There are other smaller issues that might make Tonokit less that wonderful.
A. There is no XON/XOFF serial flow control at this point and that might be a required additon to get the input buffer running right. I fear that a file download with overrun the input buffer and send the printer into confusion.
B. Inactivity shutdown variables declares ' previous_millis cmd' and I am not sure how that ties in.
C. millis( ) is doing some comparison with previous_millis_cmd versus previous_millis_heater. I am not sure if there is or isn't a loose end in the one for heater. That too might cause a crash after a one-shot call to get_command( )
+++++++++++++++++++++
I hope that helps you get something running enough to actually print something on a 3D printer. I don't think you need the watch-dog that shuts down inactivity to actually print. But you certainly need the heater control.
Careful that could be interpretted as manual data input.
I'm confused , This program takes the g code file generated by the slicer and sends it to the propeller ,the same way that Repetier Host does ,just not the fancy user interface.
Yes I read that and it reminded me to tell loopy that I have been testing the g-code sender with the propeller ,I would have posted it over there but I thought your thread was a hardware thread.
I'm confused , This program takes the g code file generated by the slicer and sends it to the propeller ,the same way that Repetier Host does ,just not the fancy user interface.
Once this is working a sd card is the next step.
Brian
@Brian_B
That is a handy bit of kit. I may have offended IDBruce by contending that G-code is better versus MDI(Manual Data Input). The reality is that having both is likely best; but when you have a 32Kb limitation, some things get set aside. My greatest concerns are to get something to fit in the Propeller and to make it run as fast as is optimal for the 3D printer. Having something that is much slower than that which other microprocessors can provide really would make the use of a Propeller rather silly.
I am actually very happy to see Gcodesender as it will give me a clear idea of have to assure flow control results in a steady output to the 3D printer print heat. Having a thermal head feeding melted plastic at a controlled rate is very different, requires a solid buffering and communications to avoid fits and starts that will affect print quality. BUT, it seems to NOT offer any source code as it is a Windows .exe product. (I am trying to provide an all Linux solution).
Regarding the stalling in Tonokit_with_serial, it might be wise to track all the loops in the code and have some sort of diagram to make sure they are closed. I think that if I use a simple text Search feature and search for all the 'return' entries, this can be identified quickly. The same think can be used in Teacup or any C program to trace program flow.
+++++++++++++++
"An SD card is the next step........"
RepRap has a whole series of SDcard M codes. Frankly, I worry a bit about them slowing down the parser or eating up the limited hubram. It might be best to have just one or two M-codes toggle in and out of an SD card management mode.
Also, I wonder about requiring another form of data flow control requiring ever more hubram when reading an SDcard file. I have an exampe g-code file that is 1.2Mbytes in size. Obviously, you can't just let that stream into the Propeller. I have yet to learn enough about the SDcard in GCC to feel confident to have it feed the Tonokit_with_serial.
It was claimed (originally) that Tonokit came with SDcard code. But I have not seen any in GITHUB. I also am feeling that since you have a Gcodesender, the hubram space miight be better used with other code to enhance printer quality.
It may be quite easy to create a Linux clone of Gcodesender complete with GUI. I have been just using Minicom in Linux and it has XON/XOFF if wanted. It also does a send file. About the only feature I see is a choice better cr-lf and lf-cr sequence. That seems a bit trivial as Tonokit-with-serial can be adapted to use whichever is best.
*** how come "code_seen" is called twice ? ,and they are both bool
Brian
Hi Brian,
At this point, I am officially calling the final goal (Teacup on the Propeller), Teacup-ette because the first version will be limited to supporting what Slic3r desires.
================
In all honesty I don't quite know what to say.
It is a nasty bit of 'stuff', almosts seems like a cut and paste error.
I am primarily relying on compile error reports to run down problems that it points out, but I am aware of that rather nasty block of code that you listed. It seems to have the first two lines commented out, and then provides a lot of initializations that may or maynot be useds in the final compile.
My biggest problem is that Tonokit is coded in Arduino's adaptation of C++.
My practical knowledge is plain vanilla C (sans Arduino's creativity).
I took on this project to learn more and it is very ambitious for me.
Where am I now?
A. Trying to help you (Brian_B) confirm that Tonokit_with_serial can actually operate a printer.
Reading the code and trying to locate bugs or unfinished portions.
I am testing with a Propeller, but no printer available.
Running down what I seem to not know about C++ requirements and style differences.
B. Trying to decide if cutting down Teacup to Teacup-ette would be better than modifying Tonokit to Teacup-ette
Investigating Tonokit has helped me learn a lot, but I am loosing confidence in how worthy it is to become Teacup-ette. It may be too simple. It may not run smoothly. It may be incomplete. (It was listed as abandoned and redundant in RepRap firmware. The GITHUP repository does not say much.)
I have compiled a complete inventory of g-codes and m-codes to be reconciled for inclusion BASED primarily on what Slic3r demands of Teacup and not all and everything that Teacup really provides
The good news about Teacup, it is in Arduino C, not C++
> I feel more comfortable with handling the code even though the .zip file is a lot more.
And, I am seeing more and more ways to downsize the Teacup code to fit the Propeller while keeping the core of it together.
+++++++++++++++++++++
What would I do with Tonokit at this point to make it work?
Comment out the inactivity shut down features and just see if the parser and the heater control behave better. This is what I am working on now. You don't need 'inactivity shut down' to do a print run.
I can only do one thing at a time, either helping make Tonokit work is one project, or making Teacup-ette from Teacup is another. So I am jumping back and forth. I don't mind learning C++, but am wary of it.
Here ;is the summary of G-code and M-code requirements in its latest revision.
@Brian_B
Sorry, my posting above was a bit long winded and not much help with your specific query.
Here are some practical suggestiosn
A. You might comment out one of the two 'code_seen( )' defintions and see what a compile and load does. At the core of this problem is your concern that there is a useless duplicate, right? So it is a matter of determining which might work.
B Since one is 'nicely written' on multiple lines and the other is 'cramped' on a single line, re-edit the cramped to multiple lines for easier reading and comparison.
+++++++++++
There may soon come a day when we might find that Tonokit is not worthy of futher effort. It makes a useful example of HOW TO port Arduino to Propeller, and it did serve well at getting Martin H. and Jazzed to add more to the Propelleruino library for needed functionality.
But it just may have been an experiment along the way.
I have more faith in cutting down Teacup at this point.
@Brian_B
I am trying to follow your lead in Tonokit_with_serial for now.
Herein is a .zip of it without the Kill and without the inactivity management code included. Also, I had to comment out M86 as it called the Kill function.
This builds without significan errors or warnings and eliminates most of the code that I worry is junk. I don't have my Propeller with me, so I have yet to load it and to see what it actually does.
If it still hangs, you may have indentified the core problem in the duplicate boolean entry for Code_Seen. Try commenting one out and running the order to see what is what.
M86 - If endstop not activated, abort the print (sounds like it might have shut us out after one G1 call.)
M86 is not required for Teacup!l So it might remain forever banished as a problem child.
I got home, loaded, and ran Tonokit_with_serial_without_kill.
I worked through the whole list of G and M codes, and it seem that G1 and G4 hand up when added X, Y, Z, E, P, or S code is attached.
There are two kinds of G codes ... buffered and unbuffered.
The unbuffered are immediately set.
The buffered take a place in line to be fed to the print head smoothly. The buffer marches to a millis() tick.
____________________
Conclusions...
The kill and inactivity code is not the main problem. It seems that the parsing of G and M are okay outside the buffered codes. And a call to G1 and G4 without other information returns a response.
So the problem lies in where a G1 or G4 call goes after running other line parameter codes. It seems to be sent off to the wrong place or not sent anywhere.
I will try to study the flow control of that aspect and figure some fixes.
++++++++++++++++++++
Essentially you have a couple of ways to work through fixing and understanding the code.
The SimpleIDE Find is very useful to locate all the places a name might be used.
Following Returns and Breaks helps to sort out flow.
Commenting out code that might seem bad and recompiling narrows the problems down.
And in this case, testing all the combinations of G and M code inputs that are suppose to work is helpful.
With all that in mind, you 'code_seen' issue might be at the center of the problem.
I will keep trying.
The above link has some discussion of "same function name twice in c++" from a Google search. There are several sites that discuss this. I just grabbed the one and have yet to really read it.
But it does start out with "function names do NOT have to be unique in C++....." argh.............
@Loopy, C++ mangles the parameter types into the name of the function, so print(int) and print (char) can have the same name. Under the covers the compiler generates a function name printint and printchar. In addition there's scoping of names, so each name space can have its own function with a name and type. It's something that you eventually get used to.
I'll read the wiki and try to learn the concepts. But the semantic contradiction (or irony) is disconcerting. It is like an Englishman that claims he is 'bloody fine'.
Apparently even Linus Torvalds prefers C, won't look at C++ code for Linux... too many ways to do the same thing in questionable ways.
I'll read the wiki and try to learn the concepts. But the semantic contradiction (or irony) is disconcerting. It is like an Englishman that claims he is 'bloody fine'.
Apparently even Linus Torvalds prefers C, won't look at C++ code for Linux... too many ways to do the same thing in questionable ways.
Apparently even Linus Torvalds prefers C, won't look at C++ code for Linux... too many ways to do the same thing in questionable ways.
I've read his rant against C++ and he's mostly concerned about code bloat within the kernel. He doesn't care if people use it in user mode code. I've been project lead on many C++ projects and he has a point. Many programmers don't understand C++ and never glance at the assembly output. Some simple statements can expand to huge amounts of code in the hands of the unwary. I got so sick of reviewing code to stomp out bad code. Each of the below has their place, but I've seen them abused:
Unrestrained use of templates (templates generate code for each type invoked).
Passing objects by value (invokes the copy constructor).
Returning objects by value (invokes the copy constructor).
Creating arrays of objects willy nilly.
Stack allocation of large objects.
His solution is that C's lower level forces the programmer to confront what they're doing. This is true, except I've seen C's macros similarly abused, but he's thrown away C++'s greater type safety and features. But it's his baby so he can do what he wants.
@Martin_H
I do realize that any tool in the wrong hands is destined to do the wrong things. So I won't completely tar C++, but I still have less comfort with it than C. I am just at that phase in learning. It does seem that one must learn C before they learn C++.
@Brian_B
The short story for Tonokit is that the parser seems incomplete, or broken in its original state (from GITBUB and ported to Tonokit_with_serial.zip).
Are you sure you really desire to fit it? I still get one-shot hangs on G1 and G4 when I add additional code to the same line of entry.
When I toggle Comment mode = true, I get additional feedback for M-codes that is nice. But the behavior of G1 and G4 seems even more questionable.
It seems the Focus should be on debugging the G-code parse section. And G1 and G4 seem to tie into the call to timers in millis( ), so it could be that is what is crashing.
+++++++++++++++++
I think I completed my research and analysis of what Slic3r requires from Teacup, so it is looking more appealing to removed the unneeded code and unnecessary features from Teacup to get a small code footprint.......... and then try to port that to the Propeller.
Why so?
It is C code, not C++
It is supposed to operate well, it isn't an abandoned project.
I guess what I am saying is that I feel a bit lost in what Tonokit provides. There is something to be learned by debugging it. But there might be more to learn from porting Teacup to Teacup-ette at this point.
The whole program starts with mendel.c (The Readme files point this out).
The MakeFiles can be wholly ignored
Just opening medel.c and trying to build in SimpleIDE is how the process starts.
Immediately you run into what to do with an #include avr_io.h file and since this is a Propeller, that gets commented out for later provision of a Propeller io solution
Then you begin into the compile looking for arduino.h. We don't want the existing and I guess Martin H. has cleverly renamed the replacemet file with a capilal A. So change the name to Arduino.h AND figure out how to link to that in the Propellerino libraries.
I thnk next the Build demands a serial.h and that to gets changed to Serial.h.
++++++++++++++++
And so, the process goes back and forth until either you or I get completely to the end of a compile. If I get their first, I will use the Zip function in SimpleIDE to post the results here.
It appears that I should pull out all the USB code right away. And there is a lot of other stuff to discover. There might be a better way to do all this that was mentioned earlier above. So I think I might look for more insight in the first 25 entries in this thread.... but all the SimpleIDE error reports that were posted were for Tonokit. I believe that only an overall approached was ever discussed for Teacup.
It is all a bit of a brutal hacking away at first. And reading the Propelleruino libraries with Find to see what is actually available. If progress is too slow... comment out items for now , add a keywork such as WHY?
in the comment and Find function can be used to relocate all the WHY? markers.
Removing functions from the parse for Teacup-ette seems rather each. It is all the 'stuff' that expects to see an AVR instead of a Propeller that will be a bit daunting. ... like the interrupt.n file. (no interrupts in a Propeller). I am hoping that Jazzed and Martin H just might have something to say after we get deeper into this.
+++++++++++++
I am starting over with the above approach as I have had several false starts so far. I need to get alway to the end of this first build attempt to survey what is what, and to identify problem items.
So areas of code that might be dumped are PID heater control for hystersis instead, USB code, SDcard code, and anything else that seems larger and additional at this point. By dumped, I merely mean that it is commented out, not removed. Some stuff may need to be recalled as the discovery of what is what moves along.
Well, I suppose that the answer is yes, G-godes (as opposed to M codes) might be considered at the heart of all and everything.
But you do have the X, Y, Z, E, F, S, and P codes that really are the workhorses of it all. That pesky thermal printer head requires quite a bit of coordination and control to work in synch with the X, Y, and Z motions.
G1 seems to do it all, but then you really have to look at everything on a line as one printer head task.
+++++++++++++
Also, there are 'buffered g-codes' that drive the printer head at calucalted feed rate in coordination with the filiment feed rate.
And there are the 'non-buffered g-codes' that pretty much just toggle items.
+++++++++++++
Reading those g-code files for parsing definitely was necessary for me to get a feel of what the code has to juggle. But I am still not quite sure what gets juggled when, or where it all fits together.
The program pretty much just opens a serial port, has the g-code parse wait for instructions, and manages controlling print heat heat at the right temperature.
Having a good introduction to C is also important... something not to long, but not outdated either.
Comments
So the heater control code in Tonokit is right. Teacup attempts to impliment a PID heater control and I suspect that takes up quite a bit more space than a hystersis approach. So referring to the Tonokit heater control might help cut down the size of Teacup.
Tonokit seems to have NOT completed coding its 'timed shut down monitor'. You will see errors in your SimpleIDE compile report related to 'kill(byte debug). And I don't think there is a 'byte debug' to tied it into.
So this is a possible indication that that code for Tonokit is incomplete in some operating sense. How incomplete is hard to say.
I've tried everything I can think of ,pull home switch's high ,pulled them low ,made sure that the extruder was up to temp before sending any g code commands.
You can send it a G1 by itself and it don't lock up and you can send it X1Y1 by themselves and it don't lock up (although It don't look like it's trying to move - per scope on step pins).
Brian
Brian
Hi again,
I have been deep into reading the C code for both the Tonokit_with_serial and the Teacup while trying to decide if it is better to upgrade Tonokit to work as a Teacup-ette, or to cut down Teacup to work on the Propeller as a Teacup-ette.
I see a few problems with Tonokit_with_serial.
A. The compile mentions that the 'kill(byte debug)' is not recognized.
B. There is a major loop that is called 'loop( ) which calls three tasks in rotation ---> 1. get _command( ) ; 2. manage_heater( ) ; and 3. manage_inactivity( )
I strongly suspect that manage_inactivity( ) is incomplete or broken and should be commented out to get the loop to not crash. Since the get_command( ) and manage_heater( ) come first, you would get a one-shot behavior of each and then the crash.
C. manage_heater( ) has some awkward code that is tied into manage_activity( ) as the timing for manage_heater is used to determine feed rates for X, Y, Z, and E steppers. Near the end of the function is a call to manage_inactivity( ) and that might require being commented out for further testing.
+++++++++++
In summary, I am say that you really should just get the get_command( ) and manage_heater( ) code working by eliminating the manage_inactivity( ). Once you do that, the called to M1 X1 Y1 may not stall.
BTW, the <space> is very important an inputing X1Y1 might also cause a crash but in [ get_command( ) ] or you might get an Echo:X1Y1... I am not sure which.
There are other smaller issues that might make Tonokit less that wonderful.
A. There is no XON/XOFF serial flow control at this point and that might be a required additon to get the input buffer running right. I fear that a file download with overrun the input buffer and send the printer into confusion.
B. Inactivity shutdown variables declares ' previous_millis cmd' and I am not sure how that ties in.
C. millis( ) is doing some comparison with previous_millis_cmd versus previous_millis_heater. I am not sure if there is or isn't a loose end in the one for heater. That too might cause a crash after a one-shot call to get_command( )
+++++++++++++++++++++
I hope that helps you get something running enough to actually print something on a 3D printer. I don't think you need the watch-dog that shuts down inactivity to actually print. But you certainly need the heater control.
Did I show you this little program for sending g code ,I've been testing it for the propeller.
http://www.shapeoko.com/wiki/index.php/GcodeSender
Brian
I'm confused , This program takes the g code file generated by the slicer and sends it to the propeller ,the same way that Repetier Host does ,just not the fancy user interface.
Once this is working a sd card is the next step.
Brian
Prior to your posting, I posted they very same topic. Please refer to this link http://forums.parallax.com/showthread.php/154883-A-New-CNC-Build-3D-Printer-El-Cheapo/page9 and read Posts #172 - #175
Yes I read that and it reminded me to tell loopy that I have been testing the g-code sender with the propeller ,I would have posted it over there but I thought your thread was a hardware thread.
Brian
@Brian_B
That is a handy bit of kit. I may have offended IDBruce by contending that G-code is better versus MDI(Manual Data Input). The reality is that having both is likely best; but when you have a 32Kb limitation, some things get set aside. My greatest concerns are to get something to fit in the Propeller and to make it run as fast as is optimal for the 3D printer. Having something that is much slower than that which other microprocessors can provide really would make the use of a Propeller rather silly.
I am actually very happy to see Gcodesender as it will give me a clear idea of have to assure flow control results in a steady output to the 3D printer print heat. Having a thermal head feeding melted plastic at a controlled rate is very different, requires a solid buffering and communications to avoid fits and starts that will affect print quality. BUT, it seems to NOT offer any source code as it is a Windows .exe product. (I am trying to provide an all Linux solution).
Regarding the stalling in Tonokit_with_serial, it might be wise to track all the loops in the code and have some sort of diagram to make sure they are closed. I think that if I use a simple text Search feature and search for all the 'return' entries, this can be identified quickly. The same think can be used in Teacup or any C program to trace program flow.
+++++++++++++++
"An SD card is the next step........"
RepRap has a whole series of SDcard M codes. Frankly, I worry a bit about them slowing down the parser or eating up the limited hubram. It might be best to have just one or two M-codes toggle in and out of an SD card management mode.
Also, I wonder about requiring another form of data flow control requiring ever more hubram when reading an SDcard file. I have an exampe g-code file that is 1.2Mbytes in size. Obviously, you can't just let that stream into the Propeller. I have yet to learn enough about the SDcard in GCC to feel confident to have it feed the Tonokit_with_serial.
It was claimed (originally) that Tonokit came with SDcard code. But I have not seen any in GITHUB. I also am feeling that since you have a Gcodesender, the hubram space miight be better used with other code to enhance printer quality.
It may be quite easy to create a Linux clone of Gcodesender complete with GUI. I have been just using Minicom in Linux and it has XON/XOFF if wanted. It also does a send file. About the only feature I see is a choice better cr-lf and lf-cr sequence. That seems a bit trivial as Tonokit-with-serial can be adapted to use whichever is best.
//#define code_num (strtod(&cmdbuffer[strchr_pointer - cmdbuffer + 1], NULL))
//inline void code_search(char code) { strchr_pointer = strchr(cmdbuffer, code); }
inline float code_value() { return (strtod(&cmdbuffer[strchr_pointer - cmdbuffer + 1], NULL)); }
inline long code_value_long() { return (strtol(&cmdbuffer[strchr_pointer - cmdbuffer + 1], NULL, 10)); }
inline bool code_seen(char code_string[]) { return (strstr(cmdbuffer, code_string) != NULL); } //Return True if the string was found
inline bool code_seen(char code)
*** how come "code_seen" is called twice ? ,and they are both bool
Brian
Hi Brian,
At this point, I am officially calling the final goal (Teacup on the Propeller), Teacup-ette because the first version will be limited to supporting what Slic3r desires.
================
In all honesty I don't quite know what to say.
It is a nasty bit of 'stuff', almosts seems like a cut and paste error.
I am primarily relying on compile error reports to run down problems that it points out, but I am aware of that rather nasty block of code that you listed. It seems to have the first two lines commented out, and then provides a lot of initializations that may or maynot be useds in the final compile.
My biggest problem is that Tonokit is coded in Arduino's adaptation of C++.
My practical knowledge is plain vanilla C (sans Arduino's creativity).
I took on this project to learn more and it is very ambitious for me.
Where am I now?
A. Trying to help you (Brian_B) confirm that Tonokit_with_serial can actually operate a printer.
Reading the code and trying to locate bugs or unfinished portions.
I am testing with a Propeller, but no printer available.
Running down what I seem to not know about C++ requirements and style differences.
B. Trying to decide if cutting down Teacup to Teacup-ette would be better than modifying Tonokit to Teacup-ette
Investigating Tonokit has helped me learn a lot, but I am loosing confidence in how worthy it is to become Teacup-ette. It may be too simple. It may not run smoothly. It may be incomplete. (It was listed as abandoned and redundant in RepRap firmware. The GITHUP repository does not say much.)
I have compiled a complete inventory of g-codes and m-codes to be reconciled for inclusion BASED primarily on what Slic3r demands of Teacup and not all and everything that Teacup really provides
The good news about Teacup, it is in Arduino C, not C++
> I feel more comfortable with handling the code even though the .zip file is a lot more.
And, I am seeing more and more ways to downsize the Teacup code to fit the Propeller while keeping the core of it together.
+++++++++++++++++++++
What would I do with Tonokit at this point to make it work?
Comment out the inactivity shut down features and just see if the parser and the heater control behave better. This is what I am working on now. You don't need 'inactivity shut down' to do a print run.
I can only do one thing at a time, either helping make Tonokit work is one project, or making Teacup-ette from Teacup is another. So I am jumping back and forth. I don't mind learning C++, but am wary of it.
Here ;is the summary of G-code and M-code requirements in its latest revision.
Sorry, my posting above was a bit long winded and not much help with your specific query.
Here are some practical suggestiosn
A. You might comment out one of the two 'code_seen( )' defintions and see what a compile and load does. At the core of this problem is your concern that there is a useless duplicate, right? So it is a matter of determining which might work.
B Since one is 'nicely written' on multiple lines and the other is 'cramped' on a single line, re-edit the cramped to multiple lines for easier reading and comparison.
+++++++++++
There may soon come a day when we might find that Tonokit is not worthy of futher effort. It makes a useful example of HOW TO port Arduino to Propeller, and it did serve well at getting Martin H. and Jazzed to add more to the Propelleruino library for needed functionality.
But it just may have been an experiment along the way.
I have more faith in cutting down Teacup at this point.
I am trying to follow your lead in Tonokit_with_serial for now.
Herein is a .zip of it without the Kill and without the inactivity management code included. Also, I had to comment out M86 as it called the Kill function.
This builds without significan errors or warnings and eliminates most of the code that I worry is junk. I don't have my Propeller with me, so I have yet to load it and to see what it actually does.
If it still hangs, you may have indentified the core problem in the duplicate boolean entry for Code_Seen. Try commenting one out and running the order to see what is what.
M86 - If endstop not activated, abort the print (sounds like it might have shut us out after one G1 call.)
M86 is not required for Teacup!l So it might remain forever banished as a problem child.
Cheers.
I got home, loaded, and ran Tonokit_with_serial_without_kill.
I worked through the whole list of G and M codes, and it seem that G1 and G4 hand up when added X, Y, Z, E, P, or S code is attached.
There are two kinds of G codes ... buffered and unbuffered.
The unbuffered are immediately set.
The buffered take a place in line to be fed to the print head smoothly. The buffer marches to a millis() tick.
____________________
Conclusions...
The kill and inactivity code is not the main problem. It seems that the parsing of G and M are okay outside the buffered codes. And a call to G1 and G4 without other information returns a response.
So the problem lies in where a G1 or G4 call goes after running other line parameter codes. It seems to be sent off to the wrong place or not sent anywhere.
I will try to study the flow control of that aspect and figure some fixes.
++++++++++++++++++++
Essentially you have a couple of ways to work through fixing and understanding the code.
The SimpleIDE Find is very useful to locate all the places a name might be used.
Following Returns and Breaks helps to sort out flow.
Commenting out code that might seem bad and recompiling narrows the problems down.
And in this case, testing all the combinations of G and M code inputs that are suppose to work is helpful.
With all that in mind, you 'code_seen' issue might be at the center of the problem.
I will keep trying.
George.
The above link has some discussion of "same function name twice in c++" from a Google search. There are several sites that discuss this. I just grabbed the one and have yet to really read it.
But it does start out with "function names do NOT have to be unique in C++....." argh.............
I am beginning to resent C++
Here is more...... but maybe not the same issue.
http://stackoverflow.com/questions/7148638/c-howto-use-the-same-function-twice-with-different-name-and-different-names-fo
I'm trying to back track now, I made one small change to the original code and lost the ADC ,Arggg!
Brian
Note that the mangling scheme is a bit more complex than my example and here's a through discussion:
http://en.wikipedia.org/wiki/Name_mangling
It's actually a good thing and has been used in many languages.
I'll read the wiki and try to learn the concepts. But the semantic contradiction (or irony) is disconcerting. It is like an Englishman that claims he is 'bloody fine'.
Apparently even Linus Torvalds prefers C, won't look at C++ code for Linux... too many ways to do the same thing in questionable ways.
C++ is a programming power-user language. Arduino and Spin are for everyone else.
If you don't want to understand something, then don't bother.
I've read his rant against C++ and he's mostly concerned about code bloat within the kernel. He doesn't care if people use it in user mode code. I've been project lead on many C++ projects and he has a point. Many programmers don't understand C++ and never glance at the assembly output. Some simple statements can expand to huge amounts of code in the hands of the unwary. I got so sick of reviewing code to stomp out bad code. Each of the below has their place, but I've seen them abused:
Unrestrained use of templates (templates generate code for each type invoked).
Passing objects by value (invokes the copy constructor).
Returning objects by value (invokes the copy constructor).
Creating arrays of objects willy nilly.
Stack allocation of large objects.
His solution is that C's lower level forces the programmer to confront what they're doing. This is true, except I've seen C's macros similarly abused, but he's thrown away C++'s greater type safety and features. But it's his baby so he can do what he wants.
I do realize that any tool in the wrong hands is destined to do the wrong things. So I won't completely tar C++, but I still have less comfort with it than C. I am just at that phase in learning. It does seem that one must learn C before they learn C++.
@Brian_B
The short story for Tonokit is that the parser seems incomplete, or broken in its original state (from GITBUB and ported to Tonokit_with_serial.zip).
Are you sure you really desire to fit it? I still get one-shot hangs on G1 and G4 when I add additional code to the same line of entry.
When I toggle Comment mode = true, I get additional feedback for M-codes that is nice. But the behavior of G1 and G4 seems even more questionable.
It seems the Focus should be on debugging the G-code parse section. And G1 and G4 seem to tie into the call to timers in millis( ), so it could be that is what is crashing.
+++++++++++++++++
I think I completed my research and analysis of what Slic3r requires from Teacup, so it is looking more appealing to removed the unneeded code and unnecessary features from Teacup to get a small code footprint.......... and then try to port that to the Propeller.
Why so?
It is C code, not C++
It is supposed to operate well, it isn't an abandoned project.
I guess what I am saying is that I feel a bit lost in what Tonokit provides. There is something to be learned by debugging it. But there might be more to learn from porting Teacup to Teacup-ette at this point.
I would rather see a striped down teacup in C ,if that was the question
Brian
Brian
Yes... Teacup has a lot of files.
The whole program starts with mendel.c (The Readme files point this out).
The MakeFiles can be wholly ignored
Just opening medel.c and trying to build in SimpleIDE is how the process starts.
Immediately you run into what to do with an #include avr_io.h file and since this is a Propeller, that gets commented out for later provision of a Propeller io solution
Then you begin into the compile looking for arduino.h. We don't want the existing and I guess Martin H. has cleverly renamed the replacemet file with a capilal A. So change the name to Arduino.h AND figure out how to link to that in the Propellerino libraries.
I thnk next the Build demands a serial.h and that to gets changed to Serial.h.
++++++++++++++++
And so, the process goes back and forth until either you or I get completely to the end of a compile. If I get their first, I will use the Zip function in SimpleIDE to post the results here.
It appears that I should pull out all the USB code right away. And there is a lot of other stuff to discover. There might be a better way to do all this that was mentioned earlier above. So I think I might look for more insight in the first 25 entries in this thread.... but all the SimpleIDE error reports that were posted were for Tonokit. I believe that only an overall approached was ever discussed for Teacup.
It is all a bit of a brutal hacking away at first. And reading the Propelleruino libraries with Find to see what is actually available. If progress is too slow... comment out items for now , add a keywork such as WHY?
in the comment and Find function can be used to relocate all the WHY? markers.
Removing functions from the parse for Teacup-ette seems rather each. It is all the 'stuff' that expects to see an AVR instead of a Propeller that will be a bit daunting. ... like the interrupt.n file. (no interrupts in a Propeller). I am hoping that Jazzed and Martin H just might have something to say after we get deeper into this.
+++++++++++++
I am starting over with the above approach as I have had several false starts so far. I need to get alway to the end of this first build attempt to survey what is what, and to identify problem items.
So areas of code that might be dumped are PID heater control for hystersis instead, USB code, SDcard code, and anything else that seems larger and additional at this point. By dumped, I merely mean that it is commented out, not removed. Some stuff may need to be recalled as the discovery of what is what moves along.
and
gcode_process.c
Of particular interest to me, would be the function (in gcode_parse.c):
In my opinion, these two files and functions are the heart and soul of the software.
But you do have the X, Y, Z, E, F, S, and P codes that really are the workhorses of it all. That pesky thermal printer head requires quite a bit of coordination and control to work in synch with the X, Y, and Z motions.
G1 seems to do it all, but then you really have to look at everything on a line as one printer head task.
+++++++++++++
Also, there are 'buffered g-codes' that drive the printer head at calucalted feed rate in coordination with the filiment feed rate.
And there are the 'non-buffered g-codes' that pretty much just toggle items.
+++++++++++++
Reading those g-code files for parsing definitely was necessary for me to get a feel of what the code has to juggle. But I am still not quite sure what gets juggled when, or where it all fits together.
The program pretty much just opens a serial port, has the g-code parse wait for instructions, and manages controlling print heat heat at the right temperature.
Having a good introduction to C is also important... something not to long, but not outdated either.
Have you looked at Andy's tutorials?
Here are some of my favorite links:
The C Book
CPlusPlus.com
C++ and C Library Reference
Linux Documentation