Posts made by dc42

@SanderLPFRG the firmware is open source so you can do what you like. There is already some support for analog probes in the expansion board firmware because the scanning inductive Z probe is in effect an analog probe.

@axiom yes you can change the speed in the M558 command that defines the probe. For conventional probing you can also reduce the dive height.

@P7uis driver 2 en-neg is driven by IC U31. That IC also drives the driver 3 outputs. So that IC probably needs to be replaced.

Drivers 4 and 5 are driven by U32..

@axiom use a scanning Z probe, if the bed surface is compatible.

The OP didn't respond to my request for the firmware version. A change was made to improve this area within the last few months, which is why I asked.

@T3P3Tony that's expected. A driver ID is not a number because it holds both the CAN address and the driver number at that address. However, it should be allowed as the P operand in a M569 command.

@SanderLPFRG looks like you are using the wrong tinyusb project. The one we use is called Libtinyusb.

@rjenkinsgb the reason I asked is that users have experienced similar symptoms when using steel-cored belts, because the belts are not meant to run over such small pulleys and the cores break. I am wondering whether something similar may have happened to the belt on that motor. Also check that the pulley grub screw is still tight.

@Aurimas I believe you, I suspect a bug. Are you able to run the following tests?

1. Reset the machine, check that there is no ghost CAN board, close all browser sessions connected to the board and leave it overnight. In the morning check if the ghost CAN board is there.

2. If the ghost can board isn't there, then repeat test #1 but this time leave a couple of open browser windows running DWC connected to the Duet,

@rjenkinsgb are you by any chance using steel-cored belts?

@wayneosdias I took a look at your schematic. The TMC5160 needs external mosfets to drive the stepper motors. For small motors the TMC2240 would be better, if you don't mind the max VIN voltage being about 36V.

@gtj0 the repo name does use the capitalised F, see https://github.com/Duet3D/WiFiSocketServerRTOS. Perhaps your local copy uses a lowercase f ?

@P7uis if it's a V1.01 or earlier board and it still works without supplying external 5V power (which includes power through the USB connection) then my guess is that a trace carrying +5V to the 5V pins of the driver 2/3/4/5 outputs connectors has blown. Disconnect all cables connected to those output headers and use a multimeter to check whether those 5V pins are all connected together.

@Aurimas there are a few issues with disconnecting/reconnecting a tool board:

1. At a physical level, you will get a current surge when you reconnect power to the tool board, because the PSU is already providing its normal voltage output and the tool board has capacitors connected between VIN and ground. You can mitigate this by connecting a surge-limiting thermistor in series with the +VIN connection. If you don't do this then you are likely to blow the fuse supplying VIN to the tool board, or the tool board itself.

2. When the tool board loses power, it loses its configuration. It would be necessary to re-send the configuration when the tool board reconnects. I think you could do that by putting all the configuration relevant to the tool board in a separate macro file, then calling that macro both in config.g and in the handler macro for the tool board reconnection event. This will only work if the tool board is connected when you power up the machine, because no event is generated the first time a tool boards connect to the main board.

3. If you are thinking of using pogo pins to disconnect/reconnect the tool board, Stratasys has a patent on that.

@SanderLPFRG I think there are two pieces of work needed to support other types of scanning Z probe: (1) allowing general analog-output Z probes to be used in scanning mode; and (2) supporting analog Z probes over CAN.

@mike_b please note, the issue that has been reproduced is not the original one that you reported. I fixed the original one some time ago. The bug that has recently been reproduced (and I have just fixed) is that if a M906 command with the I parameter is issued when the motors have moved or been enabled, but they have subsequently become idle, then on expansion boards (including main boards used as expansion boards) the regular motor current was incorrectly sent to the idle current. The consequence was that when you commanded them to move again, they didn't receive the full current.

@Triet you can connect supercaps of the same type and value in series, with parallel resistors to help keep the voltages balanced. For example, ten 10F 2.7V caps in series with a 100 ohm resistor in parallel with each one will give you a 1F 27V capacitor. Charge/discharge them through a 100 ohm 6W resistor and parallel Schottky diode.

Don't forget that after turning power off the supercaps will still power the board for some time, so wait until the LEDs have all turned off before doing any work on the system.

@ironhydroxide we've considered this in the past and I'll take another look at it. To keep costs reasonable we'd probably need to specify a maximum VIN voltage of 36V rather than 48V. Would that be OK for you?

@Aurimas what is in config-override.g?

Do you still get the error messages if you comment out the G29 line in the job file?

@developeralgo222 from the responses on the OpenPnP group at https://groups.google.com/g/openpnp/c/W-ZLi_xXj-A it appears to me that you need to specify the microsteps/degree for a cam-driven Z axis, not steps/mm.