how does grbl know to interpret next line of gcode in queue?

[Axaxin]

I don't have much knowledge about electronic stuffs/the grbl's basic mechanism dealing with stepper motor. I just wondering, when grbl is executing a line of gcode, for example, G0X100, how does grbl know that the X stepper motor has reached 100mm, and then starts to execute the next in queue? Is it because the stepper driver give a feed back to grbl? or grbl just knowing it by counting how much pulses were sent by itself?
I was thinking to use a set of closed loop step motors with grbl, to increase speed performance of my project, like some rapid loop motions. Known that grbl is designed for open loop, so my little thought might not be as easy as just by substituting in a closed loop set. Perhaps i could implement a upper level console(GUI) to make this happen, but first need to figure out how grbl behaves when executing gcode. Any suggestion?
Thanks a lot.

[HuubBuis]

GRBL knows the position of the stepper by counting the steps made.

Changing to closed loop doesn't give much more performance just more safety margin when running at the limits of your machine. Closed loop motors (steppers or servo's) do run more quit!

If you want to use closed loop steppers with GRBL, select a stepper motor with a builtin driver. They can be controller by only step/dir signals just as any normal stepper. When the closes loop stepper can't keep up the pace, he will signal the controller by setting an output pin.

[Axaxin]

@HuubBuis As you told, using a stepper with a builtin driver, let GRBL treats it as a normal stepper, in this case, if step lost/over happens during executing current gcode, how GRBL knows to hold and give room for driver/encoder to fix it before starting next line? How about using !/~(hold/resume) override command to hold GRBL when alarm signal from encoder is captured?

[HuubBuis]

GRBL doesn't know if the stepper lost steps and will keep sending position pulses. If this happens, the damage is already done, you are turning/milling at the wrong position. Closed loop lets you stretch the limits of your machine and you should (mis)use this advantage only under safe conditions (positioning at max speed). This problem has every controller, not just GRBL.

Closed loop drivers normally have 2 additional outputs, one to signal the motor is at position and one alarm output to signal the driver stopped trying to keep up with the position commands and stopped moving. This alarm output can be used to abort the milling/turning process (emergency stop). Besides the low noise, this alarm output, is in my opinion, the only advantage of closed loop drivers. I know lots of people don't share this opinion but I always try to prevent problems.

[109JB]

Grbl is only open loop and cannot "recover" from a position loss.

The closed loop steppers close the loop between the driver and the motor. Grbl is not involved in this. if the motor can't keep up, the drive can compensate to an extent, but if it gets too far then the drive will fault. This is a non-recoverable condition.

The drivers I am familiar with only have fault output. Not "in-position", because the there are really only 2 conditions. Those are basically what I will call "fault" or "not-fault". It is always either one or the other, There might be additional information displayed on driver programming utilities or on driver displays, but I am not aware of any drive that outputs this to the controller. So really only one "fault" output is needed.

The only way that Grbl can know if the motor/driver has faulted is if you hook up the fault line from the driver to an input to Grbl. I have done this using the safety door input. What happens is if the drive faults the fault signal will trip the safety door which stops the machine. The user would then ahve to figure out why the drive faulted, reset the drive, re-home the machine, etc.

[HuubBuis]

I wasn't aware there are closed loop drivers without a AtPosition signal!

No Alarm when using a closed loop driver does not mean the motor is exactly at position. It means that the position error is smaller than the maximum position error set in the drivers configuration!

Closed loop motors typically have 3 position states:

• In position: The FaultSignal is cleared, the AtPosition signal set The motor is exactly at position.
• No Fault but not exactly at position: The Fault signal is cleared, the AtPosition signal cleared The motor is not exactly in position but the error is smaller than the maximum error set in the drivers configuration. This is the "critical state" when the drivers tries to reach the exact position set..
• Fault: The Fault signal is set, the AtPosition signal cleared The motor can't keep up and the position error is larger the the maximum position error set in the drivers configuration. The motor is halted.

For accurate positioning you can't asume that when there is no alarm, the stepper is at position. You have to check and wait for the AtPosition signal (if the driver supports this).

Check the documentation for a leadshine HSS86 driver or imitation 2HSS86B driver.

[ghartc]

They all have an Atposition output. It's just that some of them require an SN7404 hex inverter on their fault output.

On Thu, Feb 7, 2019 at 9:59 AM Huub Buis notifications@github.com wrote:

I wasn't aware there are closed loop drivers without a AtPosition signal!

No Alarm when using a closed loop driver does not mean the motor is exactly at position. It means that the position error is smaller than the maximum position error set in the drivers configuration!

Closed loop motors typically have 3 position states:

• In position: The FaultSignal is cleared, the AtPosition signal set The motor is exactly at position.
• No Fault but not exactly at position: The Fault signal is cleared, the AtPosition signal cleared The motor is not exactly in position but the error is smaller than the maximum error set in the drivers configuration. This is the "critical state" when the drivers tries to reach the exact position set..
• Fault: The Fault signal is set, the AtPosition signal cleared The motor can't keep up and the position error is larger the the maximum position error set in the drivers configuration. The motor is halted.

For accurate positioning you can't asume that when there is no alarm, the stepper is at position. You have to check and wait for the AtPosition signal (if the driver supports this).

Check the documentation for a leadshine HSS86 driver or imitation 2HSS86B driver.

[109JB]

