[LinuxCNC/linuxcnc PR#351] 2.7 limit3 issue 240 About GRBL HAL

Issue #351 | 状态: 已关闭 | 作者: zultron | 创建时间: 2017-11-18

I ended up refactoring the limit3 comp; see #240. It passes @SebKuzminsky’s tests with a small fudge.

It’s different from the old comp because it handles the first order max/min limits separately from the input signal. This way it can do its best to keep up with the input, but then do the right thing when it sees the max/min limit coming up.

It turns out to be a bit complicated to decide when to worry about the max/min limits, and when to worry about the input signal, as can be seen in the string of if cases. I did my best to annotate the code for clarity.

It also turns out to be hard to stop exactly on the max/min limits while at the same time observing those for velocity and acceleration. This code overshoots the target by about 0.5%, and then has to find its way back before locking onto the limit.

!limit3-halscope

[1]: https://github.com/zultron/machinekit/tree/2.7-limit3-issue-240

#1 – zultron 于 2017-11-18

@jepler, I don’t know if it will follow an in-limits signal as well as the original. Some points in case someone does a direct comparison:
– Once it “locks in” on the input signal, as long as the input signal doesn’t violate limits, the input will be passed directly to the output.
– In Seb’s sine-wave test case, once the output catches up to the input after returning from out of limits, it hunts around for several cycles before finally getting that lock on the input signal.

#2 – jepler 于 2017-11-18

I sent this to the buildbot for a full build check on all our architectures, though I see the one point I was concerned about in particular was changed.

@SebKuzminsky I think we should merge this, but I don’t know how you feel about what is essentially a full rewrite of limit3 in 2.7.

#3 – samcoinc 于 2017-11-18

The few times I have used the limit3 component – I have run into the overshoot and runaway bug.. overshoot isn’t as big a deal – but the run away is a pain. I hope to test this weekend.

#4 – SebKuzminsky 于 2017-12-02

@samcoinc (aka skunkworks) reports in IRC that zultron’s limit3 comp works without issue for him: http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2017-11-27.html

#5 – SebKuzminsky 于 2017-12-04

I added another test to the 2.7-limit3-issue-240 branch, verifying that under normal conditions (when an input sine wave does not violate the limit3 constrains), the output of the old limit3 comp follows the input very closely. Then i merged this PR into my branch, and verified that the new limit3 comp also follows the input very closely.

I’m now satisfied that this new limit3 comp is much better than the old one in 2.7. Thanks @zultron! If you merge 2.7-limit3-issue-240 (with the new test) into this PR, I’ll merge it into 2.7. Or if you want to, I can just merge 2.7-limit3-issue-240 into 2.7 and close this PR.

#6 – zultron 于 2017-12-04

Thanks, @SebKuzminsky. You asked for a merge, but I cherry-picked instead. If that’s ok, this is ready to go.

#7 – SebKuzminsky 于 2017-12-04

Thanks for fixing this, @zultron

原始Issue: https://github.com/LinuxCNC/linuxcnc/pull/351

评论 (7)