New open source high end closed loop driver klipper compatible

[mykepredko]

@nefelim4ag

Good response but I want to make a couple of comments back.

@nefelim4ag

But that extruder motor has to produce at max about 1-2Kg force and normally should be able to produce 5-7Kg.

Force can be verified with a spool, mass on the spool, or a load cell in the toolhead.
(Extruder should be able to lift a 1kg spool off the floor at least.)

Motors that rotate, do not product “force”, instead they produce “torque” which is the force at a specific radius. Lifting a 1kg mass with a pully of radius 1mm requires a thousandth of the torque for a pulley with a radius of 1000mm.

@nefelim4ag

Motor speed is limited by the BackEMF, regardless of what sort of control you use.

Correct and, it is my understanding that, you want to have a ratio of 4:1 to 8:1 between applied voltage vs BEMF in a stepper motor. Anything more than this will distort the applied sine wave enough to affect the motors operation/position precision.

I’ve deleted a ton of calculations here but, what it comes down to is that in a typical 3D printer system (ie one with 6mm radius drive pulleys and running at 24V with NEMA 17 42 motors), running at 60mm/s to 100mm/s will result in a BEMF of 3V to 6V - which is the “sweet spot” that most printers are running at today.

@nefelim4ag

It can be interesting information if you provide data on “versus” how your machine performs with and without such drivers with your stepper motors.

Agreed. I would like to see that data (which is basically what I was asking for in my original post).

[cardoc]

@mykepredko

I would like to see that data

Have you reviewed the datasheet?
https://www.analog.com/media/en/technical-documentation/data-sheets/TMC4671.pdf
Section 3 is fascinating. I don’t completely understand the math but I believe High speed closed loop control allows considerably higher accelerations at low speeds with no loss of accuracy and 10-20% higher travel speeds.

[mykepredko]

@cardoc

Have you reviewed the datasheet?

I went through it at the start of the discussion. I’ve been following this thread with interest.

@cardoc

I believe High speed closed loop control allows considerably higher accelerations at low speeds with no loss of accuracy and 10-20% higher travel speeds.

I agree that it is reasonable to expect 10%-20% higher travel speeds due to the more efficient magnetic field management the chip provides and the resultant reduction in Back EMF. This also results in lower total current draw. I don’t know if I would agree to higher accelerations at low speeds - the point of FOC is to reduce currents that produce radial forces but, as I understand it, this does nothing to increase tangential torque (which is required for higher accelerations).

---

In any case, I jumped in on the thread because I saw the claim:

@clrobotix

the encoder on the toolhead will encrease the print quality 10 times

and, in response my questioning the claim, there is :

@clrobotix

my mention of a ‘10x improvement’ was intended to highlight the significant gain in reliability

I’m guessing the claims are based on the problems driving a traditional open loop driver and stepper motor combination beyond their capabilities, but they’re not “quality” or “reliability” issues.

If I’m wrong on this understanding, please explain.

[clrobotix]

I would like to conduct a comparative test between the TMC5160 (current setup) and a new prototype driver. I’m seeking suggestions for a robust test setup.

My initial plan is to determine the maximum speed and acceleration capabilities using the same motor over several hours. A key focus will be motor temperature. Without Field Oriented Control (FOC), I am limited to 2.2A. However, FOC utilizes current peaks at the precise moments needed—effectively creating a ‘resonance’ between the driver and motor. I expect these peaks to exceed 3A without a corresponding increase in temperature.

For the second phase, I plan to run a 168-hour (one week) continuous print at maximum speed on both drivers to visually compare the output and verify long-term reliability for my large-scale machine.

Because my machine is quite demanding and the cable distance between the motors and the electronics exceeds 2 meters, I prefer to perform the high-speed calculations directly at the motor.

[nefelim4ag]

@mykepredko

Motors that rotate, do not product “force”, instead they produce “torque” which is the force at a specific radius.

Sentence corrected.
Thanks.

@mykepredko

Anything more than this will distort the applied sine wave enough to affect the motors operation/position precision.

Alas, IDK, I gave up on that, or attempts to do register tuning further than using Excel tables.

