Posts made by RandomFactoid

@dc42

I recently discovered that my IR probe starts behaving as if it's in digital mode after a while if i'm printing in an enclosure and/or the hotend is hot for enough time for the probe to warm up. And that's even though it boots as analog. The z probe is approx. 20mm away from the nozzle (probably 10-15mm away from heatblock with a silicone sock)..and I don't think the enclosure gets warmer than 40-45 deg.

Hi,

I am having issues with my Duex2 which I bought a long time second-hand (i.e. it's not the latest version board..mine says Duex5 V0.6). Photo of the board here: https://photos.app.goo.gl/rjVUtv8GfXj3SCFm7

Currently I have fan outputs used connected as follows:

Fan4 has a thermostatically controlled hotend fan (M106 P4 T60 H1 S255)
Fan5 has part fan (M563 P0 S"Hotend1" D0 H1 F5 and M106 S0)
Fan6 and Fan7 have LED strips.

Issues:

1. Fan3 is showing ~8.5 volts when on. Clearly something's broken..somewhere. Any clues where to start looking for problems ?

2. For some reason both Fan 5 and Fan6 (e.g. M106 P5 or P6) both control the part fan - as if their PWM overlaps. Interestingly if I set them both to a certain value, switching one off still runs the fan at a value of the other fan pins. Also dimming my LEDs connected to Fan6 doesn't work - it only controls the part fan. LEDs connected to Fan7 dim fine (e.g. M106 P7 S100).

Attaching my config.g:

G21 ; millimeter units
G90 ; absolute tool coordinates
M83 ; relative extruder coordinates

;; geometry ------------------------------------------------

M667 S1 ; corexy mode
M208 X0 Y0 Z0 S1 ; S1 = set axes minima
M208 X245 Y253 Z250 S0 ; S0 = set axes maxima
M574 X2 Y2 Z2 S0 ; endstops

M557 X25:225 Y25:225 S50 ; configure z probing grid for mesh compensation
; (not used normally, but configures probing for the graphical bed report)

M98 P"/macros/zprobe/use_mfast.g"
M98 P"/macros/zprobe/use_ifast.g"

;; drive ---------------------------------------------------

;; Motor layout:
;; E0 E1
;; YB XA
;; Z2 Z3
;; Z0 Z1

;;----------------
;V2.1

M584 X3 Y4 Z5:2:1:6 E0 ; motor bindings RCF
M671 X-58:-58:297:297 Y-5:341:341:-5 S15 ; Z drive positions RCF

;;--------------------

;M584 X3 Y4 Z2:1:6:5 E0 ; motor bindings RCF
;M584 X3 Y4 Z2:5:1:6 E0 ; motor bindings
;M671 X-57:-57:312:312 Y-17:308:308:-17 S15 ; Z drive positions RCF

;M671 X-57:312:-57:312 Y-17:-17:308:308 S15 ; Z drive positions

M569 P3 S1 ; X motor direction
M569 P4 S1 ; Y motor direction
M569 P1 S1 ; Z-- motor direction
M569 P2 S0 ; Z+- motor direction
M569 P5 S1 ; Z-+ motor direction
M569 P6 S0 ; Z++ motor direction
M569 P0 S1 ; E0 motor direction
;M569 P4 S1 ; E1 motor direction
;M569 P2 S1 ; E2 motor direction

M84 S3600 ; motor idle timeout
M906 I50 ; motor idle current percentage
M350 X16 Y16 Z16 E16 I0 ; set microstepping
;M92 X160 Y160 Z320 E604 ; set microsteps per mm for 0.9-degree steppers
;M92 X80 Y80 Z400 E263 ; set microsteps per mm for 1.8-degree steppers (Mobius1)
M92 X80 Y80 Z400 E534 ; set microsteps per mm for 1.8-degree steppers (Mobius2)
;M92 X80 Y80 Z160 E160 ; set microsteps per mm for 1.8-degree steppers

;; velocity, acceleration, and current settings are in these macros
M98 P"/macros/drive/xy_fullcurrent.g"
M98 P"/macros/drive/z_fullcurrent.g"
M98 P"/macros/drive/e_fullcurrent.g"

;; firmware retraction -------------------------------------

;; Choose one as your default:
;M98 P"/macros/retraction/quiet_nozhop.g
M98 P"/macros/retraction/quiet_zhop.g
;M98 P"/macros/retraction/pa_nozhop.g"
;M98 P"/macros/retraction/pa_zhop.g"

;; thermal -------------------------------------------------

M305 P0 X0 R4700 T100000 B3950 ; bed thermistor
M143 H0 S136 ; bed cutoff temp
M570 H0 T15 S180 ; heater fault timeout
M140 S-999 R0

M305 P1 R4700 T100000 B3950 ; tool 0 thermistor
M143 H1 S280 ; tool 0 temp cutoff
M570 H1 T15 S120 ; heater fault timeout

M305 P103 X2 S"Keenovo" R4700 T100000 B3950
M143 P100 H0 X103 A0 C0 S145

;M305 P2 R4700 T100000 B4267 ; tool 1 thermistor
;M143 H2 S280 ; tool 1 temp cutoff
;M570 H2 T10 S120 ; heater fault timeout

M106 P7 S0.2 ;Hotend LED
M106 P5 S0 ; part fan
M106 P4 T60 H1 S255 ; hotend fan
;M106 P2 S0 ; enclosure fan
;M106 P6 S1.0

;; M303 H1 S235 ; run autotune
;; M500 to save autotune results to config-override.g,
;; then move the heater config lines from config-override.g here.
;; (Delete them from config-override.g, or you will be confused when changing this file doesn't work.)
M307 H0 A300.4 C567.1 D1.2 S1.00 V24.1 B0
M307 H1 A473.4 C206.5 D9.1 S1.00 V24.1 B0

;; tools ---------------------------------------------------

M563 P0 S"Hotend1" D0 H1 F5 ; bind tool 0 to drive and heater
G10 P0 X0 Y0 Z0 ; tool offset
G10 P0 S0 R0 ; tool active and standby temp

;M563 P1 D1 H2 ; bind tool 1 to drive and heater
;G10 P1 X0 Y0 Z0 ; tool offset
;G10 P1 S0 R0 ; tool active and standby temp

;M572 D0 S0.1 ;Pressure Advance

M501

T0 ; activate tool 0

I was just told that GitHub is not very much looked at when it comes to firmware issues (posted the issue here just in case: https://github.com/dc42/RepRapFirmware/issues/266) ...so just want to check with @dc42 if there's anything else I could contribute to this ? I know you asked for Gcode...so just not to leave any unanswered questions, it was:

G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion

G1 Z0.100 F18000.000
G1 X50 Y50 F18000.000
G1 F2000
G1 X150 Y150
G1 X50 Y150
G1 X150 Y50

With pause.g having
G10
G1 Z+20 F6000

Overall - at any point, but it'll probably be hard to see the output while printing. Although try that in console - it might work.
Tbh your issue sounds exactly like mine, but, you're right, it's different if you aren't using G10 anywhere.

@p40whk what values does M207 return ?

@dc42 thanks to your suggestion about the simple gcode, I think I found the problem.

Apparently if you have G10 in your pause.g (or, I suppose anywhere in your Gcode) and have Z hop defined in M207, after cancelling the print (or, I'd guess, finishing it without unretracting), after starting a new print, z=0 becomes the value of the Z hop height in M207, because it zhops, the print gets cancelled or finishes and never actually zhops down to previous height.

I tested this by uncommenting G10 from my pause.g and the problem disappeared. I also tried setting M207 Z(random number) and after starting a new print, Z=0 is at a height of (random number) and actually you can jog the nozzle into negative numbers after stopping the print...and it goes right to the negative height of M207 Z value.

This seems like a bug in the firmware as Zhop height doesn't get cancelled after the print finishes without unretracting.

@dc42 will try to do that asap...maybe today.

I am using G32 gantry leveling on Voron 2.1 using 4 z steppers with corrections of 0.0x or 0.00x on each one after 3 passes.

I've seen at least 3 posts of this kind (one from myself) about this exact issue - Z height increment between subsequent prints. Don't think there was ever a solution but to babystep for the 1st layer (in my case for instance the Z babystepping required would be around 0.4-0.5mm) and then reset babystepping for the 2nd layer and magically 2nd layer comes back to normal layerheight. Interestingly, even though it prints in air, stopping the print and sending G1 Z0 sends the nozzle to the bed as it should be. I ended up migrating to klipper for this very reason, but reverted back as DWC/PanelDue were too much of a sacrifice

Can't wait for a solution. Btw, if it'd help with debugging, i'm happy to post my configs.

Hi,

I have an old Paneldue (I think it's v1.1) with a 4.2" (or 4.3?) screen that I'd like to use as my RPi2/3 screen. Is there a way to do that ? Tried googling if anyone managed to do that with the 4 pin cable, but couldn't find anything.

Thanks!

I found this thread that looks very similar to our issue, however it's not homing related.
https://forum.duet3d.com/topic/1042/z-as-reported-by-m114-increases-by-0-02mm-with-x-or-y-home-command

To be honest I'm not sure what to make of this, but it looks like a lead to our problem could be here. Perhaps the pros have some insight ?

I know several people, especially from Voron users, were having these issues. Shame they're not really being addressed. I heard there might be an issue how the duet actually looks at leveling a moving gantry to a static bed and am thinking whether the issue is coming from there.

I feel a few steps away from migrating to Klipper on a highly priced board such as the DuetWifi+Ex...which is a shame

I have been having similar issues. I didn't need to babystep for the 1st print as I had the printer quite well dialed in. However if I wanted to start a second print straight away after removing the 1st one, it'd print at a higher z height. Interestingly it would be ~0.5mm too high even if I tried re-homing the printer. What's also surprising is that doing a simple papertest yealds the same results as before the 1st print - the nozzle does go to the same height as usual. No clue why but it seems like for the 2nd print duet applies some weird offset.

Hi,

I've been using my IR probe quite successfully, but recently, i'd say out of nowhere, it only started working in digital mode (=2 flashes = no slow down when close to bed). It doesn't actually affect how my corexy's bed gets leveled, however i'd prefer the potential increased accuracy with the slow down. Is there anything I could do/troubleshoot ? I have 3 wires connected as suggested in the manual and, strangely, it did work recently and now it isn't.

Thanks

Update:

1. Apparently 8.5v is only on Fan3 terminal. Fan 4-7 is actually just below 12v which is acceptable.

2. Paneldue issue resolved. Found a bad wire in going from paneldue to the board.

I guess this can be marked as Resolved Unless someone have ideas why only Fan/Led3 is doing that

Thanks

Thanks for replying
@T3P3Tony I only had part cooling fan wires plugged in, however those didn't have an actual fan connected. So that's a no

Hi,

I i have been using my Duet Wifi on a delta for a while and recently moved it onto a new project (Voron2). I also had an unused Duex2 laying around which I wired up to the Voron2 as it uses >9000 steppers
I am not sure at what point it happened - whether some of the issues were there beforehand, however I am now facing a couple of them.

1. The fan/led output pins on the duex2 are producing 8.5v instead of 12v as chosen with the jumper. Similarly, choosing VIN with the jumper gives a voltage of ~20.8v (main supply is 24v). For comparison 'Always on fan' pins are getting 24v.

2. At some point after connecting an inductive probe (PN-08N) I found it to be non-functional...and eventually found it to be fried. Not sure at what point it happened. Interestingly, I think since that time my paneldue has been playing up. The buttons work as intended (eg homing, moving), however i am not getting any temperatures or other info on it.

All the steppers are working as intended btw.

Any clue where to start troubleshooting ? I suspect something's fried...just not sure where to start looking. I couldn't see anything obviously fried on the boards...but perhaps I didn't look in the right spots.

Any help is very much appreciated (got some time while waiting for a new inductive sensor ).

Some closeup pics of the boards (for versions, etc..) are here: https://photos.app.goo.gl/vSRK532aHwkHWrEa6

Thanks!

Can sorting by date also be implemented into PanelDue ? I normally upload my gcode straight from Cura (DuetRRF plugin) and if for some reason I need to stop the print, it becomes very difficult to find the right file on Paneldue to restart the print. So I have to either reupload (can take a while for big prints) or go to my computer and start from it.

Thanks