Thoughts on designing a new controller

even if the bolt pattern isn’t the same, as long as the motor can be mounted it
could be used. It also removes some of the concerns about backlash if we measure
on the output shaft rather than the input shaft of the gearbox

David Lang

as long as you are polling at least a couple of times per revolution, you know
what direction you are turning, so if the count crosses the boundry, you know
what direction it crossed and can account for it.

David Lang

1 Like

it does not handle DC motors and encoders, only steppers, so it would need as
much surgery as linuxCNC or grbl for us to use it’s software. I think we are
better off aiming at linuxCNC and grbl than this system.

but it’s worth looking at their parts list, what H-bridge chips do they use? how
expensive are they?

David Lang

Docs for the Buildbotics controller are in Github here: https://github.com/buildbotics/

@Metalmaslow excellent idea. Do you plan on further breaking out your offering? For example, sled, metal linkage, z-axis all as separate items?

1 Like

We may want to split this thread in two - one for “Strategy and Roadmap” and the other for executing on the next controller iteration.

Most any entity engaged in large-scale consumer product development such as automotive, electronics, pharma, cpg all have a product range with (using Honda here) HondaJet, F-1 Racing, to the Civic, Fit, and your lawnmower. New ideas start out on a small scale where “win at any cost” is the attitude, and innovations here make their way downmarket overtime. Concept cars have a role here as well, but more for the aesthetic / experience vs engineering.

While I was initially attracted to the Maslow project by sheet size x cost, I am now excited by the community support and the pace of innovation. I will avoid adding up what I have spent on my Maslow at this point. And I have yet to make a cut towards something other than a better Maslow. But I’m hooked, and will be spending more. BUT - the price got me to start.

All of this is background to reiterate the idea behind my Accuracy Rankings post, which is to create a vehicle to:

  1. Clearly communicate the state of quality of the machine
  2. Set clear expectations for what you get for a given level of investment
  3. Drive development progress forward

The “unlimited” class could spur new thinking from unexpected places (like @Mike_Thomas Death Star sled, the Metal Maslow, etc). The middle class ($1000? $2500) could show what you could do for the same as an entry-level x-y CNC. These classes may also be in a position where they have more money than time and could help to support a commercial ecosystem.

And of course the original $500 price point. I would hope that innovations that occur because of the no-limits thinking at the top level would filter down to the lower levels over time. Meticulous designs originally conceived at higher levels may be replicated (often with an investment of time) at lower price points by those with the time to noodle on them. And constraints at this level can drive innovations for all.

I propose a simple 3-tier system that helps us all to focus on what we are building towards. As a new design comes into focus, it can be “slotted” in to where it fits. For example, the Meticulous-Z would seem to be a reasonable upgrade for a budget minded Base Maslow. It is getting to where there that thread has a solid BoM and enough experience to say "You can spend another $50, 6 hours, and improve the Base Maslow accuracy by 20% on average - with reference measurement on file for review.

For the mid-priced user, or the user that may not have 6 non-cutting hours to spare, then $150 and 1 hour will get you 25% better accuracy. It helps understand the best choices available for your situation.

3 Likes

Exactly some of the things I’ve been thinking…

The DIY nature of the project means everyone has a different frame, which effects the accuracy. I think kit providers have done some work, and could do more, to prep or even assemble critical components to eliminate potential sources of error.

Exact conversations I’ve been having lately. If new users had more options and the info to make the decision on the options, it would move the user base forward at a different pace.

This is difficult, since we are all strapped for time. I, for one, intend on doing more technical learning and contribution in fw and gc development and bug squashing.

1 Like

Agreed. This is why I was thinking more of a “class”, with machine documentation guidelines (like a Airtable survey into a base) that would help document all the factors. Maybe I’ll play with this idea and bring it back here.

1 Like

I meant development of the project overall, not necessarily the software. My observation is that mechanical issues far outrank software driven ones, but I admittedly don’t grasp the details of current calibration efforts. I would think getting to a max-accurate (for a given class) machine would be a baseline.

