[Rich Grise]

Hmm... we should do that with software guys... pretty much free beer for
life...

Does code for embedded controllers count as "software"?

Oh, wait - that's "firmware." you get to see the results the first time
you see it in action. I redid some other guy's stepper driver loop, and
it was sinfully gratifying to hear the observers (essentially everybody
else at the company) going "Ooooh! Aaaah!"

Cheers!
Rich

 

[Joerg]

krw wrote:
John Larkin wrote:
John Larkin wrote:
John Larkin wrote:
[...]

I never do hierarchical schematics. Everything's flat.

Then we have almost opposite CAD habits. But at least we have similar
beer taste, only the good stuff
What happens to reference designators in a hierarchical schematic?

Typically it numbers right on through if you hit auto-number. But it
really never mattered to me in my Orcad days because most clients wanted
a back annotation anyhow, so that the top left of the physical PCB
started with R1, C1 and the bottom right would end with R542, C367. Then
that got fed into the schematic, I updated my module spec with the new
refdeses, done.

I don't understand that. If the schematic has a main controller part
and, say, 16 channels, and you draw one instance of the channel,
abstract that into a block, and draw 16 of the blocks - which is what
a hierarchical schematic does - how does each instance have its own
reference designators, sequantial across all the modules?

Yes, it just starts with the next available number at block 1, then goes
on to block 2 and so on until all sub-sheets are done. For proper
documentation you must let it print out all 16 blocks, otherwise a
technician could never repair the unit. For a design review you don't
necessarily have to (in med or aero and such you usually do).
We're planning on setting the service and test departments up with
schematic viewers so they can use the hierarchy.

Hey, did you start modernizing the place? When I did that the first time
it was met with quite a bit of resistance. Until they started feeling
the benefits. "How did you get that stock room quantity?" ... "From my
computation machine." ... "Oh."
If I have anything to do with it... They already have the PCs, but
use them to view PDFs.

I think I finally got them to understand that engineering really needs
prices. Sometime in the future they're going to dump the purchasing
database into the parts database once a month. It's a start.
Quantity?

Quantity on hand should be in there as well. So that a rookie doesn't
design in the uA741 that purchasing still has to occasionally buy for
the old design that uncle Leroy did in the 70's.

I'll be happy with the price. There are only two of us doing any
hardware design and I know *I* won't be using a '741. ;-)

[...]
Next issue: how do you deal with multiple SKUs built off the same
schematics? They want us to manually edit the schematics for service.
I'm trying to convince them that they really don't want to do that. I
certainly don't want to be held responsible for multiple versions of
the same data.

Old rule: When only one part on the circuit board is changed in value it
is another assembly and must get another assy number. No ifs, buts or whens.

Sure, that's obvious but it still doesn't solve the schematic problem.
They want schematics for service to use[*]. We're experimenting with
"graying" (yellow, actually) out sections not implemented but it's
manual and quite labor intensive. The other problem we ran into was
that to select any component under the "fill" it has to be removed.
The fill will be selected first.

[*] I'm fighting this one.

I wouldn't fight it. Our coutry needs young technicians to understand to
read schematic.

But the same schematic with grayed out areas for two or more versions? I
wouldn't do that.

 

[Joerg]

At that point back-annotating loses it's importance. We don't back
annotate reference designators; not sure why.

Not really. There is always a time when you don't have computer access.
for example when we had a main HV line arc over in WA state and power
went for 23hrs. We could plug along. Although, after 2-3 hours the air
in the building became so stale that we moved to my hotel room. Also no
power, of course, but it had a fireplace and a sliding door that could
be opened.

 

[Joerg]

Does code for embedded controllers count as "software"?

Oh, wait - that's "firmware." you get to see the results the first time
you see it in action. I redid some other guy's stepper driver loop, and
it was sinfully gratifying to hear the observers (essentially everybody
else at the company) going "Ooooh! Aaaah!"

