Posts made by chrishamm

@timschneider DSF has a lot more memory available so it's very unlikely to get it to crash. If long G-code replies are not released quickly enough in standalone mode, that can lead to output buffer starvation which makes the whole webserver unresponsive (for a few seconds at least). That's why I proposed to call rr_reply relatively frequently from "bot" clients. The other issue which had to do with failed SPI transfers is being investigated.

@DIY-O-Sphere It is supported by DSF 3.6.0-beta.1 and later, too.

@Tinchus That's expected. When you upload a new daemon.g, the current daemon.g is moved to daemon.g.bak. My daemon.g looks like this so the new file is automatically restarted when needed:

if fileexists("/sys/daemon.g.bak")
  M472 P"/sys/daemon.g.bak"

while !fileexists("/sys/daemon.g.bak")
  ...

@DocTrucker That's right, but you could enable the Telnet port if you wanted to.

@DocTrucker Yes, port 80 should suffice. If you want to enable more services like SSH you will need to open those ports as well. For updates from the SBC you should permit outgoing HTTPS connections.

@timschneider I've logged this here: https://github.com/Duet3D/RepRapFirmware/issues/1074 But since you need to poll rr_reply for certain codes anyway, that solution probably isn't really applicable as a fix for your other problem.

chrishamm created this issue in Duet3D/RepRapFirmware

open [FeatureRequest]: Add option to rr_connect request to prevent G-code replies from queuing up #1074

@timschneider Thanks for the report. I've logged this at https://github.com/Duet3D/RepRapFirmware/issues/1073

chrishamm created this issue in Duet3D/RepRapFirmware

open [Bug]: Long G-code replies can crash WiFi boards in standalone mode #1073

@timschneider Yes, for the time being I suggest you request rr_reply as well. AFAIR G-code replies are saved up to 8 seconds. We need to discuss how connections from "bots" could be handled better, perhaps an extra key for rr_connect could be added to indicate that the new client does not wish to poll G-code replies.

@timschneider What HTTP clients do you have connected and do you have a PanelDue attached, too? It looks like the G-code reply (e.g. for M122) queues up because at least one client does not request it in regular intervals.

@tmreith It's either in ~/.config/wayfire.ini or ~/.config/labwc/autostart.

@Ant1 Hard to say without further details. Can you please open a new thread with the full M122 output? The journal of duetcontrolserver might help, too, see https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide#troubleshooting

@Tinchus Bookworm is the successor of Bullseye, some of the instructions are outdated. But I know of at least one other user who had to insert a custom HDMI mode in config.txt to get the screen fully working. The ones I have here all work out-of-the-box without any custom settings. To be clear, I am talking about this section:

hdmi_force_hotplug=1 
config_hdmi_boost=10
hdmi_group=2 
hdmi_mode=87 
hdmi_cvt 1024 600 60 6 0 0 0

PS: FKMS is NOT supported any more so the overlay for (FKMS) DRM VC4 V3D driver has no effect.

@Tinchus FKMS is no longer supported in the latest Debian Bookworm version, which the latest Raspberry Pi OS version is based on. Full KMS is now enabled by default, I think. I suggest you follow the instructions here and check if you get it working again then: https://www.waveshare.com/wiki/7inch_HDMI_LCD_(H)_(with_case)#Working_with_Raspberry_Pi

@Tinchus So this one? https://www.waveshare.com/wiki/7inch_HDMI_LCD_(H)

@Tinchus Did you try this? https://www.waveshare.com/wiki/7inch_HDMI_LCD#Software_Setting

Raspberry Pi OS and DuetPi are nearly identical. If you don't get proper touch events, you may need to switch back to the Wayfire display server using the rpi-config tool (AFAIR that was in the "Advanced" menu).

On behalf of the Duet3D team I am happy to announce the availability of our next prerelease software bundle v3.6.0-beta.3.
This version features many bug fixes and improvements. Please refer to the changelogs for further details:

• RepRapFirmware
• DuetWebControl
• DuetSoftwareFramework

Users in standalone mode can obtain the latest builds from here. Users in SBC mode can upgrade using M997 S2 provided the unstable package feed is activated. This can be done using M997 S2 F"unstable". Please note that M997 S2 is NOT available on the meanwhile outdated Debian Buster build of DuetPi. Please check out this guide if you are still using an old DuetPi installation.

If no further serious issues of this build are reported, this beta will form the basis of the next release candidate, which will eventually become the next stable version. If you do encounter problems, please report them here on the forum with [3.6.0-beta.3] in the title.

@SaldoT That recommendation was outdated and has been removed from the docs. Thanks for pointing it out, though!

@RodrigoRMaraujo Thanks for reporting this, it will be fixed in the next 3.5 release. Version 3.6 is not affected.

@NikA @resam I already identified and fixed this problem a while ago. A bug fix will be part of the next beta.

@jocanetto Well, what does the device manager say? The port should show up there, and you need to configure the same one in YAT.