Update: I got sensorless homing working on all 3 axes.
Someone suggested adjusting stealthchop/spreadcycle like this: M569 P0.3 V40 D3 and it fixed one of the axes. For the Z axis with small motors I had to go back and forth with stall sensitivity and speed. Same for the remaining axis, basically trying random speeds and sensitivities until it worked. It took a while, but it worked eventually.

@fcwilt thanks for the help.

Still got that probing offset thing to fix, but that's tomorrow.

@droftarts indeed it was the E jerk. I had it set to 4. I assumed a high E acceleration would take care of it, but it seems not.

Edit: For clarification, I meant 4mm/s, which is 240mm/min.

Left: 1K acceleration without IS.
Center: 1K acceleration with IS.
Right: 3K acceleration with IS.
Printing at 150mm/s speed on a CoreXY about the size of a 400mm cube build volume.

Is this normal?
Coextrusion filament. Looks a bit like silk, very shiny, so artifacts are emphasized.
IS, PA, and jerk are already calibrated (at least to some extent).
Running RRF 3.5.0-rc.1. (I haven't tried any other version).

It looks better if I print much slower, but still, the prints look very bad to me. I'm hoping there's a way to improve the surface considerably.

@droftarts said in Can this 5-axis FDM be configured with RRF?:

@MihaiDesigns I don't think that kinematic type is supported in the 'normal' firmware, but there is work on-going on a version of RRF that, I think, might support it, which is @JoergS5's work: https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuring_RepRapFirmware_for_a_Robot_printer

The development discussion is here, though focus is more on palletised robots (4 axis arms, basically): https://forum.duet3d.com/topic/17421/robotic-kinematics/383
This recent thread describes a machine where moves in BC move XYZ too, I think similar to your requirement: https://forum.duet3d.com/topic/35865/voron5x-with-rtcp/

Hope that helps!

Ian

I see that the robot printer still implements only AC and BC (used for the Voron5X).
Since I need this for a PoC, I guess one somewhat easy solution is to write a gcode processor that calculates the XYZ compensation when rotating A and B. I mean it would anyways be some generated gcode to print basic shapes with steep overhangs (it's one of the reasons I wanted the rotating axes).
In which case the firmware needs to move some extra axes I suppose, like G1 X Y Z U V? Then it would move all axes at the same time? And my gcode processor segments the moves into very short segments (0.2mm in length or so). Am I going the right direction here?

Posting here since it's 5 axis, but this is for a 3D printer project.
Only focusing on the rotational axes in this topic, I want to build the illustrated design so that the nozzle can rotate.

At rest position the axis closest to the end effector is parallel to the Y axis, and the next one is parallel to the X axis. Both have offsets (one relative to the other and to the end effector).
XY axes are CoreXY, Z connected to the carriage, fixed bed. So reading the documentation this would be a XYZAB or something like that? And there should be some way to configure them using M669, but am not sure the firmware has support for all the parameters. It mostly talks about AC/BC configurations where offsets are supported, but doesn't mention offsets for AB and I couldn't find a good example configuration to get inspiration from.

What I would like to get from the firmware is the IK solving so that when the g-code asks for a motion that involves A and B axes rotation, it will adjust the XYZ position so that the end effector stays in the same place with relation to the bed, but changes angles.

I'm asking here if this is supported by the firmware so that I don't invest time in building a device that cannot be configured.

Edit: here are the two vectors I'm wondering how to configure.

Left: 1K acceleration without IS.
Center: 1K acceleration with IS.
Right: 3K acceleration with IS.
Printing at 150mm/s speed on a CoreXY about the size of a 400mm cube build volume.

Is this normal?
Coextrusion filament. Looks a bit like silk, very shiny, so artifacts are emphasized.
IS, PA, and jerk are already calibrated (at least to some extent).
Running RRF 3.5.0-rc.1. (I haven't tried any other version).

It looks better if I print much slower, but still, the prints look very bad to me. I'm hoping there's a way to improve the surface considerably.

@droftarts indeed it was the E jerk. I had it set to 4. I assumed a high E acceleration would take care of it, but it seems not.

Edit: For clarification, I meant 4mm/s, which is 240mm/min.

@droftarts yes, I did check M204 and the firmware reports it correctly. X, Y, and E are all set to 15K acceleration.

I'm running a speed test and trying 15K acceleration for infill print moves. X, Y, and E axes all have acceleration limit set to 15K, and print moves are set to 15K acceleration. The interface reports the correct settings. Printing speed is close to 300mm/s. It looks right in the slicer preview (PrusaSlicer). There's no minimum layer time set.

However, during printing it looks more like under 2000 acceleration. I can't figure out why.

@Phaedrux thanks! I'm running iOS 12. I'll try downgrading the DWC.

It's an older iPad. I just upgraded to iOS 12.5.7. Still the same issue.

Update: I got sensorless homing working on all 3 axes.
Someone suggested adjusting stealthchop/spreadcycle like this: M569 P0.3 V40 D3 and it fixed one of the axes. For the Z axis with small motors I had to go back and forth with stall sensitivity and speed. Same for the remaining axis, basically trying random speeds and sensitivities until it worked. It took a while, but it worked eventually.

@fcwilt thanks for the help.

Still got that probing offset thing to fix, but that's tomorrow.

I tested firmware version 3.4.6 (updated all boards) and sensorless homing is still not working. I suspect I have an error in my configuration but can't figure out what it is.