What version of the firmware are you using?
[MSG:Grbl_ESP32 Ver 1.3a Date 20201101]
[MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907]
Is the problem repeatable?
Yes
Under what conditions does the bug occur?
Running g-code program with A-axis movements in the code.
When running a program with A axis movements, the A axis gains additional degrees beyond those commanded during the program and in excess of acceptable rounding/quantization errors. These tend to occur all at once at some point in the program. It appears to be most repeatable in the lines immediately following the first A axis move in a program.
I have also been able to observe movement of the A axis when manually typing gcode commands to move the Z axis. Again, this appears only to happen when the A axis has been moved from its “pure” zero position. Indeed, if I run a program with no A axis moves in it after a hard reset, there is no movement of the A axis from “0.0”. But if I jog the A axis at all (say forward and back 1 degree) so that it calculates the “true” position (almost never returning to 0.0 after jogging at all) and run the same program, the A axis moves without being commanded.
I’ve seen the A-axis jump anywhere from a single step to 8 degrees! The error is reflected at both the DRO and the physical axis on the machine. Once this error occurs, it carries through the rest of the program even after subsequent movements of the A axis. As far as I can tell, it only occurs once in a given program. See annotations in the serial log from a run of a test program below where the axis moved 0.478 (17 steps) without being commanded.
Observed same effect with code run from two different streamers (bCNC and GrblGru).
Serial log showing an occurrence of the bug. (“ok” lines removed):
“`
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
The machine settings are as follows:
``
$0=3
$1=250
$2=0
$3=1
$4=0
$5=1
$6=1
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=1
$24=200.000
$25=800.000
$26=250.000
$27=1.000
$30=24000.000
$31=1836.000
$32=0
$N1=
$N0=
$100=320.000
$101=320.000
$102=320.000
$103=35.556
$104=100.000
$105=100.000
$110=3000.000
$111=3000.000
$112=3000.000
$113=3000.000
$114=1000.000
$115=1000.000
$120=300.000
$121=300.000
$122=150.000
$123=200.000
$124=200.000
$125=200.000
$130=275.000
$131=397.500
$132=116.000
$133=1440.000
$134=300.000
$135=300.000
Test program:
`
G90 G94
G17
G21
G28 G91 Z0
G90
T19 M6
S12031 M3
G4 P4.
G54
G90
G1 A0 F3000
G0 X41.679 Y-1.185
G0 Z55.8
G1 X40 Y-1.185 F1500
G1 A90 F3000
G0 X41.679 Y-1.185
G0 Z55.8
G1 X40 Y-1.185 F1500
G1 A180 F3000
G0 X41.679 Y-1.185
G0 Z55.8
G1 X40 Y-1.185 F1500
G1 A270 F3000
G0 X41.679 Y-1.185
G0 Z55.8
G1 X40 Y-1.185 F1500
G0 Z55.8
G28 G91 Z0
G90
M5
M30
``
评论 (6)
#2 - ExploratoryDevices 于 2020-11-19
Sure. Boot messages are below.
Performing further troubleshooting, I compiled a "virgin" build right from the git zip download, only changing the "#define N_AXIS 4" in the test drive machine. I'm able to reproduce this issue on the test drive machine with my test program gcode from my original post.
Steps to reproduce on "test drive" machine with my $ settings from my first post:
Cold boot or hard reset. (all axes start at MPOS 0.000)
Run test program. A axis finishes at 270.109 degrees.
Run test program again. A axis finishes at 270.503 degrees.
Send "G1A270F3000" (last A-axis move from program). A axis moves to 270.025 degrees.
Boot messages:
````
Grbl 1.3a ['$' for help]
[MSG:'$H'|'$X' to unlock]
Grbl 1.3a ['$' for help]
[MSG:'$H'|'$X' to unlock]
[MSG:Grbl_ESP32 Ver 1.3a Date 20201101]
[MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907]
[MSG:Using machine:OMIO 4-Axis Router]
[MSG:Axis count 4]
[MSG:RMT Steps]
[MSG:Init Motors]
[MSG:Global stepper disable pin:GPIO(13)]
[MSG:X Axis Standard Stepper Step:GPIO(4) Dir:GPIO(2) Disable:None Limits(0.000,275.000)]
[MSG:Y Axis Standard Stepper Step:GPIO(26) Dir:GPIO(15) Disable:None Limits(-397.500,0.000)]
[MSG:Z Axis Standard Stepper Step:GPIO(27) Dir:GPIO(33) Disable:None Limits(-116.000,0.000)]
[MSG:A Axis Standard Stepper Step:GPIO(18) Dir:GPIO(14) Disable:None Limits(-1440.000,0.000)]
[MSG:DAC spindle Output:GPIO(25), Enbl:GPIO(22), Dir:None, Res:8bits]
[MSG:Local access point GRBL_ESP started, 192.168.0.1]
[MSG:Captive Portal Started]
[MSG:HTTP Started]
[MSG:TELNET Started 23]
[MSG:Flood coolant on pin GPIO(21)]
[MSG:Mist coolant on pin GPIO(12)]
[MSG:X Axis limit switch on pin GPIO(34)]
[MSG:Y Axis limit switch on pin GPIO(34)]
[MSG:Z Axis limit switch on pin GPIO(34)]
[MSG:A Axis limit switch on pin GPIO(34)]
[MSG:Probe on pin GPIO(32)]
Grbl 1.3a ['$' for help]
[MSG:'$H'|'$X' to unlock]
#3 - bdring 于 2020-11-22
I was not able to repeat all your issues, but ABC have always acted a tiny bit off.
I found and counter was not being initialized for those axes. That cleared up the DROs being off for me.
Could you try recompiling and retesting on the ABC_Stepperfix branch?
#4 - ExploratoryDevices 于 2020-11-22
Thanks @bdring. I compiled the branch you suggested with the test run set to 4 axes and the behavior I had been observing is gone. The DRO reports as expected now. I'll compile it for my machine and test it with a physical axis to make sure the DRO and physical axis still agree and report back my findings.
#5 - bdring 于 2020-11-23
I merged the change with the devt branch. Use that in the future.
The other branch may go away soon.
#6 - ExploratoryDevices 于 2020-11-23
Thanks for that.
Confirming that I tested this with a real job using my 4th axis and it worked as expected. No weird movements!
Much appreciated.
#1 - bdring 于 2020-11-19
Can you show your boot messages? I would like to repeat your setup.
https://github.com/bdring/Grbl_Esp32/wiki/Requesting-Help#boot-messages