Encoder steps.. Issue with returning sprocket to 12 o'clock after precise number of links fed out... again

Just wish I could find it. Nothing is making sense. The fact that an axis.read happens after the singleAxisMove reports a value less than the target distance but one that happens a little later (when you go to automatically reset the sprockets) reports a distance that is greater than the target … and representative of actually where the sprocket is.

I would say it doesn’t matter since the controller truly knows how long the chain is and that’s what matters. But if there’s a glitch here, I just get worried there’s a glitch somewhere else that results in overshooting the target during a cut (out of round circles, for instance). I’d say it might be because the distance moved is so high (2032 mm) in the singleAxisMove, but issuing a B09 for the same distance works fine… It’s baffling.

I guess one question I have is this isolated to something in my setup?

1 Like

Here’s the logs. First I did an set zero on the sprockets (I had already did auto adjustment to 12 o’clock), followed by an adjust left chain. The brackets variables indicate the print statements I added to report the variables of singleAxisMove.

Sent: B06 L0 R0
B06 L0 R0
Setting Chain Lengths To:
Left: 0.00mm
Right: 0.00mm
ok
Sent: B02 L1 R0
B02 L1 R0
Measuring out left chain
2032.00mm [endPos]
800.00mm [MMPerMin]
2032.00mm [moveDist]
15239steps [finalNumberOfSteps]
0.13mmpermin [stepSizeMM]
2030.67mm [value reported from axis.read at end of calibrate chain lengths]

Then I did another automatic and set zero. The error from 12 o’clock was 1.17 mm

Sent: B10 L
B10 L
ok
Sent: B10 R
B10 R
ok
Sent: G91
G91
ok
Sent: B09 L-1.17
B09 L-1.17

2032.00mm [endPos]
800.00mm [MMPerMin]
-1.17mm [moveDist]
8steps [finalNumberOfSteps]
-0.13mmpermin [stepsizeMM]
ok
Sent: B09 R-0.0
B09 R-0.0
ok
Sent: G90
G90

Sent: B06 L0 R0
B06 L0 R0
Setting Chain Lengths To:
Left: 0.00mm
Right: 0.00mm
ok
Message: Notice: Exiting the calibration process early may result in incorrect calibration.Sent: ~
ok

finally, sent a B09 L2032:

Sent: B09 L2032
B09 L2032
2032.00mm [endPos]
800.00mm [MMPerMin]
2031.94mm [moveDist]
15239steps [finalNumberOfSteps]
0.13mmpermin [stepSizeMM]

this time, there error was only 0.01 mm

If there isn’t any rounding going on with how the variables are being reported to the log, it makes no sense for the same values to provide differing results.

1 Like

I figured out how to print out more digits and the numbers are truly identical. stepSizeMM is 0.1333333333.

2 Likes

Well, I’m moving on from this since I can’t figure it out. I’ve changed GC to do a B09 command instead:

chainLength = App.get_running_app().data.config.get(‘Advanced Settings’, ‘chainExtendLength’) self.data.gcode_queue.put(“B09 L”+str(chainLength)+" R0 ")

1 Like

I find that B02 comes up short on my setup too. B09 is quite accurate.

1 Like

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 :wink:

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 :slight_smile:

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