Can you save the Serial.log, maybe something can tell us what’s happening
Can you open this as another docket under Troubleshooting please. This post is not really for fixing problems but more as a development tool.
1 Like
@bar I was finding the network failing to maintain a connection while I was running a reasonably complicated nc file, so I tried loading older versions of the firmware etc.to try and see if it was something we had changed. It just got worse. Eventually the Maslow locked up and I had to do a full install to recover. I have just run a file which was failing within a minute or so before and it completed without a hitch on the V1.17. This was the first time in over a dozen attempts that I had managed to run the same file without it disconnecting the browser.
And, if you are ever redesigning the controller board can you please make the reset button more accessible
1 Like
So it seems like at least the connection is more stable on the latest version not less?
It does seem like connection stability needs to be a priority to look into and add some better monitoring to.
Not the point I was making @bar. It appears that the more times you update, the reliability, as far as the browser connection goes, degrades. I am intending to run this nc file a few more times to see if it fails, before I do any more development or updates. I went back as far as v1.16 and it was still failing every time. It only improved when I did a full USB install.
Incidentally, when the browser connection failed, the job completed. But I could not regain control of it. Stop and pause buttons were ignored until job completed, and if I had pressed stop it then required a Retract etc to recover.
1 Like
Oh interesting! I can’t think of any mechanic which would be causing that behavior, but complex systems can behave in some really unexpected ways so it’s a good observation
Ran same nc file 3 times, no browser dropouts. I had been doing a lot of testing with my machine of various changes, requiring firmware and index.html.gz uploads, so is probably an extreme example.
1 Like
Maybe an extreme example, but I think that generally a review of all of the connection code with a focus on making it more robust is probably next on the todo list.
I’m still working on fixing the bug where the calibration process wouldn’t converge for that set of data you sent a while back, but I’ve gotten a bit off track into cleaning up and fixing some other things about how the system works along the way 
1 Like
Bar wrote:
Maybe an extreme example, but I think that generally a review of all of the
connection code with a focus on making it more robust is probably next on the
todo list.
is the connection handled on core 0 or core 1?
David Lang
1 Like
I have no idea. I believe that all of the wifi is handled on core 1, but I’d have to look into it more to say for sure.
Bar wrote:
I have no idea. I believe that all of the wifi is handled on core 1, but I’d
have to look into it more to say for sure.
I think we probably need to separate communications from movement processing,
both have fairly strict timing limits.
David Lang
1 Like
I believe that we have one core which is dedicated entirely to wifi communications for exactly that reason, but I’d have to do more research to be sure
Here is a new version that I would love feedback on. These changes started out as a response to a set of data which @ian_ab posted where the machine was not finding good anchor point locations unless it had a close initial guess.
That issue might be partly fixed, but this mostly because a refactor to clean up how the math works and to split the math library out from the main code so that we can use identical math functions on the machine and in simulation so that the calibration process can be tested (at least the math part of it) without needing the machine hardware.
In theory this should all work just the same as before, but like with any big refactor it’s possible that I broke something along the way so I would love feedback if anyone has a chance to test it!
firmware.bin (1.9 MB)
index.html.gz (132.7 KB)
Loaded and ran a couple of test cuts, no problems so far everything looks the same. Haven’t tried a Find Anchors though.
1 Like
Will do.
1 Like
I think that this is a genius idea, but I think we should move the button up below “Setup” having it share the same space as the FluidNC status indicator seems confusing to me. Like sometimes that button says “Retract” and clicking it will cause the belts to retract (which makes sense), but then sometimes it say “Home” but clicking it then won’t set the home position.
Can we store the Fitness value somewhere like maslow.yaml so we can determine with a test (default 0) whether there is a need to do a Find Anchors, especially for initial users who don’t realise that Apply Tension is not required (or appropriate) until we have a valid Anchors set. Also, I think it’s confusing we still refer to this process as Configuration.
1 Like
I think that is a good idea generally. My only hesitation is that having a good fitness value stored doesn’t tell us that we have a good calibration because the anchor points may have moved which seems like it could lead to confusion for some folks.
What if we do make it so that “Apply Tension” is the first step to locating the anchor points and “Anchor Points” becomes available only after that?..no that is a bad idea because people might want to run “Locate Anchor Points” again even after it succeeds to get more precision.
I 100% agree that you’ve identified an issue, but I wonder if there is a better way to solve it than to store the fitness value. That fitness value just tells us information about the past, not really anything about the machine’s current state.
I agree, where are we doing that?
we aren’t going to be able to solve every problem, but we can make the
maslow.yaml defaults be something that we can know is invalid so that we can
always know when we have a default yaml file and know we need to find the
anchors.
I had been thinking of setting the default anchors to some known value (right
now I think they are the values of one of Bar’s old frames), even setting them
all to 0 would work and be an obviously invalid frame size.
storing the fitness value would be useful in evaluating problem reports, we
would be able to see after the fact what fitness find anchors ended up with.
would it make sense if when anchors all = 0 we only allow retract, extend,
release tension, and find anchors? (and Z movement)
If someone is wanting to run find anchors again after they have non-zero anchor
locations, I think it’s reasonable to ask if they are sure (as it will wipe
their existing anchor locations), but allow it.
David Lang