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

Can you post an image of your heightmap and the bed.g and config.g files so we can see what it's actually doing?

@davidjryan does it help if you add another M400 command at line 13, to release the A axis while you still have motion system 1 selected?

How far does it move down? You have this in homez.g:

if move.axes[2].machinePosition <= 10 	; ensure nozzle is at least 10mm from bed
	G91                					; relative positioning
	G1 H2 Z10 F400     					; lower Z relative to current position
	G90									; absolute posistioning

so it will move down if it thinks the bed is too close to the nozzle.

@ash100 I suggest you get a diagnostic report on the tool board by sending M122 B75 and post the result here.

@Esteban said in Information on the distribution of calculations on Duet cards:

On the other hand, one last question: for very complex machines with a large number of axes, would it be more “efficient” to have a main 6XD and then add 1XDs and another 6XD in daughter mode?

If all the axes and extruders use servomotors then you should start with a 6XD. If there are more than 6 servos to connect then you will need another 6XD or some 1XD boards to drive them. If the additional axes need high step rates then another 6XD would give better performance than 1XDs.

@MaxGyver said in [3.6.0-rc.2] Code 3 move error:

Unfortunately not. I had the same error again while printing the firts layer.

Do you mean the same Code 3 error?

@fcwilt PCBWay seems to offer 3D printing and CNC machining as well as PCB manufacture.

Ian

@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