Here’s a thermal view of the controller while operating. The hotter one is on the right side of the board (looking at it), which controls the left side motor on the Maslow (Port 3). I suppose this one also controls the Z-axis (Port 2)?, so it makes some sense for it to be hotter?
Temperatures of both chips seem to be about the same - about 172F, so the heat sinks are working, but the right (Port 3 side) one is working harder than the other one, for sure.
Oh, and I physically swapped the cables, with no change - so no problems there. I didn’t see anywhere in GroundControl where I could swap the axes?
To swap axes requires delving into the firmware. There are a couple places that need to change but I don’t remember off the top of my head. If you’re heavy into investigating mode I can dig them out…
I’d wait to hear what @bar thinks would be the best next thing to try. He should be able to see the issue from the great info you’ve provided.
Did the lower speed make any difference?
If you’re up for swappig the motor definitions in software, here are the edits. In CNC_Functions.h the motors are defined in lines 129 and 130. Here I’ve //commented out the original lines and put the swapped lines beneath. Upload, swap the two connectors, and in GC, ‘Test Motors/Encoders’ to assure that left is left and right is correct 
.
//Axis leftAxis (ENC, IN6, IN5, ENCODER3B, ENCODER3A, “L”, LEFT_EEPROM_ADR, DISTPERROT , ENCODERSTEPS);
//Axis rightAxis(ENA, IN1, IN2, ENCODER1A, ENCODER1B, “R”, RIGHT_EEPROM_ADR, DISTPERROT , ENCODERSTEPS);
Axis rightAxis(ENC, IN6, IN5, ENCODER3B, ENCODER3A, “R”, RIGHT_EEPROM_ADR, DISTPERROT , ENCODERSTEPS);
Axis leftAxis(ENA, IN1, IN2, ENCODER1A, ENCODER1B, “L”, LEFT_EEPROM_ADR, DISTPERROT , ENCODERSTEPS);
I haven’t taken time yet to see whether the jitter moved on my machine, let us know if you find time to test.
I’ll hold my breath and see what @bar has to say, but have no problems adjusting the code.
I should have a chance to try decreased feedrate tomorrow as well.
Great debugging everyone!
I’m feeling that the problem described here is related to
http://forums.maslowcnc.com/t/updated-firmware-with-new-board-has-problems/230
Does that sound right?
I have a fix which I think solves the issue, but I didn’t have a fully test it on Friday so more testing is necessary before we can declare it fixed.
I would love any feedback you can give me on of the fix solves the problem for you.
@blurfl is absolutely right that the issue has to do with the PID tuning so this thread is also relevant:
http://forums.maslowcnc.com/t/making-pid-values-adjustable-from-within-ground-control/304
Yes - that sounds absolutely correct - very similar descriptions of the problem, and I’m sorry I missed the other threads!
I will grab the latest off of github, and give it a test. If you have any suggestions for PID value ranges to try, I’m happy to test…
Great! Let me know how it goes!
I can see why both those threads weren’t obvious matches. There’s nothing about the left motor or jerky movement in the title of either
The default values are the best numbers I came up with on Friday, but to be honest I spent most of my time getting the code to play nice (I think) and not a lot of time tweaking them so I’m almost certain there are better ones possible as we refine them.
I would start from those and try tweaking them and observing the results. It seems like at least as much an art as a science 
Is it also worth fooling with feed rate, or just sticking with PID values?
Pretty basic question, but what is being PIDded and what does the PID tuning apply to? Motors holding position? Compensation for sled rocking and/or chain sag? A substitute for acceleration? Something else? My PID tweaking has been for temperature control of 3D printer hot ends, motion control is a whole different can-o-worms.
Our googlian overlords return over half a million hits on pid tuning; the first of which says avoid autotune (which fwiw works pretty well in Marlin for hotend control). However that’s from somebody who makes a living tuning PID controlled devices.
Do you have a way to graph or otherwise display the response of whatever is being tuned (and is that even possible)?
I would look at both the feedrate and the PID values, or more specifically for a set of PID values that look good it is a good idea to check to make sure it still looks good at a range of feedrates.
The shape can also be important because I’ve found sets of values that look good for smooth arcs, but get jumpy around right angles.
The question of what we’re tuning is a good one.
This ancient video gives some background on why the software is the way it is:
Keep in mind while watching it that the changes which are proposed in the video have now been made.
Basically one set of PID values adjusts the way the motor’s speed is set in response to a command, while the second set changes the way the motion of the sled responds to a change in position command
That clip has a great line “too many chances for things to go wrong”
Not a PID expert, but it looks like there could be dragons where the two controllers interact. If I understand correctly the set of parameters will adjust the PWM motor effective voltage for a single motor, while the second set will need to determine which motor is out of position (or rather, causing the bit to be out of position) and can affect more than one motor. Way more complicated than open loop step/dir/pray stepper control. Have to say that’s pretty amazing. Fineness instead of brute force. Servos that aren’t big bucks.
If I understand right then acceleration would just take care of itself. The difference between the motor’s actual and desired speed would ramp up the voltage while reaching the set speed, then ramp down as it approaches, and the position controller would see that all axes take the desired path. Rather than a constant change of velocity the rate of change would vary throughout the whole time the tool is accelerating, the same idea as n’th order acceleration although likely a different way to get there. Or am I (as is traditional for moose) all wet?
I think I forgot how to do that level of math around the time they were renaming the MSC to the JSC…
Unfortunately, that didn’t go well. Updated to the latest firmware from GitHub, but at least with GC 0.82 running, the there’s no response at all to commands. Do I need to update/compile GC as well to talk nicely with the new firmware?
If Arduino is still open, it won’t release the serial port to GroundControl. Could that be the issue?
I don’t think so - I shut GC down each time (have it working again with 0.82 firmware).
Am currently testing slower feedrates - the same problem still exists with the left motor, but it creates less shuddering of the sled.
Sounds like you’ve at least got the 0.82 firmware talking to GC then. When I loaded this combo, I saw jittering on the first six inches or so, but after that it smoothed out.
Just repeated to make sure I didn’t screw it up, and same result. Unfortunately, I have the same left motor problems with 0.81 as 0.82… Looking forward to the 0.83 release on Wednesday, where I think @bar has enabled PID tuning in GC…
Thanks for the heads up that there might be something going on with the master firmware. I’ll make sure that it works smoothly for Wednesday.
Is anyone else seeing issues with the version of the firmware on master? I’m using it right now and it seems OK, but maybe it needs the latest Ground Control also?
Happy to participate in testing, what do you recommend?
Thanks @blurfl!
If you grab the latest firmware and Ground Control from GitHub do you see the machine not responding to any commands?