Posts made by dc42

@dwuk3d most likely your slicer is outputting M203 commands to limit the X and Y speeds. Most slicers can be configured not to have this reprehensible behaviour.

@lei2vaegh6 I think your sensor is PNP output, not NPN.

@ageis said in drivers nt responding after spark:

Is driver 2 not the one with the two connectors ?

Yes if it's a Duet 2. In which case, with the driver chip missing you will see a lot of spurious errors from it. Use M569 P2 R-1 to disable reports from that driver; or fit a new TMC2660C driver chip if you need all 5 drivers.

@ageis said in drivers nt responding after spark:

I keep getting an error saying phase A and phase B is shorted to gnd on driver 2 but I can't find a short with my multimeter.

If a driver is blown or for some other reason it doesn't respond to the SPI message, then typically all the error bits are flagged as active, i.e. short to GND, short to VS, phases A and B not connected, and more.

Which Duet is it, and when/where did you purchase it? Does the Driver 2 chip (or any component around it) appear damaged?

You may be able to disable that driver (including reports from it) using the R-1 option of M569.

@R006 I think the issue is that if a motor phase is disconnected, then the motor doesn't usually move when commanded, so it produces no back EMF due to rotation, causing the stall detection to trigger. Indeed, it is stalled because it is not moving. That's why you get both events raised.

Unfortunately the "phase may be disconnected" conditions doesn't identify definitively that a phase is disconnected. RRF does suppress this warning under some conditions that are known to trigger it spuriously, such as when the motor current is low or when the motor is at standstill at an exact phase position. Also, the "phase may be disconnected" and "driver stall" status flags normally won't both become active at the same time when a phase becomes disconnected. So we couldn't suppress the driver stall warning if a phase is flagged as possibly disconnected, even if we wanted to.

You could try setting a global variable in driver-warning.g if a phase is flagged as disconnected, then test that in driver-stall.g and suppress the stall error if the driver is flagged as having a phase disconnected.

Phases becoming disconnected should be a very rare event, except perhaps when commissioning a machine.

@flowall the backlash correction is gets converted to microsteps, rounding down to a whole microstep. So anything below 1 microstep is in effect ignored.

@ELAD further to the suggestion made by @droftarts, if you reduce the M201.1 accelerations then you may be able to revert to using S3 in the M915 command.

@kcress said in Why exactly does a Core X Y Z printer loose tram ?:

Whenever I turn off power, or really annoying, reboot the Duet3, I can see the gantry's right rear corner drop about 2mm.

It appears that the detent torque of the motor driving that corner is insufficient to prevent the motor from turning under the load. Is it the same type of motor as the other Z motors? How does it drive the Z axis: leadscrew, ballscrew, belt, or something else?

@Jos_mosa and now that 3.6.0 stable is released, it is visible in the DWC Object Model Browser too.

@Dutchprinting another check you can do is to see whether you can turn the most shaft by hand. If you have not connected the driver Enable signal from the 1XD to the driver, then as soon as you power up the driver, the motor shaft should lock, if the driver defaults to Enabled (or you have configured it that way, if it is selectable). Whereas if you have connected ithe Enable signal with the correct polarity, then after power up it should be possible to turn the motor shaft by hand, but after you send M17 or a movement command for that axis, the motor should lock.

@NANDHAKUMAR10 the stepper motor wires produce mostly inductive EMI. Therefore if your aim is to minimise EMI, I recommend that each motor is connected to the 6HC or EXP3HC using a dual twisted pair cable, with one pair used for each stepper motor phase. You can used shielded cable if you like, but it won't greatly help to reduce inductive EMI. The stepper motor bodies should be grounded, either through the shield of the cable if you use shielded cable, or by another means.

You haven't said what types of sensor you are using, and why you want to use EMF shielding wire for them. Are you looking to reduce EMI radiated by those sensor cables, or to shield them from external EMI (including EMI from other parts of the same system, for example stepper motor cables)?

@o_lampe said in Custom Delta/Quantum Delta Hybrid Kinematics:

My deltas always had the lowest print adhesion compared to other printers, because I couldn't squish the first layer onto the bed.

Why not?

@Visionary said in Linear motors: Day Dreaming about future printers.:

Is it possible to drive DIY 2-phase closed loop linear motor with (new) Duet hardware directly (or with additional hardware)?

That would depend on the interface t the closed loop motor.

I've looked at the possibility of using a DIY linear induction motor to drive axes of 3D printers - I have some knowledge of them from experiments many years ago. For the Z axis, I doubt they are practical or that they would offer any significant advantages. For X and Y, I don't see any arrangement other than a bed-slinger that wouldn't require one of the motors to be mounted on a moving axes, which is undesirable because then the moving mass would be considerable.

@CrooKID it sounds to me that you haven't identified the stepper motor phases correctly. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_connecting#using-the-internal-drivers and the section after that one.

@turtlegod42 that depends on how accurate your build geometry is. RRF normally calibrates the delta radius, endstop corrections and tower positions. It won't be able to calibrate all 6 endstop corrections or all the tower positions if you pretend it is a normal delta with 3 towers.

@oliverkersten said in Array index out of bounds error:

@dc42 Thanks I fot it working with using sensorrs.endstops[2].triggerd.

If I wanted to use a input then I should use M950 and then sensors.gpIn[] should also work?

Yes. An input can't be simultaneously and endstop and a GpIn port.

@turtlegod42 not without some firmware changes.

@turtlegod42 if you want each delta mechanism to move half of the commanded amount, I can see a couple of ways of doing that:

1. Tell RRF that everything is twice the size that it actually is, i.e. in M665 set the rod length and delta radius to double the actual values.

Or:

2. Use M579 to set the scale to 50%.

RRF supports more than 3 delta towers (up to 6), however this isn't documented n the GCodes dictionary. To use extra delta towers, create the extra axes using M584, then in the M665 command provide as many L values as you have towers.

@mikeabuilder thanks for confirming.

@oliverkersten the expression sensors.gpIn[0] reads the state of GpIn pin 0, which I presume you haven't defined. I think the expression you want is sensorrs.endstops[2].