Why do I need Input filter?

[tome9999]

I have spent many hours attempting to tune and run a machine with Granite Devices VSD-E drivers connected to Keling KL34-180-90 motors with CUI AMT-102 encoders on them. The control software is EMC2 but EMC pc is connected to a Mesa 7i43 fpga card (and also 7i42 buffer card) that is generating the step/dir pulse train. We would have very nice tuning graphs throughout, and after tuning, the Granite would move the motors smoothly when using moveinc commands.

Then when reconnecting to EMC control software the motor would make bad noises like it was straining to move the axis. It didn't stutter like losing steps, but noisy like bad tuning. The Granite would always fault at some point, even at low speeds, and especially at high speeds, with an "Over Current (Due to bad turning)" indication. We put an oscilloscope (as well as a logic analyzer) on the step and dir pins while the drive was running and the pulse train was flawless. It was beautiful and noise free, at exactly the expected frequency and no lost pulses. We even put the scope on each side of a 100ohm resistor on the Mesa input side in order to measure the voltage (and hence determine the current) and were seeing the expected current draw from the Granite opto and also saw that the Mesa was fully shutting off (as one would expect). Again, flawless, clean waveform. We are running the Mesa card in open collector mode and are feeding the cathode side of the Granite opto to the Mesa IO pin. The anode side is pulled up to 5v.

After hours of re-tuning and debugging we finally gave up and decided to connect up Mach3 running of a different pc with a parallel port breakout board (XYDrive XD-14) and let it generate the steps. We got the same behavior. At even low speeds the drive would fault with the same indication.

Sort of by accident we decided to turn on "Enable Input Filter". We specifically didn't want to turn it on as it mentions that using this is not desired if you are closing the loop outside the Granite (which we are with EMC) but we tried it anyway. And lo and behold all the problems went away. ??

Why would this be? Why, when we have strong flawless pulse trains, would we need input filtering? We want EMC to close the control loop, and it seems to do fine in the little testing we have done thus far, but are we going to run into problems due to needing to have input filtering on? What can we do in order not to need it?

Tom

[Xerxes]

Hi Tom.

"Input filter" option is not for signal quality, but for step pulse (or any other input mode) jitter & noise reduction. It also smoothens motion if input multiplication is being enabled on drive (like moving 5 counts on one step pulse).

I think it actually might be tuning issue. When you run test responses on GDtool, the motion profiles are flawless (no jitter etc at all). But from external sources there will be always even little bit of it which may make badly tuned system to react badly.

To test this, try adjusting acceleration to maximum from GDtool trajectory planner and do some step response tests (low, medium and large amplitudes). The sharp acceleration profile may reveal something that smooth curves didn't.

[tome9999]

Originally Posted by Xerxes Hi Tom. "Input filter" option is not for signal quality, but for step pulse (or any other input mode) jitter & noise reduction. It also smoothens motion if input multiplication is being enabled on drive (like moving 5 counts on one step pulse).

From our analysis with the logic analyzer and the scope there isn't any jitter or noise. The Mesa 7i43 card is essentially dedicated to providing a pulse train so there is no reason to expect there to be jitter.

Originally Posted by Xerxes I think it actually might be tuning issue. When you run test responses on GDtool, the motion profiles are flawless (no jitter etc at all). But from external sources there will be always even little bit of it which may make badly tuned system to react badly. To test this, try adjusting acceleration to maximum from GDtool trajectory planner and do some step response tests (low, medium and large amplitudes). The sharp acceleration profile may reveal something that smooth curves didn't.

When you say adjust it to maximum, do you really mean the largest number that GDTool will allow for "Acceleration Limit"? If I do that the number in "Effective velocity limit" is far far above the motor specs.

Also what values should I use for low, medium, and large and should I do it in torque, position or velocity tuning?


Thanks,
Tom

[tome9999]

Here are graphs from running torque mode tests. The graphs start at 100%, 75%, 50%, 30%, 15%.

Tom

[Xerxes]

Hmm, so do you use torque mode on drives and step/dir? That will not work as torque mode would require analog or PWM input (=absolute reference) to produce meaningful output.

Have you tried setting drive in velocity mode and doing same? It works with step/dir and usually gives better dynamics too.

[tome9999]

Originally Posted by Xerxes Hmm, so do you use torque mode on drives and step/dir? That will not work as torque mode would require analog or PWM input (=absolute reference) to produce meaningful output. Have you tried setting drive in velocity mode and doing same? It works with step/dir and usually gives better dynamics too.

We don't use torque mode. We use position mode. Without input filtering the motor runs rough in the control software (EMC2). If I use moveinc YY it usually moves without a problem, though it did fault once today while moving it from the drive itself. So, I don't think it s a tuning issue.

Tom

[Xerxes]

Ok. Torque plots look ok. How much margin is there between peak current and fault current settings? Too low margin causes overcurrent faults because even smallest overshoot can trigger it.

Please do also step response tests in position mode like you did for torque. Yes, set acceleration parameter to 32000 from GDtool while doing different length step tests.

