I’ve been wondering, Isn’t this something the community could take care of? I came across one or two wiki initiatives but nothing solid yet.
1 Like
Here is 0.66.7 which adds a much requested command to drive a motor directly. I’ve been concerned about doing that because I think that it has the potential to cause more issues than it fixes, but @Frank_Wiebenga pointed out that having a command without a button could be a good option to hide it enough that folks won’t click it without knowing what it does. Emergency use only.
We now have a command which you can send directly here
Which will command one motor to spin at full power for 200ms. The options are In/Out for each motor so $TLI, $TLO, $TRI, $TRO, $BLI, $BLO, $BRI, $BRO
index.html.gz (154.0 KB)
maslow.yaml (3.2 KB)
firmware.bin (1.6 MB)
3 Likes
Here is 0.66.8 which is for testing purposes only!.
When you press extend all it will always extend just 1,000mm of belt and then stop. That way we can check that we are measuring correctly.
The extend process will turn off power to the motor at 1,000mm but it will coast a bit so the actual length of belt will keep printing after that so we can get an accurate reading.
index.html.gz (154.0 KB)
maslow.yaml (3.2 KB)
firmware.bin (1.6 MB)
2 Likes
Here is 0.66.9 which gives us three changes:
-
It adds a button to release the tension in the belts
-
It replaces the calibration grid offsets which were confusing and hard to talk about with a calibration grid size. A calibration grid of size 1000mmx1000mm and 10x10 points is easier to describe than an offset and the defaults will now be consistent across frames. This also lays the ground work for using a small calibration grid (say 200mmx200mm) first at the beginning of the process and then a larger grid later based on the results of that first preliminary calibration.
-
It fixes the prints for when an encoder is disconnected to match up with the correct arm.
index.html.gz (155.0 KB)
maslow.yaml (3.2 KB)
firmware.bin (1.6 MB)
1 Like
@bar, please pin this topic or do something else to make it easier to find all
the time.
David Lang
1 Like
I just loaded the 0.66.9 files and power cycled my maslow, it isn’t showing the
new options, and when I try going to anything in the pulldown menu on the top
right, I instead get the popup that I would have gotten if I clicked on the
screen without the menu being up (i.e. I try to click on settings, and I get the
Z display.
David Lang
1 Like
this could be a firefox vs chrome problem. I tried again later and with chrome
it worked (still didn’t see all the new stuff I expected)
David Lang
1 Like
I usually test in Firefox so all take another look today, but I was pretty sure it all looked normal yesterday evening.
Can you grab a screenshot next time?
@dlang I think that I uploaded the wrong index.html file. Thanks for catching that.
Here is 0.67.1 which brings us two exciting changes
-
It fixes a bug in the calibration process math which was preventing it from finding the correct values under some circumstances.
-
If the calibration values look good (>0.5) then they are written to the .yaml file automatically. No need to mess-around with downloading and editing that file.
There is a known issue where if you try to open the config settings panel after it has automatically updated your values you will get an error 406. Refreshing the page will make it go away, but I’m looking into how to fix it properly.
index.html.gz (154.7 KB)
maslow.yaml (3.2 KB)
firmware.bin (1.6 MB)
3 Likes
When I hit save after setting the new values nothing happens. if I manually restart fluid the new values were saved, but I think previously when I clicked save it popped up a window confirming the save / restarting fluid ?
Another odd behaviour is im getting the no heartbeat messages while the calibration is running, however I have a ping running every second and it hasnt dropped a beat.
1 Like
That is intensional, a restart isn’t actually necessary there for the changes to take effect so you can save some time by not restarting.
That is 100% a bug. I will look into that. Thanks for flagging it!
Should I give this one a go? Do you think that will resolve my issue? Sorry I haven’t had the time this week to mess with the calibration process.
1 Like
Yes, I believe (
) that it should fix your calibration issue.
I’ve tested it with data from your previous runs and it seems to fix the issue from what I can tell.
EDIT: @Ethan took this and ran with it and this is better suited to be a standalone tool, which he implemented. see Standalone Calibration Simulator
…
…
I have made a branch in a fork from Bar’s repo here: GitHub - ronlawrence3/ESP3D-WEBUI at feature/calibration-tab
As noted in the PR below, this is mostly all Bar’s code. I just threw it together into a new tab.
Summary
Here are the changes: Feature/calibration tab (DRAFT!) by ronlawrence3 · Pull Request #21 · BarbourSmith/ESP3D-WEBUI · GitHub
And here is a link to the index.html.gz – of note, you must delete your index.html.gz then upload this one or you will likely get an error that the maslow is full.
Release v0.0.1-calibration · ronlawrence3/ESP3D-WEBUI · GitHub
Screenshot:
2 Likes
Here is 0.68.1 which works to improve the math behind the calibration process.
It includes a re-write of the algorithm which does the computation (not 100% sure it’s actually different, but I think that the code is more clear) and a new system for making the initial guess used to begin the computation.
I believed that the initial guess was not important (in theory it shouldn’t be), but it appears to be important so now instead of using a random hard coded initial guess we are using the existing values for the anchor points as the initial guess for the system.
This means that running a small calibration grid in the center and then a larger calibration grid afterwards might yield better results (than it did in the past) since the larger calibration grid will be computed based on the results of the previous smaller one.
Only updating the index.html.gz file is needed for this update.
index.html.gz (155.8 KB)
Is this potential incremental improvement only possible when running a larger grid, or could successive calibrations on the same grid yield further improvement?
1 Like
It might be slightly possible to get an improvement running the same size grid, but I’m not really sure. The issue that I’m hoping to fix is when folks are getting good fitness (>0.5) on a small grid, but then really low fitness (~0.05) on a larger grid.
1 Like
C Peter Lotz wrote:
Is this potential incremental improvement only possible when running a larger grid, or could successive calibrations on the same grid yield further improvement?
it may, testing needed. 
One thing to remember, Bar and Roman are only two people, and they have machines
that have been working under the original software (or they wouldn’t have
released it). It’s hard for them to duplicate many of the problems that others
have been having, so they make changes that they think are improvements, but
need the rest of us to try them and report of how much they help (or that they
don’t help)
David Lang
2 Likes