I can only say that I didn’t experience any related issues.
I have low-inductance motors and a 48V power supply for them.
But I don’t have an oscilloscope current probe to prove anything, and don’t need one to rationalize such a cost.

@clrobotix

A key focus will be motor temperature. Without Field Oriented Control (FOC), I am limited to 2.2A.

TLDR, it makes sense to first define the issues that you have with TMC5160 and how you print with them. After that allows you to basically do checks, what is fixed and what is not.

Motors should be fine under their respective datasheet current, even if they are “hot” - this is how they are designed.
By so, if you alter the current for the FOC driver, you can’t compare apples to apples.

I ran my motors at run_current 1.767A and at 2.5A, where the datasheet specifies 2.5A per phase.
Where for simple fullstep control it is 2.5A DC, and for TMC in the config (RMS) 1.767

You can partially emulate closed-loop current reduction with CoolStep, but of course, it will be less efficient than adequate closed-loop control.

You can measure power/current going into the motor if you measure between the PSU and the driver. So, it is mentioned above 10W, but IDK how large your motor naturally is or what datasheet specifies for them. I would expect values to be about I^2 * R … 2 * I^2 * R per motor in standby.

Taking into account all previous conversations, what you can verify is that closed loop driver does not produce the salmon skin effect and does not oscillate.
It is the problem even with Delta’s industrial servos, as far as I’m aware.
Also, IIRC, FOC as Closed Loop driver can also do goofy things at hold.
So, probably the edges/45-degree corners of the printed models can be interesting.
(One motor is in hold, another is printing and creating forces through the belts)

I guess a generic VFA test should do.

Then there would be edge cases, mid-range resonances, and you can reproduce it on your motors with TMC drivers. Normally, it is about 2-3 RPS, maybe higher.
This is when SpreadCycle has enough power to move the rotor, but because the steps are not created equal, and the universe is not an ideal rotor resonate and oscillates by itself.
Then there is the VFA range, normally, where your belts start to resonate and produce VFA.
And then it just works.
Because you have a large machine with large motors and long belt paths, it can perform differently, and the edge cases described above can happen in a different order or at different speeds.

If you want to be fancy, it is possible to do so with accelerometer data and by the motan dump subsystem: Debugging - Klipper documentation
So, you can look at accelerometer data at different speeds without actually printing anything.

Or if/then you connect encoders, it is possible to calibrate them and dump data.
It is expected to work if they have SPI, and there is a driver for them implemented.

Because of other stuff, which I can imagine will be way too hard to spot on the print output.
Hence, it is one of the reasons why there is still no stepper shaper.
Lack of encoders on every motor is another reason %) - hard to calibrate, hard to verify.

Hope that helps a little.
-Timofey.

[tetra]

What are those fantastic looking printheads!? Liquid cooled, four color units by the look of them. are they mixing units or serial selectable input/output. Also, what is that wire loom material you’re using. Very cool looking stuff you’ve got going on there!

[clrobotix]

Thanks. I’ll be back to you as soon as I have some data

[clrobotix]

@tetra

@tetra

What are those fantastic looking printheads!? Liquid cooled, four color units by the look of them. are they mixing units or serial selectable input/output. Also, what is that wire loom material you’re using. Very cool looking stuff you’ve got going on there!

hello.

this machine use idex with dual 4 in 1 head. The “ams” is full custom. It automatically change filament when it run out or just select a different material . It also has 2 piezo sensor one for each head. I use them to make automatic xyz offset calibration. I use liquid cooling but is useless. just more weight for no big gain. i’ll remove it.

my goal is to make high speed high reliabilty big size machine. I’ll probably make it open source when is perfect. ( after encoder driver )

[tetra]

Very nice! Pushing boundaries is how we all move forward. You’ve open sourced the driver it would seem, maybe you should market the industrial hardware - a Guy’s gotta eat!

Where are you out of? USA or ? I’m in Upstate New York for now, getting pummeled a bit with snow atm.

