Considering a Full Rewire on a Working Schaublin 125 CNC

I worked again at the spindle.

I have a “theory” on how to handle the two gearings of the machine.

First, I try to get the motor RPM into LCNC. With the analog out from the VFD, I am now able to get this with an accuracy of about ±25 RPM, which is less than 5% off. I measured the real RPM with a cheap optical tachometer and the RPM that the VFD “thinks” it is at. These two were consistently very close. The VFD was consistently 3 to 5 RPM higher than the tachometer, in an RPM range from 880 RPM (at 30 Hz) to 2080 (at 70 Hz). 3 to 5 RPM seems close enough to ignore that error and believe the VFD.

Now, having the motor RPM, I set the variator by hand so the overall reduction ratio was 1:1 (or close to it)

My plan is to tune the PID at this point and later multiply the error term (pid.s.error) by the overall reduction ratio. If I am not thinking about this totally wrong, this should give the system a hopefully somewhat stable spindle PID over the very large reduction that the backgear and variator provide.

Now I do have 3 problems:

1: There is something wrong with my pid.s setup. As soon as the error gets significantly negative, the output shoots up and the system runs away. I found that pid.s.output can be between 3000 and -3000, but I use 0–10 V, not ±10 V, so as soon as pid.s.output goes negative enough, it runs awaythe sign seems to be ignored. I think this has to be a somewhat common problem with 0–10 V. I was able to remove the runaway by using a limit component to cut away the negative part of pid.s.output, but that led to strange behavior as well. With this, I can increase P to large values without it starting to oscillate much.

2: I was able to get the motor RPM, and I have the spindle RPM, but putting both into a div2 component gives 0 at all times. And not a close-to-zero float (e.g. 5.459834658e-7), but actually just 0. I thought it had to do with the deadband, but no value of that seemed to resolve this. The spindle RPM is obviously 0 when the spindle is still, so I do have a limit component to keep the spindle RPM at ≥ 1, resolving divide-by-zero issues. And as soon as the spindle spins, the numbers seem fine.

3: I already foresee a future problem: given that I have the gear ratio and a solid PID at a ratio of 1:1, I would need to scale pid.s.error (reduction_ratio * pid.s.error), but I could not find where this variable is set, so I would not know how to set my scaling factor.

Sorry for this long rambling message, I hope I was able to explain what is going on on my side.

Sounds like an asynchronous motor with a couple of percent of slip. I dont think we need to control RPM to any really close tolerance. The only time we do commanded speed change with the tool in engagement is a CSS facing cut, or a taper cut, both of which change speed pretty slowly.

I think it will be a real challenge getting this level of control packaged into the HAL. I started working on a comp for it.

I may have not explained what I am after very well. With the variator, if we are properly tuned at 1:1, we would get a problem, as with, for example, 2:1 the same tune would overshoot massively, and with 1:2 we would undershoot.

So what I want is to measure the motor RPM and spindle RPM to get the transmission ratio and scale the PID error accordingly to have a similar response to the point at which it was tuned. I am not after controlling the motor RPM directly.

But to know if this will work or not, I have to get the tune at one point right first, see problem 1 of my previous post.

Dudelbert wrote:

I may have not explained what I am after very well. With the variator, if we are properly tuned at 1:1, we would get a problem, as with, for example, 2:1 the same tune would overshoot massively, and with 1:2 we would undershoot.

So what I want is to measure the motor RPM and spindle RPM to get the transmission ratio and scale the PID error accordingly to have a similar response to the point at which it was tuned. I am not after controlling the motor RPM directly.

But to know if this will work or not, I have to get the tune at one point right first, see problem 1 of my previous post.

Just to clarify where your spindle speed PID feedback comes from:
1. Are you using motor RPM for feedback? I think that would be the proper way to do it.
2. Are you using spindle RPM for feedback? To regulate commanded spindle speed? I'm not sure whether there is any easy way to tune that. It seems your tuning would have to change dynamically with the gearing ratio, causing multiple complications.

If I'm correct, ideally the scaling from spindle RPM to motor RPM should be on the PID command signal. At that point the gearing affect on PID tuning should only be mechanical.

This still leaves you to have to measure the adjustable gearing ratio between spindle and motor for properly scaling the speed command.

On second thought, in this kind of project I might use nested PID:

The inner PID gets its feedback from the motor RPM, its command from the outer PID, its output drives VFD hz command. This PID has to be tuned first, testing it by manually commanding it in motor RPM units.

Next, the outer PID. This gets its feedback from the spindle RPM, its command from LinuxCNC spindle speed command, then its output commands the inner PID.

Am I correct, thinking this will automatically compensate for gearing changes? Except forward/reverse gear change if it exists which would need to be handled by reversing the direction of the outer PID.

The feedback that I used for the spindle is an encoder on the spindle, so I am very confident in this feedback being good. The stuff I am doing with the motor RPM I really do not trust too much. The encoder also has an index, so threading is possible. I don’t want to change that either.

As to “This still leaves you to have to measure the adjustable gearing ratio between spindle and motor for properly scaling the speed command,” the variator is infinitely adjustable. That is why I think even a not completely accurate motor RPM and a really accurate spindle RPM to calculate the gearing ratio every servo cycle would do the trick.

So in a sense, this would only scale the error, as in: if commanded is 1000 and feedback is 800, the error would be -200. Now let’s say we are close to 1:1, then that does not really change, and we actually want the motor to go 200 RPM more.

Let’s say with the same commanded and feedback but a ratio of about 2:1—in that case, we need only about a 100 RPM change on the motor, so scaling the error with the ratio should do that. And as it is just a factor, it will never wildly change the system.

I am sorry if that makes sense only in my head. I have been banging my head against a wall here for some time now.

Regarding my problem 1, I think I have found the reason why the output is between 3000 and -3000. It is this line: [HMOT](CARD0).pwmgen.05.output-type 1
If I read the documentation correctly, it has to be:[HMOT](CARD0).pwmgen.05.output-type 0 to be 0 to 3000. I will see if that helps tomorrow.

"On second thought, in this kind of project I might use nested PID" that sounds super fancy, but I see two problems with it for me. For one, I would not know where even to start implementing this. And second, the motor RPM that I get is way too inaccurate for PID to effectively work.

I get the value from a 4–20 mA current from the VFD. I then have a 470 ohm resistor very close to my 7i84 that has the ADC to give me the signal I then process to get an RPM. The signal is rock solid, with no noticeable jitter at all, but it is only an 8-bit ADC, and my voltage is between 1.7 V and a little over 9 V, using less than half of the ADC range.

For getting an approximate gear ratio, this seems fine, but not for actual speed control, at least that is what I think. I may very well be wrong.

By the way, this is the HAL and COMP I have gotten working to control the turret.

 

I have the variator now basically working.

To the 3 problems I laid out a few days ago:

1: The problem was really at 2 points. For one, the line
setp [HMOT](CARD0).pwmgen.05.
offset-mode should have been 1 and was 0, and on top the VFD was set slightly wrong. Using open-loop FOC now, the tuning went much better.

2: The divide-by-0 issue is still somewhat there, but giving both ".in" pins a starting value greater than 0 makes it so it still throws an error at startup but works as expected thereafter.

3: It seems that I cannot manipulate the error term directly, but what works is to take commanded and feedback, calculate the error, and scale that error. With that, I can “reassemble” a feedback that leads the PID component to get the error I want it to.

With all that, I am able to have stable control over the whole RPM range of about 65 RPM to 3000 RPM.

The variator control still has to be improved, but the principle seems absolutely workable.