Switching between RRF and Klipper back and forth
-
I am encountering some limitations from using a Duet 2 WiFi and current RRF and am tempted to try Klipper, but just as an experimental alternative, because I would like to keep RRF as my default firmware as long as it can catch-up with Klipper.
My first idea was to install an additional Klipper driven board and make all connections to the controller board switchable by a multiple switch, in a way that I can use the firmware of my choice at any time, but this would exclude using toolhead boards as they are either for one firmware or the other (including things like Eddy).
My second idea is to completely replace the current Duet 2 WiFi by a new controller board that is capable of running either Klipper or RRF by just loading/flashing it quickly to the board every time I switch between them. Which board would then be suitable for this? I do not exclude using an additional Raspberry Pi (and I think that some companies offer boards with a built-in RPi?).
At this point I admit not to fully understand the role of RPi when using it in combination with a Duet board - is the RPi used to implement additional features (like multisession FTP, camera connections...) or will the RRF firmware actually run on the RPi and delegate low level commands (for stepper movement for example) to the Duet3 board similar as Klipper does?
If the latter is true, then my third idea would be to add an RPi board to my Duet 2 WiFi and load the firmware flavor of my choice every time I want to switch. I assume that a RPi running Klipper would be able to use a Duet board to low-level control the hardware.
If you find my ideas fallacious - let me know. I appreciate any comment!
PS: There is a "compute module" version of RPi (without interfaces), which is intended to be plugged onto a custom PCB. I wonder if any 3d printer controller board exists where this RPi variant can be used. A Duet host PCB with such a compute module RPi would be a fantastic idea.
-
@Triet Probably easiest just to connect a Klipper-ised RPi to the Duet 2 WiFi, via USB, and install Bossa on the Raspberry Pi. When you want to run Klipper, flash the MCU firmware. When you want to run RRF, flash the Duet 2 with RRF using Bossa and use it in standalone mode. You can probably leave the SD card in the Duet, as the Klipper doesn't use it.
What limitations are you finding at the moment? The Duet 2 is getting a bit old now, and is limited by the size of the flash memory for all the current RRF features, but generally that's just extra kinematics.
Ian
-
@droftarts Your proposal goes along my 3rd idea and would be the easier option indeed. I guess that hardware limitations (like lack of CAN-FD connectivity) would remain no matter which firmware flavor is loaded.
I don't necessarily prefer the easiest solution though, nor the cheapest one.
But this solution would be a viable transition to a modern board.
The main RRF limitation that I am bitterly missing is the ability to smoothly change pressure advance values on the fly (while printing). This prevents me from using adaptive PA, which has proven to amazingly improve quality of prints comprising wide speed and acceleration ranges. By the way, Klipper had the same issue, but it is fixed now.
-
@Triet said in Switching between RRF and Klipper back and forth:
At this point I admit not to fully understand the role of RPi when using it in combination with a Duet board - is the RPi used to implement additional features (like multisession FTP, camera connections...) or will the RRF firmware actually run on the RPi and delegate low level commands (for stepper movement for example) to the Duet3 board similar as Klipper does?
Sorry, I didn't reply to this part. Klipper and RRF use the Raspberry Pi in very different ways. In Klipper, the RPi runs the 'firmware', ie interprets the Gcode commands, and sends packets of step instructions to the MCU, usually via USB. It also provides the user interface, and reads back information from the MCU (eg temperatures, sensors etc). This is where Klipper is not 'real time'; there's a delay between something happening and the controller (the RPi) being able to respond. Klipper also has an issue with running macros, as these are 'precompiled' before sending to the MCU, so are difficult to interrupt. It also does not do CAN well, but can more MCUs can be connected using additional USB leads, it's just not quite as 'industrial' as proper CAN connectivity.
RRF still runs the Gcode on the MCU, even when connected to a RPi. The RPi takes over the file management, and streams the Gcode to the MCU for interpretation. It also takes over the user interface, and updates it with information retrieved from the Object Model stored on the MCU. This means the firmware on the MCU is still doing the 'realtime' work, and can interrupt any process in realtime too. CAN-FD is implemented on the MCU, as well as multiple motion systems and meta gcode, both features that there are not parallels for in Klipper as far as I know. For advantages of running RRF on RPi rather than standalone, see https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup#introduction
Ian
-
@Triet said in Switching between RRF and Klipper back and forth:
The main RRF limitation that I am bitterly missing is the ability to smoothly change pressure advance values on the fly (while printing).
I asked @dc42 about this. He replied:
Adding support for different pressure advance per move would increase the size of the DDA (movement record) by 2 or 4 bytes. It would also require changing the CAN motion messages, which would reduce the number of drivers that can be attached to an expansion board (or a main board in expansion mode). So I'd rather implement nonlinear pressure advance, which has also come up in the forum. Maybe it's the same user who asked about it, I don't remember.
So, not impossible, but sounds like it might be a lot of work and come with trade-offs.
Ian
-
@droftarts I am convinced of the architectonic superiority of RRF compared to Klipper and I very much appreciate that, which is why I think I will stay at RRF. I happens that I use my 3d printer to tinker with (I do not need to print anything particularly important, and it is not a business) and am curious about Klipper due to its popularity.
I think that a compute module RPi on a Duet PCB would be a great solution, adding computational resources but keeping the quality of the Duet hardware, and still adding a lot of flexibility. I mention that because I have read that the argument against implementing an RPi based RRF board has been cost caused by the plethora of (not needed) interfaces; in this case that argument does not apply.
-
@droftarts I would welcome non-linear pressure advance! Some Klipper users prefer this model as it has already been implemented in the "bleeding edge" Kalico version of Klipper. That is exactly what I am after. The mentioned disadvantages are a question of a smart implementation, perhaps demanding a more deep re-write of the software, but still possible and worth doing it. Don't take me wrong, I am aware of the significant effort needed, but I consider this feature a "must".
-
The duet 3 mini is an easy board to swap between RRF and klipper due to being able to double tap the reset button and load firmware that way.
I tend to use mellow boards in my printers and I can swap between RRF, klipper and marlin with the same board -
@jay_s_uk Thanks! So Duet 3 mini and Mellow boards. Any partikular Mellow recommendation? I am gathering my options and would rather avoid having to check all possible boards, specially on Aliexpress, as their product description is quite confusing to me.
-
@Triet super5 or super8pro.
If you go with one of those you have to buy the WiFi module separate. There's either the esp32 or esp32 with ethernet.
https://teamgloomy.github.io/fly_super5pro_h723_general_3_5.html
A H7 version of the fly-e3-pro-v3 is due out imminently too (this means CAN-FD support) -
@jay_s_uk The Super8pro looks impressive with 550MHz (don't know if that translates to so much faster). Its H7 version is available.
The Duet 3 mini5+ has only 5 stepper drivers, I need 6 (I know there are extension boards but I would prefer avoiding that if possible).
-
@Triet there is a 2-drive daughter board that provided two extra drivers on the Mini5+. https://www.duet3d.com/duet3expansionmini2plus