The motorGearboxEncoder PIDStrings are indeed much different from the axis equivalents.
An interesting thing that I see is that once the comm error has occurred, the firmware continues to send (incorrect) position but no longer responds to characters sent from GC.
1 Like
Yes, they are very different. But are they different from the settings that they are supposed to be?
Sorry, I didnât make the connection. The values printed match the values entered in the settings.
B15
Axis=R
Kp=650.00,Ki=4000.00,Kd=0.00
Kp=52.00,Ki=0.00,Kd=0.00
Axis=L
Kp=650.00,Ki=4000.00,Kd=0.00
Kp=52.00,Ki=0.00,Kd=0.00
Axis=Z
Kp=650.00,Ki=4000.00,Kd=0.00
Kp=52.00,Ki=0.00,Kd=0.00
ok
Yup those all look right.
I am stumped. I am out for the weekend, but I will try to look into this next week.
1 Like
OK, I ran a test cut tonight of a 5.5x5.5 inch square and it was dead on. I canât even measure the error.
So we need to figure out why this isnât working.
@bar has nicely helped merge all of the non-problematic commits into master. So we are down to 4 commits. I have placed them in this branch
https://github.com/krkeegan/Firmware/tree/Movement_Fixes
If you can, please update your GC to the current master and try the above firmware branch.
To make things easy try the following settings:
Position:
Kp = 1100
Ki = 0
Kd = 0
Weighting = 1
Velocity
Kp=52
Ki=0
Kd=0
If that still doesnât work then can you try the following:
- Put the sled in the center of the work surface
- Remove the log.txt file
- Run the following B13 S10 F-10 I11
- Send me the log file
This should cause your sled to run through a series of velocity steps and will help identify if the problem is with the velocity PID controller.
4 Likes
This âMovement_Fixesâ branch appears to work correctly on my setup with GC0.91. The arrow buttons move as expected, and the Maslow Test Shape runs correctly.
1 Like
Wonderful.
But a bit concerning that a bug seems to have evaporated.
Well, poke around let me know if it seems better or worse than before, our if you spot any other errors.
1 Like
This is the top of my to-do list for the day. VERY exciting!!
The suggested Position values were pretty different from before. Could that make the difference?
It certainly could be the answer. Although it is still troubling as those worked fine for me suggesting that there may be some differences across machines.
Out of curiosity I restored the earlier Positional values and all still seems to work correctly, and a bit quieter. Attached is a log taken with those values.
log.txt 2.zip (1.3 KB)
The velocity settings are the same between the two so I wouldnât expect that to look different.
The prior settings of
Kp Position = 650
Ki Position = 4000
Kd Position = 0
Were designed for the Position on Measurement setup, so you would want to set the Proportional Weighting to 0. I wonder if it would work then.
I will caution that things that sound smooth and quiet are not necessarily more accurate.
1 Like
Everything works smoothly for me. I see a distinct reduction in positional error. Great work @krkeegan!!
Does anyone else see a velocity difference between circles and straight lines of the same feedrate?
Can you expand on this.
Although, you helped me find something I thought I fixed, but I must have reverted back by accident. Straight lines are probably about 20% slower than they should be, but this has been this way for a while, this is because we use delay in the cordinatedMove but fail to take into account how long it takes for the process to occur. I fixed this once before in another commit that I misplaced, it increases the speed slightly and decreases some of the 2-5hz vibration that you hear.
Found my prior commit and added it to the end of the Movement_Fixes branch. See if that improves the velocity difference for you.
1 Like
I have good news and bad news. The good news is that I think we may have found the commit which was giving us trouble. The bad news is Iâm seeing the connection dropping when using the latest version of the Movement_Fixes branch.
How do you feel about merging it as it was (which was a great stand alone step forwards) and then we can track down whatâs going on with the speed?
Huh, interesting, give me a minute, I can rewrite that in a different form then.
As for merging. This branch fundamentally changes how the PID works and I am pretty sure the old default PID settings will not work well at all. So at minimum we need to push a simultaneous change to the defaults in GC. I leave it up to you, but I think we should wait until Wednesday when we can announce the change and encourage everyone to upgrade both items at once.
Also, it would be nice to direct people who are interested to the PID Tuning wiki page as well
https://github.com/MaslowCNC/Firmware/wiki/PID-Tuning
1 Like
Ok new commit made to the branch. I think that should work.
1 Like
That looks like it fixed both the timeout error and the slowing down in the straights for me. Fantastic!
How would you feel about merging right after the Wednesday release so we have a whole week to test before the next release. We can increment the version numbers to .92 at the same time we make the changes so that way all of .91 firmware will work with .91 GC and then .92 will work with .92?
1 Like