Octoprint & TMC2130 : axis won’t move

Hi guys !

What is the problem?
My printer wouldn’t move the axis driven by TMC2130 (on spi mode) with octoprint

What did you already try to solve it?
Running the printer with same configuration with pronterface works perfectly

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Marlin 1.1.9
Octoprint 0.15.1 on pi2
Tmc2130 on XY axis

Wondering if anybody had the same trouble ?
Thank you very much for the help

Thomas

Continuing the discussion from Octoprint & TMC2130 : axis won’t move:

OK i got some more info guys !

When i Run a G28 X0Y0, I get :
Printer seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly

Did you try to jog the extruder assembly in the Control tab after homing all the axes?

Hi !

Thank you for your answer

FYI : the option preventing the axis to move before homing is desactivated in Marlin (i put the // in front)

I try to jog the xY axis before homing and after G28 X0Y0

...they don’t move in octoprint

But still move with pronterface

Cheers !

Share the output in your terminal tab please when you issue a move command via OctoPrint, and also check what shows up in Pronterface's equivalent when you do the same there.

In general your firmware is the one responsible of moving stuff when issued the corresponding commands, your chosen stepper driver shouldn't really make a difference here and is something that OctoPrint wouldn't even know anything about. My money would be on some kind of invalid state on the firmware side when connected to OctoPrint, possibly a missing home as already pointed out or some other issue, but we'll only be able to figure that out if we have both scenarios to compare with each other.

@foosel
Thank you so much for your answer !

Please find below the report from Octoprint after starting the printer; trying to home, changing the homing sensitivity parameter & trying to home again.

Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyACM0']
Connecting to: /dev/ttyACM0
Changing monitoring state from "Detecting serial port" to "Opening serial port"
Connected to: Serial<id=0x6693b1f0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Send: N0 M110 N0125
Recv: start
Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N1 M105
38
Recv: echo: External Reset
Recv: Marlin 1.1.8
Recv:
Recv: echo: Last Updated: 2017-12-25 12:00 | Author: (none, default config)
Recv: echo:Compiled: Oct 28 2018
Recv: echo: Free Memory: 3135 PlannerBufferBytes: 1232
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo: G21 ; Units in mm
Recv: echo: M149 C ; Units in Celsius
Recv:
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D1.75
Recv: echo: M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z1600.00 E420.00
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X190.00 Y190.00 Z4.00 E25.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X2000 Y2000 Z500 E10000
Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
Recv: echo: M204 P2000.00 R3000.00 T2000.00
Recv: echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_us> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
Recv: echo: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.30 E5.00
Recv: echo:Home offset:
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Auto Bed Leveling:
Recv: echo: M420 S0
Recv: echo:Material heatup parameters:
Recv: echo: M145 S0 H180 B70 F0
Recv: echo: M145 S1 H240 B110 F0
Recv: echo:PID settings:
Recv: echo: M301 P22.17 I2.11 D58.13
Recv: echo:Z-Probe Offset (mm):
Recv: echo: M851 Z0.00
Recv: echo:Stepper driver current:
Recv: echo: M906 X 800 Y 800
Recv: echo:Sensorless homing threshold:
Recv: echo: M914 X12 Y10
Recv: ok
Send: N0 M110 N0125
Recv: ok T:27.78 /0.00 B:27.78 /0.00 @:0 B@:0
Send: N1 M115
39
Recv: ok
Send: N2 M2118
Recv: Error:Line Number is not Last Line Number+1, Last Line: 0
Recv: Resend: 1
Recv: ok
Send: N1 M115
39
Recv: FIRMWARE_NAME:Marlin 1.1.8 (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Blackbool EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:EEPROM:0
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: ok
Send: M105
Recv: echo:SD init fail
Send: M122
Recv: X Y
Recv: Enabled false false
Recv: Set current 800 800
Recv: RMS current 1436 1436
Recv: MAX current 2025 2025
Recv: Run current 25/31 25/31
Recv: Hold current 12/31 12/31
Recv: CS actual 0/31 0/31
Recv: PWM scale 0 0
Recv: vsense 0=.325 0=.325
Recv: stealthChop false false
Recv: msteps 256 256
Recv: tstep 1048575 1048575
Recv: pwm
Recv: threshold 0 0
Recv: [mm/s] - -
Recv: OT prewarn false false
Recv: OT prewarn has
Recv: been triggered false false
Recv: off time 0 0
Recv: blank time 16 16
Recv: hysterisis
Recv: -end -3 -3
Recv: -start 1 1
Recv: Stallguard thrs 12 10
Recv: DRVSTATUS X Y
Recv: stallguard
Recv: sg_result 0 0
Recv: fsactive
Recv: stst X X
Recv: olb
Recv: ola
Recv: s2gb
Recv: s2ga
Recv: otpw
Recv: ot
Recv: Driver registers:
Recv: X = 0x80:00:00:00
Recv: Y = 0x80:00:00:00
Send: G28 XY
Recv: X:0.00 Y:0.00 Z:5.00 E:0.00 Count X:0 Y:0 Z:8000 //didn't move
Recv: ok
Send: M914 X15 Y15
Recv: X driver homing sensitivity set to 15
Recv: Y driver homing sensitivity set to 15
Recv: ok
Send: G28 XY //didn't move
Recv: X:0.00 Y:0.00 Z:5.00 E:0.00 Count X:0 Y:0 Z:8000
Recv: ok
Send: M914 X20 Y20
Recv: X driver homing sensitivity set to 20
Recv: Y driver homing sensitivity set to 20
Recv: ok
Send: G28 X0 Y0
Recv: X:0.00 Y:0.00 Z:5.00 E:0.00 Count X:0 Y:0 Z:8000 // didn't move

You will find below the same report with pronterface :

Connecting...
start
Printer is now online.
echo: External Reset
Marlin 1.1.8
echo: Last Updated: 2017-12-25 12:00 | Author: (none, default config)
echo:Compiled: Oct 28 2018
echo: Free Memory: 3135 PlannerBufferBytes: 1232
echo:Hardcoded Default Settings Loaded
echo: G21 ; Units in mm
echo: M149 C ; Units in Celsius
echo:Filament settings: Disabled
echo: M200 D1.75
echo: M200 D0
echo:Steps per unit:
echo: M92 X80.00 Y80.00 Z1600.00 E420.00
echo:Maximum feedrates (units/s):
echo: M203 X190.00 Y190.00 Z4.00 E25.00
echo:Maximum Acceleration (units/s2):
echo: M201 X2000 Y2000 Z500 E10000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P2000.00 R3000.00 T2000.00
echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_us> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
echo: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.30 E5.00
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:Auto Bed Leveling:
echo: M420 S0
echo:Material heatup parameters:
echo: M145 S0 H180 B70 F0
echo: M145 S1 H240 B110 F0
echo:PID settings:
echo: M301 P22.17 I2.11 D58.13
echo:Z-Probe Offset (mm):
echo: M851 Z0.00
echo:Stepper driver current:
echo: M906 X 800 Y 800
echo:Sensorless homing threshold:
echo: M914 X12 Y10
echo:SD init fail

M122
SENDING:M122
X Y
Enabled false false
Set current 800 800
RMS current 795 795
MAX current 1121 1121
Run current 25/31 25/31
Hold current 12/31 12/31
CS actual 12/31 12/31
PWM scale 1 1
vsense 1=.18 1=.18
stealthChop true true
msteps 16 16
tstep 1048575 1048575
pwm
threshold 0 0
[mm/s] - -
OT prewarn false false
OT prewarn has
been triggered false false
off time 5 5
blank time 24 24
hysterisis
-end 2 2
-start 3 3
Stallguard thrs 12 10
DRVSTATUS X Y
stallguard
sg_result 0 0
fsactive
stst X X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X = 0x80:0C:00:00
Y = 0x80:0C:00:00

G28 XY
SENDING:G28 XY
SENDING:G0 X82.5 Y97.0 F3000 // Moved OK

G28 Z
SENDING:G28 Z // Moved OK

I sincerely hope it helps

Have a great day

In the OctoPrint case:

G28 X0 Y0

In the Pronterface version:

G28 XY

It's not the same command. Try issuing their version in your Terminal tab just like they did.

G28 XY      # should move to home
G28 Z       # should move to home
G90         # set to absolute movement mode
G0 X10      # should jog the X motor over by 10mm

Thank you so much for your answer.
Do you mean my Homing code isn't right ?
As you can see : I have try both G28 commands for homing on octoprint...None of them will make the motors move

What happens when you (from OctoPrint's Terminal) enter:

G0 X82.5 Y97.0 F3000

If it doesn't move then it feels like something isn't right in the serial communications but I could be mistaken.

hey !

when entering this command in Octoprint terminal : nothing moves unfortunately
When doing it in pronterface : the bed and nozzle move perfectly.

So weird :thinking:

for more info :
my Z axis runs on polulu and can be homed without any issue on both Pronterface and Octoprint terminal

The only possible difference could be the line numbering plus checksum that OctoPrint sends. Maybe your Marlin wasn't compiled in such a way to support that...?

This is probably stupid advice, but I think I would try (temporarily) turning that off:

~/.octoprint/config.yaml:

serial:
  alwaysSendChecksum: false

thank you so much for the advice !

Concerning the modification of the config.yaml.
I have messed with it directly from Putty and crashed my server.

I believe there is a better way to modify the config.yaml file.

Do you know if the yamlpatcher plugin is a good option ? Would you know the steps to patch the line of code you put above ?

Thanks a lot for your help

Personally, I use nano as my editor when I've remoted into my Raspberry Pi. (I happen to use ssh rather than putty but they're essentially the same.)

That said, go back into your config and try to fix it.

nano ~/.octoprint/config.yaml

Look for the area that you edited/added earlier. If you appended those two lines at the end, simply remove them and see if it's happier and running again. There probably was an existing serial: section in the file; adding a second one isn't good.

If you earlier edited by adding one line (adding that alwaysSendChecksum: false as a single line after the existing serial: line) then look carefully at the indentation. There should be two spaces before "always..." since that section is a child of serial:.

Also, don't add extra hard returns to create blank lines in the middle of this file. You need to preserve the parent, child, grandchild hierarchy of indentations.

1 Like

hey !
awesome I have managed to add the command line at the end of the config.yaml
I double checked, there is no other Serial command in the config file.

However...It didn't help and my XY axis are still stuck :slightly_frowning_face:

Are the line numbers and checksums now gone from the commands OctoPrint sends?

Like...

N1 M115*39

The N1 and the *39 are added normally for line numbers and checksums.

Hi !

After playing with putty activating and desactivating the AlwaysSumcheck command, i have discovered the origin of the issue.

I carry the p’ugin « PSU control » on Octoprint.

Apparently the TMC2130 need to have current before being connected to the printer.
I have to make sure the printer is powered before connecting it to Octoprint.

Thank you so much for your help

Hope this issue will help other people in this amazing community

Cheers

1 Like

Just wanted to report a related issue with tmc2130 drivers+marlin in case it helps anyone searching this. Last night I successfully printed a particular gcode file from octoprint. Printer auto shutdown did it's thing while I slept. Woke up, cleared the bed, and went to print the same gcode a 2nd time this morning, and it kept failing. The y axis stopped moving on it's way to the 3rd probe point when 3 point bed leveling at the start of the print. Checking M122 after this shows the y driver "ola" and "olb" flags!

This was very repeatable and frustrating... until I decided to try another gcode file... then it worked fine! Weird?!

My only guess is octoprint or a plugin somehow corrupts operation with just that one gcode file. I went to edit gcode in octoprint and found no unexpected lines or code added in the startup. In fact the second gcode that did work afterwards has the exact same startup code!

So something else hidden inside is causing the bug when printing that file. Later today I will try to delete the bad file from octoprint and see what happens when I re-upload and print.

I am running print time genius, and a bunch of other plugins that may be related. To be sure, I updated raspi, oprint, plugins, and marlin to the latest releases, and it still happens.

If further data will help, just point me to how to extract it. I have a storage oscope etc too. Not sure how obscure or important this is, but again wanted to report this strange behavior "in case it helps".

Try all this in Safe Mode and see if you can repeat. If you can't repeat this while running in safe mode then try again in standard mode but with Print Time Genius disabled.

OutsourcedGuru, thanks for the quick reply. Quick update... problem resurfaced again this morning, and it is not octoprint. Even using marlinfw's built in (LCD menu) G29 still failed. Bottom line... suspected hardware issue.

Just for your entertainment... I hooked my oscope to watch y motor lines and y diag pin... and of course it worked fine! Then I removed the probe y-harness, tried again, and it fails lol! So we can infer my motor connectors are the issue.

What is so wierd is it is so repeatable... y gets killed almost the exact same spot everytime (and no real movement of the y motor wires... other than vibes). My brain can only deduce one conclusion... my wire issue activates with a specific signal condition... or similarly some 'natural frequency' vibe interaction happening when Y passes that spot, and it matches the frequency of the connector problem, maybe? Lol...

Unfortunately I will not be able to find out exactly why since the problem goes when I connect probes. So my solution for today... print with the y'harness installed lol! This can't be happening :smiley: