Testing needed on Pending patches

Maslow-serial (81).log (2.7 KB)

Updated firmware, powered down and restarted, tried jog, get not ready message

ok, just to be sure, here is a build that I manually tinkered with the version on. it should report as version v1.12-9-gfa754ec3

firmware.bin (1.9 MB)

it includes these debug log statements:

        log_debug("Belt positions NOT saved - invalid state (not READY_TO_CUT or RETRACTED), currentState=" << currentState);
    log_debug("Belt positions saved to NVS: TL=" << tlPos << " TR=" << trPos << " BL=" << blPos << " BR=" << brPos
        log_debug("Belt positions NOT loaded from NVS - data is stale/invalid or not found");
    log_debug("Belt positions loaded from NVS: TL=" << tlPos << " TR=" << trPos << " BL=" << blPos << " BR=" << brPos
    log_debug("Belt positions marked as stale/invalid in NVS, state=" << currentState);

please verify that the flash settings are set to debug for the message level

ok, that version number didn’t work (there are too many places that version numbers are currently set, I really look forward to @bar merging the PR that sets them all based on git info)

with debug set, you should see a lot more stuff in the logs

starting at the beginning with stuff like:
erial Messages
Index.html Version: 1.12
[MSG:DBG: WebSocket 0 from 10.2.2.53 uri /]
[MSG:INFO: Channel auto report interval set to 50 ms]
[MSG:INFO: FluidNC v1.12 (HEAD-fa754ec3-dirty)]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
[MSG:DBG: Spiffs mount failed: ESP_FAIL]

Loaded firmware you sent, powered off did the dance, couple of moves then log file

Maslow-serial (84).log (4.4 KB)
Power down, power up

Refresh browser attempted

move No joy. Setup menu State: Unknown

Maslow-serial (85).log (2.6 KB)

I’m nagging copilot to track this down, your two logs were a huge help in
providing evidence.

it created a new version that is supposed to have more debug logging to try and
track down why it’s not restoring the data

David Lang

Compile Firmware on MaslowBot Review Request #501

Loaded firmware, powered down powered up, did dance, jogged Maslow log file prior to power off

Maslow-serial (86).log (5.4 KB)

Power off, power on, refresh browser, attempt move - fail log after

Maslow-serial (87).log (2.6 KB)

thanks, I see nothing in the second log about it doing anything to try and load
belt lengths. reported to copilot

David Lang

next version:

comments from copilot:

This is very concerning - the function should be called and log messages should
appear. Added extensive logging in commit (hash will show after push) that logs:

“Maslow.begin() called - about to check if positions should be loaded”
“positionsLoaded flag is: true/false” - shows static flag state
“Calling loadZPos() and loadBeltPositions()” - confirms functions are called
“Skipping NVS load - positions already loaded” - if flag prevents loading
Critical question: Could the static flag somehow persist across power cycles?
This shouldn’t be possible in C++, but these logs will reveal if that’s
happening.

Please test with this build and share logs. If we don’t see “Maslow.begin()
called”, then begin() itself isn’t executing, which would indicate a deeper
issue with how Maslow is integrated into the main loop.

Compile Firmware on MaslowBot Review Request #505

Loaded firmware, powered down powered up, did dance, jogged Maslow log file prior to power off

Maslow-serial (88).log (5.5 KB)

Power off, power on, refresh browser, Setup State: Unknown

Maslow-serial (89).log (3.7 KB)

attempt move - fail log after

reported, FYI, this is how my report looks if you want to go direct. I’m happy
to remain in the loop, but I don’t have to be.

David Lang

looked at this it has log(86) instead of 89 after log(88)

I see none of your new log messages

Review Request bdring#505

Loaded firmware, powered down powered up, did dance, jogged Maslow log file prior to power off

Maslow-serial (88).log

Power off, power on, refresh browser, Setup State: Unknown

Maslow-serial (86).log

attempt move - fail log after

oops, thanks for the catch.

one thing I just found, some of the logging data is not showing up in the window. I hooked up a USB cable to see the serial port directly and saw additional log data :frowning:

do you have the ability to do this?

I can connect a cable

serialportdump.txt (26.4 KB)

This from startiing Maslow after Retract, extend etc

Maslow-serial (90).log (5.2 KB)

I’ve had copilot look into what’s happening with the UI, it turns out that that
textbox has another filter function that’s causing it to not display logs.

I’m having copilot compare log data from my no-motor/encoder dev setup and
report what it’s fix will display.

Bar probably doesn’t want to put this in directly, but it will be something we
can load while troubleshooting at the very least.

David Lang

Do you want me to power down and restart next?

Maslow-serial (91).log (2.5 KB)

serialDumpAafterPowerReset.txt (7.7 KB)

I think this is showing that it is loading the data, but there is some state somewhere that’s not being set

Yes status is set to zero, which I think means unknown

it was issuing the request to change state to ready to cut, but the filtering
blocked that (you can’t change from unknown to ready to cut)

so now it’s working on a PR to directly set that state.

It was spinning for 20 min before it said ‘wait, I actually need to change the
code’ and started working again

so there should be a new build shortly

ugh, it may be stuck in a loop. I asked it to remove some logging from a commit
and it keeps going ‘let me see what was part of the commit’ again and again…

this AI is like a very eager, very junior, programmer with limited judgement and
the attention span of a fly (so I guess, not to different than new hires out of
school :slight_smile: )

David Lang

It’s painful but having to go through the dance is so annoying. I’ll be glad when it’s just an occasional requirement after a failure. I appreciate how much effort you are putting into this. It will be well worth it

belt length save across restart
this should report as v1.12-11-g3d0e784b

firmware.bin (1.9 MB)

give this one a try, there is one thing that may still need to be added (a call to explicitly say the machine is idle) but that may not be needed

please capture the USB serial port output as this starts up