Orcad Viewer doesn't work

[Charlie E.]

Guys, I figured it out, with the help of Jim and my client:

Jim sent some files and they opened fine. Then my client who uses
Capture 16.3 saved in 16.2 and ... Myriad opens that as well. IOW,
Myriad does not seem to support the file format of the latest release.
Ain't that just great?

Oh Boy, so they changed the file format (again!) and didn't update the
reader for it! Remind me to tweak Greg the next time I see him... ;-)

Charlie

 

[Fred Bartoli]

Joel Koltner a écrit :

I'd be curious to hear what's "superior" about the 16.3 format vs. the
16.2 format.

The "what's new" notes for 16.3
(http://www.cadence.com/products/orcad/pages/orcad_16_3.aspx) don't
mention this little change, but if you open an older ORCAD schematic in
16.3, when you go to save it you're prompted for whether or not you'd
like to use the new format.

On the other hand... TCl/Tk support? In 2010 for a product that's never
had it before? Wow. I mean, I've written a few TCl/Tk scripts in my
life, and it's a perfectly decent language, but that was some years
back... and for tools that had had TCl/Tk for years prior. I.e., I find
it hard to believe that anyone writing a *new* ORCAD script is going to
choose TCl/Tk over Visual BASIC. They must have had some big corporate
customer who wanted it? I mean, if you're going to spend money
developing new scripting abilities in ORCAD, I'd think a COM interface
would be the way to go.

---Joel

Lots of CAD packages also have to run on unix systems (where people are
used to TclTk).

Good luck with VB on 'nix

 

[Joerg]

Their layout program not only had a dongle but was a buggy piece of
garbage in the beginning.

Which is why I never used it. I only used the schematic editor. That was
dongle-less and literally bug-free. I lived and worked in Europe back
then and there they seemed to trust people less because the versions
there were dongled. And more than double in price. Sooo ... I did the
usual and bought it in the US

Layout SW isn't all that important to me and most other design engineers
that I know. The layout job is nearly always farmed out because that is
less expensive for the client. Same in chip design. Of course, larger
companies have employed layouters in house. Unless the design is super
critical RF circuitry having the engineer do the layout usually doesn't
make business sense.

 

[Joerg]

Probably. I've seen it work with 15+ page hierarchical schematics in a
fairly recent version.

The major factor here is the word "fairly". Turns out it does work with
16.2 release files but not with 16.3 release files.

 

[Joerg]

Sorry guys,
Been goofing off and getting work done today while waiting for the
solder stencils to get here for the next prototype...

Jeorg,
The .DSN file SHOULD contain all the library parts internally. It
keeps a local cache of the parts in the design. One of those gotchas
when you go and alter the part in the library, and then wonder why all
those transistors have the wrong parameters on them...

Can you have the originator try opening the files on a 'virgin'
machine? It could be he has been archiving the files after turning
off the 'library files' option since, of course, they already HAVE all
the library files configured!

Yes, adding the library files to the archive is an option... :-(

Well, we found it out. Myriad does not like the latest Orcad file
format, if you move one or more releases back it works. I'd call that a
screw-up ;-)

 

[Joerg]

JeffM wrote:
Joerg wrote:
JeffM wrote:
Joerg wrote:
Man, Eagle is so much better,
the *.sch files always contain _everything_.

Yup. **Everything**.
http://tinyurl.com/TheEAGLE-Virus

I have had no such issues in over five years that I use Eagle.

That's one data point.
The experience Marcus had is another.

[...]when dealing only with honest people
(who refuse to run stolen software) there is no problem.

The trick is to *assure* that.
Marcus *thought* he was safe, yet he still got screwed by Cadsoft.
Everyone has to decide for himself if he wants to roll the dice
--or just avoid Cadsoft's stuff.
I maintain that even the "legit" stuff you get from the company
is still warez.

You seem to be on a cruzade there

He wrote, quote "It happened that back then, I reused a very small part
of this schema (with copy and paste) in one of my projects and continued
to copy and paste the same part from my project into a couple of other
projects of mine later on."

I never do that, ever. That's quite similar to downloading some
executable from an unknown source and then complaining that all hell
broke loose.
Pretty hard to have a problem like that when a schematic file is
text-only (as in PSpice Schematics

...Jim Thompson

Except Schematics doesn't contain any of the symbol library info, so
you have to include a complete set of libraries when you send a copy
to someone...

Charlie

Not so. You've forgotten the "Archive Workspace" that collects
everything you've used into the schematic.

In text format? That would be a re-invented HPGL then?

 

[Nico Coesel]

And foot pumps probably weren't available until the next 5-year plan
kicked in, and then only if you had connections to some of the higher-ups.

AFAIK the foot pump was standard just like the starting crank. At
least they where on my parent's Lada. Never needed either though.

 

[Nico Coesel]

Yeah, but I don't think ORCAD is one of those packages.

And I can't imagine they'd thinking of porting it -- I suspect few if any
people in the market for *new* CAD tools buys ORCAD anyway; their money comes
from maintenance contracts and firms already using it that need more licenses
due to growth.


Unfortunately, as far as I'm aware, *NIX doesn't have any interprocess
communication (well, function call) standard that's widely supported. On
Windows, regardless of which language your application is written in, once it
supports COM, you can "talk" to it from command prompt scripts, Visual BASIC,
Excel, or pretty much any other program you feel like.

On unix you use tcp/ip.

 

[Joerg]

AFAIK the foot pump was standard just like the starting crank. At
least they where on my parent's Lada. Never needed either though.

A Lada station wagon I saw had a crowbar as standard equipment.
Seriously. So if you drove somewhere and had to whack out a tile floor
the tool was already right there.

But this is all Western Europe. Whole different story behind the former
iron curtain. People had to get in line and sometimes wait more than a
decade for a car. Whether you had the money or not didn't make a
difference. What I really don't get is that there are still people who
believe such an economic system is better.

 

[Charlie E.]

JeffM wrote:
Joerg wrote:
JeffM wrote:
Joerg wrote:
Man, Eagle is so much better,
the *.sch files always contain _everything_.

Yup. **Everything**.
http://tinyurl.com/TheEAGLE-Virus

I have had no such issues in over five years that I use Eagle.

That's one data point.
The experience Marcus had is another.

[...]when dealing only with honest people
(who refuse to run stolen software) there is no problem.

The trick is to *assure* that.
Marcus *thought* he was safe, yet he still got screwed by Cadsoft.
Everyone has to decide for himself if he wants to roll the dice
--or just avoid Cadsoft's stuff.
I maintain that even the "legit" stuff you get from the company
is still warez.


You seem to be on a cruzade there

He wrote, quote "It happened that back then, I reused a very small part
of this schema (with copy and paste) in one of my projects and continued
to copy and paste the same part from my project into a couple of other
projects of mine later on."

I never do that, ever. That's quite similar to downloading some
executable from an unknown source and then complaining that all hell
broke loose.

Pretty hard to have a problem like that when a schematic file is
text-only (as in PSpice Schematics

...Jim Thompson

Except Schematics doesn't contain any of the symbol library info, so
you have to include a complete set of libraries when you send a copy
to someone...

Charlie

Not so. You've forgotten the "Archive Workspace" that collects
everything you've used into the schematic.

...Jim Thompson

Actually, I remember when we FINALLY got that added! It sure made
support a lot easier... ;-)

Charlie

 

[Charlie E.]

I'd be curious to hear what's "superior" about the 16.3 format vs. the 16.2
format.

The "what's new" notes for 16.3
(http://www.cadence.com/products/orcad/pages/orcad_16_3.aspx) don't mention
this little change, but if you open an older ORCAD schematic in 16.3, when you
go to save it you're prompted for whether or not you'd like to use the new
format.

On the other hand... TCl/Tk support? In 2010 for a product that's never had
it before? Wow. I mean, I've written a few TCl/Tk scripts in my life, and
it's a perfectly decent language, but that was some years back... and for
tools that had had TCl/Tk for years prior. I.e., I find it hard to believe
that anyone writing a *new* ORCAD script is going to choose TCl/Tk over Visual
BASIC. They must have had some big corporate customer who wanted it? I mean,
if you're going to spend money developing new scripting abilities in ORCAD,
I'd think a COM interface would be the way to go.

---Joel

Actually, I 'sorta' remember them saying something about a new feature
that had required a database change in a user group meeting I went to
a few weeks ago. The trouble with Capture is that it is a bastardly
kludge, with features and interfaces added on top of and around all
the existing features and interfaces, so it is very easy to break...
;-)

Charlie

 

[Joerg]

Actually, I 'sorta' remember them saying something about a new feature
that had required a database change in a user group meeting I went to
a few weeks ago. The trouble with Capture is that it is a bastardly
kludge, with features and interfaces added on top of and around all
the existing features and interfaces, so it is very easy to break...
;-)

But once upon a time, around 1990, it was perfect

 

[Charlie E.]

But once upon a time, around 1990, it was perfect

I know you keep saying that Joerg, but it drove me crazy! I was using
it on a windows machine, and wanted to run in 1024x760, and couldn't
see any text on the symbols! The inability to zoom in beyond native
resolution made it a major posterial pain to use, since I had to
change resolutions just to use it!

Charlie

 

[Nico Coesel]

TCP/IP is just "a stream" so you end up writing a custom protocol every time,
and the parser and buffering end up making such an approach at least an order
of magnitude slower than COM's "direct call" interface...

Did you ever analyze that 'direct call'? Just look up 'marshalling'.

Granted, these days CPUs are often fast enough the raw speed doesn't matter --
with COM you never know if what you're calling was written in assembly, C++,
Python, Visual BASIC, or any other language --, but having to parse the data
in a TCP/IP stream (even if you already have a nice library to do this) is
kinda klunky, IMO.

COM does the same thing but in a very complex way.