Posts made by p8blr

@dc42 I notice the issue tends to happen when it's at Z max, and I have some overtravel switches there that will estop the printer if there's an overtravel so I never get to see how far it moves. If the axis isn't homed, what is the value of that variable? I think this is a good point, I will look into it. Thank you.

Sometimes when I turn on my printer z starts moving down instead of up towards the nozzle and I have no idea why.

Duet 6XD
(6) 3HC
(2) 1XD
Sammy
Raspberry Pi 5 in SBC mode

Running 3.5.4 (although this error has persisted on other fw versions)

(7) Teknic Clearpath servos

; homez.g
; called to home the Z axis

if sensors.analog[0].lastReading < 155 || sensors.analog[1].lastReading < 95 ; if bed and chamber aren't hot enough
	M291 P"Probing when bed and chamber are below target temps may result in innacurate Z offset. Press OK to continue anyway." R"Low Temperature Warning" S3 T0

M18 Z	; disable in case teknic motors try to recover
G4 S1
M17 Z	; droftarts suggestion to enable then wait 1 second
G4 S1

M98 P"prepare.g"	; does everything necessary to enable motion and duet reset
if {global.errorFlag}
	M99 ; exit current file

M98 P"soundNotifyShort.g"
G4 S1	; not sure if necessary but used to work with this wait

M402						; retract probe
M98 P"uvHomeCond.g"			; home U and V if they aren't homed
G1 U0 V0 F999999			; retract tools

M98 P"condHomeXY.g"			; home X and Y if they aren't homed
if {global.errorFlag}
	M99 ; exit current file

if move.axes[2].machinePosition <= 10 	; ensure nozzle is at least 10mm from bed
	G91                					; relative positioning
	G1 H2 Z10 F400     					; lower Z relative to current position
	G90									; absolute posistioning
	
; test for servo error
M17 Z						; enable servos - this wakes up the servos so they are ready to accept commands
G4 S1						; wait - sending commands too early can cause missed steps and a servo error
M98 P"servoErrorZ.g"		; check for servo error
if {global.errorFlag}		; bail if errors
	M99 ; exit current file
G91							; relative positioning
G1 H1 Z-2 F500				; try moving z just a little bit upwards
M98 P"soundNotifyShort.g"	; beep
G4 S1						; wait - sending commands too early can cause missed steps and a servo error
M98 P"servoErrorZ.g"		; check for servo error
if {global.errorFlag}		; bail if errors
	M99 ; exit current file
G1 H2 Z2 F500				; move in positive z now that we know it's safe
M98 P"soundNotifyShort.g"	; beep
G4 S1						; wait - sending commands too early can cause missed steps and a servo error
M98 P"servoErrorZ.g"		; check for servo error
if {global.errorFlag}		; bail if errors
	M99 ; exit current file

; probe z
G90							; absolute posistioning
G1 X525.9 Y507.8 F20000		; go to middle of bed (was X625.9 Y607.8)
M106 P2 S255 				; turn on fans to clean bed
M106 P3 S255
G4 S0.1						; wait
G30							; probe z
M98 P"blinkWhiteFast.g"
M98 P"servoErrorZ.g"		; check for servo error
M201 Z1000					; default accel
M106 P2 S0 					; turn off fans
M106 P3 S0

M98 P"soundAlertShort.g"
G4 S1	; not sure if necessary but used to work with this wait
set global.errorFlag = false

config.g
driveSetup.g
variables.g

homez.g

homez.g calls the following:

airEstopObserve.g
blinkWhiteFast.g
condHomeXY.g

doorLock.g
duetResetEnable.g
homex.g
homey.g
prepare.g
servoErrorAll.g
servoErrorZ.g
soundAlertShort.g
soundNotifyShort.g
uvhome.g
uvHomeCond.g
vacVerify.g

@dc42 Are you aware of any issues using chamber or bed associated sensors for thermostatically controlled fans in the latest firmware?

Thanks

@Phaedrux Not easily, it's in a deployed system. The fact that it only doesn't work (runs all the time regardless of temp) when I assign it to the bed or chamber sensors seems telling though.

Edit: I did get it to work with daemon.g with an if statement, but it'd be cool if I didn't have to do that.

@Phaedrux 3.5.4

@Phaedrux Yes, on different boards. The reason I am trying to do this, is when I heat the chamber, I want to make sure that the electronics on the head are sufficiently cooled, more than just the Duet electronics, I also have a webcam on the head. I may try adding an if statement to the daemon.g to turn this fan on/off depending on the chamber temp if the thermostatic control is not an option.

@Phaedrux I tried that as well but I have the same issue of the fans running all the time.

@fcwilt said in Thermostatic controlled fans not working:

@p8blr

