[FluidNC Issue#1481] Problem: Axis Drift About GRBL HAL

Issue #1481 | 状态: 已关闭 | 作者: HerbertHenri | 创建时间: 2025-04-17

Wiki Search Terms

Axis drifting/moving towards positive while running a G-code

Controller Board

6xCNCController, I bought from elecrow few months ago.

Machine Description

XYYZ setup, all X and Y axis with SFU1604, and Z axis with SFU1204 ballscrews, and linear rails on all axis.
The machine is DIY but quite solid, I double checked for square, and backlash on Y and X axis are abou 0.01mm (what I could measure with my gauge).

So think mechanically speaking the machine should be fine…

Input Circuits

Configuration file

board: 6x CNC Controller name: 6x XYYZ PWM stepping: engine: I2S_STREAM idle_ms: 255 pulse_us: 4 dirdelayus: 1 disabledelayus: 0 axes: sharedstepperdisablepin: NOPIN x: stepspermm: 640.675 maxratemmpermin: 1950.000 accelerationmmper_sec2: 200.000 maxtravelmm: 400.000 soft_limits: false homing: cycle: 2 positive_direction: false mpos_mm: 0 feedmmper_min: 100.000 seekmmper_min: 200.000 settle_ms: 500 seek_scaler: 1.100 feed_scaler: 1.100 motor0: limitnegpin: gpio.2:low:pu limitpospin: NO_PIN limitallpin: NO_PIN hard_limits: false pulloff_mm: 1.000 standard_stepper: step_pin: I2SO.2 direction_pin: I2SO.1 disable_pin: I2SO.0 y: stepspermm: 639.830 maxratemmpermin: 1900.000 accelerationmmper_sec2: 200.000 maxtravelmm: 400.000 soft_limits: false homing: cycle: 2 positive_direction: false mpos_mm: 0.000 feedmmper_min: 100.000 seekmmper_min: 200.000 settle_ms: 500 seek_scaler: 1.100 feed_scaler: 1.100 motor0: limitnegpin: gpio.26:low:pu limitpospin: NO_PIN limitallpin: NO_PIN hard_limits: false pulloff_mm: 1.000 standard_stepper: step_pin: I2SO.5 direction_pin: I2SO.4:low disable_pin: I2SO.7 motor1: #limitnegpin: gpio.33:low limitnegpin: NO_PIN limitpospin: NO_PIN limitallpin: NO_PIN hard_limits: false pulloff_mm: 1.000 standard_stepper: step_pin: I2SO.10 direction_pin: I2SO.9:low disable_pin: I2SO.8 z: stepspermm: 807.265 maxratemmpermin: 350.000 accelerationmmper_sec2: 70.000 maxtravelmm: 200.000 soft_limits: false homing: cycle: 1 positive_direction: true mpos_mm: 0.000 feedmmper_min: 100.000 seekmmper_min: 800.000 settle_ms: 500 seek_scaler: 1.100 feed_scaler: 1.100 motor0: limitnegpin: gpio.32:low limitpospin: NO_PIN limitallpin: NO_PIN hard_limits: false pulloff_mm: 3.000 standard_stepper: step_pin: I2SO.13 direction_pin: I2SO.12 disable_pin: I2SO.15 i2so: bck_pin: gpio.22 data_pin: gpio.21 ws_pin: gpio.17 spi: miso_pin: gpio.19 mosi_pin: gpio.23 sck_pin: gpio.18 sdcard: carddetectpin: NO_PIN cs_pin: gpio.5 probe: pin: gpio.39:low toolsetter_pin: gpio.36:low

start: must_home: false

Startup Messages

[MSG:INFO: FluidNC v3.9.4 https://github.com/bdring/FluidNC]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:config.yaml]
[MSG:INFO: Machine 6x XYYZ PWM]
[MSG:INFO: Board 6x CNC Controller]
[MSG:INFO: I2SO BCK:gpio.22 WS:gpio.17 DATA:gpio.21Min Pulse:2us]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cspin:gpio.5 detect:NOPIN freq:8000000]
[MSG:INFO: Stepping:I2S_STREAM Pulse:4us Dsbl Delay:0us Dir Delay:1us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (0.000,400.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:I2SO.2 Dir:I2SO.1 Disable:I2SO.0]
[MSG:INFO:  X Neg Limit gpio.2:low:pu]
[MSG:INFO: Axis Y (0.000,400.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:I2SO.5 Dir:I2SO.4:low Disable:I2SO.7]
[MSG:INFO:  Y Neg Limit gpio.26:low:pu]
[MSG:INFO:   Motor1]
[MSG:INFO:     standard_stepper Step:I2SO.10 Dir:I2SO.9:low Disable:I2SO.8]
[MSG:INFO: Axis Z (-200.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:I2SO.13 Dir:I2SO.12 Disable:I2SO.15]
[MSG:INFO:  Z Neg Limit gpio.32:low]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: Connecting to STA SSID:Wi-fi 2.4.ghz]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connecting...]
[MSG:INFO: Connected - IP is 192.168.100.248]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://FluidNC.local/]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Probe gpio.39:low]
[MSG:INFO: Toolsetter gpio.36:low]
ok

User Interface Software

CNCjs 1.10.5

What happened?

I noticed whatever g-code I run, all axis seems to move towards positive directions ( XY diagonally) and Z axis going up.

I tought maybe it was the machine or something, maybe the g-code, I generated the g-code on Autodesk Fusion CAM, then I tried using Aspire 12, and all the times that happens.

Last time was a Aspire g-code, I was carving a simple slot, and the slot went down like a stair, the left/top side of it goes like a ramp, and the Z axis goes up slowly, when I used MACH3, on the same machine it never really happened, wich makes me think it’s something with the new board/ gcode sender (CNCjs) / fluidnc/ my configs/ maybe wiring?, I really dont know what could it be, but i’m almost 100% sure it shouldn’t be a mechanical issue… the machine is quite solid and the G-code also should be fine?

I haven’t noticed yet, because most of the times i did cuts, were 1 -3 passes at most, so this time I was machining some aluminium, and noticed that happening, tried the same code, same everything on a piece of MDF (thinking it could be the metal), same thing happened, all 3 axis ‘drifting away’.

Anyway, thanks in advance for the help!

GCode File

slot.txt

the g-code was acctually as ‘slot.gcode’ i just changed to be able to upload… it’s a simple slot, but with very shallow passes since it was aluminum.

Other Information

Bart asked me info about my steppers, i’m running some chinese nema23 ones, exactly like the ones below

!Image

Nema23 Stepper motor 4.4A 2.3N.M – Model j-5718HB4401, with some DM556 drivers, on all axis they’re the same, and 2, 48V PSU, I also don’t think it’s a PSU problem, or motors itself, since when I was with MACH3, nothing like that ever happened… but idk, any help is appreciated!

#1 – HerbertHenri 于 2025-04-17

Drivers are setup to 3200 microsteps, just read on the wiki anything over 100 is too much? I don’t really know about that, I just did what a friend recommended, and like mentioned, used to work fine with MACH3 so Idk…

#2 – MitchBradley 于 2025-04-17

Try adding :low to the end of the steppin definitions, like this: steppin: I2SO.2:low

#3 – HerbertHenri 于 2025-04-17

What should it change? Overall the machine works as intended… when i do passes that are like 1 -3 stepdowns, it cuts normally as i could notice, the drifting seems to happen with multiple stepdowns.

I’ll try it anyway, and see if anything changes!

#4 – MitchBradley 于 2025-04-17

If the pulses are inverted compared to what the driver expects, it is possible that the driver might be inferring steps during some situations that should be treated as not being steps. I am not sure that this is what is happening, but I want to eliminate the possibility.

#5 – HerbertHenri 于 2025-04-17

But if that was the case, wouldn’t the steppers move in the other direction? 🤔

#6 – bdring 于 2025-04-17

It would not go the wrong direction, but could misread the pulse. It acts on the wrong side of the pulse. It is unlikely the issue, but worth checking.

Do you see any LED activity on axes that shot not be moving?

I can test your config, but I will not be home until next week.

#7 – HerbertHenri 于 2025-04-17

I’ll be home in a few minutes and i’ll try the pin settings and will see if any led lights up.

#8 – bdring 于 2025-04-17

Try looking for led activity in both active modes.

It is really hard to see fast off blinks.

#9 – HerbertHenri 于 2025-04-17

So I did the :low thing, nothing changed, and the leds apparently are working as they should.

I mentioned my microstepping is at 3200, is that ok? too high? Is there any chance thats the problem?

#10 – bdring 于 2025-04-17

That is excessive. It could be a problem at high speeds.

Most people use 80 to 100 steps per mm.

#11 – HerbertHenri 于 2025-04-17

But could that be the cause of the problem? I ran the same g-code just now, the Z axis went like 5-6mm up, and the drift kept happening (about 1mm to the side…)

My steps per mm are ate 640~ on xy and 800 ish at Z, should then i decrease the microstepping? Wich one you’d recommend that will still be the most accurate as possible?

#12 – HerbertHenri 于 2025-04-17

> Try looking for led activity in both active modes.
>
> It is really hard to see fast off blinks.

I was watching that, they blinked when the axis moved, no blinking was done when the axis wasnt moving (as far as i could see), both Y axis blinked togheter, i think the board might be fine… maybe my config.yaml? Idk what else to try…. and XY drift is about a 1mm on that specific g-code, and Z was about 5-6mm (going up)

#13 – bdring 于 2025-04-17

I don’t know. I’ll stop speculating. I will test next week.

#14 – HerbertHenri 于 2025-04-17

Ok, in the meanwhile i’ll decrease the microstepping and try again. I’ll be waiting on a possible solution!

#15 – HerbertHenri 于 2025-04-17

!Image

Just did these 3 slot cuts right now….

the top right one, looks okay, but it’s not, the other 2 is clearly visible how much the machine is moving, the bottom right , i just did with a Fusion 360 g-code, and after reducing my microstepping from 3200 -> 800, it drifted even more, even tho the machine is moving as intended….

the stepdown was 0.1mm, like the Aspire g-code… the left/bomttom side of the last cut, looks like a ramp…

Edit: The slots are supposed to be 5mm x 13mm, so the drifting is a bit over 2mm on the last try.

I tried a adaptive clearing too, it also drifted a bit, and the Z axis keeps going up…. i’m losing my sanity

#16 – HerbertHenri 于 2025-04-17

> Try adding :low to the end of the steppin definitions, like this: steppin: I2SO.2:low

Yeah, I did that, nothing much changed… Any other ideas that I could try?

#17 – mikeoverbay 于 2025-04-17

did you make sure your coupliing isn’t slipping?
Maybe mark it with a sharpie and see if the screw or motor shaft slips?

#18 – HerbertHenri 于 2025-04-17

> did you make sure your coupliing isn’t slipping? Maybe mark it with a sharpie and see if the screw or motor shaft slips?

Did not check that… (as far as i know it shouldn’t be… but doesn’t hurt to check!), brb in a few.

But like the drift is in both X and Y, i run 2 Y axis, and they dont miss align…. wouldn’t it need to all 4 couplings be slipping? coz i’m experiencing drift in all 3 axis… XY going top/right, and Z going up

#19 – HerbertHenri 于 2025-04-17

> did you make sure your coupliing isn’t slipping? Maybe mark it with a sharpie and see if the screw or motor shaft slips?

nothing slipping, mechanically speaking everything is fine

#20 – MitchBradley 于 2025-04-17

With external drivers, 3200 is not “microstepping”, but instead “pulses/rev”. Nearly all motors are 200 full steps/rev, 3200 pulses/rev divided by 200 full steps/rev is 16 pulses/full step , so the microstepping level is 16. That is a very typical microstepping level that, by itself, is not likely to be a problem.

!Image

#21 – HerbertHenri 于 2025-04-17

> With external drivers, 3200 is not “microstepping”, but instead “pulses/rev”. Nearly all motors are 200 full steps/rev, 3200 pulses/rev divided by 200 full steps/rev is 16 pulses/full step , so the microstepping level is 16. That is a very typical microstepping level that, by itself, is not likely to be a problem.
>
> !Image

Yes! that what i meant by 3200!

but i changed to 800 now, to see if anything changes (surprisingly the machine feels like its running smoother…) but the drift keeps happening, Z axis goes up like 8mm after that specific g-code, and XY moves like 2-3mm (towards the positive)…

I re-checkd all couplings, screws, squarenenss, everything mechanical-wise is ok…

I was googling like crazy, and could it be wiring? some sort of interference? ( i read that spindles can cause that… but i use a makita router? idk), bad connections? (idk, i made sure everything is tight and well ajusted on the wiring… I really have no idea…

Maybe my config.yaml is messed? I picked up a xyyz example and edited what i needed only…

Any kind of suggesting i’m willing to try haha

#22 – MitchBradley 于 2025-04-17

I am trying to create a test environment that is close to your setup.

Meanwhile, here are two things to try:

1. Run the program with the router turned off – an “air cut” without a bit. That will eliminate the possibility of interference from the spindle.
2. change the stepspermm values to integers to see if there could be a rounding error in the math. Obviously that will change the dimensions a little, but we can see if that affects the drift.

#23 – HerbertHenri 于 2025-04-17

> I am trying to create a test environment that is close to your setup.
>
> Meanwhile, here are two things to try:
>
> 1. Run the program with the router turned off – an “air cut” without a bit. That will eliminate the possibility of interference from the spindle.
> 2. change the stepspermm values to integers to see if there could be a rounding error in the math. Obviously that will change the dimensions a little, but we can see if that affects the drift.

Did both, still drifting :/, and Z axis still going up (or not going down properly?! idk, the thing is when i 0 the z axis againg theres a somewhat consistend 8mm increase.

#24 – HerbertHenri 于 2025-04-18

One thing i noticed, the drifting with the fusion 360 code is way bigger than the aspire gcode, idk why

#25 – MitchBradley 于 2025-04-18

I am using your config file – as given above in the initial posting – on an old 6-pack board with external driver adapters. I have one motor connected to X. The motor is an IHSV57 integrated driver/stepper combo set to 3200 pulses/rev. The motor is not connected to any mechanical system but I have a tape “flag” on the shaft so I can see the rotational position.

When I run your program, the X motor first rotates a little more than 1 turn, which is consistent with the move from X0 to X5.5 (5.5 mm * 640 steps/mm / 3200 steps/rev= 1.1 rev). It then shuttles back and for about 0.4 revs – again consistent with the movement from X4.4 to X6.6. At the end of the program, it returns to the original starting point at X=0.

I am going to try with Y

#26 – MitchBradley 于 2025-04-18

With the motor on the first Y connector, the behavior is as expected. Several initial revolutions to get to Y49.6, then back and forth shuttling along the length of the slot, then a final return to the starting position.

Please post detailed photos of the wiring between you controller board and the stepper drivers.

#27 – HerbertHenri 于 2025-04-18

!Image

I tried my best to show how it’s wired,,, but all drivers are wired the same

also the leds were on coz the machine was on hold…
when i turned off and moved back to 0.0 xy, it all turned off, only x remaining on

#28 – HerbertHenri 于 2025-04-18

> With the motor on the first Y connector, the behavior is as expected. Several initial revolutions to get to Y49.6, then back and forth shuttling along the length of the slot, then a final return to the starting position.
>
> Please post detailed photos of the wiring between you controller board and the stepper drivers.

The g-code is probably fine…
Is there any chance CNCjs is messing up? I dunno…

#29 – MitchBradley 于 2025-04-18

Do your drivers have a switch to set the input sensitivity?

!Image

#30 – MitchBradley 于 2025-04-18

I suppose it could be possible that CNCjs is sending something wrong. Please try with FluidTerm, sending “$sd/run=slot.gc”.

原始Issue: https://github.com/bdring/FluidNC/issues/1481