xcircuit-dev — XCircuit news and discussion

[Xcircuit-dev] RE: XCircuit netlist to pcb problems

[Eric Y. C. <er...@al...>]

Hi Tim.  I used defaults for both runs.  I did remember 1/6 in.
The 2.3.3 did not work, but the 2.5.4 did.  It came up with the
correct netlist (having connectivity).  Note that the 2.5.4 did
not produce a picture in which the diode end points lined up
with each other (now clear from your explanation).  But, the
netlist extraction worked just fine, presumably due to the
tolerance for accepting a connection.

The 2.3.3 drew a picture that was less well aligned.  This 
could have been the root cause, or it could have been a
netlisting bug.

Anyway, I am now using 2.5.4 (which has incidentally had less
crashing problems than 2.3.3 as well).  It works just great for
the netlisting, aside from the asthetically displeasing diode
picture.  Should enforce a 45 degree prohibition :-).  Just
kidding.

Thanks for all the help.

Eric


>Dear Eric,
>
>> There is a hint of trouble since the items from the 2nd library
>> seem to be on a different grid than the main drawing area.
>
>That would be a problem because they're not supposed to be different.
>Do you have a ".xcircuitrc" file or have done something to the
>default startup that would have redefined the grid and snap spacing?
>You should get Grid=1/6in, Snap=1/12in on startup.  The diode from
>the 2nd library should be exactly three grid-spacings long.  Turned
>to 45 degrees, it fits diagonally inside a 2x2 grid-spacing box,
>with the actually difference being within xcircuit's tolerance for
>wire endpoint offsets.
>
>There was, however, a broken version of the PCB netlister posted
>for a while which was only fixed in version 2.5.4, one of the first
>revisions.
>
>If you're definitely seeing something different than what I'm
>describing, then let me know.
>
>					Regards,
>					Tim
>

[Xcircuit-dev] Re: xcircuit simulator

[R. T. E. <ti...@st...>]

> Date: Sun, 12 May 2002 08:51:21 -0400 (EDT)
> From: Nin...@ao...
> Subject: [Xcircuit-dev] simulator
> Sender: xci...@li...
> To: xci...@li...
> 
> Hey do you guys have a simulator that interfaces with xcircuit.......Thanks

