@o_lampe
I will try those (again), but normally those names are not used by klipper, instead it uses the internal GPIO pin names.

Update - No those definitely are the RRF specific remapped names, don't work outside of RRF.

@jens55 I'd be tempted to see if there is any flex in the mount for the bltouch, as that seems to be where my current toolhead design is getting fluctuations from.

One printer is seeing 0.001 fluctuations, while the other with all same except toolhead, 0.02

I'm trying to determine what the pin allocations are. Anyone able to assist with this?

In Klipper, I need to specify either the spi_bus pin or if for software spi, the spi sclk_pin, spi mosi_pin and spi miso_pin. I have the other pins already but unsure what these would correlate to. I have connected the wires to pins Labelled SPI_MISO, SPI_MOSI and SPI_SCK of CONN_SD on the wiring diagram. However, I will need the GPIO pin names, for example:

Drivers

| Drive | DIR pin | STEP pin | ENDSTOP pin | SPI EN pin |

|-------|----------|-----------|--------------|-------------|

| X | PD11 | PD6 | PC14 | PD14 |

Misc pins

| (DUET) Name | (Klipper name) Pin |

|-------------|---------|

| SPI0_CS0 | PC24 |

@o_lampe I'm not using the can toolboard with the duet 2 hardware directly. I am running klipper on a Raspberry Pi. The Can toolhead connects to a USB to CAN board which then connects tot he toolheat via the CAN interface. The UBS side of the USB to CAN board connects wiht the PI directly.

The duet 2 wifi was intended to run the bed heating and other steppers.

@dmandn Can any of the spi0 or spi1 pins be repurposed for SPI comms with the driver? (Asking as I don't think I can manually control these drivers).

@dc42 Klipper requires a separate definition for each driver and stepper, so that should be ok.
The driver apparently works with both 3.3v and 5v IO so should be ok there.

However, no SPI might make things a bit difficult though.

Hi everyone.

Hoping I can avoid buying new control boards and simply add 2 of these Mellow TMC5160 stepper drivers as found here: https://www.aliexpress.com/item/1005004229433552.html Does anyone know how to connect/wire these into a duet wifi? Doe I need another componenet in between?

I'm hoping to use these 5160 drivers for x and y/ab steppers on a voron 2.4. Then use the built in drivers for the 5 steppers. This leaves one leftover stepper fdriver onboard. I will use a canbus toolhead for extruder as running klipper.

As I am running klipper, this question is more relating to the hardware of the duet2wifi and not reprap firmware. I will sort the klipper configuraiton out once I know if this is possible and how to wire up.

Looking to reduce the number of wires in the moving loom between the toolhead and back of the printer/controller, etc. This is in hopes of reducing the mass and number of wires moving and bending regularly. Also hoping to reduce the number of wire related failures experienced.
I am in the process of obtaining multicore silicone wires that are claimed to be more flexible and longer lasting....let's see.

At present I need 23-25wires (without any shared) to handle the items on my toolhead, which are as below:
1x 2pin heater
1x 2pin thermistor
1x 2pin hs fan
1x 2pin 5015 part fan (possibly split out to 2)
1x 4pin stepper
1x 3pin xstop
1x 3pin fil runout
1x 5pin bltouch
....and possibly 2 further wires for leds.

I have a Duet 2 wifi and duex5.

I believe the +3.3v and gnd pins for the x endstop and filament sensor can be grouped together? (laser sensor) (ie gnd + gnd, v_in and v_in).

I believe instead of a GND, the +v_in for the fans can be grouped and the fanx_- is the control pin for the PWM fans? So that implies I should be able to group the V_fan connectors to one 24v source?

BLtouch requires 5v for servo and 3.3v for probe in pin? possibly can share gnd with endstops for probe in? Then separate gnd for 5v side?

Also, is the heater controlled on the + or -? Seems like they are also controlling the - side?

The PCBs I found around don't seem to provide the options I want. The latest stealthburner option mostly does, but is missing the pinout for the BLTouch.

Anyone know if I have the above in combos correct? Has someone already worked all this out previously?

Ok, this has now been resolved (at least on one printer. Will test on the others once I have rewired them).

To fix the issue, had to update firmware and rewrite the stop.g and cancel.g files. Guessing issue was somewhere in the old firmware or in those configs.

Updated to RRF3.4.4 (Sorry, the printers were in storage for months).
Cleared all entries in stop.g and started over.
Then found it would throw the heater fault on cancel.g but is now fine on stop.g.
Cleared cancel.g, then rewrote it calling stop.g with a couple calls before and it works now too.

On another topic, also found on very rare occasions to be breaking contact on the connector, even with new wires, new molex connector crimped, and new senso with appropriate connector. I have found this can be averted by fixing the connectors so they are not free to move around. ...I need to revise my cable management.

@phaedrux Yes, I will need to run more tests but will get an example from each from my printer tomorrow. Apologies for the slow replies. I only get to work with my printers on some weekends. My wife doesn't like me spending time with them XD

Interesting, I just tried a print from prusaslicer and did not get an error after..... Maybe I have my profile wrong in Cura. Will have a look and get back to you.

@owend Ok, I will try this and see if it helps. Thank you!

@phaedrux I'm using M0 in my slicer endcode.

Everytime I run stop.g I get a heater 1 fault, I can print with this printer fine and everything seems normal, until stop.g is called.

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.1 (2022-06-01)
Duet WiFi Server Version: 1.26

I think I have made a mistake in my stop.g code, but can't seem to find the issue. I have ruled out the tune played at the end, and can see that the temps drop away normally to around 65ish then it goes crazy. So guessing it is to do with turning the hotend off?

Note, this issue has carried through a firmware update and a temp sensor and wiring replacement.

Stop.g
; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)

