Hello Guest it is March 28, 2024, 01:28:17 PM

Author Topic: Questions on Threading With Turn on Sherline - From Yahoo SherlineCNC Group  (Read 38963 times)

0 Members and 1 Guest are viewing this topic.

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
 I think you need that enabled for threading so enable it and run the plugin again and see if it reports differently this time.
Hood

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
BOB,
You need to have the spindle feedback in sync mode checked or threading WILL NOT WORK right.
At one time, if memory serves me, threading wouldn't work at all if the index wasn't checked.


I also agree with HOOD on the single index pulse is all that is needed. That's all you need know for now
and can discuss it later on if wished.

What do you mean by step / sit a while? ie; did the z actaully move then stop? or did the stepper just turn very slowly a "small" amount and stop. In the lathe diagnostic info screen was it jumpiing back and forth between
Waiting for index trigger  / threading in effect?  It should be green in the box when waiting for the index trigger
and upon a trigger, the threading in effect box should turn green.

Can you look at the pulse signal with a scope?

RICH
 

Hi All,

This is going to be a bit long, and I'm going to address a bunch of things.  

The big news:  I got it working.  

One of Rich's "78 passes" tests yielded a bunch of nice parallel grooves.  Then I did a 1/4-20 bolt.  I started with .250" rod and didn't realize that's too big, but I was able to cut the threads and it looked great.  When I turned the finished screw down to the same size as a bolt I had, that (of course) buggered up the thread profile.  So a nut doesn't fit it, but it looks gorgeous compared to everything I've been getting up till now.  

The problem?  The big problem was that I believe it was using the wrong polarity for my sync pulse!  It was "active low" and my pulse is active high.  Sheeeeshhh.  But to get to the point where I found that I had to take everything apart again and test all the hardware.  I got to the point where I was absolutely sure the hardware was right - or as sure as I could be.  Then I was convinced it was software or configuration.  I just didn't know what it was.  

Not having the "spindle feedback in sync" in software setup was a complication.  That didn't work, and threading would not have worked without it.  When I set the sync pulse active high, it started to work properly.  

I have a good oscilloscope, a Tektronix 475 if that means anything to you.  I looked at the pulse train out of my sync pulse encoder and it was as clean as can be.  No extra pulses, no glitches, no noise - nothing but clean square waves.  While I'm sure the kind of pulse encoder many were recommending would be really good, this one works as well as it needs to.  When I set the RPM rate low enough, I could watch the tape go past the sensor and see the pulse hit on the o'scope.  When I set the speed to 60 rpm in Mach (1 rev per second), I can measure 1 pulse per second on my oscilloscope.  When I set it to 600 RPM (10 PPS), I measured 10 pulses per second on the scope.  Likewise for other easily figured out speeds in RPMs.  Since Mach was telling me the right numbers, numbers I can verify at the spindle sensor, I had to conclude the whole path from the IR sensor through my Xylotex controller and into Mach must be good.  

So I dug back into all the configuration menus and found that "active low" thing.  I must have looked at it a thousand times.  I actually threaded some screws about a year ago, so it must have all been right then.  I have no idea how it changed.  

Right now, I'm pretty tired.  I will try to put up some interesting pictures tomorrow.  I'm hoping if anyone needs to learn about threading, this message "thread" might be helpful, especially if it's complete.



Bob


Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Excellent news Bob and thanks for coming back with the conclusion. So many times a thread just stops and we kind of guess a resolution has been reached but are never sure, when it is actually written that the conclusion has been reached then it, as you say, gives others a lot of help if they have similar problems.
Hood

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
 :) Good for you Bob and have fun.  :)
You may want to check out the Canned Cycle - Threading G76 item 10.7.18 on page 10-16 of
Using Mach3Turn.
 
RICH
 

Offline simpson36

*
  •  1,369 1,369
    • View Profile
Bob
Sounds like Mach is not seeing the Index properly if it is jittering about like that.

Simpson
 Art did a bit of a write up regarding Index versus Timing , if I remember correctly ,  it all boiled down to if anything Index was best.

Hood

Hood, can you elaborate on this or point me to the writeup?

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
Simpson36,

Think you may want to have a look at this posting. There may be a few others that Hood can point you to.
There's a lot about threading in that thead as it progresses from being broken to having it fixed.

http://www.machsupport.com/forum/index.php/topic,7646.msg49006.html#msg49006

RICH

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Simpson, below is the writeup Art did, I have put the relevant paragraphs in bold but left the rest so you can see it in context.
Hood


Re: [mach1mach2cnc] Index or Timing?

Hi Guys:

Just to help clear confusion..

