Posts made by oozeBot

@MJLew yes, I did. I need to go back to it and find time rework the way your code handles z as that tripped up my processor, but I don't believe it will be a huge change. It also made me realize the codebase doesn't currently handle vase mode. I'll tackle both soon.

I had some free time this week and added a "GCode Navigator" to scrub the job file. Screenshot and quick video of how you can scroll to move through the file using it.

Recording 2025-05-16 184122.mp4

@Phaedrux I actually spent a bit of time early today trying to visualize just that! But I can't figure out the best way to do that when it's over a full 360 degrees. I mean, this works, but it still requires a bit of math in your head.

Our build plates use a 9-point bed leveling system with the center point being fixed. Now that I've gotten the hang of plugins, I created this to assist with bed leveling.

Sorry, but at this time, this one is proprietary to our printers. But perhaps, it will spark someone else's interest or if someone has ideas on how to make this work for other printers, we'll see about providing a generic version.

It takes the heightmap and extrapolates the actual adjustment points on our build plates to provide the number of degrees and direction needed to bring that point exactly inline with the center, fixed, point.

I got to test this one today, and yeah, it's pretty darn handy!

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.

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.

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

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.

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

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

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

@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

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

@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

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

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.

@chrishamm Thanks! That’s the nudge we needed- It’s definitely a permission issue. We’ll get it sorted.

Bump.. So far I have not been able to find any logging or details on why it is returning a 500 error. Note that any invalid URL returns 404, so DSF is picking up that it's been registered.

Maybe the example is from a previous version of dsf-python and needs updating? Please advise as we do have a use for this and are quite motivated to put it into practice. Thanks

@chrishamm @Falcounet

We are evaluating the custom_http_endpoint.py example located at
https://github.com/Duet3D/dsf-python/blob/main/examples/custom_http_endpoint.py. We are running dsf-python-3.4.6.post4. The example is returning a 500 error and we are unsure how to debug it to move past it. Here is the output from the console while running:

send: {"mode":"Command","version":12}
recv: {"success":true}
send: {"command":"AddHttpEndpoint","EndpointType":"GET","Namespace":"custom","Path":"getIt","IsUploadRequest":false}
recv: {"result":"/run/dsf/custom/getIt-GET.sock","success":true}
Try accessing http://duet3.local/machine/custom/getIt in your browser...

Any thoughts on what might be wrong? Thanks in advance.

@chrishamm That all makes sense. I like being able to build it all together as DWC builds pretty quickly on our build server but yeah, bypassing DWC if it hasn't changed is a good idea. I just wanted to make certain I wasn't overlooking a flag or something but didn't know how I could be after reviewing the code. Thanks

@infiniteloop we’ll discuss- not against it at all but would want to spend a bit more time on the design and then have a few made for verification before posting based on the initial batch we received. We have a lot going on at the moment but will revisit soon!