Correct. The only thing I haven’t tried is ground control.
i wanted to make sure that this problem followed the various firmware versions you tried.
question for the group: is it possible that the problem may be an intermittent fault in the shied? specifically with the Z axis channel / chip?
My thinking is that would lead to an increasing error over time. What we are seeing is a offset from where it should be, but it doesn’t seem to be getting worse just sometimes it’s above the target and sometimes it’s below.
If it was a mechanical or electical issue, the physical error would change, but
the display would not show the error (mechanical or electrical errors make the
machine end up at a place different than where it thinks it is)
that’s why I keep looping back to the PID loops.
P drive the motor based on the error of position
I the longer the position error exists, the harder you should drive the motor
D account for how fast you are moving.
the maslow has two layers of PID loops (and on one layer, it seems that I is 0
so it’s a PD loop). one is for position, the other for velocity (I don’t
remember which is the lower level loop)
see Why this Robot is Really Tall - YouTube for a video that came out last
night about a balancing robot where he is going through this exact same
excercise of making a PID loop and then adding a PD loop on top of it.
do we have the ability to change both layers of the PID parameters through
gcode? or only one layer?
the maslow stops trying to drive the motors two seconds after it thinks the
movement is completed.
a couple things that I think would be good to try.
-
extend the 2 seconds to something like 20 seconds and see if the system
eventually reduces the error -
increase the I parameter on the position loop so that as the error persists
for a longer time, the system tries harder to fix it.
I still am not sure how the firmware is reporting the position to the external
software, is that something that it just dumps out every X seconds?
David Lang
1 Like
David, thanks again for the clarification. The video really clarified the use of the cascaded PID. Is there anyway to capture the raw demand / position feedback when loop tuning and not strictly relying on the WC display output?
I’m pretty sure there is nothing in the curren firmware, but it should be fairly
simple to add something, especially as a testing-only version.
David Lang
The PID test routine is here. You could potentially run it from a side program other than webcontrol and interface with this feature only.
1 Like
So, what’s my next steps? Try the PID test routine? How? Or drink a beer?
1 Like
I did drink a beer, that helped me but not the maslow.
But I did a few plunge rate tests.
WC .94, Firmware 51.30. I used Carbide Create to make a circle that would be pocketed in 4 passes.
I did 5 tests with different plunge rates and ran each test 3 times. I annotated the difference between the gcode and sled at each pass. Set up the plunge in inches in carbide create, but watched WC in mm to best see any miniscule differences.
Before each run the z axis was zero’d.
I also noticed that the sled did not come up to 5mm at the end of the program like it should of.
1" / min
.01,.02,.02,.01 (in mm)
.01,.01,.01,.02
.01,.01,.01,.01
3" / min
.03,.03,.03,.00
.04,.03,.03,.04
.03,.03,.04,.03
5" / min
.06,.06,.06,.06
.07,.06,.05,.00
.07,.07,.07,.05
8" / min
.03,.06,.09,.05
.06,.10,.08,.10
.11,.09,.15,.02
20" / min
1.80,1.15,1.07,0.98
1.77,1.18,1.08,1.02
1.63,1.14,1.05,0.98
40" / min
4.38,3.64,3.61,2.55
4.21,3.60,3.46,2.59
4.37,3.68,3.60,2.56
Not sure if this provides any additional info for helping me solve this problem.
Once again, thanks for all your help and time.
-Tim
1 Like
If I am I interpreting this correctly, the error is off proportionally as a function of speed. Faster is more deviation. This is a control loop tuning problem.
2 Likes
Im feeing the same way if im reading his data correctly. Although he did report that the last time he changed his settings he didn’t see any changes in the deviation.
@TimS , can you go the other way with your plunge rates and see what you get? Another experiment you can do is to try changing the PID settings again but at the higher plunge rate where the error is more pronounced.
Can we verify that the PID settings are actually getting updated on the machine?
Maybe the easiest way to do that is to set all the Z-axis PID values to like 0.00001 and see that it doesn’t move at all.
Just a sanity check that we’re actually tuning it
being a bit lazy here, since there are two layers of PID, how do the tuning
parameters get applied? I assume that it’s not the same to both layers.
is there a B code that will export the current parameters? (if not, can we add
one?)
David Lang
With the same test as above with lower plunge rates. (Soooooo Slowww) WC .94 / 51.30
0.5 in /min
.00,.01,.00,.01 (in mm)
.01,.01,.00,.01
.01,.01,.01,.01
0.25 in /min
.01,.01,.00,.00
.00,.01,-.01,.00
.00,.01,.00,.00
This did not have any effect, the z axis still moves. WC .94 and .957 with 51.30 and 51.27. Refreshed, restarted. I reloaded 51.27 thinking that maybe there may be an error in Orob’s firmware (51.30) and I ran the 40 in/min test the error isn’t as large.
Original test that was posted above and new test with .94 WC with 51.27:
1" / min w/51.30
.01,.02,.02,.01
.01,.01,.01,.02
.01,.01,.01,.01
1" / min w/51.27
.00,.01,.01,.01
.01,.01,.00.,01
.01,.01,.00,.01
5" / min w/51.30
.06,.06,.06,.06
.07,.06,.05,.00
.07,.07,.07,.05
5" / min w/51.27
.06,.05,.05,.06
.06,.03,.05,.06
.08,.06,.07,.06
20" / min w/51.30
1.80,1.15,1.07,0.98
1.77,1.18,1.08,1.02
1.63,1.14,1.05,0.98
20" / min w/51.27
.01,.12,.16,.07
.09,.18,.18,.10
.15,.12,.09,.10
40" / min w/51.30
4.38,3.64,3.61,2.55
4.21,3.60,3.46,2.59
4.37,3.68,3.60,2.56
40" / min w/51.27
.13,.14,.13,.17
.16,.19,.16,.16
.21,.15,.16,.18
Well that looks pretty good, right? Those numbers seem much improved.
I think that something might be going on with the z-axis PID settings not being sent to the machine?
Would anyone else be willing to verify that?
Yes, but how?
Changing the z-axis PID values all to zero and verifying that the z-axis doesn’t move anymore should do it.
We just want to see if the values aren’t having an impact only for @TimS or if it’s an issue for everyone
I’ll give it a go. I might not be able to get to it until tomorrow though.
1 Like
Ok, I made a stupid mistake and changed the settings without enabling the custom settings button. All zeros has the z axis not moving. Now going to try and “tune” it
1 Like
oh, oh how I wish I got paid for every time I did that.
2 Likes