@JoergS5
So I actually thought about the preference angles when constructing the 5 axis Voron. The printhead was designed accordingly to accommodate an A-angle of up to 90°+ (A90) while having the nozzle as close to the build plate as possible. As of now I have set the max angle at 90° but it can accommodate at least up to 110°. Also for visibility purposes it's much more preferrable than the negative A-angles. And in general on commercial 5 axis machines and CAM Software or rather post processors, the next positive C-angle is always preferred for the possible solutions. If the C-axis is freely rotating that is, some cheap trunnions for example have to turn back to 0 after 720°.

@droftarts
So I did some test prints and there were VFAs but not as bad as I would have excepted, considering the sometimes absolutely frightening resonance while the X or U axis were moving. It was actually hard to take a picture of them because they were barely noticeable. I don't have any input shaping configured yet. And some slicer settings will definitely be addressed.

I also played around with the StealthChop settings that were suggested in the TMC2209 paper. However I could't notice any impact .So I blindly tested different values for the hysteresis settings, as well as blank and off times. Good news, the motors are still alive. Bad news, I couldn't make out a difference. I got them back to the settings I started off with.

I ordered some new Nema14s. Will be interesting to see if that makes a difference and if it was a hardware problem all along.

@nie-ls
Yes swapping out the motors did actually help. Totally forgot to close this thread...
Now they are whisper quiet in stealthChop mode as they should be. Searching a problem with the most obvious solution is time not well spent. In your case I would suggest swapping out the motors too. I don't know what was wrong with mine, but I could instantly feel the difference between old and new when turning the drive shaft by hand. No resistance or indexation. Due to the fact that even damper mounts can't help in your case, I would clearly point the finger at your NEMA 17s. If you have an other NEMA17 variant to swap out, try that. Otherwise they are not too expensive, as long as you don't use any special variety.

@noobydp
I got theses ones: aliexpress
They matched the original sigma nema 14 steppers the closest. The manufacturer stepperonline is reputable and also has its own webshop. Depending on where you life and how much time you want to wait on your steppers the webshop ist the better place to order from.

@JoergS5
Perfect, I'm looking forward to tiring out the build. If everything goes to plan, I should have time to test on the printer towards the end of next week.
Thank you very much for the extra effort.

Hi there.
I'm currently building a 5-axis Voron 2.4 conversion. Included in this project is a 3D-touchprobe to locate already existing parts on the build plate. At the moment I'm setting up all the probing macros. The probing works fine for single probing points/ directions, for example:

M585 X0 P0 F600 S0      ; probe X+
G10 L20 X-1             ; set tip offset

However I'm having some trouble with the M675 command. At first it worked fine (at least 20 times) , also with combined X Y centring to find the hole centre. Video of probing cycle working: Link

M675 X F600 R1 P0	; probe x min/max, 1mm retract, probe 0
M400                    ; wait for move to finish
M675 Y F600 R1 P0	; probe y min/max, 1mm retract, probe 0
M400                    ; wait for move to finish
G10 L20 X0 Y0           ; set centre position to 0

But then, out of nowhere, it suddenly started ignoring the X+ stop (first contact X- registered). This resulted in a bent probing tip and the first scar on the buildplate. After a power cycle I started testing with a plastic bottle cap and some painters tape. I tested X and Y separately. Sometimes the X+ would also register but the middle position would not be calculated correctly (stopped short of middle position). Y probing same story. Also, sometimes the machine coordinate limits would work fine but other times, these were ignored as well. Without changing any of the code or other parameters it stated working again after the next power cycle but returned shortly after. Also, it's not on the hardware side, I checked the wires (NO-probe).

I think it would be nice if these probing cycles were reliable.
Could it have anything to do with the flash memory limitations of the Duet2?

Duet2 Wifi + DueX5
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.5.0-beta.3 (2023-04-14)
Probe definition:

M558 P5 C"!duex.e6stop" K0 H5 F600 T3000 B1 											

Thanks in advance

@JoergS5
I think in "normal" simultaneous and dynamic operation it's actually not that likely to be near that +-90° window. Especially if you think about the printing of convex or concave shapes. The 90° angle is more likely with a stationary A-axis (radial rotary printing) or AC-axis stationary when printing "normally" on the side of a cube for example. This obviously depends on the use case. I don't know how this affects the accuracy when one or both of the rotaries are stationary.

@JoergS5 said in CoreXYAC / 5-axis Voron / M669 kinematics configuration:

I add a requirement to store the absolute degree of the C axis, so a limit to +-720 can be set. I'm not sure whether the slicer or firmware shall rotate back the C axis when this limit is reached.

Well this could either be handled in the slicer but more likely in the post processor. When the angle goes over +-720 you subtract the int-multiple and set back the position with a G92 accordingly next to 0. This would be my first and dirty solution. No idea if there would be a more refined method.

