@serendipity It may be because the extruder axes aren't moving fast enough to detect the stall. Your config.g limits the speed the axis can move, particularly these three:

; Extruders ... M566 E120:120 ; set maximum instantaneous speed changes (mm/min) M203 E100:100 ; set maximum speeds (mm/min) M201 E25:25 ; set accelerations (mm/s^2)

So the axis won't move faster than 100mm/min. You also need to make sure that the speed is in the correct range for a stall to be recognised, and the maths for that is here: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection#stall-detection-sensitivity-m915-s-f-and-h-parameters

I have a macro that I was testing for (normal 3D printer) extruder stalls, that works well on extruders connected to the main board (ie not a toolboard) here: https://forum.duet3d.com/post/352709

If you can post the actual macro you are using, that may help.

Ian

@droftarts
That 74Hz spike was there before without applying any shaper.
I think that spike is because of a very slight play (which I discovered a few days ago) that the linear X-axis drive. I think it affects both X and Y. In fact I have to disassemble and try to change the balls. After that I can compare and see if that spike was due to that and whether to uncommpare.
It is an xy core and apart from that nasty 7aHz spike it seems to me that there is no excessive vibration/resonance also because the Amplitude is at most 0.010 for a part but mostly within 0.005.

The paper you linked me I had studied, po thought there was some with more graphs and different examples.

You are so kind, thank you again!

@Skyhawk757

Thanks. I did figure out a way to do it. I used a conditional (while) and that checked that status of my mid-point homing switch. If triggered, it moved 1 mm at a time in the direction towards the middle.

Following this I used a G0 command with the option (if forget what that option was called) that moves until the limit switch is triggered.

This results in the axis only moving toward center (with a little overshoot).

I am impressed with the Reprap gcode. Good job! Great flexibility!

Thanks
Greg

@chrismbp I asked @dc42, he says:

Yes most likely the mosfet failed and it took out the driver chip too. Also possible that the driver chip failed and took out the other components.

I was wondering if this might be related to the failure of your 1HCL https://forum.duet3d.com/topic/37666/duet-3-1hcl-can-connection-timeout-after-config-changes ? The only linking factors I can think of is a failing/spiking PSU, or static discharge into the VIN or GND side of the boards.

Ian

@steezebe It's the "TC_roto_coil_mount.step" file, here: https://github.com/Duet3D/Duet3-RotoToolboard/blob/master/mechanical/TC_roto_coil_mount.step

f403b5d3-c572-494a-bb77-447a9c576bf7-image.png

Ian

@dc42 Any alternatives? Thanks!

@f-riccardo Please post your config.g and homeall.g files. This will help us understand how your endstops are currently set up. Also please send M122 in the console and post the response.

The origin (X0 Y0 Z0) should be in the bottom left corner. If your prints are coming out mirrored, most likely your X and Y axes are switched. Check the motors move the axes in the correct direction, see https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_testing

Ian

@chrismbp Okay, we're happy to offer you a warranty replacement on this 1HCL. When and where did you buy the board? Assuming it's from one of our resellers (@elmoret from Filastuder maybe?), 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.

Ian

@p8blr if the axis is flagged as not homed then you can't assume anything about the value of that variable. If the machine has just been powered up or rebooted then it's quite likely to have the value zero. If the axis became un-homed because you disabled the Z motor then it could be anything.

One option is to reduce the motor current while you make that move, so that if it tries to go drop the bed lower than the minimum stop, it won't do any damage. Or you could configure that overtravel switch as the axis endstop temporarily, then use H1 instead of H2 for that move.

@fcwilt

I got it working finally. Therre was a fault in the wiring.

@Esteban

if I max out at 6.8 * 24 = +/-160W and 1.7 * 24 = +/-40W, could that explain why there's no voltage drop?

Sure, but I doubt the measured values. Both @achrn and @dc42 have pointed out how to improve accuracy, but in the end, the Duet has to apply PWM to fine-tune the temperature of a heater, which might be the reason why your PSU can handle the load.

As soon as heaters arrive in PWM mode to regulate the current, they draw less power - on average. Cheap PSUs might be unable to deal with the spikes (that’s why ”Chinese Watts“ tend to deliver less ”bang” than you’d expect), but thanks to beefy capacitors and maybe some over-engineering, you are on the lucky side:

everything has always gone smoothly.

According to my static calculation (addition of nominal power requirements of all components), you are a bit over the limits, but as long as the voltage remains stable, there’s no reason to worry.

@DaveA said in With Shapeways gone - what now?:

@fcwilt I don't know what the status of Shapeways is but I've been using https://www.jawstec.com/ for some SLA parts.

Thanks - I will check them out.

The current folks at Shapeways state they are trying to get up and running again but time will tell.

Frederick

@btmclain I see you have standstill current at 0% (M917 X0), have you tried commenting out this line, or increasing the standstill current value?

on my system when I add the M917 X0 I also get this clunk. Removing it and I have no clunk when tuning.