Since Bar is the one merging pull requests, maybe he could share a rough roadmap or priorities (probably best in a GitHub discussion) so we’re aligned on what’s most useful to work on. Might help avoid open-source chaos where stuff gets lost or done twice or never merged, and everyone works on different things without coordination. I know I need to be coordinated, otherwise I just go off on my own 
1 Like
Absolutely!
The UI and firmware are almost entirely separate and they are separate repos which is nice for maintenance. Both have README files which should be enough to get started building them, but let us know if you have questions.
Right now my top priority is bug fixes. There are still lots of little ones out there to be caught. Smaller pull requests are easier to review so more small pull requests are appreciated over large ones.
Testing is key. I find that when I’m working on code changes it takes about 10% of the time to write the code and 90% of the time to make sure it works right. We’ve accidentally merged a couple PRs that broke things recently so confirming that at least the basics of running calibration and cutting a file still work is awesome. Even code which doesn’t seem to touch those areas can have weird effects due to timing or other unexpected connections. Some sort of hardware in the loop testing would be amazing, but at the moment testing by hand is the way.
1 Like
If you are looking for an interesting bug to investigate that touches both the UI and firmware, the top of my list is to figure out why the pause button isn’t working right. It’s probably a two line fix, but since it touches a lot of places it’s hard to figure out what those two lines need to be.
1 Like
Challenge accepted!
Out of curiosity: why does the WebUI Maslow tab contain functionality which is already implemented in the main FluidNC tab (jogging, loading gcode etc.)?
1 Like
My Maslow had been working fine for 2 days (just calibration & moving, not cutting yet). As a longevity test, I had it running G-code to move continuously from X-600 to X600 for about 8 hours - without any issues. However, this evening, when trying to extend all belts, I noticed that all encoder directions were inverted. The motors start running when I push the belt inward.
I’ve ordered the new JST upgrade, so once that’s installed, I’ll continue testing and hopefully squash some bugs in the process. 
1 Like
History
1 Like
Are you referring to my question about WebUI?
Yep - the reason why there’s duplication is largely due to history
1 Like
The ultimate goal would be to get rid of the old tab and have just the Maslow tab, but at the moment there are some features which aren’t yet duplicated
Could it be that the software has reached a point where a rewrite would be more efficient than trying to keep patching up the current codebase? Not saying we should (definitely not something to take lightly).
IMHO the current software has reached the level of a pretty good prototype. Most, if not all, features are working, but the last mile is pretty hard because the code (on the Maslow custom implementation in FluidNC side, at least) is a typical example of something designed during the ride. This usually ends up being a ‘house of cards’ or ‘ball of band-aids’ design pattern. Which is absolutely fine in the prototype phase and a great way to get things running quickly. But it works against you when you want to go from prototype → professional level. For that, a fresh start with the latest stable FluidNC, adhering to their architecture (e.g., using the Kinematics class, maybe moving to WebUI 3 if it’s mature enough), might be a better approach. It would move some of the maintenance burden back to the FluidNC project (more users & devs → higher quality). Take a step back from Maslow.cpp and cut it up into much smaller, easier-to-maintain (and decoupled) classes. And implement a proper Maslow state machine (which interacts with the FluidNC state machine) to fix issues like disfunctional pause buttons, FluidNC crashes when starting G-Code when Maslow is not calibrated, etc. This opens the door to automatic testing. Since most functionality is already implemented and tested, it’s more a matter of reshuffling the pieces than reinventing the wheel. Once this new code is solid, fixing bugs and adding new features should become a lot easier. And hey, after a few years, we can do it all again Yay, code maintenance!
Just throwing this out there to see what everyone thinks.
2 Likes
it’s possible, but there is a lot less functionality in maslow.cpp than you
think, most of the hardware support is in separate files that integrate fairly
well into the fluidnc
Maslow.cpp really does two thins
- calibration (figure out where the anchors are)
- a loop to drive the motors to simulate steppers/cartesion drive with a cable
robot.
David Lang
Date: Tue, 07 Jan 2025 08:00:33 +0000
From: “justusrijke@gmail.com via Maslow CNC Forums”
notifications@maslowcnc.discoursemail.com
Reply-To: Maslow CNC Forums
incoming+3fee63de0746f0e20c4546dd21a1393d@maslowcnc.discoursemail.com
To: david@lang.hm
Subject: [Maslow CNC] [Troubleshooting] Help… Maslow disconnected. Broken
PCB?Could it be that the software has reached a point where a rewrite would be more efficient than trying to keep patching up the current codebase? Not saying we should (definitely not something to take lightly).
IMHO the current software has reached the level of a pretty good prototype. Most, if not all, features are working, but the last mile is pretty hard because the code (on the Maslow custom implementation in FluidNC side, at least) is a typical example of something designed during the ride. This usually ends up being a ‘house of cards’ or ‘ball of band-aids’ design pattern. Which is absolutely fine in the prototype phase and a great way to get things running quickly. But it works against you when you want to go from prototype → professional level. For that, a fresh start with the latest stable FluidNC, adhering to their architecture (e.g., using the Kinematics class, maybe moving to WebUI 3 if it’s mature enough), might be a better approach. It would move some of the maintenance burden back to the FluidNC project (more users & devs → higher quality). Take a step back from Maslow.cpp and cut it up into much smaller, easier-to-maintain (and decoupled) classes. And implement a proper
Maslow state machine (which interacts with the FluidNC state machine) to fix issues like disfunctional pause buttons, FluidNC crashes when starting G-Code when Maslow is not calibrated, etc. This opens the door to automatic testing. Since most functionality is already implemented and tested, it’s more a matter of reshuffling the pieces than reinventing the wheel. Once this new code is solid, fixing bugs and adding new features should become a lot easier. And hey, after a few years, we can do it all again
With Maslow.cpp, I was more or less referring to all the code in the Maslow folder - but I’m just dipping my toes in the water, and you’ve been swimming here a lot longer than I have, so I definitely take your word for it! If there’s not much there, that only makes it easier to make it testable.
FluidNC has had quite a few updates and bug fixes since the Maslow fork. It could be interesting to see what’s involved in pulling those in.
This topic is all over the place 
I’ll try to get it back on its original track once I’ve installed the JST encoder upgrade.
1 Like
justusrijke@gmail.com wrote:
With
Maslow.cpp, I was more or less referring to all the code in the Maslow
folder - but I’m just dipping my toes in the water, and you’ve been swimming
here a lot longer than I have, so I definitely take your word for it! If
there’s not much there, that only makes it easier to make it testable.
the other files in the maslow folder are fairly well integrated.
I did a big set of changes to clean things up, but didn’t have a way of testing
them and something went wrong in the 14 big changes, so I’ll probably have to
redo them from scratch 
FluidNC has had quite a few updates and bug fixes since the Maslow fork. It could be interesting to see what’s involved in pulling those in.
I agree, I poked at it, but was doing something wrong and was overwelmed with
merge conflicts when I tried to rebase to the new version.
David Lang
1 Like
I think that this is the first step and probably wouldn’t actually be that hard. Now that we have a sense of what all of the pieces that we want to have are we can organize them in a reasonable (not one huge blob) way.
I think that long term a full rethinking of the integration with FluidNC is a great idea, but it’s going to be tough until they officially start supporting the S3 processor which they haven’t yet. There are a lot of little random tweaks all over the place needed to get that to work stably which they aren’t interested in integrating yet.
The UI side is a little easier and I think that’s a place that we could update for sure.
As an end user, I think I always kind of imagined that maslow would work to have a new kinematic class, probably tensegrity, merged into mainline FluidNC. It’s challenging to maintain momentum in say, 3 or 5 or 10 years… Having a place in a larger context seems like it can create a greater sense of continuity in the long run, and that shorter term decisions could benefit from the cross pollination of multiple things…
That said, modernizing webui would be fantastic. But it ssems that it would be sad for the rest of FluidNC users to be unable to benefit from those changes.
It’s understandable if the upstream maintainers are uninterested or unresponsive that a hard fork would be a necessity.
I can understand the thought of a rewrite as well… Reading through things today, I’ve found myself fantasizing about what Maslow might look like as an embassy based project, perhaps using printhor as a starting point…
1 Like
Will Puckett wrote:
As an end user, I think I always kind of imagined that maslow would work to have a new kinematic class, probably tensegrity, merged into mainline FluidNC. It’s challenging to maintain momentum in say, 3 or 5 or 10 years… Having a place in a larger context seems like it can create a greater sense of continuity in the long run, and that shorter term decisions could benefit from the cross pollination of multiple things…
do you know if anyone is doing cable driven robots with FluidNC
There is also the issue with a motor/encoder pair instead of a stepper
David Lang
1 Like
This was sort of my experience. They’re great people, but they are spread pretty thin and when I asked about integrating chances back into FluicNC I wasn’t met with much excitement.
We’re using the S3 processor which is newer than what they support which required some changes, we have servos instead of steppers which they don’t support, and we have really weird calibration (which could be broken out into its own file better) which requires more hooks than they have. Overall I am 200% on board with tighter integration with FluidNC, but I also want to be respectful of not trying to force them to make too much change that they aren’t excited about.
I’ve made a couple pull requests to the main FluidNC, but I’ve never had one merged.
Definitely agree with you on this. The current Maslow fork started from a WIP ESP32S3 I/O extender branch, which was already pretty far from the main branch once Bar added the Maslow stuff on top. I put some time into trying to remove the clutter to align it with the main FluidNC branch again but felt that was going nowhere.
So, as a side project (just for fun and to keep my C++ skills up to date), I created a fork from the latest release of FluidNC. It’s really just a start, but it does contain one important feature: it supports ESP32S3, with very few lines of code changed compared to the main branch. Z-steppers are working. Next up is the I2C extender, encoders, and DC motor drives. Once all actors/sensors are in place, it’ll be pretty easy to move the current Maslow logic back in. If that works out, we’ll have Maslow software that includes all the fixes done by the FluidNC team. And, because it hasn’t diverged much from core FluidNC, it will be easier to contribute to FluidNC in return.
An important improvement I’d like to make in this fork is adding a state machine for the Maslow logic. This will make the code much easier to navigate and troubleshoot. Another thing to investigate is how Maslow should integrate while considering the FluidNC architecture: using the kinematics class, maybe creating a separate FreeRTOS task (with a fixed, low-jitter cycle time), etc.
WebUI2 (currently used for Maslow) is no longer maintained—possibly a dead end. There is a WebUI3 fork for FluidNC that is actively maintained. No idea how much work is needed to get the Maslow stuff in there.
1 Like
That sounds awesome! I think we should do some significant testing because I did run into some weird Wifi reliability bugs on the S3 but those were early on and I reported the fixes to FluidNC so they should be fixed now I bet.
I LOVE this idea. A lot of the Maslow code was written before we really knew what we were working towards. Like I was like “in theory calibration is possible, let’s see if we can find a way to do it”. Now it feels like we have clear definitions for what all the states should be and we can build a clear and logical system to organize them. I think that step one is going to be to split the calibration code (which is most of it) out from the Maslow code. That’s on my todo list.
2 Likes
justusrijke@gmail.com wrote:
So, as a side project (just for fun and to keep my C++ skills up to date), I
created a fork from
the latest release of FluidNC. It’s really just a start, but it does contain
one important feature: it supports ESP32S3, with very few lines of code
changed compared to the main branch. Z-steppers are working. Next up is the
I2C extender, encoders, and DC motor drives. Once all actors/sensors are in
place, it’ll be pretty easy to move the current Maslow logic back in. If that
works out, we’ll have Maslow software that includes all the fixes done by the
FluidNC team. And, because it hasn’t diverged much from core FluidNC, it will
be easier to contribute to FluidNC in return.
fantastic
Another thing to investigate is how Maslow should integrate
while considering the FluidNC architecture: using the kinematics class
I would suggest calling this a ‘cable robot’ kinematics rather than ‘maslow’
kinematics
maybe creating a separate FreeRTOS task (with a fixed, low-jitter cycle time),
etc.
This would be something to put in when you add the motor/encoder support
WebUI2 (currently used for Maslow) is no longer maintained—possibly a dead
end. There is a WebUI3
fork for
FluidNC that is actively maintained. No idea how much work is needed to get
the Maslow stuff in there.
good to know.
David Lang