I have been working on some circuitry to pull the plug on a motor on reachi ng an overload condition before it can tear up the gears or break the shaft (which the others on the project have done several times). This shut down was measuring the motor current and pulling the plug, then allowing the MC U to restart it when needed.
Later it was realized a new motor should not be run over 12 volts, so we ne ed something to limit the voltage. A regulator often requires significant head room to work, so I used the same pass transistor to add a voltage outp ut limit.
Now it looks like the entire circuit can be done in an FPGA along with a bu nch of other stuff, and not cost any more. The design time will be a lot l ess as well although the analog circuit is already done in simulation.
Four transistors, two comparators and a pocket full of passives replaced by a few FF and gates inside a chip where they will never be seen, just chug along.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
Replac...ing? You're a couple decades late to the party there...
The MCU doesn't have an ADC? Or a spare position on an I2C or SPI port? This sounds like something eminently doable just from the MCU.
That "pass transistor", I don't know about that part, I'd have to see the circuit of course. But even if it's a full analog, proportional or whatever control, even that can be done by MCU as a switching regulator; though maybe needing more effort to implement that exact solution than is worthwhile. (Personally, I would use a proper SMPS regulator/controller, and vary its setpoint, or gate its operation, from the MCU. Simple DAC or PWM channel or GPIO.)
FPGAs... are still a bit pricey, being beat by most entry-level MCUs. But yeah, that can do the job just as well, given sufficient gate count, of which some entry-level FPGAs can probably fit the bill. No idea what else the MCU is doing, rewriting all of that in HDL could be a huge pain.
Main tradeoff is, MCUs are better at slower, serial, procedural things; FPGAs are better at faster, parallel, combinatorial things. You might not want to write an ornate algorithm in HDL, and you might not want to write a big DSP system or hard real-time something-or-other for an MCU.
Tim
--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/
"Ricketty C" wrote in message
news:d5be9114-0de9-4c3e-b581-2ab2d620d068o@googlegroups.com...
I have been working on some circuitry to pull the plug on a motor on
reaching an overload condition before it can tear up the gears or break the
shaft (which the others on the project have done several times). This shut
down was measuring the motor current and pulling the plug, then allowing the
MCU to restart it when needed.
Later it was realized a new motor should not be run over 12 volts, so we
need something to limit the voltage. A regulator often requires significant
head room to work, so I used the same pass transistor to add a voltage
output limit.
Now it looks like the entire circuit can be done in an FPGA along with a
bunch of other stuff, and not cost any more. The design time will be a lot
less as well although the analog circuit is already done in simulation.
Four transistors, two comparators and a pocket full of passives replaced by
a few FF and gates inside a chip where they will never be seen, just chug
along.
My policy is simple, anything where real time is measured in ns is best done in a FPGA. Anything in ms is best done in a MCU.
Most timings in the uS region can be done in a MCU and given this is a motor with a slow build up to failure this sounds eminently doable in a MCU where development time is much faster. Most MCUs have good build in ADCs.
I guess this decision was made by someone who only has experience on FPGAs?
--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
With an MCU, it would be necessary to ensure that the motor protection was running correctly at all times. That's not only in operation but also when a processor hits a breakpoint (of any kind) during debugging.
An MCU would have any safety related interrupt at the highest priority. Plus you could have a hardware comparator comparing current directly. This could latch a power off condition that can only be reset by the MCU.
An alternative 2 MCUs, the second in a housekeeping safety capacity, they are cheap enough.
I suppose another alternative is a fuse!
--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
torsdag den 27. august 2020 kl. 07.58.04 UTC+2 skrev Ricketty C:
hing an overload condition before it can tear up the gears or break the sha ft (which the others on the project have done several times). This shut do wn was measuring the motor current and pulling the plug, then allowing the MCU to restart it when needed.
need something to limit the voltage. A regulator often requires significan t head room to work, so I used the same pass transistor to add a voltage ou tput limit.
bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulation.
by a few FF and gates inside a chip where they will never be seen, just chu g along.
what an the fpga do that the MCU can't already do without the hassle of a n ew project and the develop environment for it?
if you already control current and speed why do you need to limit voltage?
You don't normally stop an FPGA while debugging, but that often happens when debugging an MCU.
In normal operation any safety functions in an FPGA (or dedicated hardware) can be verysimple and independent of other functions - both in terms of implementation and execution.
No, this design was just started recently. Other designs aren't really rel evant.
The fact that an MCU has an ADC doesn't mean it has to be used. There are pros and cons to every design decision and they are too numerous to list fo r this matter. Suffice to say the desire is to write less C code when prac tical.
ver
ybe
or
The pass transistor can be whatever works best. Presently it is an AOD4185 used as an on/off switch. I was looking at adding more circuitry to make it a 12 volt limiter to the motor with minimal drop out when the power sour ce drops below 12 volts. I realized with some elbow grease the whole circu it could be done in the FPGA.
Control loops are not my forte, so I would need to handle this carefully. But that's true in analog and digital domains.
The analog version I'm playing with in LTspice uses a voltage divider with a small cap across the high side resistors to an op amp inverting input and a feedback resistor. The non-inverting input is a fixed voltage reference . This feeds an N-channel FET which pulls down on the P-channel pass FET, the AOD4185 driving the load.
Using the rather slow op amp uses elsewhere in the circuit it under-perform s with large transients. Changing that to an AD744 (picked semi-randomly f rom the LTspice model list) the circuit works ok but with some over drive a nd transients on current changes.
Using a faster amp results in oscillations I haven't been able to tame as y et. But this is not intended to be a real circuit unless we decide to not put this in the FPGA. I'm just looking for something to compare the digital model to.
You are behind the times. FPGAs can be as little as $2 and can incorporate functions that can't be handled as well in MCUs. In this case it is on th e board because of a perceived difference in approvals. It's odd that we a re using this justification because no one has actually said it will be eas ier to get approved... odd, but I'm not running things.
e
Rewriting??? Most of what will be in the FPGA has not been implemented yet . Something as simple as a control loop typically isn't much logic. I did a frequency control loop and many other things in a 3 kLUT device. It had several modes of operation and had to handle digital audio combined with d igital data in both direction, no reloading to set the mode. If we ever ne eded to stretch the capacity we could have split the design into several di fferent designs and loaded the appropriate one when the system mode was sel ected.
t
a
I've done a fair share of HDL and the complexity of the algorithm can be an issue simply because in an MCU you basically don't care about that complex ity, but you do care very much about speed and the issues of trying to make a single processor look like it is handling many things in parallel which is a magic trick in many ways... hard to do without well trained hands.
One of the software guys is always very eager to start optimizing before th e task has even been scoped! That's after we moved from a 20 MHz Arduino M CU to an 80 MHz ST ARM CM4F.
While I would not want to implement an Ethernet stack in an FPGA, lots of c omplex tasks are appropriate. This one is going to convert differential pr essure readings (across an orifice) with temperature and absolute pressure to measure a flow rate, then integrate that to measure tidal volume. The c alculations will need to be more than 32 bits, so the dedicated multipliers will be used in extended precision.
So what is with the top posting??? Your sig messes up the quoting in addit ion to every thing else.
he
ut
the
ant
ot
by
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
The motor protection is in hardware exactly because we don't trust the soft ware. They've already broken two or was it three motors!
Someone messed up the motor current sense circuit so it is not operational for the software to self protect in the 1.x rev boards. In many ways this project is being run like a hobby project. There was no plan or procedure to bring up the boards once they had them and there had been no design revi ew of those boards. They are full of very obvious errors like thermal pads being connected to the power planes via thermal breaks!
--
Rick C.
-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
No, I'm the only guy on the project with FPGA experience and never brought it up. The idea is that hardware is easier to get approved even though we don't have anyone telling us that. I'm tired of fighting the wind so I'm g oing with the flow. We have 8 indicators with 13 LEDs and no pins to drive them. They can be driven from the FPGA costing no more than the driver ch ips it would have required and allowing the full alarm circuit to be done a s well.
So maybe I can shove some other functions in it. I think the front panel i nterface would be good in the FPGA as well. Hardware button debouncing, ma nage the LCD interfaces and manipulate the settings data. Then we should h ave a watch dog timer. We need to be able to detect "technical" errors and report them. Actually, that reminds me of some things.
--
Rick C.
-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
I've done systems where the uP control block also had to hit a one-shot that enabled the end device. In one case, a software thermostat drives a relay to turn a heater on. The relay driver is a
5-second one-shot. Well, the control loop runs under Windows.
What does that mean exactly??? I'm not aware of FPGAs being stopped for de bug.
And what interrupt would that be, "safety related interrupt 1"??? I believ e the MCU is mostly polled operation taking sensor readings periodically. The motor over current detect is in hardware at the moment, but can easily be done in the FPGA. The harder part is limiting the voltage to the motor. The circuits supplying power are 15 V and a 12V battery. The motor warns about operating at over 12 volts. So a limiter is required.
That is the present over current circuit. But it uses a number of parts al l of which can be rolled into the FPGA other than the P-channel FET and a l evel shifter 2N7002. That's what this thread is about.
That doesn't address coding errors. The reason the FPGA was first introduc ed was to ease approval issues, hardware vs. software. I tried to tell the m most places don't treat them differently when the hardware is in an FPGA.
Yup, every time the software bug is encounters go find a new fuse!
--
Rick C.
-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
aching an overload condition before it can tear up the gears or break the s haft (which the others on the project have done several times). This shut down was measuring the motor current and pulling the plug, then allowing th e MCU to restart it when needed.
e need something to limit the voltage. A regulator often requires signific ant head room to work, so I used the same pass transistor to add a voltage output limit.
a bunch of other stuff, and not cost any more. The design time will be a l ot less as well although the analog circuit is already done in simulation.
d by a few FF and gates inside a chip where they will never be seen, just c hug along.
new project and the develop environment for it?
Correct me if I am wrong, but you can't count on software to protect the sy stem if the software crashes. No?
?
Who controls current??? We shut down the system if something is wrong and the motor is over current, like when the software crashes and the motor ram s into a solid stop.
tmicroelectronics.pdf
Yes, we are using an H-bridge chip to control the motor.
--
Rick C.
+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209
torsdag den 27. august 2020 kl. 20.29.01 UTC+2 skrev Ricketty C:
reaching an overload condition before it can tear up the gears or break the shaft (which the others on the project have done several times). This shu t down was measuring the motor current and pulling the plug, then allowing the MCU to restart it when needed.
we need something to limit the voltage. A regulator often requires signif icant head room to work, so I used the same pass transistor to add a voltag e output limit.
h a bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulation .
ced by a few FF and gates inside a chip where they will never be seen, just chug along.
a new project and the develop environment for it?
system if the software crashes. No?
the break input on the ST timer is hardware
ge?
d the motor is over current, like when the software crashes and the motor r ams into a solid stop.
-stmicroelectronics.pdf
the appnote explains the break input pins on the ST timers, it disables the timer output/sets them to safe state, all in hardware
An LM393 and a MOSFET are very comforting sometimes. I always have an analogue backup for mission-critical things like that.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510
http://electrooptical.net
http://hobbs-eo.com
Why not use a uA723 with power transistor and foldback current limiting ?
With some other topology with an emitter follower, just use a 12.6 V zener from base to ground, which will limit the emitter voltage to 12 V. When the battery voltage drops below 12.6 V, the zener will no longer conduct, reducing the series pass transistor extra dissipation.
Using a series resistor to load with up to 0.6 V drop and connect a small signal transistor across it (B and E) and the collector to the same point as the zener, will give overcurrent protection.
Using a MCU or FPGA for overvoltage and overcurrent protection sounds ridiculous. Those tools are useful for fine control when the absolute maximum parameter checks are done with fail-safe methods.
Just so. Not rocket science. Also /visibly/ avoids any awkwardness with programmable i/o pins (MCU or FPGA) when the circuit is coming out of being reset.
I just had some "fun" with a Beaglebone Black. It has 4 Banks with
32 IO-bits each, every bit with optional debouncing, interrupt on rising, falling, whatever, set/clear/read-them-all, set/clear them individually, DMA connection, the debounce time is selectable etc. I was using only bits in bank 1, but needed some more in bank 0 and could not find the device addresses.
Until I noted that the 4 Kbyte descriptor was for one bank only, and for bank 0 I had to map another 4K page into the virtual address space.
The Hardware reference manual is 6000+ pages and does not even try to tell anything about the ARM instruction set or the instruction set of the PRUs, 2 additional RISCs for predictatble IO. You can place an IO edge with 5 ns resolution with the PRUs.
There are also multiplexers that determine if any bit uses the functions defined in the 4*32 control blocks or does something different altogether, like USB, Video, LCD, PWM or ADC input.
But you can do little wonders with the BBB, like ssh-ing into it, compiling your apps locally with vi/make/gcc as if it was an ordinary Linux Debian workstation, running FFTW, flipping bits over the WLAN etc.
It is a true love/hate relationship.
The new BeagleBone AI has even some array processor DSPs.
n reaching an overload condition before it can tear up the gears or break t he shaft (which the others on the project have done several times). This s hut down was measuring the motor current and pulling the plug, then allowin g the MCU to restart it when needed.
so we need something to limit the voltage. A regulator often requires sign ificant head room to work, so I used the same pass transistor to add a volt age output limit.
ith a bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulati on.
laced by a few FF and gates inside a chip where they will never be seen, ju st chug along.
of a new project and the develop environment for it?
e system if the software crashes. No?
Yes, and that is enough to make sure the break function works with no SW in between. if it had SW, it would need to be Class B rated, and that is a bi g task
But, you also need to make sure the PWM timer (or controller) does not misb ehave
In this case, you need again Class B SW
You could have a motor running, where the current is lower than the trip tr eshold, but the PWM has gone berserk and makes the motor heat up so it fail s and makes the product hazardous
This is a typical case for motor control for 3 phase motors, in which you h ave an angle estimator control the vector for the motor. The angle estimato r can be tricked into standstill operation, where it seems the motor is sti ll running. Thus the SW has not problem, the current is below trip (so no B RK signal), and the motor heats up and becomes a hazard
STM32 has a pre-approved library:
formatting link
If you stick to this, it may be easier to convince the dollar making approv al body
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.