Digital Replacing Analog...

[Ricketty C]

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.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Tim Williams]

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\" <gnuarm.deletethisbit@gmail.com> 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.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Mike Perkins]

On 27/08/2020 06:57:58, Ricketty C wrote:

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

 

[Tom Gardner]

On 27/08/20 16:11, Mike Perkins wrote:

On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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.

 

[Tabby]

On Thursday, 27 August 2020 14:46:27 UTC+1, Tim Williams wrote:
> Replac...ing? You\'re a couple decades late to the party there...

Digital has been gradually partly replacing analogue since the 1960s. It will never wipe analogue out though.


NT

 

[Mike Perkins]

On 27/08/2020 16:18:32, Tom Gardner wrote:

On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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.

The same is likely true for a FPGA too.

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

 

[Lasse Langwadt Christensen]

torsdag den 27. august 2020 kl. 07.58.04 UTC+2 skrev Ricketty C:

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.

what an the fpga do that the MCU can\'t already do without the hassle of a new project and the develop environment for it?

if you already control current and speed why do you need to limit voltage?


aren\'t you using an STM32?

https://www.st.com/resource/en/application_note/dm00080497-using-stm32-device-pwm-shutdown-features-for-motor-control-and-digital-power-conversion-stmicroelectronics.pdf

 

[Tom Gardner]

On 27/08/20 16:44, Mike Perkins wrote:

On 27/08/2020 16:18:32, Tom Gardner wrote:
On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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.

The same is likely true for a FPGA too.

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!

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.

 

[Ricketty C]

On Thursday, August 27, 2020 at 9:46:27 AM UTC-4, Tim Williams wrote:
> Replac...ing? You\'re a couple decades late to the party there...

No, this design was just started recently. Other designs aren\'t really relevant.

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.

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 for this matter. Suffice to say the desire is to write less C code when practical.

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.)

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 source drops below 12 volts. I realized with some elbow grease the whole circuit 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-performs with large transients. Changing that to an AD744 (picked semi-randomly from the LTspice model list) the circuit works ok but with some over drive and transients on current changes.

Using a faster amp results in oscillations I haven\'t been able to tame as yet. 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.


> FPGAs... are still a bit pricey, being beat by most entry-level MCUs.

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 the board because of a perceived difference in approvals. It\'s odd that we are using this justification because no one has actually said it will be easier to get approved... odd, but I\'m not running things.

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.

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 digital data in both direction, no reloading to set the mode. If we ever needed to stretch the capacity we could have split the design into several different designs and loaded the appropriate one when the system mode was selected.

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.

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 complexity, 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 the task has even been scoped! That\'s after we moved from a 20 MHz Arduino MCU to an 80 MHz ST ARM CM4F.

While I would not want to implement an Ethernet stack in an FPGA, lots of complex tasks are appropriate. This one is going to convert differential pressure readings (across an orifice) with temperature and absolute pressure to measure a flow rate, then integrate that to measure tidal volume. The calculations will need to be more than 32 bits, so the dedicated multipliers will be used in extended precision.

Tim

--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/

So what is with the top posting??? Your sig messes up the quoting in addition to every thing else.

\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> 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.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[Ricketty C]

On Thursday, August 27, 2020 at 11:18:39 AM UTC-4, Tom Gardner wrote:

On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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.

The motor protection is in hardware exactly because we don\'t trust the software. 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 review 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

 

[Ricketty C]

On Thursday, August 27, 2020 at 11:11:41 AM UTC-4, Mike Perkins wrote:

On 27/08/2020 06:57:58, Ricketty C wrote:
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?

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 going 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 chips it would have required and allowing the full alarm circuit to be done as well.

So maybe I can shove some other functions in it. I think the front panel interface would be good in the FPGA as well. Hardware button debouncing, manage the LCD interfaces and manipulate the settings data. Then we should have 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

 

[John Larkin]

On Thu, 27 Aug 2020 16:44:49 +0100, Mike Perkins <spam@spam.com>
wrote:

On 27/08/2020 16:18:32, Tom Gardner wrote:
On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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.

The same is likely true for a FPGA too.

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!

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.

 

[Ricketty C]

On Thursday, August 27, 2020 at 11:44:55 AM UTC-4, Mike Perkins wrote:

On 27/08/2020 16:18:32, Tom Gardner wrote:
On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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.

The same is likely true for a FPGA too.

What does that mean exactly??? I\'m not aware of FPGAs being stopped for debug.


> An MCU would have any safety related interrupt at the highest priority.

And what interrupt would that be, \"safety related interrupt 1\"??? I believe 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.

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.

That is the present over current circuit. But it uses a number of parts all of which can be rolled into the FPGA other than the P-channel FET and a level shifter 2N7002. That\'s what this thread is about.

