I’m glad to know it’s not just me. I’m sure there’s a simple explanation for it, but I certainly don’t see it.
1 Like
I wonder if the issue that is seen with the B02 command is somehow related to the issue we see with Maslow measuring distance between motors.
Right now, GC issues a B11 S255 T3 L command to pull tight the left chain for three seconds. It’s immediately followed by a B10 L command. In the firmware, if I understand it correctly, there’s no pausing between gcodes. As soon as the B11 command is completed, it executes the B10 command. What if we need to give it a short period of time to “stablize” or whatever and do then do the read? Or should we do the reads during the loop where the directWrite to the gearbox encoder is happening and some how take the most stable reading during that period? Just some thoughts…
2 Likes
What’s the purpose of the “detach” commands? Why do we attach and detach from the axes (which then attach and detach from the motors)?
This runs the ‘L’ left motor at ‘S’ speed for ‘T’ seconds, and the next line isn’t executed until that is finished. I think the assumption is that will tension the chain and the gearing will prevent rebound. If rebound is a problem, wouldn’t waiting make it worse? Rebound probably isn’t happening though, aren’t we finding that the B10 value comes back short rather than long?
The theory is that it’s more of an reading problem than a physical problem. Maybe just reading something so soon after an event causes an issue. For example, when the B02 command is run and immediately read afterwards, the value is too low. Reading it sometime later provides the correct value.
1 Like
Just wondering: there are all sorts of correction parameters. Do they influence the commands?
Are you referring to things like chain sag, chain tolerance, rotational radius? etc?
I’ll re-run my test, but I found that B02 came up physically short of the target position, while B09 was spot on.
1 Like
Interesting… my B02 came up 01.17 mm long but reported to be 1.33 mm short at the conclusion of the singleAxisMove routine and later reported 01.17 mm long when the position was read a few seconds later.
B09 was spot on (+/- 0.01 mm)
Indeed. I must say, I’ve not taken a look at the code yet. So I may be very wrong 
Here’s what I think are the pertinent points:
These commands all send a chain length destination in millimeters to Motion:singleAxisMove() which accounts for the current position and calculates the step distance to move per PID loop (stepSizeMM) and the number of loops the movement should take (finalNumberOfSteps). Then it loops, commanding the axis is to move a step distance each time through, until the calculated number of steps have completed.
Axis uses _mmPerRotation to calculate movement from encoder changes, and _mmPerRotation comes from the pitch defined by sysSettings.distPerRotLeftChainTolerance or sysSettings.distPerRotRightChainTolerance, which come from GC $40 and $41 and/or groundcontrol.ini distperrotleftchaintolerance and distperrotrightchaintolerance.
main.py:computeSettings() calculates those distPerRotXXXXChainTolerance values from chain tolerance, chain pitch and gear teeth for each side.
Those types of correction parameters don’t affect it. Those parameters determine the target chain lengths for certain gcode commands. When you issue a B02, you just telling the controller to turn the sprocket a specific amount of times based upon the number of teeth of the sprocket and the pitch of the chain.
Sorry @blurfl, I started this, got distracted, you responded, and I hit Save 
we detach from the motors to avoid the waste of power to keep making micro
adjustments to them (and the heat generated)
If the pid settings were really right, we should not need to do this.
another advantage of detaching is that we ignore the encoder lines to the
motors, so electrical noise being picked up in the wires doesn’t fool us into
thinking that the motors are moving.
David Lang
2 Likes
I just ran into this myself today. Surprised this has been an issue for two years. It was very disturbing when I saw it, I was concerned that our encoder counts could have gotten messed up again. But I was relieved to find this thread.
The issue wasn’t really software, but more of a controls issue. The difference between B02 and B09 is that B02 directly called axis.detach() when it was done. This is a no-no. The PID controls should handle detaching the axes directly, and nothing else except maybe an E-Stop.
What was happening, was that the final position call was made to endMove, and then before that could be completed, B02 would get the axis position and print it. This is why it reported being less than the commanded length. Then it would call detach() before endMove() could finish its job. When the axis is detached while moving it has some momentum so it would carry on past the desired location. endMove drives the axis to a stop by reversing to brake at the proper location.
Anyways, it was a simple fix, and now we end up at the precise step count that we expect. I made this pull request https://github.com/WebControlCNC/Firmware/pull/8 but honestly, I have no idea where things are supposed to go these days.
5 Likes
I guess that’s as good of a place as any. I’m not really sure how to manage the webcontrol releases. I used to build everything on a set of VMs and an RPI, but with the move over to the new repo and other people working on it, not really sure where we stand with it.
Nonetheless, great sloothing. That problem bothered me for a very long time and I never could figure it out.
1 Like