I agree that we should pick a single model and stick with it for ease of use, and I am absolutely OK with a larger memory version of the ESP, although being able to program it with the Arduino IDE is a must to make it easy for us all to collaborate.
2 Likes
Iâve been playing around with my 8873 and I can easily read the current from the motor (although only one direction seems to be working now for some reason). I think we should scrap the SPI interface to those chips entirely and use the non-spi version. @blurflâs brilliant solution with the LED driver gives us the SPI control we want and the SPI interface to the chip seems pretty useless and somewhat of a liability because the SPI version of the chip requires some modes to be set in registers instead of with a pin pulled high or low.
1 Like
Moving left should be as easy as calling a function. If it isnât then the code is layed out wrong. All the same calculations need to be done to execute G code.
13 GPIOs is a lot. How 'bout we just do it with 1 GPIO? That 1 GPIO can be on a header for an optional plug in board containing shift registers, buttons, switches, rotary encoder, LEDS. If we include the communications channel it can have a display too.
As a non-engineer who spent his career hanging out in the room with engineers (I guess Iâm like a drummer in a band? :)) can I just raise one more time the goals/requirements questions I put forward for consideration a little while ago?
I get that itâs a chicken and egg problem, and itâs a lot of fun to pick specs and hardware. Settling some of these things will settle other technical and non-technical issues - BUT - it still feels to me like there arenât necessarily clean and measurable goals and direction overall.
A few questions come to mind:
Is the new controller specifically for the Maslow V2 (e.g. the four motor maslow)? Is there any expectation of it being backwards compatible or a need for it to be?
What are the three most important elements of the user experience with the V2?
What are the hard and soft constraints regarding price, technical knowledge (kit versus assembled/partially assembled), complexity, accuracy, repeatability? Are there strengths and weaknesses of the existing design that are hoped to be engineered in or out?
How will the Maslow V2 be enhanced and supported in the future, both hardware and software?
Is it time for a more formal leadership or decision making process around final hardware and software decisions and revision management/commits? There seems to be lots of talent and enthusiasm but it is a bit unclear sometimes âhow to get things doneâ or who is the authority on a given topic and who can make the final call to keep things moving.
Not trying to dictate any particular direction on any of these items, just trying to help bring some broader clarity to the discussion. There are lots of non or semi technical folks who can help in other areas to move a V2 project forward if we know where it is headed and who is leading the charge on things.
-Jeff
1 Like
I think that would be desirable and I donât see why it couldnât be done.
I was hoping to find a prebuilt developer board with the larger flash (Iâm not going to try to build a board at this time using a module that needs soldering). I havenât found one yet.
1 Like
Yes. So?
You raise valid points, they deserve considered answers.
I only speak for myself as an individual that wants to build the best tool for my needs.
I realize the best chance for getting the features I want is to contribute.
One of the reasons I like participating in this process is the distinct lack of âmanagement typesâ. If they appear, I disappear.
I am not an employee and will not voluntarily subject myself to bureaucracy. That said, I do appreciate a competent project manager, whom I do not consider âmanagement typesâ provided they do not waste my time. In that case, I consider them incompetent. If I am looking for an official decision on something, I would probably look to bar. Seems to have an even hand. But ultimately I work on what I think is important with materials I can afford.
Your other questions involved the direction of development but also aimed to set constraints. It is counter productive to set arbitrary constraints on a creative process too early. We are still trying to identify practical constraints and coalesce a shared vision of what Maslow V2 should be. Part of that is sifting out what it can be, what it shouldnât be, what it cannot be now but might be in the future.
The beauty of this user built model is that we do not need to design to a single
The user is free to choose a configuration that suits his needs. I think we can do a better job of defining representative packages for price, convenience, precision.
Maslow V1 with Ground Control could remain the price option, loosely defined.
WebControl, ESP32 controller, kit frame, everything in a box with printed instructions for the home gamer convenience package.
Optimized CAD package post processor, Single Board Computer or phone app for advanced user interface, ESP32 controller, and long list of options for the pro precision package.
Option 4, Choose your own adventure. Perhaps a portable option.
Marketing dictating development is another one of those deal breakers. We havenât even conceived of all the things it can do, let alone judge which of those will be most important to the user. Such predictions are almost always wrong anyway.
Market research! You go out and discover what people want. Report back, and if the engineers agree they build it, or they build what the people should have asked for instead. You determine where the project is headed.
The reason market research does not directly dictate engineering is because users only answer in terms of what they are familiar with, not what is possible.
Example: In the early days of televisions with rotary dial channel selectors, market research would say the people want a long stick for changing channels. Instead, engineers invented remote control.
1 Like
Moving left should be as easy as calling a function. If it isnât then the
code is layed out wrong. All the same calculations need to be done to execute
G code.
the code is layed out wrong 
(thatâs why I want us to move to a variation of
grbl)
but this doesnât have to be done on the motor controller board, it could be done
on the central computer.
grbl for example, implements jog controls via the serial port, not via gpio pins
13 GPIOs is a lot. How 'bout we just do it with 1 GPIO? That 1 GPIO can be
on a header for an optional plug in board containing shift registers, buttons,
switches, rotary encoder, LEDS. If we include the communications channel it
can have a display too.
at some point you are working waaay too hard to avoid using the computer at the
other end of the serial/usb cable just to claim that you are stand-alone (and to
become âstand-aloneâ you are introducing an additional processor)
David Lang
your various criteria seem good, but I donât want us to lock ourselves down so
that we canât use a better module when it comes out. there are going to be
versions in the future that have more ram and flash.
I think we should avoid external ram/flash (other than possibly access to a SD
card), or at least external to the module we use.
I would agree dueal core
set a minimum ram/flash, but allow it to grow
what is the current âbestâ gpio count? and how many variations are there that
are below that? (and how far below? if they are only down a handful of pins, we
may try to use the smaller number, but exceed that if needed)
we should pick something supported in both the Arduino IDE and platform IO
donât lock yourself down to Amazon, and itâs really hard to know whatâs
avaialble for fast shipping around the world (and that will change next month
anyway)
David Lang
a module that is castelated is easy enough to attach (solder, or there are
adapters), âdeveloper boardsâ tend to be expensive and have lots of extras that
eat up pins even if you donât use that feature.
David Lang
Is the new controller specifically for the Maslow V2 (e.g. the four motor maslow)? Is there any expectation of it being backwards compatible or a need for it to be?
it should not require 4 motors, but if we go the pi approach, it probably would
need different encoders, so not fully backwards compatible
What are the three most important elements of the user experience with the V2?
No chance of plugging into the wrong board (this will eliminate more failures
than everything else combined 
)
integrated webcontrol (eliminating separate firmware/GC versions, single
upgrade)
current monitoring or current limiting h-bridge chips (eliminating chip burnups)
2A current capacity h-bridge chips
What are the hard and soft constraints regarding price, technical knowledge
(kit versus assembled/partially assembled), complexity, accuracy,
repeatability? Are there strengths and weaknesses of the existing design that
are hoped to be engineered in or out?
the controller would normally be shipped fully assembled and ready to plugin,
but some people will want to roll their own (especially when doing variations on
the motor controller chips)
ideally one board, but as long as itâs a fairly fool-resistant plugin, possibly
multiple boards plugged together (for example, it may be 2 motor with an
additional 2 motor add-on, or may be a motor controller plugged into a pi)
currently we have ~8k steps/rev (~0.01mm/step), we would like to go to larger
sprockets, but I donât think we want to go worse than about 0.1mm/step. So if
we do encoders on the outputs rather than on the motors, we want to look at 14
bit (which woule give us about the same distance per step with a 25 tooth
sprocket)
How will the Maslow V2 be enhanced and supported in the future, both hardware and software?
depends who makes it, but probably the same way v1 has gone, people make and
ship things.
Is it time for a more formal leadership or decision making process around
final hardware and software decisions and revision management/commits?
No, there is nobody being paid to do any of this, so any decision makeing would
amount to people who arenât doing it telling others what they canât do
people who do trump people who want.
we can suggest and advise, but whoever actually builds something gets to make
whatever decisions they want, and the market will judge their results.
We can provide advise, but everyone needs to realize thatâs all it is.
There seems to be lots of talent and enthusiasm but it is a bit unclear
sometimes âhow to get things doneâ or who is the authority on a given topic
and who can make the final call to keep things moving.
if nobody builds something, or writes the code, it doesnât matter how many
people think it should be done a given way.
Not trying to dictate any particular direction on any of these items, just
trying to help bring some broader clarity to the discussion. There are lots
of non or semi technical folks who can help in other areas to move a V2
project forward if we know where it is headed and who is leading the charge on
things.
Iâm not trying to stomp on anyone either, but the truth is that there is no one
direction to go, there are currently a few differnet groups providing kits, if
none of them use the new controller it wonât go anywhere. If one of them starts
shipping a new controller that is nothing like what we discuss, that controller
is now âofficialâ and will be out there and new software should support it if
possible.
David Lang
1 Like
@JWoody18
âMaslow CNCâ isnât a business, its an opensource, community project. There are businesses selling kits and parts but, at the moment, development is community driven and I donât see that changing any time soon (why would a business add overhead for R&D and engineering when it is given to them for free?). âOpen sourceâ and âcommunity projectâ were new concepts to me when I first jumped in here almost a year ago. Coming from an engineering background, I had some of the same thoughts and questions you have. The two statements above I noticed but Iâm just now starting understand them. Iâm hoping to try to balance my time here by doing a little more contributing, instead of just reading and cutting.
Your questions and ideas are valuable and people can contribute in many ways, as you suggested. I hope to see some of your ideas come to fruition.
2 Likes
This is great news! Thanks for clarifying.
So? Thatâs a fairly abrupt approach. I didnât notice anyone else jumping on you when you weighed in quite strongly on some of your passion points in earlier posts, but I respect your right to your own style and Iâll try and help clarify where Iâm coming from. Itâs a big tent, this Internet.
So - itâs difficult for everyone who has valuable contributions they can make to do so if there isnât at least some articulated sense of direction and goals. And itâs difficult to maintain motivated community engagement without it. It is also difficult for existing, new and potential users of the product to discover and engage if these things are not articulated.
More practically, in the near term, itâs difficult to make good hardware selection decisions if you donât at least have a general sense of the requirements youâre trying to meet. Itâs the classic âtime (resources), quality or cost - pick any twoâ issue with hardware selection. The real fun and challenge in engineering is landing on that magical balance of features, availability, price, extensibility and eco-system. But some of those will necessarily take precedence over others. I wasnât suggesting a direction on any of them, only asking for clarification to understand where the priorities lie.
Ok, we can still be friends. 
You remind me of a former business colleauge. He always said no before he said yes, tuning your approach for the optimal delay just took some calibration.
Iâm not sure that having high level overall goals and rough constraints laid out constitutes âmanagementâ. Iâd suggest thatâs more leadership - leadership which comes from the community as well as Bar. If you donât know where youâre going, youâll get there.
If we were trying to build a house and there was no agreement on the general budget range, number of floors, number of rooms, type of rooms, style, materials, finishes or relevant building codes to consider⌠well Iâm not sure how successful we would be. Again, I wasnât suggesting answers to any of the questions, only trying to help get some of the bigger questions on the radar so lower level decisions have context and can the community can help vet them against goals.
The great news is, we can do anything. The bad news is, we can do anything.
I always find this refrain to be strange.
I thought engineers valued organization, structure, optimization and imagination? Most of the ones Iâve met, including immediate family, do. My technical brain asks why I would want to voluntarily commit time and energy to something without understanding the context so I can determine whether the effort will ever be of value or suitable to the project.
Just to clarify, no one was suggesting itâs not ultimately Barâs baby. But, for example, the discussion about trying to get Holey Calibration merged turned in to a âgosh, Iâm not sure who is in control or in charge of making that happenâ discussion that burned quite a few cycles. Formally delegating some of those things and publishing it would take some load of Bar and could help grease the sprockets as it were.
I to like to âwork on what I think is importantâ too, but isnât there an element of context to that as well? Bar feels passionately about keeping the price point low - so that constraint will ultimately inform hardware selection decisions, for example. However a need for more flash could mean a lower tier of boards is eliminated and the price may need to change, or the lack of flash may mean the features need to be limited to hit the price target. Having a few higher level goals and constraints roughed in guide that.
I did not set any constraints. I asked what constraints we were working under for clarity and focus. Itâs healthy to have context to help better inform discussions, decisions and contributions.
I once arrived at a hotel in a smaller city in France on a business trip. A european colleague proceeded to try and check us in as he spoke french. Drama ensued. I managed to hear enough words to know that apparently our reservation and confirmation details were irrelevant to the desk clerk. As far as he was concerned we didnât have a reservation. Tensions escalated for a few minutes as my colleague insisted they honor the reservation. The desk clerk pushed back and it was looking like we might need to find a new hotel.
I stepped in and asked, in english, if they had any rooms tonight. âOh, Oui, Monsieur, we have lots of rooms.â âGreat,â I said, âweâll take four.â. Context helps avoid getting distracted by details so you can get the most out of your effort.
I didnât set any constraints. I asked what constraints were in place. There are constraints and requirements. Or at least there are a half a dozen people I can think of who believe there are constraints and requirements although Iâm not sure theyâve all compared and agreed on them, even though lots of effort has been expended.
Constraints breed creativity, they donât stifle it. Necessity is the mother of invention.
Donât kid yourself, there is nothing particularly creative about looking at various low cost boards and tossing them on a list. There are at least a dozen affordable, powerful and accessible boards that could get the job done. Figuring out how to get more out of the lowest cost board than others have, while meeting aggressive price, feature, reliability and accessibility requirements - thatâs great creative engineering.
If you donât have a sense of ultimate goals or constraints youâre trying to bake a cake without knowing if itâs a fruit cake, a birthday cake or an ice cream cake - let alone flavours and toppings.
Said another way - goals and constraints ARE engineering.
I am passionate about the Maslow but if Iâm being honest, the inability to even have a meaningful discussion about the consistency of accuracy, let alone precision, is a challenge for a CNC project. We all kind of side step the current state of that today. If you look at broader reviews on youtube and the web, people love the concept and can find uses for Maslow for some cases but the accuracy and precision issues really limit itâs appeal. I canât be sure if I build one for a neighbor if his experience will be even close to mine. Thatâs not ideal for a CNC and seems to me like an ideal formal target for improvement. The hanging design is very innovative and deserves to evolve, itâs game changing.
Now look whoâs defining things that arenât settled! 
If someone is put off by having goals and constraints for technical projects Iâm not sure engineering is the right field. Ready, fire, aim doesnât work.
What Bar shared with me at one point was a vision that CNC be made accessible enough that it could become part of a home builders/contractors toolkit and exist affordably on virtually any construction site and help improve the speed and quality of work. Thatâs a great goal and has a lot of devils in the details to make it happen. It also overlaps nicely with enthusiastic maker/hobbyist use (many of whom are woodworkers not technical folks). I think the guys at www.yetitool.com have done a lot to move in the direction of Barâs original vision. But at USD$6K it fails on price. I think an evolved Maslow could get 85% of the benefit for substantially less, as an example. But not without clearly defined goals and constraints as well as a bit of structure so work doesnât end up queue blocked because no one knows how to get the fruits of their labour integrated.
Wow I wish I had been born an engineer so I had all the answers⌠If only I had experience with developing highly technical products from scratch through to successful global deployment in 24/7/365 operations - at substantial profit.
Engineers arenât the only ones with answers and beneficial contributions to make. It takes a team to make project. It would be help to maybe turn down the biases a little bit.
I believe you meant to quote Henry Ford saying âIf I only listened to customers, I would have made a faster horse.â Of course engineers also invented Betamax. And the Titantic. And the Hindenberg. Boom! See, it works both ways.
-Jeff
2 Likes
David, you are my hero.
It sounds like the move to four motors will help improve consistency and precision, which would be awesome. I have a feeling the backwards compatibility discussion is a whole other topic for debate. My feeling, even as a V1 kit owner, is that itâs a âcouldâ not a âmustâ or even a âshouldâ, simply because it imports all the technical and support debt without a lot of upside. An upgrade kit, though, for us V1 users is very appealing - but perhaps not cost effectively feasible given the encoder direction?
Beautiful. Yeah thatâs definitely one to engineer out. Is tape/a sticker or an insert cap (like those little plastic HDMI covers that come on cables) not a low tech solution for the current boards?
I am going to chip in and try and get a streamlined VM going later this month to try and contribute there. Less setting up software and more CAD/CAM & Cutting I say!
Or maybe more broadly, safety and resilience enhancements including those and an e-stop? See my fire scare thread in No Judgement for an eye opener.
Oye. All I was saying is it would be helpful to know who the build master/merge master is, for example - to white the confusion about how to get holey calibration formalized despite it being 90% ready to go or more.
What if the people who do are the people who want to get the release out but simply donât know how to get it over the finish line?
I wasnât wandering in to the business side of things with my questions - of course people can embrace and extend opensource, I just meant decisions about V2 hardware direction for the reference build. The more we can focus initial enthusiastic development on a specific hardware platform that was hashed out and agreed by the group, the faster we can move it forward. But someone also needs to determine when itâs settled and move on to the next part of the build. If itâs open forever weâll never get it finished.
Man I wish I could find the professor in engineering school that teaches the class you all took on pushback. It needs some updates. Again, I was referring to formalizing the process and leadership around merges and builds in particular, and being a bit more structured around milestones and goals overall. Maybe even having something like Trac or itâs modern equivalent, as used by the very successful Mythtv.org project: MythTV
There is always an opportunity to choose a direction and go boldly forth. If we donât have a direction then what are we doing? If the controller goes hand in hand with the two current suppliers future plans, maybe they can put a few bounties up for various features and bug fixes as well as throw some support behind a more formalized roadmap to help bring clarity in that regard? Just brainstormingâŚ
-Jeff
Apparently you had some issues merging code I wasnât aware of. That has nothing to do with me.
Members ¡ People ¡ MaslowCNC ¡ GitHub Thereâs your guy. If it doesnât get merged and you think its good code, create your own fork.
You took issue with 2 words I said. âYes. So?â meaning, âI agree with you. What is your point?â
Frankly I still donât understand your points.
For me, none of the things you listed are fun.
Yeah, that sounds fun. Lets do that. It is the way I like to work, and actually also the way I like to cook.
It seems you have something against engineers. Iâm sorry for whatever caused that. But just for the sake of clarity, I am not an engineer. I am just some guy on the internet with zero authority over anything except where I spend my time. That was my point.
Also, Betamax Titantic and Hindenberg all great products destroyed by users. We just have different perspectives.
More practically, in the near term, itâs difficult to make good hardware
selection decisions if you donât at least have a general sense of the
requirements youâre trying to meet. Itâs the classic âtime (resources),
quality or cost - pick any twoâ issue with hardware selection. The real fun
and challenge in engineering is landing on that magical balance of features,
availability, price, extensibility and eco-system. But some of those will
necessarily take precedence over others. I wasnât suggesting a direction on
any of them, only asking for clarification to understand where the priorities
lie.
opensource projects donât have the same tradeoff, time is either not there or is
essentially free.
the other thing is that you just cannot direct anyone else how to spend their
time.
Just to clarify, no one was suggesting itâs not ultimately Barâs baby.
actually, it is not Barâs baby any longer, he is no longer creating kits. He is
a tinkerer like the rest of us. His ideas may or may not work and may or may not
ever ship.
But, for example, the discussion about trying to get Holey Calibration merged
turned in to a âgosh, Iâm not sure who is in control or in charge of making
that happenâ discussion that burned quite a few cycles. Formally delegating
some of those things and publishing it would take some load of Bar and could
help grease the sprockets as it were.
this is part of the growing process, we havenât finished that discussion. It
doesnât work if only one person can make a release.
I to like to âwork on what I think is importantâ too, but isnât there an
element of context to that as well? Bar feels passionately about keeping the
price point low - so that constraint will ultimately inform hardware selection
decisions, for example.
no, you also have the metalmaslow team that is taking the approach that a more
expensive kit that takes less work to setup is better.
However a need for more flash could mean a lower tier
of boards is eliminated and the price may need to change, or the lack of flash
may mean the features need to be limited to hit the price target. Having a
few higher level goals and constraints roughed in guide that.
opensource doesnât work with grand plans, it works with incrimental changes
get something working, however poorly, and iterate improvements.
So we do not need to decide on the requirements now, because we donât have
anything working yet.
get it working and see what the requirements are, if people have to buy another
$7 module because what they started with wasnât good enough, too bad
I did not set any constraints. I asked what constraints we were working under for clarity and focus.
it implies that we need to set constraints, and thatâs not something that you do
much in opensource development.
Itâs healthy to have context to help better inform discussions, decisions and
contributions.
not always.
I didnât set any constraints. I asked what constraints were in place. There are constraints and requirements.
right now, there are no constraints, and other than âit needs to cut and be
better than what we have nowâ there are no requirements (other than fixing the
power plug problem )
I am passionate about the Maslow but if Iâm being honest, the inability to
even have a meaningful discussion about the consistency of accuracy, let alone
precision, is a challenge for a CNC project. We all kind of side step the
current state of that today. If you look at broader reviews on youtube and
the web, people love the concept and can find uses for Maslow for some cases
but the accuracy and precision issues really limit itâs appeal. I canât be
sure if I build one for a neighbor if his experience will be even close to
mine. Thatâs not ideal for a CNC and seems to me like an ideal formal target
for improvement. The hanging design is very innovative and deserves to
evolve, itâs game changing.
that is a problem, but nothing in the selection of the processor will matter.
This needs experimentation more than anything else.
We have multiple approaches to improve accuracy, but I donât think anything in
the new controller (including the 4 motor design) is going to make a huge
difference in the accuracy.
software changes will help, but that is independent of the new controller
If someone is put off by having goals and constraints for technical projects Iâm not sure engineering is the right field. Ready, fire, aim doesnât work.
central planning and opensource projects donât tend to go together well either.
opensource projects are almost never waterfall, they are the agile end of
things (at least the more successful ones)
If you ask any Linux developer what will be the new feature in two releases,
they will tell you that they have absolutly no idea, because there is no central
planning dictating what gets done. you instead have a lot of developers doing
things they are interested in, and when someone has something they think is
ready, they put it out for others to consider. If enough of the right people
agree, it gets added and becomes a feature for that release.
But not without clearly defined goals and constraints as well as a bit of
structure so work doesnât end up queue blocked because no one knows how to get
the fruits of their labour integrated.
we have failed to follow our policy this year.
The policy is that every two months there is supposed to be a release, no matter
how many or how few changes are pending.
Bar got busy and stopped the release and we have not defined how a release
happens so that someone else can do it.
the criteria for acceptance is if the community accepts the change or not
(managed by a github robot counting votes). This does mean that a bunch of
people could storm in and break everything (which would mean that we would have
to move to a different repo with different policies), but it also means that
anything can be accepted if more people think itâs an improvement than a
detriment.
In the case of holey calibration, the programmer creating the work also got busy
and didnât push the changes. So what happened is what is supposed to happen in
opensource communities, someone else speaks up (in this case me) to prod things
to move again.
Iâve got the TCL5947 doing SPI at 40MHz on VSPI of an ESP32-DEVKITC, works well.
Can you share links to the AsyncTCP and ESPAsyncWebServer libraries youâre using? The versions Iâve found donât seem to be the right onesâŚ
2 Likes
It sounds like the move to four motors will help improve consistency and precision, which would be awesome.
that is something we will have to see. It will roughly double the cost of the
kit, and it remains a serious question as to how much it will help. If it works
it will help speed more mostly (and some consistancy in the bottom corners), I
think it is more likely to hurt precision than help it (the added chains
introduce additional possible errors in ways that simple gravity doesnât)
but the accuracy problems will not be helped by the extra chains, that is a
software/model/calibration problem. our current model of the machine does not
match reality well enough, and our measurement/calibration isnât good enough
(there are other topics where we are discussing this)
I have a feeling the backwards compatibility discussion is a whole other topic
for debate. My feeling, even as a V1 kit owner, is that itâs a âcouldâ not a
âmustâ or even a âshouldâ, simply because it imports all the technical and
support debt without a lot of upside. An upgrade kit, though, for us V1 users
is very appealing - but perhaps not cost effectively feasible given the
encoder direction?
an upgrade kit may be possibe, that would be new electronics connecting to the
old motors/encoders, but making this possible is backwards compatibility. having
to replace everything but possibly the chains would be ignoring backwards
compatibility
Beautiful. Yeah thatâs definitely one to engineer out. Is tape/a sticker or
an insert cap (like those little plastic HDMI covers that come on cables) not
a low tech solution for the current boards?
in theory yes, in practice no, the cap comes loose. (weâve tried)
I am going to chip in and try and get a streamlined VM going later this month
to try and contribute there. Less setting up software and more CAD/CAM &
Cutting I say!
existing software setup isnât that significant, the problem is calibration
Or maybe more broadly, safety and resilience enhancements including those and an e-stop?
a big power button is as effective an e-stop as this machine can really use
(remember the current hardware wonât stop the motor from running when you hit
the e-stop, and bar has legitimate concerns about shipping a kit that can turn
on the router under software control). stopping the movement while the bit keeps
spinning is more likely to cause a fire.
Oye. All I was saying is it would be helpful to know who the build
master/merge master is, for example - to white the confusion about how to get
holey calibration formalized despite it being 90% ready to go or more.
we need to get back to following our stated processes (outlined in a prior
e-mail) and reduce the âbus factorâ for releases so that we have multiple people
who know how to do it
What if the people who do are the people who want to get the release out but
simply donât know how to get it over the finish line?
the statement still stands, there can be a thousand people who want to get a
release out, but if none of them knows (or can take the time to learn) how to
make a release, itâs not going to happen.
you may have thought that you were only talking about the last speed bump of
getting holey merged, but you made a standard mistake that people without much
opensource development make by thinking that making decisions/policies is the
way forward. That is frequently the right solution when you have some paid
people who you can then direct to do things, when the only payments is
satisfaction and the only punishment is guilt, less management like talk and
more learning and involvement is usually better.
you managed to make some statements that come off especially bad to people with
more opensource experience, which is why you got some overreaction to your
intent.
But someone also needs to determine when itâs settled and move on to the next
part of the build.
itâs settled when someone ships it.
If itâs open forever weâll never get it finished.
it is open forever. anyone can override any amount of discussion by shipping
something different.
Man I wish I could find the professor in engineering school that teaches the
class you all took on pushback. It needs some updates.
Again, I was referring to formalizing the process and leadership around merges
and builds in particular,
unfortunantly you were unfamiliar with the processes we defined around this (and
to be fair, not all the details were formally defined)
and being a bit more structured around milestones and goals overall.
and that is exactly what people are reacting negatively to.
Maybe even having something like Trac or itâs modern equivalent, as used by
the very successful Mythtv.org project: MythTVThere is always an opportunity to choose a direction and go boldly forth. If
we donât have a direction then what are we doing? If the controller goes hand
in hand with the two current suppliers future plans, maybe they can put a few
bounties up for various features and bug fixes as well as throw some support
behind a more formalized roadmap to help bring clarity in that regard? Just
brainstormingâŚ
In general, I find the most successful opensource projects have the fewest
formal milestones and instead have a continual flow of iterative improvements.
formal milestones can work if you have a company involved with money to pay
developers (and no, the companies selling the kits donât have that sort of
money, they are doing good to break even overall on the kit sales)
I hope Iâm not repeating myself too much here. Iâm not trying to browbeat you,
just explain why you are getting a reaction different from what you expect.
David Lang
1 Like
I found this writeup that bdring did about the port of grbl to esp32.
http://www.buildlog.net/blog/2018/07/grbl-cnc-firmware-on-esp32/
Some interesting comments in there regarding the challenges of getting grbl to work on the esp32âs rtos.
2 Likes