Posts made by DavidSimcock

@t3p3tony I took it from the Ooznest Workbee configuration that I had on a duet 2 wifi, and adapted it for the parameters of my machine. Why there should have been those kinematis commands I don't know. And I confess to not really understanding why there were 4 entry's...

@davidsimcock The issue does seem to be resolved with changing the kinematics M669 command.
A BIG THANKS to all who have made suggestions to resolve the issue. It is much appreciated.

@dc42 said in Duet 3. ? faulty Driver0. Post requested by Duet:

@davidsimcock from your config-axes.g file:

; Axes configuration executed by config.g
M584 X0.0 Y0.1:0.3 Z0.2:0.4
...
M669 K0 X1:0:0:0 Y0:1:0:1 Z0:0:1:0

You are defining 3 physical axes but your M669 command assumes 4. Try changing the M669 command to this:

M669 K0 X1:0:0 Y0:1:0 Z0:0:1

Right...I've revised the M669 as suggested. Homing now functions as it should, with the x axis motor holding torque. Thanks for the suggestion!

@phaedrux said in Duet 3. ? faulty Driver0. Post requested by Duet:

After homing is complete can you send M906 and M913 by itself and report back what it says?

Another thing to try is to completely backup your current config, remove it all, and start with a fresh basic config from the online tool.

https://configtool.reprapfirmware.org/Start

Thanks. Here are the M906 and M913

M906.txt

M913.txt

@t3p3tony said in Duet 3. ? faulty Driver0. Post requested by Duet:

@davidsimcock I would rename the current homey.g to homey.g.backup then make a new homey.g with the contents above. then yes G28 X, then G28 Y

OK...I've done that. The result is that the x axis motor is de-energised at the end of the process.

@t3p3tony said in Duet 3. ? faulty Driver0. Post requested by Duet:

@davidsimcock ok so something is causing the X axis to loose its holding torque as part of the Y homing.

Can you try the following minimalistic homey.g temporarily.

; homey.g
; called to home the Y axis

G91 ; relative positioning
G1 H1 Y1500 F1500 ; move quickly to Y axis endstops and stop there (first pass)
G1 Y-3 F150 ; go back a few mm
G1 H1 Y1500 F150 ; move slowly to Y axis endstops once more (second pass)
G90 ; absolute positioning

Caution this file no longer homes homes Z as part of the Y move so please ensure the Z axis is in a safe position before running it.

The idea is to see if the X axis is still disabled if X is homes first, then Y homed. both as individual moves. (so homeall.g is not modified yet.)

Just to check Tony...are you suggesting I suspend all the commands in my homey.g and paste your commands beneath? Followed by sending homex.g and following this with sending homey.g ?

@t3p3tony said in Duet 3. ? faulty Driver0. Post requested by Duet:

@davidsimcock said in Duet 3. ? faulty Driver0. Post requested by Duet:

@t3p3tony
re stalling...I cannot stop the movement with even strong pressure.
In the process of trying this I have more information though. When the x axis is homed (homex.g) independently of the y axis, the x axis motor holds torque after the homing sequence. When the y axis is subsequently homed (homey.g), holding torque disappears from the x axis motor. I hope I have explained that adequately.

Hi David, that's interesting. what happens if you reverse the sequence, from startup, first home Y, then home X I note that Z is home in both those individual files.

In the above case, i.e homey followed by homex, the x axis motor retains it's holding torque.

@dc42 said in Duet 3. ? faulty Driver0. Post requested by Duet:

@davidsimcock the G92 commands in your homing files are redundant, although I don't see how they would cause this problem. The M584 P3 command in homey.g also appears to me to be redundant. What happens if you remove all those G92 and M584 commands?

Thanks dc42. Suspending those commands, unfortunately, makes no difference.

@dc42 said in Duet 3. ? faulty Driver0. Post requested by Duet:

@davidsimcock where in those files do you use M906 to set the motor current?

M906 is set in the config-axes.g

@t3p3tony
re stalling...I cannot stop the movement with even strong pressure.
In the process of trying this I have more information though. When the x axis is homed (homex.g) independently of the y axis, the x axis motor holds torque after the homing sequence. When the y axis is subsequently homed (homey.g), holding torque disappears from the x axis motor. I hope I have explained that adequately.

@t3p3tony
No stalling at all. The homing move is completed. Thereafter minus X movements do not happen (the DWC reports that the x position HAS changed according to the request). And the x motor is no longer energised (sorry for repetition).
Changing to Driver5, and everything behaves as would be expected.

@t3p3tony
config-user-settings.g

config-override.g

@t3p3tony

config-network.g
config-drives.g
config-axes-limits.g
config-probe.g
config-spindle.g
config-laser.g

M917 with x axis on Driver0.txt
M917 with x axis on Driver5.txt

Thanks Tony

David

@t3p3tony
"What is slightly confusion for me is it sounds like your homeall process is working, but then after homing has completed the axis is then not powered. Is that an accurate description?"
Exactly so Tony.

"When you are homing X is there an error or warning in DWC?"
There is neither error nor warning displayed.

M122s below

M122 with driver0 for x axis after homing.txt

M122 with driver5 for x axis after homing.txt

Thanks
David

Ooznest supplied me with a Duet 3 Mainboard on 17th March. They request that I post the issue here, so that a replacement board (if that is what is needed) can be authorised. See text to Ooznest below:

"Hi
Referring to the below order, I have an issue with the Duet 3 mainboard, which I will attempt to describe below.
I have configured the Duet 3, using your excellent Workbee software as a starting point. I have a reasonable degree of experience with the firmware as I have for a few years been an owner and user of one of your machines, with a Duet 2 wi-fi.
Anyway, the issue is that when I perform a home all process, at the end of the homing process, the x axis motor is no longer energised and has no holding torque – i.e I can rotate the x axis ballscrew by hand. The other axes are held rigid by their stepper motors. I have spent a couple of days troubleshooting this, assuming there was an error in the configuration. I would add that I have tried different motors but the issue persisted.
Eventually, I tried connecting the x axis motor (which was connected to Driver 0) to Driver 5, and making appropriate changes to the drive mapping. The issue was resolved.
So, I suspect Driver 0 is faulty, and should this be the case, I would of course be grateful if you would exchange the board.
I have attached my configuration files in case they are of any help. These are prior to swapping to Driver 5
You are welcome to call me on 07850084600 if you need clarification.
I look forward to hearing from you.
Many thanks
David Simcock"

config.g
config-axes.g
config-axes-endstops.g
homeall.g
homex.g
homey.g
homez.g

Ooznest order.pdf

I look forward to hearing from you.
Thanks
David Simcock

Hi,
I hope someone can point me in the right direction with a couple of things.
I am adding a rotary axis (parallel with the Y axis) to my 3 axis router (ooznest OX). The xPro controller s which I‘ve had for a few years seems unable to be adapted to the task. I think I will need 5 stepper motor outputs (for X, Y, Z, Y slave, A axes) and it appears that Duet 2 will fit the bill. I have seen a duet 2 up and running with a Workbee machine but controlling 3 axes only. There was not an obvious means of configuring a 4th rotational axis in the Workbee software. So… is it straightforward, using the Duet web interface to set up a rotational axis (and to clone the Y axis as a slave)? If so is it just a case of clicking a few boxes in the software?
Secondly, does anyone know of a post processor for use with Fusion 360 which will generate g code for the 4 axes, which will be understood by Duet 2?
I do hope this makes some sense...
Thanks!