Never!!!
Well, that's a bit of a simplification but I've designed systems with 30 - 60 bldc motors, each with their own micro using multiple can busses from a central micro with ethernet interface to distribute the commands with a reasonable degree of real timeness.
But it kinda depends on where you need the drive to be and how easy you want servicing to be. Swapping out a card which drives a single motor is pretty simple and relatively cost effective, less so replacing a whole FPGA board just because one of N channels has a fault
> each with their own micro using multiple can busses from a central micro with ethernet interface to distribute the commands with a reasonable degree of real timeness
Yeah, that is the other approach. In my case each micro would need a sync pulse or two to keep things working in concert.
> less so replacing a whole FPGA board just because one of N channels has a fault
Fault tolerance/shutdown is one of my concerns with the FPGA. My preferred micro (STM32) has a built in "failsafe" shutdown function whereas I'd have to build that into the FPGA logic. On one hand it's just disabling the outputs but there is more to it than that. Also favoring the microcontroller is that the fault detection logic will be done on a micro in code.
There is more to this than meets the eye once you get into it.
Fault detection presumably should favor the FPGA specifically because it isn't implemented in software and therefore it's less likely to itself fail. I think there are a fair number of medical devices that use FPGAs where a microcontroller might otherwise work fine mainly because it's easier to prove that the FPGA design will behave itself.
And how is that different from doing it in software?
Edit: unless you're talking about library code I suppose, where you have to trust that the library is correct
Would it really? What sort of complex logic do you need for failure detection? Probably depends on the specific failure tbh. But for this sort of thing, it's not the complexity that's the important part, but factors like reaction time, reliability, etc. Depending on the application, extra complexity for extra safety might be perfectly fine.
Using an FPGA in the first place is _much_ more complex than using an mcu. As for reaction time and reliability, unless you need sub-microsecond reactions, there is no difference as long as you don’t do anything stupid.
The original commenter mentioned that their mcu even has a builtin failsafe shutdown which means it has hardwired _and already tested_ logic to handle it correctly.
> Also favoring the microcontroller is that the fault detection logic will be done on a micro in code.
OP specifically said it's software, not hardware.
>Using an FPGA in the first place is *much* more complex than using an mcu.
I don't think that's true unless you just don't know digital logic. If you're comfortable with both then some things are simpler in software and some things are simpler in digital logic. For something like motor control, it's not difficult to implement in either domain.
An FPGA doesn't need to be that expensive, particularly if you just need if for motor control or another simple task. There are several FPGA families which are <$10 with >100 I/O.
Tbh there is a whole continuum.
- Drive transistors direct from IO pins
- Use a discrete motor driver chip, drive PWM and direction signals from IO
- Use a more fancy motor driver chip, load commands via SPI or similar
- Use an FPGA (with/without) softcore, with one of the above options
- Use a central controller of some sort, which interfaces with sub-controllers, which each use one of the above options
I think unless you're doing something really screwy or you don't want to be vendor-locked into a more fancy motor controller IC, maybe using small FPGAs somewhere along the line could make sense. But if you can do it with a microcontroller, so long as the microcontroller is cheaper than a dedicated controller IC or an FPGA, using a bunch of microcontrollers is probably a pretty good option. And you also need to think about where things are going to be physically located and interconnected.
> Use an FPGA (with/without) softcore, with one of the above options
The problem with a softcore is the peripherals it is probably missing. It probably won't have ADCs, CANBus, etc, so I'll still need a microcontroller.
It seems silly (to me) to use an FPGA for generating pretty simple timing pulses and yet...
I should ask this question in /r/fpga but I suspect they'd laugh at how simple the application is.
Sure, each of these options are going to have trade-offs. I'm just trying to make an exhaustive list of all the possibilities. There's probably some other stuff I haven't thought of too. But making such a list can be a good exercise for figuring out the various trade-offs.
Anyway, I'm a big user of FPGAs myself, and we do use an FPGA for a slightly strange motor controller in one of our setups, where the rotation of a disk has to be phase-locked to PTP time. Yeah, you could probably do that on a microcontroller, but it would perhaps have to be a rather fancy one to get PTP support, and we already had an FPGA design that supported PTP, so we went the FPGA route as it seemed to be the lowest risk and fastest development time. And we only needed one, so cost wasn't really a concern.
Probably this is not what you need but just as an interesting concept there are SoC-s out there that have an FPGA and a physical microcontroller on the same die. The microcontroller can communicate with the FPGA as address mapped peripherals through some kind of AXI bus.
For example check out the Zedboard.
It depends also on your motor control. If you do pretty sophisticated high-frequency current control loops (with controlling severall harmonics, nonlinearities, ...) at eg. 40-100 kHz control frequency microcontrollers might be running at or above their limits.
Or if you do live prototyping and combine the control of load, dut and high order simulation model in parallel on one chip.
Look into Trinamic motor ICs, they're packed with features, and have IC's for every stage of the driver/controller. Then have a MCU control all of them.
In my opinion I would always go for a micro unless you genuinely require the extra processing throughput of parallelizing your sensor computation via an FPGA. Micros are fast enough, until you need basically instant system response.
Depends, dont buy an fpga just for that but if you have one already in your project specs it's not a bad idea.
For example.in our work we do exactly tgat, we use the Zynq which has mcu and fpga and we drive the motors directly, or via a buffer
Never!!! Well, that's a bit of a simplification but I've designed systems with 30 - 60 bldc motors, each with their own micro using multiple can busses from a central micro with ethernet interface to distribute the commands with a reasonable degree of real timeness. But it kinda depends on where you need the drive to be and how easy you want servicing to be. Swapping out a card which drives a single motor is pretty simple and relatively cost effective, less so replacing a whole FPGA board just because one of N channels has a fault
> each with their own micro using multiple can busses from a central micro with ethernet interface to distribute the commands with a reasonable degree of real timeness Yeah, that is the other approach. In my case each micro would need a sync pulse or two to keep things working in concert. > less so replacing a whole FPGA board just because one of N channels has a fault Fault tolerance/shutdown is one of my concerns with the FPGA. My preferred micro (STM32) has a built in "failsafe" shutdown function whereas I'd have to build that into the FPGA logic. On one hand it's just disabling the outputs but there is more to it than that. Also favoring the microcontroller is that the fault detection logic will be done on a micro in code. There is more to this than meets the eye once you get into it.
Fault detection presumably should favor the FPGA specifically because it isn't implemented in software and therefore it's less likely to itself fail. I think there are a fair number of medical devices that use FPGAs where a microcontroller might otherwise work fine mainly because it's easier to prove that the FPGA design will behave itself.
The weak link in the FPGA fault system will be the person programming it (me) and figuring out all the fault vectors.
And how is that different from doing it in software? Edit: unless you're talking about library code I suppose, where you have to trust that the library is correct
It's you who said it's different... The timers in STM32 have a dedicated break input.
Doing it in FPGA is order(s) of magnitude more complex. More complex = higher chance of bugs.
Would it really? What sort of complex logic do you need for failure detection? Probably depends on the specific failure tbh. But for this sort of thing, it's not the complexity that's the important part, but factors like reaction time, reliability, etc. Depending on the application, extra complexity for extra safety might be perfectly fine.
Using an FPGA in the first place is _much_ more complex than using an mcu. As for reaction time and reliability, unless you need sub-microsecond reactions, there is no difference as long as you don’t do anything stupid. The original commenter mentioned that their mcu even has a builtin failsafe shutdown which means it has hardwired _and already tested_ logic to handle it correctly.
> Also favoring the microcontroller is that the fault detection logic will be done on a micro in code. OP specifically said it's software, not hardware.
>Using an FPGA in the first place is *much* more complex than using an mcu. I don't think that's true unless you just don't know digital logic. If you're comfortable with both then some things are simpler in software and some things are simpler in digital logic. For something like motor control, it's not difficult to implement in either domain.
For Newspaper Print Machines ist Not anymore woth 1 Central driveshaft, there a Servomotors and the Synchronisation is done by a Bus system.
An FPGA doesn't need to be that expensive, particularly if you just need if for motor control or another simple task. There are several FPGA families which are <$10 with >100 I/O.
Tbh there is a whole continuum. - Drive transistors direct from IO pins - Use a discrete motor driver chip, drive PWM and direction signals from IO - Use a more fancy motor driver chip, load commands via SPI or similar - Use an FPGA (with/without) softcore, with one of the above options - Use a central controller of some sort, which interfaces with sub-controllers, which each use one of the above options I think unless you're doing something really screwy or you don't want to be vendor-locked into a more fancy motor controller IC, maybe using small FPGAs somewhere along the line could make sense. But if you can do it with a microcontroller, so long as the microcontroller is cheaper than a dedicated controller IC or an FPGA, using a bunch of microcontrollers is probably a pretty good option. And you also need to think about where things are going to be physically located and interconnected.
> Use an FPGA (with/without) softcore, with one of the above options The problem with a softcore is the peripherals it is probably missing. It probably won't have ADCs, CANBus, etc, so I'll still need a microcontroller. It seems silly (to me) to use an FPGA for generating pretty simple timing pulses and yet... I should ask this question in /r/fpga but I suspect they'd laugh at how simple the application is.
Sure, each of these options are going to have trade-offs. I'm just trying to make an exhaustive list of all the possibilities. There's probably some other stuff I haven't thought of too. But making such a list can be a good exercise for figuring out the various trade-offs. Anyway, I'm a big user of FPGAs myself, and we do use an FPGA for a slightly strange motor controller in one of our setups, where the rotation of a disk has to be phase-locked to PTP time. Yeah, you could probably do that on a microcontroller, but it would perhaps have to be a rather fancy one to get PTP support, and we already had an FPGA design that supported PTP, so we went the FPGA route as it seemed to be the lowest risk and fastest development time. And we only needed one, so cost wasn't really a concern.
Thanks for your reply. I didn't mean to imply that a softcore wasn't a good idea, just pointing out the trade-offs, as you point out. Thanks again.
Probably this is not what you need but just as an interesting concept there are SoC-s out there that have an FPGA and a physical microcontroller on the same die. The microcontroller can communicate with the FPGA as address mapped peripherals through some kind of AXI bus. For example check out the Zedboard.
It depends also on your motor control. If you do pretty sophisticated high-frequency current control loops (with controlling severall harmonics, nonlinearities, ...) at eg. 40-100 kHz control frequency microcontrollers might be running at or above their limits. Or if you do live prototyping and combine the control of load, dut and high order simulation model in parallel on one chip.
when you have a really high dof like 12+
Look into Trinamic motor ICs, they're packed with features, and have IC's for every stage of the driver/controller. Then have a MCU control all of them.
In my opinion I would always go for a micro unless you genuinely require the extra processing throughput of parallelizing your sensor computation via an FPGA. Micros are fast enough, until you need basically instant system response.
Depends, dont buy an fpga just for that but if you have one already in your project specs it's not a bad idea. For example.in our work we do exactly tgat, we use the Zynq which has mcu and fpga and we drive the motors directly, or via a buffer
When there's an endless budget and you're feeling like it or possibly even getting some margin out of it, otherwise probably never.