@phaedrux said in DuetWifi 1.01 Updated to 1.24 - No Z Axis after update:

@dirtybirdnj said in DuetWifi 1.01 Updated to 1.24 - No Z Axis after update:

I just commented out their contents

What did they contain?

I copied the contents of the files over to a scratch pad before I commented them out, here they are. I don't recall setting these up so it seems like something that was on the SD card that the previous firmware didn't run / care about? Not sure... either way I am elated that I had two successful prints tonight!

// deployprobe.g
; Probe deployment routine for Mini Kossel
M564 S0					; don't apply limits
G1 X25 Y93 Z40 F10000	; put probe arm next to belt
G1 X-5 F500				; move probe arm across belt
G1 X12 F1000			; move probe back
G1 X0 Y0 F10000			; move to somewhere sensible
M564 S1					; apply limits again


//retractprobe.g
; Probe retraction routine for Mini Kossel
M564 S0					; don't apply limits
G1 Z40 F10000			; raise head
G1 X-59 Y66 Z35			; move over the post
G1 Z7 F500				; push probe down on post
G1 Z35 F10000			; raise head again
G1 X0 Y0				; move to somewhere sensible
M564 S1					; apply limits again

After taking a look at these I can clearly see it's setting M564 S1 at the end of each which is prob what was causing the "axes not homed" errors! I commented out the M654 H0 in my config.g and it homes the Z with no problem now. These files also account for the "random" x+y movements that were happening with the homing process as well... mysteries solved and case closed.

This thread can be marked solved! Thanks again to @dc42 @Phaedrux for your help!

Hello,

I have a Duet 2 Wifi that's powering a Printrbot Simple Metal.

I currently use the web control UI 100% to control the printer.

I would like to have a few momentary push-button switches that I can use to make the printer run specific GCODE scripts. Here's the ones I want to set up so far:

1. Home All
2. Warm Hotend & Bed to standby temps
3. Pause
4. Resume
5. Firmware Reset / Emergency Stop
6. Start printing "newest" gcode file on SD card

I know it's possible to use some of the GPIO pins on the Duet for control of lights / LEDs and stuff but what I'm hoping to do is wire all these buttons to a raspberry pi, and have it send commands to control the Duet.

Any suggestions on taking advantage of the PanelDue pins vs sending commands over wifi and impersonating the duet web interface?

https://github.com/patrickkuo/PanelPi
https://duet3d.dozuki.com/Wiki/PanelDue

I found an interesting repo where someone seems to have done what I wanted by spoofing the web interface, but their project focus appears to be running a web UI and actuating controls based on that. I want to run a raspi in a headless / command line mode and read GPIO input, and then send commands to the Duet.

Eventually I would also like to use a multi-segment LED matrix to display the layer #, hotend temp, etc. I'd also like to be able to execute arbitrary post commands to send myself slack / sms updates (print is done, printer paused for material change etc) I basically need two things:

1. Get printer info every 60s
2. Send string with GCODE / Macro to run

Thanks!

Hello,

Yesterday I had a print lift off the bed and get stuck to my hotend. I caught it in time to remove the giant blob but while I was doing this the machine experienced some kind of fault and now the Hotend & Bed both read 2000C. I have tried turning the machine on / off with the bed / hotend sensors disconnected and it doesn't make a difference.... web UI still shows 2000C for both.

Additionally I tried searching how to reset heater faults... I found another thread that suggested M562 P1 and M562 P2
https://duet3d.dozuki.com/Wiki/Gcode#M562:_Reset_temperature_fault

This clears the "fault" display in the web UI, but when I power off / on again the fault returns.

Hello! I recently started having issues where my printer would brown out only when using the heated bed. I had been using the bed for many months happily but since a recent firmware update, it just wasn't cooperating. Most of the things I found googling this issue suggested replacing the wiring or PSU, so I figured now is the time for 24v.

I spent $20 on a 240W 10A 24v power supply and it totally fixed my browning out issues. Previously I would get "voltage low" errors until the brownout occurred, but it's now printing like a champ sticking around 24v.

Swapping out was pretty painless, the board accepts 12/24v readily, I had a small little circuit I made to make my bed sensor play nice with the duet and I put a small box I got off amazon that steps 24v down to 12v so I can keep printing now and fix this "less than perfect" thing later.

