LowRider v4 Community Hog-Out Test

LowRider CNC Troubleshooting
1

I’ve been kicking around an idea for a while, and I’d like to see if the community is interested.

One of the questions that comes up over and over is:

  • Are metal strut plates actually better than MDF?

  • Does adding more printed braces make a measurable difference?

  • How much does gantry length really affect performance?

  • Is a heavier spindle worth the tradeoff?

  • Does PET-CF, ASA, PLA, or another printed material matter and on which parts?

Everyone has opinions, but we don’t have much actual data.

The goal of this project is to change that.

Rather than asking “How fast can your machine cut?”, I want to build a community dataset that shows which design choices actually increase machine stiffness and usable cutting performance.

The idea is simple:

Everyone runs the same Hog-Out test generated with Vector76’s excellent test pattern generator, using the same basic cutting parameters, bit type, and material. We then record both the machine configuration and the results.

Each machine starts with an easy feedrate and increases in fixed increments until the machine reaches its practical limit. Think of it like a volumetric flow test for a 3D printer—the goal isn’t to win, it’s to identify the point where performance starts to fall off.

For each submission we’d record things like:

  • Gantry length

  • Tube material

  • Strut plate material

  • Number of printed braces

  • Printed part material

  • Router/spindle model

  • Bit stickout

  • Feedrate ladder results

  • Highest clean feedrate before failure

  • Failure mode (deflection, chatter, skipped steps, etc.)

Over time, we should be able to answer questions like:

  • Does ⅛" steel outperform ¼" MDF, and by how much?

  • Is the difference larger on longer gantries?

  • How much do additional braces actually help?

  • Is there a point of diminishing returns?

  • Which modifications provide the biggest improvement per dollar?

I’m not trying to create a scientific laboratory test. I’m trying to create a repeatable community benchmark that anyone with a LowRider v4 can run in an afternoon.

I’ve put together a draft testing protocol and data sheet, but before I ask people to start cutting I’d really like feedback from the community.

What would you change?

Are there variables I haven’t considered?

Is there a better way to measure performance while still keeping the test simple enough that lots of people will actually participate?

If we can get enough submissions, I think we’ll end up with something that’s genuinely useful—not just for people modifying existing machines, but for anyone building a new LowRider and trying to decide where to spend their time and money.

I can’t load the document directly here so I made a drive folder and made it shareable.

2

Before anyone starts filling out spreadsheets, I’d like to get a couple people’s blessing.

First, I’d really like Ryan’s thoughts on the idea. This project exists because of the LowRider, and if this turns into a useful dataset I’d rather it belong to V1 Engineering than to me. My hope is that it becomes something the community can continue to build on, and if the information ends up being useful for future LowRider development—whether that’s incremental improvements to the LR4 or ideas for an eventual LR5—even better.

One of the strengths of the V1 community is simply its size. Even with a dedicated beta team, there’s no practical way to test the huge variety of machine sizes, materials, modifications, routers, spindles, and build styles that are already out in the wild. The community has collectively built hundreds, if not thousands, of machines. If we can gather data from even a small percentage of them using the same benchmark, we’ll end up with a dataset that’s impossible for any small beta group to produce.

I’d also like Jamie’s permission to use his Hog-Out test generator as the foundation for this benchmark. It already provides a consistent, repeatable way to progressively increase cutting load, and it seems like a perfect fit for collecting comparable data across many different machines. There’s no point reinventing something that’s already well thought out.

If both of you are on board, I’ll clean up the protocol based on everyone’s feedback, organize the data collection, and let the community do what it does best—build a dataset that answers questions with measurements instead of opinions.

3

*mods

I didn’t know where to put this, so please feel free to move it wherever best suits.

4

One thing I wanted to explain is why the protocol standardizes so many variables.

The goal of this project isn’t to find the fastest possible cutting recipe. It’s to compare LowRider machines. Every variable we can standardize is one less thing that can influence the results.

If one person cuts plywood, another cuts MDF, one uses a compression bit, another uses a 3-flute end mill, everyone chooses different depths of cut, and everyone generates their own toolpath, then we’re no longer comparing machines—we’re comparing machining strategies.

Instead, I’ve tried to standardize as many variables as are practical:

- Same test pattern

- Same cutting material

- Same style of end mill

- Same depth of cut

- Same feedrate increments

- Same test location on the machine

That leaves the machine itself as the primary variable.

The things we’re actually interested in become the differences between the machines:

- Gantry length

- Tube material

- Strut plate material

- Printed part material

- Number of braces

- Router/spindle choice

- Bit stickout

- Other machine configuration differences

Obviously, no community benchmark can eliminate every variable. Two sheets of MDF won’t be perfectly identical, and no two routers or end mills are exactly alike. But by removing as many variables as reasonably possible, patterns should begin to emerge as more machines are added to the dataset.

This is also why the protocol isn’t necessarily optimized for maximum material removal. Every machine probably has a different “best” recipe. That’s not what we’re trying to measure.

The philosophy is simple:

If two machines differ by only one design choice, I’d like that design choice to show up in the data.

If we can keep everything else reasonably constant, then differences in the results are much more likely to reflect differences in the machine itself—not differences in the cutting recipe.

5

Yes, a year or two back a user made extensive studies and posted them. No need to discuss this one. :grinning_face_with_smiling_eyes:

6

My gut feeling is that with so many variables, you would need a ton of data to converge on a useful conclusion. Testing one variable at a time is the gold standard.

2 Likes
7

That is actually something I missed on my edit. Lol. Ai helped me write it and I didn’t get the right filaments changed out

Scientifically, I completely agree. If you want to isolate a single variable, changing one thing at a time is the gold standard.

The challenge is that no one person has the time, budget, or shop space to build and test every meaningful combination. There are simply too many variables: gantry lengths, tube materials, strut plates, brace counts, printed materials, routers, spindles, and countless other small modifications.

That’s where a community dataset can become valuable.

Think about how the automotive industry works. Engineers spend years testing prototypes under controlled conditions before a vehicle is released. Once it’s in customers’ hands, though, manufacturers continue collecting data from warranty claims, service records, and real-world use. That data isn’t more controlled than engineering tests—it simply represents a much larger and more diverse sample of real-world conditions.

I see this project in a similar light.

Ryan and the beta team did the engineering that produced an excellent machine. What I’m proposing isn’t intended to replace that process. It’s an opportunity to learn from the number of LowRiders that have been built since.
The strength of the community is the sheer number of different configurations that already exist.
With enough submissions, we can begin filtering the data instead of trying to test every combination ourselves.
For example:
Show only 30" gantries. Does strut plate material make a measurable difference?
Now expand that same comparison across all gantry lengths.
Do additional braces help equally on every machine, or only on longer gantries?
Does one modification become more valuable as the machine gets larger?

I don’t know what the answers are, and that’s exactly why I think it’s worth collecting the data.

The goal isn’t to prove one design is “best.” The goal is to identify trends that only become visible when you have enough real-world machines contributing data.