Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. achrn
    3. Posts
    • Profile
    • Following 0
    • Followers 1
    • Topics 94
    • Posts 554
    • Best 127
    • Controversial 0
    • Groups 0

    Posts made by achrn

    • RE: Low heating element current

      @Esteban I would focus on whether your measurements are actually valid. In what situation did you take the measurement? Your H0 has no Q value, so at anything less than 100% duty (i.e. heater cold and on at full power) it's PWM at 250 Hz. Does your clamp meter measure accurately if it's a square wave at 250Hz? Even if it does, have you corrected for the less-than-100% duty?

      If you really want to measure the current personally I'd put the heater into bang-bang mode (B1 in the M307), connect an ammeter in series, and take the readings quickly as the heater element first heats up.

      posted in General Discussion
      achrnundefined
      achrn
    • RE: dsf-python-3.6.0rc1 http endpoint not working for me

      @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.

      posted in DSF Development
      achrnundefined
      achrn
    • RE: a python daemon

      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.

      posted in Plugins for DWC and DSF
      achrnundefined
      achrn
    • RE: Another weighing filament holder returns

      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.

      posted in Plugins for DWC and DSF
      achrnundefined
      achrn
    • dsf-python-3.6.0rc1 http endpoint not working for me

      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()
      
      posted in DSF Development
      achrnundefined
      achrn
    • RE: 3.6.0 RC1 python perform_simple_code not working

      @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).

      posted in Beta Firmware
      achrnundefined
      achrn
    • RE: 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?

      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]
      
      posted in Beta Firmware
      achrnundefined
      achrn
    • RE: Bed Overheating – SSR Relay Issue on Tractus T1250?

      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.

      posted in Duet Hardware and wiring
      achrnundefined
      achrn
    • 3.6.0 RC1 python perform_simple_code not working

      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?

      posted in Beta Firmware
      achrnundefined
      achrn
    • 3.6.0 RC1 python errors in OM with SubscribeConnection

      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).

      posted in Beta Firmware
      achrnundefined
      achrn
    • RE: delta Z motor goes clunk, regardless of motor or driver

      @T3P3Tony said in delta Z motor goes clunk, regardless of motor or driver:

      @achrn @SPAX

      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.

      posted in General Discussion
      achrnundefined
      achrn
    • RE: Fan Spinning at 0

      @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.

      posted in Using Duet Controllers
      achrnundefined
      achrn
    • RE: Duet Smart Effector sensitivity

      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.

      posted in STM
      achrnundefined
      achrn
    • RE: Run out of inputs on Duet 3 Mini 5+

      @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

      posted in Duet Hardware and wiring
      achrnundefined
      achrn
    • RE: faulty magnetic assembly?

      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.

      posted in Filament Monitor
      achrnundefined
      achrn
    • faulty magnetic assembly?

      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:
      PXL_20250110_194831040.jpg
      becomes:
      PXL_20250110_194857195.jpg

      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...)

      posted in Filament Monitor
      achrnundefined
      achrn
    • Roto toolboard spec error?

      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.

      posted in Documentation
      achrnundefined
      achrn
    • RE: delta Z motor goes clunk, regardless of motor or driver

      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

      posted in General Discussion
      achrnundefined
      achrn
    • RE: delta Z motor goes clunk, regardless of motor or driver

      @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).

      posted in General Discussion
      achrnundefined
      achrn
    • RE: delta Z motor goes clunk, regardless of motor or driver

      @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
      
      posted in General Discussion
      achrnundefined
      achrn