Please check out:

The Maslow Machine Census (alpha)

Agree wholeheartedly. It is not at all clear to me what frame should be chosen (let alone at a given time commitment/complexity or price point) in order to yield the most accurate Maslow. If I had more time and was willing to spend more money can I be relatively assured of a better cut than with Bee’s cheap and cheerful (wonderfully documented) frame? I still don’t have a clear answer. :slight_smile:

I’m intrigued by the laser cut top beam emerging from the MetalMaslow iteration of the design. Lots of conversations suggest the direction of finely tuning the motor spacing and vertical position -should- lead to optimal results and greater consistency (makes logical sense) but I haven’t yet seen a more formalized and repeatable test that confirms this. If it’s true, it leads one to ask if there is a shipping/mail friendly way to perhaps make something like laser cut motormount templates that slide over imperial or metric sized square tube that can be bought at local home centers around the globe… Afterall, we don’t need the whole bar shipped, only templates that register to the ends and provide mounting holes (at least if I understand correctly…) to achieve this.

Building on what @cmullins70 said, even without stratifying in to various “small/medium/large” budget tiers, I’d be happy if there was a 3 or 5 item “if you do X you’ll get Y benefit” that properly documented the “upgrade” or change and talked about reasonable expected improvement in accuracy or repeatability (or even reliability if applicable). There is a great sense of urgency and engineering ingenuity in the air here, which is something I think we all enjoy partaking in, but it does sometimes feel like we skip a cog every now and then and the best we can do is point someone to a dense and rolling 400+ entry post that “kind of has the answer, you’ll get the idea…” but doesn’t quite answer the question completely.

I’m not sure what the answer is, but it does seem like marshalling all the resources and getting a vetted, updated and comprehensive set of baseline docs and specs and accuracy readings in place is necessary to determine if all the other work is materially moving things forward in ways that can be easily measured. How to do that, well I don’t have any big thoughts on that one yet. :slight_smile:

I will say that the one problem with opensource designs and “everyone can do it their own way, huzzah, it’s open source” is that you can end up losing the very constraints and challenges that make engineering both more enjoyable but also more useful. :wink: Constraints are actually fun and helpful and make it easier for newcomers to engage…

-Jeff

PS - Said a different way, I’m still hoping for a clear 1-2-3 for the what/why of the new controller design. Super stoked reading Bar’s musings in the thread @WoodCutter4 linked but even for a sub component it shouldn’t be too hard to clearly state the key objectives. Brainstorming is all well and good, especially for clean sheet ideas, but when you’re trying to improve an existing one it helps to know if we’re shooting for pure innovation or improving and rounding off sharp edges of the existing one…

3 Likes

I’m leaning towards the Texas Instruments DRV8873. When I first glanced at the datasheet I assumed that “SPI or Hardware Interface Options” meant that I could interface fully through SPI to command something like “set power 50%” and it would stay there until a new command was sent. On reading the data sheet more closely I believe that you are correct that it requires a regular PWM interface and then SPI can be used to set error flags and read the current draw. I still think it’s a nice chip, but you are right that more pins will be needed than just the SPI bus I was hoping for.

Has anyone seen a cheap motor driver chip which can be controlled over just SPI?

Afterall, we don’t need the whole bar shipped, only templates that
register to the ends and provide mounting holes (at least if I understand
correctly…) to achieve this.

see New motor mount suggestion

this mount registers to the end, designed to fit unistrut or wood

Building on what @cmullins70 said, even without stratifying in to various
“small/medium/large” budget tiers, I’d be happy if there was a 3 or 5 item “if
you do X you’ll get Y benefit” that properly documented the “upgrade” or
change and talked about reasonable expected improvement in accuracy or
repeatability (or even reliability if applicable). There is a great sense of
urgency and engineering ingenuity in the air here, which is something I think
we all enjoy partaking in, but it does sometimes feel like we skip a cog every
now and then and the best we can do is point someone to a dense and rolling
400+ entry post that “kind of has the answer, you’ll get the idea…” but
doesn’t quite answer the question completely.

