Y axis Problems
-
Can you share the results of M122 and M98 P"config.g"?
It would seem to be mechanical. Perhaps binding? Backlash?
-
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6JKD6-3S46N-TB86S
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 150904
Dynamic ram: 61012 of which 0 recycled
Never used RAM 142276, free system stack 219 words
Tasks: SBC(ready,4.9%,358) HEAT(delaying,0.0%,405) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,333) TMC(notifyWait,7.1%,93) MAIN(running,87.9%,1272) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:11:51 ago, cause: power up
Last software reset at 2021-09-06 17:27, reason: User, GCodes spinning, available RAM 142060, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 132
MCU temperature: min 22.2, current 29.4, max 29.5
Supply voltage: min 24.0, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 0, standstill, reads 53258, writes 14 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 53258, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 53258, writes 14 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 53258, writes 14 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 53258, writes 14 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 53258, writes 14 timeouts 0, SG min/max 0/0
Date/time: 2021-09-12 17:02:46
Slowest loop: 0.45ms; fastest: 0.03ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 3560, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 3560/0/0
Tx timeouts 0,0,3559,0,0,0 last cancelled message type 30 dest 127=== SBC interface ===
State: 4, failed transfers: 1, checksum errors: 0
Last transfer: 1ms ago
RX/TX seq numbers: 24583/24583
SPI underruns 0, overruns 0
Disconnects: 0, timeouts: 0, IAP RAM available 0x2c83c
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 0.32, max wait times: 8.5ms/0.0ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 2916/844M98 P"config.g"
Tool 0 offsets: X-10.000 Y-10.000 Z0.000
Tool 0 offsets: X-10.000 Y-10.000 Z0.000 -
@modest-orange It looks like some backlash in the machine. Can you post pictures or give a description of the mechanism? It looks like there's a fixed bed and the gantry moves in Y while the extruder moves in X and Z. The gantry is going to be pretty heavy- what type of motor(s) is/are driving it? Are you using external drivers or the drivers on the duet board?
-
@mrehorstdmd backlash issue would turn up on the other side, unless there's an issue with preloading I guess
-
@mrehorstdmd I am using parts from the Open Builds store; V-slot belt driven with 3GT-2M timing belts. https://openbuildspartstore.com/nema-23-belt-pinion-actuator-bundle/
I have two motors on the Y gantry running opposing each other (they both travel in the same direction when the printer gives a move command). You are correct the gantry is moving X and Z direction and is considerably heavy when loaded with clay. However the error is still there when the clay extruder is removed.
I am using the drivers on the Duet3 6HC board to drive all the motors. Here's the line from the config.g for the motor mapping;
; Drives
M569 P0.0 S0 ; physical drive 0.0 goes backwards
M569 P0.1 S1 ; physical drive 0.1 goes forwards
M569 P0.2 S0 ; physical drive 0.2 goes backwards
M569 P0.3 S0 ; physical drive 0.3 goes forwards
M569 P0.4 S0 ; physical drive 0.4 goes backwards
M569 P0.5 S0 ; physical drive 0.5 goes backwards
M584 X0.0 Y0.1:0.5 Z0.2 E0.3:0.4 ; set drive mappingI had to disassemble the printer to remove some horizontal play on the Z axis (which holds the weight from the clay extruder). It did clean up some of the prints but didn't solve the issue.
Going to have to look up what backlash and preloading are as I have heard those terms but don't know them.
Thank you again for your assistance!
-
@modest-orange With a circular path, at either end of the Y movement you're stopping the gantry. Maybe the top bar of the gantry, where the massive clay extruder mounts, is twisting due to momentum of the extruder/clay. Try pushing on the extruder clay cylinder while blocking gantry movement and see if it causes the nozzle to move.
-
@mrehorstdmd There is some deflection at the nozzle when I press on the extruder body/nozzle. However it take a little more force that you would think. I believe the rig itself is appropriately rigid for the weight, I think. I would assume if there was enough play to initiate this problem, it would also show at the 12 o'clock position as well.
I'm traveling this weekend but will try attaching a marker to the printer, with the extruder body removed, and see if the lines it creates also show this problem.
-
@mrehorstdmd
20211002_093145_Trim(1).mp4The video shows the motor turning "incorrectly" at the 6 o'clock position but not at 12. This occurs with both Y motors.
-
@modest-orange can you post some pictures of the printer that show the whole thing, not just closeups?
-
-
Been doing some more testing with tool offsets and bed size when I came across this instance.
The error is dependent on which direction the tool is moving. I had swapped the direction of every other circle in this print, clockwise and counter-clockwise. Earlier I referred to the error occurring at the 12 o'clock position because it was easier to refer to. While the printer moves counter-clockwise the error actually occurs closer to 11 o'clock Moving clockwise the error occurs closer to 1 o'clock.
This makes me think it has something to do with the motors and how power is being sent to them. Possibly. I may try to reroute the motors to different drivers and see how it does then.
-
@modest-orange have you tried adjusting the V roller tension/play? I have seen similar problems on an openbuild cnc due to the spindle tilting under load at the X axis roller. The long lever of the Z axis probably increases the effect.
-
@modest-orange said in Y axis Problems:
Any ideas or theories will be helpful and welcome.
A crazy idea from my side is that the energy chains are producing resistance at some point (joint bulky, cable length too short) and the movement jumps.
-
@pakue There was some play on the Z axis that I resolved by tightening up the tension of the rollers. I however don't believe this to be the problem as when the printer is not under any tension the motors will still move with the stutter. I'll try removing the belt and see if they still stutter under zero load.
@JoergS5 This could be possible. However I don't know exactly how to rectify that. Today I release all the cables from the cable chains and held them loosely separated during a print to now effect. As far as cables being too short I am currently using 7 foot cables on everything. Both Y motors have some extra wire that is bundled near the board normally.
I also woke up this morning thinking the cable chain was bumping but confirmed that to not be the case.
Thank you for all your suggestions and input!
-
SOLVED
I took the belt off of the Y motors to check to see what happens under no load. The 4 set screws for the Y motor gears were all loose. The error was caused by play in the belt gear (timing pully). After adding some locktite and assembling everything back together, I am printing circles again and any other shape without issues.Thank you for everyone who took the time to help me solve this one!
-
@modest-orange thanks for letting us know what it was.