XCircuit does not [yet; I'm working on it] interface directly to a simulator.
However, the SPICE output it produces is more-or-less compatible with all
SPICE versions (you may need to hand-edit for specific versions;  I'm     
working on that problem, too).  The ".sim" output it produces is compatible
with "irsim" (Berkeley VLSI tools).

   Interactive simulation *is coming*, although my original target date of
June now seems overly optimistic.

                                                Regards,
                                                Tim

[Xcircuit-dev] Re: xcircuit colormap errors

[R. T. E. <ti...@st...>]

Dear Eric,

> The second thing that worked is to just revert the Cvt routine.

Now I'll have to find a way to resolve the differences between the
old and the new versions of Cvt...

> Obviously, the line was taken out for a reason, but I cannot figure out
> why.  If there is a non-zero return code, .pixel should still be set, or
> else who knows what its value will be.

There is at least one system out there where LookupColor returns a
completely bogus value in .pixel.  It looks to me like a server error.
Now I'm stuck with the problem that getting around the sever error
breaks the code on systems with properly-working X servers.  I may
be reduced to adding it as an ugly compile-time switch.

Thanks for checking out the bug fix suggestions and reporting back.

					Regards,
					Tim

[Xcircuit-dev] simulator

[<Nin...@ao...>]

Hey do you guys have a simulator that interfaces with xcircuit.......Thanks

[Xcircuit-dev] investigate Cvt

[Eric Y. C. <er...@al...>]

Hi Tim.  I tried a couple of things, both of which were successful.  The first
was to close Netscape.  The menus looked fine then.  So, this is caused
by running out of colors, since Netscape takes up so many.  Actually, it must
take up some pretty crucial ones, since the page it was open to is the
tutorial, with all the screenshots!  So, one workaround is to close Netscape
every time XCircuit is running, but this is a hassle, since I have to open
it every now and then as I read the tutorial.

The second thing that worked is to just revert the Cvt routine.  That works
just fine, and the old colors come back.  This works even if Netscape is
showing the tutorial.  The reason why it works is that there is one major
difference in the 2.5.4 code.  If a non-zero code is returned from the
color lookup, the 2.3.3 code will call findanothercolor (or something
like that).  This will build a private color table, and every subsequent
call to Cvt will succeed rather than leaving the pixel member un-initialized.
Obviously, the line was taken out for a reason, but I cannot figure out
why.  If there is a non-zero return code, .pixel should still be set, or
else who knows what its value will be.  This might even give a memory
error.

I will also try moving XtAppAddConverter up, but I don't see how this
will help, especially since I am not sure how this routine works.  I am
not very fluent in Xt.

Eric

Re: [Xcircuit-dev] XCircuit and strange colormaps

[Eric Y. C. <er...@al...>]

Hi Tim.  Wow!  This is really great advice.  Thanks for the quick reply.
I will try it out tonight.  Running out of colors seems like a reasonable
explanation.

Eric

[Xcircuit-dev] XCircuit and strange colormaps

[R. T. E. <ti...@st...>]

Dear Eric,

   This seems to have been precipitated by a change that was supposed
to *fix* things in 8-bit mode, not break them.  Compare routine
CvtStringToPixel between version 2.5.4 and earlier versions; you
might get better results by changing it back to the original.

   You also might have encountered "bug #5" (see the Manifest file,
down toward the bottom), in which if your 8-bit colormap is close to
being out of spare colors, and the allocation runs out in the middle
of xcircuit's allocating all its colors, then the colormap may never
be installed and colors will certainly be screwed up.  I could never
produce this problem on my machine, so I have always considered it
too rare to be a worry.  But now, you make me wonder.

   And, it could be a conflict between two systems implementing
the same X routine differently;  the problem I was trying to correct
with the change to CvtStringToPixel in version 2.5.4 seemed awfully
suspicious, in that XLookupColor was returning "success" but had a
trash value in cvexact.pixel.  If that's the case, reverting
CvtStringToPixel to the original form might work for you.

   Finally, there's one more thing I thought of:  it may be that
xcircuit.c, line 2268

   XtAppAddConverter(app, XtRString, XtRPixel,
		(XtConverter)CvtStringToPixel, NULL, 0);

should really be at line 2242; that is, it should be called before
XtOpenApplication() so that the same routine is applied to the fallback
resources as is applied to the application resources.  I suggest
trying this solution first (before making any changes to CvtStringToPixel).
At any rate, let me know what happens.

						Regards,
						Tim

[Xcircuit-dev] XCircuit debugging

[Eric Y. C. <er...@al...>]

Hi.  I am trying to debug a broken connectivity problem in XCircuit.
This problem relates to generating pcb netlists.  After running
through the tutorial on the bridge rectifier, a correct netlist
is output with respect to nodes, but there is no connectivity.
In other words, the diode bridge is floating with respect to the
input.

Anyway, I figured that I needed to first upgrade to the latest
(unstable) version, 2.5.4.  Unfortunately, this does not come
up with usable menus.  The menus are all green, with no text in
them.  I replaced the .Xdefaults with the new .ad file, and
neither one worked.  All green.

Since green was the problem, I decided to remove all references
to green in the .Xdefaults file for xcircuit.  The odd thing is
that this had very little effect.  When I changed one of the 
lines, the menu fill changed to gray (even if I changed the
entry to blue).  When I removed all lines, except for the
*foreground and *background lines, the problem still occured,
indicating that the "green" issue was hardcoded in the program.

I then removed all instances of green (Green3) etc from all c
and header files, and the problem persisted.  Also, I compared
the source code in these sections with the working version 2.3.3.
There appeared to be no major changes.

That means that the green is coming from someplace else.  There
are no hardcoded references anymore to green in the code, header
files or .Xdefaults, but the menus are still coming up green
filled.  The instances of green in the stable build are in the
same places, and the stable build works.  So, it is very likely
that the green is coming from an entirely unrelated portion of
the program generating a side effect.

There is a very suspicious section in which a custom color table
is loaded, but this is the same as in the stable build, which
works.  This code is apparently triggered when it is found that
the current colors do not match within some kind of measure
which is 512 in the code.  Changing this number to 1024 has no
effect, and neither does commenting out the custom color table
routine.  Obviously, what is going on is that the green is
loaded into the color table by this custom generation routine,
and there is some essentially unrelated change that is either
corrupting the color table or assigning two important indices
to either close or identical values of green.

It may be difficult to duplicate this problem elsewhere since
the X server on my system is limited to 256 colors.  Since 
there is a working build, it may be possible to work on back
by means of binary subdivision, but this will require a lot
of patching back.  Is there a better way to fix the problem
by going right to it?  Does any of this ring a bell?

Thanks,
Eric

Re: [Xcircuit-dev] Backspace problem

[ken r. <ke...@24...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks! That did it. 

I was using the RPM that was posted on the xcircuit site, which was 2.5.3 with the XCF_Text_Left, and.... my delete key was physically broken on my keyboard-- no scancodes being sent out for several keys that I never use, delete included. Duh.

I was also still using the older parameterized library. Double-duh. The new analoglib2 works great.

Thanks, I am relieved to find out that both were pilot-error problems.

Cheers!

- -ken
- -------
On Mon, Apr 29, 2002 at 12:50:59PM -0400, R. Timothy Edwards wrote:
> Dear Ken,
>    You might want to play around with the default bindings defined in
> "keybindings.c"---lines 527 and 529 are
> 
>    add_binding(XK_Delete, XCF_Text_Delete);
> and
>    add_binding(XK_BackSpace, XCF_Text_Delete); /* Changed from XCF_Text_Left */
> 
> respectively, in version 2.5.4.  The comment at the end of the second
> one was the way it was in version 2.5.3.  It is possible that this,
> combined with some "xmodmap" settings in your home directory or system
> login defaults, are remapping the "delete" key to match "backspace", and
> in so doing, lose the "text delete" function because the XK_Delete
> keysym no longer maps to any keyboard key.  Remapping the backspace
> key caused so many complaints that I repented after only a few minor
> versions with the change.  "XCF_Text_Left" is mapped to the left-arrow
> key, anyway.
> 
> -------------------
> 
> As for the PCB output:  The first library page symbols were designed for
> use in VLSI layouts, not PCB layouts.  So the "c.1" and "c.2" names of
> the pins is not appropriate for PCB use.  Either use the capacitor symbols
> with values on the "analoglib2" library page, or else edit the "capacitor"
> library part and change "c.1" to "1" and "c.2" to "2", making them valid
> pin numbers for PCB use.  Technically, this is PCB's problem, as it should
> accept non-numerical pin names.  It may be the "." that it dislikes,
> though;  I haven't checked to find out.  Pin numbers don't make much
> sense for discrete components, unless they're in a can or SIP or some
> other package for which pin numbering is meaningful.  Either way, the
> advice above will solve your problem without writing ugly "sed" scripts.
> 
> 						Regards,
> 						Tim
> 
> _______________________________________________
> Xcircuit-dev mailing list
> Xci...@li...
> https://lists.sourceforge.net/lists/listinfo/xcircuit-dev

- -- 
- ---------------
Freedom of the press belongs to those who can afford to pay the hosting bill.
Now, that means you! $1/1GB, no monthly fees. http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8z1+Fe8HF+6xeOIcRAiSuAJsE6GqfegVL/3ScXo2vaWGBvL+IwQCeNtR8
YbpJjmTLYjHSMENeePJ2J0M=
=RPEB
-----END PGP SIGNATURE-----

[Xcircuit-dev] Backspace problem

[R. T. E. <ti...@st...>]

Dear Ken,
   You might want to play around with the default bindings defined in
"keybindings.c"---lines 527 and 529 are

   add_binding(XK_Delete, XCF_Text_Delete);
and
   add_binding(XK_BackSpace, XCF_Text_Delete); /* Changed from XCF_Text_Left */

respectively, in version 2.5.4.  The comment at the end of the second
one was the way it was in version 2.5.3.  It is possible that this,
combined with some "xmodmap" settings in your home directory or system
login defaults, are remapping the "delete" key to match "backspace", and
in so doing, lose the "text delete" function because the XK_Delete
keysym no longer maps to any keyboard key.  Remapping the backspace
key caused so many complaints that I repented after only a few minor
versions with the change.  "XCF_Text_Left" is mapped to the left-arrow
key, anyway.

-------------------

As for the PCB output:  The first library page symbols were designed for
use in VLSI layouts, not PCB layouts.  So the "c.1" and "c.2" names of
the pins is not appropriate for PCB use.  Either use the capacitor symbols
with values on the "analoglib2" library page, or else edit the "capacitor"
library part and change "c.1" to "1" and "c.2" to "2", making them valid
pin numbers for PCB use.  Technically, this is PCB's problem, as it should
accept non-numerical pin names.  It may be the "." that it dislikes,
though;  I haven't checked to find out.  Pin numbers don't make much
sense for discrete components, unless they're in a can or SIP or some
other package for which pin numbering is meaningful.  Either way, the
advice above will solve your problem without writing ugly "sed" scripts.

						Regards,
						Tim

[Xcircuit-dev] Delete/Backspace and PCB output

[ken r. <ke...@24...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just started entering schematics into xcircuit/pcb and am very impressed so far!

I have xcircuit 2.5.3 on a Linux 2.4.7-10 (RedHat 7.2 stock) system, and have discovered that backspacing over text doesn't actually backspace over it. Kind of annoying. I don't have any funky ^h/^? mappings, either, so I'm not sure what the problem is.

In any case, the delete key didn't work either, nor did any number of control-char combinations. It seems like, once a character has been entered into a label, they can never be erased, ever, other than by deleting the label and starting over again.

I tried back-revving to version 2.2 of xcircuit, which fixed the problem, but of course I can't use 2.2 because I could not get PCB to accept what it put out.

I also looked around in the docs for pertinent xresources/xdefaults items, and the python-nased keymappings, and didn't see any way.  I could of course be overlooking something obvious.

My search of the mail archives didn't come up with anything either.

Any help would be appreciated, and my apologies if this is just xwindows pilot error on my part.

BTW, I also had a strange PCB output problem with the analoglib2 library. The spice output is perfectly good ("C1 input2 GND 100n") but the pcb output is getting rejected by pcb. It doesn't like the "c.2" in the "GND  C3-c.2   C1-c.2   D1-2 " type of lines. I can sed my way around it, but if I'm doing something wrong I'd rather fix that instead.

Again, thansks for all your effort on this, it's a very powerful package.

- -ken
- -- 
- ---------------
Freedom of the press belongs to those who can afford to pay the hosting bill.
Now, that means you! $1/1GB, no monthly fees. http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8zXNie8HF+6xeOIcRAn3dAJ9HCWNzjyMhusJtODJEp+xZbayOEgCfbX8E
8zHikWALm3u6HG/hap3jhHQ=
=mLUl
-----END PGP SIGNATURE-----

[Xcircuit-dev] Video blanking

[R. T. E. <ti...@st...>]

Dear Dave,

   Obviously I'm not looking often enough through the xcircuit mailing
list.  Anyway, this is an essentially unsolvable problem:  The X server
is at fault, and confuses the timer between the screensaver and xcircuit,
in spite of the fact that xcircuit provides its unique application ID
when it registers the timeout event (well, the problem is either in the
X server or in the screensaver).  An unsatisfactory solution, but one
which works, is to turn off your screensaver.  If necessary, you could
start xcircuit from a script which would revive the screensaver after
you exit.  As I said, it's not very satisfactory.
   I think I will try to abandon the X timeout function altogether and
use a low-level interrupt timer instead.  That might get rid of the
problem.  I'll give that a try, but I'll need somebody who experiences
the problem to test it, since I can't duplicate this particular bug.

						Regards,
						Tim

[Xcircuit-dev] Any hope for bug 544657?

[David A. <ac...@cs...>]

I'm getting bitten bad by the `button-down video signal loss', just as
described in

http://sourceforge.net/tracker/index.php?func=detail&aid=544657&group_id=4952&atid=104952  

Is there any hope for progress on this one over the near term --- say
maybe a month or so?  Does anybody who's up the developer curve have
the hardware to duplicate the problem?

I'm going to have to commit to something fairly soon for drawing
several chapters worth of schematics and figures... and I sure would
like to benefit from xcircuit's libraries and beautiful output if I
could.

Thanks for any information.

       -Dave

Re: [Xcircuit-dev] xcircuit Q&A

[Bryce D. <br...@tl...>]

Thanks for the netlisting ideas.  I'll try them.

On Wed, 24 Apr 2002, R. Timothy Edwards wrote:
> > I'm using xcircuit 2.5.2.  Later versions are crashing on startup with an
> > XQueryColors error.  I filed that one too. :)
> 
> Yuck.  I may need to see the actual error result, but try this:  xcircuit.c,
> routine "findnearcolor" (around line 1807), add as the first executable code
> after the type declarations:
> 
>    if (ncolors > 256) {
>       XQueryColor(dpy, cmap, cvexact);
>       return cvexact->pixel;
>    }
> 
> The rest of the stuff in that routine was supposed to be dealing with
> indexed color;  it is not relevant to 24- or 32- bit TrueColor visuals,
> and I suspect that's the problem.  But it could be something else.

I have 8 bit color, so that didn't help.  In fact findnearcolor() is never
called at all before it crashes.

I did a lot of gdb tracing and the complete results are at
http://sourceforge.net/tracker/index.php?func=detail&aid=548152&group_id=4952&atid=104952

The problem in 2.5.3 is because BBOXCOLOR was not initialized, but it
looks like you already fixed that in 2.5.4.

In 2.5.4, xc_alloccolor("Gray90") is returning a trash value of 135109808.
It calls CvtStringToPixel(NULL, &zval, &fromC, &toC) with
 fromC={size = 6, addr = 0x80c72aa "Gray90"}

That calls XAllocNamedColor(dpy, cmap, (char *)fromVal->addr,
                      &cvcolor, &cvexact)
which returns zero and goes to 
XLookupColor(dpy, cmap, (char *)fromVal->addr, &cvexact, &cvcolor)
which does not return zero, so it does
  cvcolor.pixel = cvexact.pixel;
but cvexact.pixel is 135109808.  There's the trash value.

If I change the "cvcolor.pixel = cvexact.pixel" line back to what it was
in previous versions:
  cvcolor.pixel = findnearcolor(&cvexact);
then 2.5.4 starts up fine with no X errors.

That should help to narrow it down.  See the SF bug report for more
details.

Regards,
Bryce

[Xcircuit-dev] xcircuit Q&A

[R. T. E. <ti...@st...>]

Dear Bryce,

> 1. I can't find any way to specify power and ground connections in a
> multigate chip.  Maybe one of the instances should have power and ground
> ports, and the others should not?

Put numbered pins for Vdd and GND on the library symbol (such as on top and
bottom).  On any one of the parts in the schematic, attach Vdd and GND
(or attach labels with the global names Vdd and GND) to any one of the
devices.  You will, however, need to post-process the result to get
rid of the redundant entries for those pins, as xcircuit only recognizes
the problem well enough to report "duplicate entries U1 and U1" or something
to that effect.  I will work on this problem.

> 2. The pcb netlist output looks like U1-3-10, meaning part number U1, gate
> number 3, pin 10.  This cannot be parsed in the pcb software, unless I
> change it to just U1-10.  I know how to do this with a perl script to fix
> up the netlist, but is there a better way?

The "info label" for the device has "pcb:U?-1" (or -2, -3, etc.).  Edit
it as follows:  Select the last number in the string (with a middle-mouse-
button select box) and then select menu option "Text->Unparameterize".
Then edit the string and delete the "-1" off the end.  You will no longer
get the sub-component number in the PCB output.

> I'm using xcircuit 2.5.2.  Later versions are crashing on startup with an
> XQueryColors error.  I filed that one too. :)

Yuck.  I may need to see the actual error result, but try this:  xcircuit.c,
routine "findnearcolor" (around line 1807), add as the first executable code
after the type declarations:

   if (ncolors > 256) {
      XQueryColor(dpy, cmap, cvexact);
      return cvexact->pixel;
   }

The rest of the stuff in that routine was supposed to be dealing with
indexed color;  it is not relevant to 24- or 32- bit TrueColor visuals,
and I suspect that's the problem.  But it could be something else.

						Regards,
						Tim

[Xcircuit-dev] Multiple-gate chips in PCB netlists

[Bryce D. <br...@tl...>]

I was hoping to draw a schematic with a quad op-amp, based on the quad
NAND example in the quadparts library.  However I cannot get the quad NAND
to produce a usable pcb netlist.  I have filed a few bugs on Source Forge
describing the problems I'm seeing.  Basically:

1. I can't find any way to specify power and ground connections in a
multigate chip.  Maybe one of the instances should have power and ground
ports, and the others should not?

2. The pcb netlist output looks like U1-3-10, meaning part number U1, gate
number 3, pin 10.  This cannot be parsed in the pcb software, unless I
change it to just U1-10.  I know how to do this with a perl script to fix
up the netlist, but is there a better way?

I'm using xcircuit 2.5.2.  Later versions are crashing on startup with an
XQueryColors error.  I filed that one too. :)

