The SD card contains the configuration files. Almost never need to wipe it. The firmware is stored on the board itself. If you're having trouble accessing the board, after restoring the SD card, try this guide,
https://docs.duet3d.com/en/User_manual/Troubleshooting/Duet_wont_respond
Can you share your files and the results you're getting?
Can you share your homing files and an example gcode file?
I'm not sure we have docs specific to that type of setup, but I seem to recall a forum post with working example of it being done. I think it's common with vorons.
If you can share some more specifics we can probably work out how it should function.
@Anon1337 said in Delta with two motors per axis?:
Something along the lines that you can't home the machine with the encoders connected, correct?
I think you would just home in open loop mode.
@Anon1337 said in Delta with two motors per axis?:
6 motors, 2 per axis
Yes I think that's been done before, though I don't recall any with closed loop motors.
RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.1 (2023-08-31 16:19:24) running on Duet 3 MB6HC v1.01 (SBC mode)
Is it pause.g or Pause.g?
@ageis said in Duet bed not receiving power:
M950 H0 C"bedheat" T0
Which pin do you want to use instead?
Find the pin you want to use and look up it's name here: https://docs.duet3d.com/en/Duet3D_hardware/Duet_2_family/Duet_2_WiFi_Ethernet_Hardware_Overview#pin-names
Then replace "bedheat" with that pin name.
Can you try doing a wireshark capture during an upload that fails?
@secure said in Can't start a new print after finishing one..:
Second job crash.
Is it crashing during homing of the second job? Post your homing files?
Or is it crashing during the end gcode of the first job?
@nikscha said in CAN board not responding:
M122 of the borad:
Does it ever respond correctly to an M122?
When and where was the board purchased?
Makerbot endstop pin number Function Duet 3 IO_x pin marking Duet 2 endstop pin marking
1 VCC 3V3 3V3
2 or 3 GND GND GND
4 Output IO_x_IN STP
Unfortunately the pin markings on the Makerbot endstop board are hidden underneath the connector. Pin 1 is next to the long edge of the board that does not have the microswitch on it, and pin 4 is nearest the edge with the microswitch.
Can you see markings on the endstop indicating which pin is which?
If the description from the documentation matches your endstop pin 1 would be on the right side of the endstop in your picture with the red cable in it. Which based on the table should be VCC 3.3v, but you have that wired into the middle pin on the Duet connector, which is ground.
The blue wire in the middle should be ground, but you have it wired to 5v external.
Pin 4 with the green wire is signal and it looks like that one is correct.
So I think you're basically shorting the 5v rail.
So I think you should move the red wire to the 3.3v pin on the duet connector and move the blue wire to ground. But to be sure you should identify which pin is which on the endstop itself. You may need to lift up the white connector a little bit to see the silk screen printing under neath it. Or maybe they have it labeled on the back side.
I use the same endstops, so that style does work, but it sounds like they are wired incorrectly such that it's shorting, or drawing too much current.
Can you show a picture of it actually connected so we can see both ends?
@mynameisdev said in Independent X axis homing fails - one side overshooting:
I do have fixed endstops
If the endstops are fixed and you have no control over the trigger position you would need to use the split axis option. X/U so that each motor can move independently to the endstop and then make an adjustment move to return to square. You still need a way to determine what square is though so you know how much to adjust.
This page gives details on both options. It's geared towards the Z axis, but the principles are the same.
https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_auto_levelling
If you're still having some issues can you capture a video of the homing process in action so we can see what's happening?
Can you share an M122 and M122 B# from the Duet and 1HCL in question?
You should only use a split X / U axis for homing if you want to do skew correction and the endstops are fixed.
Instead use the combined endstops. M574 X1 S1 P"!^io0.in+!^io1.in"
Also make sure that the order of the endstops matches the order of the motors in M584 X0.0:0.1 If the order doesn't match you could see the problem you're experiencing.
Are you able to ping the Duet IP address when the print is paused?
@izeman said in BigTreeTech Graphic display on Duet Wifi:
@Phaedrux said in BigTreeTech Graphic display on Duet Wifi:
It's BTT that's claiming RRF support, what do they say?
I just saw this in the DOCs section and thought I could try it out. If you don't want to support BTT and other stuff, why not just state that, and delete that section?!
So it was the Duet3D claiming BTT has built in support and not BTT claming they had RFF support. Classic hen-egg problem?!
I asee, thanks. So it worked at one time, but no longer. We will update the documentation.
@raftaman said in Probing Errors with Prusa mk2.5s and PINDA sensor:
G28 Z Error: Homing file homez.g not found
When exactly are you getting that error?
It's BTT that's claiming RRF support, what do they say?
It still looks like over extrusion to me. Try reducing the extrusion factor to 90 or 95% and see if it helps.
Do you have a link to the display?
@gnatman said in Zstepper issue / fried chip?:
I think I fried the stepper chip on the z thats on the duet
What makes you think that?
@gnatman said in Zstepper issue / fried chip?:
Can I take the stpper from ZA and move it also to the duex5 or am I out of luck?
That depends if you have a free driver on the Duex5 or not. If you have a spare open, yes it's easy to move over.
Are these errors happening on motors with fixed wiring or wiring that moves with the print head?
The error message is saying that there may be disconnected wiring, perhaps even intermittent. So that would be the first thing to check.
It's unlikely that a firmware update would improve the situation if it's been working fine as it is.
Has the configuration changed recently?
@raftaman said in Probing Errors with Prusa mk2.5s and PINDA sensor:
G28 Z Error: Homing file homez.g not found
Do you have a homez.g file in your sys folder on the SD card?