[tome9999]

Originally Posted by Xerxes Ok. Torque plots look ok. How much margin is there between peak current and fault current settings? Too low margin causes overcurrent faults because even smallest overshoot can trigger it.

You can see that in the first image I posted, we have peak set to 20A and fault set to 39A, We have a 20A linear power supply. We have seen it put out about 30A for short bursts. We also tried setting fault to 43A, which appears to be the highest we go but it made no difference. We are at a loss to explain the overcurrent faults. It REALLY isn't overcurrent-ing. We get these faults as it is just moving along very slowly (though noisily).

Originally Posted by Xerxes Please do also step response tests in position mode like you did for torque. Yes, set acceleration parameter to 32000 from GDtool while doing different length step tests.

I will do this today and let you know. Since after tuning the Granite can move the axis with no problem, very smoothly, at any accel/speed and this only happens under control by the PC I can't imagine this is really a tuning problem.

Input filtering helps immensely, but as I say it should not be required in our set up....

Tom

[Xerxes]

By default VSD-E's overcurrent triggering is set to be quite sensitive (maximum protection). I rolled a modified firmware that is little bit more forgiving regarding overcurrent sensing and may fix the issue in difficult cases. Please try loading attached firmware with GDflasher and let me know if it helps

[pjensen]

Hi - I've been working with Tom on this problem. I have a vertical machining center that I retrofitted with the same granite drive and motor combination a couple years ago with relative ease. I'm hoping we can solve this issue as we have been having lots of problems with this drives/motor combo that I recommended to Tom I thank you for your help!

My VMC has been running for years now without a problem. It's run through all sorts of different cutting loads and speeds, and has never had the slightest hiccup. I think the servo tuning is fine.

I looked at it's granite configuration yesterday and noticed that I had input filtering on. I turned it of, and lo, same problem as with the Tom's gantry. The drives run rough and fault frequently even when moving slow. The step generation should be fairly clean (it runs a stepper in my rotary axis without any problems, and looks very nice on a scope). Before I had the granite drives, I used rutex servo drivers and the step train worked with those just fine too (the rutex drives had other reliability issues not related to their movement that made me switch to granites). The step train is, without any doubt in my mind, quite clean. And yet input filtering is needed...

I also worked with Tom and tried changing the input scaling multiplier and divisor, as I noticed GDTool said that the divisor had to be >25 for stability. We increased the multiplier and divisor from 50:50 to 500:500, and that actually helped. I had to also increase the max velocity setting. The drives run smoother this way, although they still fault (yes, now they often fault even when running smoothly!). This is all with input filter _off_. I haven't tried it yet with input filter on and the higher input scaling numbers. In the end I changed it to 60:600, and increased the step rate from the mesa card controller accordingly (increased rate by 10 times).

Can you explain what the divisor is doing? Why does it matter if it's 50:50 or 500:500? I had thought it was the ratio that mattered, but apparently there is more going on here. In some instances even with 500:500 it's still rough, but it's much better than with 50:50. 60:600 works even better is not really rough at all (although it still faults with overcurrent frequently)

Ok, thanks for your help. We'll definitely give the new firmware you posted a try.

-Peter

[pjensen]

One more thought about the over-current error. The power supply Tom is using is rated at 20A, and we were not able to get it to output more than about 30A even when we deliberately tried to drive the motors really hard by putting all maximum settings in the torque mode step response. Those motors practically jumped off the gantry they were turning so fast and hard, and yet not much over 30A, and no overcurrent. In other cases while tuning (when parameters were set poorly) it's gone into uncontrolled oscillations, and yet still nothing much over 30A or current fault - just eventually a following error or somebody slams the e-stop.

I suppose it's possible the granite's onboard caps are sourcing a very short burst of 43A, but I'm doubtful. The motor's aren't dead shorts, after all... even if the granite's PWM just went to 100% I don't think we'd see the 43A (which is where we set the current fault threshold).

Again, I'm confused by this behavior, so I'm trying to think some of this out loud. I think the granites may be sensing a false over-current (maybe some noise on the A/D input line that's measuring current - is that possible?). Thanks for your help.

Best Regards,
-Peter

[Xerxes]

VSD-E extensively utilizes the input reference signal (this case the step train) for motor feedback control & feed forwards. The smoother the input is, the lower disturbance the controller has thus produces smoother motion. So the drive extracts also velocity & acceleration from step/dir signal which may explain the differences.

So, when using input filter the disturbances get reduced. Same happens when you choose scaling of 1:10 instead of 1:1. In 1:10 case the drive has 10 times more precise data of target acceleration & velocity (because step frequency is 10 times higher).

BTW, have you set velocity & acceleration feedforward values in GDtool? These parameters are pretty sensitive to input signal precision. Try setting these to 0 to see if it makes any difference.

Drive decides to go in overcurrent stop if even single ADC sample exceeds the user specified limit. The modified FW filters single spikes from this signal.