[Grbl_Esp32 Issue#20] Missing step pulse behavior

未分类 bolang 4个月前 (10-14) 39次浏览

Issue #20 | 状态: 已关闭 | 作者: jimfong1 | 创建时间: 2018-08-11

标签: bug


Hello,

Testing out the grbl code on a Nodemcu32s and getting some odd step pulse behavior.
Checking to see how fast x axis step pulse rate is possible with these x axis settings

$100=250
$110=3000

From position X=0
G1X100F2000 moves fine, nice step pulse output seen on the oscilloscope.

When I do a longer
G1X200F2000 move, you see the step pulse acceleration then the pulse train completely disappears and then picks back up again when it decelerates. It drops the middle portion of the move.

When I change the feed rate to a lower value such as 1000, it works fine
G1X200F1000

So at certain combinations of feed rate and move distance, it doesn’t work correctly.

Regards,

Jim


评论 (8)

#1 – bdring 于 2018-08-11

Are you using the lastest master branch and the default settings? How long is the drop out.

I can try to reproduce your problem. While experimenting with new features I have seen some of the peripheral APIs appear to block interrupts during function calls. I have not seen that in the current code, but I will look for it.

I am out of town until late next week to take my kids to college (both Colorado State … go Rams). I will not be able to try anything until I return.


#2 – jimfong1 于 2018-08-11

I downloaded from github a few days ago. All default values except $110 was changed to 3000. This was to test max pulse rate.

The dropout is a few seconds, it depends on how long the g1 move was set at. No hurry. I use grbl on several boards but mostly on a LPC1769 running the port of grbl-lpc on a laser. The LPC1769 is pretty fast but serial throughput is a limitation for laser raster scanning. I’m hoping to see if the Esp32 would be faster. I’m running about 70khz step pulse rate with about 2500 gcode lines per second throughput when laser raster scanning.

Oh thanks for the work on PSOC port too. I got it to compile but the two PSOC pioneers boards I have are older versions. I need to order a Psoc5 to test.

> On Aug 11, 2018, at 10:45 AM, bdring wrote:
>
> Are you using the lastest master branch and the default settings? How long is the drop out.
>
> I can try to reproduce your problem. While experimenting with new features I have seen some of the peripheral APIs appear to block interrupts during function calls. I have not seen that in the current code, but I will look for it.
>
> I am out of town until late next week to take my kids to college (both Colorado State … go Rams). I will not be able to try anything until I return.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.


#3 – bdring 于 2018-08-13

@jimfong1

I am unable to reproduce your problem. I used the same settings and gcode you provided. I can run a stepper motor well past 80KHz before the motor cannot go any faster. I can still hear the steps though.

If I push the speed above what it can handle (100kHz+) I will hear a behavior like what you describe, but will hear/see an occasional pulse.

I should probably figure out a safe MAXSTEPRATEHZ, via math from FSTEPPER_TIMER and turn that on.

I only had a little time to look at this. I want to write a gcode torture test I’ll take your input into account when writing it. I might also write a $I like command to dump ESP32 setting to make sure those are right.


#4 – jimfong1 于 2018-08-13

Video of the dropped step pulse. If you don’t receive this Video attachment, let me know and I’ll post up to YouTube so you can view it.

Latest github source downloaded today.
Arduino 1.8.5
ESP32 board manager installed version 1.0.0
Nodemcu32s
All default values except $110=3000
DM542 driver @ 24volts
Nema17 from StepperOnline.com

Move command was
G1X200F2000

> On Aug 13, 2018, at 9:01 AM, bdring wrote:
>
> @jimfong1
>
> I am unable to reproduce your problem. I used the same settings and gcode you provided. I can run a stepper motor well past 80KHz before the motor cannot go any faster. I can still hear the steps though.
>
> If I push the speed above what it can handle (100kHz+) I will hear a behavior like what you describe, but will hear/see an occasional pulse.
>
> I should probably figure out a safe MAXSTEPRATEHZ, via math from FSTEPPER_TIMER and turn that on.
>
> I only had a little time to look at this. I want to write a gcode torture test I’ll take your input into account when writing it. I might also write a $I like command to dump ESP32 setting to make sure those are right.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.


#5 – bdring 于 2018-08-13

@jimfong1 I can’t see the video, but I was able to reproduce some similar issues. No need to post the video.

I get problems when I use the default of $2=1. That is a step pulse invert. Try changing to $2=0. I don’t know how that became the default. It seems like most people would want 0 or 7. 0 is the default in AVR Grbl. I must have typo’d that.

I don’t know why it causes that behavior. There is a likely a problem in the code.

Thanks for your help finding this.


#6 – jimfong1 于 2018-08-14

$2=0 fixed the problem. Thanks.

Fastest step pulse I’m getting is 127khz single axis move, pretty good. This is higher than smoothieware running on LPC1769 which is about 90khz. Stepper motor runs smoothly at that speed.

Setting $0=3 which is the minimum step pulse width. The actual pulse width is 3.920microseconds. Period is 7.880microseconds.

> On Aug 13, 2018, at 5:55 PM, bdring wrote:
>
> @jimfong1 I can’t see the video, but I was able to reproduce some similar issues. No need to post the video.
>
> I get problems when I use the default of $2=1. That is a step pulse invert. Try changing to $2=0. I don’t know how that became the default. It seems like most people would want 0 or 7. 0 is the default in AVR Grbl. I must have typo’d that.
>
> I don’t know why it causes that behavior. There is a likely a problem in the code.
>
> Thanks for your help finding this.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.


#7 – bdring 于 2018-08-14

Great to hear. I will leave this issue open until I get a chance to update the code.

It is hard to dial in those other times to exact values.


#8 – bdring 于 2018-08-14

The default file has changed and a note about step pulse invert was added to the readme.md


原始Issue: https://github.com/bdring/Grbl_Esp32/issues/20

喜欢 (0)