@guitartoys Thanks for posting. What Duet are you connecting it to? Can you take a picture of both ends of your cable in situ, and post it?

Ian

@3DPotter as Jay says, you would need to compile your own firmware to do that. The pins used are defined in file src/Config/Pins_DuetNG.h. A further possible complication is that the current code assumes that all step pins are on Port D, so if you swap a step pin with another pin that is not on Port D then a code change would be needed too.

@stellator Normally, the 'X' stepper is back right on a CoreXY, and the 'Y' stepper is back left. I think you have these the wrong way around.

I think it should be:
Motor XY - 'Y' motor - 1 goes to Duet2Wifi E0-Stepper (driver 3)
Motor XY - 'Y' motor - 2 goes to Duet2Wifi Y-Stepper (driver 1)
Motor XY 3 - 'X' motor - goes to Duet2Wifi E1-Stepper (driver 4)
Motor XY 4 - 'X' motor - goes to Duet2Wifi X-Stepper (driver 0)

So your M584 should be

M584 X0.0:0.4 Y0.1:0.3 Z0.5:0.6:0.7 ; set axis mapping

Then check the direction of movement for the motors, using https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_coreXY#testing-motor-movement, reversing the pairs of motors' direction as necessary.

Edit: I don't think it's 4WD problem, so long as the pairs of motors are working in the same direction as each other. Though it may be easier to get it working in 2WD first!

Ian

@dc42 very true, very true.

@Caveman-0 So would you able to find out is it the power supply or the board? Since I am having issues with Over-voltage and causing board to shut down. And hence wondering if it is the board that I need to replace or the power supply.

@CNCsimon

Thank you for your help

Was a pleasure … 🤓

@Amagatth Please create a new thread and include as much detailed information as possible. You can reference this thread if you think it's relevant.

@janjoh I use a simple macro to turn on and off the leds...

Definition in config.g

; LEDS M950 P1 C"e1heat" Q500 ;use heater 1 outupt for LED M42 P1 S1

macro LED ON/OFF

if state.gpOut[1].pwm == 1 M42 P1 S0 else M42 P1 S1

@dc42 Thank you very much. That's exactly what I was looking for.

@dc42 @gloomyandy Thanks to both of you for your help!

It's nice to see that the community here helps each other. This is no longer the case in many other forums

@droftarts
Thanks for responding!
To answer your questions in order:
Was the M569.5 command generated by the Closed Loop plugin?

Yes

Are you running in standalone or SBC mode?

Standalone

Is the SD card good (it could be the SD card can't cope with the speed at which the data is collected and written)?

Not entirely sure how to qualify an SD card for this? It is a 16GB SanDisk Ultra micro SD (I believe the stock card that came with the board but not 100% certain of that). It has been reformatted to eliminate the partition that the stock micro SD cards that come with the boards have.

Can you send M122 B# (where # is the CAN address of the 1HCL board) when the printer restarts, which may show the reason for the crash?
M122 Prior to reconnection
M122 Before Reset.png
M122 After Reconnection
M122 After Reset.png

@Woody78

Hat jemand eine Idee?

Ja. Lesen! In English, of course, so that the Duet community can contribute. Start with the official (and very good) documentation by Duet3D itself - for Z probes, there’s this one: Connecting a Z probe. For the Klicky probe, scroll to the bottom. Then, search the forum for ”Klicky” - you’ll find many threads on that.

One note on your specific question: for a switching probe, it is possible to attach it to any input connector. The Duet 2 came with some dedicated ports, but these assignments were alleviated and have mostly become obsolete. BUT: in order to pick up the Clicky, you must first home the printer, so you might consider using a conventional endstop for Z anyway. For probing, the Klicky is fine.

Another reason to use the dedicated probe connector on the Duet 2 is flexibility: whenever you would like to switch to some other kind of probe, that’s easy with the Z probe header, with some other ports: impossible.

Please send an email to warranty@duet3d.com and CC your reseller. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.

@droftarts Great! Thanks for the link. That help a ton. I haven't ruined mine yet, but I'm more than prepared to accept that I might. Failure is always an option.

@bpeters2 you can use can-fd with the mini 5+. The connection is a 2 pin molex.
You can also buy a little expansion board that adds 2 more drivers to the mini https://www.duet3d.com/duet3expansionmini2plus

@droftarts I do have crimpers. I used to do a lot of network cables back in the day. I have the tools/skills, I just hate those connectors. Home-Made, Pre-Made, or otherwise. I also don't want to have to unsheath a pre-made cable if I don't have to. Plus, a pre-made cable will end up costing almost as much as a big bag of connectors and won't end up lost in my bin-o-cables to be thrown away in 15 years when I finally dig through them. 🙂

@Phaedrux
Thank you. I currently use Cura 5.5.0. I will look over the several files that have exhibited this issue today but I run those same files on two other machines with no bed heater issues. Only this machine exhibits the unreported fault. That is the reason I believe it is something with this specific motherboard rather than the files. It does have driver0 damage; perhaps an EOS event hurt the processor.

Can anyone suggest any diagnostics I could run while printing that might catch this fault? I'm assuming there is a latch or memory location that holds the "heater active" data. Can that be monitored, and capture what's going on?

Yes Cura calls Reprap during file generation.

Can you show some photos of the setup and the fuse?

Have you verified your PSU?

Have you tried setting up a simplified arrangement with a single motor for testing?

@gloomyandy really interesting and a very good article! I have not seen it before.

Funny to see they first chose the ADS1263 but later moved back to the HX sensor. It does seem effective, but probing at 1mm/s is less than we aim for (we have a bed size of 600x500 with a probing grid of 11x11, (if we probe the entire bed)

Therefore we now plan to read the signal directly at the microchip

@dc42 Yes I do, thank you for checking.

Running into a couple of other smaller issues but I'm thinking its all config related.. I'll follow up with a new thread.

VB,