This is just a guess but sensor 0 is assigned to the bed heater and sensor 1 is assigned to the chamber heater.

Correct?

Perhaps being assigned to those non-extruder heaters, thermostatic control does not work as it does for extruder heaters?

Frederick

That is a good point, I tested assigning that fan to every sensor on my printer and the thermostatic control worked on each sensor, except the bed and chamber sensors. I wonder why that is?

@Phaedrux console.txt

My fan 6 and 7 run at 100% with this command for instance:
M106 P6 S0 H0 T50
or
M106 P6 S0 H1 T50
when those sensors report to be at room temp (25C)

However, when I change to any other temperature sensors (other than 0 or 1), it works properly. I can't find any issues with my config file, can you?
config.g driveSetup.g variables.g

Running 3.5.4 on 6XD with multiple 3HCs and 1XD in SBC mode with RPi 5

Thanks

@droftarts Thank you for your reply. I should have added more details; the reason I don't have the R parameter set to 0 is that I don't want to trigger a driver error just because the servo gets disabled. For example, I have safety switches on the printer doors that cut power to the servos when the doors are opened. So I suppose that I really only want the driver error to occur when a movement is commanded, but the servo is not enabled.

Thanks!

I'm using some Teknic servos with my Duet 6XD and have the alarm wires connected to a 3HC expansion board. The reason I have it wired this way is because of the way the Teknic servos output their alarm signal. It's not truly an alarm wire, it's referred to as a HLFB or "High level feed back" wire that can do various complicated things I, however, have it configured to switch on/off when the servo is enabled or disabled. If the servo is over-torqued, or misses steps, it will shut down for safety and become "disabled". This is the only useful configuration of the HLFB connection with regard to interfacing with a Duet. Because of it's functionality, I cannot simply connect it to the error pin on the 6XD, as the Duet firmware assumes the state of the pin is "OK" on startup (In which the Teknic servo is outputting a signal that states the motor is disabled, but not in shutdown) so when the servos become "enabled" the Duet firmware takes that switched signal as a driver error because it has now changed states. To combat this communication conflict, I have it configured as follows:

section of config.g

M950 J16 C"^121.io0.in"                   ; assign input for X HLFB+
M950 J17 C"^6.io0.in"                     ; assign input for Y1 HLFB+
M950 J18 C"^6.io1.in"                     ; assign input for Y2 HLFB+
M950 J19 C"^6.io2.in"                     ; assign input for Z1 HLFB+
M950 J20 C"^6.io3.in"                     ; assign input for Z2 HLFB+
M950 J21 C"^6.io4.in"                     ; assign input for Z3 HLFB+
M950 J22 C"^6.io5.in"                     ; assign input for Z4 HLFB+
M581 P16:17:18:19:20:21:22 T2 S0 R1       ; configure external trigger 2, active to inactive, when printing

trigger2.g

; this only exists b/c I had to use an additional 3HC to connect the HLFB outputs becasue the teknic motors only indicate servo enable & not in shutdown, and currently the firmware assumes the startup state of the error pin
; is NOT in an error state, so when the servo enables, the duet thinks it's an error.
; config.g configures the 7 servo HLFB pins and associates them with this trigger.
; the below code will check the status of the io.in pins and artifically raise a driver-error event for the coorospoinding servo
; servo enabled + not in shutdown = 0
; servo disabled | in shutdown = 1

if sensors.gpIn[16].value == 0  ; if x servo is disabled or in shutdown
    M957 E"driver-error" D0 B121    ; raise driver error event, driver 0, CAN 121, P???

if sensors.gpIn[17].value == 0  ; if Y1 servo is disabled or in shutdown
    M957 E"driver-error" D0 B0    ; raise driver error event, driver 0, CAN 0, P???

if sensors.gpIn[18].value == 0  ; if Y2 servo is disabled or in shutdown
    M957 E"driver-error" D1 B0    ; raise driver error event, driver 1, CAN 0, P???

if sensors.gpIn[19].value == 0  ; if Z1 servo is disabled or in shutdown
    M957 E"driver-error" D2 B0    ; raise driver error event, driver 2, CAN 0, P???

if sensors.gpIn[20].value == 0  ; if Z2 servo is disabled or in shutdown
    M957 E"driver-error" D3 B0    ; raise driver error event, driver 3, CAN 0, P???

if sensors.gpIn[21].value == 0  ; if Z3 servo is disabled or in shutdown
    M957 E"driver-error" D4 B0    ; raise driver error event, driver 4, CAN 0, P???

if sensors.gpIn[22].value == 0  ; if Z4 servo is disabled or in shutdown
    M957 E"driver-error" D5 B0    ; raise driver error event, driver 5, CAN 0, P???

