K
Klaus Kragelund
Guest
On Sunday, August 30, 2020 at 12:35:08 AM UTC+2, Ricketty C wrote:
Maybe elaborate on your requirements then
You now mention \"medical device\". That will be a lot tougher approval wise than a household appliance, so your needs for approved SW will be even more relevant
Which medical standard do you have to comply to?
Cheers
Klaus
On Saturday, August 29, 2020 at 6:20:30 PM UTC-4, Klaus Kragelund wrote:
On Saturday, August 29, 2020 at 3:32:52 AM UTC+2, Ricketty C wrote:
On Friday, August 28, 2020 at 7:08:41 PM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 10:07:35 AM UTC+2, Ricketty C wrote:
On Friday, August 28, 2020 at 2:23:21 AM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 4:50:09 AM UTC+2, Tim Williams wrote:
\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com....
No, this design was just started recently. Other designs aren\'t really
relevant.
Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.
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.
Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.
And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.
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.
There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.
And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.
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.
Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).
A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from.
And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.
As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).
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.
A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).
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.
I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.
MCUs start at a fraction of that, and median parts are a few bucks.
As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck..
I guess the typical FPGA load configuration at boot with each block defined in SRAM like registers
For a Class B product, one would need to check all those registers at interval in run mode. 60730 defines all the modes that must be tested at interval and at boot
I can\'t view that spec, but it claims to only apply to \"household\" electronics.
Yes, and that covers pretty much any electronics in your home or office
Which has nothing to do with ventilators.
Sure it has. A ventilator, a pump, an air condition. Anything with a motor in it, or any product that has a power level that in case of a fault could heat a component up and exceed insulation specs or outright burst into flames is covered.
Say one of your FETs that controls the motor shorts or operates in linear mode that would not trigger a safety function will heat the motor up to above 150 degrees for Class F wire, would then fail the UL/IEC test
In case of a motor controlled with SW, there needs to be safeguards that makes sure the SW behaves correctly, even when you introduce errors into the microcontroller. Bit flip, timer going berserk, oscillator outside ranges etc
We spend a LOT of time on these faults, component breakdown tests, to be sure the product is safe
In 60730 what exactly is a class B product?
Any household product. What standard have the approval body told you that you should comply to?
I do not think a typical FPGA has this feature, so it cannot be approved as a HW block
On top of that, the oscillator frequency needs to be checked along with other parameters
I don\'t know anything that does meet that requirement. I recall NASA gear that would reboot periodically to deal with soft radiation induced errors. Is that the sort of thing you are talking about?
This is a requirement for any equipment with SW that control an element that can potentially heat up to unsafe levels. So in this case, a motor for a household gadget. In our case, it\'s a circulation pump
So, nothing to do with NASA, this is for \"standard\" electronics
Fine, but what electronics with digital \"stuff\" meets this requirement? How do they meet it other than just not using digital \"stuff\"?
Using Class B SW techniques. Like those described in this document from ST:
https://www.st.com/resource/en/application_note/dm00105610-guidelines-for-obtaining-ulcsaiec-607301603351-class-b-certification-in-any-stm32-application-stmicroelectronics.pdf
About the oscillator check, that can be done quite simple inside the controller. You feed the main clock to a timer, and you then compare the main clock with say the watchdog clock/timer. They must not differ much, if they do, you pull the reset flag
Who defines \"not much\"???
You do. You check that at the maximum range that the product is still safe. So if your clock will impact your product to have double heat consumption at half clock frequency and that is a problem, then that is your limit
Same for code check. During compile time, you calculate the code checksum. During runtime, the code checksum is calculated every 10 seconds. If it differs, you pull reset
Ok then, reloading the config would meet that requirement. So the NASA approach for FPGAs works well.
Yes
In this case I know of no such requirement. I think people accept that such errors are sufficiently rare. In our case the software and firmware can keep an eye on one another. If either sees something wonky the entire unit gets rebooted. The MCU can reboot the FPGA after the FPGA has rebooted the MCU.
That does not cut it. The approval body needs to approve your SW. If you do not have approved Class B SW, then your micro is considered to be one big fault generator. If you have your checks in place, then you can get it approved. The advantage of using the libraries from ST or Microchip and others is that they are preapproved, so you only need to argue about the application layer when you talk to the approval body
Don\'t you do component breakdown tests and evaluation of Critical Components (those that need UL/IEC approval, since they are connected to the line, Y caps, X caps, varistors etc)
Cheers
Klaus
Normally I would welcome such a discussion, but you are not getting it. The standard you are referring to does not apply to medical equipment. The medical standard may require something similar, but that will be the medical standard requirement, not the standard you are referring to which may be very different. The software hazards are not relevant if they are prevented from materializing because the hardware prevents them.
I\'m not interested in going round and round about this. You need to understand what I\'m saying and you don\'t seem to.
Maybe I am not getting it, could be
Maybe elaborate on your requirements then
You now mention \"medical device\". That will be a lot tougher approval wise than a household appliance, so your needs for approved SW will be even more relevant
Which medical standard do you have to comply to?
Cheers
Klaus