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

Troubleshooting
41

So after the B11 echo, the Firmware executes the code block above. I wonder whether millis() rolled over during the while loop; would that cause the motor to run on?

42

I don’t think so. GC received a “ok” afterward. When I see that, I think it exited the B11 command. This makes me believe the motor is not still “pulling”. Instead, it just doesn’t release the tension.

1 Like
43

@Joshua I just recovered from a HD crash and took the opportunity to install your fork and I can confirm that the “pull tight and measure” routine never releases the chains and never resolves a measurement. I saw this thread while setting up hardware and thought I’d try it.

3 Likes
44

I have no idea how off-topic this could be, however will throw it in just as a ‘noob’ question.
GC/FW 1.27 has done some change in how the Eeprom is written. Tried 1.27 for over 30 hours in Fake-Server on my desk. I was good in making this ‘fake Maslow arduino’ insane with 1.26, and can’t get it to this unpredictable stage any more. If it’s unrelated, sorry.
How difficult would it be to have a test FW/GW hosted, where only the Eeprom part is merged for volunteers (preferably those that can replicate the issue) :wink: ? ← The noob question

45

That’s good news, @madgrizzle 's patches were to address that issue. :+1:

Not quite clear about this, but “anything’s possible with software” , well… What do you have in mind?

46

If Joshua’s fork is still on 1.26, then a quick test just merging the Eeprom (if other would conflict) part could save some digging time, or not. Depends on the result. :man_shrugging:

1 Like
47

I think I did this. I remember, as part of the pull from MaslowCNC/Firmware:main, there were commits from @madgrizzle, mentioning EEPROM updates. However, when I look at the changes, I cannot find where it is. There are not (currently) any changes in MaslowCNC/Firmware:main that I can merge in the Holey Calibration fork.

Here they are. Below is a screenshot from the schmittjoshc/Firmware commit history.

HoleyGCMerges
HoleyGCMerges1023×487 30.9 KB

3 Likes
48

Those look like the patches I remembered. @Gero, is that what you had in mind?

2 Likes
49

I’m not sure how the changes to eeprom would affect this. The change I made was to only write to eeprom when there was something to write. The problem is that the firmware is not responding with the encoder read (result of B10 L command) and therefore ground control can’t execute the callback that’s used to move to the next step (ground control should be assigning a callback to be executed when the B10 result is received).

@joshua can you post the part of the log where the B10 command is issued/echoed?

2 Likes
50

After receiving the B10 command, the controller is supposed to respond with a:

[Measure: xxxxxx]

Is this problem something that has just started to happen?

1 Like
51
52

Sorry for being a little behind on the thread… which firmware version are you using?

53

:smiley:

I did not have this issue with Holey Calibration fork when it was in sync with v1.25

54

“Message: Unable to find valid machine position for chain lengths 0.00, 0.00 Left Chain Length Greater than System Settings Chain Length LeftChainLength: 4393.02 System Chain Length: 3360”

This was in the first log linked “log (2).txt” … out of curiosity how wide is the top beam?

55

The B10 command isn’t anything special:

if(gcodeLine.substring(0, 3) == "B10"){
    //measure the left axis chain length
    Serial.print(F("[Measure: "));
    if (gcodeLine.indexOf('L') != -1){
        Serial.print(leftAxis.read());
    }
    else{
        Serial.print(rightAxis.read());
    }
    Serial.println(F("]"));
    return STATUS_OK;
}

Since the logs don’t show that message being received by ground control, I assume the controller either is getting hung up somewhere and the only place it can get hung up is in the encoder read section… but I looked at the firmware and didn’t see anything that was changed in the read (it doesn’t read position from the eeprom).

I’d be curious to know what happens if you just manually issue the “B10 L” command using a macro.

56

Interesting…I also just started having an issue with the red and black crosshairs not following each other and no errors from the system:

57

~12’

58

Interesting…I also just started having an issue with the red and black crosshairs not following each other and no errors from the system:

59

I’ve hesitated to put all this in the holey calibration thread since it is becoming clear there are issues with 1.26 and I don’t want to confuse that with Holey.

60

The current master branch of holey calibration is running all v1.27 changes. Are you using an older version of firmware?

1 Like