@JoergS5
So I actually thought about the preference angles when constructing the 5 axis Voron. The printhead was designed accordingly to accommodate an A-angle of up to 90°+ (A90) while having the nozzle as close to the build plate as possible. As of now I have set the max angle at 90° but it can accommodate at least up to 110°. Also for visibility purposes it's much more preferrable than the negative A-angles. And in general on commercial 5 axis machines and CAM Software or rather post processors, the next positive C-angle is always preferred for the possible solutions. If the C-axis is freely rotating that is, some cheap trunnions for example have to turn back to 0 after 720°.

@dc42
Thank you for the clarification.
So this basically this means no onboard kinematics until a robot code version is released and I created a custom fork for the Duet2 with every unused pin und unnecessary feature disabled? Or just upgrading to a Duet3 6HC+3HC?

But the Duet2 should be able to handle 5-axis simultaneous movement when the kinematics model is calculated externally and just fed in as XYZAC coordinates? Or do I already need to disable features now/ is there a way to monitor the flash memory used?

Hi guys.

Short Intro:
I built a 5-axis Voron 2.4. Mechanically it works but I'm having trouble with the M669 kinematics configuration. (Duet2 Wifi + DueX5)

Long Intro:
So, I'm currently in the final phases of my study to become a mechanical engineer. As part of my bachelor thesis, I got the task to develop a 3d printing system which can be used to functionalize already existing plastic parts e.g. printing geometries on injection moulded parts. This was the perfect task for me because on the one side I know my way around 3d printers and as a CNC-Machinist by trade I have already worked with 5-axis CNC machines.
So after a short research phase I settled on converting a 350mm Voron 2.4 to 5-axis using duet boards and RPF, mostly because I'm already familiar with the firmware and it's the only one capable of handling the 5-aixs stuff.
I mainly developed three key components: AC-axis trunnion, custom printhead because of the necessary clearances and a 3D-touchprobe-tool to locate the parts in space.


Current status:
Mechanically and electrically, everything works. For the setup process I put it in the standard coreXY mode M669 K1. Homing for all the axis works perfectly (A- and C-axis do also have homing switches). A is constrained +/- 90°, C is free to rotate indefinitely.

Problem:
In my research concerning the feasibility of the project I stumble upon all the duet documentation regarding the "robot" stuff: Robot Docs. I found my way to the 5-axis CNC page (5-axis Docs) and discovered a already existing configuration for CoreXYAC. So the command M669 K13 B"robotType=CoreXYAC" should solve all my problems.
Turns out I was a bit too optimistic there. When implementing M669 within the config.g file I get the following message:
Am I correct in the assumption that those types are not implemented in RPF 3.4.5 or are other previous configurations needed before the M669 command?
So even if I must configure the kinematics matrix myself, it's hard for me to find the correct information, as it's obviously quite a niche application and the information is fragmented across different pages. For example: The M669 command is featured much more in depth on the robot config page than on the gcode repository for M669.
If someone already has any help, insight or information regarding this topic, your support would be much appreciated.

Thanks in advance
Dan

PS: I looked a lot at the OpenX5 repository from Freddie Hong but all the kinematics stuff is handled in the grasshopper/ rhino setup and not on the Duet. Due to the fact that we are planning to use commercial 5-axis slicing software this is not really a option. This printer needs to receive XYZAC lines and to move according to the kinematics model.

@noobydp
I got theses ones: aliexpress
They matched the original sigma nema 14 steppers the closest. The manufacturer stepperonline is reputable and also has its own webshop. Depending on where you life and how much time you want to wait on your steppers the webshop ist the better place to order from.

@nie-ls
Yes swapping out the motors did actually help. Totally forgot to close this thread...
Now they are whisper quiet in stealthChop mode as they should be. Searching a problem with the most obvious solution is time not well spent. In your case I would suggest swapping out the motors too. I don't know what was wrong with mine, but I could instantly feel the difference between old and new when turning the drive shaft by hand. No resistance or indexation. Due to the fact that even damper mounts can't help in your case, I would clearly point the finger at your NEMA 17s. If you have an other NEMA17 variant to swap out, try that. Otherwise they are not too expensive, as long as you don't use any special variety.

@lem
I have tried playing around with the blank time (M569 B) and the off time (M569 F). Between these two and the minimum step puls width (M569 T a:b for TMC2209) I suspect the solution for my problem. However playing around with the T parameter is not easy because it needs to match with the other parameter combination or the control will not accept the change (bad timing error). The only way to analyse all those changes correctly would be to have a readout on a oscilloscope. But I don't have one and wouldn't be able to interpret the results anyway.
I will have at least some clarity on my theory once the new motors arrive and they behave differently or the same.

@droftarts
So I did some test prints and there were VFAs but not as bad as I would have excepted, considering the sometimes absolutely frightening resonance while the X or U axis were moving. It was actually hard to take a picture of them because they were barely noticeable. I don't have any input shaping configured yet. And some slicer settings will definitely be addressed.

I also played around with the StealthChop settings that were suggested in the TMC2209 paper. However I could't notice any impact .So I blindly tested different values for the hysteresis settings, as well as blank and off times. Good news, the motors are still alive. Bad news, I couldn't make out a difference. I got them back to the settings I started off with.

I ordered some new Nema14s. Will be interesting to see if that makes a difference and if it was a hardware problem all along.