Thanks,
Bryce

[Xcircuit-dev] xcircuit disappearing labels

[R. T. E. <ti...@st...>]

Dear Jeremy,

   Thanks for the detailed---and repeatable---bug report.  I discovered
the problem at netlist.c, line 3106, where the comment

	/* (All elements after the 1st temp label are temp labels) */

was rendered false by the method of retaining netlists.  If you make
a netlist, temporary labels which are not visible on the schematic
get created.  If you subsequently add more parts, they get wiped out
the next time the netlist is invalidated.  To correct the problem,
the section following the comment needs to be a little more
sophisticated.  Change (netlist.c, line 3105 in source version 2.5.4):

         /* Free any temporary labels which have been created    */
         /* (All elements after the 1st temp label are temp labels) */
     
         else if ((*cgen)->type == LABEL) {
            labelptr clab = TOLABEL(cgen);
            int tmpval = (int)(cgen - cschem->plist);
            if (clab->string->type != FONT_NAME) {
               while (cgen < cschem->plist + cschem->parts) {
                  clab = TOLABEL(cgen);
                  freelabel(clab->string);
                  free(clab);
                  cgen++;
               }
               cschem->parts = tmpval;
               break;
            }
         }

to:

         /* Free any temporary labels which have been created    */
     
         else if ((*cgen)->type == LABEL) {
            labelptr clab = TOLABEL(cgen);
            int tmpval = (int)(cgen - cschem->plist);
            if (clab->string->type != FONT_NAME) {
               genericptr *tgen;

               clab = TOLABEL(cgen);
               freelabel(clab->string);
               free(clab); 
               for (tgen = cgen + 1; tgen < cschem->plist + cschem->parts; tgen++)
                  *(tgen - 1) = *tgen;
               cschem->parts--;
               cgen--;
            }
         }

