Linear scales, DRO
Opened this issue · 13 comments
Hello! Is it possible to make it use linear scales on A1/A2 gates? I.e. for resyncing positions after jogging axes manually (by flywheel).
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.
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
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.
Ahh. I see now. perhaps it should be a discussion, but not an issue.
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.
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.
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.
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_ZandNEEDS_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.
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 :)
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.
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.
- 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.
- Still can not understand backlash compensation logic. It it taken out only for reverse (negative) moving of axis?
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.