Hello Guest it is March 28, 2024, 04:09:37 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ART

1011
Video P*r*o*b*i*n*g / Re: MachCloud point viewer program
« on: April 29, 2009, 02:53:07 PM »
Wow.. nice work.

Art

1012
General Mach Discussion / Re: Problems threading on the lathe
« on: April 26, 2009, 07:38:53 AM »
Hi Chip.


Thx, you and rich have pretty good numbers,

your 99 slots seems to miss one slot per rev, and 999 seems to lose about 10.. thats interesting, we'll see how real world
conditions do. I still have one computer reading weirdly so whatever I find may reflect soem weakness somewhere, but you
two are fine fer now.

 Thx for the tests, preciate the results.

Art

1013
General Mach Discussion / Re: Problems threading on the lathe
« on: April 25, 2009, 05:57:11 PM »
Chip:

 Excellent! , thanks. Your numbers are good. Is the Slot based RPM steady? Mine stays within 0.xx of 1 RPM typically.
Correction is not yet turned on, so slowing the spindle will only show you a Q value which indicated exactly how much correction
will be applied in realtime as the thread progresses. Gree means its slowing down from start, red means its speeding up.

 Yours seems perfect as long as the slot based RPM is steady.

Thx
Art

1014
General Mach Discussion / Re: Problems threading on the lathe
« on: April 25, 2009, 11:06:33 AM »
Hi Guys:

  Heres a test driver.. Even if you use 1 pulse per rev Id like to know what happens when you try it. You have to load the driver, and the plugin enclosed.
You can set the INDEX timeing as normal, and if you dont have a slotted wheel, set the TIMING input ot the same as the INDEX input. This will simulate
a slotted wheel with 1 slot. Id be interested in your results as a diagnostic. PP mode only though.

 You can see the results with the plugin/Advanced Spindle menu item, you shoudl see a stable RPM on the second DRO, but Id like to knwo what they all say.
Take note it takes 64 revs with single slot to get a proper RPM  because its assuming a 90 slot wheel at the moment, and averaging over 64 slots.

Thx
Art

1015
LazyTurn / Re: LazyTurn
« on: April 23, 2009, 04:49:42 PM »
HI Dave:

  Oh, it isnt important.. If OEM's get interested..fine.. but I still write the stuff for us little guys..
I always went under the theory of  "If you build it..they will come. ) LOL

Art
\

1016
LazyTurn / Re: LazyTurn
« on: April 23, 2009, 04:04:48 PM »
LOL, with over 38000 views on this topic.. Im thinking a lot of people feel the same way.

 Seriously, I hope to drive myself to the secondary sorting next week.. and if that works all thats left is a finish pass.
Not that any of that is easy, but at least theres light in the tunnel down there somewhere..

 Im getting a few letters asking when it will be available, some OEM's seems to want it for lathe work, but it'll be a couple
months yet till completion I think.. Next year we'll talk facing and boring maybe..

Art

1017
LazyTurn / Re: LazyTurn
« on: April 23, 2009, 10:53:17 AM »
Dennis:

  Its possible, I just got hijacked a bit on other code.. and Im still ruminating on cut order for the secondary passes..
I shoudl be done other work soon..

Art

1018
General Mach Discussion / Re: Problems threading on the lathe
« on: April 22, 2009, 07:46:59 AM »
Hi Guys:

  Actually, even if we only had a slotted wheel I could give you an indexable home. The question is if we can say withotu doubt that no slots are missed during the time the machine is on. If we KNOW that to be true, Itd be easy enough to give you a button that sets any particular slot to be the index slot. Youd simply revolve the spindle by hand to a certain spot, and hit a button that sets it as the index.  There are multiple ways to deal with such things but only if we know that the reading of the slots is absolute and we never lose any.

 Anyway, there are several things that can be done with an advanced Spindle control plugin that we can look at over time once we know if threading will work
under the proposed sheme. Id like to simply have multiple setup selection onthe plugin that allow for various configurations, each perhaps with known %error
tolerances on threads.

  More as data comes in I guess. :)

Thx
Art

1019
General Mach Discussion / Re: Problems threading on the lathe
« on: April 21, 2009, 01:21:22 PM »
Hi :

 Yup, I do want the slots to be variable, and Id use 30 without any hesitation, or even 10  ( or 4.. ), but I suspect any accumulative error
will be better corrected by more slots, while more slots will limit RPM more and more, so its all a tradeoff, a fast speed user may decide that
8 slots is fine, whlie a slower lathe may be better off with 90 or 100.

  In the end, if it all works I may just add a DRO so the user can tell MAch3 how many slots there are, in which case th eindex pulse woudl no longer
be required as long as the user is SURE that no slot ever goes missing.. I can then simply start counting from an arbitrary position and count the slots
to know where I am. The advantage of the index slot is simlpy that I can count the slots and double check that noe went missing.. Not really required
if we fnd the slots alone are extrememly stable and never get lost.

  Ill add code to determine that soon, and youll be able to see if , over time, any single slot was missed, if none are after several hours, and everyone finds
that to be true, the requirement for the second sensor for index will go away.

Thx
Art
 

1020
General Mach Discussion / Re: Problems threading on the lathe
« on: April 21, 2009, 07:47:20 AM »
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