@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
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!
Here is one more photo showing the canbus wiring. We are really liking this method over soldering the pigtails.
Big shout out to @Zapta for the assistance with this as it was based on his open source design. @PCR - we looked at your design as well..
We decided to create a HAT (of sorts) for v1.2 of the toolboard. It's job is primarily to smooth the large-ish cooling fan we've chosen which does not react well through PCM. It also splits the thermostatic fan for the hotend to operate the cooling fan on the board itself.
The 4 plugs that are unused in the front are input/outputs for the CanBus. It will allow us to use the JST XH pigtails as jumpers to the board and then terminate our wiring using the larger JST PH connectors.
@T3P3Tony - this is why we don't want you to sunset v1.2 of the toolboard! 
@chrishamm - When building DSF, the build process clones a copy of DWC, builds it, then deletes the clone. I have modified the common.functions file to build from our local repository and not remove it afterwards.. but is there a better way to handle this? I have not found a way to do this without modifying code due to the clean-up routine deleting the source folder. Thanks
@dc42 - bumping this.
** edit ** I was able to rebuild the deb file and resign it with the updated 3.4.6+ firmware. Still would like to know if there will be a 3.4.7 prior to 3.5's release though.
Thanks
@oozeBot said in Array index out of bounds error on object model node:
@dc42 - has there been any further consideration of releasing 3.4.7 of RRF? Or could you provide me the 3.4.7 deb file for our package server? The issue is that during the apt-update process, it tries to downgrade from 3.4.6+ to 3.4.6.. Thanks
@dc42 - has there been any further consideration of releasing 3.4.7 of RRF? Or could you provide me the 3.4.7 deb file for our package server? The issue is that during the apt-update process, it tries to downgrade from 3.4.6+ to 3.4.6.. Thanks
@chrishamm - thanks for the nudge on where this is parsed. We were on the fence about building custom versions of DSF (we wanted to keep these stock), but for now, we went ahead and rebuilt for publishing on our package server.
What we did was added a new custom parameter that can be added into the End G-Code section:
;TYPE:Custom
; OBJ_HEIGHT: 24.23
which results in:
@chrishamm Placing a G1 Zxx.xx at the very end of the file fixes the issue. While I understand this won't affect the machine's travel, I'm not thrilled with this being the solution.
Perhaps a marker could be added similar to NUM_LAYERS which, when present, would populate the Object Height without further scanning of the file?
@chrishamm This makes sense and is likely the culprit.. The last layer change on this file is at line 2013568. The last line in the file is 2034064. That's a bit over 20000 lines and I bet it is scanning way less than that.
Here is the ending gCode (minus comments) for one of the files which fails to parse Object Height. The routine which runs after the job is complete is encapsulated in the custom mCode M9001.
Perhaps it has to do with M486? I believe that was introduced as a feature in PrusaSlicer 2.7.1?
I can provide a full file if necessary.
G1 X263.999 Y139.759 F12000
G1 F6000
G1 X260.696 Y143.062 E.21742
G1 X260.707 Y142.418 F12000
G1 F6000
G1 X263.354 Y139.77 E.17427
G1 X262.488 Y140.003 F12000
G1 F6000
G1 X260.949 Y141.542 E.1013
M486 S-1
G10 ; retract
M9001
;TYPE:Custom
That huge file in the screenshot that is over 500MB was uploaded moments before I took the screenshot - Object Height reads just fine. So it's definitely a head scratcher..
@dc42 - any insight as to what is going on or what RRF uses to calculate Object Height? FYI - our slicer profile already injects the following in the "End G-Code" section as suggested in several other threads.
;NUM_LAYERS [layer_num]
@Phaedrux No - our test deck has some very large files that work just fine.. we haven't pinpointed what's causing it, but it appears to have something to do with multiple objects.
