Maslow Home Maslow Community Garden Newsletter

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

#14

I’ll stop spamming for the night.
I modified the firmware to report the values in singleAxisMove. For both commands, the values were identical:

endPos = 2032.00
moveDist = 2032.00 (hence startingPos = 0.0)
MMperMin = 800
stepSizeMM = 0.13

I’m a bit dumbfounded why the results are different. The main difference I see with the B02 behavior is at the end, the axis read reports a value less than 2032 but it actually overshoots 2032 and the firmware knows it because when the axis is read later, its shown to be greater than 2032.

0 Likes

#15

This is very interesting, I am excited to see what you learn. I don’t have anything to contribute other than that everything you said seems logically sound and I agree that both commands should have the same behavior under those conditions. I agree that it sounds like a software bug to me.

0 Likes

#16

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

#17

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

#18

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

2 Likes

#19

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

#20

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

1 Like

#21

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

#22

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

#23

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)?

0 Likes

#24

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?

0 Likes

#25

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

#26

Just wondering: there are all sorts of correction parameters. Do they influence the commands?

0 Likes

#27

Are you referring to things like chain sag, chain tolerance, rotational radius? etc?

0 Likes

#28

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

#29

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)

0 Likes

#30

Indeed. I must say, I’ve not taken a look at the code yet. So I may be very wrong :wink:

0 Likes

#31

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.

0 Likes

Sprocket does not reset to 12:00 automatically in calibration step 9b
#32

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:

0 Likes

#33

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