Duet 3 Expansion 3HC sensorless homing via CAN

tru_ann

Hello. We are developing a 3D printer that has 4 motors that are used for AWD Core-XY kinematics (like in VzBoT 3D-printer) and another 3 motors that move the table along the Z axis. The 3 Z-axis motors are connected to a Duet 3 Expansion 3HC. We would like to use sensorless homing for all motors. However, in the article “Duet 3 with CAN expansion firmware configuration limitations”, it states that “Stalls of expansion board motors cannot be used for homing. We expect to remove this restriction in firmware 3.6.” For this reason, we would like to know when approximately firmware 3.6 is scheduled for release. Thanks!

droftarts

@tru_ann Yes, expansion boards do not currently support homing using motor stalls. I'm not sure when this will be addressed; possibly not for 3.6, as it is marked as 'after 3.6' in this Github issue: https://github.com/Duet3D/RepRapFirmware/issues/698

What type of Z axis do you have? If it's driven by a leadscrew then it won't be easy to get sensorless homing working, because of the force multiplication provided by the leadscrew. If you're using belts, then another sensorless homing problem is that the homing precision is only to the nearest multiple of 4 full steps. Perhaps not so critical in X and Y, but in Z this would be bad for consistent layer height.

Ian

T3P3 created this issue in Duet3D/RepRapFirmware

closed Support stall homing on expansion boards #698

tru_ann

@droftarts We have a positive experience with sensorless homing and leadscrew on Z axis. We would not like to use endstops in terms of amount of wiring. Are there any workaround solutions to this problem?

droftarts

@tru_ann said in Duet 3 Expansion 3HC sensorless homing via CAN:

Are there any workaround solutions to this problem?

Only to connect the axes to the mainboard, but I guess that causes a problem for the 4x XY motors then. You could look at 3rd party boards like the BTT Octopus/Kraken that support 8 drivers, and run the TeamGloomy port of RepRapFirmware: https://teamgloomy.github.io/btt_kraken_h723_general_3_5.html

Ian

Cognirit

Good afternoon! I'm facing the same problem.

I am doing a scientific project, I am making a printer as a platform for researching and comparing different kinematic schemes. I expect to use up to 12 independent axes.

In this regard, I was really hoping for Sensorless homing to avoid drowning in wires. I didn't expect that an expansion board might not have full functionality. =/

And the Duet ecosystem is very much to my ideological liking in this respect.

And there is hardly any board for 12 motors

Is there any way to help the Duet project with this problem?

jay_s_uk

@Cognirit theres the fly-super8pro which can run RRF. That has 8 driver sockets and you can add another 3 using a BTT-EXP-MOT.
Or theres the Fly-ProX10, that has 10 driver sockets
That gets you to 10 or 11 where they can all do sensorless homing.

dc42

@Cognirit I can try to squeeze stall endstops for motors on expansion boards into the 3.6.0 release, but it won't make 3.6.0beta 2.

Cognirit

@dc42 thank you for reply! Am I correct that we would be best off waiting for this feature in 3.6.0beta3 or later? So as not to interfere with work on beta2?

dc42

@Cognirit yes, we intend to release beta2 as soon as we have fixed two bugs in beta1.

Cognirit

@dc42 Can you tell us if there is at least a rough prediction of when the update we need will be released at least in beta? We would love to take on testing it and actively share the results.

Cognirit

@dc42 Good day!

I noticed the release of beta3 in the project changelog.

Could you please let me know if the sensorless homing issue for the Duet3 Extension 3HC board is planned to be fixed in beta3?

Thank you!

tru_ann

@dc42 Good afternoon!
We join the question from Cognirit about issue solution in beta3. We also are very much looking forward to a soon release in which this problem will be fixed. Thanks!

gnydick

I didn't know this was a limitation of the expansion boards. I ignorantly went out and got the 3HC, converted my RailCore to AWD and sensing works. My 3HC is CAN ID 1 and I see messages in the console that tell me driver 1.0 or 1.1 stalled.

The issue I do face, please don't discuss here, I'll start a post and not steal this thread, is that the steppers become increasingly unsynced after homing each axis.

dc42

@tru_ann @Cognirit we've scheduled this feature to be included in 3.6 and I've started work on it. It may not be finished in time for 3.6 beta 3 but will be in 3.6 RC1.

Cognirit

@dc42 Great to hear that! Thank you!

T3P3Tony

@Cognirit this has been implemented in 3.6 beta3:

https://forum.duet3d.com/topic/37289/software-version-3-6-0-beta-3-now-available

Cognirit

@T3P3Tony Thank you for writing! @dc42

I can't properly convey how glad I am that I came across your developments and Duet2 about 7 years ago - and I still use them primarily in projects and research.

In my opinion it is currently the most flexible and user-friendly system for enthusiasts who are trying to create something new in the world of CNC machines.

Thank you and your team for all the work and effort you've put into this ecosystem and I hope it thrives for a long time to come!

T3P3Tony

@Cognirit thanks for the kind words!

tru_ann

@T3P3Tony @dc42 Glad to hear this!
I'm relatively new to your platform, but it's nice how customizable it is and how responsive the developers are.

tru_ann

@dc42 @T3P3Tony Hello! We installed firmware 3.6 beta3 and tested sensorless homing on the Duet3 3HC board. Individually all Z-axes perform homing without problems. However, when we tried to run homing with independent stopping (M574 Z2 S4) the system worked the same way as with S3 mode: when the first axis reached the end, all axes stopped. We tried running homing with the same settings, connecting the motors to the Duet3 6HC main board and it worked as it should: each motor stopped at the correct time. Is it possible that this is another unresolved problem with the Duet3HC Expansion board? I am attaching our configuration files. Thanks!
homez.g
config.g