Re: LT Spice looks

On Wed, 13 Nov 2024 17:20:20 -0500, "Edward Rawde"
<invalid@invalid.invalid> wrote:

"john larkin" <jl@glen--canyon.com> wrote in message news:aq7ajj59feghbv9cbdr5ip42ffqlbtl607@4ax.com...

On Wed, 13 Nov 2024 14:09:14 -0500, "Edward Rawde"
<invalid@invalid.invalid> wrote:
>

"john larkin" <jl@glen--canyon.com> wrote in message news:nbr9jj5rkdrs81tgi1iv2ar8p1f9klu084@4ax.com...

On Wed, 13 Nov 2024 12:02:36 -0500, "Edward Rawde"
<invalid@invalid.invalid> wrote:
>

"john larkin" <JL@gct.com> wrote in message news:0ul9jj906v7pungdbs1u82mrqel9lv7tlr@4ax.com...

On Wed, 13 Nov 2024 11:26:30 -0500, "Edward Rawde"
<invalid@invalid.invalid> wrote:
>

"john larkin" <JL@gct.com> wrote in message news:33h9jjhk0tb3vm31r4fatp265q3dt22mem@4ax.com...

On Wed, 13 Nov 2024 08:17:31 -0500, legg <legg@nospam.magma.ca> wrote:
>

On Tue, 12 Nov 2024 16:30:44 -0800, john larkin <jl@glen--canyon.com>
wrote:
>

Have you noticed that an LT Spice schematic looks different if you
open it on different computers? The fonts seem to change.

>
Picture is worth a thousand words here.
>
Different ?
>
RL

>
Mostly fonts. Some can come from different settings, but even with the
same settings things are weird.
>
As one zooms in and out, font scaling does not track graphic scaling.
Try it. The length of strings jumps around. So if you make something
look good at some zoom level, it gets ugly at others, like text
overlapping parts and such.

>
It's always done that since I've been using it.
>

>
And there are different grids for parts and lines and for different
kinds of text. So it's hard to keep stuff aligned.
>
All that makes it hard to draw a neat schematic.

>
I've worked in plenty of places where you didn't get to draw your own schematic so you just had to deal with the fact that
although
it produced a correct netlist it didn't look anything like what you'd have drawn yourself.
>

>
I believe that a beautiful schematic, for simulation or for a real
PCB, works better than an ugly schematic.
>
I see real horrors posted here, and elsewhere.

>
If the netlist and PCB layout is correct then why waste time on making the schematic look like you want it, only to be told by
someone else that they would have drawn it completely differently?
>

>
The time spent making a schematic look good is essentially another
design review, more eyeball time on the problem.

>
A good engineer will do that anyway, but it doesn't necessarily mean that the design will look good to someone else.
>

>
And who dares to order a design engineer to change his schematic?

>
LOL some of the managers I've worked for.
And drawing office people who weren't going to let you use your own logic symbols or other symbols.

>
I remember long ago when we had draftsmen who took sketches and drew
schematics on paper, with straight lines. Some of their stuff was ugly
too.
>
Now, most engineers enter schematics themselves. All the logic symbols
come out of a company-shared library.
>
I still like to start with a D-size pencil-on-paper schematic, partly
because I don't need to use library parts at the early stage of
design.

>
I sometimes draw parts of a circuit on paper, usually when I want to calculate something or sketch/brainstorm something, but I
haven't drawn a full schematic on paper directly myself since somewhere around 1988.
>

>
>
>

>

>
Well, I do insist that my engineers treat a Spice schematic like a
real document, with proper title block, author, date revision control.
>
The sloppy software hacking mentality is terrible when applied to
hardware design.

>
But not long ago you were agreeing with me about trying things out, either in your mind or as an experimental prototype.
Isn't that just like trying things out in software?

>
Simulations, sketches, brainstorming, breadboards are quick and easy,
and encourage people to think and change their minds. But
production-quality multilayer PC boards are not the most efficient way
to experiment.

>
Ok so the question is when do you switch from Simulations, sketches, brainstorming etc to revision control?
The schematics people post here are not usually under revision control so they don't need "proper title block, author, date
revision
control."
I can think of no reason why anyone would get upset about the absence of this information on such a schematic.

>
It answers the questions     What the hell is this?    Who did this?
>
A few years later, it's best to know this stuff.

>
Once it's in my filing system it will probably never be seen again.

Never see the Spice model again? That certainly reduces the
documentation requirements.

Around here, even whiteboard sketches are titled and dated and
photographed and archived in a project folder.

>

>

>

>

One place I worked tried to get to just two PCB iterations before production.

>
Our goal is one: sell rev A.
>

My comment at the time was that software should also be told that they can only compile it twice.

>
When we worked on paper, with punched tape or cards, we'd actually
READ our code before we assembled and ran. I wrote one RTOS while
visiting a friend in Juneau Alaska and mailed hand-written pages back
to the home office to be punched and assembed and tested. It had one
bug.

>
When I first wrote some code which was going to be run for me, the form I filled in was taken elsewhere and manually transferred
to
punch cards which were then fed into the computer which I never saw. The output was returned to me on paper. A transcription error
caused my first program to fail.
It was clear to me at the time that if only I could have my own computer to see the output immediately then I could run, test,
run,
test, experiment, run test and eventually arrive at a program I was happy with.
>
When I actually got a computer which could run my own code I had to put the kit together myself and enter the code bytes myself.
https://en.wikipedia.org/wiki/MK14
One thing which was immediately apparent was that one little mistake in the code would turn it into a program which randomly
rewrote
itself and then you'd have to enter it all again. I got as far as being able to save a program on a reel-reel tape recorder.
>
>

>
The easier it is to run something, the less checking will be done, and
the more bugs there will be. Bridges and buildings and airplanes get
checked before they are built so have less bugs than Windows.

>
You might want to talk to Boeing about that.

The door plug blowout was a field assembly error. Required parts
weren't installed.

Not to mention
https://www.google.com/search?q=florida+university+bridge+collapse
Or
https://en.wikipedia.org/wiki/Surfside_condominium_collapse
>

Building collapses usually happen because the construction is not in
conformance with the signed-off drawings.

Our drawings define the end product, but usually don't detail every
steps that manufacturing uses to achieve conformance to drawings. QC
does inspect the final assemblies for conformance to all released
documents.