I have tested this and it gets rid of the problem.  I have changed it in the
distribution, which is now version 2.5.4 rev. 1.

						Regards,
						Tim

[Xcircuit-dev] The end of Open Source in the US?

[Bob P. <bpa...@cs...>]

http://wired.com/news/politics/0,1283,51274,00.html

Anti-Copy Bill Slams Coders
By Declan McCullagh

WASHINGTON -- America's programmers, engineers and sundry bit-heads have not 
yet figured out how much a new copyright bill will affect their livelihood. 
? ? ? ? ?
When they do, watch for an angry Million Geek March to storm Capitol Hill.

A bill introduced this week by Sen. Fritz Hollings (D-South Carolina) would 
roil the electronics industry by forcibly embedding copy protection into all 
digital devices, from MP3 players to cell phones, fax machines, digital 
cameras and personal computers.

[The way that the clueless politicians have written the law, even your simple 
digital wrist watch needs to have this copy protection code...]

{The Digital Millennium Copy Protection Act as already been keeping people 
from disclosing bugs found in things like the Linux kernel. ?:-( }

[Xcircuit-dev] xcircuit 2.5.3 bug report

[<jh...@ai...>]

I figured out a means of reproducing the bug I reported in xcircuit a
week or two back.

1) start xcircuit.
2) 'l' for library.  
3) drag a nand to the center of page 1.
4) create three input wires connecting to the inputs of the NAND gate.
   length doesn't appear to matter.
