In our functional evaluation of PDMLink 9.0 F000 & M020, we discovered an issue with Family Table functionality. I have been told that this is how PDMLink 9.0 M030 & M040 work as well. When a FT is verified in Pro/E, there are 2 potential outcomes : 1) Success - All instances regenerated successfully 2) Failure - At least 1 instance did not regenerate successfully
When attempting to checkin an unverified family table from Pro/ ENGINEER, the user is prompted to : 1) Verify now 2) Ignore this 3) Ignore all
After checkin of a unverified family table, the status of the family table can be displayed in the object's details page. So, PDMLink is aware of the bad data quality, but doesn't do anything about it. There is a configuration option (verify_on_save_by_default=yes) to set a default value to VERIFY when the user prompted, but it still allows users to ignore the warnings. To me, this is pretty basic stuff...anybody who has experienced the bad old days of pre-Pro/I 3 will surely appreciate that allowing unverified (bad) Family Table data only leads to trouble.
My questions for you : 1) How have you deployed PDMLink without being bitten (you know where) by bad family table data that should have been verified? 2) Have you customized the system to force verification prior to checkin? My answers to you are "no" and "no". I'm on PDMLink 8 and so far, using it only for auto number generation and electronic releasing. Digital data management, product structure, document viewers, vendor integration, linking to MRP is all to come, 3-6 months in the future. Full integration is being dragged out, as slowly and painfully as possible, with no end in sight. Your issues seem trivial by comparison, but who's comparing.
Still, I'm not 100% convinced of their legitimacy. PDMLink says "who cares" to the family table verification issue. I agree; what business is it of the document management system what the "integrity" of the data is? Could it similarly examine and test AutoCAD drawing files? Solidworks or Catia V5 files? Who's expect it to!?! You should be thinking more along the lines of a vigorous ModelCheck program to test Pro/e data against some standard/criteria of integrity. MC can check lots of things, including what you're looking for (inappropriately) out of the PLM system.
Family table verification is itself flawed functionality and valid under only very limited circumstances, invalid under many others. The only place where I know that verification is indispensible is in working directly with the table to add instances. There is no other way that such an instance is regenerated and recognized as a table member except by Verify.
OTOH, Pro/e's Table functionality often marks instances as requiring verification when there seems no reasonable need for it. For example, open any generic, modify a layer, do a 'Save status', save the part, do 'Tools>Family Table' and click Verify. Every instance will be marked as 'Unverified'. Can anyone explain how any instance (much less the generic) requires regeneration because I turned off the layer display on datum planes? Do the same with changing just about anything in the 'Edit>Setup' Menu Manger functionality. Change units, material, mass props, etc, none of which have the possiblility of causing a model feature failure, yet all mark each and every instance as 'UNVERIFIED'. Please explain how this has anything to do with combating "bad data"!! Likewise, any change to generic dims, either regulated or unregulated by the table, will result in every instance being marked as 'UNVERIFIED'. I have experienced even more bizarre behavior from Pro/TABLE and its family table creatures. Generally, the most fool proof way to deal with modifying instances is to open them, change a table based dimension, regen and save. This will generally update the table and make the instance show up with Verification Status as 'SUCCESS'; in some cases, modifying a table governed dim in the instance, regen and save has resulted in the new values showing up in the generic table but every other instance being marked as 'UNVERIFIED'. Again, it's not even conceivable how changing one instance could cause the change in status of all other instances, except that PTC has followed the most stupidly conservative course of regarding any change to the generic (and by inference, any change to an instance) as changing the status of ALL instances and thus, requiring their mass verification. But who is mistaking this kind of clowning around for data integrity or its absence as "bad data"? It's a BIG stretch; maybe a Seventh Inning one? I'm yawning.....
David Janes