Linear scales, DRO about nanoels

[digiexchris]

The only thing closed loop steppers don't solve is error in the machine's ways or ballscrew. Big CNC machines have maps that have correction factors at a lot of different places along it's travel.

Closed loop via linear scale means the gap in deviations from perfect between the stepper and the movement (the rest of the machine) are accounted for, since the closed loop stepper can only determine if it rotated enough, not if the load moved far enough.

That said, I don't feel that's necessary for the H4 in my machine, I tend to use the ELS as a semi-automatic aid to manual machining, where I'm used to accounting for those problems manually anyway. I'd probably go to linuxcnc if I was doing more complete automatic stuff (like full CNC). However, handling this in software might be a low cost way for people to do ultra precision stuff on very worn lathes :)

[kachurovskiy]

Hi @vegetate7, it's possible to connect optical rotary encoders on A1/A2 that will jog the axes when turned, but - even though linear scales operate on exactly the same principle - H4 doesn't have a function to use that signal for position correction. It should be possible to add that function but I think very few customers were asking for it and honestly I'm a little puzzled as to how exactly to implement that and avoid the hysteresis especially since everyone has backlash on their axes.

[vegetate7]

Yep, backlash is the pure evilness. Tho the external DRO can be used for automatic backlash calculation :)
Anyway I'm not talking about continuous position correction. Just only after disabling/enabling axes, or disconnecting/connecting halfnuts. In that points ELS already have no information on where the axes is. But I'm do not know too what to do with backlash.
May be make some selectables strategies. like:
0 - Do not use DRO for correction.
1 - Compensate backlash by doing small steps and checking position untill position start changing. And, may be steps to opposite direction for (backlash+1step), to compensate that position change.
...
XX - Trust DRO since having very precise ballfeeds

[kachurovskiy]

Thank you for bringing this up. Let's keep this issue open and collect feedback and proposals from the community, perhaps we could produce a widely supported proposal here over time. What I'd be looking for is something that is widely applicable and simple to understand and use.

[vegetate7]

Ahh. I see now. perhaps it should be a discussion, but not an issue.

[kachurovskiy]

Ahh. I see now. perhaps it should be a discussion, but not an issue.

No worries, we can keep it as a feature request issue.

[vegetate7]

I was wandering over HobbyMachinist's els code. He is using DRO for kind of a closed-loop operations. If enabled - calculate positions, test limits, etc with DRO data, not the steppers steps. And got some ideas.

• Enable steppers at the start of the operation, disable at the end or pause. This will allow more convinient way to move axes. You can do it by keys, or rotary encoder, or with manual flywheel. IMHO jogging by the rotary encoder is the pain :)
• Constantly count linear encoders position.
• Sync position to linear encoders at the start of operation. Set limits based on linear encoders.
• Backlash compensation at the start of operations based on linear encoder data.

[kachurovskiy]

Yes, this is a good approach. I do feel like investing into closed-loop steppers and ballscrews (on same or another machine) is overall a more interesting solution to the problem though.

Enable steppers at the start of the operation, disable at the end or pause

FYI this is possible today with NEEDS_REST_Z and NEEDS_REST_X.

[vegetate7]

Yes, this is a good approach. I do feel like investing into closed-loop steppers and ballscrews (on same or another machine) is overall a more interesting solution to the problem though

Agree. Let closed loop drivers do closed loop does.

FYI this is possible today with NEEDS_REST_Z and NEEDS_REST_X
Nice! A half of job is done already! (Tho it's commented as something for "closed loop", I do not think it will be a problem for using closed loop dirvers/steppers).

WRT the rest, I looked to code. It shouldn't be too hard to do. Some flags to not to converse encoder's pulse to movement (getAndResetPulses(&x)). Or even not to store pulses in pulse1Delta / pulse2Delta, but keep counts as actual axis position. And later use this position when setting limits and origin.

[vegetate7]

Was thinking a lot :) May be direct counting of a linear encoders pulses not a bes idea.
High resolution encoders wil produce high frequency interrupts, this can affect stepper pulses stability. Or loss of encoder pulse - miscalculating positions. And so on..
So I star thinking about some kind of a dedicated counter+rs485 interface. Found some on ALI, but price is high and speed is low. I think cheap ESP32 board can handle it.
ELS can poll it in display update, axis origin set, stop limits set. Not constantly, only in some special cases.
This still need some type of backlash compensation anyway.

[digiexchris]

I think I may have stumbled onto the reason some users complain of lost steps, and it's tied to the enabling and disabling of interrupts mid loop while doing math on the encoder pulses and writing the result to memory. I can detail the issue and a proposed solution if we're amenable to it. Could be a lot of work though. Using an index pulse as an error correction would be easier (but, there is a way to be nearly perfectly accurate without it, and also improve ISR speed and therefore max rpm, and thread safety). Another easy option is a voting system between 3 encoders (such as a manually made optical slotted disk and 3 pairs of optical sensors) nasa style! If one misses one due to a missed interrupt, the other two should hopefully catch it, as long as interrupts get turned back on far enough and there's enough phase error built into the system to allow them to be out of sync (perfectly in-sync encoders would still have the missed step issue).

…

On Tue, Dec 5, 2023 at 3:52 PM vegetate7 ***@***.***> wrote: Was thinking a lot :) May be direct counting of a linear encoders pulses not a bes idea. High resolution encoders wil produce high frequency interrupts, this can affect stepper pulses stability. Or loss of encoder pulse - miscalculating positions. And so on.. So I star thinking about some kind of a dedicated counter+rs485 interface. Found some on ALI, but price is high and speed is low. I think cheap ESP32 board can handle it. ELS can poll it in display update, axis origin set, stop limits set. Not constantly, only in some special cases. This still need some type of backlash compensation anyway. — Reply to this email directly, view it on GitHub <#143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMZQGV3BI5EY72TSLLS773YH6JQFAVCNFSM6AAAAAA75SIBVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGY3TIOBSGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[vegetate7]

Meanwhile I've got a DRO with rs485 modbus interface.
Not a light fast, taking around 20ms to read one axis position. But I think I can live with it, because not need to poll it every steper pulse. It will be polled asynchrnously and synched to axis position only in certain cases.
I'm going to use A2 port to connect to MAX485 board.

upd.
Some unclearness in the code for me.

1. What is the purpose of saving / loading axis positions? We can not rely on them after poweron. While in powerdown axis can be moved, and the spindle moved with very high probablity? BTW, with DRO and Z-index on the spindle encoder we (may be) can resume , let's say, threading.
2. Still can not understand backlash compensation logic. It it taken out only for reverse (negative) moving of axis?

[vegetate7]

I made a PR. Just to look. It is not tested at all.
How it (should) works:
When stepper is disabled, enabled DRO position polling, which sync actual tool position into a->pos.
No backlash compensation after stepper enabled ATM. Even no good idea how to.