I am getting ready to recreate a set of mapkeys in Creo that were originally created in WF4 and I need a little advice. In previous version of Pro/E it was considered bad practice to create a mapkey using icons or anything that could be customized because the mapkey would not be usable for other users with slightly different UI configurations. Because of this, I have always created my mapkeys using menu picks and it has worked very well.
The problem I see is that Creo is almost entirely icon driven and the whole user interface can be customized. Since there are no menus, I don't see how you can make a reliable mapkey that will work on more than one machine. The only real solution I see is to use the search function but that also seems like it could have problems.
I would just review your mapkeys afterwards and do lots of testing on other people's machines. When you review the code you will see references to activating the various tabs. These actions can be stripped out if you like (although it may take some guess and checking).
upon the start-up of a user, files distribute from a central place to their local Creo load point any "changed" version of the config.pro or creo_parametric_admin_customization.ui file. Changed could be from the server or local load point with the server being master.
The ribbons are modified accordingly and are activated via an icon. I also make sure to include the mapkey name in the code so that when you hover over the icon, it tells you the name and the key sequence, example:
The first and best practice I would note would be for everyone using Creo to have a PTC.com account. There is a tremendous amount of material available on PTC's website and I often reference specific topics in the Help Centers ( ). A PTC.com account is also required to open a case with technical support.
For instance on Relation Parameters, we created what we called Embedded Parameter Creator. It was based on weblink and was an interface in the embedded webbrowser. What it did was to provide selection of parts we make and the list of parameters such parts had to have. Users could launch also the script when using existing parts, The tool highlighted if certain parameters or relations were missing/wrong according to the part opened. It has helped a lot with data cleansing (we do a lot of Save As)
We also replaced the OOTB Regeneration buttons by our customer ones. As some of our models needed to be regenerated twice to get the green light (most users regenerated once and never checked the green light).
Generally from my experience, admin must fight on several areas, Policy but also system configuration so either policy is used automatically by the system (eg for us if parameters were missing you could not check in, or if Model Check returned certain types of error). And train the users, provide consolidation training. A lot is down to education.
Any file (prt, drw, or asm etc.) may have only one owner. That is, only one person has the ability to write to that file. Any file that you are the owner of should exist in your own directory and nowhere else. If a file is to change owners, the current owner must follow the proper procedure. (See Transferring Files)
Any time electronic files are sent to, or received from, vendors, clients, or any other outside party, there must be a record of what was sent/received. Copies of all such files will reside in directories as shown in Pro-Standard-Directory-Structure.doc. For instructions see Sending Files.
Files can be named in either of two ways. One is to use the ID part number. The other is to use a meaningful descriptive name. Either method can be used but must be consistent within any given project.
Features should, whenever possible, reference/be dimensioned to, the default datums, second choice is secondary datums, next is surfaces. It is not good to reference or dimension to edges, especially not silhouette edges created by rounds. Design intent, however is the most important, so use your judgment and build features in the most sensible way you can.
It is a good idea to change to an isometric view before aligning to part surfaces or edges, to be sure of which one you are picking. It is best to align to datums, next best is surfaces, and then edges. NOTE: As of release 16, you can align to surfaces without reorienting the view.
A guideline for the order to create features:
Default datums, other datums and axes, base feature, pre-shell features (including large rounds), shell, pre-mirror, mirror, other fit/form/function features, draft, and rounds. As always, design intent supersedes this rule of thumb.
Use reorder and insert mode to keep features in a sensible order. In addition to the above guidelines it is helpful to have related features ordered together. This helps in understanding the model and is useful when using insert mode.
Start with the base or chassis and assemble parts and sub-assemblies to it in the same order that will be used in manufacturing. This may give the most desirable end results, but is often difficult to achieve.
Start with the most important functional unit and build on that. For example, on Clipper it was the optics base, this was where most of the action was taking place, and many other sub-assemblies had to interface with it. This gave us the most meaningful model in terms of design intent. Sub-assemblies which interfaced with each other could be assembled together directly with datums at the point of interface, guaranteeing proper alignment. In method #1, each assembly would be assembled to the chassis, and the interface would rely on the chassis being correct. In this method (#2) the function drives the assembly, not vice versa.
Parts should be assigned different colors in an assembly to make it easier to understand. Do this in the assembly, not in the individual parts. It can be helpful to have a consistent color scheme, for example:
Or use colors that most closely represent the real objects. The primary goal of assigning colors is to make the assembly easier to understand, so this should take priority over any color scheme. (i.e. Two adjacent parts should be different colors even if they are the same material.)
Whenever possible use the views that are defined in the standard startpart. (i.e. Top, front, right, etc.) Note: If a view name is deleted or redefined in the part, the drawing may lose all dimensions for that view AND all views that are its children. So be careful not to change or delete the standard views.
When detailing a part for someone else DO NOT make any changes that will affect the geometry of the part model. Changes of this type should be made by the responsible engineer, in part mode. This, of course, does not include the creation of x-sec.s or other detailing functions that save information in the part file, these changes are okay.
For general drafting practices use ANSI/ASME standards unless otherwise specified for your project. The drawing setup files will determine most of the settings (text height, arrows etc.) to ensure consistency within the project. Make sure you are using the same files as the other members of your team.
Each user will have a config.pro in their working directory for each project. There is normally a template config.pro in the Library directory for your project. Copy this file to working directory. This file will contain the following settings:
Since your working directory is different on each project, it is suggested that you make a different icon for each project you work on. You should rename the shortcut to indicate which project it is for. You can do this either while creating it, or by right clicking on the icon and choosing rename.
Startpart.prt and Startassy.asm are templates that contain default datums, coordinate systems, tolerance info, several parameters, and many saved views. Using these saves time and helps to insure consistency in models made by different users. Note: NEVER change or delete the default views. Any drawings that reference those views can lose the dimensioning scheme, requiring the user to completely redimension the drawing.
Similarly, you want a record of all electronic files that we send. Since Creo files may have associations to the assembly, and may have relations etc. it is possible for them to change without our awareness. So it is very important to make an exact copy of what was sent in a directory where it will not affect or be affected by the assembly or other users.
NOTES: If the file you are sending has any parents, they must be sent as well. For example, if you are sending a drawing (.drw) file you must also send the part (.prt). If you are sending an assembly, you must send all of the sub-assemblies and parts too.
If you are sending an IGES, DXF or other translation, it is a good idea to make an archive of the original Creo files as well. This will come in handy if the translation is not readable by the recipient. Also it is easier to check dimensions etc. in the original.
Our innovations have helped healthcare professionals enhance the lives of more than 1500 patients worldwide to date. Chris Grayling is one of those patients to have felt the benefits of our Advanced Energy technology. Read his case story to find out more.
We partner with our customers to provide innovative technologies and provide a suite of supporting products that offer both great value and quality within Gastroenterology, Urology, Pulmonology and Surgery. Discover our medical specialities.
Our unique, Kamaptive Technology. combines super high frequency microwave and advanced bipolar radiofrequency energy to enable a range of miniature and minimally invasive endoscopic devices to precisely cut, coagulate and ablate.
Our range of Advanced Energy devices, powered by our unique Kamaptive Technology, are designed to provide the highest level of patient benefits, deliver cost savings and the latest technology to healthcare providers. By bringing our Advanced Energy devices to the emerging field of therapeutic endoscopy, we are empowering hospitals and healthcare professionals to revolutionise their practice and provide an optimised and efficient patient pathways.
c80f0f1006