@TimV-0

I kept the ender5 limit switches but replaced the wiring with generic 3 pin wires to the board. I am having problems keeping the wires connected at the end stops.

With proper connectors, this should not happen. Maybe the wires are too "generic"?

I applied heat shrink tubing at the limit switch end, so they now all look perfect but seem to vibrate loose.

Cosmetics cannot hide the face below for long 👺. Use proper connectors or a good soldering iron - the switches are just fine.

@JADoglio Thanks You very much. I don't care how many hours I spend printing, building printers, and upgrading there is always something new to learn and thankfully someone out there to teach it.

@MortarArt said in Emergency stop without input:

I'm curious how that works.

error correction

@MortarArt said in Emergency stop without input:

I'll update the firmware and see how I go.

If you update your firmwares, don't forget to update the panel due firmware as well.

https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_PanelDue

@infiniteloop 👍

@sgk yes solved

Go through this guide and let us know what you find and how far you get.

https://docs.duet3d.com/en/User_manual/Troubleshooting/Duet_wont_respond

I didn't like having to do this in the middle of a print, but turing it off and then on again worked.

@dc42 said in software limits prevent negative tool offset on IDEX Printer:

Why don't you change the Z limit in the tool change file to a value based on the Z offset of the incoming tool? That way you can use the same code for all tools.

@CR3D
Based on DC42's advice, I think this would work in your tool change file

M208 S1 Z{min(0,0 - tools[state.nextTool].offsets[2])} ; set Z minima to the lower of zero or zero minus incoming tool offset

But this line in the G10 documentation

Tool offsets are given as the offset of the nozzle relative to the print head reference point, so the signs are opposite to what you might expect because tool offsets are subtracted from the required printing locations during printing.

makes me wonder if the math should be
Z{min(0,0 + tools[state.nextTool].offsets[2])}

I don't have multiple tools, so I,m not 100% sure on the G10 setup.
e.g.
Let's say tool 1 is zero offset (reference) and tool 2 is 1mm higher in Z

If that means your Z offset for tool 2 is +1, then use the first example.
If it means your tool 2 offset is -1, then use the second example.

@dc42 Quick update, the printer is still running, I have an estimated 37 hours remaining on the print right now. Installing a new power supply seems to have fixed the problem. What's odd is that the old power supply is installed in an identical printer and hasn't caused that one to fail yet... I guess this issue is solved, but I don't feel satisfied with the answer lol. I can still send you a M122 on Monday when the printer is finished if you'd like.

@marco13 You can send M98 gcode command:

import serial with serial.Serial('/dev/ttyACM0') as ser: ser.setRTS(True) ser.write(b'M98 P"yourmacro.g"\n')

See https://docs.duet3d.com/User_manual/Reference/Gcodes#m98-call-macrosubprogram

@Thorpydo we're glad to have you with us!

@Pierre52 see https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_connecting_external

Basically, you can add external drivers individually to the Duet 2 WiFi, or use a Duex5 to add 5.

Ian

i have great performance from the magnetic runout sensor. but when i do have false positives, i simply widened the limits to 10% to 190%, and this lets the printe run unless there is zero filament movement. but i mostly don't have to do this.

but i now want to try the idea using the counter and global variables.

@kuon Yes, and a Mini 5+ could also drive a 1A motor. However, the phase resistance and inductance is high. For guidance, see https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_choosing#inductance

The inductance of the motor affects how fast the stepper motor driver can drive the motor before the torque drops off. If we temporarily ignore the back emf due to rotation (see later) and the rated motor voltage is much less than the driver supply voltage, then the maximum revs/second before torque drops off is:

revs_per_second = (2 * supply_voltage)/(steps_per_rev * pi * inductance * current)

You can use this calculator to calculate back EMF: https://www.reprapfirmware.org/emf.html

Ian

Let us know if it reappears.

@marco13 you've already started your own topic. please don't spam others (especially old ones)

If you're using a belt to lift the Z axis, you can most easily prevent Z axis drop by using a worm gear reducer on the motor. It doesn't require any extra electrical connections or any special configuration, and it stops the Z axis from moving at all when power is cut. I have one of these 30:1 reducers in my printer's Z axis (yes, one motor, so no autoleveling needed or used). It is driven by the driver chip on the Duet2 controller (current set to 1A). At that current it easily lifts a 3.5kg bed plus 4 kg of print weight. I set steps/mm in config.g and it's done. I chose drive pulleys that yield 20um/full step, so I get excellent Z axis quality when printing in layer thickness that is a multiple of 20um (100 um, 200 um, 500 um, etc.).

Note- you can get cheap planetary drives on steppers, and if the reduction ratio is high enough they might prevent Z axis drop, but they don't have whole number reduction ratios (read the fine print!) so you won't get "nice" full-step values from them.

"My guess is that it's a router issue, and changing the channel resets something in the router."

Do you have another none asus router to test with?

You could reverse the microstepping change and the M569 change and see if it makes a difference. You could also flash back to 3.3 firmware, but there's no similar bug that I'm aware of.