@chrishamm Thanks! That was it.
Changed the imports and the send.response() and now it works.
With hindsight I then find this change (and some others) had been made at https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/custom_http_endpoint.py in early December last year, but I had missed that.
Updated for 3.6 (tested on 3.6.0rc1): PyDaemon.zip.txt (as usual you will need to take the .txt off the end of this file - I'm circumventing the forum restrictions).
The only change is to renumber it to a 3.6 version and set the requisites to 3.6.
Installation
The 3.6.0RC1 package repository does not have 3.6.0 DSF (at time of writing), and the 3.5.1 DSF one does not work with 3.6.0, so you need to add DSF manually. The 3.6.0 RC1 version is on pypi: https://pypi.org/project/dsf-python/3.6.0rc1/ so sudo pip3 install --break-system-packages dsf-python==3.6.0rc1 should install it.
python3-dsf-python (3.6.0~rc1-1) is in the repository now so can just sudo apt install python3-dsf-python (or apt upgrade) it.
Otherwise it's install in the usual manner for plugins - drop the zip onto the 'Install Plugin' button in Plugins in DWC and click the Start button (after checking the code is not going to do you harm). Refer to the first post in this thread for discussion of what goes in your daemon.py file.
Updated for 3.6 (tested on 3.6.0rc1): WeighFilament.zip.txt (as usual you will need to take the .txt off the end of this file - I'm circumventing the forum restrictions).
Functionally it's the same (so read the first post in this thread for what it does). Actually the only change is to renumber it to a 3.6 version and set the requisites to 3.6. The calibration file is unchanged so if you put that somewhere safe you could copy it back after putting the new plugin in and wouldn't need to calibrate.
As before, this plugin is purely DSF, no DWC component at all. I still can't get endpoints working so this one still uses the kludge of writing a global variable instead. You can define a macro containing e.g. M291 P{global.filWeight^"g filament on spool"} R"Filament Weight" to get the weight (or read the object model).
Installation
The 3.6.0RC1 package repository does not have 3.6.0 DSF (at time of writing), and the 3.5.1 DSF one does not work with 3.6.0, so you need to add DSF manually. The 3.6.0 RC1 version is on pypi: https://pypi.org/project/dsf-python/3.6.0rc1/ so sudo pip3 install --break-system-packages dsf-python==3.6.0rc1 should install it.
python3-dsf-python (3.6.0~rc1-1) is in the repository now so can just sudo apt install python3-dsf-python (or sudo apt upgrade) it.
You need some python libraries. At a command prompt: sudo apt install python3-numpy. The previously required python3-rpi.gpio and python3-setuptools seem to already be part of the latest DuetPi image.
You need to download and install the HX711 library from https://github.com/tatobari/hx711py This is pure python and relatively straightforward. Having downloaded and unpacked you cd into the library top folder and sudo python3 setup.py install --record files.txt.
To install the plugin drop the zip onto the 'Install Plugin' button in Plugins / external plugins in DWC - but DO NOT START the plugin yet.
The plugin won't create the necessary global variable, only update an existing one, so you need to add creation of the variable to config.g, e.g. with the following. The value you set here doesn't matter. You can use a different variable name, but in that case must edit the value near the start of /opt/dsf/plugins/WeighFilament/dsf/weighfilament.py to match.
if !exists(global.filWeight)
global filWeight = 0
You need to calibrate the routine before use. The plugin has a helper script to do that, and it's easiest to put this into /usr/local/bin so you can run it directly. At a command prompt run sudo cp /opt/dsf/plugins/WeighFilament/dsf/weigh /usr/local/bin and then sudo chmod a+rx /usr/local/bin/weigh.
With nothing on the spool holder at a command prompt run weigh zero or weigh z, this records the tare reading of the holder alone.
Then you need something of a known weight not dissimilar to a spool of filament (preferably nearing the end) on the holder - I use a 200g weight - and run weigh calib or weigh c. It will ask you what the weight is.
Then preferably put an empty spool on the holder and run weigh spool or weigh s. If you don't have an empty spool but do know what one weighs you can run weigh manual or weigh m and enter a weight value.
Some semi-cryptic entries should now have shown up in the weighfilament_calib.txt file in the system directory.
You can re-run any of these (e.g. when you change to a spool with a different empty weight), but you must stop the plugin first. There is no locking, and the script and plugin will scramble each other's communication with the HX711 if they run simultaneously, normally resulting in a hang or garbled data. The calibration file grows forever, if you do a lot of resetting the calibration you can open it and delete older lines - the routine just uses the last of each 'zero', 'calib' and either 'spool' or 'spoolwt' lines it finds in the file.
If you get wildly varying (or complete garbage) answers or the weigh script hangs, the plugin is probably running. Stop the plugin before running the script. Also, the plugin only reads the calibration file on startup - so you need to start the plugin after changing calibration values for it to get the new values anyway.
However, there is apparently the possibility of problems with bit ordering and byte ordering which can also lead to garbage values - if you still get garbage values see the discussion on the HX711 library github page and make changes in definitions near the top of both the helper script and the weighfilament.py file in the plugin zip file.
After all that you should be able to start the plugin. Apart from 'Status' changing to 'started' nothing visible will happen, but if you look in the object model browser or run M291 P{global.filWeight} you should get a weight.
I've tried DSF http endpoints on 3.6.0 rc1 and it's not working for me in exactly the same way as it didn't in 3.5.1 (which is described here: https://forum.duet3d.com/topic/35700/dsf-python-3-5-1rc1-problems-with-http-endpoint-not-working?_=1742631997497 but I shall recap):
Duet 3 MB6HC MB6HC 3.6.0-rc.1
Duet 3 Expansion TOOL1LC TOOL1LC 3.6.0-rc.1
Duet Software Framework DSF 3.6.0-rc.1
Duet Web Control DWC 3.6.0-rc.1
Raspberry Pi 4 Model B Rev 1.2
Linux delta.XXXXXX 6.6.74+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64 GNU/Linux
from a Bookworm DuetPi image initially
dsf 3.6 is not currently in the package repository, I got it from https://pypi.org/project/dsf-python/3.6.0rc1/ and did sudo pip3 install --break-system-packages dsf-python==3.6.0rc1
The custom_http_endpoint.py script does not seem to be in the 3.6.0rc1 source from pypi, but I used the one from 3.5 (I'll add it to the bottom of this post).
Script output looks like it's working:
send: {"mode":"Command","version":12}
recv: {"success":true}
send: {"command":"AddHttpEndpoint","endpointType":"GET","namespace":"custom","path":"getIt","isUploadRequest":false}
recv: {"success":true,"result":"/run/dsf/custom/getIt-GET.sock"}
Try accessing http://duet3.local/machine/custom/getIt in your browser...
as it starts up, then when I make a connection:
recv: {"sessionId":-1,"queries":{},"headers":{"Accept":"*/*","Connection":"keep-alive","Host":"localhost","User-Agent":"Wget/1.21.3","Accept-Encoding":"identity"},"contentType":null,"body":""}
send: {"statusCode": 200, "response": "so happy you asked for it!", "responseType": "statuscode"}
However, there's no data received (I used wget on the same machine to bypass any networking shenanigans):
@delta:~ $ wget -S http://localhost/machine/custom/getIt
--2025-03-22 09:20:35-- http://localhost/machine/custom/getIt
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Content-Length: 0
Date: Sat, 22 Mar 2025 09:20:35 GMT
Server: Kestrel
Length: 0
Saving to: ‘getIt’
getIt [ <=> ] 0 --.-KB/s in 0s
2025-03-22 09:20:35 (0.00 B/s) - ‘getIt’ saved [0/0]
It has zero content length.
User running custom_http_endpoint.py is a normal user but member of dsf group.
Running as root doesn't help.
Socket has permissions srwxrwxr-x 1 user dsf 0 Mar 22 09:17 getIt-GET.sock
Journal log looks OK
Mar 22 09:23:48 delta.XXXXXX DuetWebServer[750]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://localhost/machine/custom/getIt - - -
Mar 22 09:23:48 delta.XXXXXX DuetWebServer[750]: DuetWebServer.Singletons.SessionStorage[0] Session 7e5e184ecf1c475fb53104344d27ab60 added (readWrite)
Mar 22 09:23:48 delta.XXXXXX DuetWebServer[750]: Microsoft.AspNetCore.Hosting.Diagnostics[2] Request finished HTTP/1.1 GET http://localhost/machine/custom/getIt - 200 0 - 23.2772ms
Accessing the URL from a PC on the local network with Edge doesn't get any content either. I haven't tried further browsers (but I did last time).
This is the endpoint script I'm using:
#!/usr/bin/env python3
"""
Example to create a custom GET endpoint at http://duet3/machine/custom/getIt
Make sure when running this script to have access to the DSF UNIX socket owned by the dsf user.
"""
import time
from dsf.connections import CommandConnection
from dsf.http import HttpEndpointConnection
from dsf.object_model import HttpEndpointType
async def respond_something(http_endpoint_connection: HttpEndpointConnection):
await http_endpoint_connection.read_request()
await http_endpoint_connection.send_response(200, "so happy you asked for it!")
http_endpoint_connection.close()
def custom_http_endpoint():
cmd_conn = CommandConnection(debug=True)
cmd_conn.connect()
# Setup the endpoint
endpoint = cmd_conn.add_http_endpoint(HttpEndpointType.GET, "custom", "getIt")
# Register our handler to reply on requests
endpoint.set_endpoint_handler(respond_something)
print("Try accessing http://duet3.local/machine/custom/getIt in your browser...")
return cmd_conn, endpoint
if __name__ == "__main__":
try:
cmd_conn, endpoint = custom_http_endpoint()
# This just simulates doing other things as the new endpoint handler runs async
time.sleep(1800)
finally:
if endpoint is not None:
endpoint.close()
cmd_conn.close()
@achrn said in 3.6.0 RC1 python perform_simple_code not working:
@chrishamm said in 3.6.0 RC1 python perform_simple_code not working:
@achrn There were some errors in the previous 3.5 dsf-python client which renders parts of it unusable with 3.6. Hence I suggest you upgrade to dsf-python 3.6-rc.1, I expect that will fix your problems.
Should 3.6.0 be available by apt install?
Further to that, https://pkg.duet3d.com/dists/unstable-3.6/armv7/binary-armhf/ seems only to contain 3.5 and the 'Packages' file likewise only lists a v3.5
Package: python3-dsf-python
Architecture: all
Version: 3.5.0-1
Priority: optional
However, 3.6 RC1 version is on pypi: https://pypi.org/project/dsf-python/3.6.0rc1/
I've used sudo pip3 install --break-system-packages dsf-python==3.6.0rc1 after which the test script up thread works and the variables gets set to 99. I'll try the other issue I had also.
It would be good if 3.6.0RC1 could be added to the package repository - it seems to be the only 3.5 package in https://pkg.duet3d.com/dists/unstable-3.6/armv7/binary-armhf/ (unless there's a good reason why it shouldn't be included).
@chrishamm said in 3.6.0 RC1 python perform_simple_code not working:
@achrn There were some errors in the previous 3.5 dsf-python client which renders parts of it unusable with 3.6. Hence I suggest you upgrade to dsf-python 3.6-rc.1, I expect that will fix your problems.
Should 3.6.0 be available by apt install?
I've done apt update and apt upgrade but apt list gives me (inter alia)
python3-dsf-python/unstable,unstable,now 3.5.0-1 all [installed]
All the rest of the packages seem to have gone to 3.6.0 RC1:
duetcontrolserver/unstable,now 3.6.0~rc.1 arm64 [installed,automatic]
duetpimanagementplugin/unstable,now 3.6.0~rc.1 arm64 [installed]
duetpluginservice/unstable,now 3.6.0~rc.1 arm64 [installed]
duetruntime/unstable,now 3.6.0~rc.1 arm64 [installed,automatic]
duetsd/unstable,now 1.1.0 all [installed,automatic]
duetsoftwareframework/unstable,now 3.6.0~rc.1 arm64 [installed]
duettools/unstable,now 3.6.0~rc.1 arm64 [installed,automatic]
duetwebcontrol/unstable,now 3.6.0~rc.1 all [installed,automatic]
duetwebserver/unstable,now 3.6.0~rc.1 arm64 [installed,automatic]
Failure so the SSR is switched on is the most common SSR failure. See e.g. https://omronfs.omron.com/en_US/ecb/products/pdf/precautions_ssr.pdf "Short-circuit failures represent the main failure mode and can result in an inability to shut OFF the load" (but you probably don't need all the protection circuitry that note suggests, though presumably it does all serve a purpose).
When replacing it beware that most of the SSRs on ebay or aliexpress are fake. Buy your SSR from a reputable supplier.
I've posted another message about trouble with command connections downloading OM, but I've discovered I've got a problem with even more basic DSF from python, so this one probably comes first!
I'm trying to use CommandConnection perform_simple_code to set a global variable. This was working on 3.5.4, but isn't on 3.6.0 RC1, though the debug messages look like the system thinks it has worked.
My python script:
#!/usr/bin/env python3
# imports
import sys
from dsf.connections import CommandConnection
# create command connection used for communicating with dsf
print("connect", flush=True)
cmd_con = CommandConnection(debug=True)
cmd_con.connect()
# update value of global variable
print ('update variable', flush=True)
res = cmd_con.perform_simple_code('set global.filWeight = 99', async_exec=True)
print ('result:', res, flush=True)
cmd_con.close()
# pack up
sys.exit()
running it:
root@delta:~# ./foobar.py
connect
send: {"mode":"Command","version":12}
recv: {"success":true}
update variable
send: {"command":"SimpleCode","Code":"set global.filWeight = 99","Channel":"SBC","ExecuteAsynchronously":true}
recv: {"success":true,"result":""}
result:
root@delta:~#
but global.filWeight doesn't change to 99 (it stays at 0, from config.g global filWeight = 0).
I have nothing untoward showing up in journalctl -f or any log files (that I've found).
Have I missed something fundamental about DSF python in 3.6?
I have Duet 3 MB6HC with Duet 3 Expansion TOOL1LC running 3.6.0-rc.1, SBC mode.
I have a plugin which is python which makes a subscribe connection then attempts to download the whole object object model (it then goes on to do other stuff, but it fails at trying to get the object model). This was running fine on 3.5.4.
Before this point is only global variables, imports (including from dsf.connections import SubscribeConnection, SubscriptionMode), define some functions.
verbose and vTS are both true to generate the logs comments with timestamps.
#################################################
# main
#################################################
if __name__ == '__main__':
# establish the dsf-python connection, with some re-tries just in case
for attempt in range(5):
try:
if verbose: print(("{:.6f} ".format(time.time()) if vTS else '') + 'try subscribe connection', flush=True)
subscribe_connection = SubscribeConnection(SubscriptionMode.PATCH, debug=False)
subscribe_connection.connect()
except:
time.sleep(3)
else:
if verbose: print(("{:.6f} ".format(time.time()) if vTS else '') + 'got subscribe connection', flush=True)
break
else:
# ran to end of our attempts and didn't break out so still not established
# make one last attempt after a longer pause
time.sleep(15)
subscribe_connection = SubscribeConnection(SubscriptionMode.PATCH, debug=False)
subscribe_connection.connect()
try:
# get the complete object model once
# note we cast it to a string in order to feed it in to json.loads
om = json.loads(str(subscribe_connection.get_object_model()))
This apparently makes the connection OK (log messages at lines 10 and 16 above appear OK at 3 and 4 below) but then generates a traceback referring to /usr/lib/python3/dist-packages/dsf/object_model/spindles/spindles.py:
Mar 16 20:19:19 delta DuetPluginService[838]: [info] Plugin PyDaemon: Launching /opt/dsf/plugins/PyDaemon/dsf/pydaemon.py
Mar 16 20:19:19 delta DuetPluginService[838]: [info] Plugin PyDaemon: Process has been started (pid 2181)
Mar 16 20:19:19 delta DuetPluginService[2181]: 1742156359.805182 try subscribe connection
Mar 16 20:19:19 delta DuetPluginService[2181]: 1742156359.806868 got subscribe connection
Mar 16 20:19:19 delta DuetPluginService[2181]: Traceback (most recent call last):
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/opt/dsf/plugins/PyDaemon/dsf/pydaemon.py", line 174, in <module>
Mar 16 20:19:19 delta DuetPluginService[2181]: om = json.loads(str(subscribe_connection.get_object_model()))
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/connections/subscribe_connection.py", line 43, in get_object_model
Mar 16 20:19:19 delta DuetPluginService[2181]: object_model = self.receive(ObjectModel)
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/connections/base_connection.py", line 78, in receive
Mar 16 20:19:19 delta DuetPluginService[2181]: return cls.from_json(json.loads(json_string))
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/object_model/model_object.py", line 87, in from_json
Mar 16 20:19:19 delta DuetPluginService[2181]: return cls()._update_from_json(**preserve_builtin(data))
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/object_model/object_model.py", line 160, in _update_from_json
Mar 16 20:19:19 delta DuetPluginService[2181]: super(ObjectModel, self)._update_from_json(**kwargs)
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/object_model/model_object.py", line 76, in _update_from_json
Mar 16 20:19:19 delta DuetPluginService[2181]: setattr(self, attr_name, attr.update_from_json(json_value))
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/object_model/model_collection.py", line 55, in update_from_json
Mar 16 20:19:19 delta DuetPluginService[2181]: self.append(self._item_constructor().update_from_json(item_to_add))
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/object_model/model_object.py", line 93, in update_from_json
Mar 16 20:19:19 delta DuetPluginService[2181]: return self._update_from_json(**preserve_builtin(data))
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/object_model/model_object.py", line 69, in _update_from_json
Mar 16 20:19:19 delta DuetPluginService[2181]: setattr(self, json_key_snake, json_value)
Mar 16 20:19:19 delta DuetPluginService[2181]: File "/usr/lib/python3/dist-packages/dsf/object_model/spindles/spindles.py", line 38, in active
Mar 16 20:19:19 delta DuetPluginService[2181]: self._active = int(value)
Mar 16 20:19:19 delta DuetPluginService[2181]: ^^^^^^^^^^
Mar 16 20:19:19 delta DuetPluginService[2181]: TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
Mar 16 20:19:19 delta DuetPluginService[838]: [info] Plugin PyDaemon: Process has been stopped with exit code 1
I haven't done much digging, but my immediate thought is that all I've done in the script so far is a subscribe_connection.connect() which has succeeded first time (not needing any retries) and then the om = json.loads(str(subscribe_connection.get_object_model())) failing doesn't seem like I've done enough for it to be a problem in my code... (om at this point is empty - om = {} among the global variable definitions).
My full plugin python file: pydaemon.py (though that's one in which verbose and vTS are False).
@T3P3Tony said in delta Z motor goes clunk, regardless of motor or driver:
Please try 3.6Beta3 to confirm if the issues is resolved or not
https://forum.duet3d.com/topic/37289/software-version-3-6-0-beta-3-now-available
Apologies for the long delay to get back to this. I didn't try any of the betas, but I've done some multiple test cases now with 3.6.0-rc.1 and no clunks for any case. I've only tried ZVDDD input shaping (that's what I was using that clunked), but I have tried varying the other things that seemed to influence it and not triggered anything untoward.
Thanks.
@flo1990 said in Fan Spinning at 0:
sanyo 9gax0412p3s001
That fan is expecting a 25kHz PWM and you're only giving it 250Hz, might be relevant.
My reading of the data sheet is that it should stop at zero PWM (the closely related 9gax0412p3s003 does not stop). I would try a higher frequency and at the higher frequency you may well need a pullup.
Note that the 'Intel spec' for 4-wire PWM is non-specific on the pullup - it specifies that the fan should have a pullup, but not how strong it needs to be. It seems to me that many fan manufacturers read it as requiring a pullup that's strong enough only to force an unconnected PWM wire high (i.e. very weak indeed). Such a weak pullup is not useful at 25kHz.
Duet seem to interpret the requirement as meaning that the fan should have a pull-up that's strong enough to be relevant at 25kHz, so the duet boards just pull the PWM line to 0V and don't drive it high in between.
Older Noctua fans seem to have a fairly strong pullup and work fine on Duets. I've had several other brands that do not (CUI, Delta) - see e.g. https://forum.duet3d.com/topic/35576/trouble-with-delta-fan. These days I add a pullup to any 4-wire fan - generally somewhere in the vicinity of 4kohm to 1kohm.
Try cleaning your printhead fans.
I wouldn't believe it myself if I hadn't seen it, but if my hotend fan accumulates fibres tangled on the fan blades, the smart effector generates spurious triggers. Even a little crud (not enough to make any human-discernible change in fan performance) results in about 50% of probe attempts coming back as 'already triggered'. Removing the crud makes it go away.
I'm not the only person to have reported this experience.
@T3P3Tony said in Run out of inputs on Duet 3 Mini 5+:
@fcwilt one option is to use a SAMMYC21 development board over CAN.
I note the chip45 link on https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Using_the_Sammy-C21_development_board_with_Duet_3 is broken - it should now be https://www.chip45.com/Microcontroller-Modules-Boards/Sammy-C21-ATSAM-Duet3D::4.html
Just to say (for the record): resolved by Duet3D, I'm very happy with the solution, thanks.
Now both my printers have functional magnetic filament sensors.
I've just bought an apparently 100% genuine and unused magnetic filament monitor kit on ebay. Slightly unexpectedly it turned up as a v1 magnetic assembly one (the listing photo was a v2 magnetic assembly, but hey-ho).
However, the ring magnet rotates freely on the brass shaft. I thought maybe I was imagining it, so I put some dots of sharpie marker on:
becomes:
It seems to me there's no point proceeding to try and assemble this, because if the magnet rotates independent of the hobbed assembly it's just not going to work. I assume that's so?
Next question - is there any way to buy just the magnetic assembly? (I suspect not, but worth asking...)
https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family/Duet_3_Roto_Toolboard under "Operating limits" lists the stepper current limits as "Up to 1A peak current, 1.1A RMS". One of these figures must be wrong, I think. Further up teh page it repeats 1A peak, so I suspect it's the RMS that's wrong.
It occurred to me to check some other input shapinng:
M593 P"zvd" F37 clunks more softly and at different movements: in the 1200 acceleration case (which clunks under zvddd other than 12-26) it clunks for movements above xval=22
M593 P"zvdd" F37 clunks intermediately loudly, but at different movements: in the 1200 acceleration case (which clunks under zvddd other than 12-26) it clunks other than xval=8-24
So I also tried varying teh frequency
M593 P"zvddd" F74 and M593 P"zvddd" F18 both clunk and not-clunks differently to F37
@droftarts Aha! Excellent, thank you. I was just about to figure out how to try it standalone, following @Phaedrux 's request. I confirm that if I run mine SBC mode without input shaping I have no clunks. Since the cause has been narrowed this far and repeated by someone else, I'm not inclined to work back through old firmware versions, unless really likely to make teh difference between solving it and never resolving it, but I could try some older versions if it will make a big difference to tracking down the problem - please let me know.
Input shaping as the 'cause' stacks up because I only relatively recently put on a toolboard, and it's only when I got the toolboard (with the accelerometer) that I enabled input shaping. So although I hadn't made the connection that that's when clunks started, with hindsight it's very credible it was at about that time. I don't run it fast enough to really need input shaping anyway - the quality enhancement is debatable, and it's more a case of enabling it because it's there, so disabling it is not a hardship.
Thanks everyone for input, I'm now clunk free (though I also have a printer in pieces, so I need to spend some time re-assembling).
@droftarts no, no config-override.
I've tried taking teh test case that clunks and rotating it 120 degrees about the global z-axis, and running taht to see if teh X tower motor then clunks. All teh moves are then teh same relative to X tower as teh clunking case were relative to Z tower. However, when I do that, nothing clunks.
This is my rotated test case:
; test clunking for varying coordinates
; rotated 120 degrees about Z
G1 X56.292 Y32.500 F9000
G4 P100
G1 X43.292 Y55.017
G4 S3
G1 X56.292 Y32.500 F9000
G4 P100
G1 X42.792 Y55.883
G4 S3
G1 X56.292 Y32.500 F9000
G4 P100
G1 X43.292 Y55.017
G4 S3
G1 X56.292 Y32.500 F9000
G4 P100
G1 X42.792 Y55.883
G4 S3
@Phaedrux it's on the Z-tower motor, regardless of which physical motor or which driver that is. I've tried three different motors and four of the drivers on the 6HC board, in various combinations, whatever is defined as Z-tower motor clunks. The motors and drivers that clunk when they are Z do not clunk when they are X or Y.