part of the problem we have is that some people are getting good accuracy,
others, are not, and we don’t know why.

My current working theory is that there are three main reasons for this

  1. frame (mostly top beam) is too flexible

  2. the calibration routine is not working well enough and is resulting in
    calculated measurements that are obviously wrong (I am thinking that holey
    triangulation will help this a lot, but I’m struggling to run it)

  3. the tape measure being used is inaccurate enough to cause grief. We recently
    had an interesting discussion on class 1, class 2, and unclassified tape
    measures. see
    In search of accurate measurements

we also don’t have anyone who has gotten a good accurate machine go through and
test other configs to see what effect the other configs have.

PS - Said a different way, I’m still hoping for a clear 1-2-3 for the what/why
of the new controller design.

We currently have three controllers

arduino mega and stock maslow controller
arduino due and modified maslow controller
arduino mega and TLE controller

Pairing one of these with a Raspberry Pi and using WebControl seems like it is a
huge win (I’ll say that being able to use my phone to bump things to get a
sprocket to 12 o’clock is a HUGE win compared to having to get to the computer
to move things and the machine to see if it’s in the right position yet)

So one goal of the new controller is to see if we can combine this, make the
controller run WebControl (or equivalent)

Additional features that we want to see if we can support (not in any order)

  1. support a stepper for a Z axis
  2. support other encoder types (SPI and RS422/RS485 communications)
  3. support 4 motor designs
  4. support higher current for the motors
  5. support higher voltages for the motors
  6. eliminate the ability to plug the power supply into the wrong plug
  7. current limiting on the motors to avoid frying chips
  8. current measurements on the motor drive
  9. wifi connectivity
  10. faster processor to handle the calculations a little better
  11. double precision floating point math for more accurate calculations

David Lang

I haven’t yet seen one, but the beast might exist. I still go back to the idea that if you are going to build a custom motor controller, go ahead and add a simple, low cost microprocessor to the board whose function is to just perform motor controls and read the encoders and let it talk to the “master” device (RPi, whatever) through SPI, serial, etc. You could use a PIC controller (multiple PWM outputs and quadrature encoder interfaces) but I don’t know how easy they are to program or update in the event there’s a need to.

1 Like

Would it make sense for organized efforts to focus on Epics (themes) to move work forward in a particular area? For example, a theme might be ‘Eliminate Bad Experiences’. (A $500 CNC busts its target price if I have to reorder a controller or a motor - not that I’m speaking from personal experience or anything :slight_smile:). Your #6, 7 address this. I also see “Better Accuracy”, “Faster Cutting”, and “Broader Software Support”. I think.

Another Epic I would like to see is “reduce or eliminate recalibration”.

we need to fix the ‘manually set chain length’ in the stock GC. This is one
thing webcontrol does much better.

in webcontrol you have the motor controls to set the sprockets to 12 o’clock in
the manually set chain length screen. So the process is, go to that screen,
tweak the sprockets to 12 o’clock, set the marked links on the sprocket, hit the
button, return to cutting

in Ground Control you have to go to automatic calibration, tweak the sprockets,
quit, answer the scary warning telling you that things may not work if you quit,
go to an advanced tab to then find the ‘manually set chain lengths’ button and
then go back to cutting.

if you don’t mark your chains, or you change something else on the machine, you
are going to have to re-calibrate.

David Lang

better accuacy is a software/hardware issue, not a controller issue.

faster cutting requires different motors (plus acceleration planning in the
firmware)

what are you thinking of when you say “Broader Software Support”?

David Lang

So does this bring us back around to the importance of unsticking the holey-calibration branch and web control updates and getting those merges approved and new builds out so this can become mainline? I was very pleased to hear from @WoodCutter4 that there is some movement in that direction but it still sounds like it’s not quite clear yet how to get it all over the finish line. Are there any blocking items? Certainly having better usability around ensuring you stay calibrated will go a long way to accurate cutting. :slight_smile:

-Jeff

not enough people with time/expertise in firmware and GC programming