WildCard Not Working in the pin list -ace 2015

[KOBI1912]

 i have add an Pin list  FOR  ITEM: 194l-E##-3254

BUT when choosing the item in the catalogue, the pin list are Missing

only afte setting the pin list with the full name 194l-E12-3254 ,THE PIN LIST ARE LOCATED  AS EXPECTED

[mathalekar · Accepted solution]

Hello Gobi

Wildcard usage concept is completely abolished now and all wildcard from database is expanded full and integrated in database. Do use proper pinlist format while adding in database.

[drathak]

---

@mathalekar wrote:
Hello Gobi

Wildcard usage concept is completely abolished now and all wildcard from database is expanded full and integrated in database. Do use proper pinlist format while adding in database.

---

So items that have previously been added with wildcards won't work now?

That makes lots of sense.  Another housekeeping task to handle after the upgrade.

[dougmcalexander]

I'm not having any problems with asterisk wildcards in version 2015.  I use Pin Lists to populate everything from 3-pole circuit breakers and disconnect switches to motor starters and pilot lights.  I used the Migration Utility to migrate from 2014 to 2015 and all of my Pin Lists work thus far.  THe issue may be associated with the use of "#" wildcards, but astersisks still work.

[RickFrance]

Asterisk (*) Wildcards are not working for me in 2015. The migration Utility also changed all the wildcards in the Pin List to the actual catalog numbers for each part that matched the wildcard.

[rhesusminus]

And that is exactly how it's meant to be in AcadE 2015. 🙂

[RickFrance]

But that is not a good thing. WE've been using wildcards for years in the Pin Lists and changing that requires a lot of additional unnecessary work.

[rhesusminus]

Well, that all depends...

The migration tool should take care of all existing pinlist values.

I did a AcadE 2014 basic training for some customers last week, and they by far preferred the new way (I have to show what's different in 2015 now) to do things.

They thought it was silly that they had to open another database editor, remember the catalog numbers and make sure they didn't misspell the manufacturer/catalog number, as one of them did, and we used a few minutes to figure out why it didn't work.

In my opinion, the new way to do things is better than the old pinlinst database.

[RickFrance]

You are entitled to your opinion, but that does not mean your opinion is best for everyone. For me, it is a step backwards because now when I add catalog data for a new component that has 100 different ratings therefore 100 different catalog numbers that vary slightly, I now have to add the pin list for 100 items instead of one single line item with a wildcard. For companies that do a lot of customization that is not a desirable method especially when you were capable of this in previous releases.

[dougmcalexander]

I answered this previously from my phone, and I guess I misunderstood.  I thought this was in reference to the Footprint Lookup database, which is still separate and wild cards are allowed.  The new Catalog Browser integrates the PINLIST entries into the same Access Form as the part number, so you can enter the pin assignments at the same time that you enter other details, while you have the datasheet in front of you.  This is similar to how the competitors do it.  As you enter the data for a new part, you also enter the 2D, 3D, and Layout Symbol mapping. It is all entered into one dialog.  But I have always preferred the wild card method versus the way the competitors do it, so this appears as a step backwards for AutoCAD Electrical.  I suspect that Autodesk did a market survey and somebody wanted AutoCAD Electrical to work more like the competitor's software.

It is convenient that you can enter the pin assignments at the same time you enter a new part into the database; no need for using the separate Pin List Database File Editor. My question for Autodesk is why do this only to pin lists and not Footprint Lookup and Schematic Lookup?  Their symbol assignments could be entered at the same time as well.  Add a ... button to allow us to browse to the footprint symbol, if we don't want to type in the block name.  I'm not saying I endorse this idea.  I'm just pointing out that it makes no sense to integrate only the pin lists and not the schematic symbol and footprint lookup.   Since version 2015 has us map the schematic symbol via the Catalog Browser, there seems to be no need for a separate Schematic Lookup database, and therefore no need for a separate Footprint Lookup database either.

[rhesusminus]

I completely understand that it might not be the best choice for everyone.

However, if you are going to add 100's of catalog entries, you have to add them to the database first, before entering the pinlist database.

Doing it like this, it's all done in one operation:

[RickFrance]

I've always used MicroSoft Access for the majority of this type of data so I seldom use the Pin List Editor or the Footprint Editor. Its just faster to me. Same is true for multiple catalog entries.

I love Doug's idea on getting rid of the Footprint Lookup though and entering it into the same data. That would not only make it easier to enter but help keep data seperate when using a secondary catalog. I think it would probably speed up the Lookup Process as well.

[dougmcalexander]

I agree that it seems cumbersome.  I prefer the wildcard method as well.  But I think the idea with the Catalog Browser is to enter one new component and use the Right-click>Copy Row and Right-click> Paste Row method to create the other variations of it, thus you are still only entering the pin list data once for a family of devices.  It is best to edit this database using the built-in editor because soooo many customers hack theirs directly in MS Access and they get fields out of order, delete fields entirely, or add non-standard tables.  This all leads to migration issues.

I just don't understand why they didn't include the footprint lookup data as well.  2015 allows us to map a schematic symbol, and even a 3D footprint symbol, so if they add a field for the footprint block, we can do all in one place; no need for the Footprint Lookup Database Editor and the Schematic Lookup Database Editor.  It just seems odd not to go all the way with this new concept.  Otherwise just leave well enough alone.

I also think that a global search field needs to be added to the Catalog Browser, like previous releases had, in case you know the part number but not which table it is in.  It's not a big problem for me.  I use standard table names that all have a description in the Catalog Browser, but I have customers who aren't as meticulous as I am, and they add a new table without first checking to see if a proper table already exists for their new component entry, or if it might make sense to add the part to the MISC_CAT table.

[RickFrance]

I also do not use the default catalog for my Pin List entries and the Pin List Editor only recognizes the default cat.

I believe in keeping my data seperate from the default data - much less to migrate and therefore fewer migration errors.

[RickFrance]

I'm not sure why their was a need to kill the wildcard in order to allow the other method. Both methods should be able to work in conjunction with one another.

[rhesusminus]

I completely agree with you also Doug.

I guess it has something to do with all the reprogramming that has to be done, making sure all the functions in AcadE seraches "default_cat" instead of "footprint_lookup" for matches.

The pinlists were already in the same database and that makes it somewhat easier to make new functionality 😄

After using the beta I hoped that there was some way to "trick" the catalog browser into doing this, as it supports "commands" for multi pole component etc. but I just haven't been able to "cheat it"... yet 😄 

[dougmcalexander]

I don't know why they even kept the separate pinlist tables.  They could have added fields to the component family tables so the pin list data could be in the same record as the part number data.  Ironically, the Cataog Browser gives you the impression that you are looking at one record in one table, but you're not.

[RickFrance]

I always assumed it was seperate in order to have the wildcard capability.There really is no other logical reason to have it seperate.

[dougmcalexander]

You needed the wildcard method when you had to enter the same part number(s) in two separate databases.  Now you can enter once, and copy.

[RickFrance]

Still prefer the wildcard method and here is why in one example.

No AB Pushbuttons come out of the box with Pin Numbers however we always use Pin 1 & 2 for them - so I could go in my secondary Catalog and enter in the pin list AB 800T* with coil pins 1,2 and I was done.

I can still do that in my secondary catalog but now I have to enter the pin list for each push button individually - that's a real pain in my opinion.