5) 'T' to add a pin, name it "A", to the left end of the topmost wire
6) 'T' to add a pin "B" to the middle wire
7) select "netlist"->"write spice"
8) middle-button over "B" to select it; reject any wires that might also
   get selected, only select "B".
9) 'c' to copy pin B;  place the copy in the middle of the bottommost wire
   with the middle button
10) select "netlist"->"write spice" --- and the copied "B" vanishes!
    This is the first manifestation of the bug.

for more fun:

11) Copy the nand gate all over the place.  Make some new wires.
12) select "netlist"->"write spice" -- all of the new wires and nand
    gates vanish!

Jeremy

[Xcircuit-dev] xcircuit 2.5.3: 2 bugs, 1 suggestion

[<jh...@ai...>]

First, let me start by saying that xcircuit rocks -- thank you very,
very much!!!  These are just some minor things, mostly.

Platform: debian linux, 2.2.19pre21 kernel

Bug: Sometimes, if you create a pin, and then copy it, and then write
a netlist, the copy and everything you've done afterward just
disappear.  On the other hand, if you create a pin, copy it, save the
file, and restart xcircuit, and then generate a netlist from the file,
everything works fine.  Unfortunately, I have not been able to figure
out how to reliably reproduce the bug yet.

Minor bug: 'G' is documented as creating a global pin, but when
pressed, xcircuit claims it isn't bound to macro.

