search

CAP1Sup / Intellistep

A rework of the terribly coded firmware from the BTT S42B v2 boards
GNU General Public License v3.0
45 stars 10 forks source link

Encoder (TLE5012) Improvements #59

Open IhorNehrutsa opened 3 years ago

IhorNehrutsa commented 3 years ago

It seems like a good candidate https://github.com/xerootg/btt-s42b-simplefoc/blob/master/src/TLE5012b.h https://github.com/xerootg/btt-s42b-simplefoc/blob/master/src/TLE5012b.cpp also https://github.com/xerootg/btt-s42b-simplefoc/blob/master/reference_driver/encoder.h https://github.com/xerootg/btt-s42b-simplefoc/blob/master/reference_driver/encoder.cpp

I think @xerootg may add some comments

CAP1Sup commented 3 years ago

Ironic, because I was just finishing turning the current functions into a class. I'll push in a minute, I need to check that it works properly.

CAP1Sup commented 3 years ago

Sorry for the delay, I had some really big issues with the stepping. Commit fc0e3f82dc93c358a91c1432f7fa6b71679306cc is what you're looking for. Everything should be fixed to match. Edit: I missed a reference, commit 3c4c32794c4907d44e4ace5d13bd9bdff865269c fixes the missed reference

IhorNehrutsa commented 3 years ago

TLE5012-Magnetic-Angle-Sensor https://github.com/Infineon/TLE5012-Magnetic-Angle-Sensor https://github.com/Infineon/TLE5012-Magnetic-Angle-Sensor/wiki/Library-Architecture https://github.com/Infineon/TLE5012-Magnetic-Angle-Sensor/tree/master/src/corelib

CAP1Sup commented 3 years ago

We actually tried to use that, however the communication just didn't work. @TazerReloaded put a ton of work into the encoder, which is the only reason why it works. I tried and was unable to get it to work, regardless of if I used the library or not. If you look at it, you'll see that some of the functions in the encoder class have a great deal if similarly compared to the TLE library. It's just that BTT decided to be dumb and designed the encoder interface wrong. Therefore, we have to use custom functions to communicate with it

IhorNehrutsa commented 3 years ago

It's just that BTT decided to be dumb and designed the encoder interface wrong.

Do you mean Infineon?

IhorNehrutsa commented 3 years ago

I have a few question about the TLE5012. Could you reopen this issue?

IhorNehrutsa commented 3 years ago

Check encoder speed #64 34.8kHz

CAP1Sup commented 3 years ago

It's just that BTT decided to be dumb and designed the encoder interface wrong.

Do you mean Infineon?

Nope. I can't remember exactly what BTT did wrong, but I think that they didn't use a resistor where they should have according to the datasheet. That causes the enable pin of the SPI to have to be set to open drain during communication. We have no idea why, it's just how BTT managed to figure it out.

IhorNehrutsa commented 3 years ago

Encoder speedup 1 #68 35kHz

xerootg commented 3 years ago

I can vouch for BTT's layout just not playing well with the Infineon driver.

CAP1Sup commented 3 years ago

@IhorNehrutsa I worked on the encoder communication in encoderTransferRefactor, but I wasn't able to make and signifigant progress. I think that the DMA is our best bet for SPI coms as it is non-blocking (allowing the step routine to be called between angle readings) and reduces the load on the CPU. I started it, but I'm having trouble figuring out how to get it to work properly. Is there any chance that you could take a crack at it?

IhorNehrutsa commented 3 years ago

I can try

CAP1Sup commented 2 years ago

I was able to improve communication performance (commit 2a6155c6b080bed59244f2d492133c7391aaac87) by creating a specific function for writing the mode the GPIO 7 (MOSI pin). If you remember, we discovered that BTT designed the board wrong and used this as a workaround. This should greatly reduce the execution time as there is much less logic and most of the function uses precomputed values.

TazerReloaded commented 2 years ago

Did you measure the execution time difference? The compiler might do a fair bit of optimization with the old code too, so I wonder what the actual difference is.

I was busy building something completely different with the S42B over the last days: IMG_20211124_172236174 It is a device that operates a 90 degree valve on a water pipe to regulate a heating system. I figured if the encoder can measure the input shaft, it might as well measure the output shaft. It's still experimental, but it works. Need to build a case or something to hide the wires. In the process of building that thing I wrote a new firmware: https://github.com/TazerReloaded/ValveCloser Nothing groundbreaking, but the motor moves with a fixed sine control (silent and powerful, but maybe not that accurate, stolen from BTT code), and I figured out the safety word for the TLE5012B. Could also be used as a "minimal" firmware for experiments. Motor movement is only controlled by the encoder reading, no complicated step calculations. If the motor does not move the expected amount in a given interval, an error is reported. Same goes for over-temperature and encoder errors. No LCD support, configuration in header file, minimal serial communication. Intended for use as a "smart servo", you set the desired position and it goes there, reporting errors if any. I won't use the S42Bs for my printer in the near future, too many issues, and Klipper with input shaper on 24V steppers works perfectly fine. I'll report if I find an use case for my second unit. Have a nice evening!

CAP1Sup commented 2 years ago

Yeah, I meant the execution time. Moving to bit sets was much faster than the old HAL pin code. That's a great use for a S42B! I might make some... references to your code 😏, especially the TLE5012 read function...