On Tuesday 11 September 2012 11:46:15 SourceForge.net did opine: > Bugs item #3563795, was opened at 2012-08-31 11:13 > Message generated for change (Comment added) made by > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=106744&aid=3563795&gro > up_id=6744 > > Please note that this message will contain a full copy of the comment > thread, including the initial issue submission, for this request, > not just the latest update. > Category: Motion Controller > Group: None > > >Status: Deleted > >Resolution: Invalid > > Priority: 5 > Private: No > Submitted By: https://www.google.com/accounts () > Assigned to: John Kasunich (jmkasunich) > Summary: Positional drift when probing > > Initial Comment: > During long, repetitive probing operations, large discrepancies develop > on all axes between actual position (as measured by dial indicator) and > reported position (LinuxCNC's "Machine Actual"). > > Two G-code programs are > > ---------------------------------------------------------------------- > > >Comment By: https://www.google.com/accounts () > > Date: 2012-09-11 05:24 > > Message: > Apologies. I was able to obtain and use a frequency counter to verify > that the problem was not with LinuxCNC/Mesa 5I25/7I76, but with my > stepper drivers, so I'm removing this trouble ticket. > > ---------------------------------------------------------------------- > > Comment By: https://www.google.com/accounts () > Date: 2012-08-31 11:33 > > Message: > (sorry about that, thought I could add files before completing bug > report.) > > Two G-code programs are going to be attached to this bug report to help > replicate the problem. The first, "test_steppers.ngc", starts at an > indicator-measurement point, makes a large number of traversals back and > forth between two other points, and then returns to the > indicator-measurement point. It is based on the one listed at > > http://linuxcnc.org/docs/devel/html/common/Stepper_Diagnostics.html#_ste > p_timing > > The second program, "test_steppers_with_probe.ngc", starts at an > indicator-measurement point, traverses to a second point, and then > probes toward a third point, going back and forth in this way between > the 2nd & 3rd points for a large number of iterations before returning > to measurement point. > > *** > > I ran the first (non-probing) program along Z axis for 200 iterations > starting with zeroed 1/10,000-inch indicator. When program returned to > measurement point, indicator read -0.0002 inch. Ran for 500 more > iterations; returned to -0.0003 inch. Ran for yet another 500 > iterations; returned to -0.0001 inch. These numbers are all within > +/-0.0005-inch tolerance of my Z leadscrew. This ruled-out issues with > acceleration/velocity, driver timing, electrical noise. > > I then ran the second (probing) program for 200 iterations. It returned > to +0.0014 inch. After 500 more iterations it returned to +0.0053 inch. > After yet 500 more iterations, it returned to +0.0096 inch. > > This seems to isolate the problem as something specific to probing. > > *** > > Details of my setup: > - Ubuntu-10.04LTS installed via LinuxCNC-Live CD > - 8,000-nanosec latency > - Mesa 5I25/7I76 stepper control > - Keling KL-4042D drivers configured for 1/10 microstepping > - Keling NEMA-23 KL23H276-28-4B 270 oz-in steppers, 200 steps/rev, > running warm to touch > - HAL configured for 5-microsec steplen/stepspace, 20-microsec > dirsetup/dirhold > - Max & traverse vel of 1.0 in/s, max accel of 10.0 in/s^2 > - Taig CNC milling machine with 20-tpi leadscrews, +/-0.0005-in > tolerance - Backlash measured within +/-0.001-in > > Additional details: > - Verified issue on LinuxCNC 2.5.1, and with most recent devel version > from git repo > - Verified with variety of HAL probe setups, including one with > debouncing, and one very vanilla > - Issue also present when using software step generation > > I have recently been running operations with lots of probing, and have > been seeing machine drift of up to 0.05 inch.
I can't quantify the effect, but it did seem to have effected the results I got when I did several contour scans of the floor plate in my rifle, which I was considering replacing with an alu part. It seemed the drift got worse when I did the scan in finer steps. Doing the last scan in a 10 thou grid, I went back and manually tested along the top of the dome and got triggers up to 25 thou off from what was recorded during the scan, with the worst error being the starting, all zeroed point. Slowing the feed rate by 10x didn't appear to effect the results, with the last scan at .05" feed was no better. I did carve the result, but had neglected to establish a registration point at both ends (my bad) so it was obvious I wouldn't be able to register the two faces. The internal work was also more complex than I had bits for because of the follower spring retainer dovetails. Another of my unfinished projects that kept me out of the bars for a month or more. :) > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=106744&aid=3563795&gro > up_id=6744 Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! What's page one, a preemptive strike? -- Professor Freund, Communication, Ramapo State College ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
