I'm using Orcad PCB (Tiny-Allegro ;-) version 16.2 s28.
I've drawn some custom shapes for pads/soldermask (Halfcircle2mm.ssm and Halfcircel2mm-sm).When I load them in Padstack Designer (as "Shape" with "Geometry" dropbox="Shape") the preview of the pad is just a vertical line, the soldermask looks like the drawn (but hollow). This seems a bit strange - but preview functions has never been a Cadence selling point. The the "Top" view of "Views" in Padstack designer is just a square - but I think thats a feature that has never worked with custom shapes anyways (?).Using the padstack (Halfcircel2mm.pad) in a footprint looks as expected. But when placed on a board it seems the soldermask is used for the actual pad. In any case the outline is to big (and pin center is not where it should be).Thus the pads are shorted (and I get the expected "SMD Pin to SMD Pin Spacing" DRC).I'm at the point where I think I've tried everything at least twice - but I'm hopefully just missing something obvious?Any input greatly appreciated!
Best regards, Anders Frederiksen (Denmark)
PS: Relevant design files and a screen shot of the footprint in the editor and placed can be found here http://hi5.dk/Temp/CustomPad-failing.zip
Seems to be working here with your files.
I did not see a package symbol so I made one using your two half-circles. I have attached an image.
I did not do anything to your symbols in the zip to make this work...
In reply to redwire:
In reply to N i z e:
Ok, I see the problem now that you are seeing. It looks like something is cached wrong.
I have not solved it yet but I would suggest redoing the part with new names for each piece. You should *not* be seeing what you are seeing. Unfortunately I am out for a few days and can't help solve this until later this week. Hopefully someone else can help fix it.
I think this is related to the origin points of your ssm files. You need to make sure that 0,0 is located in the correct place. When you load the ssm file into Pad Designer (and then PCB Editor) it uses this 0,0 location. I did move your origin points to get a better overview. I did also use v16.5 (not sure of there is a different behaviour in the latest release).
In reply to steve:
Steve, thanks for the answer! No doubt the offset pad/SM are from the moved origin. But it's not the cause of the copper pad being changed when the symbol is placed. I'm fairly confident of this because the origins were originally in the center of the original full circles. Before I discovered the pad problem I moved the pad center - because the way the symbol is made both pins would have identical origins (and thus shorting out when routed).
Redwire: As I read it you do see the same error when placed with 16.5?
This is a bit intersting as it means it's definitely my symbol that's
messed up and not just a general 16.2 error with placement. I'll try to redo the symbol
with different names etc. - although I'd rather recognize the problem
than using brute force until I "get lucky". ;-)
If I manage to get through this one, I'll make a post with any findings immediately...
Thanks a lot for your efforts so far!
Sorry to be jumping in late, but I'm having difficulty understanding your issue exactly. I just grabbed your original (?) zip file and it appears to me you are seeing exactly what you should given the data files there.
Also, I assume that you ultimately want a package symbol with two separate semi-circle pads with separate isolated electrical connections?
The first problem I see is the origins of your two shape symbols currently do not match up. The origins will be used as the alignment point by pad designer in overlaying the two shapes as well as becoming the origin and placement and connect point of the resulting padstack when imported into a package symbol as a "pin". The origin of the two custom shapes should therefore be in the centers of the two shapes, not at the edge (center of the original circle) as is currently shown in your "halfcircle2mm-sm" shape symbol.
The second problem I see is your "Halfcircle2mm.pad" padstack file currently specifies the soldermask shape for use on both the "BEGIN_LAYER" and "SOLDERMASK_TOP" layers of the padstack. This is why your copper pad is the same size as the soldermask when placed in your package symbol.
If you fix the origins of your two shape symbols to center of the shapes such that they overlay correctly like you want them, then specify their respective usage correctly in you padstack definition, you should be able to use the same padstack to place two separate "pins" in your package symbol (with one rotated 180) and spaced approximately 1mm apart (center-to-center) to get the desired results.
In the heirachical flow of things, the custom shape symbols will flow into the padstack definition. The padstack will then get used or placed into the package symbol with whatever is defined in the "SOLDERMASK_TOP" layer of the padstack being mapped into the "PACKAGE_GEOMETRY, SOLDERMASK_TOP" subclass of the package symbol. Then when you use that symbol on a board and generate gerbers, the package_geometry soldermask items are collected from all your package symbols along with any custom "BOARD_GEOMETRY, SOLDERMASK_TOP" items to become your overall soldermask artwork. At least normally, depending on how your artwork is defined.
Please excuse me if I have totally mis-understood the problem.
In reply to Roger BFS:
No need for apologies - I very much appreciate any feedback I can get!
I think you understand the goal fully. And you might have found a problem in the padstack definition. The solder mask should of course use halfcircle2mm-sm. I might have uploaded a wrong file of the many malfunctional attempts - butI'm a bit puzzled if it's that simple. I'm confident I've had multiple attempt where the soldermask and pads looked fine in the editor - but when the symbol is placed the pad suddenly changes to be the same as the pad (see the Package-in-editor(dra).png and Placed-symbol.png from the zip). But if there's a problem in the padstack I might be even to trial and error a working symbol (with a "real" SM, not the hacked on in my current) in a couple of hours...
Initially I had the origin in the center of the virtual circle - but I
moved it 1mm in as the routing would cause errors if not routed straight
away from the flat side. Now it just exist "funny" when not routed
However the problem still remains: No matter how perfect the symbol (.dra) looks when edited it's totally messed up when placed on a board. Just take a look at the screenshot in my last post (test-package-in-editor.png): This is how the symbol 'must look' in the editor to "be right" on a board. It's probably something to do with the pad origins being differently interpreted in when the editor is in library mode and board mode. This makes it very annoying to debug.
I definitely want to avoid any components with non standard pads if this is the tool standard.... ;-)
I'm slowly beginning to understand your issue. I agree that its looking like a different interpretation by the editor between symbol and board modes. Or perhaps its a caching issue among your various "malfuntion" trial attempts. You are aware that the tools do not automatically update from one to the other?
When you change a shape symbol (move origins and such) it does not automatically get used by the padstack unless you re-save the padstack file with the correct shape symbol names. Similarly when you update the padstack it does not get used in the package symbol unless you do a pad-refresh and re-save the package file. then if you have that symbol already placed on a "brd", you have to refresh that to get the latest info to flow down the chain of tools.
Couple of other thoughts that might be causing issues. Check your "grid" settings between the editor modes. If your symbol editor is set for a different placement grid than your board editor it could be causing a placement interpretation glitch. I really suspect that the different origin points between the pad and soldermask shapes could also be confusing things. Again its important that the origin of your shape symbols precisely agree with how you want the shapes overlayed in the padstack definition as well as where you want the connect point to be for routing in the board.
Also, are you using Windows 7 perhaps. The V16.2 tools are NOT compatible with Win 7 and many weird artifacts have been known to surface if that is the case.
The Cadence tools are very capable, flexible, and complicated. The downside is the continuous debug when weird things like this happen. I just created a couple of custom pad shapes today (offset L shaped) with soldermasks and got it all to work fine for me. Although, I'm using V16.5 upper tier licenses.
Thanks for the good luck wishes - I'm afraid I need it!
Did you actually try to open/place my symbol from the initial zip file? I'm quite curious if I'm only battling my Allegro incompetence or I'm also dealing with an actual 16.2 error....
error sources, I acknowledge that the caching might sometime play
tricks on me. But as things generally does not change until
updated/replaced, I think it's not the real issue. With the insane
amount of time I've wasted on this, I'd also count on flukes saving me
at some point if caching was the sole problem.
Likewise, I do
actually run the 16.2 under Win7-64. But I'd expect crashes or something
obvious - like the missing check boxes in the placement dialogue. (The
latter nearly broke me - thanks to NordCad.dk for helping me out there!). But I should probably get a XP running again for testing if the issues remain. Might be worth a few hours...
I fail to understand how the grids can mess things up? Should I avoid changing them? Or start parts with a certain grid setting?
do realise that the (seemingly) only sane thing to do would be to
upgrade to the newest version and buy some support - or just pay someone
to do the darn libraries and possibly other stuff that cause problems.
But I've just gone "all in" on a huge development project. Absolutely no
income and lots of expenses (currently "sponsored" by my savings
account along with my rent ;-). So when it comes down to upgrading tools
etc. or actually being able to finance the hardware for the
prototype... well working long hours seems like the only right thing to
do. (I just need to remember to slam my fist (head?! ;-) into the table
and not the screen/PC when frustration inevitably kicks in). After all
I've got no use for the tools if I don't survive to do another design.
If I know Cadence right, I can't even sell my new license to another
PS: On a final note I do acknowledge that the Allegro is a
But for us poor souls starting out without an expert in the next office
- it's simply frustrating. Definitely the efforts has not been focused
on usability (at least not successfully). Undoubtedly everyday Allegro users get used to the quirks -
but the learning curve is devastatingly steep. I might be missing quite
a few things - but I often end up wondering if it's "just me". For
instance I still find my self calculating and keying in
coordinates every time I need something done to measurements. Feels
insane - but I have not yet found a better way! (More like a
early-eighties AutoCad version than what I'd expect of an UI today. I guess AutoCad at least improved after SolidWorks etc. started stealing their engineering customers big time. ;-)
It's also frustrating that previews are either non-existing or
non-working. No decent libraries (well, almost) to start out with - and
no "best practise" guides available. The library work is just plain
frustrating. You either have to accept that you need to clean up symbols
(line widths, text sizes etc) in every design or spend a lot of time
grooming the libraries (and remember to write down your own "best
practises"). I'm sure a seasoned Allegro user will be able to write
skill (?) macro stuff to help out with both libraries and in-design
cleanup. But I'm not venturing there yet - plenty of problems already.
For now I've actually given up on getting any inter-tool communication going (Orcad PCB to Orcad Capture - how hard can it be?! ;-) - but at least I've seen some working with 16.0 under XP
(not easy though!). Need to revisit that problem at some point - it'll
save a lot of time if it works. Other current things I gave up on
include finding the setting that avoid dynamic copper island to keep
appearing, not being able to show drill holes in the editor, removing
parts of pads (thought anti-etch would do the trick, but no) etc. Guess I
should keep a list and write a beginners guide when there's nothing
else to do... ;-)
Btw. I'd recommend any other desperate newbie out there to start on YouTube (!) or these foras (but search them with google) - because imho the documentation and online help is mostly just a waste of time.:-O
Congratulations! You have managed to create a symbol that confuses the hell out of all versions of Allegro :-) But after several hours of poking around and debugging, I think I have some answers for you (at least ones that work on my v16.5 win7-64 system).
The main issue that was causing the symbol to show up differently when placed on a board than what it looked like in the symbol editor was a caching "feature". I don't know what sequence of trial-error steps you used to get the symbol that was in your original zip, but it apparently had the erroneos padstack (with the soldermask shape defined for both pad and soldermask layers) stuck in its memory. Although you had updated the symbol somehow to look ok in the editor, it still had old padstack and shape symbols in its database.
I uncovered this annoying update/refresh problem as I started tring to correct the problems on my system. Essentially, when you place a component on a board for the first time (at least without a netlist driven placement) it grabs the package symbol data and padstack definitions along with any embedded shape symbol definitions and stores them in the board database. The same thing basically happens if you are editing a package symbol as well - the padstacks and embedded shapes get imported and saved in the package symbol file.
The confusion comes when you edit a package symbol to change padstacks definitions and do a Padstack-Refresh, it updates the padstack data and display, but it DOES NOT update the embedded shape symbol data that was grabbed during the initial placement. So when you grab this "updated" package symbol and place it on a board, you get the new padstack definitions but the previously stored shapes. If it should be a later attempt to update the board file again refreshing the package symbol with a newer version DOES NOT refresh the shape symbols.
I discovered this after deleting all symbols off my test board file, saving it, closing it to edit something else then re-opening the board and looking at the refresh symbols menu and noticing that it still showed the two shape symbols in its memory even with no components on the board!
Then of course the other issue that we've noted before was the placement of the origins in creating your pad shape symbols. Apparently having the origin on the "edge" of the shape causes confusion for the tools (and warning in the padstack editor) besides not doing what you want it to achieve. You also need to be careful about having the design resolution (no of decimal places) set consistently along with grid definitions between the brd and dra editing sessions. Goofy stuff does happen when "rounding" off as the tools import data from one symbol to the next.
Anyway, I went back to the beginning and fixed all the glitches (at least on my system) and the placed part looks good on the board now. I would send them to you but they are "up-reved" to 16.5 so you couldn't use them directly. Anyway here are the "fixit steps" you need to implement to hopefully get the desired results:
1) Fix your flash symbols to put the origin 0.5mm in from the straight edge for both the pad and mask versions (that's where I put it).
2) Fix your library padstack to call out the correct shapes for the BEGIN and SOLDERMASK_TOP layers. You don't need to specify a "flash" as this might confuse things elsewhere. After fixing the padstack def as needed, don't forget to re-save the file.
3) Now go edit your package symbol two ways. Do the Tools>Padstack>Refresh (or Replace) to get the new one imported. Would also be a good idea to do a Tools>Padstack>Modify Design Padstacks then a Purge>All to get rid of any unused padstack definitions hanging around in the symbol database.
4) Next on the package symbol do a Place>Update Symbols to see a list of all the "items" in the symbol database. If you expand the "Shapes/Symbols" box you will probably see your two shape symbols listed. Put a check in the box to select all of them then check the "update padstacks" box along with any of the others to be safe and click "Refresh". This should actually re-import the pad shapes into the symbol (which the first update padstacks step didn't do).
5) At this point your symbol will look messed up because you had the two pins place at the same coordinate on top of each other due to the offsets in your pads originally. You can't do this in general without creating all kinds of DRC errors anyway, so you need to move the two pads apart. Placing them 1.0mm apart horizontally should achieve what you really want. Save the file!
6) Now you can go place the new package symbol your board. But again you need two steps to clear left-over junk. You might want to delete and re-place the new package symbol from the library. But even then you won't get the new symbol details. You will have to also go do a Place>Refresh Symbols step to again select the "Shape" list and do a refresh. At that point you should hopefully see the nnew "correct" symbol!
Whew - not that it hasn't been educational, but now I HAVE to go finish a board design I was working on ;-)
Thanks a lot for your impressive effort! Rather embarassing and rude I did answer earlier. Sorry about that! :-O
Using your early posts I was able to hack (trial 'n error) the design to make usable boards/gerbers. The symbols are still totally messed up when opened - I'll give them the big overhaul using your "manual" as soon as I get all the monkeys off my back! Probably need to start over; at least my first attemt to fix them (right after I got your post) failed miserably... ;-)