richard harris wrote:
> I am currently running emc 2.2.6 I have been threading a right hand
> M10x1.25 thread all day approximately 90 parts. I switched to
> cutting a left hand M10x1.25 and everything was fine for the first 20
> parts then suddenly on the spring back pass it will rapid one of the
> cuts. I looked at the wires on the spindle encoder to see if
> anything got loose and all looked fine. Ran the same code again with
> no problems, thought it was a fluke and continued to run parts. Four
> parts later it did the same rapid still on a spring pass but the last
> one not the first. Ran the program ten times in the air and 4 times
> it ran perfectly 6 times it rapided in a spring pass, always a spring
> pass. I switched back to right hand cuts and it ran without issue.
>
Are you using a Pico Systems Universal PWM Controller in that system?
If so, what is the date code on the EPROM on that board?
I see you got it in May 2007, I fixed up some problems in the spindle
sync function right around that time. I THINK your unit has the new
firmware, and the remaining problems were in the driver, and we worked
them out at the 2007 CNC Workshop. Your 2.2.6 version of EMC certainly
has those updates. That nasty behavior was EXACTLY what I was having
trouble with at the 2007 NAMES show, but the combination of firmware and
driver fixes seems to have taken care of it.
I haven't done any single-point threading in reverse, but I did do a
batch of thread drilling/rigid tapping without any glitches.
However, that cycle only syncs the spindle in forward mode, and then
just leaves the spindle synched as it reverses the motor.
A problem I had and finally diagnosed with the help of the rest of the
EMC crew at the 2007 Workshop was the special case where the spindle was
left running long enough to accumulate over 16 million counts and
rollover into the extension byte. (The PPMC encoder counter is 24 bits,
the driver extends this to signed 32-bits.) Every time you sync the
spindle in a G33 operation, it rsets the hardware counter to zero.
If you allow enough time in other operations for the counter to overflow
into the extension bits, the driver needs to handle that condition properly.
It may have been fixed for the forward direction but not for reverse!
You can use Halmeter to watch the encoder counter the spindle is on, or
just calculate how many minutes the spindle needs to run to count up 16
million counts. Then see if the program goes haywire (with no tool or
no workpiece). If you can get it to reliably fail when the encoder
count is greater than -16,777,216 (2 ^ 24) that will tell me where to look.
If anyone else wants to critique this (my brain is too fried at this
hour to clearly think this through) the code that resets the highest
byte of the
count is :
/* need to properly set the 24->32 bit extension byte */
if ( pos.byte.b2 < 0 ) {
/* going backwards */
pos.byte.b3 = 0xFF;
} else {
pos.byte.b3 = 0;
}
I can think of some possible ways this could get into trouble.
Depending on the exact sync between the index pulse, the AB quadrature
edges and the time EMC samples this, the 24-bit hardware counter could
have been zeroed synchronously by the index pulse, and then started
counting into negative territory. If the extended byte is set to 0xFF,
and then it triggers another borrow, the high byte might decrement to
0xFE, causing a HUGE discontinuity in position. The broken out bytes
are declared signed, so the comparison if (pos.byte.b2 < 0) ought to
work as written to detect that the counter has started into negative
numbers. What about the case where the spindle is going slow, so when
the driver reads it it is still all zeros from the index detection, and
pos.byte.b3 is set to 0? I guess the sign extend is well proven to
borrow correctly, so that shouldn't cause any problem.
Any thoughts?
Jon
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
