> >>I'm not sure I follow that bit. > > Say you have a master part, # 3245671, this is sort of a "primary machined >number". > > On the blueprint for this part, there will be certain features that don't > have >any dimensional > > information, but instead have a callout of some kind, i.e., "Hole D", or >somesuch. > > At the top of the blueprint is a "tab block" that is a table of "alternate >part numbers", >
Ah OK, Yes I've seen that used in produccing similar but different printed circuit boards (my background is in electronics not foundry work) > This was originally a convenience/cost saving thing, I suspect. Almost certainly, and it makes it much easier to add new variants since only the tab values need changing. What it means for you is that you need in parallel to your main app a mechanism for managing the identities through these differeing ID values. Effectively a lookup table and mechanism for tracing designs from raw pattern to finished item. > >>You may also find it useful to think through the state model for your > castings/workpieces. That may help to constrain the number of >Actions/operations required. > > ummm...what's a "state model"? It defines what operations can be done on your objects at any given time depending on the "state" of the object. As a simple example a light can be switched on when it is off and off when it is on, but it cannot be switched off if it is already off. In your can you will have a sequence of operations with dependencies between them such that certain operations can only be done after others have completed. Others cannot be done after others have been done. State models can be table driven which makes them highly configurable so that a single object can be loaded by multiple state models and effectively act like different object types without having to change the code. HTH, Alan G. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