This wiring scheme and code only sort of works. If something is being printed and a servo goes into shutdown, the trigger works and the print is paused. However, I have discovered an issue with this method, if something is NOT being printed, but the user is manually jogging an axis, homing an axis, etc. The shutdown signal is ignored. Does anyone here have a recommendation for how it could work in non-printing moves as well?

Thank you!

@dc42 How exactly do I modify the esteps/mm so that the plot crosses extrusion factor 1 at speed 0? I'm getting better results using a linear trendline, however, the issue I keep running into is this:

If I calibrate my esteps/mm at the slowest speed I use (1000mm/min for instance), then print some test prints at faster speeds, measure the widths, plot the results, my extrusion multiplier will always be off on the speed I calibrated at, i.e. if A = 0.0036, and I calibrated my multiplier to be 1 at 1000mm/min then my multiplier is now 1.0036 now at 1000mm/min.

@dc42 the steps/mm are correct. I have them set to the values specified by the extruder manufacturer.

Does this make more sense?

Book1.xlsx

• Print same part multiple times, only varying the print speed. (Two perimeter thick print, no infill)
• Measured the wall thickness several times, average them.
• Omit the 500mm/min speed because it is an outlier (may be a limitation of the pellet extruder)
• Theoretical bead width is 3.6mm, I take the nominal value (2*3.6mm) and divide it by the actual widths. This gives me an extrusion multiplier - I refer to it as the "corrective multiplier".
• Because I'm not using filament, my slicer has an arbitrary "filament diameter", I use the extrusion multiplier to recalculate a new filament diameter (Surface area * coefficient = surface area, solve for Diameter)
• I now create a new extrusion multiplier, based on the new extrusion multiplier at 1000mm/min being 1. This is calculated by taking the new nominal width, divided by the actual widths.
• I plot the extrusion multiplier vs the extrusion speed in mm/s (as specified in the M592 documentation) and apply a 2nd order polynomial trendline.

I end up with these coefficients:
M592 D2 A0.0047 B-0.00001 L1.29478

What is strange is that when I apply these, sometimes my extruder doesn't extrude at all.

Please let me know what you think. Thank you.

@dc42 I collected some data, but I'm not sure how to make an equation that fits the format. I can't set an intercept of 1. Was my mistake that I calibrated at my maximum speed?

I'm racking my brain trying to figure out how to make an equation that doesn't have a constant and I can't figure it out.

Marlin supports a constant:

@droftarts Can you explain or link me to an explanation of this equation: (1 + min(L, Av + Bv^2)) ?

I read through the forum posts linked in the M592 description but I still don't understand the theory behind that equation, let alone how to determine the A and B coefficents.

Thanks.

I've been testing a Dyze Pulsar and I've noticed that the print speed very much affects how much plastic exits the nozzle. I've done some testing by printing 3-inch cubes with the same profiles, but varying the print speed, weighed them. I came to the conclusion that as the speed increases, so should the extrusion multiplier. I've created fast/medium/slow printer profiles in Simplify3D V5 that work well. However, as I was trying to create a post-processor that would modify the extrusion distance based on the feed-rate, I wondered if this was a capability of the Duet?

@dc42 Interesting. Any idea on an estimated completion date on the feature request? Or maybe a workaround I could do instead? I want the user to be able to have a way out of a very long while loop.

Thanks.

@droftarts I updated to 3.5.3 and tested the code but no change, I then added a M400 like this below, and it still did not run the last few lines of code, line 11 & 12.

M98 P"soundNotifyShort.g"   ; beep
M42 P17 S1  ; set closing direction
G4 S1   ; wait
while sensors.gpIn[15].value == 1   ; while not fully closed yet
    M42 P16 S1  ; turn on motor
    M98 P"promptUser.g" ; give user opportunity to cancel
    if global.userPrompt == 1
        break
    G4 S1
M400
M42 P16 S0  ; turn off motor
M98 P"soundAlert.g" ; beep
M291 "Top cover is at max closed" S2

This code runs every line

M98 P"soundNotifyShort.g"   ; beep
G4 S1   ; wait
var myCounter1 = 5
while iterations <= 5
    M98 P"promptUser.g" ; give user opportunity to cancel
    if global.userPrompt == 1
        break
    G4 S1
M98 P"soundAlert.g"    ; beep
M291 P"end of code" S2

This code skips the lines after the while loop

M98 P"soundNotifyShort.g"   ; beep
M42 P17 S1  ; set closing direction
G4 S1   ; wait
while sensors.gpIn[15].value == 1   ; while not fully closed yet
    M42 P16 S1  ; turn on motor
    M98 P"promptUser.g" ; give user opportunity to cancel
    if global.userPrompt == 1
        break
    G4 S1
M42 P16 S0  ; turn off motor
M98 P"soundAlert.g" ; beep
M291 "Top cover is at max closed" S2