Urgent: RRF 3.2 Messed Up Delta Auto-Calibration
-
I just ran a bunch of tests in different modes and with different firmware versions. I'm sick of doing it. What it boils down to is:
- with RRF 3.1.1 in SBC mode, everything runs fine, nothing ever gets skipped
- with RRF 3.2 in SBC mode, things occasionally get skipped, no errors get generated that I can see (checked M122 and /var/log/syslog)
- with RRF 3.2 in standalone mode, everything runs fine, nothing ever gets skipped, and everything runs measurably faster (!!!)
That last point is relevant. I thought it might just be my imagination, so I made a video to be sure:
Note that for the clip in the bottom-left corner (the one labeled "failed"), the printer doesn't just quit after it fails to do the bed mesh probing. It pauses for a bit while the nozzle heats up to printing temperature and then proceeds to print, but I stopped the job after the bed mesh probing failed to happen.
As can clearly be seen, the board in SBC mode runs exactly the same between 3.1.1 and 3.2 (when it doesn't fail). However when running in standalone mode with 3.2, it's significantly faster. There's no hesitation between moves. It just flies from command to command and gets stuff done quicker. I do find it somewhat interesting that the failed run is slightly faster than the two on the right side.
"But maybe it's because of your longer ribbon cable?"
Nope... the video with firmware 3.1.1 was taken with the standard ribbon cable that's provided in the box.
Maybe someone needs to explain to me the advantage of SBC mode, because I'm not seeing it. It's more restrictive in many ways, it's slower, and now it's become less reliable. I don't get it. I give up. I'm switching everything to standalone mode and I'm leaving SBC mode far, far behind until someone explains to me why I should put up with the compromises it imposes.
-
@GoremanX I'm sorry the problem is still there in SBC mode. I'll write some more tests to see if I can provoke it if I keep probing repeatedly with my Delta printer. Our configs are nearly identical so I'm really suprised I haven't been able to reproduce it yet.
The connection between your Duet and Pi looks OK to me. To address the hesitation between single probing moves I have more performance improvements planned for v3.4, usually they happen when a G/M-code requests file data. That may take a short moment because RRF cannot access the SD card immediately like in standalone mode. During prints this isn't a threat though, because RRF keeps several codes in a buffer to ensure continous smooth movement.
The main advantages of SBC mode remain
- faster network speeds
- support for HDMI screens wthout extra network connection
- third-party plugins (with simple plugin management via DWC coming in v3.3)
- HTTPS support (easily configurable via M586 in v3.3)
- optional usage of other Linux applications
I'll let you know when I've made more progress on this issue.
-
@chrishamm I can attest to the faster network speeds. It's much, much faster to upload gcode files to the printer in SBC mode than in standalone mode. This makes a big difference with larger files (50+MB). Like orders of magnitude.
As far as wiring, in SBC mode I need:
- a 26 pin ribbon cable that must be restrictively short
- 1 USB-C wire for power to the Pi (the ribbon cable is insufficient to power my 2GB Pi4B +monitor without triggering warnings)
- 1 micro-USB wire for power to the Pi touchscreen
- 1 ridiculously long, delicate DSI ribbon cable between the Pi 4 and Pi touchscreen (it's not HDMI)
- I also once had a ridiculously long DSI ribbon cable between the Pi 4 and a Pi HQ camera, though the long cable was wrecking the images so I had to remove that
The long ribbon cables to the camera and monitor are specifically due to the location of the Pi, tucked under the printer because of the limit imposed by the 26 pin ribbon cable. Wifi signal is also poor there. So while uploading files is much faster, browsing the web or updating the system files on the Pi is slow.
In standalone mode I need:
- a single USB-C power cable with Y splitter to power both the Pi and touchscreen
- a network cable between the Pi and Duet 3
That's it! There's no practical length limit. The Pi sits in the monitor's plastic housing way up on the side of the printer. The flimsy ribbon cable between them is inside that housing, it's like 80mm long and irrelevant. The whole thing is out in the open getting great wifi reception. I can now connect it directly to the camera with a short cable.
Incidentally, are the CAN diagnostic numbers relevant at all? I 'm not sure why CAN is there since I don't use any add-on boards, and I was under the impression that CAN and SPI are mutually exclusive when it comes to communication between 2 devices, yet the "Send timeouts" in the CAN section were consistently climbing the entire time I was testing. Maybe that's just internal board messaging stuff and completely irrelevant... I won't pretend that I'm knowledgeable about communication protocols
I'd love to see an SPI-over-ethernet solution worked out to remove the distance restriction between the Pi and Duet 3. Seems like it would just take a couple of those cheap adapter hats to implement.
