@DuetCDH said in Testing Endstops:

I read that, in DWC 3.5 or greater (I think mine is 3.5.1) the axis letter in the status pane should have a green background. Mine does not change (never green).

I'm not sure when this functionality was added originally, but I though from 3.5.0. However, if you're in CNC mode, it wasn't supported until DWC 3.5.3, see https://github.com/Duet3D/DuetWebControl/wiki/Changelog-DWC-3.x#version-353-changes-since-352

Ian

@emofes said in Bltouch not always triggering during bed probe:

A few things I'm wondering:
Are there any commonly known issues that would cause frequent network disconnects?

Not with the Ethernet boards, they're pretty solid. There have been ups and downs with the WiFi versions over the years, but as far as I'm aware that's fixed now.

The controller is in an enclosure, and the Ethernet cable runs over the power supply; could there be an interference issue?

Possibly. If possible, re-route the Ethernet cable away from the PSU. It could be picking up interference, that is somehow interfering with the BLTouch servo control or signal wires.

The Ethernet cable connects to a coupler so that another Ethernet cable can be connected outside the enclosure. Maybe the coupler or one of the cables is bad and causing random disconnects?

Again, possibly, and similar to above, it may be picking up interference. You could try replacing the two-part cable with a single cable, temporarily.

Could a problem with DWC or the Ethernet connection be causing interrupts?

Like I said, something spamming the network might generate traffic that is interrupting the Duet. Your M122 command shows this:

=== Network === Slowest loop: 221.55ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 3 of 8 Interface state active, link 100Mbps full duplex Socket states: 5 2 2 2 2 2

