New ModelCheck Ideas

[jwagh]

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:

1. No Weak Dimensions
2. All Orphaned Dependencies Broken
3. Features set to Read Only
4. Any un-embedded datums or sketches should be named
5. No 0 dimensions for scenarios where they could be constrained to coincident (in sketches, holes, datum planes, etc)
6. Only Locked Dimensions, where applicable
7. All dimensions should be named when used for relations or family tables
8. All features should be named for family tables
9. Sheetmetal flatpattern won't fail
10. No nested family tables
11. Patterns should be set to Identical, where possible, instead of General
12. Remove unnecessary relation comments
13. Any sheetmetal features not using the default sheetmetal parameters for bend radius, etc...
14. First Assembly component that is externally referenced
15. First Assembly component that is not using default or coincident with default datum planes
16. Checking subcomponents in assembly for proper naming convention
17. Checking subcomponents in assembly for proper parameters (windChill location, based on naming convention and release state)
18. No Assembly Cuts
19. Assembly not to be in Exploded View
20. Assembly not to be in X-Section View
21. Drawing/Annotation Notes to only be used from a certain list, where the notes contain more than one line
22. Drawing General Views to not reference Geometry
23. Model Name should be the same as File Name and Number (3 columns in WindChill)
24. . I had to create a separate idea for this...

In addition:

1. Better Support for use-case scenarios where some instances of family tables are released and others still being worked on or tweaked from the generic's family table. How can we run modelcheck without flagging all instances as modified.
2. Allow an option for ModelUpdate or Custom Checks to go to the ALL tab by default
3. Allow mapkeys to work within browser pages and change the ModelCheck tab/buttons
4. Allow condition file to incorporate more than 2 statements and include multiple AND/OR with parenthesis
5. Allowing the condition file to see information about the drawing's model (parameters, model type, etc)
6. Update HTML look to be similar to WindChill 10, like the current looks like WindChill 9
7. Have the condition file be able to not add parameters or add parameters based on certain situations (will help the family table scenario above - for generics)
8. ModelUpdate run on other modes besides Interactive
9. Check for Material Names that should NOT be using
10. ModelCheck be run from within WindChill (like the View addon can create dxfs...)
11. ASM_CREATE_VIEW ability to create ISO views - more complex views
12. EXTRA_LAYERS - Allow for a list of layers to be in the layer tree, without forcing its creation, such that everything else can be deleted
13. PRT_PARAM_MAP won't actually map if PRT_PARAMETER is also available for the same parameter
14. STD_DRW_DTL_FILE based on model units
15. OVERLAP_INFO - Support Geometry lines, not view border
16. UNUSED_SHEETS to support formats
17. MCREGEN_VERIFY_FT_INSTS for parts as well (see above about released instances)
18. DIR_REPORT to be a separate location than the actual HTML files for the ModelCheck browser. Any non-local path will fail give an error when running modelcheck
19. Move out as many config.init options to another location that can be modified while running Creo AND can be set with a condition.init
20. MATERIAL_NAME support for subfolders in the material library.
21. 9/5/17 - Allow ModelCheck reports to be added as an attachment to the CAD Document in WindChill automatically.
22. 10/18/17 - Have the Circular reference error actually spell out what is wrong and what the loop is. At LEAST using the same words as the .crc file. We would appreciate better wording than the .crc. Currently it just lists the model, which is very confusing and doesn't help much. The Creo 4 notification window doesn't help much in this area as well. We need to move away from the .crc file to debug circular references. Modelcheck AND the noficiation window should be better used for this.

From Comments Below:

1. mlockwood-2‌ - ModelUpdate option on a per-check basis (buried features to not be deleted) especially since buried feature check is more wrong than right... (And Erased Views)

I'm sure there is more that I'll think of later. But this should be a good starting list

[MikeLockwood]

Fabulous list - much appreciated.  We may use some of this for manual checklists.

[jwagh]

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.

[MikeLockwood]

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.

thanks

[jwagh]

Yup! Forgot that one. Added your idea to the list. This way it is all one place

[BenLoosli]

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!

[jwagh]

Ben,

  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.

[dnordin]

Mike,

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."

Regards,

Dan N.

[BenLoosli]

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.

[MikeLockwood]

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."

[MikeLockwood]

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.

[jwagh]

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.

[esallingboe-2]

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??

[jwagh]

I'm pretty sure submodels are only checked for modelcheck interactive (regular or regen).

[smilliman-2]

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.

[esallingboe-2]

I'm afraid you're right

But, it would be good if it could be done in submodels on save as well

[esallingboe-2]

Can you please clarify

[smilliman-2]

I thought this would take care of your question, but it does not seem to be that way.

CHECK_ALL_MODELS

<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.

[esallingboe-2]

Thanks ,  I have to investigate it

[esallingboe-2]

Hi

No this will not Work, it is only performed in interactive mode

We need to have it running as a active part of storage

ES

[sully7]

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.

James Sullivan

CadActive Technologies

[jwagh]

Jim,

     The ProToolkit license is extremely expensive and requires learning a whole new coding language.

[sully7]

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.

James Sullivan

CadActive Technologies

[jwagh]

Is there a good resource and training to learn J-Link? I haven't done C since college.

[manjunathrv]

Also Vote for ModelCHECK with Windchill

[jschramm]

Great list!

Another idea, which we would appreciate, is to be able to exclude models from modelcheck via condition.mcc when they are not checked-out.