I did that once. Then marketing wanted the "rat-tat-tat-grrrrrrrrrrrrr"
of the old scheme put back in because users could then hear the motor
working :-(

 

[Joerg]

Only when there is an idiot at the helm.

Do you mean the programmers?

 

[Archimedes' Lever]

I think that's (partially) up to the printer driver?

All you have to do is spool of the print job of a single page to a
paused printer, and you will see that the print job's datagram size is
huge on pdfs.

-- Since a Windows app is
still calling DrawLine/DrawEllipse/etc.

Not all Windows apps follow that page construction format. Nor do they
need to.

when it's printing (as well as
DrawBitmap), the printer driver can just forward the vector graphics
information onto the printer if the printer knows how to rasterize ("rip")
vector graphics itself... and I'm under the impression that many "high end"
(office) printers do it this way.

Nope. Printers receive a finished page that gets formatted by the
driver to contain the page start headers and page finish footer. That
datagram gets assembled at the computer for a pdf. There are not very
many that do post script any more, and even adobe does not default the
pdf compiled page to post script.

I'd say that most any print job that is not using fonts at the printer,
are passing completed pages to the printer whether it is a graphic or
uses drawing functions. The driver is the only place where one sees true
WYSIWYG previews. That is why CAD apps have the print drivers integrated
so deeply into their print function application section. Also, finished
pages sent to the print yields more ppm from the printer than when the
print engine has to process the data sent to it further to achieve the
finished datagram it feeds the drum with. I think drivers lean toward
compiled, finished pages as opposed to a block of data that has to be
further processed. Not all printers have huge memory sticks incorporated
into them.

 

[Fred Abse]

The print jobs are bit mapped graphics, just like I said. That is how
it is compiled, and sent to the printer.

That's not what you said. You said "A pdf is a full bit map. Every pixel
is defined and stored", which is not true.

 

[Archimedes' Lever]

Do you mean the programmers?

at your facility and at adobe as well for not being able to make it
idiot proof.

 

[krw]

krw wrote:
krw wrote:
John Larkin wrote:
John Larkin wrote:
John Larkin wrote:
[...]

I never do hierarchical schematics. Everything's flat.

Then we have almost opposite CAD habits. But at least we have similar
beer taste, only the good stuff
What happens to reference designators in a hierarchical schematic?

Typically it numbers right on through if you hit auto-number. But it
really never mattered to me in my Orcad days because most clients wanted
a back annotation anyhow, so that the top left of the physical PCB
started with R1, C1 and the bottom right would end with R542, C367. Then
that got fed into the schematic, I updated my module spec with the new
refdeses, done.

I don't understand that. If the schematic has a main controller part
and, say, 16 channels, and you draw one instance of the channel,
abstract that into a block, and draw 16 of the blocks - which is what
a hierarchical schematic does - how does each instance have its own
reference designators, sequantial across all the modules?

Yes, it just starts with the next available number at block 1, then goes
on to block 2 and so on until all sub-sheets are done. For proper
documentation you must let it print out all 16 blocks, otherwise a
technician could never repair the unit. For a design review you don't
necessarily have to (in med or aero and such you usually do).
We're planning on setting the service and test departments up with
schematic viewers so they can use the hierarchy.

Hey, did you start modernizing the place? When I did that the first time
it was met with quite a bit of resistance. Until they started feeling
the benefits. "How did you get that stock room quantity?" ... "From my
computation machine." ... "Oh."
If I have anything to do with it... They already have the PCs, but
use them to view PDFs.

I think I finally got them to understand that engineering really needs
prices. Sometime in the future they're going to dump the purchasing
database into the parts database once a month. It's a start.
Quantity?

Quantity on hand should be in there as well. So that a rookie doesn't
design in the uA741 that purchasing still has to occasionally buy for
the old design that uncle Leroy did in the 70's.

I'll be happy with the price. There are only two of us doing any
hardware design and I know *I* won't be using a '741. ;-)

[...]
Next issue: how do you deal with multiple SKUs built off the same
schematics? They want us to manually edit the schematics for service.
I'm trying to convince them that they really don't want to do that. I
certainly don't want to be held responsible for multiple versions of
the same data.

Old rule: When only one part on the circuit board is changed in value it
is another assembly and must get another assy number. No ifs, buts or whens.

Sure, that's obvious but it still doesn't solve the schematic problem.
They want schematics for service to use[*]. We're experimenting with
"graying" (yellow, actually) out sections not implemented but it's
manual and quite labor intensive. The other problem we ran into was
that to select any component under the "fill" it has to be removed.
The fill will be selected first.

[*] I'm fighting this one.

I wouldn't fight it. Our coutry needs young technicians to understand to
read schematic.

But the same schematic with grayed out areas for two or more versions? I
wouldn't do that.

The problem is that there is no way to assure the schematics stay in
sync with each other. Everything is a manual and tedious process,
thus prone to error. I don't like adding error prone processes into
the flow.

 

[Joerg]

[...]

Old rule: When only one part on the circuit board is changed in value it
is another assembly and must get another assy number. No ifs, buts or whens.
Sure, that's obvious but it still doesn't solve the schematic problem.
They want schematics for service to use[*]. We're experimenting with
"graying" (yellow, actually) out sections not implemented but it's
manual and quite labor intensive. The other problem we ran into was
that to select any component under the "fill" it has to be removed.
The fill will be selected first.

[*] I'm fighting this one.

I wouldn't fight it. Our coutry needs young technicians to understand to
read schematic.

But the same schematic with grayed out areas for two or more versions? I
wouldn't do that.

The problem is that there is no way to assure the schematics stay in
sync with each other. Everything is a manual and tedious process,
thus prone to error. I don't like adding error prone processes into
the flow.

Oh-oh, that's sound like there isn't a proper ECO process in place.
Maybe that is where some fint-tuning needs to be done first ;-)

 

