Topics created by semi55

@semi55 He's still busy with 3.6! To reiterate the question for @dc42 :

User wants to hide the U axis on an IDEX, so his users don't jog it and get unexpected movement. Seems fair, but:

If he hides U with M584 P3, when U is mapped to X, and X is moved, there's no movement. This seems like a bug, as I thought M584 P# only hid the axes in DWC. I have not reproduced this. Is this expected behaviour with hidden axes that are mapped? As far as I'm aware M584 P should only hide the axis/axes homing and jog controls in DWC, but it seems to affect axis movement. I always thought it was odd that you had to unhide axes to home them, though again I haven't really experimented with it. Alternatively, to keep U and X in sync without extra movement (again, I haven't tested if this is the case, but he reports it), DWC could send an M400 after each time a U move is sent, maybe? Or would this cause problems with stuttering movement if a jog button was pressed multiple times?

Ian

@droftarts Thank you very much Ian for your elaborate answer. That solved it!
I've chosen the easy route and used I_O4 and I_O7 and they are working perfectly now.

@jay_s_uk That worked perfectly, thank you very much!

@semi55 said in Duet 6XD power peripherals through 5_EXT_IN:

Can I connect an external 5V power supply to the 5V_EXT_IN pin (with no jumpers on the 5V section) to give enough current to power the LEDs and the servos

Or should I power these devices directly from the external 5V power supply?

Yes, you can do either of these. Use the +5V pin on the 5V_EXT_IN connector. See https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Mainboard_6XD_Hardware_Overview#h-5v

or is this pin only for controlling an external power supply with an SSR?

No, that's the 'pson' pin, though it is on the same header.

Ian

@DonStauffer that also makes sense.
Thanks for your input, I will keep that in mind when starting to implement this for my future machine.

@hackinistrator thanks for your reply and sry for my delayed answer. Leadscrews aren't an option as I have to stick with the rotating movement instead of linear movement of the axis because it drives another belt.

The motors are running at 24V.
Yes, I need 2Nm roughly to be able to move the axle. I have a gear ratio of 5:1 with 1/8 microsteps and two 1.9Nm Motors which leaves me with 3.7Nm left if 19,51% of the max power of the motor is preserved through 1/8 microstepping regarding the faulhaber website.

In theory and in praxis this is enough, the motor is working fine now. Only thing that I've pin pointed is that the timing belt is flexing too much and I am working on a solution for this at the moment.

@phaedrux is there any othrr way? It was working on 3.3, may be if we replicate permissions fron that version?

@jay_s_uk I've upgraded the board to 3.3.0_5 and the SBC to the latest 3.3.0 stable release but unfortunately with no effect. It still stops randomly sometimes.

I've tried to cancel the print after it stopped and got this:

M0 H1 Error: M0: Pause the print before attempting to cancel it

which seems odd as the print should be paused, or is it maybe because it is getting stuck in the script somewhere?

Driver 1 and and 4 are not in use btw. I have a weird arrangement due to one driver slot being fried.

This is the output of M122 P200:
M122 P200.txt

@fcwilt Thanks for pointing that out, I now see how the probe value blips during a mesh level. Now I just check that the value is 0 before and after running a BlTouch self test for a couple seconds. Already saved my hide once while I figure out my intermittent issue.

@semi55 Orthogonal axis compensation helps with Y not being 100% perpendicular to the belt Z axis. Since the heightmap is intended to compensate the Z height depending on the X/Y (or other) axes, you'd have to replace Y with Z but I guess there isn't an easy way to change the slicer for this.