Maslow-serial (81).log (2.7 KB)
Updated firmware, powered down and restarted, tried jog, get not ready message
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 ![]()
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
)
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