Topics created by Tinchus

@Tinchus From my experience most of the resonance when it is speed specific will be related to any mass that is not perfectly centred on the ball screw (i.e how much of a banana the screw is). The motor will have its own resonance, but its exceedingly hard to mitigate that without straight up changing the type of motor.

Your right to think about changing the tip of the screw from a hard clamp to some form of plastic dampening clamp. it can still hold up the tip and provide a little bit of dampening enough to remove the resonance.

You can see a similar system used on the Prusa XL or our Construct1 XL printers 3485a756-eed9-4941-9a44-b3eb04eda352-image.png

(obviously these are threaded rods, but they work the same for ball screws)

@Tinchus

From the docs..,
The H parameter defines the Z probe dive height, which is the height above the trigger height from which probing starts. The default is 3mm or 5mm depending on firmware version. You may wish to increase it during initial calibration. When using mesh bed compensation or running G30 commands with specified XY coordinates (for example from the bed.g file), the firmware moves the Z probe to this height above where it expects the bed to be before commencing probing. The maximum depth of probing from this position is twice the dive height.

I think you'll find on straight G30 Z home, the dive height is ignored as the height is unknown.
Otherwise you would never be able to home from any height.
About the best you can do is check for typical errors before you start using the object model.

I use this macro which is called before any Z homing or bed leveling

check BL Touch var probeOK = true if sensors.probes[0].value[0]=1000 ; if probe is in error state set var.probeOK = false echo "Probe in error state- resetting" M280 P0 S160 ; reset BL Touch G4 S0.5 if state.gpOut[0].pwm < 0.05 set var.probeOK = false echo "Probe is already deployed - retracting" M98 P"0:/sys/retractprobe.g" G4 S0.5 if sensors.endstops[2].triggered set var.probeOK = false echo "Probe is already triggered - resetting" M280 P0 S160 ; reset BL Touch G4 S0.5

I also use this check in my homeall.g to cancel the print if any errors occur during homing
Any successful command should return a value of 0

G30 ; home Z by probing the bed if result !=0 abort "Print cancelled due to probe error"

Outside that, you'd have to have a secondary switch, pressure sensor or similar attached I'd think.

@Tinchus said in Bltouch not deploy sometines it does:

If I push pin up with fingers, DWC never sees the BL activation (zprobe value is always cero). If I issue an M402 pins goes up, then M401 deploys the pin and if I try to trigger it, pin is trigger but DWC nevers sees that, probe value is always cero.

The pin is magnetic, so if you force it up it's going to stay put magnetically, but that's not to say it's the same as triggering. It's best not to touch the pin at all as it's very fragile. And only control it with the proper M401 and M402 commands so that the state of the pin can be accurately tracked by the firmware.

As for the cabling, please try the setup I suggested. If the short leads of the BLtouch itself aren't long enough, try making a short extension harness. The idea is to see if the issue is cable interference or if the BLtouch itself is malfunctioning.

For what it's worth, I run several wires through my harness 1.5 meters to the print head including the heater, PT100, two fans, and BLTouch. All the cables are individually twisted or braided though to limit interference.

@droftarts yes, I though the problem is completly different of this post.

@gloomyandy Ok, I understand, it is a interpretation thing I think because it is correct that DC made a clarification that I didnt read, I interpreted "time out" of the mnessage box, not of the whole maCRO AS IF CANCEL WAS PRESSED.

So lets see how can I achieve my objective, if you can help me on that would be great: As I posted, I run a macro, at the beginning I have that message , my objective is to be able on some situations, in order to save time, to just cancel the rest of the macro. So My message ask for a yes or no. But also, if Im not available, I want that message to time out and default behaviour should be to continue and execute the rest of the macro. Is there today a way to do that because if the time out jwill cancell everything, Im out of options

@droftarts jajajaj I have just read that article jajajaja thanks

@Phaedrux Done (manually choosing refresh is the same I guess?). Still shows 0 while heating the bed. This is not happening with the hotend temp, as soon as hotend temp is set, the value is updated on DWC

@Phaedrux Problem solved. Dont know why, seems chromium got bloques as usual when changing the printers fantasy name. Usually when this hapenned in the past, using this link on desktop asked you about a lock being present and giving you the chance to reset this lok. This time that never happened.

Manually removing the lock solved the problem:

rm .config/chromium/SingletonLock

Thaks

@chrishamm said in Problem on new installation / upgrade:

Bookworm

Thnaks you all. I think this post can be considered as SOLVED.

As a recap:
at least for me, the 64 bits version is really not running with enough resources on a a raspi 3 B+, too slow, I got many weird erros on daemoin.g file, camera issues, etc.

The 32 bit version is now running as suposed to.

LCD touch screen in my case needs extra config to run on bookworm, I found the solucion here: https://www.waveshare.com/wiki/Main_Page#RPi-Displays (llok for your model)

@Tinchus
Replied to your other post here

@droftarts Thanks very much for all the info. I guess my most probable cause the sd card, may be is too old by now (been under heavy use for 3 years I think? and also has been upgraded for at least 5 times for sure a little more).
Thanks!

@dc42 OH! well that is good to know. Probably would be good to include this clarification into docs. Post solved, thanks a lot for the answers

@gloomyandy ok, I will try this and get back to you

@Tinchus Is there any particular reason you check avgPwm?

@T3P3Tony Sorry forr delay in answering Tony, I as out of office. Update seems to have corrected the failure. Im not sure 100% because I have done only 3 attemps and were partial attemps, I have not tried to amke it fail. For now I guess it is solved, but I have noticed during these test another problem, I will create a separate post for this now (it is an unload problem)

@Tinchus I think M84 S0 has been invalid to set the idle state for a while. The S0 switch was never intended to mean "never idle hold", and is not documented in the M84 entry as doing that. The correct way to set no idle hold is to use M906 I parameter to set the idle hold to the required level, eg M906 I100.

I'll update the Gcode documentation to make this clearer.

Ian

@Tinchus said in reconection to wifi after disconnect:

Is there a way to make duet reconnect again to the network / retry the connection without rebooting it?

see M587.1: Start network scan