search

BarbourSmith / FluidNC

The next generation of motion control firmware
Other
34 stars 8 forks source link

add per-arm extensions and expose arm length #141

Closed davidelang closed 3 months ago

davidelang commented 3 months ago

Expose _armLength (Maslow_arm_length) and _beltEndExtension (Maslow_belt_anchor_length) in the yaml file to support non-standard sizes.

add Maslow_(tl/tr/bl/br)Ext keys to the yaml file as (tl/tr/bl/br)Ext variables to allow for custom length extensions to exist on the ends of belts (either to allow frames larger than the belt will reach, or to allow a clamp to be put on the belt so that retraction stops early, allowing us to avoid having to fully detach the belts for a retract cycle)

I don't have a setup to be able to compile and test these changes, but they seem very straightforward. I think that these all get set to proper defaults if there is nothing in the yaml file, but it is possible that these will require a synced yaml change.

BarbourSmith commented 3 months ago

I'd like to generally work to simplify things rather than making them more complex. Even if each change is good on it's own, the resulting product can end up being too complex to use which I think is one of the core downfalls of open source projects...they tend to keep adding features until they become unusable because it's hard to argue against each individual feature since they each bring something good.

I'd be open to adding this if it exists as a branch for a while and we find that there are folks using it and taking advantage of that feature, but at the moment I don't think that this is really anyone who is using this in practice.

davidelang commented 3 months ago

I know there isn't anyone using it in practice as it doesn't exist.

but we've talked about how painful it can be to do the full rehang dance on a portrait frame, and this would let you add a stop to the belt that would eliminate the need to fully detach the belt.

we also talked about adding extensions to the belt to reach anchors in a building that the belts are not long enough to reach. This would let us do that as well.

exposing the internal variables is just something to make it possible to use non-standard arms, which isn't significant now, but we are talking about future options which pretty much all end up with the ends of the arms being at a different radius than the current version.

At this point, I'm not looking to add these to the normal UI, just to have them as variables in the yaml file so that they can be used for the oddball cases without needing to recompile.

David Lang

On Mon, 17 Jun 2024, BarbourSmith wrote:

Date: Mon, 17 Jun 2024 13:51:52 -0700 From: BarbourSmith @.> Reply-To: BarbourSmith/FluidNC @.> To: BarbourSmith/FluidNC @.> Cc: David Lang @.>, Author @.***> Subject: Re: [BarbourSmith/FluidNC] add per-arm extensions and expose arm length (PR #141)

I'd like to generally work to simplify things rather than making them more complex. Even if each change is good on it's own, the resulting product can end up being too complex to use which I think is one of the core downfalls of open source projects...they tend to keep adding features until they become unusable because it's hard to argue against each individual feature since they each bring something good.

I'd be open to adding this if it exists as a branch for a while and we find that there are folks using it and taking advantage of that feature, but at the moment I don't think that this is really anyone who is using this in practice.

BarbourSmith commented 3 months ago

I understand, but let's get a couple folks using it on a fork and reporting that they like it before making it a part of the main code. Nobody has even tested this yet