- Posts: 21
- Thank you received: 0
2.7.15
- tommylight
-
- Away
- Administrator
-
Less
More
- Posts: 22012
- Thank you received: 3
6 years 8 months ago #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 to join the conversation.
6 years 8 months ago #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
jazial wrote: 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 to join the conversation.
6 years 8 months ago #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 add
for 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.
Code:
* pid: use command-deriv when supplied
In fact, I see this in your HAL:
Code:
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
Code:
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.
Please Log in to join the conversation.
Time to create page: 1.180 seconds