The INDEX input takes a one per revolution pulse. IT then calculates the speed
of the spindle from that timing,
and during a thread, calcuates if the timing from rotation to rotation slows. If
for example, the average rotation is 350us
prior to the actual motion of the thread.. ( Average time per rotation is
calculated when the spindle is on and no motion
is in effect ), and during a thread the time of one rotation is found to be
400us, this means that the last rotation took 50us
longer than the standing average ( a 14.28% slowdown) , then the axis motion is
slowed by 14.28% during the next rotation,
this repeats from rotation to rotation to end up with as near a perfect average
time of axis vs spindle rotation speed.

When using the TIMING input instead of the INDEX input, the system looks for
multiple pulses, but in particular looks
for a pulse 50% wider than the others. This 50% wider pulse is then considered
the INDEX, and the system does the
rotation speed calculation only from that pulse for the spiindle speed display.
However, the other pulses are counted, and
the total rotation time is divided by the number of pulses. SO lets say you have
4 pulses, one of which is 50% wider than the
rest. Any threading will begin on the widest pulse as the trigger, but the time
from pulse to pulse will be calculated and
compared to the total average time of rotation divided by the number of pulses.
The system will slow down axis motion to
correct for deviations between the pulses.

So more pulses will not give you a faster DRO update of rotation speed, but in
theory will correct more often for slowed
down rotations. Its been proven however, to have no advantage in the thread.
While a mathmatically theoretical advantage
exists in the multiple slot theory, any advantage gained seems to be lost in the
disadvantage of additional complexity of the
correction. There are several reasons for this internally and in the required
timing and math. My suggestion is to useĀ  INDEX
and notĀ  TIMING as a result. KISS is an important principle here IMO.


The SS is being written to use the INDEX method of timing sync at first, it
will then branch to encoder sync which is much
more exact and allows for things such as stopping a spindle and having a thread
stop and continue when the spindle is restarted.
This really required only a much higher granularity of timing than the PP
driver. TO sync to a encoder in the PP woudl require
the ability to vary the interrupt timer on granularities smaller than the
available 40us ones ( in 25Khz mode). Since the SS has
a 4MHZ maximum granularity, its much more possible to vary timing in smaller
increments thus matching exactly ( pretty much) with the varying encoder count
to count time. It is this granularity issue that guides the threading design in
current Mach3, and forces the consideration as above. By all that I mean if the
system determines a motion must slow to match a spindle, the PP driver has only
the power to create a bresenhamed output timing based on 40us granularity, the
SS could use a sub microsecond timing variation which would be invisable to the
end drivers. Any such correction can be thought of as purposely added jitter to
the output stream, Jitter slows the output stream by the required percentage but
causes a phase shift on the drivers output, so it must be kept low and the PP
driver is limited to 40us pulse to pulse variablity, usually thats much lower
than a driver can effectively see in its resultant phase shift, but in the SS
the timing jitter should be able to be much much smaller and totally invisable
to the driver which is the sought after end effect for a perfect threading sync.
Jitter, often thought to be a problem in pulsing output, is actually used as a
benificial effect in Mach3, and the amount of jitter is tightly controlled to
take advantage of its good effects, and keep it low enough to minimise its
negative effects on the drivers phase timing stability. All digital based output
timing has jitter, its a matter of understanding it and using it effectively. In
threading , Mach3 uses a system of control very similar to Mariss's look forward
trajectory smoothing technique, but it was developed long before that.

End analysis: stay with INDEX when using a PP unless you have some inherent
reason for trying the TIMING input. The theoretical advantages dont outweigh the
mathmatical disadvantages.



Thanks,
Art ( just a user who knows a little bit about timing. :-) )
« Last Edit: January 25, 2009, 07:44:48 AM by Hood »

Offline simpson36

*
  •  1,369 1,369
    • View Profile
Hood,

Thx.

I wasn't considering 'timing' vs 'index' in terms of Mach3 specific vernacular.

As I read it, 'timing' is theoretically better, which is what I was thinking, particularly at slow rotations. However, the real world limitation is the PP and granularity at 25khz, which is also understandable.

For steppers, I'm learning more and more advantages to the Smooth Stepper.

When I do another conversion, it will be with servos, so I won't be able to benefit from that piece of technology, but I find it interesting none-the-less.


Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Simpson, the SmoothStepper has been badly named, well not so much badly named but rather unfortunately named as it tends to make people think it is for Stepper Motors only. That is not the case and actually it is servos that can really take adavantage of the SmoothStepper. I have big AC Servos on my lathe and previous to the SmoothStepper I could only get 3.4m/min rapids due to the high encoder count and that was with 1:2 electronic gearing in the drives. Now I can easily get 20m/min, if I dare, with no  electronic gearing,  but have actually settled for 10m/min as 400Kg of saddle flying up to a chuck at faster than that has me a bit frightened ;D I did do a vid of the Lathe doing a job with the parallel port and then I did another with the same job and the SmoothStepper.

Hood
« Last Edit: January 25, 2009, 10:17:50 AM by Hood »