Home › Forums › TinyG › TinyG Support › Milling pockets with smaller pockets error
- This topic has 3 replies, 2 voices, and was last updated 8 years, 9 months ago by cmcgrath5035.
-
AuthorPosts
-
January 25, 2016 at 7:31 pm #9293John JMember
I have been fighting with this all day long.
I have been using fusion360 CAM to generate the g code. I have never had a problem until today as I generally use this for simple parts.
The problem comes in when I have a pocket with a shoulder in it and I have to preform a secondary pocket function to clear out the second pocket.
The first pocket will work fine. Then on the second pocket the tool will simply helix all the way down to the bottom of the part and then rapid in a straight line to the outer edge of the pocket with out clearing any other material.I have been on the fusion360 forums all day. They looked at my code and said everything seems fine and even when you run the code in the simulator it works perfectly.
I believe this is a problem with the tinyG as I can hear it pausing for a split second where it should begin to spiral out to clear the pocket. I have it set to take .100″ depth of cut per pass. Instead it will continue the helix down.
I sure would like some help on this of if its a known problem to let me know so I can come up with a work around.January 25, 2016 at 10:43 pm #9294cmcgrath5035ModeratorFor starters, I hope you have reviewed the tinyG wiki, especially
with focus on Gcode commands supported and not yet supported.
It would be helpful if you could post to a cloud drive (Dropbox, Gdrive, etc) you parameter set (a $$ dump) and the problematic Gcode for a look by the devs.
Post a link here.Also, what OS are you using to interface with tinyG, and what program to send Gcode (CoolTerm, UGS, Chilipeppr, etc)?
January 26, 2016 at 6:47 pm #9295John JMemberThank for your your response!!!
Sadly now I feel like I cried wolf. I tried it one more time about 1 hour ago after leaving the controller off all night long and for no obvious reason. Now it works like a charm.
I did review all the supported g code and I confirmed with fusion360 that everything is kosher last night.
Could it have been a problem with the controller storing something it shouldn’t have and then leaving it off so long finally cleared it?
I did reset it a few times yesterday and it had no effect.
The file I loaded was the same file.I guess this will remain a mystery as it works 100% now so I can’t repeat the errors I was having yesterday.
None the less if it happens again I will be prepaired with the info you requested above.
I am using chilipeppr in windows10. and I’m using fusion360 CAM and tiny g post processor they have built in.January 27, 2016 at 6:46 am #9297cmcgrath5035ModeratorHmmm, not much difference between hitting the reset button (or power cycling) and sitting over night, unless your tinyG was overheating.
But what you describe does not sound like motor driver shutdown due to overheating.
Do you have a fan for tinyG?
If problems return, try generating your Gcode without ARCs(replacing them with short straight moves). Some folks have had issues with Arcs in the X-Z or Y-Z direction. When you mentioned helix movement, I sort of expected to hear that.
Good luck
-
AuthorPosts
- You must be logged in to reply to this topic.