Engineering student and 3D printing adict
@dc42 Here is the updated Retract macro from line 14 of my original post:
M400; clear the command buffer
M280 P1 S{global.retract_angle}
G4 P400; wait for purge bucket to fully retract
Before adding in the M400, the M280 P1 command was being executed between lines 7 and 8. I don't know if the dwell was being executed early.
@gloomyandy Also, do you know how if statements are handled by the command buffer? As in are commands inside of an if statement body queued from outside, or does the firmware hold off on queuing them until the condition of the if statement is evaluated?
@gloomyandy Yeah that seems to be working. I was playing around with putting M400 commands in various spots, and it seems that for them to be effective, they need to be right before the M280 command that moves the purge bucket.
Still, it seems weird that the printer is looking forward inside of another macro and executing an M280 command 10 or so lines early.
Anyway, thanks for your help!
I have a printer that I have been building while in school that has a two-into-one extruder set up, running off of a Duet Maestro. I'm running fw version 3.4.1. I have added a purge bucket for filament swaps that is servo actuated. It's been working, but I've been tweaking things, and something I did messed things up.
Here is that macro:
; called from tfree#.g macros
if state.currentTool == 0 || state.currentTool == 1; if a tool is active:
set global.fan_speed = fans[0].requestedValue; store current fan speed (do this before tool change because PrusaSlicer emits the new fan speed command before actually changing tools)
M106 S0; turn off fan
M98 P"0:/macros/Tool Changing/Purge Bucket/Deploy"; move into position/deploy purge bucket
G1 E30 F150; purge
G1 E10 F270; fast purge
M106 S255; turn on fan to cool blob
G1 E-140 F840; immediately retract filament (140/840)*60 = 10 seconds cooling
G1 X128 F60000000; scrape nozzle
M106 S0; turn off fan
set global.blob_detected = false; reset
M98 P"0:/macros/Tool Changing/Purge Bucket/Retract"; retract purge bucket/dump blob
else; if no tool is active:
echo "cannot purge when no tool is selected"
Line 14 is being executed between lines 7 and 8.
Could this be caused by commands being added to the command buffer before the condition of the if statement is evaluated or something? Any help appreciated, and I can supply the other macros being called if needed.
Edit: messed up line numbers in original post
@Phaedrux yes that was immediately after running the macro and seeing the motor stall.
I don't understand why the fix works, but it works, so I'm happy (enough)!
@Phaedrux thanks for the reply!
Here's the output from the M122 command:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.05 running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LL3T0-6JKD6-3S86P-TV22P
Used output buffers: 3 of 24 (8 max)
=== RTOS ===
Static ram: 19804
Dynamic ram: 87332 of which 24 recycled
Exception stack ram used: 324
Never used ram: 23588
Tasks: NETWORK(ready,1220) HEAT(blocked,1272) MAIN(running,4192) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:01:11 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 23544 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04418000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 38.3, current 38.9, max 39.5
Supply voltage: min 0.0, current 12.7, max 12.8, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, read errors 0, write errors 1, ifcount 124, reads 16064, timeouts 0
Driver 1: standstill, read errors 0, write errors 1, ifcount 124, reads 16062, timeouts 2
Driver 2: standstill, read errors 0, write errors 1, ifcount 179, reads 16063, timeouts 1
Driver 3: standstill, read errors 0, write errors 1, ifcount 127, reads 16062, timeouts 0
Driver 4: standstill, read errors 0, write errors 1, ifcount 254, reads 16062, timeouts 1
Driver 5: standstill, read errors 0, write errors 1, ifcount 109, reads 16062, timeouts 0
Driver 6: standstill, read errors 0, write errors 1, ifcount 120, reads 16064, timeouts 0
Date/time: 1970-01-01 00:00:00
Slowest loop: 1.72ms; fastest: 0.05ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 156, MaxWait: 12706ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 5, completed moves: 5, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 7.06ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
After the diagnostic I did go ahead and change the microstepping, and it seems to have solved the problem, although I don't understand why. My understanding was that the drivers on the Maestro interpolated x256 anyway. Am I missing something?
Also, why didn't it skip steps at full speed, but then it did during the deceleration phase of the move?
Thanks again!
Edit: Just to clarify, the diagnostic was performed before changing the firmware, right after witnessing the motor stall.
My machine uses two bowden extruders which feed into a y-splitter, which then feeds into a direct-drive extruder on the print head. This way i can print with dual extrusion. I have a simple macro which I use to load filament into one extruder or the other before a print.
At any given point in time, there are two extruders pushing the filament in series. So in the macro, one of the bowden extruders grabs the filament, feeds it for a while through the bowden tube, and decelerates a little ways before the hobbed gear in the print head. At this slower speed, the direct drive extruder can more easily grab onto the filament. Once this has been achieved, the extruders speed up again to advance the filament up to the nozzle, decelerating again as the filament approaches it.
The direct drive extruder always stalls during the first deceleration move of the macro, but nowhere else. At this point there is no load on it, since the filament hasn't reached it yet. The second deceleration move doesn't cause a stall, and it never stalls during an actual print.
Since this might be important for figuring out what's going on, that direct drive extruder is a NEMA 11 with a 9-to-1 gear ratio.
This is the gcode for the load macro:
M201 E10
G1 E10 F120; grab filament
G1 E600 F1200; quickly advance
G1 E13 F120; slowly advance past extruder 2
G1 E55 F1200; quickly advance up to nozzle
G1 E20 F120; slowly extrude
M201 E500
Video of the phenomenon on imgur:
Here is my config.g file:
What's causing this stall, and how to I prevent it?
Thanks y'all!
@Danal It's good to know that wiring in series is an option, but I want my tool change macros to work even if somehow the filament changer is out of alignment or if I'm just starting the machine. For example, suppose I call tool 0, which is on the left side of my printer. If the filament changer is already at the left endstop, I want it to move off the endstop to the right first, then go back to the endstop. If it's sitting at the right endstop, I would like it to just move to the left endstop without moving to the right first. As far as I understand, RRF3 allows you to do this with conditional statements. But if both endstops are wired in series, there's no way of knowing which of these options to choose without prior information.
@dc42 is this a viable method of tricking the firmware into having min and max endstops?
M584 U6 V6
M574 U1 V2 S1
@Danal So assuming I wired two NC endstops in series, my config file would look something like this?
M584 U6 ; use drive 6 for the U axis
M574 U1 S1 ; U axis endstop on low end, active high
What about if I wanted to use two separate limit switches? Would this work?
M584 U6 V6
M574 U1 V2 S1
Then I could create homing files for the U and V axes, where "home U" is move to the low end and "home V" is move to the high end. Then I could put in an if statement (in the homeu.g file) where while homing U, it will back off of the endstop if it's already triggered, but not if it's already away from it.
Is there any reason this wouldn't work?