Hi:
The idea of having one slot larger than the others is not implemented as before. In this current testing
you need to have two inputs. One from the TIMING input, which simply has the sensor looking at slots,
and one for INDEX.
An encoder on Encoder 3 can replace the TIMING input, but the INDEX input is needed either way. So
the slotted wheel should have all slots sized the same. As to the number of slots? Hard to say. Steve willl
be testing , as I think John will , with a 90 slot wheel. The way the driver is written it will count the slots
and adjust its reading based ont he number of slots it reads, the plugin will display a DRO showing how many
slots have been seen per rotation, it should be rock steady unless theres a problem.
The number of slots will affect maximum speed available. For example, Craig recently reported he can read up to
240,000RPM with just the index pulse, so a 90 slot wheel will likely read 2666RPM as a maximum speed all things
considered. If you use a 64 slot wheel, then about 3750 woudl be the theoretical max.
If you attempt to use a 2000count encoder, then Id expect 120RPM is the max. SO its important
to try to use as few slots as you think you can, but there are things to be considered.
I wrote this test assuming that 64 slots woudl be the minimum slot number, which would make the system sense
speeds 64 times per rev. This shoudl in theory make things track 64 times better than before. Having less slots will
make the correction average over more than 1 rev, which may or may not work, we'll need data to see.
Currently, the test only tests the RPM sensing for stability. Once thats done Ill implement the correction of slowdown.
There are a couple ways I can do that, with instant time evaluation on a per slot basis, or a rolling avergage of slot times.
Im still not sure which will be best. PResently, the RPM is very stable, on mine at 0.2RPM at 400RPM, but the driver is using
a rolling 64 slot average to make it this stable. Wether we use the same 64 slot rolling average as a ratio to a locked average at
thread start, OR use a instant 1 slot time against that rolling average time is the question. Secondarily the issue will be if either
will track toghtly enough to make a good trhead over long time domains is important.
I can guarentee nothing here. What we know is that short threads seem fine using 1 rev count time locked at thread start,
and slowing based on instantaneous following 1 slot times as a ratio. Thats what we've been using. But the variability of those times
seems to force a slow time degradation, its my hope that by making the system time average out the errors that everything will
lock in much tighter. It will be interesting to see. The idea of a dual ratio bresenham division ration for control came to me a few
months ago, the numbers seem to crunch well and Im very curious to see if it works as well in reality as it does in theory.
Since most will thread at speeds no faster than 1000RPM, a 90 slot wheel seems ideal, or a 25 line encoder (100 counts per rev),
I just wouldnt increase it much higher than 250 counts per rev myself, as that will limit you to about 1000RPM.
Now those numbers are all at 25Khz kernal. At 45Khz your maximums shoudl be almost double the stated values.
For those curious as to the issue, or why EMC for example seems to have a more exact responce, Ill explain just how they do it, vs
how I do it.
In EMC, the trajectory planner runs at a servo rate that is in real time. As one slot passes by the system calculates how far the Z
should have moved in that time frame, and advances it by that amount. This is exact and real-time. But in Mach3, the motion is already
precalculated and buffered for up to 2 seconds. There is no time machine that allows me to go back and correct the time. SO, what I have
always done is check the rotation time, and knowing the time the pulses were prepared for, I slow the stream by the average differential,
and this works well for short threads. But over time an error is creeping in. Its my hope that by averaging out the slot times I get a much more
representative time measurement without the small variations caused by some sensors or systems that fluctuate slowly. The error seems caused
by random fluctations in the time measurement, thus the 5RPM variability shows in the display. Since I now get a very exact reading, its should be
possible for m to better identify the slowdown caused by the spindle itself, and negate the slowdown caused by system responce.
In this method you cannot actually stop the spindle, it will correct down to a very slow speed , perhaps 90% slowdown, but stopping would
cause a stream overshoot ( but then that was always so. ). The overshoot previously could be as much as 1 rev, but in the 90 slot scenario, the
overshoot shoudl be 1 slot or so, which woudl be trivial in the case of 90 slots per rev at slow speed. If it all works I may be able to set a stop point
where the Z motion stops, and picks up again after passing an index point at a certain minimum speed, but thats in the future if all works well.
This is all very experimental, hasnt been done before as I can tell, so we're in a very grey area. If it works in reality as well as on paper, we'll
be real happy, if not... well, we'll have a steady RPM display and the code will allow for other toys that dont require the exactitude of threading.
Plans are in the works to use this timing method to do other things, such as sense stalled steppers and auto corect positions while slowing the system
to allow motors to catch up. A type of closed loop control. Who knows, its only though such experiments that I can guage how usefull such
timing technology is.
Thx
Art
Topic: Problems threading on the lathe (Read 599563 times)
Guest