Cannot explain ferror? CNC hobbing machine

09 Sep 2017 05:34 #98720 by Henk

I hope someone can help me explain or at least point me in a direction to solve the following problem...

We are running a CNC hobbing machine using LCNC (7i92+ 2x7i77 etc). The machine is equipped with AC servo drives and feedback s from glass scales and a C axis rotary encoder. The C-axis is controlled using a custom component not unlike Encoder-Ratio.

The problem is that we are experiencing joint 5 following errors which is a real pain because it damages the gear being cut and can break the hob which is quite expensive. This seems to happen on the final cut every time which could well be coincidence???

Joint 5 PID is tuned to achieve within 0.001 degrees accuracy which I think is real good. The ferror in halscope spikes to infinity within one sample which in my mind is mechanically near impossible, so the error must come from the command side. I have seen this spike positive and negative.

Attached is a screenshot of halscope when this happens.

The component we are using simply tracks the spindle position, multiplies this by a ratio which is subtracted from the C-axis position FB to create an "error". The PID use this error as feedback which results in synchronized motion between the spindle and the C-axis.

Unfortunately I cannot attach the component now as I do not have a copy of it on this PC but I can send it on Monday.

Any advice on what to look for would be appreciated.

09 Sep 2017 05:35 #98721 by Henk
and now the attachment...
09 Sep 2017 14:00 #98728 by PCW
Could you plot the commanded position and perhaps the inputs and outputs of your component?
(and trigger on following error)
09 Sep 2017 15:15 #98731 by Henk
I thaught about that....
Commanded position i can add to halscope but the inputs to the comp is spindle and axis positions which is cumalitive. How do i monitor those variables?
09 Sep 2017 15:46 #98732 by PCW
If its some kind of math error it may be big enough to show up even relative to the increasing spindle position

Another option is using the ddt component on the commanded and feedback position numbers (should give you velocity)
09 Sep 2017 16:16 #98734 by Henk
Thanks for the advice. I will try that.
11 Sep 2017 14:45 #98833 by Henk
I ran the machine today for several hours with no trips. We had a power failure over the weekend so this morning all encoder counters etc was reset to zero. I added the input and output of the component to halscope as well, unfortunately no trip so I don't know what happens to those yet...

I did think of something and would like your comments on this.

The component use spindle.revs as an input and calculates the C-axis "error" using the hob/workpiece ratio. this error is then used for joint5 feedback and PID do the rest.

What I have seen is that the joint5 feedback in degrees cumulates quickly into the thousands. we stopped at approx. 500k degrees. At this number, it seems that the float value with 7 significant digits only has 1 decimal. What happens when this value reaches 1000k? Do we lose the accuracy of the number because it still only has 7 significant digits? In this case, the accuracy of the C-axis position is less than the allowable ferror which will probably cause the trip. I'm not sure if this is just the format of the displayed number on halshow, maybe I'm on the wrong track altogether

Thanks for the help
11 Sep 2017 15:58 #98843 by PCW
AFAIK all LinuxCNC floating point numbers are double precision so this should not be an issue
16 Sep 2017 05:08 #99021 by andypugh

Henk wrote: The component we are using simply tracks the spindle position, multiplies this by a ratio which is subtracted from the C-axis position FB to create an "error". The PID use this error as feedback which results in synchronized motion between the spindle and the C-axis.

I don't think that that sounds right. And your component is the first place I would be looking for the source of the problem.

I do a fair bit of CNC hobbing myself, but my system simply divides the spindle position by the tooth count and sends that as a position request to the work axis. I have a bit of HAL magic that starts from zero any time the tooth count is changed (otherwise the spindle tries to unwrap a few hours worth of turns...) but everything happens in absolute position mode. (there is a PID to control the servo, but the same system was originally used with steppers on my Mini-Mill)

I suspect that you might have an overflow in your custom component, can we see it?

The absolute most reliable way to work would be to take raw encoder counts as an input (S32) and internally promote that to S64, which can never wrap. Then calculate the workpiece position required from that in double-precision float.
18 Sep 2017 08:43 #99077 by Henk
Hi Andy
Thanks for your comments below. The .comp file attached.

The main reason for intercepting the C-axis feedback was so that we still have control over the C axis from G-code or manual mode. From time to time we have to re-cut a workpiece and this helps to do the touch-off. We would like to rough gears out by using milling cutters of appropriate form (cut, index, cut, index....) and for this we also need control over the C-axis. I guess this can still be possible if the component putputs a commanded position when enabled, or the normal commanded position when disabled.

We also experienced the unwinding problem but managed to find a solution to that, see the .comp.

Your comments will be appreciated.

Time to create page: 0.079 seconds
Powered by Kunena Forum