Forum Replies Created
-
AuthorPosts
-
cmcgrath5035Moderator
Thanks, good data set for review.
Nothing obvious on quick review, passed on to Devscmcgrath5035ModeratorIs this a full custom machine, or a derivative of ShapeOko, Ox or other popular machine?
Posting your full updated parameter set might help as well.
Post to a cloud service (dropbox, etc) and provide a link here if you can.
This interface makes the lines more difficult to scan for anomalies.If you are running via CoolTerm, you are likely using the G54 coordinate system, which is the default. Are you sending commands a line at a time from coolterm, or sending a pre-built Gcode file?
Unless the GCode file is implementing offsets, I don’t think you are having coordinate system issues.I don’t really understand what you mean here:
When I go back to move machine, especially in Y direction, it shows Y is moving out of working envelop about 2/3 down.
cmcgrath5035ModeratorCan you identify what CAM package created your Gcode?
There may be a tweak required to the back end processor, if one exists.Uploading your Gcode to a cloud drive and posting a link may also be helpful in diagnosing the issue.
Some CAM packages generate very aggressive arc Gcode that has been problematic for tinyG.
Running in mm mode, if your are not already, may help
cmcgrath5035ModeratorThanks for the follow up.
I believe the “proper” way to grant users the necessary permissions would be the path of adding the user to the group sharing “rw” permission with root, if so configured.
Using “sudo chmod 666 /dev/ttyUSB0”, grantinting rw-rw-rw-, works but might be considered excessive granting on a multi-user platform.
cmcgrath5035Moderatorusing coolterm
If CoolTerm, what Prevue screen are you asking about?
cmcgrath5035ModeratorI assume you are using Chilipeppr?
Make sure to set Xmin, Xmax, Ymin and Ymax to the size of your machine.
Prevue should scale accordinglycmcgrath5035ModeratorWindows?
Try this procedure (avrdude):July 23, 2015 at 6:42 am in reply to: Takes off kind of opposite I guess, I'll try to explain my problem. #8090cmcgrath5035ModeratorI just saw your post over at CP.
You might try fw=440.16, there are always tweaks for arcs being performed, so the possibility some improvement.July 23, 2015 at 6:34 am in reply to: Takes off kind of opposite I guess, I'll try to explain my problem. #8089cmcgrath5035ModeratorFrom your description it sounds like potentially an inch mode issue combined with arc issue?
Perhaps post your Gcode file to a cloud drive and the devs could look at it or use parts of it for another test case.You might also try to regenerate the job in mm to see if that helps.
July 23, 2015 at 6:23 am in reply to: TinyG support for Subroutine calls / O Codes / M98 and M99 #8088cmcgrath5035ModeratorI don’t see G98 or G99 on the list of supported GCode commands in the wiki:
There is some “preliminary discussion” here:
Repetition of code loops might be possible with Chilipeppr macros, or other CAM interface
cmcgrath5035ModeratorWhat device blew?
Use this to describe area of boardThe chance that a recoverable/repairable failure that might be protected by short/current protection is rather low.
cmcgrath5035ModeratorSee
Your FW is very out of date.
This procedure will load 440.16, which has a bug but is still much better than 435.10.FW 440.17 will be posted soon, resolving the bug.
Keep an eye out.cmcgrath5035ModeratorOK, in Coolterm do a $$ command, then copy and paste the results to a file per the method in URL.
cmcgrath5035ModeratorWe need a whole lot more information to be of help.
About all we know at the moment is you have a belt machine, a big one.Spinning belts can be speed, loose belts, or a combination.
What OS you run?
How are you communicating with tinyG?
Post your parameters for a look:The wiki is your best friend – keep reviewing, after a while it will make more sense.
cmcgrath5035ModeratorNope, 30V Max input to tinyG.
Some spindles tend to be noisy, so dual PS helps keep tinyG quieter too.
-
AuthorPosts