Wiki Search Terms
Axis drifting/moving towards positive while running a G-code
Controller Board
6x_CNC_Controller, 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
dir_delay_us: 1
disable_delay_us: 0
axes:
shared_stepper_disable_pin: NO_PIN
x:
steps_per_mm: 640.675
max_rate_mm_per_min: 1950.000
acceleration_mm_per_sec2: 200.000
max_travel_mm: 400.000
soft_limits: false
homing:
cycle: 2
positive_direction: false
mpos_mm: 0
feed_mm_per_min: 100.000
seek_mm_per_min: 200.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.2:low:pu
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
standard_stepper:
step_pin: I2SO.2
direction_pin: I2SO.1
disable_pin: I2SO.0
y:
steps_per_mm: 639.830
max_rate_mm_per_min: 1900.000
acceleration_mm_per_sec2: 200.000
max_travel_mm: 400.000
soft_limits: false
homing:
cycle: 2
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 100.000
seek_mm_per_min: 200.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.26:low:pu
limit_pos_pin: NO_PIN
limit_all_pin: 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:
#limit_neg_pin: gpio.33:low
limit_neg_pin: NO_PIN
limit_pos_pin: NO_PIN
limit_all_pin: 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:
steps_per_mm: 807.265
max_rate_mm_per_min: 350.000
acceleration_mm_per_sec2: 70.000
max_travel_mm: 200.000
soft_limits: false
homing:
cycle: 1
positive_direction: true
mpos_mm: 0.000
feed_mm_per_min: 100.000
seek_mm_per_min: 800.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.32:low
limit_pos_pin: NO_PIN
limit_all_pin: 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:
card_detect_pin: 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 cs_pin:gpio.5 detect:NO_PIN 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
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
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!
Activity
HerbertHenri commented on Apr 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…
MitchBradley commented on Apr 17
Try adding :low to the end of the step_pin definitions, like this: step_pin: I2SO.2:low
HerbertHenri commented on Apr 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!
MitchBradley commented on Apr 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.
HerbertHenri commented on Apr 17
But if that was the case, wouldn’t the steppers move in the other direction? 🤔
bdring commented on Apr 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.
HerbertHenri commented on Apr 17
I’ll be home in a few minutes and i’ll try the pin settings and will see if any led lights up.
bdring commented on Apr 17
Try looking for led activity in both active modes.
It is really hard to see fast off blinks.
HerbertHenri commented on Apr 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?
bdring commented on Apr 17
That is excessive. It could be a problem at high speeds.
Most people use 80 to 100 steps per mm.
HerbertHenri commented on Apr 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?
HerbertHenri commented on Apr 17
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)
bdring commented on Apr 17
I don’t know. I’ll stop speculating. I will test next week.
HerbertHenri commented on Apr 17
Ok, in the meanwhile i’ll decrease the microstepping and try again. I’ll be waiting on a possible solution!
HerbertHenri commented on Apr 18
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
79 remaining items
HerbertHenri commented on Apr 30
Just got my hands on an easy-servo, for the X-axis (i had bought it a while ago, arrived today.)
I’ll try to setup this easy-servo and run tests again, to see if any drift ( at least on the x axis…) keeps happening…
If not, is safe to assume the issue might be on the drivers? (i know you don’t like when i assume things… but i’m just asking )
HerbertHenri commented on Apr 30
it’s also another nema 23, but uses this drive…
MitchBradley commented on Apr 30
I asked you to stop asking vague questions. Of course the issue “might” be on the drivers, but what exactly does that mean? If the drivers work with the RnR board, they are not hopelessly broken. But there could be some strange interaction between them and the 6x board. That in itself is vague and untestable.
Do you have another MCU, like an ESP32 or Arduino, that could be programmed as a pulse counter? Such a pulse counter could determine whether the 6x board is issuing the correct number of steps.
MitchBradley commented on Apr 30
I thought of another thing to try – set dir_delay_us to 100.
HerbertHenri commented on Apr 30
I have arduino uno, can be done with it?
MitchBradley commented on Apr 30
Yes, it will work on Uno. I will write the program. I already wrote a pulse counter program for ESP32; modifying it for Uno will be easy. I connected my ESP32 pulse counter to Y axis step and dir and ran your slot program. At the end of the program I added the line
G0 X0 Y0to return to the starting position.Here is the last few lines from the pulse count.
+653609 means that 653609 pulses were recorded with DIR active, -653609 means the same number with DIR inactive, diff: 0 shows that the two numbers were the same, i.e. it returned to the starting Y position. The line with nonzero diff was the last one before the motion finished.
I also tried it on the X axis (result was 0) and the Z axis (result was nonzero because the program left the Z coordinate at 29.75).
MitchBradley commented on Apr 30
Here is the Arduino sketch
<Removed as broken; see next message>
I could not test it on Uno because the Uno that I found in my junk box has a bad bootloader. I did succeed in compiling it for a Nano and uploading that, but I haven’t had time to test it yet. I will test later when I get back from exercising.
As with all GitHub attached files, you will need to rename it, removing the .txt suffix.
Connect the 6x GND to Arduino GND, Step to digital in 2, Dir to digital in 3. The results will be displayed on the Arduino Serial Monitor at 115200 baud.
MitchBradley commented on Apr 30
I fixed the Uno bootloader and tested the program. This version of the counter sketch works:
count.ino.txt
MitchBradley commented on Apr 30
If the counter sketch ends up with a 0 diff after you return to 0,0,0, then the driver is misinterpreting pulses. If the counter sketch ends up at a different diff count, the 6x board is probably doing something wrong.
HerbertHenri commented on Jul 29
Hey man, been a while, live been crazy.
So I was testing it right now, i ran this testslot.txt code (it’s txt coz git doesnt accepct .gcode..)
testslot.txt
Just tested the X-axis as you told me with the arduino UNO, i ran using UGS, at the beggining the serial was showing
+0 -0 diff: 0
then i ran the code, and at the last lines it showed
+48972 -51435 diff: -2463
+51435 -51435 diff: 0
+51435 -51435 diff: 0
Did it on one of the Y-axis now
+0 -0 diff: 0
at the begining, then i ran the same code w/o changing anything
Last lines on the serial monitor:
+269893 -266444 diff: 3449
+269893 -266444 diff: 3449
+269893 -269893 diff: 0
+269893 -269893 diff: 0
So on the other Y-axis
+0 -0 diff: 0
at the begining, then ran the same code.
Last lines on the serial monitor:
+269893 -266444 diff: 3449
+269893 -269893 diff: 0
+269893 -269893 diff: 0
MitchBradley commented on Jul 29
If the pulse counter always ends up at “diff: 0”, that means the FluidNC controller is doing the right thing.
Some time ago I suggested setting “dir_delay: 100”. Did you try that? You could also try “pulse_us: 20”.
closed this as completedon Aug 17
HerbertHenri commented on Aug 19
I did the dir_delay 100, nothing really changed
MitchBradley commented on Aug 19
Another thing to try: With dir_delay: 100, change the step pin polarity by either adding or removing :low.
HerbertHenri commented on Aug 19
Ok, i’ll be trying it by the weekend!
Thanks again for all the help.