Interstitial Firmware Releases

[md8n]

And here’s the fix for the toolpath-displayer bugs, it was a small merge problem (of my making), so this is a small rollback, a not so small roll-forward, and a cleanup of some confusion.

I’ve already tested it here, but obviously YMMV

Tool path displayer update by md8n · Pull Request #116 · BarbourSmith/ESP3D-WEBUI

[ian_ab]

Tried this out, couldn’t extend belts past 1700 mm, so could not put on frame.

[md8n]

Thanks - I’ll explore what the reason will be

[md8n]

Just double-checking here - you did go into the Setup dialog and then clicked on the ‘Config’ button to get to this dialog?

1700 is the default. After changing it you’ll need to hit ‘Save’ of course - again apologies if I’m stating the obvious and you’ve already done that

[ian_ab]

Yes, did that several times , it didn’t change the amount it was feeding out. Also tried powering off and and back on. Also no joy. The new Extend Dist was still there but it just ignored it. I have reset to V86, then V88 (original) and it now operates correctly.

[md8n]

Thanks for the feedback - I think I understand where I need to look more clearly now

[md8n]

OK - I’ve dug through this a lot, and I cannot replicate it.

I even tried setting the extend length to 150mm (stupid short) and it worked no problem.

But I have been sitting on some code to make maslow.js a bit more generic. So I migrated that onto a branch based on Maslow Main and it’s working great. All yours @bar Generic-ish handling of maslow config stuff by md8n · Pull Request #117 · BarbourSmith/ESP3D-WEBUI

[ian_ab]

I reloaded the V88.1 again and still ignores whatever I set Extend Dist. Tried 150mm with a power reset for M4, still extends to 1.7 mm. If you can think of anything else I can do to help then let me know.

[Justus]

@willpuckett

just did a build that’s working with the enlarged flash, but I’m not very experienced with these things…

Does this look right to you?

# Name   ,Type ,SubType  ,Offset   ,Size     ,Flags
nvs      ,data ,nvs      ,0x9000   ,0x5000   ,
otadata  ,data ,ota      ,0xe000   ,0x2000   ,
app0     ,app  ,ota_0    ,0x10000  ,0x2F0000 ,
app1     ,app  ,ota_1    ,0x300000 ,0x2F0000 ,
spiffs   ,data ,spiffs   ,0x5F0000 ,0x1F0000 ,
coredump ,data ,coredump ,0x7E0000 ,64K

Looks good to me! You actually have another 64KB (0x10000) to spare, but that’s just a drop in a comfortably sized bucket.

[Justus]

@willpuckett

I also tested downgrading to an older version via web interface. While the upload works and the board restarts and runs, I’m pretty sure it’s gonna write to the wrong place at some point, and that it would be unadvisable to downgrade without wiping and repartitioning.

I agree. I initially expected a firmware upload to not change the partition table, but it appears to do so. I don’t know how it does it or the full effects. However, to be safe, I’d advise performing any upgrades or downgrades that affect the partition table using the command-line utilities.

[md8n]

OK - I suspect the problem is in the firmware and not in the front end code.

I’m still running v0.88 on my M4, but with the updated UI code.

[ian_ab]

Yes, that appears to be it. I loaded the v88 firmware code and the updated UI code, the belts extend correctly.

[ian_ab]

Bar, this firmware bin ignores Extend Dist, always runs to 1700mm

[willpuckett]

So glad you said this I was misattributing that to some of my other testing

[willpuckett]

@Justus

Looks good to me! You actually have another 64KB (0x10000) to spare, but that’s just a drop in a comfortably sized bucket.

I had that 64k split between the app partitions initially, but they have to be in 4
64kincrements… I’ll add it to the spiffs partition.

Do these partition sizes seem reasonable for the maslow app? It’s hard to predict the future, but it would be nice for users to not have to do a full install again for a long time…

[bar]

@ian_ab

Bar, this firmware bin ignores Extend Dist, always runs to 1700mm

Thanks for catching that, I will dig into what is going on there!

[bar]

I’ve been working on improving the calibration process so that the UI better reflects what is happening in the background.

To do that I added these buttons over on the right side of the UI which will dynamically change to show just the actions which are available from the current state.

Unfortunately after building this I’ve decided that its not quite right. I think that having those buttons on the home screen is just asking for them to be clicked accidentally.

I think that the right answer is to have those buttons stay on the setup popup, but to better show the current state there and also make it clear which actions are available at the moment there so that’s my next plan.

In the meantime I would love feedback on what everyone’s thoughts are on how the system works and how it could be better.

Here is 1.04.1:

firmware.bin (1.9 MB)
index.html.gz (117.4 KB)

[ian_ab]

@bar

just asking for them to be clicked accidentally.

If you leave dynamic buttons on the front screen, can you make it so you have to confirm (i.e. Continue) e.g. “Click OK to Confirm Retraction” etc.
When you Extend All it changes all buttons to extending, I think Retract all should still be an option on the menu, as I don’t always want to extend all the way out.

[ian_ab]

Also release tension to still be available. I have to use this multiple times in order to get M4 off the frame as two belts stay tight after the first release and sometimes the second. I do like them on the front screen.

[bar]

Yeah, I think that just having three at a time available isn’t enough