If you are still on 12v with your duet... upgrade! it's awesome! Heated bed reaches temp SO MUCH FASTER now... fans are louder which leads me to believe they were previously starved for power/voltage.

Hello,

I am working on making a drawbot style machine with an OpenBuilds XY kit and a duet 2. The kit I'm using uses standard NEMA 17s for the X and Y axis, but because it's designed for lasers and other minimal z-axis usage it has nothing to move the pen up and down.

Here's a pic of the kit for reference:

I do have a spare NEMA kicking around I could mount to the carriage, but one of the goals of this machine is to write as fast as possible. I'd prefer to just use a servo since I just need to move a small carriage up / down to control drawing and that would keep the weight of the stuff on the gantry down.

I'm planning on using this awesome design for a 1 axis pen holder, my thought is whether I use a servo or stepper it should be pretty easy to get one of these to "push down" the pen and have the rubber band in the design keep it up off the page while traveling.

I found a threads on here with suggestions and info:

• https://forum.duet3d.com/topic/4853/servos-as-axes - No servo Z-Axis support
• https://forum.duet3d.com/topic/132/servo-support-eventually/5 - Use a servo control board

The most promising one was suggesting using a sparkfun stepper controller board. This should let me move the servo to two distinct positions by turning a GPIO Pin on the duet on/off. Just wanted to get a second opinion that this sounds like a reasonable plan... I assume this means I'll have to have some custom "slicing" that uses different commands instead of G1 Z1, G1 Z1.0 etc. I have worked on some code that turns SVGs into GCODE so it shouldn't be too difficult as long as I understand the GCODE I'm replacing.

Please let me know if you have any suggestions or have done anything like this.

If you want to know what I'm drawing with the robot check out www.robotdrawsyou.com

@phaedrux said in DuetWifi 1.01 Updated to 1.24 - No Z Axis after update:

@dirtybirdnj said in DuetWifi 1.01 Updated to 1.24 - No Z Axis after update:

I just commented out their contents

What did they contain?

I copied the contents of the files over to a scratch pad before I commented them out, here they are. I don't recall setting these up so it seems like something that was on the SD card that the previous firmware didn't run / care about? Not sure... either way I am elated that I had two successful prints tonight!

// deployprobe.g
; Probe deployment routine for Mini Kossel
M564 S0					; don't apply limits
G1 X25 Y93 Z40 F10000	; put probe arm next to belt
G1 X-5 F500				; move probe arm across belt
G1 X12 F1000			; move probe back
G1 X0 Y0 F10000			; move to somewhere sensible
M564 S1					; apply limits again


//retractprobe.g
; Probe retraction routine for Mini Kossel
M564 S0					; don't apply limits
G1 Z40 F10000			; raise head
G1 X-59 Y66 Z35			; move over the post
G1 Z7 F500				; push probe down on post
G1 Z35 F10000			; raise head again
G1 X0 Y0				; move to somewhere sensible
M564 S1					; apply limits again

After taking a look at these I can clearly see it's setting M564 S1 at the end of each which is prob what was causing the "axes not homed" errors! I commented out the M654 H0 in my config.g and it homes the Z with no problem now. These files also account for the "random" x+y movements that were happening with the homing process as well... mysteries solved and case closed.

This thread can be marked solved! Thanks again to @dc42 @Phaedrux for your help!

@phaedrux

Can you try deleting the deployprobe.g and retractprobe.g files?

THIS WORKED The "random movements" issue has been solved! I didn't delete the files I just commented out their contents, but I'll prob remove them soon for good measure.

Still need to run M564 H0 before z-axis is unlocked, but I feel way more confidant about doing some test prints now that the machine is homing correctly and behaving as expected again.

@dc42

Do you mean you always need to run M564 H0 to home the Z axis; or only if you try to home the Z axis before X and Y have been homed?

Yes, this is exactly the case. Please see the screenshot above, I posted a log from the g-code console to document this.

Did you add the S2 parameter to the following command in homez.g as @Phaedrux said?

I did and the S2 allows for upward movement before the probe, but it still refuses to execute the G30 that does Z-probing unless I run M564 H0 first.

@phaedrux

First off thank you so much for your help with this!

Your G31 needs to define the X and Y offset between the probe and the nozzle.

!!!! wow lol seems like a critical thing to be missing... measuring this now and figuring out the distance