[Joerg]

at your facility and at adobe as well for not being able to make it
idiot proof.

At mine? No programmers here. Strangely, _all_ other software behaves
very well and is stable. Weird, isn't it?

 

[John Larkin]

krw wrote:

[...]

Old rule: When only one part on the circuit board is changed in value it
is another assembly and must get another assy number. No ifs, buts or whens.
Sure, that's obvious but it still doesn't solve the schematic problem.
They want schematics for service to use[*]. We're experimenting with
"graying" (yellow, actually) out sections not implemented but it's
manual and quite labor intensive. The other problem we ran into was
that to select any component under the "fill" it has to be removed.
The fill will be selected first.

[*] I'm fighting this one.

I wouldn't fight it. Our coutry needs young technicians to understand to
read schematic.

But the same schematic with grayed out areas for two or more versions? I
wouldn't do that.

The problem is that there is no way to assure the schematics stay in
sync with each other. Everything is a manual and tedious process,
thus prone to error. I don't like adding error prone processes into
the flow.

Oh-oh, that's sound like there isn't a proper ECO process in place.
Maybe that is where some fint-tuning needs to be done first ;-)

Once we formally release a letter rev of a schematic, we don't change
it. The actual parts values and used/unused status is determined by a
BOM (parts list) and any applicable ECOs. We can have multiple
dash-number versions of a basic assembly, and fixes or customer
specials can be ECOs of standard dash-number versions.

We know the history and status of every board, by serial number.

John

 

[John Larkin]

At mine? No programmers here. Strangely, _all_ other software behaves
very well and is stable. Weird, isn't it?

DimBulb seems to think that all software, especially Microsoft
crapware, is perfect, and anybody who has any problems is an idiot.

He even liked Vista!

John

 

[Joerg]

krw wrote:
[...]

Old rule: When only one part on the circuit board is changed in value it
is another assembly and must get another assy number. No ifs, buts or whens.
Sure, that's obvious but it still doesn't solve the schematic problem.
They want schematics for service to use[*]. We're experimenting with
"graying" (yellow, actually) out sections not implemented but it's
manual and quite labor intensive. The other problem we ran into was
that to select any component under the "fill" it has to be removed.
The fill will be selected first.

[*] I'm fighting this one.
I wouldn't fight it. Our coutry needs young technicians to understand to
read schematic.

But the same schematic with grayed out areas for two or more versions? I
wouldn't do that.
The problem is that there is no way to assure the schematics stay in
sync with each other. Everything is a manual and tedious process,
thus prone to error. I don't like adding error prone processes into
the flow.

Oh-oh, that's sound like there isn't a proper ECO process in place.
Maybe that is where some fint-tuning needs to be done first ;-)

Once we formally release a letter rev of a schematic, we don't change
it. The actual parts values and used/unused status is determined by a
BOM (parts list) and any applicable ECOs. We can have multiple
dash-number versions of a basic assembly, and fixes or customer
specials can be ECOs of standard dash-number versions.

We know the history and status of every board, by serial number.

That's how it ought to be. Now you can calmly lean back and sip a coffee
even when an auditor waltzes in out of the blue.

I try to work that way even as a consultant but of course I am not
(officially ...) allowed to write ECOs. In my case I also keep a design
history because in some markets that can be asked for in an audit.

 

[krw]

krw wrote:

[...]

Old rule: When only one part on the circuit board is changed in value it
is another assembly and must get another assy number. No ifs, buts or whens.
Sure, that's obvious but it still doesn't solve the schematic problem.
They want schematics for service to use[*]. We're experimenting with
"graying" (yellow, actually) out sections not implemented but it's
manual and quite labor intensive. The other problem we ran into was
that to select any component under the "fill" it has to be removed.
The fill will be selected first.

