Issue Calibrating - "Pull chain tight and measure" doesn't stop pulling

Drunk and fishing in the dark :grin:
Did you extend the top beam to 5 M?

Left Chain Length Greater than System Settings Chain Length LeftChainLength: 5415.68 System Chain Length: 3810

You did not extend your top beam to 12ft and increased the length of the chains without telling GC that?
Feel free to ignore all comment till 8 hours in the future :wink:

Edit: Sorry, was meant as a joke. Looking at it now, it was a bad one.
Wouldn’t a broken gear with the encoder intact give exactly this feedback?

Edit2: A slipping sprocket would do the same, if the screw is not tight on the flat side of the motor shaft.

1 Like

I set my chain length to 3810 in GC. The bit about 5415.68 is very interesting. Yeah I guess I need to open up the left motor, although completing the holey calibration processes did not show any signs of motor or gear issues.

Very good troubleshooting, Gero. Thank you. I will check and report back.

The gears are fine (now I need to recalibrate :frowning: ). I really don’t think the sprocket was slipping because the lock screw was tight to the flat side of the motor shaft.
While I’m glad I don’t need to buy a new motor, I’m even more puzzled as to what the issue it. I’m going to go through the calibration routine again and see what happens.

1 Like

Using the encoders to detect a stall could be a future improvement, plus it would reduce bending and give a more accurate spacing calculation

1 Like

And strip fewer gears

1 Like

it would also probably save gears to ramp up the power (33% 1 sec, 66% 1 sec,
100% 1 sec)

David Lang

1 Like

I just went through calibration again after putting the motor back together. Same thing; pull tight doesn’t stop pulling. I do not hear the beeping sound from the motor like normal. I guess I should swap motors.

EDIT1: Although, if there are no motor or encoder monitoring functions as part of this, why doesn’t the motor stop pulling and extend a bit?

EDIT2: I realized that I did not wipe EEPROM before trying this again, since the log showed my chain length as something very long, which might have caused a hang up in the software to prevent pull-tight from stopping. This time I wiped everything (deleted log and ini files) and started fresh but the issue remains. Now I will swap motors to see if maybe there is something wrong that I did not see when inspecting the gears (I took all of them off and they were fine). More concise log files here (2 and 3 should be pretty clean):
log (2).txt (101.5 KB) log (3).txt (103.1 KB) log.txt (94.9 KB)

Is this a software issue?

probably, can you look at your groundcontrol.log file and see if it shows
anything odd?

I believe you said you were using the January version of GC and the firmware,
correct?

try detaching the chain from the motor and letting it run, see if it just keeps
running or if it stops after a few seconds

David Lang

1 Like

There appears to be an issue with how long it thinks the chain is.

I’m actually using the latest Holey GC and FW forks, which have the v1.26 master GC and FW merged into the fork.

Good idea. Getting set up now. I did swap left and right motors.

I am realizing that the previous attempt, after I wiped eeprom, I did not set my chain length to actual (3810 actual vs 3360 default). That may be what tripped me up.

Thanks for your help.

EDIT1: Something troubling…after wiping eeprom, I’ve been getting the “unable to find valid machine position for chain lengths…”. With fresh fw in the arduino and default gc I would get this:
image
and after updating my actual chain length, it changed to this:

image

After doing a motor/encoder test (all passed) the error changes to this (WHEN I PRESS THE STOP BUTTON):
image

I did not have these troubles the first time I ran the latest Holey GC (GUI). I don’t believe I did a eeprom wipe.

It’s actually possible to skip this part of the calibration and manually enter the distance between the motors. I too found this procedure rather awkward at best. After I rebuilt my frame with a unistrut top bar, I simply measured the distance between the motors with a metric tape measure, loaded Holey GC/firmware and manually entered the length. I’ve had good success chip making, ever since.

1 Like

I agree, however; if we are going to keep the step, it needs to work :slight_smile: As you can see above I did the same thing and had a very good calibration result.

