Well finally. That is a surprise. I have a few of some other +5V ADCs from Parallax and was under the wrong impression that was all that Parallax sold.
It seems I should figure out a shopping list... soon.
And by the way, these are 12bits while the AruinoUno is 10 bit ADC... more precision.
And I am strongly leaning toward the Propeller Project Board just because it can easily solder SMD devices as add-on and it can easily include a SDcard slot to download programs that way. (The PropellerASC+ may support and SDcard on a shield, but I am not sure of this or how to do that and everything else we seem to desire.)
The SD connector on the ASC is on the back side of the board.
The Propeller ActivityBoards (fondly known as ABS) have 4 ADC channels. It shouldn't be too hard to use the ABS ADC in stead of the MCP3208 assuming 4 channels are sufficient.
Sorry about not testing on linux and mac where the Print.h -vs- print.h problem shows up ... I usually just test on windows which is less work and frustration for me.
@Publison
Thank you, that pretty much makes the choice between the PropellerASC+ and the Propeller Project Board near equal. Of course with the Propeller Project Board, you can have a bit more as all the Propeller i/o are clearly available and an MCP3208 would easily have all 8 inputs available... but you would have to do a bit of soldering to get those extras.
++++++++++++
It has been a busy weekend.. mostly responding to new postings. I am looking forward to the week ahead to get more done.
My TO DO LIST
a. Having gotten Tonokit with serial, as provided by Jazzed to build without error reports, it is now time to modify the parser to include all the Teacup features.
( I had a Build error problem because of a typo in the Arduino.h that called to include print.h rather than Print.h)
b. Try to study and learn more about the proper use of Projects and Libraries in SimpleIDE.
(I just have been too busy to read the manual in detail. And now that I can make something work, I need to become more skilled... less appeals for help.)
c. Try to port grbl Arduino code to the Propeller as a separate project in a separate thread.
(Jazzed and Martin G. really have done all the program work so far in this thread. They added features to libPropelleruino as soon as they found things missing. I feel it is up to me to try to demonstrate that I can do something myself. Besides, I am more interested in CNC with Gerber g-code.)
d. Keep in touch here. I guess users really would prefer a device that supports the more sophisticated Repeltier g-code.
(It is time to access what more is needed and what can fit into a GCC solution. This may require a change over to Spin/PASM for more compact code to fit into a Propeller1.
While I am interested in the discussion, somebody else would be best able to take the lead in code development. On the front end, a Repeltier g-code parser would need to be copied or created. On the back end, there may be more hardware devices to control. And in between, there are features of linear and curve interpolation, floating-point dimensions to motor steps conversion, acceleration and deceleration of print head motions, code for a printer bed heater control, SDcard reader and file management... possibly more.)
==========================
And so....
If you are interested in 3D Printer control on the Propeller, think about what you want and how you might contribute to the effort. Code development is not just going to be pumped out to a wish list. If you have a 3D printer build and can test and verify, you might be in a position to get a few wishes granted, but this thread was always intended to have everyone learn to use SimpleIDE and GCC to help themselves.
I am still waiting until Tonokit is Teacup compatible to consider this project done. And it would be an even nicer ending if it supported reading g-code directly from an SD card file with the serial port just used for process control.
Modifying for a Repeltier g-code parse is a big extension that may or may not get done anytime soon. It depends much on those that want it helping out.
Size matters...... we have 32Kb of hub ram.
I get a report that says 'Code size 17,416 bytes' when I .zip the successful Tonokip with serial project. i don't have any idea what the actual Propeller binary length is as of yet. It seems I would have to load the Propeller, then use the Propeller Tool or Brad's Spin Tool to find out more specifics of how much space is available.
Quite a bit of progress has been made in a very short time. Thanks to Jazzed and Martin H.
I get a report that says 'Code size 17,416 bytes' when I .zip the sucessful Tonokip project. i don't have any idea what the Propeller binary length is as of yet. It seems I would have to load the Propeller, then use the Propeller Tool or Brad's Spin Tool to find out more specifics of how much space is available.
Ummm ... space available: 32KB-17KB = 15KB.
If you need more details there is a map file full of text. Not as pretty as the Propeller-Tool but vastly more useful to someone who understands programming ... probably of little value to beginners. Open project manager, right-click an item, Show Map File.
Hmm,
This is the only place that I see adc pins . Don't worry I won't change until instructed.
Thanks'
Brian
I really haven't had the time to run down the ADC library, but 27, 26, and 25 do seem like pin numbers. The problem is whether they represent the SPI interface or ADC pin inputs (I strongly suspect that is the ADC's SPI interface).
I will look at the Tonokit with Serial, but I am quite sure it would be buried in the ADC libary unless it is a simple configuration call at the top level of the program.
(CLUE -- read the Configuration.h and the Pins.h files .. I dimly seem to recall a comment about the ADC input pin designation therein. )
In sum you do Not connect an ADC input to the Propeller pin. You connect to 1 through 8 (or 0 through 7) of the MCP3208 inputs.
Which do you want to reconfigure.. the MCp3208 interface, or the ADC inputs that it provides? You may also require 10K pullup resistors on the SPI lines. And you do want to know which goes where. A schematic of the PropellerASC would confirm some of this.
Well finally. That is a surprise. I have a few of some other +5V ADCs from Parallax and was under the wrong impression that was all that Parallax sold.
It seems I should figure out a shopping list... soon.
And by the way, these are 12bits while the AruinoUno is 10 bit ADC... more precision.
The MCP320X has been sold and supported since 2005. Chip wrote a driver then which is used in a few demos. This being one:
I know, it's hard to keep track of all the components Parallax has to offer.
Okay, this is good news. I guess I have dated myself. It hard for me to keep track of everything, and the internet just keeps offering more to keep track of.
The silliness of it all is I have been wondering for a year or so where I might buy an MCP3208 for my Forth projects on the Propeller. I just need to add a few into my next order (for a few Propeller Project Boards).
The PropellerASC+ would have to come from Martin Hodge. But I now see that the shield I'd really like to use only exists in Gerber files. ... which means that I would have to fund make a printed circuit board to have that particular one. The LAMPS doesn't mate to it, but there is a $49.000 XYZ shield that does so nicely... just doesn't explain what amps and volts are available for stepper motors (which require a match)
SO... everything points toward a Parallax Project Board and a few MCP3208 chips with Pololu Stepper Motor Controllers populating some added sockets.
@Brian_B
I have been reading my Slic3r generated Repeltier g-code file and it seems to not use all of Repeltier's g-codes... it is a simplification, a sub-set when I compare it against the RepRap pdf. I definitely do NOT see the G-2 and G-3 codes for curved arcs as being included.
So a limited-set g-code parser for Repeltier g-code is a possibility as a first phase of development and makes for a smaller code spaces, sooner to be ready for the Propeller.
What I really would like is to see an example your 3D CAD program of what it thinks Repeltier g-code should be able to respond to. I don't think I can rely on the RepRap pdf to make code fit a smaller ram space. I might just list all and everything, not what is in actual use by you.
So, post an example file of something with curves for me to examine, please.
Ok,
Here is a flywheel I made in Geomagic (stl) ,imported into Repetier, sliced w/slic3r (set for teacup) ,the g-code attached is about .01% of all the g-code ( 10 MB total) ,it is the beginning and ending code .
Note the screen shot when I first try and connect to the propeller. This is the code that Repetier sends to the propeller and then waits for a answer.
A. MakerBot is yet another flavor of g-code (actually they may have two other flavors), so the direct g-code download is neither Teacup or Repeliter.
B. I wanted what your 3D CAD provided with its internal slicer program, not another compile from Slic3r (which I can do myself)
Why? Well Slic3r is not using the full set of Repeltier codes.. it omits G2 and G3. I wanted to see what your front-end of choice was slicing, not what Slic3r is doing (I already know that).
++++++++++++++++++
Another Progress report
I am in the midst of adding missing Teacup codes to Tonokit's parse to adapt it to be truly Teacup. That was the goal of this project. We have a successful Build and load via SimpleIDE of a CMM version.
The drawback is the CMM version will just run slow. When compared against an ArduiniUNO it might be rather sad in performance.
Once that is complete several projects need to be considered.
First, taking Tonokit and possibly modifying to an acceptable limited Repeltier g-code parser as provided from Slic3r output. Or course that may be slow as well, but it will allow more users to consider eventual PASM/Spin solutions to expedite performances.
And then, the full enchilada version of a RepRap standard Repeltier g-code parser in PASM. This would run faster, and might really be a shining star.... something as fast or faster than an Arduino solution.
There are some real questions about what and how much of standard Repeltier g-code is really required. In the world of 3D printing, the printed object is only as good as what the Slicer application compiles.
Furthermore, I have been using defaults in Slic3r and the files I generated may not be the best output that Slic3r can do. I now see that I have been compiling 'honeycomb' objects and not the slower, larger compiles of solid objects. With Slicers, it is a world of options and more options and details and more details.... That is where you get your real quality --- if and only if your g-code is fully recognized by your control board.
And so I am a bit hung up on whether or not provision for the G2 and G3 codes is a must-provide. The inclusion means a big chunk of code for arcs.
For now, I have omitted SDcard file add-ons. At any point, one can consider this if space allows such. But it seems a distraction until which g-code flavor and at what level of performance are decided.
Loopy,
From what I know G2 and G3 are extremely hard to make work, That is why most slicers won't call them and just make the arc by moving x and y very small amounts. The slicer takes the pressure off of the Microcontroller to perform calculations on the fly.
Trust me my printer makes very nice arcs without ever using a G2 or G3.
Brian
edit: the g-code I posted is the code that my printer would use (set for teacup), not makerbot code.
Well Repelier without G2 and G3 seems very feasible via a modified Tonokip parser.
I just want to complete the Teacup parser features first. Since the code is compiled in CMM, if fits in the Propeller with room to spare, but may be a bit slow. Slic3r seems to be a very acceptible slicer. Maybe KISSlicer is another. But the truth is that it all becomes a merry chase to please everyone that doesn't want to code their own.
Definitely start without support for arcs...I started putting arc support into KISSlicer, then found so few people used them that there would not be much testing of the code, and in the end it wasn't worth the effort. Adding to that, most objects people print are from triangulated files (typically STL), which of course has no smooth curves. (There are a couple of open-source(ish) libraries for reading real CAD formats (like STEP or the simpler IGES), but I can not use them in KISSlicer, as it is closed source.)
@Lonesock
Yeah, it does seem that the RepRap wiki mentions that some flavors of g-code parsers accept G2 and G3 for arcs; but also it seems that many of the slicers avoid entirely compiling with such -- or do so only upon special compile configurations.
Added to that, g-code parsers in general feed an X step, a Y step in sequence, not at the same time. So smoothness is something that is dependent on the fineness of the the division that each g-code provided by the slicer.
i could spend a lot of time on adding G2 and G3 that is not in demand. With that in mind, I am working toward just getting a good Teacup parser working. Teacup 'offically' does not accept G2 and G3, so compiles to that target will do just fine.
If one is going to really code a parser it is an important document. And it makes quite obvious that the 'great divide' in g-code parsers is those that do NOT provide for arcs with G2 and G3 and those that do.
In sum, the 'offical stance' is that Repetier and Marlin should provide G2 and G3; but FiveD, Teacup, and Sprinter do not. There is no mention of other flavors.
This project started with the goal of getting a Teacup g-code interpreter ported from Arduino to the Propeller in GCC. It looks like that is going to get done rather quickly (with only the Serial support, not the SD card support). With all that I have learned, it seems that I can envision migrating to a PASM solution to do the same, and maybe more.
The goals have always been for a complete parser, but also of speed. The issue of 'as good as or even better' speed with the Propeller over the Arduinio are better addressed in PASM. Porting the code has been an opportunity for me learn from the Arduino code by actually doing something, and I think that approach is faster than just reading C source code without seeing what it does.
For now, Propeller users can have at least one device that works with 3D printing while the next generation evolves.
And so, we will continue trying to get something useful along the way while trying to get something better over the long haul.
G-code are not really that hard. And even though the RepRap document list then into the 500s, the one's that are actually doing is a reasonably short list. Please refer to the attached documents to see what i mean.
FYI, the Tonokit to Teacup document is a new revision as of today. And if you are really ambition about a 3-D printer with smooth curves.. consider options other than g-code. Others are evolving. I am not going to deal with them.
Loopy,
From what I know G2 and G3 are extremely hard to make work, That is why most slicers won't call them and just make the arc by moving x and y very small amounts. The slicer takes the pressure off of the Microcontroller to perform calculations on the fly.
Trust me my printer makes very nice arcs without ever using a G2 or G3.
Brian
edit: the g-code I posted is the code that my printer would use (set for teacup), not makerbot code.
When I was at Gerber, we supported Circular Interpolation from day one. It was very important for Photo plotters and drafting plotters We did it on HP1000, and later on the 68000. I wish I had the code. Pascal at the time I think.
When I was at Gerber, we supported Circular Interpolation from day one. It was very important for Photo plotters and drafting plotters We did it on HP1000, and later on the 68000. I wish I had the code. Pascal at the time I think.
I cannot emphasize strongly enough that G-code is not all the same in all applications. Gerber file format, HP plotter format. Teacup format, Repetier format, and so on --- ALL exist with subtle differences.
Starting without any experience with g-codes can lead to making false assumptions about what is required by a parser. And I have started without any experience, had to work through looking at what is really in use and thinking quite a bit.
Regarding the utility of G2 and G3..............
Yes indeed, I suspect with with Plotters, not 3D printers that are dependent of slicer compilers, the called to G2 and G3 are really necessary. It isn't that I don't think it is useful in any context. But the usefulness is lessened if the slicer compiler can't manage it well (and that seems to be the case)
So the issue of G2 and G3 inclusion is specific to 3D Printers. Plotters have much higher resolution and achieve greater accuracy.
Teacup g-code does not compile G2 and G3 codes... that is just the way it is. And this project is still trying to produce a Teacup compatible parser.
++++++++++++++++++++
Another Progress Report.
I keep thinking that I can just get started with migration of Tonokit with serial to a Teacup parser. But as I read the RepRap document and the actual TeaCup code, more features seem to be cropping up that require more research and thought.
So I am still trying to make a good To Do list to provide for a genuine Teacup parser. See attached which is once again revised.
Loopy,
I should get the propellerASC today and the RAMPS board by friday ( I like the free shipping, but it's slow ) . I'll start more testing when I get everything hooked up.
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.
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.
Hmm,
G codes are a whole different animal though ,you can send just a G1 and the propeller stays responsive. If you send a G1X1Y1 it locks up, I think it is a limit switch issue but not sure.
HI Brian_B,
I enlarged the serial comm buffer from 256 to 1024 and noticed some remarkable changes in what I was getting. It may be that the buffer size is a contributor to the problem.
After exploring the larger buffer size, I again recompiled with 'debugging = true' and that results in G1 codes offering more information, also N code info... lots of messages, but G1 does lock up in the mode after one shot. I suspect there is something that is not right about the return after parsing one line.
Either the buffer crashes by loosing count or is wrongly zeroed.
I am a bit concern with the flow from the serial port overruning the Tonokit buffer if the parse can't keep up with a steady stream of input. Buffering and even look ahead compiling are critical features that Teacup addresses in a more sophisticated fashion. I could mention a lot more, but I think that what I have said is enough to think about. Other stuff might just be weird speculation on my part. I need to study more and read the code for both more.
I am reading Tonokit and Teacup for comparison and it is seeming more and more like I should be cutting Teacup down to a Teacup-ette rather than trying to build Tonokit up to a Teacup-ette.
Nonetheless, Tonokit is an excellent bit of entry level code for people that are just getting started with C and it has a lot less #include files and is a shorter overall read to find your way around it.
Comments
Well finally. That is a surprise. I have a few of some other +5V ADCs from Parallax and was under the wrong impression that was all that Parallax sold.
It seems I should figure out a shopping list... soon.
And by the way, these are 12bits while the AruinoUno is 10 bit ADC... more precision.
The SD connector on the ASC is on the back side of the board.
http://mghdesigns.com/wiki/asc:start
The Propeller ActivityBoards (fondly known as ABS) have 4 ADC channels. It shouldn't be too hard to use the ABS ADC in stead of the MCP3208 assuming 4 channels are sufficient.
Sorry about not testing on linux and mac where the Print.h -vs- print.h problem shows up ... I usually just test on windows which is less work and frustration for me.
Thank you, that pretty much makes the choice between the PropellerASC+ and the Propeller Project Board near equal. Of course with the Propeller Project Board, you can have a bit more as all the Propeller i/o are clearly available and an MCP3208 would easily have all 8 inputs available... but you would have to do a bit of soldering to get those extras.
++++++++++++
It has been a busy weekend.. mostly responding to new postings. I am looking forward to the week ahead to get more done.
My TO DO LIST
a. Having gotten Tonokit with serial, as provided by Jazzed to build without error reports, it is now time to modify the parser to include all the Teacup features.
( I had a Build error problem because of a typo in the Arduino.h that called to include print.h rather than Print.h)
b. Try to study and learn more about the proper use of Projects and Libraries in SimpleIDE.
(I just have been too busy to read the manual in detail. And now that I can make something work, I need to become more skilled... less appeals for help.)
c. Try to port grbl Arduino code to the Propeller as a separate project in a separate thread.
(Jazzed and Martin G. really have done all the program work so far in this thread. They added features to libPropelleruino as soon as they found things missing. I feel it is up to me to try to demonstrate that I can do something myself. Besides, I am more interested in CNC with Gerber g-code.)
d. Keep in touch here. I guess users really would prefer a device that supports the more sophisticated Repeltier g-code.
(It is time to access what more is needed and what can fit into a GCC solution. This may require a change over to Spin/PASM for more compact code to fit into a Propeller1.
While I am interested in the discussion, somebody else would be best able to take the lead in code development. On the front end, a Repeltier g-code parser would need to be copied or created. On the back end, there may be more hardware devices to control. And in between, there are features of linear and curve interpolation, floating-point dimensions to motor steps conversion, acceleration and deceleration of print head motions, code for a printer bed heater control, SDcard reader and file management... possibly more.)
==========================
And so....
If you are interested in 3D Printer control on the Propeller, think about what you want and how you might contribute to the effort. Code development is not just going to be pumped out to a wish list. If you have a 3D printer build and can test and verify, you might be in a position to get a few wishes granted, but this thread was always intended to have everyone learn to use SimpleIDE and GCC to help themselves.
I am still waiting until Tonokit is Teacup compatible to consider this project done. And it would be an even nicer ending if it supported reading g-code directly from an SD card file with the serial port just used for process control.
Modifying for a Repeltier g-code parse is a big extension that may or may not get done anytime soon. It depends much on those that want it helping out.
Size matters...... we have 32Kb of hub ram.
I get a report that says 'Code size 17,416 bytes' when I .zip the successful Tonokip with serial project. i don't have any idea what the actual Propeller binary length is as of yet. It seems I would have to load the Propeller, then use the Propeller Tool or Brad's Spin Tool to find out more specifics of how much space is available.
Quite a bit of progress has been made in a very short time. Thanks to Jazzed and Martin H.
Never heard of ABS, (that's plastic, right?)
I've only heard it reffered to PAB
If you need more details there is a map file full of text. Not as pretty as the Propeller-Tool but vastly more useful to someone who understands programming ... probably of little value to beginners. Open project manager, right-click an item, Show Map File.
A bit of an inside joke. Sorry. ABS as in Abdomen ?
This is the only place that I see adc pins . Don't worry I won't change until instructed.
Thanks'
Brian
A-butyl-styrene... can anyone come up with what DDT represents? It is rather longish. And then there is OPM, Other People's Money.
I really haven't had the time to run down the ADC library, but 27, 26, and 25 do seem like pin numbers. The problem is whether they represent the SPI interface or ADC pin inputs (I strongly suspect that is the ADC's SPI interface).
I will look at the Tonokit with Serial, but I am quite sure it would be buried in the ADC libary unless it is a simple configuration call at the top level of the program.
(CLUE -- read the Configuration.h and the Pins.h files .. I dimly seem to recall a comment about the ADC input pin designation therein. )
In sum you do Not connect an ADC input to the Propeller pin. You connect to 1 through 8 (or 0 through 7) of the MCP3208 inputs.
Which do you want to reconfigure.. the MCp3208 interface, or the ADC inputs that it provides? You may also require 10K pullup resistors on the SPI lines. And you do want to know which goes where. A schematic of the PropellerASC would confirm some of this.
LOL
The MCP320X has been sold and supported since 2005. Chip wrote a driver then which is used in a few demos. This being one:
http://obex.parallax.com/object/371
I know, it's hard to keep track of all the components Parallax has to offer.
Okay, this is good news. I guess I have dated myself. It hard for me to keep track of everything, and the internet just keeps offering more to keep track of.
The silliness of it all is I have been wondering for a year or so where I might buy an MCP3208 for my Forth projects on the Propeller. I just need to add a few into my next order (for a few Propeller Project Boards).
The PropellerASC+ would have to come from Martin Hodge. But I now see that the shield I'd really like to use only exists in Gerber files. ... which means that I would have to fund make a printed circuit board to have that particular one. The LAMPS doesn't mate to it, but there is a $49.000 XYZ shield that does so nicely... just doesn't explain what amps and volts are available for stepper motors (which require a match)
SO... everything points toward a Parallax Project Board and a few MCP3208 chips with Pololu Stepper Motor Controllers populating some added sockets.
I have been reading my Slic3r generated Repeltier g-code file and it seems to not use all of Repeltier's g-codes... it is a simplification, a sub-set when I compare it against the RepRap pdf. I definitely do NOT see the G-2 and G-3 codes for curved arcs as being included.
So a limited-set g-code parser for Repeltier g-code is a possibility as a first phase of development and makes for a smaller code spaces, sooner to be ready for the Propeller.
What I really would like is to see an example your 3D CAD program of what it thinks Repeltier g-code should be able to respond to. I don't think I can rely on the RepRap pdf to make code fit a smaller ram space. I might just list all and everything, not what is in actual use by you.
So, post an example file of something with curves for me to examine, please.
Ten in stock here:
http://www.parallax.com/product/32214
Here is a flywheel I made in Geomagic (stl) ,imported into Repetier, sliced w/slic3r (set for teacup) ,the g-code attached is about .01% of all the g-code ( 10 MB total) ,it is the beginning and ending code .
Note the screen shot when I first try and connect to the propeller. This is the code that Repetier sends to the propeller and then waits for a answer.
Hmm,
can't attach a STL file to my post.
Brian
Brian
http://www.thingiverse.com/thing:11895/#files
this is the complete g-code generated.
Brian
Well, what you did do is a bit confusing.
A. MakerBot is yet another flavor of g-code (actually they may have two other flavors), so the direct g-code download is neither Teacup or Repeliter.
B. I wanted what your 3D CAD provided with its internal slicer program, not another compile from Slic3r (which I can do myself)
Why? Well Slic3r is not using the full set of Repeltier codes.. it omits G2 and G3. I wanted to see what your front-end of choice was slicing, not what Slic3r is doing (I already know that).
++++++++++++++++++
Another Progress report
I am in the midst of adding missing Teacup codes to Tonokit's parse to adapt it to be truly Teacup. That was the goal of this project. We have a successful Build and load via SimpleIDE of a CMM version.
The drawback is the CMM version will just run slow. When compared against an ArduiniUNO it might be rather sad in performance.
Once that is complete several projects need to be considered.
First, taking Tonokit and possibly modifying to an acceptable limited Repeltier g-code parser as provided from Slic3r output. Or course that may be slow as well, but it will allow more users to consider eventual PASM/Spin solutions to expedite performances.
And then, the full enchilada version of a RepRap standard Repeltier g-code parser in PASM. This would run faster, and might really be a shining star.... something as fast or faster than an Arduino solution.
There are some real questions about what and how much of standard Repeltier g-code is really required. In the world of 3D printing, the printed object is only as good as what the Slicer application compiles.
Furthermore, I have been using defaults in Slic3r and the files I generated may not be the best output that Slic3r can do. I now see that I have been compiling 'honeycomb' objects and not the slower, larger compiles of solid objects. With Slicers, it is a world of options and more options and details and more details.... That is where you get your real quality --- if and only if your g-code is fully recognized by your control board.
And so I am a bit hung up on whether or not provision for the G2 and G3 codes is a must-provide. The inclusion means a big chunk of code for arcs.
For now, I have omitted SDcard file add-ons. At any point, one can consider this if space allows such. But it seems a distraction until which g-code flavor and at what level of performance are decided.
From what I know G2 and G3 are extremely hard to make work, That is why most slicers won't call them and just make the arc by moving x and y very small amounts. The slicer takes the pressure off of the Microcontroller to perform calculations on the fly.
Trust me my printer makes very nice arcs without ever using a G2 or G3.
Brian
edit: the g-code I posted is the code that my printer would use (set for teacup), not makerbot code.
I just want to complete the Teacup parser features first. Since the code is compiled in CMM, if fits in the Propeller with room to spare, but may be a bit slow. Slic3r seems to be a very acceptible slicer. Maybe KISSlicer is another. But the truth is that it all becomes a merry chase to please everyone that doesn't want to code their own.
Jonathan
Yeah, it does seem that the RepRap wiki mentions that some flavors of g-code parsers accept G2 and G3 for arcs; but also it seems that many of the slicers avoid entirely compiling with such -- or do so only upon special compile configurations.
Added to that, g-code parsers in general feed an X step, a Y step in sequence, not at the same time. So smoothness is something that is dependent on the fineness of the the division that each g-code provided by the slicer.
i could spend a lot of time on adding G2 and G3 that is not in demand. With that in mind, I am working toward just getting a good Teacup parser working. Teacup 'offically' does not accept G2 and G3, so compiles to that target will do just fine.
@Everyone
I am learned a great deal as I have been reading a 44 page PDF I created from the [URL="http://http:.\//reprap.org/wiki/G-code"]http://reprap.org/wiki/G-code[/URL] entry.
If one is going to really code a parser it is an important document. And it makes quite obvious that the 'great divide' in g-code parsers is those that do NOT provide for arcs with G2 and G3 and those that do.
In sum, the 'offical stance' is that Repetier and Marlin should provide G2 and G3; but FiveD, Teacup, and Sprinter do not. There is no mention of other flavors.
This project started with the goal of getting a Teacup g-code interpreter ported from Arduino to the Propeller in GCC. It looks like that is going to get done rather quickly (with only the Serial support, not the SD card support). With all that I have learned, it seems that I can envision migrating to a PASM solution to do the same, and maybe more.
The goals have always been for a complete parser, but also of speed. The issue of 'as good as or even better' speed with the Propeller over the Arduinio are better addressed in PASM. Porting the code has been an opportunity for me learn from the Arduino code by actually doing something, and I think that approach is faster than just reading C source code without seeing what it does.
For now, Propeller users can have at least one device that works with 3D printing while the next generation evolves.
And so, we will continue trying to get something useful along the way while trying to get something better over the long haul.
G-code are not really that hard. And even though the RepRap document list then into the 500s, the one's that are actually doing is a reasonably short list. Please refer to the attached documents to see what i mean.
FYI, the Tonokit to Teacup document is a new revision as of today. And if you are really ambition about a 3-D printer with smooth curves.. consider options other than g-code. Others are evolving. I am not going to deal with them.
When I was at Gerber, we supported Circular Interpolation from day one. It was very important for Photo plotters and drafting plotters We did it on HP1000, and later on the 68000. I wish I had the code. Pascal at the time I think.
I cannot emphasize strongly enough that G-code is not all the same in all applications. Gerber file format, HP plotter format. Teacup format, Repetier format, and so on --- ALL exist with subtle differences.
Starting without any experience with g-codes can lead to making false assumptions about what is required by a parser. And I have started without any experience, had to work through looking at what is really in use and thinking quite a bit.
Regarding the utility of G2 and G3..............
Yes indeed, I suspect with with Plotters, not 3D printers that are dependent of slicer compilers, the called to G2 and G3 are really necessary. It isn't that I don't think it is useful in any context. But the usefulness is lessened if the slicer compiler can't manage it well (and that seems to be the case)
So the issue of G2 and G3 inclusion is specific to 3D Printers. Plotters have much higher resolution and achieve greater accuracy.
Teacup g-code does not compile G2 and G3 codes... that is just the way it is. And this project is still trying to produce a Teacup compatible parser.
++++++++++++++++++++
Another Progress Report.
I keep thinking that I can just get started with migration of Tonokit with serial to a Teacup parser. But as I read the RepRap document and the actual TeaCup code, more features seem to be cropping up that require more research and thought.
So I am still trying to make a good To Do list to provide for a genuine Teacup parser. See attached which is once again revised.
I should get the propellerASC today and the RAMPS board by friday ( I like the free shipping, but it's slow ) . I'll start more testing when I get everything hooked up.
Brian
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
WOW. That's great news.
G codes are a whole different animal though ,you can send just a G1 and the propeller stays responsive. If you send a G1X1Y1 it locks up, I think it is a limit switch issue but not sure.
Brian
I enlarged the serial comm buffer from 256 to 1024 and noticed some remarkable changes in what I was getting. It may be that the buffer size is a contributor to the problem.
After exploring the larger buffer size, I again recompiled with 'debugging = true' and that results in G1 codes offering more information, also N code info... lots of messages, but G1 does lock up in the mode after one shot. I suspect there is something that is not right about the return after parsing one line.
Either the buffer crashes by loosing count or is wrongly zeroed.
I am a bit concern with the flow from the serial port overruning the Tonokit buffer if the parse can't keep up with a steady stream of input. Buffering and even look ahead compiling are critical features that Teacup addresses in a more sophisticated fashion. I could mention a lot more, but I think that what I have said is enough to think about. Other stuff might just be weird speculation on my part. I need to study more and read the code for both more.
I am reading Tonokit and Teacup for comparison and it is seeming more and more like I should be cutting Teacup down to a Teacup-ette rather than trying to build Tonokit up to a Teacup-ette.
Nonetheless, Tonokit is an excellent bit of entry level code for people that are just getting started with C and it has a lot less #include files and is a shorter overall read to find your way around it.