Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. oozeBot
    • Profile
    • Following 0
    • Followers 4
    • Topics 144
    • Posts 917
    • Best 172
    • Controversial 0
    • Groups 0

    oozeBot

    @oozeBot

    306
    Reputation
    203
    Profile views
    917
    Posts
    4
    Followers
    0
    Following
    Joined Last Online
    Website oozebot.com Location United States

    oozeBot Unfollow Follow

    Best posts made by oozeBot

    • Top-down gCode viewer (WIP)

      I decided to finally take the time to learn how to create plugins within the framework and thought this would be a good challenge for a first project. Yes, it's really being designed for use within our machines, but we'll likely release a "lite" version (if there is enough interest) as an external plugins outside of the "full" version that's baked into our framework. The only caveat is that this is tied to an SBC implementation (which all our machines use), so converting it to stand-alone might be further than we will want to take it.

      We already have @Sindarius excellent gCode viewer - and this is not to take away from that!

      A few key features that have been implemented so far:

      • Segmentation based gCode rendering (it splits each G1/G2/G3 into microsegments that are rendered at a precise delay so the overall move completes at the exact time expected by the associated feedrate)
      • Actual extrusion width instead of approximated (still working on perfecting this)
      • Feature type color rendering
      • Loads local files, files saved within DWC, and can sync with the current job
      • Tons of memory optimizations to keep resource utilization as small as possible
      • Play, Pause, Speed controls, and Forward / Reverse functionality

      I'm all ears for feedback on this. It is just a side-project I thought of early last week. However, I've already grown quite fond of zoning out while watching it. 🙂

      Here are some videos and a screenshot of where I currently am with it.

      gCode Plugin - recording 1.mp4
      gCode Plugin - recording 2.mp4

      Screenshot 2025-05-04 211629.png

      posted in Plugins for DWC and DSF
      oozeBotundefined
      oozeBot
    • Preview of our updated DWC UI

      Our intent with DWC is to only enhance its functionality by adding in some unique functionality necessary for our printers. However, we weren't fully satisfied with filament handling, so we overhauled it. It isn't as clean underneath as it uses globals to handles the various states, but overall, it's working well. Feedback is welcome and the final code will be released on our github.

      ab208b0a-92f9-4b98-9522-cf8d56f643ad-image.png

      posted in Duet Web Control
      oozeBotundefined
      oozeBot
    • You down with OPP? (oozeBot Post-Processor)

      We thought we'd create a thread about the initial beta of our post-processor (PP) for Slic3r-based programs (PrusaSlicer, SuperSlicer, etc) - especially with the recent threads about only probing the needed area on the build plate as that is its primary goal. Also because there isn't much info out there on building PPs and this could be used as framework for other projects.

      The project lives at: https://github.com/oozebot/OPP It is not yet documented, as I just posted it. I'll get to that soon, but will provide an overview here on how to utilize it.

      The script is written in Python, so you will need to install the latest version on your machine. OPP.py needs to be downloaded to your local machine and then referenced in your slicer under Print Settings > Output options > Post-processing scripts as follows:

      "C:\Path To Python\python.exe" "C:\Path To Script\OPP.py" 
      

      To keep it lightweight, it relies on two additional lines of code added to Printer Settings > Custom G-code > Start G-code:

      ;=== OPP HEADER ===
      ;FirstLayerMinMax: X{first_layer_print_min[0]}:{first_layer_print_max[0]} Y{first_layer_print_min[1]}:{first_layer_print_max[1]}
      

      There are several variables that are defaulted in the script that can either be altered within it for your setup or can be passed into the script on the Post-processing command line referenced above. These are documented within the script but here they are as written in the command line with a quick overview:

      "C:\Path To Python\python.exe" "C:\Path To Script\OPP.py" mesh=2 points=5 spacing=18 start=M9000 xOffset=19 yOffset=19 minGrid=0 maxGrid=300  
      

      It really only makes sense to pass in mesh and either points or spacing. The rest can be quickly adjusted in the script for your printer.

      There are 3 options for Mesh:
      Mesh=0 disables the functionality
      Mesh=1 creates a custom mesh grid utilizing points

      • example: An object where X=100 and Y=200 with 5 points will probe the X-axis every 20mm per row and probe the Y-axis every 40mm per column, generating a 25 point mesh grid

      Mesh=2 creates a custom mesh grid utilizing spacing

      • example: An object where X=100 and Y=200 with 20mm spacing will probe the X-axis 5 times per row and probe the Y-axis 10 times per column, generating a 50 point mesh grid

      As explained above, Points are used with Mesh=1 and Spacing is used with Mesh=2.

      Start is the filename or customer mCode for an equivalent of start.g (we use M9000 / M9000.g). A unique start file is needed as start.g is called prior to executing any gcode at the beginning of a job and the unique mesh grid will not be executed otherwise.

      And if you aren't using an initialization script like start.g, you should really consider converting to one!

      xOffset and yOffset are your probes offset. They are used to find the center of the custom mesh grid. This is useful to set your Z=0 in the center of the mesh instead of the center of the build plate.. because you really only care about the relative section of your build plate when using a custom mesh.

      minGrid and maxGrid are the boundaries your probe is capable of reaching. It the algorithm creates a mesh outside these bounds, the script will alert the user and no mesh will be created.

      The end result of the PP is the injection of the following code. Note the size of the mesh is different as Mesh=1 uses the exact size of the printable object(s) + 1mm where Mesh=2 creates a grid based on the spacing around the object.

      Mesh=0

      ;== Modified by OPP: oozeBot Post Processor
      ;== Source: https://github.com/oozeBot/OPP
      
      ;== Initialization script
      M9000
      

      Mesh=1

      ;== Modified by OPP: oozeBot Post Processor
      ;== Source: https://github.com/oozeBot/OPP
      
      ;== 25 point mesh grid
      M557 X73:146 Y42:137 P5
      M9000 C"mesh" X90.5 Y70.5
      

      Mesh=2

      ;== Modified by OPP: oozeBot Post Processor
      ;== Source: https://github.com/oozeBot/OPP
      
      ;== 30 point mesh grid
      M557 X72.0:162.0 Y36.0:144.0 S18.0
      M9000 C"mesh" X98.0 Y71.0
      

      Note the parameters being passed into the custom start code (M9000). They can be handled like this within M9000.g (or whatever you use).

      G28 ; Home all axes
      if exists(param.C)
      	if {param.C} = "mesh" ; Generate custom mesh grid
      		if exists(param.X) & exists(param.Y)
      			G1 Z5 X{param.X} Y{param.Y} F9000 ; Move to center of object to set Z=0
      		else
      			G1 Z5 X136 Y136 F9000             ; Move to center of build plate to set Z=0
      		M558 F200 H2.0 A20 S0.02     ; Configure z-probe
      		M561                         ; Clear bed transformations
      		G30 Z-500                    ; Probe build plate
      		M208 X-10 Y-10 S1            ; Allow negative travel for X & Y
      		M290 R0 S0                   ; cancel baby stepping
      		G29 S2                       ; cancel mesh bed compensation
      		M561                         ; Clear bed transformations
      		G29 S0                       ; Perform mesh probing
      		M208 X0 Y0 S1                ; Disallow negative travel for X & Y
      	else
      		G29 S2                       ; cancel mesh bed compensation
      		M561                         ; Clear bed transformations
      		G29 S1 P"heightmap-110c.csv" ; Load height map
      	
      M376 H5 ; Set mesh taper
      
      posted in General Discussion
      oozeBotundefined
      oozeBot
    • Duet 3 / Toolboard - significant issue when connection is lost

      We recently had the power wire leading to the toolboard fray which resulted in it losing power. When this happened, the print continued, however the BLTouch's probe extended breaking it in half.

      While this exposed our carriage needs better strain relief, we would like to request the firmware immediately pause the print if it loses it's connection to the toolboard.

      Is this possible? Thanks

      posted in Firmware wishlist
      oozeBotundefined
      oozeBot
    • RE: New Input Shaping plugin v3.4.1-b1

      One thing I just realized is that the the moves are based on max speed set in M203 - which in our case is 400mm/s - way above normal printing speeds. It might be beneficial to allow setting the speed of the moves as a parameter as that definitely plays into the readings..

      posted in Plugins for DWC and DSF
      oozeBotundefined
      oozeBot
    • RE: Duet 3 / Toolboard - significant issue when connection is lost

      @dc42 / @T3P3Tony - We need to raise this issue again to see if anything could be done about it, potentially in 3.4 as it creates a significant risk.

      What was just discovered is that if the toolboard isn't communicating with RRF, the following errors are reported but then the script continue. This is extremely hazardous for bed leveling as it continues with the homez.g script even though the toolboard/probe isn't responding.

      3/5/2022, 12:54:39 PM	Error: Failed to enable probe
      3/5/2022, 12:54:39 PM	Error: M280: Response timeout: CAN addr 20, req type 4012, RID=73
      3/5/2022, 12:54:38 PM	Error: Response timeout: CAN addr 20, req type 6037, RID=72
      3/5/2022, 12:54:37 PM	Error: M280: Response timeout: CAN addr 20, req type 4012, RID=71
      

      To us, the condition of losing connection with the toolboard is significant enough that RRF should immediately halt.

      posted in Firmware wishlist
      oozeBotundefined
      oozeBot
    • RE: oozeBot Elevate

      I wanted to post a few photos of a Halloween "torture test" we recently completed. This was printed in ABS, with no supports, using a 1.2mm nozzle. Extrusion width was 1.8mm and layer height was .4mm. It is 300mm deep x 264mm wide x 244mm high, was printed in ~17 hours, and weighs right at 3.5lbs.

      This was our first time using a 1.2mm nozzle and getting the retraction settings right to (mostly) control stringing was a challenge, but firmware retraction made the changes easy! There was some mid-air printing near the base, but that was in the design and it recovered beautifully..

      cthulhu1.jpg
      cthulhu2.jpg
      cthulhu3.jpg
      cthulhu4.jpg
      cthulhu5.jpg

      posted in My Duet controlled machine
      oozeBotundefined
      oozeBot
    • RE: oozeBot Elevate

      Check out this video Slice just posted of one of our machines in action! What they didn't mention is this 200mm tall Spider-man was printed in ABS at 100mm/s (50mm/s external perimeter) in ~8 hours!

      https://www.youtube.com/watch?v=gGw1ZOPIXSc
      03faa2cb-1f4d-4abc-8888-59fc60bf455b-image.png

      posted in My Duet controlled machine
      oozeBotundefined
      oozeBot
    • Pushing the bounds of DWC on a SBC

      I had some time today to mess with DWC today and implemented a new list view for python / bash / other scripts under System. We needed a clean way to distribute scripting updates to not-so-savvy linux users. I'm pretty pleased with it so far and would love some feedback. This will be posted to our github just as soon as version 3.4.4 of OWC (oozeBot Web Control) is wrapped up.

      New Script List
      caef0c3e-31ad-4a94-b812-9c4c66a7a012-image.png

      File Editor
      1c3941d7-38ab-42d9-a65d-55ff2dc5ade5-image.png

      New Menu Items:
      704e031b-3144-46d4-bb77-77521edbc849-image.png

      results of executing the script:
      60567f29-6d97-4941-aa1e-78f2935e2267-image.png
      6c7a92b3-e842-4e4e-9569-6f3baecdb6d5-image.png

      posted in Duet Web Control
      oozeBotundefined
      oozeBot
    • PSA - Disable RPi WiFi Power Save

      A few months ago, our machines began experiencing random failures where the SBC (we use the Raspberry Pi 4b) would become unresponsive. It was worrisome, to say the least, as it began randomly happening to all our printers. After considerable effort in diagnosing the issue, we believe the issue to be WiFi Power Save mode. After disabling, we have not experienced any further failures for several weeks.

      If/when the WiFi module 'hiccups' due to Power Save being enabled (and it's enabled by default) the SD Card will timeout as it shares the same interface as WiFi and the RPi becomes unresponsive.

      If anyone reading this disagrees, or has better insight, please feel free to correct us.

      There are several ways to disable WiFi power save mode. We chose to create a service to handle it based on information found here: https://raspberrypi.stackexchange.com/questions/96606/make-iw-wlan0-set-power-save-off-permanent

      Create a new service file:

      sudo systemctl --full --force edit wifi_powersave@.service
      

      Insert the following code and save:

      [Unit]
      Description=Set WiFi power save %i
      After=sys-subsystem-net-devices-wlan0.device
      
      [Service]
      Type=oneshot
      RemainAfterExit=yes
      ExecStart=/sbin/iw dev wlan0 set power_save %i
      
      [Install]
      WantedBy=sys-subsystem-net-devices-wlan0.device
      

      Run the following two commands and then reboot:

      sudo systemctl disable wifi_powersave@on.service
      sudo systemctl enable wifi_powersave@off.service
      

      After reboot, you can verify it is now disabled by running the following:

      iwconfig | grep "Power Management"
      

      The output should now include something like the following:

      lo        no wireless extensions.
      
      eth0      no wireless extensions.
      
                Power Management:off
      
      posted in General Discussion
      oozeBotundefined
      oozeBot

    Latest posts made by oozeBot

    • RE: Top-down gCode viewer (WIP)

      I had a bit of time to work on this some more and have began adding in object cancellation. Here is a screenshot and a quick video of it loading various files in my test deck.

      Screenshot 2025-05-07 140307.png

      Recording 2025-05-07 140227.mp4

      @MJLew - without an attached SBC, it would still be able to load a local file from your computer for rendering, but that is about all it could do. Do you mean scrub through the gcodes like this? Recording 2025-05-07 141611.mp4

      PM me if you'd like me to try one of your files.

      posted in Plugins for DWC and DSF
      oozeBotundefined
      oozeBot
    • Top-down gCode viewer (WIP)

      I decided to finally take the time to learn how to create plugins within the framework and thought this would be a good challenge for a first project. Yes, it's really being designed for use within our machines, but we'll likely release a "lite" version (if there is enough interest) as an external plugins outside of the "full" version that's baked into our framework. The only caveat is that this is tied to an SBC implementation (which all our machines use), so converting it to stand-alone might be further than we will want to take it.

      We already have @Sindarius excellent gCode viewer - and this is not to take away from that!

      A few key features that have been implemented so far:

      • Segmentation based gCode rendering (it splits each G1/G2/G3 into microsegments that are rendered at a precise delay so the overall move completes at the exact time expected by the associated feedrate)
      • Actual extrusion width instead of approximated (still working on perfecting this)
      • Feature type color rendering
      • Loads local files, files saved within DWC, and can sync with the current job
      • Tons of memory optimizations to keep resource utilization as small as possible
      • Play, Pause, Speed controls, and Forward / Reverse functionality

      I'm all ears for feedback on this. It is just a side-project I thought of early last week. However, I've already grown quite fond of zoning out while watching it. 🙂

      Here are some videos and a screenshot of where I currently am with it.

      gCode Plugin - recording 1.mp4
      gCode Plugin - recording 2.mp4

      Screenshot 2025-05-04 211629.png

      posted in Plugins for DWC and DSF
      oozeBotundefined
      oozeBot
    • RE: Any thoughts on what might have caused this 6HC to go sideways?

      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.

      posted in Duet Hardware and wiring
      oozeBotundefined
      oozeBot
    • Latest Bookworm GPIOChip weirdness

      We recently began seeing issues with our custom build installing properly on RPi5s with the following error. Interestingly enough, our build installs just fine on a fresh copy of 64-bit Raspberry Pi OS, but fails after a full-upgrade.

      [fatal] Failed to open IO device: Error 2. Can not open GPIO device file '/dev/gpiochip4'
      

      I finally had time to dive into this and have noticed that gpiochip4 no longer exists and then becomes a pointer back to gpiochip0.

      lrwxrwxrwx 1 root root           9 Apr 16 10:23 gpiochip4 -> gpiochip0
      

      Reverting our build's config.json back to gpiochip0 fixes this and everything is now working as expected.

      "GpioChipDevice": "/dev/gpiochip0",
      

      @chrishamm - this is what I was trying to ask in this thread: https://forum.duet3d.com/post/353788 Switching this back to gpiochip0 allows our build to properly update the firmware from the command line.

      Finally, if peer review proves this to be true, the documentation at the following GPIO Transfer Ready Pin section is now inaccurate. https://docs.duet3d.com/User_manual/Machine_configuration/DSF_Other

      posted in DSF Development
      oozeBotundefined
      oozeBot
    • Any thoughts on what might have caused this 6HC to go sideways?

      My personal dev system (photo below) has been sitting on my desk running happily for well over a year now completely sealed as shown. It has never had any motors connected to it (or anything else) nor had any known events that might have caused power spikes, etc. Last week, I found it doing this: Recording 2025-04-15 114733.mp4

      IMG_0019.jpg

      I guess I can't embed a video, so if you don't want to click the link, all six drivers are erroring with "over temperature shutdown, phase A short to ground, phase B short to ground." over and over..

      edit to answer the obvious - the board is cool to the touch. There is no signs of anything being "over temperature" and there is a cooling fan built in blowing directly on the board from behind.

      Perhaps something @dc42 can weigh in on? FYI - replacing the board immediately resolved the issue, so it's definitely the board.. Thanks

      posted in Duet Hardware and wiring
      oozeBotundefined
      oozeBot
    • RE: Firmware update bricked printer - SPI connection has been reset

      @chrishamm said in Firmware update bricked printer - SPI connection has been reset:

      @p8blr If it's actually caused by a system update, don't use apt to install the latest system package versions, instead use M997 S2 only to update DSF. I'll investigate.

      @chrishamm - any updates one what has caused this behavior to start happening? We hadn't noticed it until a recent apt upgrade (not Duet related). Are there workarounds to get this back on the command line? Thanks

      posted in Firmware installation
      oozeBotundefined
      oozeBot
    • RE: New experimental DuetPi Bookworm builds available

      @chrishamm said in New experimental DuetPi Bookworm builds available:

      @oozeBot Right, the Bookworm build uses a startup script to determine if it's running on a Pi 5. If it is, it makes those adjustments automatically. I'll update the documentation.

      Thanks. I just added something similar within duetcontrolserver's postinst script to do the same.

      posted in Beta Firmware
      oozeBotundefined
      oozeBot
    • RE: New experimental DuetPi Bookworm builds available

      @chrishamm - I was able to get past my issue. The documentation ( https://docs.duet3d.com/User_manual/Machine_configuration/DSF_Other#gpio-transfer-ready-pin ) states The following steps can be skipped if a Raspberry Pi is used. That does not appear to be valid for the Raspberry Pi 5 as I had to switch to gpiochip4 instead of the default gpiochip0. Thanks

      posted in Beta Firmware
      oozeBotundefined
      oozeBot
    • RE: New experimental DuetPi Bookworm builds available

      @chrishamm will you be releasing instructions on how to "roll your own" copy of DuetPi for bookworm? We have a custom version but I've not been able to get it to connect with the old instruction set as I'm receiving:

      Setting up reprapfirmware (3.4.6-3) ...
      [fatal] Could not connect to Duet: Timeout while waiting for transfer ready pin
      

      In the meantime, I'm flashing one of your builds onto an SD for testing now.

      Thanks!

      posted in Beta Firmware
      oozeBotundefined
      oozeBot
    • RE: Tool board 1.2a crimp question

      While I feel certain almost no one else on the forum can (or should try to) justify such costly terminal crimpers, I'll throw out there that these official JST crimpers are the absolute shiznit. We have both the PH and VH models. Now if only Molex had something as high quality for the KK terminals.

      IMG_9228.jpg

      posted in Duet Hardware and wiring
      oozeBotundefined
      oozeBot