I find it responds normally, after I remembered to kill Arduino and restart GC 
1 Like
Great! Thanks for checking that. I feel better now 
Curious if you tried the new firmware with GC 0.82?
Yes, version 0.82 on both ends. I’ve tried Linux, mac and Windows, all connect correctly. Are you having an issue getting GC v0.82 to talk to firmware 0.82 at all? If so, we can troubleshoot that.
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:
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 
. 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? 
1 Like
Great suggestion! Version numbers bumped 
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
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