Loss of position

[Juank23]

good morning terjeio....
I have a problem with the code, I realized that it is losing steps in a large gcode, I did several tests with servomotors which give higher performance acceleration and precision, but in a small gcode the servos return without problem to their initial position, but when the gcode is large the servos lose position, I have several controllers, the f411, f401, rp2040, and with all the same thing happens, but try with a bluepill f103 and this code https://github.com/robomechs/6-AXIS-USBCNC-GRBL
and it works fine.... also try with an esp32 and fluidnc and it works fine, do you know what could be happening?

[terjeio]

Do you have more details?
E.g. is the step count the steppers see out of sync with the controller step counters?
The reported position is correct?
By how much is the position off? Is it consistent for every run?
Can you post a large file that fails?

[Juank23]

Good morning Tetjeio...
Thanks for your prompt reply ....
The problem is in the position of the axes X, Y, Z etc...
it does not return to the initial position with an extensive gcode that is to say the servomotors X,Y,Z lose steps, I tried all your most recent codes and even some old ones and the same thing happens, I thought that it could be some configuration in the servos and I tried with a bluepill and the firmware of the link that I sent you and they worked well although the configuration is greater than with the tests in grblhal next I send you photos of the configurations that I am using and the gcode I remain attentive thank you....

[Juank23]

I send you the gcode
vik.zip

[terjeio]

I have now run your test file on a STM32F446 with your settings using my machine simulator. Both the reported positions (in the real time report) and the simulator step counts return to 0.

What is the stepper driver specification for the minimum dir to step pulse setup time?
And our $29 setting (pulse delay)?

And can you answer these questions asked previously, if possible?

The reported position is correct?
By how much is the position off? Is it consistent for every run?

[Juank23]

good day terjeio, the servo dirve is brand xinje ds2, tembien test with a leadshine is d508, vexta asd2-a
and stepperonline cl57tbut with all does the same, but with the bluepill and the code of the link that I sent you does not do that, the motors do not lose steps, the grblhal code has some limitation?

[terjeio]

the grblhal code has some limitation?

No, it might be faster than the other ports. If the dir -> step delay is too small for the drivers this could lead to the drivers losing or incorrectly interpreting step pulses. The AMASS used by Grbl/grblHAL to smooth step pulses may introduce some seemingly random delay between dir transitions to next step pulse thus most of the time keeping signalling within driver tolerances.

[Juank23]

terjeio, look try with the esp32 and grblhal and also with the rp2040 and the same thing happens, I uploaded grblhal to the bluepill and also does the same servos lose steps, but if I upload the 6-AXIS-USBCNC-GRBL with this servos work well there is some small problem in the code, if you could try it with a motor so you realize what's happening

[terjeio]

Have you tried with setting $29 to a value >= 1?
And please answer my previous questions if you can - I ask them so that I can get some clues to what might be the issue...

[Juank23]

Already tested and still the same....

[terjeio]

Ok, again then:

The reported position is correct?
By how much is the position off? Is it consistent for every run?

[Juank23]

Good morning Terjeio,
If every time you run the gcode,
it loses the initial position.
I open the gcode in iosender all I leave it at zero run the program and after a couple of minutes I give stop and run the command G0X0Y0 and completely loses the position, then send photos I remain attentive

[terjeio]

after a couple of minutes I give stop and run the command G0X0Y0

Well, that is why it loses position.

grblHAL:

• most drivers has a large input buffer, 1024 bytes compared to 127 bytes in legacy Grbl.
• has a new stop command that is similar to reset but less harsh. But still stops motion abrubtly.

ioSender supports the character counting method (agressive buffering) that attempts to keep the input buffer relatively full, this for smoother motion. Many legacy senders does not and implement stop (or rather pause) by simply stop sending commands to the controller. If ioSender did that you would risk the machine running for quite some time before coming to a halt. This is, IMO, dangerous and the reason for adding the new stop command. So for a controlled halt of motion when ioSender is used with a grblHAL controller first press Feed hold, and after motion has stopped press Stop. This will ensure position is not lost.

