Home › Forums › TinyG › TinyG Support › tinyg interprets G2/G3 code incorrectly
- This topic has 35 replies, 8 voices, and was last updated 7 years, 3 months ago by
Vex.
-
AuthorPosts
-
November 13, 2018 at 6:57 am #11192
siredmar
MemberI second the problem with 440.20. I did comment on issue (#174 on github.
I don’t necessarily use Fusion 360 to generate my gcode. I do use other tools like makercam or pcbgcode for eagle as well.
G2/G3 moves should be working to have a reliable machine :-/I read about the issue on separate sources but didn’t find the answer for the question: Did the problem with G2/G3 ever got solved and if so, which firmware version shall i use?
Maybe someone can clear things up. I guess i’m not the only person on the planet who got this issue.
November 13, 2018 at 9:18 am #11193cmcgrath5035
ModeratorMany have run into the issue, most it seems have figure ways to mitigate.
Work in MM, tweak post processors and the like.Some have found the current edge, 449.01 better in some situations
http://synthetos.github.io/November 13, 2018 at 9:41 am #11194siredmar
MemberI suspect that current energy will be put into the development of g2core. Is the G2/G3 problem still present in this firmware? Will there be a backport to TinyG?
November 13, 2018 at 3:46 pm #11195siredmar
MemberI tried my gcode file with success on edge 449.01.
Can you explain how release cycles work for TinyG?November 13, 2018 at 4:09 pm #11196cmcgrath5035
ModeratorThat is good news about 449.01.
Release cycles are not really planned as the code base is quite mature.
Release 449.01 has been in Edge for a couple years now so that folks like you could experiment.As you observe, G2core is getting the bulk of the developers focus.
At some point in the future, there will likely be a final (?) tinyG release that includes functionality and capability backported from the G2core base that makes sense for tinyG hardware and compute capabilityNovember 23, 2018 at 8:31 am #11201Vex
MemberI can second the G2/3 commands of 449.01 seem to be working for the facing operation I did. Though I did notice that zeroing G54 no longer seems to function correctly while using that via CP. The command seems to be sent/accepted, but the resulting digital DRO does not reflect the change. Consequently when I have attempted to verify it will proceed to travel to the original G54 as opposed to the one that was just zeroed. The remedy seems to be to either send a reset command within CP and get lucky, or disconnect from JSON, and manually power cycle the TinyG.
I’m unsure if this is an issue with 449.01 or with CP/JSON settings. I do know it was working in 420 with the same $$.
-
AuthorPosts
- You must be logged in to reply to this topic.