(added) re: water cooling. yeah, I wondered about dragging all that liquid around with the printhead. I was also wondering since you had to do a size reduction at the head, why not do it at the source to minimize that mass in the tubes. good aluminum heatsinks with fans are pretty good too though. maybe shrouded to channel flow better would be useful too.

[clrobotix]

is it possible in your opinion to use the knowlege of torque of tmc4671 to implement a real time active resonance compensation with the accelerometer? it will be like noise cancelling.

[nefelim4ag]

@clrobotix

is it possible in your opinion to use the knowlege of torque of tmc4671 to implement a real time active resonance compensation with the accelerometer?

I’m not sure what you meant by that. There is a lag between data collection and data actually received by the host, the host plans steps beforehand, so realtime as mentioned in other topics, through the host is not feasible.

Where PID/FOC controller will contradict with IS and everything else, so it makes even less sense.

I generally think that the only probably correct way to make them all play together is to tune IS initially without a closed loop, so the system will be controlled in a way that it can obey in the first place.
And after that, use a closed loop of your choice to do real-time correction.

Because the other way around, Klipper will send trapezoidal movements, which are not possible to obey at high accelerations, the closed loop will try to follow them, and you will have problems, as most implementations before.

This is my opinion; it may work or may not. I didn’t use closed-loop motors.
Nor do most closed-loop solutions have the ability to run in an open-loop way for initial tuning.

Hope that clarifies something.
-Timofey

[cardoc]

Klipper calculates kinematic moves “in the future” then sends the MCU a set of instructions of when to do what. No opportunity exists for “real time” correction.

The TMC4671 overcomes that by operating downstream of the MCU to ensure the motor did what it was instructed to do, in (nearly) real time.

Klipper’s input_shaper uses a PREDICTIVE model of resonance to avoid sending moves that would excite known resonance frequencies.

Theoretically an Inertial Measurement Unit (accelerometer based) could create a much more detailed error model (as the printer operates) to refine the input_shaper. It could not completely provide real time correction as there is no way to know the nozzle is going to be out of position until it is ACTUALLY out of position.

A sufficiently precise IMU could be used as a feedback “encoder” for the TMC4781 but it can only minimize errors as they happen never eliminate them. I’d love to see it tried…

[EmperorArthur]

@cardoc

The TMC4671 overcomes that by operating downstream of the MCU to ensure the motor did what it was instructed to do, in (nearly) real time.

There’s already one printer which does closed loop control. The Magneto X. Unfortunately, the extruder can’t keep up. Closed loop control would really help with providing more power to the motor in those situations.

[clrobotix]

I’m thinking about real time compensation.

The idea is to mount two micrometric linear encoders (X/Y) and feed the data into a high-speed MCU. The MCU intercepts the G-code to synchronize the ‘theoretical’ position with the ‘actual’ one. It then drives piezo actuators to adjust the extruder’s position on the fly. This system would be autonomous, compatible with any printer, and affordable. With this hardware-level correction, Input Shaper would no longer be necessary.

with piezo actuator we can have high speed , high force and high precision.

what do you think?

[cardoc]

@clrobotix

two micrometric linear encoders (X/Y)

Measuring from where to where? There is no reliable “datum” axes to measure from.

The bed shakes, the printer frame deflects and oscillate, belt tension causes racking in the gantry etc.

Yes a piezo actuator could correct the nozzle location in real time IF you can determine the needed correction vector.

Place a laser pointer on the center of your bed so it shines straight up onto the ceiling. The beam is the datum you need to measure from. Raise the gantry (lower the bed) to clear the pointer. Manually set that to Z0. With no filament loaded start a print with decent acceleration. Watch the spot on the ceiling. How big of a circle does the laser draw in the ceiling?

How are you going to measure nozzle location in reference to that datum axis when the axis is constantly moving?

[clrobotix]

you are right.

It may be a better way to use just an accelerometer. and a voice coil actuator istead of piezo. also I should intercept the step/dir signal to calculate the teorical acceleration. with accelerometer I can get the sum of all oscillations

[3dcoded]

