Below are a list of some of the items on our company checklist that are not covered by modelcheck. We would like to see some of these implemented. I know some have their own product idea, but I'm throwing everything in here:
From Comments Below:
I'm sure there is more that I'll think of later. But this should be a good starting list
Fabulous list - much appreciated. We may use some of this for manual checklists.
We use a checking mapkey that runs modelcheck and then goes through the persons model step by step for many of these other items. Would be quicker if it was just in modelcheck.
This thread really starts to take off, and I'm hoping PTC may improve ModelCheck based on it.
My major input at this time based on lots of recent work is about the UPDATE functions. I'm scared to turn no because A) some are automatic and leave the user no choice (e.g. MC automatically deletes!!!!! any buried features B) There is no confirmation what UPDATE has done. Because of this, we've laboriously created mapkeys that do the same thing but the user has control. Would like to see UPDATE allow user interaction.
Yup! Forgot that one. Added your idea to the list. This way it is all one place
I voted this up, but I also see some items on the list that I disagree with or find at first glance will be impossible to implement.
Remember, PTC has NO in-house programmer who developed ModelCheck, it was purchased from Rand Worldwide, and PTC has done little to enhance it since they bought the code..
Item 1: I use weak dimensions when I just don't care what the value is since a later feature will make the weak dimension go away in the final model.
Item 6: How does software determine which locked dimensions are required? Personally, I don't like locked dimensions and seldom use them except in extreme cases.
Item 10: While it might be nice, there are cases where a nested family table is nice. As with any family table, how it is treated and modified goes a long way in making them work, especially in Windchill.
Item 12: Relation comments document the part design, they are important for the next user to understand how the model was created X years ago.
Item 18: While I agree they are bad, especially when I see outside the intended geometry messages when I retrieve an assembly, they do serve a purpose. Match drill a dowel hole in a tooling plates needs to be done with assembly cuts. You can do them at the part level, but they are better done as assembly cuts.
Items 19 & 20: Not sure what you are asking for? If you mean the default stored view in an assembly, then I agree.
Item 23: Totally disagree!! The Model Name should be a descriptive name. The filename and number should be the same, but even then I can see cases where they don't match.
IA Item 1: Family tables should be modified as a whole by a select few people and stored in a Library so the get pulled into a designer's workspace as Read-Only. There are best practices for dealing with FTs that if this happens are not being followed.
IA Item 7: How does the software know what conditions to apply changes to or not. You don't want to editing condition tables every time you run MC to set up your custom conditions.
IA Item 9: Might be easier to check against a list of approved materials. The unapproved list approaches infinity!
Your first statement is untrue. Over the last few months, PTC has done a lot of tweaking and rework on ModelCheck. For instance, a bunch of my tickets were fixed and I found out about some upcoming config.init options that have not been publicly released yet (MU_MASS_RECOMPUTE & MC_REGEN_REPORT_ALL, MC_GET_VERSION_FROM_META_DATA). Since Wildfire 5, they've added about a dozen checks to ModelCheck. Plus, there are rumors that management has been eyeing an overhaul for ModelCheck.
Also, just because you personally don't believe in some of these checks, doesn't mean you need to use them. They would be for others. To answer your questions:
Item 1: We have some users with very poor modeling practices. They don't constrain nor dimension anything. This forces them to actually think about the design they want and create some design intent
Item 6: Locked dimensions are only for sketches. The only difference is that they prevent geometry lines from being dragged. You may think dragging one line is JUST moving that one item, but will end up adjusting some other geometry entities creating unknown changes to your sketch/design/model. Changing a dimension rather than dragging prevents this from happening. Locked dimensions prevent dragging.
Item 10: Could be. We've had issues with nested family tables. Again, to each their own, but we would like the check.
Item 12: Unnecessary relations comments would be defined like PRT_REL_UNWANTED, where we would specify the actual comment. Many of our legacy models say something like MODEL RELATIONS BELOW THIS LINE. We would like to clean that up and remove it.
Item 18: Again, there are scenarios where they should be done, but not at our company. They cause too many issues that can be resolved using Merge into another part. Not all of these would be ERRORS, they would be WARNINGS.
Item 19 and 20: Yes, people are checking them into WindChill In exploded or X-Sectioned Views.
Item 23: Again, this is company specific. Our current policy is to have all three columns match to avoid confusion when doing Save-As and for many other reasons. All other information is exported from Creo into custom Attributes we created. We use three TITLE parameters for our descriptions. Again, I am requesting functionality, not enforcing it.
IA Item 1: We have some situations where complete products are family tables. For instance, we may have one rack-mount box have one HDMI output connector and another with 2 HDMI output connectors. Everything else is the same, from a designers perspective. Therefore, the PCB Assy, the chassis, and the product would all be family tables. If those instances are released and we need to create a quick new product that has three HDMI connectors (by changing the HDMI pattern number), it shouldn't force the other instances in the chassis part to be modified.
IA Item 7: Example: IF (FT_GENERIC_PRT) ADD_DATE_PARM=NO. Sort of like what it can do now with: IF (FT_GENERIC_PRT) MATERIAL_INFO=NO
IA Item 9: The Material List is a long extensive list that are within Subfolders. MATERIAL_NAME does not support subfolders. When I started working at the company, all start parts already had 718_INCONCEL listed. WOOPS! I would like to flag 718_INCONEL as a wrong material instead of listing the hundreds of OK ones that users won't be able to add anyway from modelcheck because they are in subfolders.
Doesn't update mode only automatically "fix" items flagged as "Errors"?
Since you cannot toggle between "update" mode & "check" mode while in the same Creo Parametric session (an enhancement I'd like to see), you can configure multiple check files with just those items you'd like to potentially fix automatically. One set of check files would be to list the items ("Y" vs. "E" in the check file); the other set of check files would be to fix the items ("E" vs. "Y" in the check file). You can create mapkeys for the user to toggle which "mode" they're going to use. If they run the list items checks first, they can review the report and correct any items that MC would otherwise delete (or not handle as wanted). They can then run the fix items checks to have MC fix the remaining items. Granted it's not the most graceful method, but it should work. I have not actually tested this.
Also, MC should report what it changed according to PTC's docs:
"About ModelUPDATE Mode
The ModelUPDATE mode allows you to automatically update models for errors generated during PTC Creo Modelcheck . All the updates possible from the PTC Creo Modelcheck report that do not require manual interaction such as typing or selection are automatically performed in ModelUPDATE mode. A report of successful and failed updates is generated. You can configure ModelUPDATE mode using the PTC Creo Modelcheck configuration files."
Maybe PTC has started to improve ModelCheck, but those efforts are not out to the general user base, yet.
My first parts of the second sentence are still true.
PTC has NO developers in-house who developed Model Check.
PTC did not develop Model Check they bought it from Rand Worldwide.
While I agree that any checking done with ModelCheck or other means is strictly voluntary, in some cases a data check is not always black or white (yes or no). Getting software to handle the gray areas of data checking is the hard part of developing ModelCheck checks that work for each company.
Daniel, good points - gets into a bit more specifics, but important. More to know, but this is what I currently have experienced:
Ref - We currently only have one set of config files and set MC to automatically use those (simple); users currently can't select from among sets.
- Update automatically removes some things (like buried features) and I can't see where to see a confirmation
- Update does provide a confirmation but the user has to know where to look one by one; if they simply close the browser (inside Creo) and move on, there is no awareness that things have been changed, possibly drastically. They can optionally dig down to find the report but it's not "in your face."
This is a good discussion. Maybe PTC could / should / would want to initiate some sort of survey to methodically collect. Could do some compare / contrast with competing CAD tools also maybe.
I've been working with SolidWorks Design Checker recently. Superb UI for configuring, but lacks 90% of the checks for 3D models. It also fixes / updates w/o much feedback, but mostly confined to drawings.
NX has a very good check tool as well - saw a recent demo.
Overall, has to be simple by default, with added complexity available when needed.
Added ModelCheck - check for Missing Internal References in Features!, which I could not believe is not in ModelCheck. I had to create a separate idea for this.
I voted this up,
From my point of view ModelCheck are in need of a update, both functionality and UI
We run ModelCheck in Creo when the models are saved, but there is one issue, ModelCheck do not check on sub levels
Do you have this issue aswell or??
I'm pretty sure submodels are only checked for modelcheck interactive (regular or regen).
You can check them in all options. You just have to turn it on in the settings. For interactive you should see a menu pick either top level or all levels.
I'm afraid you're right
But, it would be good if it could be done in submodels on save as well
Can you please clarify
I thought this would take care of your question, but it does not seem to be that way.
<Y / N>
Indicates if Creo ModelCHECK must check all models of an assembly, regardless of whether the models were changed after retrieving or the value of the parameter MC_ERRORS.
• Y - There are always all models examined and ignores the setting of the configuration option SKIP_MODELS.
• N - The models are tested according to the setting of the configuration option SKIP_MODELS.
Note: CHECK_ALL_MODELS (CHECK_ALL_MODELS) is applicable only to the interactive mode of Creo ModelCHECK. It does not work for regeneration and storage mode because such modes Creo ModelCHECK is performed only for the top level assembly or for the component that you save or regenerate.
Thanks , I have to investigate it
No this will not Work, it is only performed in interactive mode
We need to have it running as a active part of storage
I definitely agree that ModelCheck needs some "out-of-the-box" improvments... but just to comment quickly, it theoretically can be customized to cover a fair majority (if not all) of these desired ideas using ProToolkit.
PM me if you'd like more information.
The ProToolkit license is extremely expensive and requires learning a whole new coding language.
Agreed ... but you don't actually need the full ProToolkit or Object Toolkit (OTK) - there are ways to customize it using Creo's free APIs.
J-Link (the 'free' part of the java OTK), the VB API (can be coded in C# therefore as well), both enable custom checks as well via "IpfcBaseSession.RegisterCustomModelCheck() and CCpfcCustomCheckInstructions.Create()". It doesn't help the issue of needing to know a whole new coding language... but it definitely is better than the thousands of dollars per license you'll need to pay otherwise.
I definitely agree that they need to update it "out of the box" to be much, MUCH better.... but it can be done.
We have a good amount of experience with this, so feel free to PM if you'd like a demo.
Is there a good resource and training to learn J-Link? I haven't done C since college.
Another idea, which we would appreciate, is to be able to exclude models from modelcheck via condition.mcc when they are not checked-out.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.