The only thing in the motor is the position encoder and maybe a brake. The electronics is in the drive and you can run them with 20m cables if you want. Doesn’t matter.
The reason most bldcs don’t like long cables is that they are low voltage and high current. Which requires thicker cables the longer the run is. Nothing says you can’t run a motor with 100M cables.
This is pretty nice. You need two of those and your problem is solved.
I think AliExpress it is, it’s out of stock like everywhere.
The question is what is the protocol and hardware. You could run any signal over a fiber-optic cable for kilometers with near-zero latency, but that would cost you both arms and legs.
Yes, however the inductance at high PWM will create certain issues that again you need to solve on each end. I think @Franz_Schmidt needs help with a very pointed and doable solution to his problem. What would be your solution to his problem?
SPI is meant to be a board level protocol and doesn’t really like longer runs with the clock signal. That being said you can run if over rs422 transceivers or lvds pretty well. TI has a solution brief for it even: https://www.ti.com/lit/an/slyt441/slyt441.pdf
LTC4332 is a purpose made SPI extender thats pretty dope. You’re limited to 2 MHz speed though.
Any differential signaling will do. For cheap ones it’s usually just quadrature while tamagawa, yaskawa et al. Who have absolute encoder use their own digital protocols(hiperfsce, endat, biss etc).
Nice. So SPI extenders are: LTC4332 is 2MHz and LTC6820 is 1MHz.
Thanks @Valentine @Adam_Donovan @Roiki for the help.
I’m just going to try the SPI extenders for now. The schematic/part selection for the high power section of my board is done. For the PCB layout, i think I will put the i/o isolation, the SPI extender and MCU on a separate PCB so i can change it easier when I have problems, i think the power stage isn’t that difficult. Also power PCB will have 2oz copper so i can make the MCU board 1oz copper.
Ltc6820 also supports multidrop while 4332 is point to point only. It also uses a single pair(4332 uses 2) so is compatible with existing can bus wiring.
Looking at the schematics it seems internally both ICs are using some proprietary variation of a canbus to communicate. Very interesting.
@Roiki Thanks, that’s a great suggestion.
Today i talked with the automation engineer at my workplace and he says for Siemens servo motors 50-100m between the driver module in the electronics cabinet and the motor is no problem.
To chime in with my 2c here:
The AliExpress Motor with the 3m cable is using encoder signals - so depending on how fast the motor is turning, this will be a digital signal with 2500PPR x motor speed in RPS = encoder’s signal frequency
Depending on the motor’s speed this should be below 1MHz or in the low MHz… The cable is probably shielded.
I can’t imagine this technique reliably extending to 100m, so I would image your Siemens guys are doing something more clever…
SPI communication, which involves multiple dependent signal lines and bi-directional communication, will be more sensitive to noise problems across large distances. It’s really only recommended for on-PCB links.
And the SPI → MCU → SPI → MCU links will introduce latencies. And latency on the sensor data is definately not good for the FOC performance.
So I would prefer a more direct interface like the encoder ABI or PWM for this use case.
To bridge the distance the SPI extender looks quite good in principle. Like CAN bus (or Ethernet) it uses differential signalling for far lower power consumption and much increased resilience to noise and line problems.
However, the MCU reading/writing SPI will introduce extra latency, and I would not expect that to be beneficial.
I’ll be interested to find out how it goes for you, please do let us know!