core
core copied to clipboard
grblHAL
Close Loop GRBL or Stepper Drive Alarm support
To work precisely, closed loops systems are the solution. But GRBL don't have support for it yet.
Two solutions are possible. `1: add encoder to each stepper motor, and feed the encoder signals to GRBL. GRBL will receive feedback from encodera and works in closed loop. It won't acknowledge OK status unless commended movement is achieved. Incase motor were unable to move, an alarm for that specific axis may be generated with feed hold
2: second option would be to used closed loop drives and steppes directly. The stepper drive generates an alarm Incase of unsuccessful moment. The alarm pin can be monitored for each axis and corresponding axis alarm may be generated along with feed hold
3: this is the simplest option, where feed hold switch and alarm signals are passed from OR gate and the output is given to feed hold pin. But here no status for that specific axis will be generated`.
To make GRBL fully closed loop, 1st option may be adopted. If that's not possible for the time being, then semi close loop can be achieved via option 2 and 3.
But GRBL don't have support for it yet.
Closed loop control is something that has to be added at the driver level. I have some code for a Maslow type machine that I experimented with earlier...
Stepper driver events (motor fault and motor warning signals) are already defined by the core, driver support has to be added where relevant. The handling (by the core) of those signals might have to be better defined though.
TMC5160 as and example of a driver that is not so expensive and available for less than 15$ has an encoder support! search for TMC5160-bob on Aliexpress and you will find it!
It would be very nice to support such a feature on this driver since it is affordable on the hobbyist level !
It would be very nice to support such a feature on this driver since it is affordable on the hobbyist level !
You can add the code?
You can add the code?
I am not really sure If I can do it or not, I am a Web developer by the day, my skills in embedded development is not really as good as web development and windows development in general. I will give it a try at some point since I have already started a design for a driver that support 48V and encoder input with RS485 comm. hopefully when I finish it I will be able to test it!
Closed loop control is something that has to be added at the driver level.
I disagree. It should be added in grblHAL itself. But not for a reason for closed-loop stepper(for those you have to use closed-loop steppers+drivers anyway), but for a closed-loop position accuracy. May be with PID control, similar to lathe threading. Linear encoders like SINO KA500 relatively affordable and have 1um(1 micrometer!) resolution. By using those backlash can be eliminated, any inconsistency in leadscrews can be eliminated.
The latest release now has an option to enable motor fault input provided that the board map has a definition for it.
Closed loop control is something that has to be added at the driver level.
I disagree. It should be added in grblHAL itself.
The encoder inputs has to be handled at the driver level, the control loop could be implemented in a generic plugin or in the core. IMO it would be best to start with a plugin.
would you like to assist me in implementing such a plugin?
Linear encoders like SINO KA500 relatively affordable and have 1um(1 micrometer!) resolution.
Standing in front of my recently acquired, age old 2thousand pounds mill, my Idea was to drive the existing lead screws there with VFD controlled AC motors.
At least for X-Axis, this motor and gear is already there. Z -Axis is lifting a some hundred pounds table. Y-Axis is hidden deep in heavy cast iron and has close to a mm backlash. All that does not feel like simply clamping a tooth belt pulley on the lead screw handles and drive them by a stepper...
I encountered the SINO encoders last night and was glad to find this thread right now.
May be I'm on the wrong train, yet? Both the starter of this thread and other search hits https://github.com/grblHAL/core/discussions/110 https://github.com/grblHAL/core/discussions/85 want to use position feedback to enter skd of error state.
In contrast, I'd like to feed back into the correction of motion that is kept ongoing. If e.g Z axis is lagging back because of the heavy weight but still moving, I'd like to speed other axes proprtionally down to stay on the planned trajectory. Stopping motion - even if for pause only and allowing resumption - I'd consider as contraproductive.
I see there is a PID in the spindle https://github.com/grblHAL/core/wiki/Additional-or-extended-settings#pid-closed-loop-control-settings and as far I can remember a similiar construction in lathe threading: Axes kept in sync with external motion
Might we build upon that?
Maslow kinematics combined with a supporting driver is the closest attempt from my side. It uses PID control for XY and positioning. Here is the driver I tinkered with some years back:
The driver is way out of date and for TI Tiva C (TM4C123). IIRC I had it somehow working for a single motor in a test configuration (not an actual machine).
thanks, but ... hm .... looks like a challenge at a first glance, I don't get a handle on this code. Well, that's what a challenge is for ;-)
Is there any documentation on the code structure of the core and it's interface to the plugins?
As far as I understand, I'd expect some main loop running where at short intervals skd of "planner" is
- recalculating the future trajectory,
- keeping track of current position,
- calculationg the action required within whatever given constraints
- translating this action to output signals
Or is there only the diligent way to plough through all the source on my own? :-\
I'm just collecting informations and ideas in the web. Would it be better to continue in some discussion thread?
Is there any documentation on the code structure of the core and it's interface to the plugins?
Only this, a book should be written?
As far as I understand, I'd expect some main loop running where at short intervals skd of "planner" is
Yes, this which calls protocol_execute_realtime() at a high frequency. Outputting stepper signals is done in an interrupt handler.
Would it be better to continue in some discussion thread?
Yes, since this is an old thread and you are not the OP.