1 Like

Back to the position error due to chain lengths…
The only way I could get it to go away was to go to Advanced>Set Chain Length - Manual.

Swapped motors and the issue is still there. Something is going on in the software.
The end of this file should be the pull-tight. Prior to that, I set the chain lengths manually.log (4).txt (155.0 KB)

After messing with this, I think the chain lengths are messed up long before the pull-tight calibration step.

so I was the one who thought up this way of measuring the motor distance way
back in the kickstarter days when the motors were mounted at an angle and it was
really hard to measure. This was a huge step forward at the time.

Since we switched to the top beam, it’s really easy to measure from the outside
to outside of each motor and subtract 40mm and get the accurate measurement of
the distance between motors (to the limit of your tape measure accuracy, see the
‘type 1 vs type 2’ tape measure accuracy discussion)

So for the standard calibration you are better off just measuring it.

However, I think there are still a couple good reasons for pulling the chain
tight.

  1. find out if the frame flexes or the motor mounts shift on you. Better to find
    this out early than have it be a source of error that you don’t know about.

  2. find out what the chain tolerance error is (the chain has tiny gaps between
    the pins and the holes so it can move, over 500+ links, this adds up to a
    noticable error)

So I advocate that the process should be

  1. measure the distance between the motors
  2. pull the chain tight (without quite as much ofa jerk as we currently give it)
  3. measure the distance between the motors again (hopefully it will be the same
    as above, if it’s significantly off, look to fix frame flex)
  4. compare the measured distance with the calculated distance with the chain.

it would be best to pull with both motors rather than just one, but the firmware
doesn’t currently allow this.

I don’t know if the chain stretch is significantly more with high tension
compared to low tension, I know that the sag will be significantly lower.

It would be good to have someone test under low tension, and take a long
straightedge and lift up the middle while the motors are running at low power
and see how much it moves

pull the chain tight under low power
record the chain length
apply low power to the motors, lift the middle with a long strightedge to remove
sag
record the chain length
release the tension (run one motor the other direction for a short distance
ramp power up to high on the motors
record the chain length
(and release the tension when it’s done)

David Lang

2 Likes

How are this 3 values in gc.ini compared to real life?

motorspacingx = 3495.28
chainextendlength = 2032.0
chainlength = 3360.0

Motorspacingx of 3495.28 mm does not pertain to anything that I know of. I measure 3617.6 mm for my motor spacing.
Chainextendlength - I have not tested but it seems like the motors don’t actually let out 2032 mm (I felt this way with stock fw with default extend length value too).
Chainlength - I have measured my chains, while on the floor under no tension, which is 3810 mm. I put that into GC.

1 Like

So, I’ve looked into this a little. No testing, though.

It looks like the “Pull Chain Tight” command is a B11 command. Here is the GC code where this is done.
GroundControlPullChainTightCode

The specific command used is “B11 S255 T3 L”. It looks like the S255 is the speed (normalized to 255, meaning 100% speed), and T3 is the time in seconds. So, based on the command, it should pull for 3 seconds, and stop.

Here is the code in the Firmware where this is actually executed.

It pulls a speed and a time from the gcode command, converts the time to milliseconds, and loops for the specified period of time “while (millis()-begin < ms){…” This is exactly inline with what it should do. I am wondering if there is something lost in translation between GC and the Firmware. Something like, there are characters being manipulated by GC, or the Firmware isn’t parsing the characters correctly.

I did look in the Arduino documentation of millis(). Their implementation stores the output of millis() as an “unsigned long”; however, in the Firmware, it is being assigned to a “double”. This might need more research.

2 Likes

Look in log.txt - search for ‘B11’ to see GC log the command when sent, and a couple lines later Firmware should echo back the gcode line it received.

It looks like the B11 command was received and echoed. Then, the B10 L command was received and echoed. However, nothing is printed which shows the actual chain length.
Then, there was an error message, "Couldn’t find valid machine position for "

1 Like