Hi
I am thinking that I will really be needing constant velocity profiling (SCurve would be nice), and it was something on Dons "to do" list. Is there an easy way of adding this (a self modifying table)?????
@Andrew: Wow congrats you got it working! I'm still busy with my daily work. So my CNC must still sit and wait.
How About creating a new table with an excel-sheet which then is copied & pasted into the code?
What do you mean by constant velocity profiling? In my understanding a S-curve isn't constant velocity.
Hi Stefan
Sorry that was probably not the correct use of the words.
What I have done is make up a test bed using a Gravograph engraver with a 500x500 cutting area, and I can select between different controls - Mach3(Parallel Port), Linuxcnc(Parallel Port), GRBL, TinyG and now Dons control.
In this way I can compare different controls on the same machine running exactly the same gcode file - I was amazed at the different smoothness and cycle times between the differing controls. The TinyG control is my favourite in regard to smooth motion.
What I was meaning was the way the motion controller handles the transition between the current move and the next move. With an "S curve" move (also known as a 5 period move), the accel and decel periods are divided into concave and convex halves, plus a cruise period makes 5 periods. A 5 period S curve move takes exactly the same time to execute as simpler three-period, constant-acceleration trapezoidal move - it's just the transitions are smoother. The time lost in smoothing the endpoint transitions is made up by a higher midpoint acceleration. In spite of the fact that the time is the same, the machine can be run at a faster rate because the jerk is controlled.
Yes, I have the Prop Ed kit, a quickstart board and a protoboard. I was planning on making a DRO for my mill and lathe with the DRC encoders I have, I also have some Mitutoyo style linear scales to play with. I also have a Hardinge HC with an Accuslide CNC retrofit that needs a new controller.
My current setup for testing uses Allmotion EZinch boards and Lin Engineering NEMA 17 steppers on a Master Setco 2" x 2" XY table. It originally had EAD servos on it but those are had to drive at the hobby level.
I think will set this up on the PE kit, looks like I will need a to get an SD reader and I will check out the VT-100 software.
I know Bad Hersfeld. A part of my education to become a teacher was in Bad Hersfeld. For this I was a couple of times there. Each time half a day.
But I hadn't time to go sight seeing in the city. Bad Hersfeld is 80 km from where I live. So it's near enough to go there. But far enough to not go there. ;-)
Please post your progress if you have an SD-card-reader
Just placed an order for the SD card (and a bunch of other stuff). I will start putting together the rest of it while I'm waiting. I'm wondering how hard it would be to change the display to the built-in VGA or one of the little 7" LCD displays I have.
this CNC-object is downloaded now 226 times. All you downloaders - Please post what you have done and what you are planning to do with this software-package.
I'm still building the machine. It's getting heavy fast.
In case anyone else is wondering how the cogs are used in this program, I found a bit of an error in the comments.
These are the objects used by the program with the original comments:
OBJ
Ser : "VT100 Serial Terminal" ' Spin code interperter running in first COG
FS : "FloatString" ' Spin code
FM : "FloatMath" ' Spin code
Circular : "Hybrid_Circle8" ' Requires 1 COG
Linear : "Int_Line8" ' Requires 1 COG
F32 : "F32_pasm" ' Requires 1 COG F32 V1.5a Floating Point Math Object by Jonathan "lonesock" Dummer
fat0 : "SD-MMC_FATEngine.spin" ' Requires 1 COG
fat1 : "SD-MMC_FATEngine.spin" ' Requires 1 COG
OutBuffer : "OutputBuffer" ' Requires 1 COG
OutDriver : "OutputDriver6" ' Requires 1 COG
The "fat1" object doesn't require it's own cog. It uses the same cog as "fat" for PASM code and uses the calling cog for Spin portions.
The "Ser" object does start a cog.
I think Don's comments at the beginning of the "Start" menu list the cog use accurately.
{ Cog Usage: 0 This Spin Program
1 Serial Driver
2 F32 Math Routines (This routine is used by the Circular & Linear Interpolator Cogs.)
3 Circular Interpolation
4 Linear Interpolation
5 Output Buffer
6 FAT32 SD memory card
7 Output Diver
}
I think I'd like to use a second Propeller as the serial terminal instead of tying up a PC to communicate with the driver.
I think I'd like to use a second Propeller as the serial terminal instead of tying up a PC to communicate with the driver.
Or go portable with an Android-based tablet?
I hook a bluetooth module up to the Prop and link to my Android devices.
I have been using "Basic4Android" for a while but have just started to experiment with BASIC! (exclamation is part of the name) which is an interpreter that runs on the actual Android device.
Ridiculously easy to program with and quite flexible.
I've been fiddling with GRBL on my junkyard CNC that I made from old printer parts. GRBL is Arduino based and use a PC running a Python script to stream the gcode to GRBL using flow control to prevent GRBL's buffer from filling up.
This package looks interesting because of the analog feed rate control which GRBL doesn't have. Looking at the screen shot above it sound like this is completely self hosted and that you load the gcode off a uSD, and the PC is just the UI via the serial connection?
Note that my junkyard CNC isn't rigid enough to do anything useful, but I learned a lot about steppers, gcode, and CNC control software. I recently bought used NEMA 23 steppers off eBay and the plans for the Solsylva 10x9. So I plan to build a nice rigid CNC to replace my junkyard version.
Due to some strained back muscles, I finally got around to downloading SimpleIDE and taking a cursory look at Don Starkey's code. I must say that his code looks very interesting. Over the course of the next few months, I will be closely examining this code, to see how it may be applied to a 3D printing application. By the time I finally get around to digging in, I hope others will still be interested and that this thread will become more active.
In addition to this thread, I will also be paying close attention to and participating in these closely associated threads:
I've posted my presently useless modifications in this post.
If anyone is interested to know what I've done, make sure and read several of the posts prior to the post with the code attached to it.
I'm thinking this project may be a good application for Spin overlays Dr_Acula talked about in this thread.
I also wonder if this is an application where using C makes more sense than using Spin (did I really just say that?). Ug, I've used C a lot but I enjoy programming in Spin much much more than programming in C.
I'm very interested in this project but I'm afraid it's still a bit over my head at this point.
I have not yet taken the time to dive in deep and it appears that I still need to learn assembly. I could be wrong, but I think runtime programming could be cut down in size. G-code has never been my thing, because I simply wrote my own control code, but when you start talking CNC like most people are accustomed to, then we start talking g-code. The problem lies in the circular and linear interpolation, which I currently do not understand.
As for cutting down the program size, I would rip this and other stuff out by the roots:
AccTable long 8.4733,7.4651,6.7490,6.2063,5.7767,5.4256,5.1317,4.8809
long 4.6636,4.4730,4.3041,4.1529,4.0166,3.8929,3.7800,3.6764
long 3.5809,3.4924,3.4102,3.3335,3.2618,3.1946,3.1313,3.0716
long 3.0152,2.9619,2.9112,2.8631,2.8173,2.7736,2.7319,2.6920
long 2.6538,2.6172,2.5821,2.5483,2.5158,2.4846,2.4545,2.4254
long 2.3974,2.3703,2.3441,2.3187,2.2942,2.2704,2.2474,2.2250
long 2.2033,2.1822,2.1617,2.1418,2.1224,2.1035,2.0852,2.0673
long 2.0498,2.0328,2.0162,2.0000,1.9842,1.9688,1.9537,1.9389
long 1.9245,1.9104,1.8966,1.8831,1.8699,1.8570,1.8443,1.8319
long 1.8197,1.8078,1.7961,1.7846,1.7733,1.7623,1.7514,1.7408
long 1.7303,1.7201,1.7100,1.7001,1.6903,1.6807,1.6713,1.6621
long 1.6530,1.6440,1.6352,1.6265,1.6180,1.6096,1.6013,1.5931
long 1.5851,1.5772,1.5694,1.5617,1.5542,1.5467,1.5394,1.5321
long 1.5250,1.5180,1.5110,1.5042,1.4974,1.4907,1.4841,1.4776
long 1.4712,1.4649,1.4587,1.4525,1.4464,1.4404,1.4344,1.4286
long 1.4228,1.4171,1.4114,1.4058,1.4003,1.3948,1.3894,1.3841
long 1.3788,1.3736,1.3685,1.3634,1.3583,1.3533,1.3484,1.3435
long 1.3387,1.3339,1.3292,1.3245,1.3199,1.3153,1.3108,1.3063
long 1.3019,1.2975,1.2932,1.2889,1.2846,1.2804,1.2762,1.2721
long 1.2680,1.2639,1.2599,1.2559,1.2520,1.2481,1.2442,1.2404
long 1.2366,1.2328,1.2291,1.2254,1.2217,1.2181,1.2145,1.2109
long 1.2074,1.2039,1.2004,1.1969,1.1935,1.1901,1.1868,1.1835
long 1.1802,1.1769,1.1736,1.1704,1.1672,1.1641,1.1609,1.1578
long 1.1547,1.1516,1.1486,1.1456,1.1426,1.1396,1.1367,1.1337
long 1.1308,1.1280,1.1251,1.1223,1.1194,1.1166,1.1139,1.1111
long 1.1084,1.1057,1.1030,1.1003,1.0976,1.0950,1.0924,1.0898
long 1.0872,1.0847,1.0821,1.0796,1.0771,1.0746,1.0721,1.0697
long 1.0672,1.0648,1.0624,1.0600,1.0576,1.0553,1.0529,1.0506
long 1.0483,1.0460,1.0437,1.0414,1.0392,1.0370,1.0347,1.0325
long 1.0303,1.0282,1.0260,1.0238,1.0217,1.0196,1.0175,1.0154
long 1.0133,1.0112,1.0091,1.0071,1.0050,1.0030,1.0010,1.0000
Tables may provide faster access during runtime, but the faster you go with steppers, the more torque you lose. PulseTheStepPin driver handled this nicely by doing acceleration/deceleration at runtime, and even by using that driver, if you went to fast, the stepper motor driver would stumble or you lost a lot of torque. This is just one example of how the program can be trimmed.
I am really not sure where I am heading yet, but g-code parsing does not seem that difficult, nor does the controlling of stepper motors, the problem lies in the g-code and correlation to linear and circular interpolation. It may be easier for me to get a good grasp on that and then just attempt my own code.
@IDBruce
You are more than welcome... just trying to provide a better view of what is available and what might be handy.
I am deeply into reading all the Arduino C code that I have collected and will eventually compare it to Don Starkey's approach. I just feel that Don Starkey's OBEX CNC is a more dated solution; whereas the Arduino and LinuxCNC code is under active development.
And I am a bit concerned that Don Starkey did not fully understand how to allocate cogs to get the best performance out of the Propeller. That may be a source of the buffer bug that he left hanging.
I've been fiddling with GRBL on my junkyard CNC that I made from old printer parts. GRBL is Arduino based and use a PC running a Python script to stream the gcode to GRBL using flow control to prevent GRBL's buffer from filling up.
This package looks interesting because of the analog feed rate control which GRBL doesn't have. Looking at the screen shot above it sound like this is completely self hosted and that you load the gcode off a uSD, and the PC is just the UI via the serial connection?
Note that my junkyard CNC isn't rigid enough to do anything useful, but I learned a lot about steppers, gcode, and CNC control software. I recently bought used NEMA 23 steppers off eBay and the plans for the Solsylva 10x9. So I plan to build a nice rigid CNC to replace my junkyard version.
Are you running GRBL on an Arduino (the quick and dirty solution) or did you actually port it to the Propeller?
Nothing wrong with a 'junkyard CNC' for learning. There is a ton to learn before you really need to commit $5000 to a really tight, ready-made CNC table. Learning on junk is money in the bank.
The Python front end to control feeding to the controller packets that don't over run its buffers seem imperative. Tonokit that we ported to Propeller seems to not take that into consideration and I am beginning to think a 3D printing might run in fits and starts that cause a huge mess... or that its buffer will just crash and the printer will stall after a few lines of code. Lots for me to run down.
out of curiosity I bought an arduino and three 2A stepperdrivers to test GRBL. So far I have only tested with one steppermotor just lying on the table.
seems to work well as far as I can say from just turning a single axle on the table.
GRBL is written in C. Does anybody see a chance to port GRBL with small effort to propeller-C?
For me personal my next steps are: testing GRBL with the mechanic of my CNC-Mill. Especially precision.
Then starting to write a GUI on the propeller for controlling the arduino running GRBL.
Comments
I am thinking that I will really be needing constant velocity profiling (SCurve would be nice), and it was something on Dons "to do" list. Is there an easy way of adding this (a self modifying table)?????
AE
How About creating a new table with an excel-sheet which then is copied & pasted into the code?
What do you mean by constant velocity profiling? In my understanding a S-curve isn't constant velocity.
best regards
Stefan
Sorry that was probably not the correct use of the words.
What I have done is make up a test bed using a Gravograph engraver with a 500x500 cutting area, and I can select between different controls - Mach3(Parallel Port), Linuxcnc(Parallel Port), GRBL, TinyG and now Dons control.
In this way I can compare different controls on the same machine running exactly the same gcode file - I was amazed at the different smoothness and cycle times between the differing controls. The TinyG control is my favourite in regard to smooth motion.
What I was meaning was the way the motion controller handles the transition between the current move and the next move. With an "S curve" move (also known as a 5 period move), the accel and decel periods are divided into concave and convex halves, plus a cruise period makes 5 periods. A 5 period S curve move takes exactly the same time to execute as simpler three-period, constant-acceleration trapezoidal move - it's just the transitions are smoother. The time lost in smoothing the endpoint transitions is made up by a higher midpoint acceleration. In spite of the fact that the time is the same, the machine can be run at a faster rate because the jerk is controlled.
AE
Yes, I have the Prop Ed kit, a quickstart board and a protoboard. I was planning on making a DRO for my mill and lathe with the DRC encoders I have, I also have some Mitutoyo style linear scales to play with. I also have a Hardinge HC with an Accuslide CNC retrofit that needs a new controller.
My current setup for testing uses Allmotion EZinch boards and Lin Engineering NEMA 17 steppers on a Master Setco 2" x 2" XY table. It originally had EAD servos on it but those are had to drive at the hobby level.
I think will set this up on the PE kit, looks like I will need a to get an SD reader and I will check out the VT-100 software.
This looks like a fun project.
Robi
I just noticed you live in Hessen. do you know Bad Hersfeld? I was there in the late '70s with How Btry, 3/11 ACR.
I know Bad Hersfeld. A part of my education to become a teacher was in Bad Hersfeld. For this I was a couple of times there. Each time half a day.
But I hadn't time to go sight seeing in the city. Bad Hersfeld is 80 km from where I live. So it's near enough to go there. But far enough to not go there. ;-)
Please post your progress if you have an SD-card-reader
best regards
Stefan
this CNC-object is downloaded now 226 times. All you downloaders - Please post what you have done and what you are planning to do with this software-package.
best regards
Stefan
I figure I'll be working with Don's code a lot over the next few weeks. Any of the rest of you using Don's code?
Here's a working link to Don's code in the OBEX.
Here's Don's original thread about starting this project.
Not as yet but I follow with great interest. Looking forward to seeing this machine up and running.
Regards,
Mickster
In case anyone else is wondering how the cogs are used in this program, I found a bit of an error in the comments.
These are the objects used by the program with the original comments:
OBJ Ser : "VT100 Serial Terminal" ' Spin code interperter running in first COG FS : "FloatString" ' Spin code FM : "FloatMath" ' Spin code Circular : "Hybrid_Circle8" ' Requires 1 COG Linear : "Int_Line8" ' Requires 1 COG F32 : "F32_pasm" ' Requires 1 COG F32 V1.5a Floating Point Math Object by Jonathan "lonesock" Dummer fat0 : "SD-MMC_FATEngine.spin" ' Requires 1 COG fat1 : "SD-MMC_FATEngine.spin" ' Requires 1 COG OutBuffer : "OutputBuffer" ' Requires 1 COG OutDriver : "OutputDriver6" ' Requires 1 COGThe "fat1" object doesn't require it's own cog. It uses the same cog as "fat" for PASM code and uses the calling cog for Spin portions.
The "Ser" object does start a cog.
I think Don's comments at the beginning of the "Start" menu list the cog use accurately.
{ Cog Usage: 0 This Spin Program 1 Serial Driver 2 F32 Math Routines (This routine is used by the Circular & Linear Interpolator Cogs.) 3 Circular Interpolation 4 Linear Interpolation 5 Output Buffer 6 FAT32 SD memory card 7 Output Diver }I think I'd like to use a second Propeller as the serial terminal instead of tying up a PC to communicate with the driver.
Or go portable with an Android-based tablet?
I hook a bluetooth module up to the Prop and link to my Android devices.
I have been using "Basic4Android" for a while but have just started to experiment with BASIC! (exclamation is part of the name) which is an interpreter that runs on the actual Android device.
Ridiculously easy to program with and quite flexible.
Regards,
Mickster
This package looks interesting because of the analog feed rate control which GRBL doesn't have. Looking at the screen shot above it sound like this is completely self hosted and that you load the gcode off a uSD, and the PC is just the UI via the serial connection?
Note that my junkyard CNC isn't rigid enough to do anything useful, but I learned a lot about steppers, gcode, and CNC control software. I recently bought used NEMA 23 steppers off eBay and the plans for the Solsylva 10x9. So I plan to build a nice rigid CNC to replace my junkyard version.
I'd love to hear that somebody is using the OBEX object.
Due to some strained back muscles, I finally got around to downloading SimpleIDE and taking a cursory look at Don Starkey's code. I must say that his code looks very interesting. Over the course of the next few months, I will be closely examining this code, to see how it may be applied to a 3D printing application. By the time I finally get around to digging in, I hope others will still be interested and that this thread will become more active.
In addition to this thread, I will also be paying close attention to and participating in these closely associated threads:
http://forums.parallax.com/showthread.php/155093-Porting-Arduinio-3D-Printer-code-(Teacup-firmware)-into-a-Propeller
Good work Don.
I've posted my presently useless modifications in this post.
If anyone is interested to know what I've done, make sure and read several of the posts prior to the post with the code attached to it.
I'm thinking this project may be a good application for Spin overlays Dr_Acula talked about in this thread.
I also wonder if this is an application where using C makes more sense than using Spin (did I really just say that?). Ug, I've used C a lot but I enjoy programming in Spin much much more than programming in C.
I'm very interested in this project but I'm afraid it's still a bit over my head at this point.
I have not yet taken the time to dive in deep and it appears that I still need to learn assembly. I could be wrong, but I think runtime programming could be cut down in size. G-code has never been my thing, because I simply wrote my own control code, but when you start talking CNC like most people are accustomed to, then we start talking g-code. The problem lies in the circular and linear interpolation, which I currently do not understand.
As for cutting down the program size, I would rip this and other stuff out by the roots:
AccTable long 8.4733,7.4651,6.7490,6.2063,5.7767,5.4256,5.1317,4.8809 long 4.6636,4.4730,4.3041,4.1529,4.0166,3.8929,3.7800,3.6764 long 3.5809,3.4924,3.4102,3.3335,3.2618,3.1946,3.1313,3.0716 long 3.0152,2.9619,2.9112,2.8631,2.8173,2.7736,2.7319,2.6920 long 2.6538,2.6172,2.5821,2.5483,2.5158,2.4846,2.4545,2.4254 long 2.3974,2.3703,2.3441,2.3187,2.2942,2.2704,2.2474,2.2250 long 2.2033,2.1822,2.1617,2.1418,2.1224,2.1035,2.0852,2.0673 long 2.0498,2.0328,2.0162,2.0000,1.9842,1.9688,1.9537,1.9389 long 1.9245,1.9104,1.8966,1.8831,1.8699,1.8570,1.8443,1.8319 long 1.8197,1.8078,1.7961,1.7846,1.7733,1.7623,1.7514,1.7408 long 1.7303,1.7201,1.7100,1.7001,1.6903,1.6807,1.6713,1.6621 long 1.6530,1.6440,1.6352,1.6265,1.6180,1.6096,1.6013,1.5931 long 1.5851,1.5772,1.5694,1.5617,1.5542,1.5467,1.5394,1.5321 long 1.5250,1.5180,1.5110,1.5042,1.4974,1.4907,1.4841,1.4776 long 1.4712,1.4649,1.4587,1.4525,1.4464,1.4404,1.4344,1.4286 long 1.4228,1.4171,1.4114,1.4058,1.4003,1.3948,1.3894,1.3841 long 1.3788,1.3736,1.3685,1.3634,1.3583,1.3533,1.3484,1.3435 long 1.3387,1.3339,1.3292,1.3245,1.3199,1.3153,1.3108,1.3063 long 1.3019,1.2975,1.2932,1.2889,1.2846,1.2804,1.2762,1.2721 long 1.2680,1.2639,1.2599,1.2559,1.2520,1.2481,1.2442,1.2404 long 1.2366,1.2328,1.2291,1.2254,1.2217,1.2181,1.2145,1.2109 long 1.2074,1.2039,1.2004,1.1969,1.1935,1.1901,1.1868,1.1835 long 1.1802,1.1769,1.1736,1.1704,1.1672,1.1641,1.1609,1.1578 long 1.1547,1.1516,1.1486,1.1456,1.1426,1.1396,1.1367,1.1337 long 1.1308,1.1280,1.1251,1.1223,1.1194,1.1166,1.1139,1.1111 long 1.1084,1.1057,1.1030,1.1003,1.0976,1.0950,1.0924,1.0898 long 1.0872,1.0847,1.0821,1.0796,1.0771,1.0746,1.0721,1.0697 long 1.0672,1.0648,1.0624,1.0600,1.0576,1.0553,1.0529,1.0506 long 1.0483,1.0460,1.0437,1.0414,1.0392,1.0370,1.0347,1.0325 long 1.0303,1.0282,1.0260,1.0238,1.0217,1.0196,1.0175,1.0154 long 1.0133,1.0112,1.0091,1.0071,1.0050,1.0030,1.0010,1.0000Tables may provide faster access during runtime, but the faster you go with steppers, the more torque you lose. PulseTheStepPin driver handled this nicely by doing acceleration/deceleration at runtime, and even by using that driver, if you went to fast, the stepper motor driver would stumble or you lost a lot of torque. This is just one example of how the program can be trimmed.
I am really not sure where I am heading yet, but g-code parsing does not seem that difficult, nor does the controlling of stepper motors, the problem lies in the g-code and correlation to linear and circular interpolation. It may be easier for me to get a good grasp on that and then just attempt my own code.
Thanks.... I had not noticed that he provided seperate objects for circular and linear interpolation.
You are more than welcome... just trying to provide a better view of what is available and what might be handy.
I am deeply into reading all the Arduino C code that I have collected and will eventually compare it to Don Starkey's approach. I just feel that Don Starkey's OBEX CNC is a more dated solution; whereas the Arduino and LinuxCNC code is under active development.
And I am a bit concerned that Don Starkey did not fully understand how to allocate cogs to get the best performance out of the Propeller. That may be a source of the buffer bug that he left hanging.
Are you running GRBL on an Arduino (the quick and dirty solution) or did you actually port it to the Propeller?
Nothing wrong with a 'junkyard CNC' for learning. There is a ton to learn before you really need to commit $5000 to a really tight, ready-made CNC table. Learning on junk is money in the bank.
The Python front end to control feeding to the controller packets that don't over run its buffers seem imperative. Tonokit that we ported to Propeller seems to not take that into consideration and I am beginning to think a 3D printing might run in fits and starts that cause a huge mess... or that its buffer will just crash and the printer will stall after a few lines of code. Lots for me to run down.
out of curiosity I bought an arduino and three 2A stepperdrivers to test GRBL. So far I have only tested with one steppermotor just lying on the table.
seems to work well as far as I can say from just turning a single axle on the table.
GRBL is written in C. Does anybody see a chance to port GRBL with small effort to propeller-C?
For me personal my next steps are: testing GRBL with the mechanic of my CNC-Mill. Especially precision.
Then starting to write a GUI on the propeller for controlling the arduino running GRBL.
best regards
Stefan