Closed Loop with Linear CoreXY Encoders

[skuep]

Hi everyone,
I am in the process of building a Pick-And-Place machine (OpenPNP) and I am currently using the excellent Duet Mini 5+. I was thinking about the feasibility to go Closed Loop for the CoreXY kinematics that I chose, which generally does not seem to be an issue (when using rotary encoders!).

However I was also thinking about using chinese linear encoders (E.g. Sino KA200) for even better positional accuracy and I am evaluating whether such a setup is possible: Closed Loop on CoreXY with A/B motors in conjunction with X/Y linear encoders.

There was a quick discussion already in the forums (https://forum.duet3d.com/topic/36201/corexy-linear-encoders-1hcl-closed-loop-expansion-board/) and the consensus is, that it is currently not possible. After a few hours looking through the code, I would pretty much confirm that this is currently not possible, since the encoder is always directly mapped to the motor, way after any kinematics calculations have been carried out.

I am thinking about tackling this in the future (sounds like a nice challenge) and so far I have devised the following plan:

1. Get a EXP3HC board (a board with more than one motor driver) so the firmware has access to two local motor drivers.
2. Make firmware support CLOSED_LOOP feature. One encoder will run on the PDEC hardware and another encoder will be implemented using CCL. I think this should be possible, there is an appnote on the old AT(x)mega processors on exactly this. I think it could be made to work on the SAME5X (https://ww1.microchip.com/downloads/en/Appnotes/Interf-Quad-Encoder-CCL-w-TCA-TCB-DS00002434C.pdf).
3. Validate functionality using two regular rotary encoders on motor A/B connected on one of the expansion headers. From a quick glance, the required pins (PDEC and CCL) seem to be on the SPI1 header. +5V/GND could be sourced from another header
4. Implement a "encoder forward matrix" (or reverse matrix) feature into the expansion firmware that defines the relationship between encoders and drives. Currently each drive has their own encoder attached. This would need to be reworked a bit, so that one driver can access all (both) encoder positions and mix&match them according to the forward matrix. Ideally the user should be able to configure this encoder forward matrix using the M569.1 command similar to the M669 X<> Y<> Z<> command.
5. Change the closed loop code (and tuning code) to get encoder values through the forward (or reverse) matrix so that each PID motor controller sees only decoupled "virtual" axes that they can use for control

I think I could make 1-3 work on my own, since it's basically a bit of hardware fiddling and modifying the expansion firmware. However for points 4-5 I am too inexperienced with the RRF stuff to be able to implement this. Also I am not yet sure if there are some caveats when implementing the encoder decoupling into the ClosedLoop class. Are there situations where the coupling is unwanted (e.g. encoder tuning? encoder calibration?). Issue #11 could be related to exactly this question.

What do you think? Is this of enough interest to get one or two persons to help or is this too niche? Not sure what Duet3D's plans on closed loop are or if customer interest in closed loop is too low to sink effort into this.

[skuep]

Just a heads up, after I set up the build environment I noticed that the TMC5160s on the EXP3HC do not have the XDIRECT register. Bummer.

Maybe I need to find another way to get to my goal, since interest here seems also quite limited. Thanks anyway for all the work that went into this!

[dc42]

TMC5160 drivers do have the XDIRECT register although I think it may have a different name. Implementation of phase stepping (which also uses XDIRECT) is currently being implemented on the 3HC in the 3.6-dev branch of RRF.

[skuep]

Thanks for the reply. I quickly grepped through the datasheet yesterday and couldn't find anything related. In the code, it says something about 0x2D, which is not the DIRECT register but the XTARGET register.

So I am not sure, I think the mechanism works quite differently to the TMC2160 (positioning mode instead of direct mode?) so it's good to hear that it might be supported soon, because I couldn't have managed that myself.

I will have a look into 3.6-dev

[dc42]

Hi Simon, From page 33 of the TMC5160A datasheet rev 1.14: [image: image.png] Best regards - David

…

On Mon, 14 Oct 2024 at 16:58, Simon Küppers ***@***.***> wrote: Thanks for the reply. I quickly grepped through the datasheet yesterday and couldn't find anything related. In the code, it says something about 0x2D, which is not the DIRECT register but the XTARGET register. So I am not sure, I think the mechanism works quite differently to the TMC2160, so it's good to hear that it might be supported soon, because I couldn't have managed that myself. — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUYI3E62X3O3RCFT75VXDLZ3PSY5AVCNFSM6AAAAABL6WHJNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJRGY3DIMRQHA> . You are receiving this because you commented.Message ID: ***@***.***>

-- David Crocker, Duet3D Ltd.

[skuep]

Wow, that's well hidden 🤣 alright that clears things up. Might have another go at it in the next days.

[skuep]

In the first step I am trying to get closed-loop working on the stepper controller 0 and so far it compiles and I get the firmware binary.
See https://github.com/Duet3D/Duet3Expansion/compare/3.6-dev...skuep:Duet3Expansion:3.6-dev-3hc-closedloop?expand=1

Two questions (if you don't mind):

1. I noticed that on the 3HC board, there is no CLK being provided to the TMC5160, whereas on the 1HCL, a clock is provided to the TMC2160 controller. What's the idea behind that? Does the clock need to run synchronous? Do you think it's problematic that the 3HC doesn't provide a clock to the stepper controller?
2. Can I run the newly compiled firmware (based on 3.6-dev) on the 3HC board and connect it to the Duet3 Mini5 running an older firmware (I think 3.5-dev but need to check) or does the mainboard also need to run 3.6-dev?

[dc42]

1. The purpose of providing a clock from the MCU to the TMC2160A on the 1HCL is to allow us to use a higher SPI speed to the TMC2160A in order to reduce latency in the control loop. The datasheet gives a maximum frequency when the internal clock is used, and a higher frequency when an external clock is used and the SPI clock is synchronised to it.
2. You might get away with running 3.5 on the main board if you don't have any filament monitors connected to the 3HC and you don't mind having no input shaping on the 3HC.

[skuep]

@dc42 Again, thanks for the help. I am currently running the compiled firmware of my branch. And I can get the motor into closed loop perfectly, using my Duet3D Encoder daughterboard. That attaches directly to the TEMP_DB header (Conveniently, the PDEC pins are also there).

I have basic closed-loop functionality and I can successfully perform an encoder calibration (after I noticed that it's not CPR but PPR that need to be provided). I also updated all firmwares to the 3.6 (beta) version just to be safe.

However I have one issue and that is, that I cannot get any data back from the M569.5: Closed loop data collection command. I suspect that either I am not recording any samples on the EXP3HC board or that they are not sent back to the Duet3 Mini5 board for whatever reason. I am quite sure, it's just some #if (or similar) that I missed in the code. Maybe a missing timer initialization?

Do you have a guess where in the code of the EXP3HC I could have a look?

EDIT: I think I have found the culprit. The CAN data sending task is currently instantiated for each axis (and the handle stored into a single static global variable). I have modified the code to instantiate the task on-demand (during tuning move only) for the axis, that needs it and now it works. See this commit.

[skuep]

Good news, after a few days of hard thinking and simulating, I found an okish way to implement a quadrature decoder using the CCL, EVSYS, EIC and TCC3. See commit here

It's modeled closely (but not exactly) after AN2434 Interfacing Quadrature Encoder using CCL with TCA and TCB from Microchip.

Unfortunately, one drawback is, that you need the A and B pins on CCLINx pins as well as EXTINTx pins. I couldnt find another way to make the logic work. I updated the kicad design of the adapter PCB (see here).

Second caveat is, that with two closed loop drives, the EXP3HC began to act weirdly and stuttery. Turns out, that I needed to increase the loop cycle time slightly so the TMC task does not overwhelm the MCU. With the default 80us cycle delay it was at 40-50% CPU usage. Now with 160us it's at roughly 20%.

One thing that I find odd (happens with either encoders) is the sharp steps in the commanded motion during the closed loop move. Why is the start of every slope not "smooth" like it is in the screenshots here. It looks like the acceleration slope is not being used here.

EDIT: I found it through shear luck I think (a lot of the code is like spanish to me). There is still a bit of code that was not yet complete for nDrivers > 1 and CLOSED_LOOP. Commit here improves the situation, but it only works on one of the drives. If I move the other one, the board crashes. Any advice?

Interestingly it does not occur when turning closed loop off (M569 P1.0 D2)

Gotta say, I am pretty happy for now :-)