Yeah, sorry - I should have been clearer with my thoughts. What happens is that due to tweaked PID values and oscillations, the calibration cuts tend to be curved - when that happens, it’s hard to know what to measure on, and it gets difficult to calibrate.
In my case, even the default PID values cause this, so I was trying to adjust while calibrating, which was a frustrating exercise that was never a good idea to begin with. The difficulty is testing over the full range of motion - the jittering varies - I guess due to variable torque on the motors, backlash, etc?
What I’m thinking about doing is using something like the Google Science app (which lets you log accelerometer motion on your phone) to understand the time periodicity of the oscillations, and therefore (hopefully) allow for better PID tuning. I can then just attach my phone to the sled and run a full range-of-motion test. If there’s a better way to get this, please let me know.
How are things concerning this issue?
I seem to have the same problem. Right motor is running smooth but the left makes the exact same noise as the one in the video at the beginning of this topic. Not always and not in every direction of sled movement but I can’t go above 200mm (80inch)per minute feed rate to avoid jerky sled movement and swinging chains.
GC and firmware 1.02
The current status of this issue is that a significant number of people see it. We’ve established that it is not a hardware issue because I’ve sent new hardware and that hasn’t fixed the problem, plus it doesn’t show up on versions less than .98 .
It also doesn’t happen all the time, and none of the people working on the software have been able to make it happen and it is very difficult to fix a problem if we can’t replicate it.
Changing the PID values will make it go away but possibly reduce the accuracy of the machine.
the pid settings changed after .98, and that really does make sense as the
problem.
PID settings are always a trade-off between how aggressivly the machine tries to
be exactly where it’s supposed to be and how getting too aggressive and going
into an oscillation (overshooting and then trying to back up, etc)
We need a wiki page explaining this and suggesting ways to adjust the PID values
for the maslow.
It does oddly seem like there is some large but a minority percentage for whom the velocity PID settings were too aggressive. I seem to recall bumping it down to Kp = 5 solved it for people. I intended on going back and adjusting the Kd value appropriately, but I just forgot. I will do that by this weekend and get a PR for the new PID settings.
I don’t think the accuracy trade off is much if anything, but I will keep an eye out for it.
We should have something that works out of the box for the ‘standard’ maslow,
but as people are building things with different motors, we should be able to
provide them guidence on tweaking things.
Once we get far enough to support acceleration, we can de-tune the PID loop to
be less aggressive, and set the acceleration limit to represent what the PID
look can do.
Right now, since we don’t have acceleration accounted for in the firmware, it’s
trying to go from nothing to full speed instantly (and full speed to nothing
instantly), and that requires tuning the PID loops to be as aggressive as we can
make them without pushing things into instability.
I wonder if we can detect this by doing an unloaded motor test at partial speed
and see if the resulting voltages are relatively stable or if they vary ‘too
much’ (if they ever reverse while we are running at 10% speed, that is clearly
in the ‘too much’ territory)
The latest 1.03 upgrade is a very good one,thanks to those who put effort in to it!
The jerky motor is history and I can now run higher feedrates.
Excellent work!
The Z-axis is rather slow in comparison, I’m using a 2mm per rotation rod and it would be nice if the maximum feed rate the software allows would be a bit higher.
Is that an easy adjustment or am I asking too much?
you ill need to look at replacing the Z xis motor with a faster one. Bar picked
a motor that has a lot of torque, at the expense of speed. He was thinking in
terms of just cutting full depth things so you only need to adjust the Z once
every pass around the object, so speed doesn’t matter
now that we are using the maslow for other things, the motor choice isn’t ideal.
It’s not a big problem,certainly not doing profiles but I’m now doing a lot of pockets in one go and makercam is not very efficient in it’s planning.
Maybe I should look at other cam software.
I’ve been using gcodemillopt to optimize the output of makercam and generally it works very well… However, the last thing I tried messed up optimizing it. Ymmv
Chiming in here, I just got my Maslow up and running for calibrations and I am seeing this same behavior on my left motor. I am running GC 1.02 and the 1.02 firmware. It is intermittent like the OP said the jerky motion was present during all of the calibration stage.
Before I made any actual cuts I ran the sled tool path just to test that things were working as intended. That is when I noticed it improve at higher speeds.
I have made no changes to the stock settings except performing the calibration.
I will upgrade to this new 1.04 version and confirm that the jerky motor issue is solved.
Just got to test this out and while I see a big improvement, my left motor still is doing a slight jerk or pause. I am almost certain it is doing it at specific frequency like once every 2 seconds or something like that. I’ll see if I can get a video.
FYI - the 1 motor is on a controller running at a different clock frequency. This is why the make different noises. Can you send a video of what your motion looks like now?
You can see in the video the very short pauses it is making. It’s not much but it is more than the right motor.
I uploaded the original quality because it was extremely hard to see in the compressed video. I think it may be a little easier to see when watching the sled but you can hear slight pauses of the motor. I may be nuts.
I see it. I think that might be a pause between executing lines of gcode. Why that would be more pronounced on the left then the right is a mystery to me, but I think the place to address this is by speeding up the way gcode is processed. Right now each line is run, then the machine tells Ground Control that it is ready for a new one and GC sends one. I believe there is about a 50ms delay in that process which is probably what we are seeing.
The machine has an onboard buffer which is designed to hold multiple lines of code so that they can be processed one right after the other and we had that system working with I believe around a 6ms delay between lines so a 10x improvement but we were seeing that sometimes some people would lose maybe 1 in 1000 lines of gcode somewhere in the process so we reverted to the current system to fix that issue.
It might be time to go back to buffering lines, or maybe make it an option in settings with defaults to off until we’ve got all the kinks worked out.
The short version is that you are not crazy, I see that pause too and I think it’s something that everyone sees and we should fix it, but you should ignore it
.