[*] I'm fighting this one.

I wouldn't fight it. Our coutry needs young technicians to understand to
read schematic.

But the same schematic with grayed out areas for two or more versions? I
wouldn't do that.

The problem is that there is no way to assure the schematics stay in
sync with each other. Everything is a manual and tedious process,
thus prone to error. I don't like adding error prone processes into
the flow.

Oh-oh, that's sound like there isn't a proper ECO process in place.
Maybe that is where some fint-tuning needs to be done first ;-)

Maybe you're not reading what I write (or I'm not writing what I
mean). ;-)

The ECO process is fine. We can build the widgets just fine. The
boss wants schematics to match the different products, built from the
same boards (actually two different revisions, but that is an
unrelated ECO process problem). The schematic reflects the board (max
population). Each of the three products is a make from, off that
schematic, with a different BOM at the higher level. Since the
schematic reflects the max-populated board, which doesn't exist, it's
"too confusing" for service.

Again, it's not an ECO problem. It is a documentation "problem",
since there isn't a schematic that matches the product BOMs. To
generate those schematics would be a labor intensive and error prone
project.

 

[krw]

Not really. There is always a time when you don't have computer access.
for example when we had a main HV line arc over in WA state and power
went for 23hrs. We could plug along. Although, after 2-3 hours the air
in the building became so stale that we moved to my hotel room. Also no
power, of course, but it had a fireplace and a sliding door that could
be opened.

If we have no power, we have no lights or soldering irons either.

 

[krw]

If you boss decides your guys really do need those three separate schematics,
you can point out to him that upgrading to Capture CIS (that supports variant
views and BOMs directly) is quickly cheaper than the labor to do all this
manually...

We have one seat of CIS. The layout guy is the only one who has the
license, so maybe I'll point that out to the boss. ;-) No idea why
he has it. Before my time.

 

[Joerg]

If we have no power, we have no lights or soldering irons either.

This was in the northern part of WA state. Most folks lived in the
boonies, the outdoors types, quite well prepared. Inverters, generators,
12V irons, several Weber barbies, propane fridges, beer, you name it,
they've got it. No matter whether there is power or not

 

[Joerg]

krw wrote:
[...]

Old rule: When only one part on the circuit board is changed in value it
is another assembly and must get another assy number. No ifs, buts or whens.
Sure, that's obvious but it still doesn't solve the schematic problem.
They want schematics for service to use[*]. We're experimenting with
"graying" (yellow, actually) out sections not implemented but it's
manual and quite labor intensive. The other problem we ran into was
that to select any component under the "fill" it has to be removed.
The fill will be selected first.

[*] I'm fighting this one.
I wouldn't fight it. Our coutry needs young technicians to understand to
read schematic.

But the same schematic with grayed out areas for two or more versions? I
wouldn't do that.
The problem is that there is no way to assure the schematics stay in
sync with each other. Everything is a manual and tedious process,
thus prone to error. I don't like adding error prone processes into
the flow.

Oh-oh, that's sound like there isn't a proper ECO process in place.
Maybe that is where some fint-tuning needs to be done first ;-)

Maybe you're not reading what I write (or I'm not writing what I
mean). ;-)

The ECO process is fine. We can build the widgets just fine. The
boss wants schematics to match the different products, built from the
same boards (actually two different revisions, but that is an
unrelated ECO process problem). The schematic reflects the board (max
population). Each of the three products is a make from, off that
schematic, with a different BOM at the higher level. Since the
schematic reflects the max-populated board, which doesn't exist, it's
"too confusing" for service.

Again, it's not an ECO problem. It is a documentation "problem",
since there isn't a schematic that matches the product BOMs. To
generate those schematics would be a labor intensive and error prone
project.

Proper documentation would be a requirement for me to sign on the dotted
line of an ECO. Drove some folks crazy, but ...

If the schematic is clearly marked, for example with dashed lines around
certain areas and some text like "not installed on XYZ version", then
it's ok. Else there has to be a matching schematic even if that means
more work.

 

[krw]

This was in the northern part of WA state. Most folks lived in the
boonies, the outdoors types, quite well prepared. Inverters, generators,
12V irons, several Weber barbies, propane fridges, beer, you name it,
they've got it. No matter whether there is power or not

Laptop w/12V auto/air brick.