"Responder states" indicates what the protocol is currently doing, see the list here. 0 indicates it's currently 'free'.
"Http sessions" indicates there are 3 HTTP sessions. Are you connecting multiple browser tabs to the Duet? Reducing the number of HTTP sessions will help connectivity, ie close browser windows connected to the Duet that you are not using will free up the session.
"Socket states" indicates what the network sockets are actually doing, from the list here in RRF 3.5.4, where 2 is 'listening' (which means it is currently available) and 5 is 'closing' (if you ran M122 again, it's state would probably change to 2).

So from this M122, nothing is happening, and most sessions and sockets are available. If you can grab an M122 during mesh levelling, it might be more revealing.

If the chip receives too many connection requests at once, the rest may be aborted, and that leads to connectivity issues. If you increase the number of HTTP sockets by disabling FTP/Telnet (if you are not using them, and have them enabled in config.g with M586), it's less likely to happen.

You haven't posted your full config.g, which might help.

Could using input shaping, mesh bed leveling, DWC, etc. be too much for the board to handle at once?

Not as far as I'm aware. The MCU on the Duet 2 WiFi/Ethernet is the same as on the Mini 5+, computationally. It is limited by flash memory and RAM, but @dc42 works hard to keep it functional.

Ian

@droftarts Looking at the SSR, the it doesn't seem like bed heater turns OFF when LED turns OFF. Is there a good way to test this?

@dc42 the Duet3 control board is not installed inside the closed chamber as the roto toolboard is. How can this calibration affect the outcome of the printing tests?

Is there anything off in the M69 P121.0 report?

@dc42 Success! Thank you!

I removed the "R0" and "Enable" now acts as expected and my X Axis moves!

Now to connect the other axis and the limits so I can home properly.

Thanks again!

Chuck

@dc42 I found the problem.
We moved the power plug to the front of the machine so we could get to it.
there is a plug at the switch at burnt up.

Thank you very much for your help

@Sazabi

Sometimes, despite on m401 or m402 (deploy/retract) I still have probe triggered.

When retracted, the state of the probe is irrelevant, you simply cannot probe anything because the pin is kinda locked. So let’s concentrate on the readings you get in the ”deployed” state.

I see led on sensor turning on/off

Did you actuate the pin manually as I proposed? If so, what readings do you get in DWC?

I dont think it's sensor issue. More like something with my duet2 board.

That’s too early to tell. First, report the range of DWC readings on multiple touch actions (with your fingertips), separately for triggered and untriggered states.

Printed one part and stuck again.

If you encounter mixed results or intermittent failures, have a look at the probe’s mechanics. The pin must move easily, it must not be tilted under any circumstances. What about the spring? Can it possibly get stuck on its way? Carefully inspect all tolerances, Follow the assembly instructions on post-printing: ”Sand the flag and clean the main channels if needed.“ Well, in some cases, to file is superior to sanding.

BTW: what kind of filament did you use for the BFPTouch - PLA, PETG, or some other material?

@droftarts I was able to get it working... kinda. Here is an image of the board's backside. It does need all 3 voltages to work, 3.3, 24, and whatever the chosen motor voltage is. Unfortunatly the configuration pins to set the current appear to have no effect at least in the lower ranges. It's just putting a ton of current to the motor regardless of the combination. Just about smoked a brand new LDO 17.
I did find info on a forum where they were succesfully being used. It was stated that the driver was only suitable, in standalone mode, for large, high current steppers like a nema 34 or larger.
Oh well. Several hours down the drain messing with this thing. Guess I'll send them back and get a 6HC coming. Thanks again for your time.
20250425_191626.jpg

@DuetUser Wrong temperature readout would imply that something has zapped the MCU or associated temperature reading circuit, and the most likely culprit is static electricity. Failures like this generally occur during printing. We recommend grounding the extruder and motor. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Power_wiring#grounding
The Roto and 1LC toolboards can be grounded conveniently:

On Duet toolboards (Roto, 1LC v1.3 and later) the mounting screw holes are all grounded to VIN negative via 100K resistors to provide a path to ground for any static build up.

Grounding is also mention here: https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Toolboard_1LC#wiring-notes

We recommend connecting the hot end metalwork to ground on the toolboard via a resistor (10k to 1M Ohm), if it is not grounded through its mounting system. This will prevent the hot end building up static charge, which might otherwise occur as filament is extruded and may then flash over to the tool board thermistor input, causing damage.

A big enough static discharge will completely kill the MCU.

For the ones that are not extruding, it may be they are running older versions of the firmware compared to the main board, ie toolboard on 3.4, while the mainboard is on 3.5. This usually stops extrusion, while everything else looks okay.

It may also be worth updating toolboards to the latest bootloader, see https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_bootloader

Ian

I went over electronics compartment last weekend and couldn't find anything obvious like a loose wire pressing reset button or some shorting on the button itself. Electronics are cooled by fans which are always on which may be enough - but I'm not sure on that one

@aria_james

@dc42 said in Struggling with PID tuning on Duet 3 with custom CoreXY:

You can configure heater feedforward to combat that.

See https://docs.duet3d.com/User_manual/Connecting_hardware/Heaters_tuning#heater-feedforward

Ian

I think I figured it out. I had B0 instead of B1 in my M307 line. Seems to be working as it should now.

@bug2k22 I didn't read your post carefully enough and I thought you meant the FFC for the inductive sensor. The FFC for the filament monitor is less critical. You can route it close to metal if necessary, preferably metal that is connected to Duet ground.

@MaxGyver I would use unshielded twisted pair in that situation because it has lower capacitance. If you use shielded, I suggest you connect the shield to Duet ground and leave it unconnected at the driver end of the cable.

Additional ESD protection should not be required.

Thank you both! I'll have an engineer do some testing on it. We've never seen one have this kind of issue before and would like to understand if we (really, myself since it's been on my desk) caused it damage or if it was just a faulty board. I'll go ahead and remove the "Unsolved" tag.

@Aubertin the 3.3v regulator is U10 which you said was getting hot

@JC42 i've used a similar servo and MG90s on a toolboard. I used a buck convertor off of the 24v input to get the 5v the servo required.

Various details about servo's buried in my SV08 thread - starting about here if they are of any use.

https://forum.duet3d.com/post/350131

I presume you have already seen the standard duet3d docs on hobby servo connection.
https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_servos