Home › Forums › TinyG › TinyG Support › Weird inaccurate first move after homing
- This topic has 5 replies, 3 voices, and was last updated 10 years, 4 months ago by psyko.
-
AuthorPosts
-
June 23, 2014 at 7:11 am #6218psykoMember
Hello,
While working with my Shapeoko, I noticed the circle were not really round (about 0.8mm off).
So I decided to make sure :
– my axis move the required amount,
– my machine is properly squared.I only manage to test the motion travel ( to make sure the travel/revolution was ok. It ‘s about 39.5… something right now) on the X axis and here is my issue.
So the operation is :
– Homing (which works great, within +-0.02 mm)
– Set the digital caliper to zero (tied to the x axis makerslide rail)
– Move 1mm by 1mm and measure the resulting move.And here is the issue. My very first 1mm move is always less than a mm (around 0.68 to 0.75mm). The other mm after that are all good (around 0.99 and 1.01 mm).
The issue is probably not the caliper, since I tested it on precision shaft and it gives me the good dimension within 0.02mm range. but 0.70 instead of 1mm is a huge difference…
Does anyone have an idea about the cause ? Something I’m doing wrong ?
There is no reset/motor idle/power cut between the homing sequence and the very first move.Thanks
June 23, 2014 at 10:11 am #6219cmcgrath5035ModeratorMy first thought when reading you question, assuming X and Y axis parameters are identical and set accurately, was belt tension. My second thought was “is the home position too close to a rail, such that the the motors are holding the home position under some sort of stress” ?
Is the first move still “short” if you follow this procedure:
1. jog to somewhere in the middle of the X-Y work area.
2. Set that as zero point (if using tgFX)
3. Reset tinyG (manual reset button). That will set tinyG to zero at that point and will release the holding tension on the motors so that the belt tensions should equalize and be fully relaxed when the hold current is reapplied at the end of boot.
4. Zero set you measurement system (micrometer)
5. enter Gcode F200 to set a relatively slow “non-aggressive” work velocity.
6. enter Gcode G1 X1.0 to move 1mm at F200If 1-5 works, maybe try it at higher speed and/or at different zero points around your workspace
Other thoughts
-Worn belts? I have worn my belts near the ends somewhat by ramming the machine to a rail and spinning the pully. If Home is always in the same area, I think you can expect faster wear in that zone.-Motor pully really tight on shaft?
– Tension on X carriage due to, for example, motor cabling/cabling track?
Good luck
June 24, 2014 at 8:13 am #6225aldenMemberPsyko – I’d recommend updating to the new edge branch. We have been working on a number of issues that may be related to this one. Go to the github.io download page http://synthetos.github.io/ and look for edge build 435.06 (or later)
June 25, 2014 at 5:30 am #6241psykoMemberThanks Alden, I’ll check this.
Is there any changelog somewhere to see the differences ?June 25, 2014 at 7:12 am #6243aldenMemberI still have some work to do on the changelog. It’s not as automated as I’d like and with as many commits as we do I have to go back through the commit messages and filter out those that are not important to end users.
This release (intended for master once it has some more field exposure) advanced the firmware version to 0.97, and most of the changes in config are documented on this page of the wiki:
https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97Most of the internal changes are summarized as:
– Improvements to absolute and long-term accuracy; we can now run long, multi-hour jobs with +/- 1 step accuracy, which in a typical machine translates to about 10 microns.
– New strategies in place for handling Gcode moves that are too short to draw.
– Fixed a number of bugs related to inches mode and other display problems.
For the rest I need to comb the commit messages.
July 8, 2014 at 3:55 pm #6369psykoMemberHi,
Is there any significant change in the json dial protocol since 380.05 (I know I’ll have to change the Buffer planner report)
Thanks
-
AuthorPosts
- You must be logged in to reply to this topic.