Pinlist update from parent or peer?

[Scott_Errthum]

I have a situation (dealing with manifolded solenoid valves) where I would like to be able to control the pinlist for a parent part from a higher-level parent. I have done some experimenting, and it seems that if you configure a child part to also have Manufacturer and Partcode data, it acts like a child and also allows you to assign a partcode to it. I would like to extend that one step further, imagine this scenario:

1) user places a part down (a solenoid manifold), and assigns a partcode to it for the base part and ancillary equipment to build the manifold.

2) user then places individual solenoids down (that get individual partcodes assigned to them, since they aren't known in the generic manifold part number). These solenoids use the pinlist lookup to control it's own pinlist data field so that its children can make use of the pinlist controls (like limiting contacts available on relays).

3) user as also allowed to place down electrical "children" to the individual solenoid parts (see item 2 above) that make use of the pinlist in the part.

I can get this to work if I assign the ENTIRE pinlist to the parts in item 2, but this isn't desireable, since each solenoid acts similar to NO/NC contacts on a relay (type "C"). So an individual manifold can be made up of up to say 23 solenoids, with pins (electrical side) numbered 1-24 (13 is common to all). Station 1 has pins 1,13,14 available, station 2 has pins 2,13,15 available, etc. If a 5/2 solenoid is in place then the station may have only the first set available (1,13 or 2,13).

Hopefully this is enough information, I tried to cut down the explanation a little. Let me know if it is understood what I am trying to do. I have another situation that is similar that I will approach later.

Regards,

Scott

[Anonymous]

This may or may not be useful for your complex
situation... AcadE's PINLIST assignment can also carry a "PEER" pinlist
assignment. This was originally implemented to take care of a situation like a
reversing motor starter. You have two independent contactors represented by two
parent coil symbols, one overall part number for the pair. But you need two
sets of PINLIST info, one for the forward coil and one for the reverse coil. The
solution is to assign the overall starter's part number to one coil,
let's say the "forward" coil. So it gets the PINLIST info. But its part
number entry in the _PINLIST table of the default_cat.mdb catalog lookup file
can be preset with additional data in a field called PEERPINLIST. This
is the pin data for the "peer" or reversing contactor coil (to be inserted
next). Both sets of pinlist data land on the "forward" coil but the "peer" data
is just there for temp storage. Now, you pop in the reversing contactor
part of the motor starter. It doesn't get a part number BUT you can pick on the
NO/NC Setup Button > Pick Peer and select the forward coil. The PEERPINLIST
data gets dragged across to the reversing coil symbol. Now both symbols have
their own unique set of pinlist data for their respective children.
 
 

[Scott_Errthum]

Yes, I read all about this. The problem with my scenario is that I would have multiple valves (coils) assigned to one parent (peer). Each should get it's own pinlist data. I had given some thought to the possibility of writing a routine to handle a special property to do this, but I would like to be able to trigger this routine on part insertion (ie, not have to execute the routine).

I started this whole thing with assigning the pinlist data to the primary parent, but that causes the comment text to be copied to all of the children (very undesirable since the valves will have their own description and function).