2.7.15
- tommylight
- Away
- Moderator
Less
More
- Posts: 18039
- Thank you received: 5988
12 Feb 2020 11:58 #157167
by tommylight
Replied by tommylight on topic 2.7.15
Add G64 P0.1 to the gcode file for mm machine or
G64 P0.01 for imperial
the 0.1 or 0.01 is the actual distance that the machine is allowed to stray off the path.
G64 P0.01 for imperial
the 0.1 or 0.01 is the actual distance that the machine is allowed to stray off the path.
Please Log in or Create an account to join the conversation.
26 Feb 2020 22:25 #158578
by andypugh
Are you using exactly the same config files in each case, or did you re-create your configs?
Release notes are here: github.com/LinuxCNC/linuxcnc/blob/ba122d...a8c/debian/changelog
Hello,
I've upgraded to 2.7.15 and path is not accurate
Slots are not straight
Circles are oval
Downgraded to 2.7.14 and everything is fine
maybe some bug in release, or do I have to tune something ?
Are you using exactly the same config files in each case, or did you re-create your configs?
Release notes are here: github.com/LinuxCNC/linuxcnc/blob/ba122d...a8c/debian/changelog
Please Log in or Create an account to join the conversation.
27 Feb 2020 10:13 - 27 Feb 2020 10:13 #158614
by andypugh
So, it's an analogue servo system, so the problem could be this:
In fact, I see this in your HAL:But it seems that you might have an error in your HAL as there is nothing driving that signal elsewhere in the HAL. so the velocity command will always be zero and your FF1 term will be ineffective.
So, possibly, an error in your HAL has been masked by a bug in LinuxCNC.
If you comment-out the pid.L.command-deriv lines then you should be back where you were.
Better might be to leave those lines in and addfor each axis. But that might require some re-tuning of the FF1 PID terms.
The explanation here is that the PID component was meant to calculate velocity command internally if the pin was not connected, and use the supplied value if it was. But it was always calculating it internally. This took some time to be noticed, as it works nearly the same.
* pid: use command-deriv when supplied
In fact, I see this in your HAL:
net x-vel-cmd => pid.x.command-deriv
So, possibly, an error in your HAL has been masked by a bug in LinuxCNC.
If you comment-out the pid.L.command-deriv lines then you should be back where you were.
Better might be to leave those lines in and add
net L-vel-cmd axis.N.joint−vel−cmd
The explanation here is that the PID component was meant to calculate velocity command internally if the pin was not connected, and use the supplied value if it was. But it was always calculating it internally. This took some time to be noticed, as it works nearly the same.
Last edit: 27 Feb 2020 10:13 by andypugh.
Please Log in or Create an account to join the conversation.
Time to create page: 0.228 seconds