Keyboard Shortcuts
Likes
- LTspice
- Messages
Search
|
Re: Trying to use .MOD file in schematic
Model files (.MOD, .LIB, .SUB, .TXT, .whatever) can be added either to a schematic (.ASC file), or to a symbol (.ASY file) that then is placed on the schematic.? Exactly how and where you add the path to the model file, depends on which one it is.? We need more details to answer your concerns.
?
Andy
? |
|
Re: Trying to use .MOD file in schematic
On Wed, Feb 5, 2025 at 10:36 PM, <william.finley@...> wrote:
What said all that?? Did you watch a YouTube video? What kind of component are you doing this with? ?
If it is an inductor, and if you need to make special edits to the component, do not either left-click or right-click on the inductor symbol.? Instead, use Ctrl-Right-click on the symbol.? That brings up the General Attribute Editor, where you can add to or edit each attribute.? If you just Right-clicked, then you get the special inductor editor that has special fields for things like Series and Parallel Resistance, and I'm guessing those were not the fields you wanted to edit.
?
What is this .MOD file for?? Is it for an inductor?? For a transistor?? For a diode?? For an IC?
?
It is rather unusual to use a model or .MOD file for an inductor, but I can't tell what you are trying to do with it.? Can you tell us more?
?
Andy
?
? |
|
Trying to use .MOD file in schematic
I did .include "the file path to the mod file" but it says I need to right click a general part and include the subcircuit name for the value and erase spice model. Every time I put a generic part on the schematic and left click, it does not give me that table with all the categories I am suppose to fil in. It give me things like inductance, parallel capacitance, parallel resistance and DC resistance. How do I enact this .MOD file into a component so I can use it? Thanks.? |
|
Re: Over-voltage protection circuit does not work as expected
¿ªÔÆÌåÓýDave, thanks for the advice. The ramp down is not needed indeed. Anyway, the original model of TLV1805 is a nice find. ? Jurek ? From: <[email protected]> on behalf of "Bell, Dave via groups.io" <Dave.Bell@...> ? You¡¯re right - it does work! I found the output voltage curve a little confusing by itself, with the ramp Up and ramp Down. But reducing the output cap to 10u or increasing the load to 100 ohms, it became clear; it was just the slooow decay that looked weird. ? Dave ? From: [email protected] <[email protected]> On Behalf Of jerzy przezdziecki via groups.io
Sent: Wednesday, February 05, 2025 12:51 PM To: [email protected] Subject: EXTERNAL: Re: [LTspice] 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@...> ? Is there a circuit for this thread? Ild like to look at it myself when i get home. ?
|
|
Re: Over-voltage protection circuit does not work as expected
¿ªÔÆÌåÓýYou¡¯re right - it does work! I found the output voltage curve a little confusing by itself, with the ramp Up and ramp Down. But reducing the output cap to 10u or increasing the load to 100 ohms, it became clear; it was just the slooow decay that looked weird. ? Dave ? From: [email protected] <[email protected]>
On Behalf Of jerzy przezdziecki via groups.io
Sent: Wednesday, February 05, 2025 12:51 PM To: [email protected] Subject: EXTERNAL: Re: [LTspice] 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@...> ? Is there a circuit for this thread? Ild like to look at it myself when i get home. ?
|
|
Re: Over-voltage protection circuit does not work as expected
Cool thanks.
toggle quoted message
Show quoted text
|
|
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@...> ? Is there a circuit for this thread? Ild like to look at it myself when i get home. ?
|
|
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.
toggle quoted message
Show quoted text
|
|
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 ¨C as you said ¨C the TLV1805 is made for this purpose. Jurek ? From: <[email protected]> on behalf of "mpessoa via groups.io" <mpessoa@...> ? I understand that overvoltage protection (OVP) must be a very simple and reliable circuit. ? ? ? |
|
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. ?
?
? |
|
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. Le 05/02/2025 ¨¤ 16:41, Udo
Huhn-Rohrbacher via groups.io a ¨¦crit?:
|
|
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]>:
--
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:
Makes sense. 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:
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 ¨C 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@...> ? 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 ? 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 ¨C that forces the out out to an open/pulled-up state. ? Dave ? From: [email protected] <[email protected]> On Behalf Of Roy McCammon via groups.io ? 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
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.
?
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.
?
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.
?
Yes, that would be true if N003 was actually ground.? But it is not.? Do not think that N030 = 0. 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.
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.
?
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. ?
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:
Got 'em. Thank you. One more to go. ? |
Bell, Dave
Marcelo_Pessoa
Tony Casey