Closed rickcaddell closed 8 years ago
Rick, I believe this is fixed in edge. I will not be able to test for a few days but let me verify later this week. Thanks for the spreadsheet.
I will test this on edge tonight.
On Mon, May 2, 2016 at 6:14 AM Alden Hart notifications@github.com wrote:
Rick, I believe this is fixed in edge. I will not be able to test for a few days but let me verify later this week. Thanks for the spreadsheet.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/174#issuecomment-216187841
G0X2.2500Y3.6875Z0.2000 G3X1.3125Y2.7500I0.0000J-0.9375 G3X1.3131Y2.7157I0.9375J0.0000
Is what you have in your test xls file. However it looks like you are not setting a feedrate? If that was a type is here an output from edge 449.01
{ F500 G0X2.2500Y3.6875Z0.2000 G3X1.3125Y2.7500I0.0000J-0.9375 G3X1.3131Y2.7157I0.9375J0.0000{"r":{"err":"{"},"f":[3,111,10]} {"sr":{"line":0,"posx":0.000,"posy":0.000,"posz":0.000,"posa":0.000,"feed":0.00,"vel":0.00,"unit":1,"coor":1,"dist":0,"admo":1,"frmo":1,"momo":4,"stat":1}} {"r":{},"f":[3,0,8]} {"r":{},"f":[3,0,9]} {"qr":31} {"r":{},"f":[3,0,10]} {"qr":30} {"qr":29} {"qr":28} {"qr":27} {"qr":26} {"sr":{"posx":1.799,"posy":2.948,"posz":0.160,"feed":500.00,"vel":1166.40,"momo":0,"stat":5}} {"qr":27} {"sr":{"posx":1.860,"posy":3.591,"posz":0.200,"vel":500.00,"momo":3}} {"qr":31} {"sr":{"posx":1.313,"posy":2.750,"vel":0.00,"stat":3}} {"sr":{"stat":3}}
{"r":{},"f":[3,0,10]} {"sr":{"posy":2.716,"stat":3}} ? Line number: 0 X position: 1.313 mm Y position: 2.716 mm Z position: 0.200 mm A position: 0.000 deg Feed rate: 500.000 mm/min Velocity: 0.000 mm/min Units: G21 - millimeter mode Coordinate system: G54 - coordinate system 1 Distance mode: G90 - absolute distance mode Arc Distance mode: G91.1 - incremental distance mode (default mode) Feed rate mode: G94 - units-per-minute mode (i.e. feedrate mode) Motion mode: G3 - counter clockwise arc feed Machine state: Stop tinyg [mm] ok> Machine state: Stop
This looks right. My x an y are moving at the same time? Thoughts?
This was just an example for the spreadsheet that I clipped out of a program that had the feedrate set in a previous block. This is inch mode by the way.
The axes may be moving, but they move with a fault also. It moves from the start point to the end point. You have to see if it is actually moving in an arc.
I'm having a CNC Lasercutter and we're running into the same problems. Some arcs are ignored and replaced with straight lines. The G-codes were generated with an extension in Inkscape. Example;
"G02 X303.5451 Y66.3705 I5.0418 J4.5767"
Would using R... instead of I... & J... be the solution? Is there an alternative way to generate G-codes from an image?
To get around the problem with TinyG, I have written a program in Visual Studio that runs on Windows that
takes a GCode file and replaces all the arcs with individual cord moves, basically a circular interpolator.
The files come out with a lot of blocks, but it works good. I will send it to you if you want.
Send me your e-mail address. Send to rickcaddell@epbfi.com.
Old Man
From: XDJazzz [mailto:notifications@github.com] Sent: Thursday, May 12, 2016 6:51 AM To: synthetos/TinyG Cc: rickcaddell; Author Subject: Re: [synthetos/TinyG] G02 and G03 are sometimes skipped and the cutter path is a straight line to the endpoint (#174)
I'm having a CNC Lasercutter and we're running into the same problems. Some arcs are ignored and replaced with straight lines. The G-codes were generated with an extension in Inkscape. Example;
"G02 X303.5451 Y66.3705 I5.0418 J4.5767"
Would using R... instead of I... & J... be the solution? Is there an alternative way to generate G-codes from an image?
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/174#issuecomment-218723631 Image removed by sender.
There is a macro in ChiliPeppr that already does this. It does it by just taking the data from the ChiliPeppr 3D viewer which did the hard work of creating lines from arcs. It was hard to get all the arc rendering totally correct and it took the community to help out because of all the edge cases. It’s easy to visualize whether ChiliPeppr has the arc correct or not because the 3D viewer is so good.
Why not just take the Javascript code and macro further rather than try to reinvent in .NET?
From: rickcaddell [mailto:notifications@github.com] Sent: Friday, May 13, 2016 4:12 AM To: synthetos/TinyG TinyG@noreply.github.com Subject: Re: [synthetos/TinyG] G02 and G03 are sometimes skipped and the cutter path is a straight line to the endpoint (#174)
To get around the problem with TinyG, I have written a program in Visual Studio that runs on Windows that
takes a GCode file and replaces all the arcs with individual cord moves, basically a circular interpolator.
The files come out with a lot of blocks, but it works good. I will send it to you if you want.
Send me your e-mail address. Send to rickcaddell@epbfi.commailto:rickcaddell@epbfi.com.
Old Man
From: XDJazzz [mailto:notifications@github.com] Sent: Thursday, May 12, 2016 6:51 AM To: synthetos/TinyG Cc: rickcaddell; Author Subject: Re: [synthetos/TinyG] G02 and G03 are sometimes skipped and the cutter path is a straight line to the endpoint (#174)
I'm having a CNC Lasercutter and we're running into the same problems. Some arcs are ignored and replaced with straight lines. The G-codes were generated with an extension in Inkscape. Example;
"G02 X303.5451 Y66.3705 I5.0418 J4.5767"
Would using R... instead of I... & J... be the solution? Is there an alternative way to generate G-codes from an image?
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/174#issuecomment-218723631 Image removed by sender.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/synthetos/TinyG/issues/174#issuecomment-219015418
The latest version of Goko provides a similar feature. A modifier system allows to modify GCode files. One of the modifier is a Segmentize which approximate an arc with segments.
Rick, I have tested your code and it's a nice 1/4 arc (roughly 90 degrees). I'm running a Shapeoko2 profile with the current master build 440.20. Do you have any other examples of this problem? Or anyone else does?
@XDJazzz - Can you please provide some more of that file? I need to know that starting point of the arc (i.e. the endpoint of the previous line) in order to test. - Thanks.
Alden,
Thanks for spending the time on this. Note that I am running Master Candidate 440.19, not 440.20 like you are.
I tried 440.20 and it works but 440.19 does not.
Maybe the problem here is that I do not understand the version scheme. I was assuming that Master is
the most stable, Master-Candidate is like a beta test next to be promoted to Master, and Edge is a science fair
project, that will be promoted to Master-Candidate when all the issues are solved.
The version numbers are confusing to me (ie. Master-Candidate (440.19) is a smaller number than Master (440.40)),
but I am confused most of the time. For my edification, what is the version numbering scheme?
I am using 440.19 because I like to have the latest features, and do not mind testing them. What I am afraid of is that
when 440.19 is promoted to Master it will have the arc issue.
Here is the complete program. Some arcs work (the last few) some don't (the first few).
G20
G0Z0.8000
G0X0.0000Y0.0000S12000 M03 M08
G0X2.2500Y3.6875Z0.2000
G1Z-0.1250F5.0
G3X1.3125Y2.7500I0.0000J-0.9375
G3X1.3131Y2.7157I0.9375J0.0000
G1X1.3249Y2.5978
G1X1.3515Y2.4823
G3X2.2500Y1.8125I0.8985J0.2677
G3X2.6233Y1.8900I0.0000J0.9375
G1X2.6974Y1.9261
G1X2.7681Y1.9687
G1X2.8348Y2.0172
G3X3.1875Y2.7500I-0.5848J0.7328
G3X2.7702Y3.5299I-0.9375J0.0000
G1X2.7001Y3.5724
G1X2.6265Y3.6086
G1X2.5502Y3.6381
G3X2.2500Y3.6875I-0.3002J-0.8881
G0Z0.8000
M05 M09
G0X0.0000Y0.0000
M2
Old Man
From: Alden Hart [mailto:notifications@github.com] Sent: Sunday, May 15, 2016 10:15 AM To: synthetos/TinyG Cc: Rick Caddell; Author Subject: Re: [synthetos/TinyG] G02 and G03 are sometimes skipped and the cutter path is a straight line to the endpoint (#174)
Rick, I have tested your code and it's a nice 1/4 arc (roughly 90 degrees). I'm running a Shapeoko2 profile with the current master build 440.20. Do you have any other examples of this problem? Or anyone else does?
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/174#issuecomment-219288276 Image removed by sender.
The only branches that should be up on Synthetos/TinyG are Master (440.20), Edge-0.97 and Edge-0.98. You may need to update your git repo. You can delete 440.19. The build numbering only gets larger, so 440.20 supersedes 440.19 - which was never released.
The arc problem should not recur, and I'll add your tests into the regression suite in the tg_pytest project.
UPDATE: I ran your full file on 440.20 and it completed successfully. Do you see he same results?
Alden,
The only way I know how to update TinyG firmware is from the download site http://synthetos.github.io/
and the TinyG Updater which I prefer.
The download site has these versions :
Branch
Version
Download Link
master
440.20
tinyg-master-440.20.hex http://synthetos.github.io/binaries/tinyg-master-440.20.hex
master-candidate
440.19
tinyg-master-440.19.hex http://synthetos.github.io/binaries/tinyg-master-440.19.hex
edge
446.19
tinyg-edge-446.19.hex http://synthetos.github.io/binaries/tinyg-edge-446.19.hex
The TinyG Updater shows the same as the above.
Old Man
From: Alden Hart [mailto:notifications@github.com] Sent: Sunday, May 15, 2016 11:53 AM To: synthetos/TinyG Cc: Rick Caddell; Author Subject: Re: [synthetos/TinyG] G02 and G03 are sometimes skipped and the cutter path is a straight line to the endpoint (#174)
The only branches that should be up on Synthetos/TinyG are Master (440.20), Edge-0.97 and Edge-0.98. You may need to update your git repo. You can delete 440.19. The build numbering only gets larger, so 440.20 supersedes 440.19 - which was never released.
The arc problem should not recur, and I'll add your tests into the regression suite in the tg_pytest project.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/174#issuecomment-219293698 https://github.com/notifications/beacon/ALKosQLBw6rk9Kn5CZAJMa3sY9OnUKKLks5qB0FXgaJpZM4IVFhU.gif
Looks like this issue is still open. Please see issue 181.
Thanks - Brad
I can second that the issue is still open with 440.20. Please see attached gcode. Its a simple star generated via makercam where the edges contain args. Problem: Some of the arcs on the edges are milled correctly where other edges won't move the arc but cut straight to the next point after the arc.
G21 G90 G40
G0 Z3
T0 M6
G17
M3
G0 X31.948477157360408 Y14.569543147208122
G1 Z-1.5 F200
G1 X48.84263959390863 Y5.687817258883249 F300
G3 X51.17005076142132 Y7.091370558375635 I0.7385786802030457 J1.4060913705583755
G3 X51.147208121827404 Y7.3604060913705585 I-1.5862944162436547 J0
G1 X47.91878172588832 Y26.17258883248731
G1 X61.588832487309645 Y39.49746192893401
G3 X62.068527918781726 Y40.63451776649746 I-1.1091370558375635 J1.1370558375634519
G3 X60.70812182741116 Y42.20558375634518 I-1.5862944162436547 J0
G1 X41.819796954314725 Y44.9492385786802
G1 X33.37309644670051 Y62.065989847715734
G3 X30.525380710659896 Y62.065989847715734 I-1.4238578680203045 J-0.7030456852791878
G1 X22.078680203045685 Y44.9492385786802
G1 X3.187817258883249 Y42.20558375634518
G3 X1.8299492385786804 Y40.63451776649746 I0.22842639593908629 J-1.5710659898477157
G3 X2.3096446700507616 Y39.49746192893401 I1.5862944162436547 J0
G1 X15.97715736040609 Y26.17258883248731
G1 X12.751269035532996 Y7.3604060913705585
G3 X12.728426395939085 Y7.091370558375635 I1.5634517766497464 J-0.2690355329949239
G3 X15.053299492385788 Y5.687817258883249 I1.5862944162436547 J0
G1 X31.949238578680202 Y14.568527918781726
G0 Z3
M5
M30
Note:
I am planning on turning over the source of an application that runs a milling machine using TinyG, however there are two issues that I really think need to be addressed before I can do that. I want to test these before turning over the source. Both issues have been submitted but nothing has become of it. One issue is G02 and G03 not working all the time. The other has to do with keeping in syc with the TinyG as far as program execution. That will be submitted in another issue.
G02 and G03 are sometimes skipped and the cutter path is a straight line to the endpoint. I have analyzed this (See attached spreadsheet) and found that the CAM system is outputing the best I and J values given the three digit percision of the TinyG.
Circle.xlsx
Alden Hart responded to a previous issue about this, and said he fixed it, and he very well may have, but I have not been able to us the Easy Updater to get that version. All of the versions out there still have this issue.
If this is fixed I would greatly appreciate the edge being updated.
Old Man