Random idea (this would need some testing to verify). Is the positional lag predictable? Like if you tell the X-axis to move to 100mm (assume cartesian kinematics), how long after the move completes would the encoder register the X-axis to be at 100mm? If this positional lag is predictable and consistent, then you could sum up the step/dir signals to determine a given stepper’s target position and verify that the stepper gets to the right position within the known positional lag. If the stepper takes more than a certain error threshold amount of time to reach the position (or it never does), then we’ve skipped steps so we need to inject additional step signals to correct for the issue.

In step-by-step form (I find this easier to understand):

Assuming positional lag of 1ms (completely arbritary) and 16 microsteps on a 1.8º stepper

1. Klippy receives a G1 command requesting a stepper to move 100mm at 10mm/s (ignoring acceleration for simplicity).
2. Klippy queues 320000 steps (100 * 16 * 200)
3. Closed-loop board receives 320000 step pulses and passes on each pulse to the TMC driver
4. Closed-loop board determines that the stepper should be at position 320000 after 10s, meaning the encoder should register 320000 steps after 10.001s (with positional lag)
5. Either:
   Encoder reaches position 320000 within 10.001s (within threshold, ok)
   OR
   Encoder doesn’t reach position 320000 within 10.001s (inject additional steps)

There should probably also be some sort of threshold where if the stepper never reaches the target, send an error signal back to the host and request user attention.

[cardoc]

@clrobotix

accelerometer I can get the sum of all oscillations

2 accelerometers actually (unless you want to epoxy your heated bed to a 2000kg block of granite). 6 axis IMU on the build surface and a 2 axis on the print head.

Then all you have to do is track the location of the axis through the center of, and perpendicular to, the build plate. Solve for the intersection of that axis and the current build plane. Then calculate the distance from the nozzle in 2 axes. Once you know that you can determine the correction to move the nozzle BACK TOWARDS the desired location.

OH and you can’t calculate the error UNTILL THE NOZZLE IS OUT OF PLACE. In order to apply corrections you need to detect VERY SMALL errors very very quickly as you are already behind (you can’t measure an error until there is an error).

So all you need is 2 IMU systems with a combined error band on the order of 1 micron sampling at LEAST 500Hz…

[EmperorArthur]

There’s no need to feed the Gcode in, unless you’re trying to duplicate the look ahead functionality Klipper already has. Just use the step and direction signals.

As I said, what you’re looking for already exists. Just not that integrated into Klipper. The Magneto X uses linear encoders on the rails for the feedback portion of the closed loop.

@cardoc

The bed shakes, the printer frame deflects and oscillate, belt tension causes racking in the gantry etc.

Yet, all of these problems have been solved in milling machines for decades and they have much larger forces acting on them. The way they deal with deflection and oscillation is as old as machining. Throw more mass at the problem.

However, those systems do almost always use use closed loop control systems to ensure accuracy. Which is one reason I’m enthused about the board at the start and any additional Klipper integration.

[cardoc]

Closed loop it employed to wash out backlash and hysteresis NOT deflection and resonance.

Closed loop control CANNOT predict positional errors. Until errors are of a magnitude sufficient to be measured then and only then can the correction be made.

Rigidity is what gives a milling machine the ability to produce quality surface finish NOT closed loop control. Rigidity also allows a place to anchor the fixed end of the encoder to provide the datum.

A core XY printer has no available mounting points for encoders so the gains that can be realized by adding closed loop control end with motor shaft position leaving 95% of the hysteresis and backlash uncorrected.

I spent a couple days modeling an optical motion capture system. Concept was an IR point source offset 25mm from the nozzle and 8 line sensors (1x1024 pixels each). I was able to reach a theoretical resolution of 0.05mm at 1000hz. I then determined there was no rigid datum to mount the cameras on AND realized that 0.05mm was about 1/10 of the resolution needed to resolve salmon skin type surface issues.

At that point I concluded that 4k x 1 pixel sensors would help but not overcome the resolution issues and that unless I was prepared to build a 2000 lb test rig the concept was not practical.

If someone wants to poor a 2000 hollow concrete cube and build a coreXY drop bed printer inside it I’d be happy to consult on the motion capture system.