Ater Release tension the only one left is Retract All (which is fine if Release Tension also stayed) Maybe Release Tension should be left on the original menu for now.
1 Like
Is it possible for release tension be only applied to the 2 lower belts for known amount instead of (as I understand it) for a timed loop). This should allow a
retension to pull M4 back to a known position by tightening the 2 lower belts by the same amount as released (or am I missing something).
1 Like
Here is version 2
It goes back to keeping the buttons inside the popup so they can’t be accidentally clicked, but it still shows which ones are available in green and makes the current state clear.
index.html.gz (117.4 KB)
Release tension followed by Apply Tension should already work…The system should be able to do those just fine, I think that the issue is that after releasing the tension we are transitioning to the state “Unknown” which is like when the machine first powers up and I think that’s wrong. I think we should transition to “Extended” which is the state that we’re in when the belts are first fully extended. That would make sense, right?
1 Like
“Release Tension” is still available after “Release Tension” (which I like) but it is greyed out. Maybe it could go Orange to signify “use with caution” and machine state go to “Extended” Instead of “Unknown”. Then Machine state changes to “Unknown” after subsequent application of “Release Tension” if “Apply Tension” does not restore to a known position.
1 Like
I think that it should be safe to use release tension repeatedly.
I’m thinking that if at the end of release tension we can check to see how fart the belts are extended. If it’s more than some threshold (say 1 meter) then we can transition to extended out. If it’s less than that threshold we could go to state unknown.
OR
We could have release tension remember what state we were in before and go back to it.
Any thoughts?
Bar
I like this option better.
If you go to Unknown State you cannot Apply Tension
1 Like
I’m going to release 1.05 tomorrow and then I will make this change and make a release here so that we can test it
2 Likes
I’ve (and by “I” I mean the AI that now writes all of the worlds code) done a pretty major re-write of how the kinematics system works.
The machine used to operate internally in XY and Z axes internally and then at the last step we would convert those X, Y, and Z coordinates into the lengths of the belts to move.
This was a reasonably good first approximation for how the system works, but it had some limitations.
In particular our Maslow.yaml file had configurations for things like the maximum speed and acceleration in the X, Y, and Z axis, but in practice we are actually operating a five axis CNC.
The new system updates the internal mathematics to fully understand and incorporate that into acceleration planning.
Our Maslow.yaml file now has A, B, C, D, and Z axies each with their own tunable parameters. This should let us significantly increase the maximum feed rate without worrying about possibly exceeding the max feedrate of any one axis because now those will be taken into account while computing moves.
Overall this is a pretty significant move to make the firmware work in the “right way” as a five axis machine instead of pretending to be a 3axis machine that’s doing some extra math.
To the user this update should be largely opaque, but it does require updating the firmware, index.html, and Maslow.yaml files. In practice we’ve probably added some bugs so I’m posting this here first and I would love any feedback if anyone is up for trying it.
index.html.gz (118.6 KB)
maslow.yaml (4.2 KB)
firmware.bin (1.9 MB)
At least one bug that I know of is that we used to be able to raise and lower the z-axis with the belts retracted and that doesn’t work right anymore. I’m working on a fix for that one.
Overall it’s an exciting update on the math side of things!
4 Likes
Neat! Sounds like a lot of work went into these changes.
Will the same existing GCODE work? Does the new firmware internally translate GCODE with G0/G1 commands for X Y Z position/feedrate to the new A,B,C,D,Z axis?
Conversely, can tinkerers generate GCODE with G0/G1 commands for A,B,C,D,Z for whatever machines they’re building with the Maslow 4.0/4.1 controllers?
2 Likes
Great question! The machine still understands standard gcode, but internally it translates that into what movements need to be made just like before.
Ideally from the outside you won’t even be able to tell that anything is different, but under the hood the math is more correct and we have better controls to tune the machine.
1 Like
This is in the maslow yaml file after the message
Below here should not need to change, …
kinematics:
MaslowKinematics:
# Frame anchor points - all values in millimeters
# By convention bottom left is (0,0) and bottom right is (width,0)
# Bottom, top, left, right are defined with power cord down, looking from top
Also the version numbers haven’t changed for firmware and index.html
Haven’t tried testing yet
1 Like
Starts fan but no movement of z-axis. After trying to move z, clicked on Apply Tension and M4 started pumping out belts on tr & tl. Had to power off.
After manually editing yaml file got errors could not read TRx values etc, and error on line 81 (which is a comment) lots of error 3s
Reloaded new yaml file. Changed config to vertical and extend to 1760, tried to run Calibrate got error straight away and all motors stopped.
Trying again after editing yaml file via fluidnc menu with values from backup yaml file.
1 Like
All appeared to be ok, M4 accepted new values. Applied tension and moved to bottom left. Tried loading a simple circle and doing a run without router or vacuum. Failed immediately. Log attached
Maslow-serial (43).log (6.4 KB)
Have to leave it now, try again later.
1 Like
Excellent feedback! I’m about to be off in the woods for the weekend but I will dig into it next week and see if I can figure out what is going on there
1 Like
Enjoy your weekend.
Ran Config with the original values in yaml. All appeared OK. Failed as soon as I tried to run a file. Noticed as M4 started to move BR BL both a little loose. Log files attached.
Maslow-serial (46).log (8.4 KB)
Maslow-serial (45).log (22.0 KB)
Going back to 1.07 to prove M4
1 Like
I bet that there is something going on with the position being loaded when the machine applies tension.
It would be interesting to see if the same issue happens when using the jog arrow buttons.
I was able to jog all over with no problems, it was only when I started a dummy test cut that it fails right away
1 Like
We ran into that exact same issue in the past, I don’t remember what the solution was but I remember the issue 
The issue turned out to be pretty simple. We now have tunable parameters for each belt, but they weren’t very tuned.
There is still more tuning to do, but this config file should fix running cuts.
maslow.yaml (6.5 KB)
Reloaded back to the IFR version with new YAML file. I have set home position at bottom left. I could step around without problems. When I clicked on Home icon, with the M4 approx. centred the machine went to the home position but BR belt was extending too much belt. had to pull on it to prevent it starting to wind backwards. When it got to the home position it then took up the slack on BR belt.
I then centred the M4 again and pressed home again, same thing happened, far too much belt on BR.
I suspect this is a tuning issue, what area should I look at?
I have also noticed after moving that the M4 releases a few mm of belt and tightens again before moving with a jog
1 Like