On Sunday 03 January 2016 10:00:50 Cecil Thomas wrote: > I guess I wasn't as clear as I had hoped about my question. > To be more specific: > When the commanded value for a move is converted into steps (or > microsteps) and that number of steps contains a fraction....What > happens to the fractional part of a step???? > > I am not speaking of dropped steps as would be the case in a stepper > whose movement is inhibited by not being able to complete a step due > to load, velocity, acceleration, setup or duration. > I am only questioning whether LinuxCNC drops the non integer portion > of a step when converting from commanded position change to steps. > > I have assumed that the system can only issue steps as an integer and > that the fraction is dropped. If this is the case then the system > can ONLY "round down" so all commanded moves that don't convert to > integers wind up being short of the desired move. Never "long". The > only way the error can "even out" is by virtue of having the effect > balanced by equally "short" moves in the opposite direction. > > As I have designed my program there are many more moves in one > direction than in the other so I assume that the "shortness" > accumulates over a large number of moves. My calculations for the > accumulation of error in my system seem to match the measured > results. I can change my program to try to balance the forward and > back moves or I can add a stage of reduction to the A axis to reduce > the magnitude of the "leftovers" or both but before I proceed I would > like to be sure that the trajectory planner does as I assumed "Only > round down". > > > Cecil
I tend to write my code in loops, and I have never been presented with such an error that wasn't traceable back to PEBKAC. The biggest problem I have with my cheap 4" motorized table is backlash, and I assume some cyclic error because the bullgear has at least a thou of eccentricity in it. I wrote, 2+ years ago, a program to sharpen a table saw blade by polishing the face of the tooth, writing it so that the table revolved at least 50 times, but each revolution was calculated to take about .0001" off the face of the tooth. I wanted a touch that would not cause any great flexure in the diamond coated wheel in the dremel's chuck because it was facing it at as close to zero degrees as I could mount the dremel. It took most of 2 days to run. That blade was of a tooth style no longer marketed by anybody, a CMT with an ATBF tooth sequence, a high angle tooth to the left, one just like it to the right, and a flat topped tooth that ran about a thou lower than the high angle tooth's tips. It gave the cleanest cuts in hardwood I've ever seen. Bottom of the kerf is dead flat. And it was even better after that resharpen. I have 2 of those blades, and they will not be thrown away until there is no carbide left to sharpen. But I've not yet EDM'd the bolt holes to bolt it to the rotary table for the other blade yet. The one I sharpened is still on the saw, and has cut quite a few feet of the 1/8" thick side sheet alu of a wrecked UPS stepvan that I use to make boxes for my stuff. And it just cut out all the mahogany to make 3 more of those blanket chests on the Dec 2014 Fine WoodWorking cover. Still reasonably sharp, no burns if I keep the wood moving. So, whatever linuxCNC's code does with the leftover fractional steps, I haven't a clue, other than it is totally not a problem here. I suspect it does save it, and add it (or subtract it as the case might call for) to its calculations for the next move. That would average it out to less than a .0001" dial indicator can detect. OTOH, my tables drive is 90/1, or 4 degrees per full rev of the motor and I am microstepping /8. Given that ALL of the BoB's we can get from fleabay are needlessly opto-isolated (because most of the common drivers we use are already isolated), and that the opto's are call a surveyor & set stakes slow in comparison to all the other edge delays in a typical system, the first thing I would do is add at least .5 microseconds to the step timeing, and at least 1 more microsecond the direction setup and hold timings just to see if the error goes away. FWIW, I have noted that there CAN be a difference in speeds attained depending on the direction so I scoped the output and found that when moving in one direction, the direction was being changed, then reverted after the step had been issued. I do not recall if that was a software step drive, or the 5i25's output but it was far enough back up the calendar count that it had to be software stepping. I certainly do NOT see that on my lathes cnc4pc C1G BoB's leds which are visible in normal operation, and theres a 5i25 doing the work in that install. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