@phaedrux said in DuetWifi 1.01 Updated to 1.24 - No Z Axis after update:

I just occured to me now that it looks like you have a duet wifi but are running 1.24? I think you're eligible to upgrade further to 2.03 if you wished.

This was one part of the update that was super confusing, I wasn't sure if the Duet2 and the DuetWifi I have are directly compatible with the firmware offered.

The file I sent during firmware writing using BOSSA was Duet2CombinedFirmware.bin from what appears to be the latest release.

https://github.com/dc42/RepRapFirmware/releases/tag/2.03

@phaedrux

M558 is definiltey responding to the extra settings, but I still have to run M564 H0 to home the z-axis.

Additionally when it does run G30 it does one probe and then rises and dives again moving in x+y+z. In doing so it pushes up past the end-stops making bad noises even though it's already homed the x and y axes.

It seems like it's doing something after the probing, but none of the actions defined in any of the home_.g match what it's doing. What exactly happens when G30 runs and is it dictated by any of these files? Running G29 also causes the machine to push beyond its axes after x and y homing as well.

Here's the latest version of my config:

; Communication and general
M111 S1                            	; Debug off
M550 OldYeller				; Machine name and Netbios name (can be anything you like)
M551 Preprap                        	; Machine password (used for FTP)
;*** If you have more than one Duet on your network, they must all have different MAC addresses, so change the last digits
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED 	; MAC Address
;*** Wifi Networking
M552 S1					; Enable WiFi. Disabled for setup and testing. Enable once set up on your network.

M555 P2                           	; Set output to look like Marlin
M575 P1 B57600 S1			; Comms parameters for PanelDue

G21                                 	; Work in millimetres
G90                                	; Send absolute coordinates...
M83                                 	; ...but relative extruder moves

; Axis and motor configuration
M569 P0 S0                          ; Drive 0 (x motor) goes reverse
M569 P1 S0                          ; Drive 1 (y motor) goes reverse
M569 P2 S0                          ; Drive 2 (z motor) goes reverse
M569 P3 S0                          ; Drive 3 (ext motor) goes reverse
;M569 P4 S1                         ; Drive 4 goes forwards

M350 X16 Y16 Z16 E16 I1             ; set 16x microstepping with interpolation
M574 X1 Y1 Z0 S1		    ; set homing switch configuration (x and y switches, at low end, active high)
M906 X800 Y800 Z800 E800            ; Set motor currents (mA)
M201 X1000 Y1000 Z1000 E100         ; Accelerations (mm/s^2)
M203 X3000 Y3000 Z3000 E600         ; Maximum speeds (mm/min)
M566 X1000 Y1000 Z1000 E50          ; Maximum jerk speeds mm/minute
M208 X200 Y200 Z240                 ; set axis max and high homing switch positions (adjust to suit your machine)
M208 X-0 Y0 Z0 S1                   ; set axis min and low homing switch positions (adjust to make X=0 and Y=0 the edges of the bed)
M92 X80 Y80 Z400 E95                ; set axis steps/mm
G21                                 ; Work in millimetres
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves

; Thermistors
M305 P0 T100000 B3950 R4700 H30 L0	; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 B3974 R4700 H30 L0	; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
M305 P2 T100000 B3974 R4700 H30 L0	; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
M570 S180				; Hot end may be a little slow to heat up so allow it 180 seconds

; Fans
;M106 P1 H-1 				; disable thermostatic mode for fan 1

; Tool definitions
M563 P0 D0 H1 F0:1                      ; Define tool 0 - Heater 1, Fan 0 (extruder) and Fan 1 (bed fan)
G10 P0 S0 R0                        	; Set tool 0 operating and standby temperatures
M92 E663:663                       	; Set extruder steps per mm

; Z probe and compensation definition
;*** If you have a switch instead of an IR probe, change P1 to P4 in the following M558 command
M558 P5 X0 Y0 Z1 F100 T5000 H2	        ; Z probe is an inductive probe and is used for homing
G31 P1000 Z2			        ; Set the zprobe height and threshold (put your own values here)

;*** If you are using axis compensation, put the figures in the following command
;M556 S78 X0 Y0 Z0                   	; Axis compensation here
M208 S1 Z-0			        ; set minimum Z
;
T0					; select first hot end


;Enable pronterface?
M555 P2

;Enable Z-Axis because of dumb firmware
;M564 H0