Do I have a bad motor?

No issues getting 0.82 GC to talk to 0.82 firmware - that works fine.

When I grab the latest firmware from GitHub (unnamed), 0.82 GC will say that it connects fine to the Maslow, but when I issue commands, it doesn’t respond at all. Have you happened to have tried that particular combination?

I should probably just pull the latest GC as well, but it will take a little while to get the dev environment set up on that PC, I think…

Yes, I used the firmware updated earlier this morning.
Try this -msetmupma macro to send B05 (B zero 5) and send that. The Maslow should respond with the firmware version number ang GC displays its own. Does that work?

It says:
image

And just to make it a little stranger, the motors do work when being tested - all three pass!

That’s good news, mostly. That means you’ve a good serial connection, and the electronics and motors are good to go.
You could try an Automatic Chain Calibration. If you’ve marked the cal links on the chain, you can get away with setting the 12 o’clock position and then hanging the chains aside while the motors run. At any rate, after calibrating the chain, try the <<Action<<Return to Center to see if that restores control.

Ohhhh I know what’s going on here!

The firmware on master right now is expecting PID values to be sent from Ground Control but 0.82 Ground Control doesn’t send any PID values because that wasn’t a feature yet.

When the firmware doesn’t get PID values they stay at zero and it won’t move, but test motors passes because the hardware is still good.

So to answer the original question does the firmware on github master work without Ground Control version 0.83, the answer is no.

I’d love to know if it fixes your problem before Wednesday so I can keep working on it, so maybe the fastest solution is to build you a version of Ground Control right now so you don’t have to wait. What OS are you using?

2 Likes

Windows - I have the capability of getting a build environment set up, but that can take an indeterminate amount of time, so a pre-built version would be greatly appreciated!

2 Likes

Give this guy a try, and let me know if you see movement:

2 Likes

Works great - have movement! The jerkiness is definitely mitigated quite a bit. You can still hear the pulsing in the left motor, but the overall movement is definitely smoother across a wide range of motions.

I’ll try to cut something and see how it goes…

1 Like

Great news!

Hopefully we can continue to refine those PID values and achieve fully smooth motion

That explains that, then :smile:. I can create the problem on the mac by using the release of GC and the current master of the firmware. The problem is solved as you predict when I use the current master of GC. Time to bump the version number if the current master? :wink:

1 Like

Great suggestion! Version numbers bumped :+1:

1 Like

That explains why the firmware on master didn’t work for me either.

Tried to cut, but decided to set up toolpaths in Fusion360 (I’m familiar with it for designing 3D printed parts, but not for CAM!). Something is mucked up with how it was defining Zs, so I need to stop and think about it for a bit.

I’ll be out of town for a few days, and I hope someone has PID tuning all sorted out when I get back :wink:

1 Like

Been working on this the last couple of days, and tearing my hair out a bit. Now the left motor is fairly smooth, but the right one is giving me fits…

I think - maybe - that messing with the PID values messes with the calibration? Either that, or I mucked up the PID enough that it’s not reading ‘true’. As a side point, in the new version, I get a lot of jerkiness in calibration when setting the right motor pin at 12 o’clock. Sometimes, moving it one degree moves it back and forth and then settles somewhere several degrees away from starting point - oscillation due to bad PID values?

I’m going to do more reading/thinking about PID (definitely a somewhat complicated topic) and looking through the source code to see what I can do to tune the numbers.

The PID values should not make it loose calibration, but they can cause
ocillation and jerkyness

the PID loop is comparing where the bit is with where it’s supposed to be (and a
layer above that that compares the current velocity with what it’s supposed to
be)

In either case, when it detects an error, it works to correct it. If it’s overly
aggressive in correcting the error (the P value), it will jerk and overshoot,
resulting in an error the other way, jerking back. If it’s wildly too low it
will lag behind where it should be.

If the Damping isn’t strong enough, it will just ocillate back and forth
and never settle down.

If the Integration isn’t strong enough, it will never actually reach the target
(although position wise, it should get very close, but velocity wise, it will
never get up to full speed)

In general, you want to ramp the values up until things become unstable and then
back off

I found this video very helpful to understand it.

As I noted above, our case is a bit more complex as we have two layers of PID
loops, one adjusting the speed to try and get the accurate position, and the
second adjusting the power to the motors to try and get the accurate speed. This
makes tuning more complex.

2 Likes

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.

@krkeegan what are your thoughts?

I have had mine mothballed since Harvey, hoping there would be a fix. Tried to adjust PID, but couldn’t ever quite get it resolved satisfactorily.