An alternative 2 MCUs, the second in a housekeeping safety capacity,
they are cheap enough.

That doesn\'t address coding errors. The reason the FPGA was first introduced was to ease approval issues, hardware vs. software. I tried to tell them most places don\'t treat them differently when the hardware is in an FPGA.


> I suppose another alternative is a fuse!

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

 

[Ricketty C]

On Thursday, August 27, 2020 at 12:16:57 PM UTC-4, Lasse Langwadt Christensen wrote:

torsdag den 27. august 2020 kl. 07.58.04 UTC+2 skrev Ricketty C:
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.


what an the fpga do that the MCU can\'t already do without the hassle of a new project and the develop environment for it?

Correct me if I am wrong, but you can\'t count on software to protect the system if the software crashes. No?


> if you already control current and speed why do you need to limit voltage?

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 rams into a solid stop.

aren\'t you using an STM32?

https://www.st.com/resource/en/application_note/dm00080497-using-stm32-device-pwm-shutdown-features-for-motor-control-and-digital-power-conversion-stmicroelectronics.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

 

[Lasse Langwadt Christensen]

torsdag den 27. august 2020 kl. 20.29.01 UTC+2 skrev Ricketty C:

On Thursday, August 27, 2020 at 12:16:57 PM UTC-4, Lasse Langwadt Christensen wrote:
torsdag den 27. august 2020 kl. 07.58.04 UTC+2 skrev Ricketty C:
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.


what an the fpga do that the MCU can\'t already do without the hassle of a new project and the develop environment for it?

Correct me if I am wrong, but you can\'t count on software to protect the system if the software crashes. No?

the break input on the ST timer is hardware

if you already control current and speed why do you need to limit voltage?

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 rams into a solid stop.


aren\'t you using an STM32?

https://www.st.com/resource/en/application_note/dm00080497-using-stm32-device-pwm-shutdown-features-for-motor-control-and-digital-power-conversion-stmicroelectronics.pdf

Yes, we are using an H-bridge chip to control the motor.

the appnote explains the break input pins on the ST timers, it disables the timer output/sets them to safe state, all in hardware

 

[Phil Hobbs]

On 2020-08-27 11:18, Tom Gardner wrote:

On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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 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

 

[server]

On Wed, 26 Aug 2020 22:57:58 -0700 (PDT), Ricketty C
<gnuarm.deletethisbit@gmail.com> wrote:

>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.

Why not use a uA723 with power transistor and foldback current
limiting ?

>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.

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.

 

[Tom Gardner]

On 27/08/20 21:01, Phil Hobbs wrote:

On 2020-08-27 11:18, Tom Gardner wrote:
On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
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?

I suspect the last point is correct. However...

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 LM393 and a MOSFET are very comforting sometimes.  I always have an analogue
backup for mission-critical things like that.

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.

 

[Gerhard Hoffmann]

Am 27.08.20 um 19:53 schrieb Ricketty C:

On Thursday, August 27, 2020 at 11:11:41 AM UTC-4, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:

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?

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 going 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 chips it would have required and allowing the full alarm circuit to be done as well.

So maybe I can shove some other functions in it. I think the front panel interface would be good in the FPGA as well. Hardware button debouncing, manage the LCD interfaces and manipulate the settings data. Then we should have a watch dog timer. We need to be able to detect \"technical\" errors and report them. Actually, that reminds me of some things.

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.


Cheers, Gerhard

 

[Klaus Kragelund]

On Thursday, August 27, 2020 at 9:31:29 PM UTC+2, Lasse Langwadt Christensen wrote:

torsdag den 27. august 2020 kl. 20.29.01 UTC+2 skrev Ricketty C:
On Thursday, August 27, 2020 at 12:16:57 PM UTC-4, Lasse Langwadt Christensen wrote:
torsdag den 27. august 2020 kl. 07.58.04 UTC+2 skrev Ricketty C:
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.


what an the fpga do that the MCU can\'t already do without the hassle of a new project and the develop environment for it?

Correct me if I am wrong, but you can\'t count on software to protect the system if the software crashes. No?


the break input on the ST timer is hardware

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 big task

But, you also need to make sure the PWM timer (or controller) does not misbehave

In this case, you need again Class B SW


You could have a motor running, where the current is lower than the trip treshold, but the PWM has gone berserk and makes the motor heat up so it fails and makes the product hazardous

This is a typical case for motor control for 3 phase motors, in which you have an angle estimator control the vector for the motor. The angle estimator can be tricked into standstill operation, where it seems the motor is still running. Thus the SW has not problem, the current is below trip (so no BRK signal), and the motor heats up and becomes a hazard

STM32 has a pre-approved library:

https://www.st.com/en/embedded-software/stm32-classb-spl.html

If you stick to this, it may be easier to convince the dollar making approval body


Cheers

Klaus