Hi,
Is there a list of (significant) changes between these 2 versions of the smart effector? I just bought one and it's 1.3 and I wanted to know if I was going to be missing out on anything important?
The only difference I (think I) can see from the documentation are that the position of the thermistor connector moved and that a micro-fit connector was added for the hotend.
Thanks!
Chris
That was my problem. Switched it to 5v and I am now happily printing.
@Phaedrux thanks, but not a huge deal. It was just a Creality motor and I've replaced it with a slightly better Tevo motor from the scrap pile and it works better than ever now!
@chrishamm I have a syslog that has the same gcode run twice in a row, once with no errors and then once with the errors. Hopefully the syslog is the "journal" that you were referring to. Either way, it's good to know that the error still occurs with the debug logging enabled.
@chrishamm Thanks.
I changed the log level to debug and reboot the PI to be sure everything was restarted. I see debug messages from the DuetControlServer and DuetWebServer in /var/log/syslog. If the error happens again (I fear the debug logging is going to change the timing that causes this to happen) should I attach the output of running "grep -i duet /var/log/syslog" to the github bug report?
(Let me know next week when you're back)
@chrishamm This problem is most definitely not fixed. Yesterday I had the error occur twice. FWIW, random and explained behaviour by the software used to control industrial machines is something that I think should still be investigated -- even if it's difficult.
Whenever I get the random error message, I click "Emergency Stop" in the interface and restart the job. I do so just to be on the safe side and since I know I'll have to click emergency stop eventually anyway because the print never terminates, and the interface fails to let me cancel it.
Yesterday, the error occurred in 2 prints jobs in a row (with an emergency stop in between). Memory corruption, while still a possibility, sounds very unlikely.
I did try to find a reproducible example by having macros running macros running macros, but I was not able to reproduce anything that doesn't involve actually running print jobs. One difference in my tests and the actual print jobs is that some macro invocations are generated by M401 / M402 gcodes. I see in the RRF code that when system macros are run, it takes not of that (runningSystemMacro). Is there any difference there that could be part of the problem?
@chrishamm Thank you but unfortunately I think that's not the (entire?) fix. Was it this commit that you were hoping fixed the problem?
I find that the error occurs more frequently on one of my machines so I upgraded it to 3.5.3 to test. I just had the error occur when starting a print. FYI:
I have 3 machines that were running 3.5.2 and I'm seeing errors with very different frequencies on these machines. The one I upgraded to 3.5.3 has the error occur 10% of the time. That machine has a EXP3HC board that runs a Y motor an U motor and an extruder. The second machine runs a toolboard and I see the error here less frequently (I don't have a percentage estimate but definitely less frequently). The last machine has yet to report an error and it doesn't use any CAN expansion boards.
I don't see anything interesting in the differences in the SBC. All three machines are running Raspberry PI 4 boards (the two that have had the errors are Rev 1.5 and the one that hasn't is 1.4). The most machine that most commonly has errors and the one that has never had an error are running Raspbian 10 and the one other is Raspbian 12.
9/21/2024, 4:12:58 PM Error: in file prepare-to-print.g line 32: unknown variable 'probing_temp'
9/21/2024, 4:12:58 PM Error: in file prepare-to-print.g line 34: unknown variable 'probing_temp'
9/21/2024, 4:12:43 PM Warning: Macro file has been started on channel File but none was requested
@chrishamm I was just browsing the "random restarts on mini" thread and wondered if my problems could be related. However, both of my machines are running Duet 3 Mini 5+ (Ethernet not WiFi).
Both machines have CAN boards attached. The one that encounters this error more frequently is using a EXP3HC and the other a TOOL1LC.
@chrishamm Here's a gcode file that I was running at around the time I last saw the error. I can't be sure it's the one I was running but the exact object probably doesn't matter given that the error happens before the print itself starts.
@chrishamm / @dc42 The two machines I am running 3.5.2 configs are:
https://github.com/crpalmer/3d-printing/tree/master/veho
https://github.com/crpalmer/3d-printing/tree/master/ender5
For whatever reason, it happens much more frequently on "ender5" (don't be confused by the name, all that is left of the original ender-5 is the frame). It doesn't happen all the time and I'm starting to wonder if it happens more frequently when it has been running for awhile (perhaps some kind of subtle memory corruption?). It did happen again yesterday:
9/10/2024, 6:27:28 AM Error: in file prepare-to-print.g line 32: unknown variable 'probing_temp'
9/10/2024, 6:27:28 AM Error: in file prepare-to-print.g line 34: unknown variable 'probing_temp'
9/10/2024, 6:27:12 AM Warning: Macro file has been started on channel File but none was requested
and like before after the print finished (including M2 in the end.gcode) the machine thought that the print was still running and it was impossible to cancel the print. I end up just doing an Emergency Stop when this happens.
@gloomyandy Yes, I normally use active-low endstops. The ones I bought recently were wired as active high and I just left them as-is. I just rewired them to make them active-low and that does indeed seem to have solved the problem (not that I understand how it was a problem...). Thanks!
I have successfully used dual independent y motors on multiple printers and just verified that one of these really is working correctly (homes each motor to the corresponding endstop).
A new printer that I've been commissioning looks to me to be configured equivalently doesn't work correctly. This printer homes and to whichever endstop is triggered first and never triggers the second one. I can verify that it's only using one endstop either by manually triggering it or even just by making the gantry very offset which then homes to the very offset gantry position.
Both the machine that is working and the one I'm having trouble with are running RRF 3.5.2 and both are based on Duet 3 Mini 5+ boards. The one that is working has the endstops and motors on a CAN connected board and the one that is not working is connected directly to the Duet 3 Mini 5+ (using the 2 stepper expansion board for these 2 motors) with the endstops also connected to the main board.
Given that I know the software works and I have verified it works, that only leaves the fact that I'm being stupid. Can someone tell me what I've done wrong here?
The output of M574 M584:
Endstop configuration:
X: high end switch connected to pin !121.io2.in, min interval 30ms
Y: high end switches connected to pins !io5.in !io6.in
Z: none
Driver assignments: X0.0 Y0.5:0.6 Z0.1:0.2:0.4:0.3 E121.0, 3 axes visible
and the full config.g is:
global includeDuplication = 0
global xMin = 0
global xMax = 625
global yMin = 0
global yMax = 600
global zMax = 600
global xCenter = 300
global yCenter = 300
global zprobe_x = 0
global zprobe_y = 75
global klicky_is_manual = true
global klicky_pre_x = 113.8
global klicky_pre_y = 180
global klicky_dock_x = global.klicky_pre_x
global klicky_dock_y = 220
global klicky_release_x = global.klicky_dock_x - 50
global klicky_release_y = global.klicky_dock_y
global klicky_servo_up = 1660
global klicky_servo_down = 575
global klicky_n_deploys = 0
global in_filament_error = false
G4 S2 ; wait for expansion boards to start
; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
; Drives
M569 P0.0 S0 ; D3 ; x
M569 P0.1 S0 ; D3 ; z1 (front left)
M569 P0.2 S0 ; D3 ; z2 (back left)
M569 P0.3 S0 ; D3 ; z4 (front right)
M569 P0.4 S1 ; D3 ; z3 (back right)
M569 P0.5 S0 ; D3 ; y2 (right)
M569 P0.6 S0 ; D3 ; y1 (left)
M569 P121.0 S1 ; D3 ; e
M584 X0.0 Y0.5:0.6 Z0.1:0.2:0.4:0.3 E121.0 ; set drive mapping
; Z leadscrew positions
M671 X-100:-100:680:680 Y70:530:530:70 S5
M92 X53.33 Y53.33 Z600 E680 ; set steps per mm (recommended; 690 orbiter)
M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation
M566 X600.00 Y600.00 Z240.00 E300 P1 ; set maximum instantaneous speed changes (mm/min)
M203 X24000.00 Y24000.00 Z600.00 E7200 ; set maximum speeds (mm/min)
M201 X1000.00 Y1000.00 Z500.00 E5000 ; set accelerations (mm/s^2)
M906 X1200 Y1200 Z1200 I30
M906 E900 I10 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
; Axis Limits
M208 X{global.xMin} Y{global.yMin} Z0 S1 ; set axis minima
M208 X{global.xMax} Y{global.yMax} Z{global.zMax} S0 ; set axis maxima
; Endstops
M574 X2 S1 P"!121.io2.in" ; configure active-high endstop for low end on X
M574 Y2 S1 P"!0.io5.in+!0.io6.in" ; configure active-high endstop for high end on Y
; Z-Probe
;M950 S0 C"io1.out" ; servo pin definition
M558 P8 C"^121.io1.in" H5 F200 T24000
G31 X{global.zprobe_x} Y{global.zprobe_y} Z6.55 P25
M557 X100:500 Y100:500 P9 ; define mesh grid
M376 H3
; Filament sensor (BTT SFS 2.0)
M591 D0 P7 C"121.io0.in" L3.024 R90:110 E9 S1
;M591 D0 P7 C"io4.in" P1 S1
; Accelerometer (toolboard), input shaping and pressure advance
M955 P121.0 I10 ; Z+ -> Y+ and X+ -> X+
m593 P"zvd" F38.5 S0.1
M572 D0 S0.05
; Fans (tool 0)
M950 F0 C"121.out1" Q250 ; create fan and set its frequency
M106 P0 S0 H-1 C"part" ; set fan value (off). Thermostatic control is turned off
M950 F1 C"121.out2" Q500 ; create fan and set its frequency
M106 P1 S1 T45 H1 C"hotend" ; set fan value (on). Thermostatic control is turned on
; Fans (board cooling)
M308 S10 Y"mcu-temp" A"MCU" ; defines sensor 10 as MCU temperature sensor
M308 S11 Y"drivers" A"Duet stepper drivers" ; defines sensor 11 as stepper driver temperature sensor
M950 F2 C"out5" Q500 ; create fan and set its frequency
M106 P2 S1 H-1 C"board" ; set fan value (on). Thermostatic control is turned off
M106 P2 H10:11 T32 C"board"; set fan 2 value
; Bed Heater
;M308 S0 P"temp0" Y"thermistor" T100000 B4734 C1.153746e-7 ; configure sensor
M308 S0 P"temp0" Y"thermistor" T100000 B3950 ; configure sensor
M950 H0 C"out0" T0 ; create bed heater output and map it to sensor 0
M307 H0 R0.212 K0.115:0.000 D9.15 E1.35 S1.00 B0
M140 H0 ; map heated bed to heater 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
; thermistor (e3d)
M308 S1 P"121.temp0" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor
M950 H1 C"121.out0" T1 ; create nozzle heater output and map it to sensor 1
; revo 40w
M307 H1 R3.488 K0.464:0.226 D1.62 E1.35 S1.00 B0 V24.1
M563 P0 S"E3Dv6" D0 H1 F0 ; define tool 0
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C
; Servo for klicky
;M950 S1 C"out6" ; assign GPIO port 1 to out9 (Servo header), servo mod
;M280 P1 S{global.klicky_servo_down}
; Miscellaneous
M912 P0 S0
T0
and homey.g:
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 Y+650 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F6000 ; go back a few mm
G1 H1 Y+10 F360 ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning
Also, if anyone has done this themselves, are there any suggestions/tips/best practices to accurately measure the offset between the two endstops?
All I was coming up with was printing a large square, measuring it as best I can and then doing some math to get the skew angle and therefore the correction. And then obviously repeat until it seems close enough because all the measurements and printing itself are approximate...