@phaedrux @garyd9 in case you'd like a walkthrough of how the current TAMV runs voiced-over by yours truly, here you go: https://www.youtube.com/watch?v=1nGc_hFzK0s&t=5s
I've taken Danal's legacy (I was actually one of the early testers for TAMV over on the Jubilee discord where he started the project), and run full steam ahead with it to make it even more accessible to folks with toolchangers/IDEX machines running RRF. We've come a long way improving on his work, and there's more to come!
That's a really interesting observation and I'm going to run a few tests this week to see if I can find that sweet spot. Multiple speeds and perhaps even changing the chop register on the TMC might yield some improvement. Thank you!
Resurrecting this topic, as I just stumbled upon it..
TAMV has been updated recently (I'm maintaining the Jubilee branch), and has been significantly enhanced. It does automatic detection, semi-assisted detection (where you jog to a crosshair and click a button to calculate, capture, and apply offsets), selectable tool calibration (choose what tools get calibrated), and is now fully multi-threaded for faster execution. Klipper support is also in beta testing (its now an extensible program for any controller). Installing takes about 5 minutes on a pi, since it now uses pre-compiled openCV binaries.
Only thing you'll have a challenge with is IDEX support, as its currently limited to identifying X,Y and Z axes for alignment, where usually idex will require other axes. I haven't extended it to any axis you choose yet as its quite a bit of work, but it works great on Duet 2 and Duet 3 boards, and we're always around on the Jubilee Discord for any questions and help!
We're lacking a little of the fine details on how to run the software, as I haven't caught up with the docs writing yet.
Latest source (use the master branch please):
https://github.com/HaythamB/TAMV
General installation instructions (also on the GH repo):
https://jubilee3d.com/index.php?title=TAMV
Let me know if you want any info! 
semi-assisted mode looks like this.
Forgot to reply and close this out: running beta 2 now, seems to be alright, but the root cause was my hardware and not the controller or the firmware. A slight oversight on my end was definitely the culprit!
Cheers!
@Veti excuse me while I drive to Ben Nevis and take a leap off the top.
Fml, serious case of Dad brain this weekend. Sorry to waste everyone's time for something so damn trivial. I have never been more embarrassed.
@t3p3tony I've tried recreating it by removing the endstop connection, stalling the stepper during homing, etc. etc. but I can't seem to recreate the same error message I've had, and the printer still runs the Z home macro flawlessly. I'm honestly quite perplexed and chalking this one up to RRF beta gremlins 
Thanks for the help in all cases!
Resurrecting this topic, as I just stumbled upon it..
TAMV has been updated recently (I'm maintaining the Jubilee branch), and has been significantly enhanced. It does automatic detection, semi-assisted detection (where you jog to a crosshair and click a button to calculate, capture, and apply offsets), selectable tool calibration (choose what tools get calibrated), and is now fully multi-threaded for faster execution. Klipper support is also in beta testing (its now an extensible program for any controller). Installing takes about 5 minutes on a pi, since it now uses pre-compiled openCV binaries.
Only thing you'll have a challenge with is IDEX support, as its currently limited to identifying X,Y and Z axes for alignment, where usually idex will require other axes. I haven't extended it to any axis you choose yet as its quite a bit of work, but it works great on Duet 2 and Duet 3 boards, and we're always around on the Jubilee Discord for any questions and help!
We're lacking a little of the fine details on how to run the software, as I haven't caught up with the docs writing yet.
Latest source (use the master branch please):
https://github.com/HaythamB/TAMV
General installation instructions (also on the GH repo):
https://jubilee3d.com/index.php?title=TAMV
Let me know if you want any info!
semi-assisted mode looks like this.
@t3p3tony I've tried recreating it by removing the endstop connection, stalling the stepper during homing, etc. etc. but I can't seem to recreate the same error message I've had, and the printer still runs the Z home macro flawlessly. I'm honestly quite perplexed and chalking this one up to RRF beta gremlins
Thanks for the help in all cases!
U Axis failed to home due to a physical problem with the physical state of the U stepper (to skip over the details: it completely failed to home).
I have non-homed axes movement allowed in my config, so it shouldn't have impacted the movement of X and Y in the homez.g macro. I feel like it may have something to do with how macros are called when an error is triggered. For example, G1 error thrown in homeu.g, sent to console for display, but in the background the next macro is called and the first G1 command is skipped due to the error from the previous step. This may have been the case, but I'm not certain.
Also X and Y were at their endstops, so they definitely didn't move at all. You're right, its too late to check (and I'm not ready to try and recreate this event!) if DWC reported different coordinates for those axes..
@t3p3tony yes, that's the question. nothing for the firmware, config, etc. had changed.
The only thing that I can be sure happened during this whole event was that my U axis (for my tool lock) failed to home, and that threw off the Z homing macro's first couple of steps to move the carriage to the middle of the build plate.
That's about as far as I can tell. So the question would now be: Why was the error thrown and why did the macro fail to move the print head (I'm assuming the error is from line 9 of the homez.g: G1 X155 Y155 F42000
@o_lampe this config has been working for over 6 months without a hitch. Its just yesterday with the failed U axis home that I had the error, and the Z homing failed.
Also, why would I need H2 on Z-lifts? I'm using a 3xZ configuration and I'm moving the bed normally. What's your thinking behind this suggestion?
Hey all,
Oddest occurrence today: after completing a print successfully on my Jubilee toolchanger, I removed the print as usual, and then clicked the "Print Again" option on DWC. Lo and behold, my G28 ran the Y and then X homing sequence, and then started the Z homing sequence.
The carriage failed to move to the center of the bed, as defined in my homez.g, and as such, the bed kept raising and seeking the endstop (conveniently located nowhere near where its supposed to be) until the anti-backlash nuts popped right off. I did get a single message stating "Error: G1/G2/G3: intermediate position outside machine limits" but I'm unsure when in the cycle this appeared.
Picture for posterity's sake:
Machine had no tools loaded (I had just completed a print), and here's the relevant sections of my gcode file in the start and end portions that would be relevant to what the machine was trying to operate.
Only thing that I think could have happened is somehow my homeu.g failed to complete, but in that case, why didn't the machine move in X or Y, but continued to move in Z?
I can easily add some conditional gcode to handle checking if axes are homed, but I really think this might be some overlooked area of the codebase that triggered this odd (and potentially machine-destroying) condition..
Start of gcode file:
M104 S235 T2 ; set temperature
;TYPE:Custom
; babystepping (PLA 0.11; PETG -0.03)
M290 S-0.01 R0
M190 S55 R55
T0 P0
T1 P0
T2 P0
T-1 P0
; BEGIN: start custom g-code
G91 G1 Z5 ; drop bed slightly
G90 ; absolute positioning
G28 ; home all axes <---- this is where it failed.
M558 F400 S0.01
G32 ; tram bed
G32
G32
M558 F400 S0.01
G29
End of gcode file:
G1 X148.409 Y155.848 E-0.01371
;WIPE_END
G1 E-0.03 F3600
; stop printing object cable_clinger_v0.stl id:0 copy 0
M107
;TYPE:Custom
; Filament-specific end gcode
;END gcode for filament
M104 S0 ; turn off temperature for tool
T-1 ; unload tool
;G91 G1 Z10 G90
M0 ; call stop routine
M84 ; disable motors
stop.g simply calls cancel.g, which is here:
; cancel.g
; called when a print is cancelled after a pause.
T-1 ; park any active tool
M400
G91 G1 Z5 G90
G0 X-20 Y-20 F42000 ; return all motions to home
M140 S0 ; turn off the bed heater.
M84 S600 ; disable motors after 10 mins of inactivity
homeall.g:
; homeall.g
; called to home all axes X Y Z and Toolchanger lock
;
G91 G1 Z5 F800 H2 ; Lift z so we don't crash
M98 P"homey.g"
M98 P"homex.g"
M98 P"homeu.g"
M98 P"homez.g"
homey.g:
; homey.g
; called to home the Y axis
; make sure everything has stopped before we make changes
M400
; Set relative mode
G91
G1 Y-400 F6000 H1 ; Big negative move to search for endstop
G1 Y4 F600 ; Back off the endstop
G1 Y-10 F600 H1 ; Find endstop again slowly
; set absolute mode
G90
homex.g:
; homex.g
; called to home the X axis
;
M400 ; make sure everything has stopped before we make changes
G91 ; Set relative mode
G1 X-400 F6000 H1 ; Big negative move to search for endstop
G1 X4 F600 ; Back off the endstop
G1 X-10 F600 H1 ; Find endstop again slowly
G90 ; Set absolute mode
homeu.g (toolchanger lock axis):
; Home U Axis
G91 ; Set relative mode
G1 U-100 F6000 H1 ; Big negative move to search for endstop
G1 U6 F600 ; Back off the endstop
G1 U-10 F600 H1 ; Find endstop again slowly
G90 ; Set absolute mode
and finally, homez.g:
; Home Z Axis
; Set acceleration for travel moves
M204 T10000
; Lift z so we don't crash
G91 G1 Z10 F800 H2 G90
; Move to the center of the bed
G1 X155 Y155 F42000
; Set the probing speed
M558 F500
; run probe 1
G30
; Set a slower probing speed
M558 F100
; run probe 2
G30
relevent entry from log file:
2021-11-02 20:20:31 [warn] Started printing file 0:/gcodes/cable_clinger_v0.gcode
2021-11-02 20:21:10 [warn] Leadscrew adjustments made: -0.072 -0.063 -0.030, points used 4, (mean, deviation) before (-0.056, 0.112) after (0.000, 0.111)
2021-11-02 20:21:29 [warn] Leadscrew adjustments made: -0.055 -0.051 -0.052, points used 4, (mean, deviation) before (-0.053, 0.114) after (0.000, 0.114)
2021-11-02 20:21:49 [warn] Leadscrew adjustments made: -0.052 -0.058 -0.056, points used 4, (mean, deviation) before (-0.056, 0.110) after (0.000, 0.110)
2021-11-02 20:23:12 [warn] 25 points probed, min error -0.155, max error 0.081, mean -0.017, deviation 0.060
Height map saved to file 0:/sys/heightmap.csv
2021-11-02 20:36:20 [warn] Finished printing file 0:/gcodes/cable_clinger_v0.gcode, print time was 0h 15m
2021-11-02 20:41:28 [warn] Started printing file 0:/gcodes/cable_clinger_v0.gcode
2021-11-02 20:41:50 [warn] Error: G1/G2/G3: intermediate position outside machine limits
2021-11-02 20:42:10 [warn] Cancelled printing file 0:/gcodes/cable_clinger_v0.gcode, print time was 0h 0m
2021-11-02 20:42:10 [info] Event logging stopped
config file attached for reference: config.g
@phaedrux @garyd9 in case you'd like a walkthrough of how the current TAMV runs voiced-over by yours truly, here you go: https://www.youtube.com/watch?v=1nGc_hFzK0s&t=5s
I've taken Danal's legacy (I was actually one of the early testers for TAMV over on the Jubilee discord where he started the project), and run full steam ahead with it to make it even more accessible to folks with toolchangers/IDEX machines running RRF. We've come a long way improving on his work, and there's more to come!
Forgot to reply and close this out: running beta 2 now, seems to be alright, but the root cause was my hardware and not the controller or the firmware. A slight oversight on my end was definitely the culprit!
Cheers!
Hey guys,
I am running RRF3.3beta1 on a Duet 2/ Duex 5 Jubilee toolchanger, and I've noticed a really odd occurrence with how macros are called from gcode.
In my tpost.g, I have a sequence of commands that also includes calling a "tool_lock.g" macro to actuate my U-axis locking mechanism. Now this has always run just fine on every single stable RRF release since 2.0.5, and was running smoothly on 3.3beta1, until now.
Several times today, on multiple gcode files, it seems like the Duet isn't calling the tool change macro "tool_lock.g" from the tpost file. All the other commands in my tpost are being executed flawlessly, but it seems like running a custom macro has some sort of buffer glitch. My M122 report (attached ofc) states an error code of 0x0C, which could be both buffer errors being triggered (since there's nothing wrong with the SD card apparently).
I've triple-checked for any wiring issues, of which there are none, and manually running the macro from my PanelDue is flawlessly executed every single time. Its only when I call the macro "tool_lock.g" from the DWC console using the M98 command from the tpost that I get a weird pause in DWC, as if its churning away in the background to execute what I've inputted.
Event log is clear, nothing happening there. The only indication (other than the failure to lock my tool) is the error code in the M122 output. I'm stumped.
Any ideas?
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3beta1 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MS4-7J1F0-3S46R-KGS4D
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 21448
Dynamic ram: 77604 of which 60 recycled
Never used RAM 12968, free system stack 96 words
Tasks: NETWORK(ready,229) HEAT(delaying,310) DUEX(notifyWait,23) MAIN(running,293) IDLE(ready,19)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:15:12 ago, cause: power up
Last software reset at 2021-03-11 18:16, reason: User, GCodes spinning, available RAM 12968, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x0c
Aux0 errors 0,0,0
MCU temperature: min 19.1, current 34.4, max 34.6
Supply voltage: min 24.1, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 40770, ok, SG min/max 0/1023
Driver 1: position 5275, ok, SG min/max 0/1023
Driver 2: position 9373, ok, SG min/max 0/1023
Driver 3: position 0, ok, SG min/max 0/1023
Driver 4: position 0, ok, SG min/max 0/1023
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, ok, SG min/max 0/1023
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-03-11 22:22:02
Cache data hit count 936346140
Slowest loop: 135.66ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.2ms, write time 149.5ms, max retries 0
=== Move ===
DMs created 83, maxWait 95560ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 10794, completed moves 10761, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 3 is on, I-accum = 0.7
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 F7200.000" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is not empty:
Queued 'M106 S247.35' for move 10783
1 of 16 codes have been queued.
=== DueX ===
Read count 1, 0.07 reads/min
=== Network ===
Slowest loop: 157.77ms; fastest: 0.00ms
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.25
WiFi MAC address 60:01:94:2e:9f:97
WiFi Vcc 3.39, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 26616
WiFi IP address 192.168.1.202
WiFi signal strength -57dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 2 0 0 0 0 0 0
So yes the code is fetching rr_reply after each call before disconnecting.
And the 0x0c error is what shows up for the Duet Error code in the M122 output.
I've been able to work around this issue by waiting in the code until the buffer size is greater than 150, which seems to work so far in my testing, but I'm still not clear on why I'm having these issues.
What do you recommend I try next?