On Wednesday 16 May 2018 11:46:15 Gene Heskett wrote:
> 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.
In case anyone cares, here is a screen snapshot of it running a g33.1
peck cycle, and showing the output overtravel in both turns of the
spindle and distance its overshooting. Its the overshoot distance I
would like to send back to the gcode in the form of a #<_varname>.
How can I do that in the .hal file?
--
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
