On Tuesday 15 May 2018 21:32:28 Gene Heskett wrote: > Greetings; > > I have the gui sorted, looks good. But my exercise code I'm using > should have a fixed starting point for each poke at the tapping, but I > see in the backplot, it is very slowly drifting to the left. This is a > stepper machine, so it has no idea where the machine actually is. So > where is this drift in the backplot? Its not hugely serious at this > point, but the fact that its doing it is a concern. I'm in the house, > listening to the distant weather, but I'll repeat this tomorrow with a > dial on the carriage to see if its physically moving its stop point > where its waiting for an index pulse while running a loooong string of > g33.1's. > > Another thing is just how fast the oveshoot goes up with increasing > spindle revs. I may have to play with the vfd some, and adjust the > limit3 I have in the path to the vfd to slow that down, trying to make > a true 4 quadrant control. > > At 100 rpms, and an empty ER-42 mounted, overtravel is .28 turns, > distance is .01390". Raise the revs to about 350, and its over 2 turns > and .110". I hate to think what it would do with the 8" 4 jaw mounted, > thats a 40 lb flywheel.
Sleeping on what I have done, I think the actual capturing of the overtravel encoder count can be done simpler. So I may play with it some today. The basic premise right now is to feed a pair of mux2's as sample-holds from the encoder, freezing one at the motion command reversal output, and the other when the encoder direction output has detected its actually moving in reverse by one count. The resultant frozen value is by detecting the diff in a sum2 with one gain set to -1.0000000. That sum2's output then gets multiplied by the reciprocal of counter edges, become a floating point turn(s) of the spindle. That is then mult2plied by the distance per turn obtained by the m68e0q#<-tpmm> in the gcode>, or the 1/tpi as the case may be. The display is updated 5 milliseconds after the encoder has reversed, so the first cycle starts at 0, and is updated with the first measurement at the bottom of the first forward "peck". There's a couple oneshots to stage that for a continuous output display in the chain. The thought occurs that I might be able to use that if I can get it back into the gcode, to subtract this distance from the original gcode value. That would make it so one could measure the depth of a blind hole, put that in his gcode, put the divisor calc inside the peck loop to reduce it by one, which should then track, maintaining around the same cutting depth increase but dynamically compensating for the measured overtravel. To make that work would appear to need the reverse of the M68 function in gcode, to be available to hal. How is sending of a hal developed value back to a #<_var> gcode can use done? Looking at what we have, it appears the offset module could do that. But it would slide the thread timing around, definitely not good. Is that what I should use for the compensating move for this? Sounds dangerous, as does moveoff. I'd much rather set a memory var by name and read it with a gcode reference. That s/b safe as its then subject to all of the limit switches etc. So how can I do that? Or are we stuck editing our gcode on a hole to hole basis as we must do now unless the hole is drilled quite a bit deeper for tap safety. Thanks guys. -- 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> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
