After loading V1.13 setup menu looked like this
After retract, Extend it looked normal but I couldn’t move around. I could however load and run a job. Still unable to Jog afterwards
1 Like
Went back to V1.12 - All OK, Reloaded V1.13, now working. Probably had some left over stuff from testing
1 Like
After power down and restore, got message saying belt lengths unknown. When I tried to jog. Then Released Tension and Apply Tension was able to jog and run a job
1 Like
Hmmm that sounds like something to keep an eye on.
I’ve seen that behavior-ish when the browser side doesn’t know the machine current state. Basically the browser thinks that the machine isn’t ready when it actually is. Refreshing the page usually fixes it if that’s the case
The status displayed was ready to cut, computer had been off, so it was a fresh load of the browser. Interesting that the release tension, apply tension restored functionality, wouldn’t expect that if it was a browser problem.
1 Like
Yeah that is unexpected
Having a problem resuming after power restart (12 hrs later). Comes up with status Extended instead of Ready to Cut and panics and does not read the maslow.yaml file.
1 Like
Hi. I’ve noticed the same thing. If the Maslow is powered off while in the Ready to Cut state and then restarted, it usually boots into the Unknown state. A couple of times, though, it did remember its previous state.
1 Like
This part is right. For safety it boots back into the Extended state and you will need to press “Apply Tension” to get things ready to cut again. It’s a safety check in case something goes wrong…for example:
Fortunately the “Apply Tension” will do a measurement and check against the stored values for the frame so if it were to ignore the maslow.yaml file it wouldn’t let you move the machine (because that could damage something)
In this case I think that maybe this is just an old .yaml file and the names of those settings have changed so I think that it ignoring them is the right behavior
There is a slightly weird thing happening here. Rebooting the Maslow sometimes causes this error, often several times in a row. Nothing will work, can’t release tension, can’t do anything. Then leaving it for 5 minutes and power rebooting, it will come up as normal, for several times in a row then it will go back to not reading the maslow.yaml file again. It is like there are 2 versions of the system files and it alternates between them randomly. I have reloaded the firmware, maslow.yaml and index.html.gz files several times without altering this behaviour. I tried copying and loading a renamed maslow.yaml to config.yaml in the hope it would pick up that file if it couldn’t read the maslow.yaml file. That did not work. Sometimes it boots up, sometimes it doesn’t. I then tried changing the Config/Filename to config.yaml (Flash Settings) When it works it uses the renamed yaml file.
When I was working with David testing, we loaded a number of non-performing test files, and I suspect some of these may have caused this strange behaviour.
I am considering doing a full reload via the USB port.
Reloaded the software, still exhibiting same problem, not consistently.
Also: After a successful cut, on return to ready to cut, it doesn’t appear to store the current position. If I release tension then restore tension it records the current position.
1 Like
@bar found a bug last night (may not be ‘the’ bug, but is ‘a’ bug that may be
related)
David Lang
1 Like
I did find and fix an issue which I think is this one. It was a two part issue.
1st: The way that the commit ID was being stored in memory could cause memory overflow issues. Those are pretty intermittent because basically it was overwriting some random bit of memory next to wherever it landed which seemed to often, but not always mess up reading the anchor point locations section of the maslow.yaml file.
2nd: The structure of the maslow.yaml file changed, but the default values that are used when the file fails to load hadn’t been updated meaning that when it fails to load it would boot into a weird state where it had an out of date structure for the .yaml file.
Both should be fixed now on Maslow-Main
Can you put changes up on Interstitial Firmware Releases please
1 Like
Added!
I may be having a similar issue. When the Maslow 4.1 comes up after reboot I sometimes get the Extended state instead of Ready to Cut and “error 3”. After rebooting several times with same result I walk away for 30 minutes. Then I finally get to the point where I can execute the “Belt Dance” (reboot, release tension, retract belts, extend belts, apply tension). I also come across a message that the ymal file is corrupt.. I have created a yaml.bk file that I swap when the corrupt yaml file message comes up. It seems to fix the issue temporarily.
Paul Bateman wrote:
I may be having a similar issue. When the Maslow 4.1 comes up after reboot I
sometimes get the Extended state instead of Ready to Cut and “error 3”.
After rebooting several times with same result I walk away for 30 minutes.
Then I finally get to the point where I can execute the “Belt Dance” (reboot,
release tension, retract belts, extend belts, apply tension). I also come
across a message that the ymal file is corrupt.. I have created a yaml.bk file
that I swap when the corrupt yaml file message comes up. It seems to fix the
issue temporarily.
do you have a copy of your old maslow.yaml file? there is a bug with 1.13 where
if it has problems reading the maslow.yaml file it will create a default one
that is incorrect (and will generate “error 3”)
If you have your old maslow.yaml file, you can copy the anchor coordinates from
that and put them into the new file.
David Lang