Re: Over-voltage protection circuit does not work as expected
toggle quoted message
Show quoted text
On Wed, Feb 5, 2025 at 3:51 PM, jerzy przezdziecki via groups.io <jprzezdziecki@...> wrote: Yes, it’s uploaded in TEMP as “TLV1805_overvoltage_protection_circuit_works” ? Jurek ? From: <[email protected]> on behalf of "Richard Andrews via groups.io" <richardandrews.ma@...>
Reply to: <[email protected]>
Date: Wednesday, 5 February 2025 at 21:49
To: <[email protected]>
Subject: Re: [LTspice] Over-voltage protection circuit does not work as expected
Resent from: <richardandrews.ma@...>
Resent date: Wed, 05 Feb 2025 12:49:16 -0800 Is there a circuit for this thread? Ild like to look at it myself when i get home. ? On Wed, Feb 5, 2025 at 3:41 PM, jerzy przezdziecki via groups.io <jprzezdziecki@...> wrote: I can imagine that crowbar is much better, but I would not be afraid about transients. This chip is extremally fast, a few ns. So – as you said – the TLV1805 is made for this purpose. Jurek ? I understand that overvoltage protection (OVP) must be a very simple and reliable circuit.
I've had a lot of problems with this circuit because sudden load variations can cause transients in the output voltage and reach high values triggering the triac! That's terrible.
Extreme situations can generate noise and lead to malfunctioning protection circuits.
My overvoltage detection, for this reason, is done by simple zener diodes and only components like the TLV1805 are suitable, as they have been designed for this purpose.
Because of these problems, in one specific case I used a microcontroller to trigger the crowbar. The microcontroller was able to distinguish between an overvoltage and a transient.
|
Re: Over-voltage protection circuit does not work as expected
Yes, it’s uploaded in TEMP as “TLV1805_overvoltage_protection_circuit_works” ? Jurek ? From: <[email protected]> on behalf of "Richard Andrews via groups.io" <richardandrews.ma@...>
Reply to: <[email protected]>
Date: Wednesday, 5 February 2025 at 21:49
To: <[email protected]>
Subject: Re: [LTspice] Over-voltage protection circuit does not work as expected
Resent from: <richardandrews.ma@...>
Resent date: Wed, 05 Feb 2025 12:49:16 -0800 Is there a circuit for this thread? Ild like to look at it myself when i get home. ?
toggle quoted message
Show quoted text
On Wed, Feb 5, 2025 at 3:41 PM, jerzy przezdziecki via groups.io <jprzezdziecki@...> wrote: I can imagine that crowbar is much better, but I would not be afraid about transients. This chip is extremally fast, a few ns. So – as you said – the TLV1805 is made for this purpose. Jurek ? I understand that overvoltage protection (OVP) must be a very simple and reliable circuit.
I've had a lot of problems with this circuit because sudden load variations can cause transients in the output voltage and reach high values triggering the triac! That's terrible.
Extreme situations can generate noise and lead to malfunctioning protection circuits.
My overvoltage detection, for this reason, is done by simple zener diodes and only components like the TLV1805 are suitable, as they have been designed for this purpose.
Because of these problems, in one specific case I used a microcontroller to trigger the crowbar. The microcontroller was able to distinguish between an overvoltage and a transient.
|
Re: Over-voltage protection circuit does not work as expected
Is there a circuit for this thread? Ild like to look at it myself when i get home.
On Wed, Feb 5, 2025 at 3:41 PM, jerzy przezdziecki via groups.io <jprzezdziecki@...> wrote: I can imagine that crowbar is much better, but I would not be afraid about transients. This chip is extremally fast, a few ns. So – as you said – the TLV1805 is made for this purpose. Jurek ? I understand that overvoltage protection (OVP) must be a very simple and reliable circuit.
I've had a lot of problems with this circuit because sudden load variations can cause transients in the output voltage and reach high values triggering the triac! That's terrible.
Extreme situations can generate noise and lead to malfunctioning protection circuits.
My overvoltage detection, for this reason, is done by simple zener diodes and only components like the TLV1805 are suitable, as they have been designed for this purpose.
Because of these problems, in one specific case I used a microcontroller to trigger the crowbar. The microcontroller was able to distinguish between an overvoltage and a transient.
|
Re: Over-voltage protection circuit does not work as expected
I can imagine that crowbar is much better, but I would not be afraid about transients. This chip is extremally fast, a few ns. So – as you said – the TLV1805 is made for this purpose. Jurek ? I understand that overvoltage protection (OVP) must be a very simple and reliable circuit.
I've had a lot of problems with this circuit because sudden load variations can cause transients in the output voltage and reach high values triggering the triac! That's terrible.
Extreme situations can generate noise and lead to malfunctioning protection circuits.
My overvoltage detection, for this reason, is done by simple zener diodes and only components like the TLV1805 are suitable, as they have been designed for this purpose.
Because of these problems, in one specific case I used a microcontroller to trigger the crowbar. The microcontroller was able to distinguish between an overvoltage and a transient.
|
Re: Over-voltage protection circuit does not work as expected
I understand that overvoltage protection (OVP) must be a very simple and reliable circuit.
I've had a lot of problems with this circuit because sudden load variations can cause transients in the output voltage and reach high values triggering the triac! That's terrible.
Extreme situations can generate noise and lead to malfunctioning protection circuits.
My overvoltage detection, for this reason, is done by simple zener diodes and only components like the TLV1805 are suitable, as they have been designed for this purpose.
Because of these problems, in one specific case I used a microcontroller to trigger the crowbar. The microcontroller was able to distinguish between an overvoltage and a transient.
?
?
?
|
My Grandfather used to say "make sure it's plumb" meaning make sure it's perfectly vertical. He used to be a handyman and mason.
|
Re: Over-voltage protection circuit does not work as expected
As much as a defective Power MOSFET can prevent a
series-protected voltage limiter, a problem with the crowbar
thyristor or its control circuit can defeat its purpose.
Nothing is ever perfect.
Le 05/02/2025 à 16:41, Udo
Huhn-Rohrbacher via groups.io a écrit?:
toggle quoted message
Show quoted text
I would not designate the proposed circuit as an
overvoltage protection circuit. At most it's something like a
"voltage clipper" or "voltage limiter" for excessive input
voltage excursions.
Let's assume there are any failures within the control
circuit, or a defective Power-MOSFet, or even overvoltages,
coming from external sources directly to the Load, then you
will get in trouble with that circuit.
A true overvoltage protection circuit requires a crowbar
arrangement, as well known in the power electronics industry.
Best regards
Udo??
Am Mi., 5. Feb. 2025 um
15:40?Uhr schrieb jerzy przezdziecki via
<jprzezdziecki= [email protected]>:
Hello,
?
I have uploaded circuit that
finally works as executed with a good TLV1805 model
found online.
The problem was the ic. I
have used a voltage comparator from the LTSpice
library list with an open collector – instead of an
original TLV1805 push-pull one.
This made a simulation not
working properly. So everything was fine with the
PMOS.
?
Anyway thanks to all for
advices.
?
Jurek
?
Two other suggestions:
Keep Vcc at 36V, but add a
separate PWL(0 0 1 36) source to the comparator
signal input, rather than the R2/R3 divider.
THEN(!) swap the + & -
inputs. As is, it turns the output FET ON when the
test voltage exceeds the Zener.
?
Dave
?
?
Works a heck of a lot better,
with the S pin NOT grpinded…
As David Schultz suggested,
maybe add the bypass cap between B and S,. but don’t
ground it – that forces the out out to an
open/pulled-up state.
?
Dave
?
?
Isn't that
what it is supposed to do?? 19V is not overvoltage
so you would expect the mosfet to conduct.
--
Dipl.Ing.Udo
Huhn-Rohrbacher
Albert-Kratz-Str.1
D-75180 Pforzheim
phone: +497231-352339
fax: +497231-140338
mobile: +491523-3612096
E-mail: u.huhn.rohrbacher@...
|
Re: Over-voltage protection circuit does not work as expected
I would not designate the proposed circuit as an overvoltage protection circuit. At most it's something like a "voltage clipper" or "voltage limiter" for excessive input voltage excursions. Let's assume there are any failures within the control circuit, or a defective Power-MOSFet, or even overvoltages, coming from external sources directly to the Load, then you will get in trouble with that circuit.
A true overvoltage protection circuit requires a crowbar arrangement, as well known in the power electronics industry.
Best regards Udo?? Am Mi., 5. Feb. 2025 um 15:40?Uhr schrieb jerzy przezdziecki via <jprzezdziecki= [email protected]>:
Hello, ? I have uploaded circuit that finally works as executed with a good TLV1805 model found online. The problem was the ic. I have used a voltage comparator from the LTSpice library list with an open collector – instead of an original TLV1805 push-pull one. This made a simulation not working properly. So everything was fine with the PMOS. ? Anyway thanks to all for advices. ? Jurek ? Two other suggestions: Keep Vcc at 36V, but add a separate PWL(0 0 1 36) source to the comparator signal input, rather than the R2/R3 divider. THEN(!) swap the + & - inputs. As is, it turns the output FET ON when the test voltage exceeds the Zener. ? Dave ? ? Works a heck of a lot better, with the S pin NOT grpinded… As David Schultz suggested, maybe add the bypass cap between B and S,. but don’t ground it – that forces the out out to an open/pulled-up state. ? Dave ? ? Isn't that what it is supposed to do?? 19V is not overvoltage so you would expect the mosfet to conduct.
-- Dipl.Ing.Udo Huhn-Rohrbacher Albert-Kratz-Str.1 D-75180 Pforzheim phone: +497231-352339 fax: +497231-140338 mobile: +491523-3612096 E-mail: u.huhn.rohrbacher@...
|
Re: In need of some zeners or maybe model them myself
On Tue, Feb 4, 2025 at 10:45 PM, Andy I wrote:
I am right in assuming therefore that, as long as the model parameters match the datasheet, and therefore the device I'm trying to model, I'll be golden, yes?
Tough question.? Simulations are never quite correct, but good models should yield good results in most cases.? There can be exceptions, though, so being 'golden' is never guaranteed.
?
Makes sense.
If you can verify the models, by comparing them not just with the datasheets but with other measurements of real parts, you are usually in good shape.? Comparisons with datasheets are pretty good; going further (if you can) gives you better confidence.? Many SPICE users don't do either.? Sometimes they are lucky, sometimes not.
?
Andy
?
?
I have everything I need here at work and, at home. I've also done plenty of voltage readings of this device in the past but, like I said, being no one here actually understands how the circuit was designed exactly, I've only been able to get so far in trying to understand what the originators of the circuit were thinking when they designed this circuit 40 years ago. Lol! I ain't giving up any time soon. Just the opposite, I plan on figuring this f***er out! Lol!
?
|
Re: Any Good Reason to Create a Hierarchical Connector and Conductors to Route (Plumb) Ground Out of a Hierarchical Schematic
Ah, yes. I had forgotten that. Thanks.
--
Regards,
Tony
On 05/02/2025 14:21, Andy I via
groups.io wrote:
toggle quoted message
Show quoted text
Technically, the
"hidden" connection is to a not-hidden pin on the A-device
symbol's lower left corner.? If the pin is left floating, which is
the normal way to use them, LTspice makes a hidden to node 0.? If
the pin goes anywhere on your schematic, the connection to node 0
is broken, causing the output currents to be sourced from
something other than node 0.
|
Re: Over-voltage protection circuit does not work as expected
Hello, ? I have uploaded circuit that finally works as executed with a good TLV1805 model found online. The problem was the ic. I have used a voltage comparator from the LTSpice library list with an open collector – instead of an original TLV1805 push-pull one. This made a simulation not working properly. So everything was fine with the PMOS. ? Anyway thanks to all for advices. ? Jurek ? From: <[email protected]> on behalf of "Bell, Dave via groups.io" <Dave.Bell@...>
Reply to: <[email protected]>
Date: Sunday, 2 February 2025 at 19:08
To: "[email protected]" <[email protected]>
Subject: Re: [LTspice] Over-voltage protection circuit does not work as expected
Resent from: <Dave.Bell@...>
Resent date: Sun, 02 Feb 2025 10:08:17 -0800 Two other suggestions: Keep Vcc at 36V, but add a separate PWL(0 0 1 36) source to the comparator signal input, rather than the R2/R3 divider. THEN(!) swap the + & - inputs. As is, it turns the output FET ON when the test voltage exceeds the Zener. ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Bell, Dave via groups.io
Sent: Sunday, February 02, 2025 10:01 AM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] Over-voltage protection circuit does not work as expected? Works a heck of a lot better, with the S pin NOT grpinded… As David Schultz suggested, maybe add the bypass cap between B and S,. but don’t ground it – that forces the out out to an open/pulled-up state. ? Dave ? ? Isn't that what it is supposed to do?? 19V is not overvoltage so you would expect the mosfet to conduct.
|
Re: Any Good Reason to Create a Hierarchical Connector and Conductors to Route (Plumb) Ground Out of a Hierarchical Schematic
Oops, I left out a word, two replies back:
?
...? If the pin is left floating, which is the normal way to use them, LTspice makes a hidden connection to node 0.?
?
Andy
?
|
Re: Any Good Reason to Create a Hierarchical Connector and Conductors to Route (Plumb) Ground Out of a Hierarchical Schematic
On Wed, Feb 5, 2025 at 02:06 AM, eewiz wrote:
I am pretty sure this has nothing to do with version 24.1.1.? I think LTspice has always behaved this way - going back at least as far as LTspice IV and probably earlier.
?
After running the sim, nothing changes outside the block, still ground on one side of the resistor and V(n030) on the other side connected to the RTN hierarchical connector.
Inside the block, the RTN hierarchical connector still says "Click to plot V(n030)" but, the net connected to that RTN hierarchical connector now says "This is ground."
Bee careful here.? When looking at a local schematic, LTspice doesn't know that this net is going to be used as something other than ground, so it calls it "ground" when displaying that schematic.? You might think that is incorrect, but LTspice doesn't know (can't tell) without knowing where the external connections go.? On a local view of a lower-level schematic, it can not tell - especially because it might be used different ways if more than one higher-level schematic calls it.
?
I think the same thing would happen if you drew a multi-level hierarchical design without a ground symbol on any of the lower-level schematics.? Let's say you took node "ABC" on a lower-level schematic, and tied its pin directly to node 0 on the top-level schematic.? When examining that schematic in isolation in the schematic editor, LTspice does not know that this net will actually become node 0.? So it labels the net "ABC" even though it will be "0".? The local schematic view is never the full expanded picture.? It can only look locally.
?
The resistor outside the block has one end connected to ground and its other end also connected to ground through a hierarchical connector named RTN.
That observation is incorrect.? The net that LTspice labels "ground" in the lower-level schematic, is not actually ground when it becomes connected to the higher-level schematic.? Therefore the resistor outside the block is NOT connected to ground on both ends.? It must not disappear from the netlist, because it really is there!
?
Unfortunately we have two domains, and you need to be careful not to mix them.? There is the local picture - looking at the lower-level schematic - and there is the global picture after "expansion" and connections are made.? At the end of the day, the only "real" one is after expansion.? But it is not possible to "see" that while looking at a lower-level schematic in the schematic editor.? That view doesn't "know" what the external connections will be.
?
The same exact thing happens all the time when examining lower-level schematics in the schematic editor.? If you hover over a net that goes to an Input, Output, or Bi-Direct pin (one of the ones with a box drawn around the name), LTspice can only display its LOCAL net name, even though that is NOT the real name of the net.? Think of it as only a temporary net name, used until connections are made to the next higher-level schematic.??When you use that lower-level schematic in your hierarchy, that net's name changes.? But in the local view of that schematic, LTspice doesn't know what that name will be.? So it can only name it (incorrectly? not really) with the net name that you drew on that one schematic.
?
You might say, "Can't LTspice examine where the net goes in the next higher level, and show the right names after expansion?"? The answer is No, because that lower-level schematic might be called (used) 3 times, maybe even in 3 different higher schematics, meaning that the 3 instances of this net actually have 3 distinct net names.? LTspice can't show all of them.? It is not one single net, it is 3 distinct nets.? In one of those circuit calls, that pin might connect to node 0.? When looking at this lower-level schematic, it would be both correct and incorrect to say that the net is "ground".? The only reasonable thing LTspice can do, is show what its apparent net name would be, in total isolation.
?
That is why your view of your lower-level schematic calls the net "ground", even though the net ends up NOT being ground after connections are made and the netlist is expanded.? "Ground" is its temporary name, subject to revision during netlist expansion.
?
Since LTspice's ground (GND) (node 0) is a perfect superconductor that never drops any voltage, there can never be any current through that resistor because it is grounded on both ends.
Yes, that would be true if N003 was actually ground.? But it is not.? Do not think that N030 = 0.
A resistor grounded on both ends is removed from the netlist hence, it shows no "plot my current" arrow when pointed at.
A resistor grounded on one end with the other end unconnected or connected to an open wire, is also removed from the netlist.
Neither resistor's current nor the open net's voltage can be plotted.
None of that happens in your case with hierarchy because node N030 is NOT node 0 or "ground".
?
I urge you to be very careful about making these observations.? You have a tendency to make incorrect assumptions and jump to inflexible conclusions that are incorrect, and then you stick to those wrong conclusions.? I'm sorry to be critical, but I have seen this happen over and over.? Keep an open mind and don't close your options.
1. If routing ground out of a hierarchical schematic, be absolutely sure to remove all of the triangular (label 0) ground symbols from the interior of that hierarchical block and physically connect any nets that may have been disconnected by those ground symbol removals.
That can be a rule to follow, but it is not necessary.? You do need to understand that your external connections to that net (to every net in the schematic) take precedence.? If you connect that net to something that isn't ground, then the net won't be grounded - no matter how "wrong" it may look to you when examining just the lower level schematic in isolation.
?
It is actually reasonable to draw a lower-level schematic, where a net is called "ground" locally (using the triangle symbol), but also goes to an I/O pin (with a box around it).? That ENABLES you to selectively "override that ground".? If the higher-level schematic doesn't connect to the pin, it remains ground.? If the higher-level schematic connects it to +150 V, that net becomes not-grounded and has +150 V on it.? Think of it as a feature you didn't realize was there.
?
As I wrote earlier (in another message), this is extremely helpful when importing external netlists into LTspice.? Some vendors write their SPICE models with signals going to node 0 that you would rather not be grounded.? Before LTspice, I had to re-write their SPICE models to disconnect them from ground.? It was a PITA.? Now, LTspice handles it automatically.? Within the context of the subcircuit, the node appears to be node 0.? But when the subcircuit is called and connections are made to the next-higher level in the hierarchy, that net changes to something other than node 0.? It's wonderful.? LTspice does the right thing.
?
As far as I am aware, in other SPICE programs (well, only a few that I've tried), node 0 was always ground, no matter where it was used.? LTspice is the only program I know that has this wonderful feature.
?
I would not be surprised to find that all nodes "0" within a sub-circuit would need to be renamed to something like "00" to ensure that LTspice does connect all those nodes together but does not sumarilly connect that net to ground.
That is the hard way to do it.? That would be what I used to do, except that I had to use a nodename like 9999 or "AltGnd".? Many other SPICE programs treat nodes 00 and 000 as identical to node 0.
?
Or maybe not, maybe LTspice treats node 0 within a sub-circuit cell differently then it treats the triangular (label 0) ground symbol within a sub-circuit block.
If I understand what you're saying, that is correct.? Inside a lower-level schematic or netlist, LTspice treats node 0 as "maybe ground", which can be overridden by an external connection when the schematics and subcircuits are expanded.
?
On the other hand, if you suggest that subcircuits in Netlist form behave differently than lower-level schematics, that is incorrect.? It treats them the same.? They are the same.
?
Andy
?
|
Re: Any Good Reason to Create a Hierarchical Connector and Conductors to Route (Plumb) Ground Out of a Hierarchical Schematic
On Wed, Feb 5, 2025 at 06:28 AM, Tony Casey wrote:
There are some situations where it is very difficult not to use actual GND, even implicitly. The digital (A) devices are an example. They have a hidden "device common", so the outputs can source current, apparently from nowhere. ...
That can easily be avoided too, if you know you want to.
?
Technically, the "hidden" connection is to a not-hidden pin on the A-device symbol's lower left corner.? If the pin is left floating, which is the normal way to use them, LTspice makes a hidden connection to node 0.? If the pin goes anywhere on your schematic, the connection to node 0 is broken, causing the output currents to be sourced from something other than node 0.
?
Andy
?
|
Re: In need of some zeners or maybe model them myself
On Tue, Feb 4, 2025 at 10:24 PM, Andy I wrote:
On Tue, Feb 4, 2025 at 07:37 PM, Ivan wrote:
Where did you upload them to? I looked in files but, don't see anything called "some-zener-model.zip"
?
The Files " Temp" folder is almost always the place to look first for newly-uploaded files. ?
Andy
?
Got 'em. Thank you. One more to go.
?
|
Re: Any Good Reason to Create a Hierarchical Connector and Conductors to Route (Plumb) Ground Out of a Hierarchical Schematic
Just an observation: there are a number of opamp models (for
example) that bring a V- (negative supply) pin out of the subckt.
The assumption being that the device can be used with V- grounded or
with a negative voltage supply rail. It turns out that the model
only works if V- is actually grounded and not with a negative
supply. This is good example of poor design.
If you have a sub-schematic, or .subckt, and an assumed internal
grounded connection that is brought out to the top level, it is
helpful and convenient to use the COM net (with its own triangular
symbol) within the .subckt instead of GND (0) triangle and to bring
this out through the symbol. You can still ground this at the top
level. Or not. If it's grounded, you can still plot the current
flowing in the COM pin to ground.
There are some situations where it is very difficult not to use
actual GND, even implicitly. The digital (A) devices are an example.
They have a hidden "device common", so the outputs can source
current, apparently from nowhere. I try to avoid anything where KCL
(Kirchhoff's Current Law) is not observed.
--
Regards,
Tony
|
Doesn't M-W include, 'plumb'? vt:? to
investigate deeply, and plumb adj 1: vertical, adj 2: very,
completely (mainly US)?
On 2025-02-05 03:57, eewiz via
groups.io wrote:
Hello All:
?
On Mon, Feb 3, 2025 at 10:45 PM, Andy I wrote:
By the way, I am not sure if
everyone here understands your use of the words "plumb" or
"plumb out".? Honestly, I am not sure that I know exactly what
you mean either.? Remember that a sizable percentage of?the
members of this group are not in North America and do not know
our slang.
?
?
From the Meriam Webster Dictionary
?
plumbing
?
: an internal system that
resembles plumbing especially
: one
consisting of conduits or channels for conveying fluids
?
?
On Mon, Feb 4, 2025 at 4:43 PM, mstokowski wrote:
: to
supply with or install as plumbing
?
intransitive verb
: to
work as a plumber
?
All for now
?
?
--
OOO - Own Opinions Only
Best Wishes
John Woodgate
Keep trying
|
Re: In need of some zeners or maybe model them myself
It is the case in 99.99% instances. There are
a few Spice models that include parasitics that vary with
packaging, but they are very high-frequency devices.
On 2025-02-05 01:30, Ivan via groups.io
wrote:
Funny that it just
dawned on me that it doesn't matter if the model is for a
through-hole or an SMD. That is the case, no?
--
OOO - Own Opinions Only
Best Wishes
John Woodgate
Keep trying
|
Re: In need of some zeners or maybe model them myself
I'm afraid I can't offer any leads to Spice
models. But I doubt that the transistor is very different from
others with similar voltage and current ratings. The data sheet
will show that (or not, if you are unlucky).
On 2025-02-05 00:46, Ivan via groups.io
wrote:
On Tue, Feb 4, 2025 at 04:11 AM, John Woodgate wrote:
Which country are you in?
I know of a British supply of the power transistor at a
very low price, comparatively, but not for export.
?
USA but, I'm not looking to get any. We have a supplier at work.
Don't know who and don't care what they cost. Not my circus.
Just looking for the spice model. In your first response you
said " Then
ask the manufacturer, found by a web search - STI in the case
of the 1N4572, Microchip for 1N5226, etc.". You're not
implying that you found spice models on their sites are you? I
haven't been able to get anywhere on either site.
--
OOO - Own Opinions Only
Best Wishes
John Woodgate
Keep trying
|
Any Good Reason to Create a Hierarchical Connector and Conductors to Route (Plumb) Ground Out of a Hierarchical Schematic
Hello All:
?
Just an FYI.
On 24.1.1, I added a hierarchical connector named RTN, and conductors, to route a net that was connected ground (GND) (node 0), out of a hierarchical schematic to permit connection of that net on a top level schematic to ground or possibly some other net.
Outside the hierarchical block I connected the RTN label through a resistor to a triangular (label 0) ground symbol.
After running the sim, pointing at the net connected to the ground symbol says "This is ground."
Pointing at the net on the opposite side of the resistor says "Click to plot V(n030)".
?
Inside the block, the RTN hierarchical connector and the attached net both have the V(n030) net name.
Inside the block, I restore the triangular (label 0) ground symbol and re-connect it to the net having that V(n030) net name.
?
After running the sim, nothing changes outside the block, still ground on one side of the resistor and V(n030) on the other side connected to the RTN hierarchical connector.
Inside the block, the RTN hierarchical connector still says "Click to plot V(n030)" but, the net connected to that RTN hierarchical connector now says "This is ground."
?
The resistor outside the block has one end connected to ground and its other end also connected to ground through a hierarchical connector named RTN.
That resistor should now disappear from the netlist but, it does not.
Pointing at the resistor still shows the "plot my current" arrow and the net that goes to ground through the hierarchical connector RTN still says "Click to plot V(n030)".
?
Since LTspice's ground (GND) (node 0) is a perfect superconductor that never drops any voltage, there can never be any current through that resistor because it is grounded on both ends.
It should not show a "plot my current" arrow when pointed at.
It says that the resistor has a DC operating point of -36.724039uA and 13.486551nW.
It says that V(n030) = -367.2404uV. It's a 10 ohm resistor.
LTspice becomes confused in this example.
?
When no hierarchy is involved:
A resistor grounded on both ends is removed from the netlist hence, it shows no "plot my current" arrow when pointed at.
A resistor grounded on one end with the other end unconnected or connected to an open wire, is also removed from the netlist.
Neither resistor's current nor the open net's voltage can be plotted.
?
If I remove the resistor and connect the RTN label directly to ground outside the block, the net inside the block changes from "Click to plot V(n030)" to "This is ground." and the RTN hierarchical label changes from "Click to plot V(n030)" to "node "RTN" (0)."
All results were identical regardless of the "Input", "Output" or "Bi-Direct" selection of the RTN hierarchical label.
?
When I ground the RTN label outside the block and move the resistor inside the block, everything works as it should.
The RTN label says "node "RTN" (0).", the resistor is grounded on both ends and its current cannot be plotted because it has been removed from the netlist.
?
My observations:
1. If routing ground out of a hierarchical schematic, be absolutely sure to remove all of the triangular (label 0) ground symbols from the interior of that hierarchical block and physically connect any nets that may have been disconnected by those ground symbol removals.
?
2. I have no evidence about the use of a hierarchical connector and conductors to route (plumb) the node 0 ground out of a hierarchical cell type sub-circuit because I have not had the need to experiment with such.
I would not be surprised to find that all nodes "0" within a sub-circuit would need to be renamed to something like "00" to ensure that LTspice does connect all those nodes together but does not sumarilly connect that net to ground.
Or maybe not, maybe LTspice treats node 0 within a sub-circuit cell differently then it treats the triangular (label 0) ground symbol within a sub-circuit block.
?
If anyone has proved or disproved the assertions in number observation 2 above, please opine.
?
All for now
|
Marcelo_Pessoa
Tony Casey
John Woodgate
eewiz