Switching between RRF and Klipper back and forth

Triet

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

droftarts

@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

droftarts

@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

Triet

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

Triet

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

jay_s_uk

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

Triet

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

jay_s_uk

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

Triet

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

dc42

@Triet there is a 2-drive daughter board that provided two extra drivers on the Mini5+. https://www.duet3d.com/duet3expansionmini2plus