M83 ; Relative extruder moves
G91 ; Relative positioning

G1 Z10 F3000 ; Lift gantry + nozzle 10mm
G1 E-10 F600 ; Retract 10mm of filament
; M702 ; Unload filament settings from tool
M117 "Retracted filament!"

G10 ; Retract
G1 E-5 F300 ; Retract 5mm filament to ensure clean homing on next run

G10 P0 R0 S0 ; Turn-off hotend
M116 P0 S50 ; Wait for temperatures to drop
M117 "Extruder cooled!"

; Turn off fan
M106 P1 S0 ;Turn-off extruder/HS fan
M117 "Extruder fan off!"

M140 S0 ; Turn off bed heater
M106 S0 ; turn off part cooling fan
M117 "Bed off!"

G28 X ; Home X
G1 Y330 ; Move head to rear left for complete bed & print access

M98 P0:/Macros/Tunes/Mario.g ; call Mario.g tune macro file
M81 ;Power Down to save power.

@o_lampe Interesting thought. I didn't notice any comms issues though. This was also repeatable, seemed to happen after repeating the same print from file about 3-4 times. I found if I run only 1-2 times then power cycle it seemed to avoid the purge issue. ...right up to the go crazy and disassemble a ball screw, break through a couple plastic end blocks, etc issue it experienced.

I have now obtained a new ballscrew and got it functioning again, checked all config files and do not see any issues in the config files nor the print gcode.

@phaedrux - Ah ok, I think I will do that, thanks.

@dmandn Understood, though on this printer I really don't want to be replacing parts again due to another catastrophic failure (kind of procrastinating about it). Is is ok to downgrade firmware? Feel like a stable release might be safer for now. ....checking docs as not been through firmware doco for a while.

@dmandn Ok, new ballscrew in, re-checked and re-terminated some wires.
X,y and z operating normally for respected homes. Home all also fine.

No file changes made, still pointing towards firmware at this stage.

Random move to back right of coreXY, after a few prints. Will then hover around in this space of approx 1x1cm and spew out filament quickly. To stop, power off, then back on and coordinate system restored and usually get a couple print from file runs before issue returns. Unsure of cause.

2nd issue, with no changes to config.g or bed.g files from previous firmware version, sometimes works fine, however on last two runs, run outside bed and crashed. Cannot test for cause as printer 'disassembled itself on last repeat before I got to the power switch.

Been running with same config files (except for updates when firmware notes showed changes required) since 3.2.

I am running a duet 2 wifi v.14, with duex5
BLV MGN Cube coreXY with 3 way kinematics (custom).
Printer has been running in same configuration, except new heater, thermistor and fan for last 24months or more. Though not used often as been waiting for parts.