Suggestion: it's not obvious that one should use the mouse to
click/drag the help screen in the help browser.  Perhaps a sentence at
the very start of the help content?

Jeremy

[Xcircuit-dev] editing of parameters

[Bob B. <rob...@ag...>]

Hi,

I can't seem to delete characters in a parameter string
using the 'e' option.  It adds, but no delete.  Is this
a problem with key bindings or do I have to delete the
whole thing and re-enter a new string?

If you know how would you send me some hints as to how
to get this to work.  I tried looking at the tutorials,
and they just show me how to add text.

I'm using the 2.5.2 version of Xcircuit on a LINUX system.
(Slackware LINUX, and I compiled the source.)  If parameters
are not easy to change, SPICE netlists will have the wrong
values in them.  As an example, I tried to change the 1.0 K ohm
resistor to 1.0 ohms.  I couldn't delete the "k".

Robert Batey     Agilent/Boise

[Xcircuit-dev] xcircuit for pdb layout

[R. T. E. <ti...@st...>]

Dear Dave,

> The website mentions that xcircuit can be used for PCB layout. How do I
> switch from schematic to pcb?

Perhaps that's a bit misleading.  As some people like to PCBs for home-made
circuits, sometimes all they want is a PostScript printout on the laser
printer which can be etched into a copper-plated board.  Xcircuit's
PostScript output makes it useful for that.  For anything more complicated
than that, use the open-source tool "pcb", not xcircuit, for the layout.
I hope that clarifies the statement in the website.

						Regards,
						Tim

[Xcircuit-dev] xcircuit pcb

[Dave L. <dla...@ad...>]

The website mentions that xcircuit can be used for PCB layout. How do I 
switch from schematic to pcb?

[Xcircuit-dev] Re: PDF schematic

[Bob P. <bpa...@cs...>]

3/6/2002 12:10:05 PM, "R. Timothy Edwards" <ti...@st...> wrote:

The problem is that I don't have the original native output.  All I've got is the
manufactures data sheets from their web sites.

I've been able to use ps to text to get the text, but it makes a mess of math equations.

>Sorry that there's not much of a good solution here.

I kind of expected that for this case.

[Xcircuit-dev] Libraries needed

[Bob P. <bpa...@cs...>]

Any one have a good looking "Danger High Voltage" sign/symbol?

How about Feynman Diagrams?

Any thing at all to share? :-)