They all have an Atposition output. It's just that some of them require an SN7404 hex inverter on their fault output.

Look at the leadshine easy servo DH drives http://www.leadshine.com/UploadFile/Down/ES-DH1208d_V1.4.pdf for one that at least doesn't document how to access at-position. I have 3 clones of these and another type as well that doesn't have any at-position signal.

Regardless, in regard to Grbl, or any other open loop controller, there really isn't anything practical you can do with the at-position indication anyway. If the drive is not in position during motion, there is nothing you can do other than a feed hold to let it catch up. The only other thing you could do is perform a move and then wait for the at-position indication as a signal to proceed to the next move. Either of these would kill performance and any look-ahead planning and drastically reduce speed. Other than that, you would have to re-code Grbl.

In addition, since machines usually have more axes than one you would need to monitor every at-position pin and make sure all of them were sending an in-position signal, or are you only going to slow one or two axes to let the lagging one catch up. This isn't trivial and isn't capable in grbl.

If that kind of positioning accuracy is needed then I would say Grbl and closed loop steppers are the wrong tools. That kind of accuracy screams for a loop closed to the controller or for a dual closed loop system. Again, not a grbl thing.

[109JB]

For accurate positioning you can't asume that when there is no alarm, the stepper is at position. You have to check and wait for the AtPosition signal (if the driver supports this).

I forgot. You absolutely can assume that no alarm means accurate positioning as long as the allowable error for a fault is within acceptable limits.

[Axaxin]

@109JB @ghartc @HuubBuis thanks for all of your valuable comments.

With respect to comments above, I can only conclude that:

1. simply use grbl + closed loop stepper, only gives more safe margin when machine performs at max speed limit. In other words, it can't significantly increase speed limit of the machine but the total efficiency for a piece of work.
2. I think the closed loop driver does know the number of steps lost at the point of alarm/fault triggered. And, if grbl is set to trigger safety door at the same time, by some calculation, grbl is able to relocate position of motors and continue. However, this process could only be done outside of grbl, or like @109JB said, not a grbl thing. (I might be wrong)
3. If step lost happens a lot for a work, means that it's over the limit of the machine/system. Spend more money could help (sad).

I should have declared that I'm not using grbl to do CNC things, my project does not require very high accuracy in positioning but require at least, it can finish the planed track at max speed limit of machine with respect to its cost budget. Let's saying that the planed track is like going along a square, as long as it travels all along the square by the end, i don't mind if there are some shacking-like tracks during the work.

[HuubBuis]

at least, it can finish the planed track at max speed limit of machine

The closed loop stepper controllers I know of, will stop immediately if the alarm (fault) is triggered. They have to be power cycled to clear the alarm and restart stepping.

If step lost happens a lot for a work.....

You should lower the stress on the stepper!

[109JB]

If using closed loop steppers, as @HuubBuis said, a fault will require a power cycle of the stepper driver to reset it. What sending the fault signal back to Grbl does is allows Grbl to stop the other axes to prevent further problems.

As far as recovering from the fault in a case like this, the procedure would be to reset the drives, re-home the machine if homing switches are installed and then address what likely caused the fault. This could be pushing the machine too hard or something else, but you have an opportunity to adjust.

Closed loop or open loop, servo or stepper, the key is to operate the machine within the limits of the installed drive system. I have an open loop machine as well as the closed loop machine and the open loop machine works perfectly when operated appropriately. The closed loop system just allows a bit of a safety net in my opinion.

[Axaxin]

If step lost happens a lot for a work.....

You should lower the stress on the stepper!

the "work" refers to my work. No doubt, for a typical CNC work, lower the stress and a bit more time consumption is more reasonable.

a fault will require a power cycle of the stepper driver to reset it.

@109JB Is there anyway to extract the number of step lost from the driver?or, there is just no such data/thing exist？

[109JB]

@109JB Is there anyway to extract the number of step lost from the driver?or, there is just no such data/thing exist？

I'm really not 100% sure, but I don't believe the following error can be accessed once the drive is in a fault condition.

[Axaxin]

Eventually I realize that what I am really looking for in closed loop steppers is, to see if there any way to let grbl re-capture the position of motors without re-home.

I don't believe the following error can be accessed once the drive is in a fault condition.

well, to handle those following errors definitely is out of my knowledge.

[HuubBuis]

You can add a second encoder (low resolution) to the spindle or stepper. This the position can be read in a second dedicated Arduino. You could then use this position in your application to startup again. As an alternative, you could also read the signal from the stepper encoder if you use an external driver. This is "simply" adding two optocoupler inputs in series with the encoder output.

A other solution is to use Mach3, Stepper and Encoder, normal (open loop) stepper driver, and a controller like CSMIO/IP-M as closed loop controller, but that is a lot more expensive.

Think about avoiding losing steps, this will make life easy!

[Axaxin]

@HuubBuis yep, to play around with encoder is better direction to my project rather than looking at closed loop driver. Do you have any guide or tutorial about that arduino working with encoder?

[HuubBuis]

Here a encoder tutorial . The tutorial is about a small "pot meter" type encoder but they all work the same just the resolution differs. Included is a small example sketch and you can find a lot more using Google.

https://howtomechatronics.com/tutorials/arduino/rotary-encoder-works-use-arduino/

You can sent the position periodically to the serial port or wait for a trigger ("?" on GRBL)