Due to a user request ioSender will use the same protocol as other senders when the controller is Grbl based, it just stops sending new commands. IIRC the label on the Stop button should change to Pause when motion is ongoing to as feedback to the user - note I am not able to recheck that now. This explains why Grbl controllers does not lose position.

[Juank23]

Well that also happens if I let the gcode finish, my question is why with the bluepill and the other code that does not happen?

[terjeio]

Well that also happens if I let the gcode finish

Well, then we are back to my unanswered questions...

[Juank23]

well, I think this is a big problem because if you have a large cnc and the gcode is extensive.
it would easily lose the position even if you have servomotors ....????

[Juank23]

Good morning Terjeio, Is there any way to solve this problem?
I remain attentive thank you

[terjeio]

Is there any way to solve this problem?

First it has to be identified where the problem is located. I will do my part when I am back home by retesting the ESP32 and RP2040 drivers.
If you find time to answer my previous questions that would help to isolate where, if not I will have to do so on my own.

I anyone are willing to donate a closed loop driver/motor combo that may help as I currently do not have one available.

[Juank23]

Good morning Terjeio...
I did several tests with the controllers I have (STM32F103, STM32F401, STM32411 and Esp32) and all have the same problem, tell me exactly what you need to know because I did not understand very well your questions remain attentive ..... thanks

[terjeio]

I need to know when you run a test to completion is the position error the same every time or does it vary (is random)?
How large is the error? Several mm or a small fraction of a mm?
Is the position reported from the controller correct at the end of a run?

[Juank23]

Good morning Terjeio.....
The positioning error is random depending on how long the gcode.... lasts.
the magnitude of the error depends on the duration of the gcode...... a couple of mm, I'm going to get a comparator to know exactly when it is the error ...
the position indicated by the controller after finishing the gcode is not correct because of the error...

Working on an engraving gcode when it finishes I run it again and I see that the engraving is a couple of millimeters off in X,Y,Z.
I remain attentive

[terjeio]

The positioning error is random depending on how long the gcode.... lasts.

You have different run times with the same gcode file? I want to know if the same file consistently produces the same error every run or if there is some randomness.

the position indicated by the controller after finishing the gcode is not correct because of the error...

So the displayed position differs from the programmed one?

I see that the engraving is a couple of millimeters off in X,Y,Z.

That is a lot - several thousand steps.

[terjeio]

I have now run several tests successfully with the ESP32 driver (latest commit) connected to my simulator, are you sure the stepper drivers are tuned correctly?

[Juank23]

Good morning terjeio....
well I have tested grblHAL with these controllers STM32F1xx, STM32F4xx, RP2040, ESP32 and I noticed that error.... The strange thing is that with the same hardware and other firmware such as fluidnc, Grbl_Esp32, 6-AXIS-USBCNC-GRBL that does not happen, I am building an actuator to test with the servo motors and that way I can tell you in detail the error that there is as soon as I do those tests again I will write you thank you very much.

[terjeio]

FYI the ESP32 driver had issues with I2S stepping that I have now fixed. Depending on which ESP32 board you are testing with this may be the cause of your problems.

[JoachimF]

Hello Juank,

Have you tried normal steppers? I read some servos could be in speed precise or position precise.
I have an EP32 on my lathe, I can test a long gcode if you provide it to me, only two axis x and z, next step is to test blackpill to get spindle sync, I'll give you a report if I loose steps.

Regards

[Juank23]

good day JoachimF, I have tried with a dm556 driver and a nema 23 motor.
and I also have the same problem, I'm waiting to get some components that I bought to make more accurate tests since I have only tried with the engines that are in the images above, the strange thing is that with another grbl there is no such problem I thought it was a problem of firmware ....