Patterning Oddities
I came across a pattern where the original feature is in the middle. It was done using the Distance pattern type. For the first direction a datum plane was selected and a distance and number of instances given. Then the second direction was chosen, and the same datum plane was selected, the direction arrow reversed and the distance and number of instances selected. The goal was to produce 5 features - the original and 2 on each side so 3 instances had to be added on each side. However, the total number of instances created is nine, with four overlapping which is probably why this pattern of features did not get used as a ref-pattern. The puzzle is that this even works. Robustness I guess. It creates a 3 x 3 matrix of locations, but they are colinear.
Since the original feature was built from a datum plane there was no locating dimension to build a dimension pattern from. This is easily rectified by creating another datum plane offset by 0 from the original and rerouting the feature to that. This doesn't completely solve the problem as direction patterns only go one way by default and this needs to split.
Welcome to Pattern Relations. Instead of an increment, an tiny program is used to generate values for the dimension.
So I tried memb_v = inst_1*spacing - idx_1*spacing, which sort of works, but still duplicates the original feature on the way.
So I had to add:
if (idx_1 > floor(inst_1/2)
memb_v = memb_v - spacing
endif
(note - I am away from Creo, so check the pattern parameters that are in the relation editor.)
Obviously this is for patterns where the original is in the center of the pattern, so when the idx_1 goes any more than half-way, just subtract an additional spacing increment. Some other arrangement might be made for cases where the original feature is offset from the centerline, but not at one end.
I tried to use memb_v = inst_1*spacing - idx_1*spacing - (idx_1>floor(inst_1/2)* spacing, using the logical inequality test to multiply the spacing directly, but the relation interpreter flagged it as mismatched arguments. Most languages promote logical test results to a number like 0 for false and 1 for true in numeric situations, but Creo doesn't.
What was noticeably missing was a way to create parameters while creating the pattern relation.
It would be nice to create two-sided patterns directly - so that there is a separate plus and minus direction for each dimension selected. This way the related incremental spacing can be shown on the drawing/edited directly instead of having to bring up the relations editor within the pattern editor or the seemingly unrelated parameters - that is, nothing directly tells the downstream uses how to vary the pattern without a lengthy search.
One thing that makes the search lengthy is that although the 'Relation' flag is in the Direction pattern, there is a check-box that must be selected (Creo 2.x) to edit it.
Working without a map.
I am working on building a VBA macro that builds a mapkey to take pairs of model names and create a simplified rep of only those parts. This is the fallout from the global interference analysis. It's been a while and I am reminded why working with mapkeys is about as unpleasant a task as is possible.
The main area is the lack of a guide to explain the syntax of what is recorded, which means editing and debugging them is an exercise that is significantly frustrating. Adding to the confusion is that it's built on top of additional padding. For example, in one approach to selecting a directory the recorder moves all the "\" directory separators to "\\" But why? I have no idea. And it doesn't seem to matter, which saved having to handle that case.
I should probably create a new Mapkey document that I can collect info about them. A quick search turns up a lot of others encountering similar problems.
Analyze this!
I recently have been doing a global interference analysis and am less than pleased with the result. The main problem is what it's always been, that interference fasteners and threaded fasteners show up as interferences but those interferences don't exactly matter. However, there is no way to mark these interferences to be ignored, so they show up every time the analysis is run. Another problem is that the list doesn't show enough to track down the interfering parts by showing their next assembly and component number. It's nice to be able to click on an intefering pair and see the items light up, but when there are 3000+ items on the list it isn't much help.
There is also the problem that the list, as-produced, is not sorted according to volume and does not include interference type. For example, if a face or a vertex is buried into another part that is a simple interference, and a greater volume indicates greater interference. However if the parts interpenetrate**, the volume of interference may be small, but the actual problem could be much larger.
Summing up - it would be good to be able mark acceptable interferences and have them filtered from the list. Items that would typically on that list - e-rings, pressed-in inserts, screws into matching nuts/tapped holes, parts that push into soft gaskets, roll-pins, et al. These pairs should be stored in the assembly level they occur in, so if an assembly with acceptable interferences is put into a higher assembly, the system can exclude or flag those already identified as OK/expected. What would be stored is pairs, comp #s, next assemblies, and volume. If those all match then skip/flag as pre-identified.
One big annoyance is that the calculation of column widths for the "i" display into a text display box is flawed. If the saved interference file (you can save it as a txt file, but Creo adds a numeric suffix, blinding WIndows from double-clicking to start Notepad) has more than 999 lines, the lines numbered 1000+ shift the entries on those lines so that fixed column width parsing in Excel pushes the ":" into the first Part column. Maybe Notepad++ will become the integral editor for Creo and allow fixing this prior to export?
What I have done is to create a pairs key-record in Excel for the acceptable interferences so that as time goes on, for similar assemblies I can pre-flag acceptable interfering pairs and concentrate on just the ones that are not expected. However it is not certain to identify unique interferences that can be certainly crossed off the list.
** Push a pin into a finger and there is greater volume as it goes farther; push it all the way through and the volume doesn't change with location, but the error in location is much greater. Knowing the type of interference is a help in know what to spend time on.
Excel-ent
One part of using CAD is to verify that what's going on in the model matches what's going on in the rest of the Org. If you are in a company has a software pipeline that drives purchasing from the CAD model then this won't mean much, but if there are processes that determine which parts are to be used in certain assemblies, and those processes produce Excel or other tabular data, this might be of some interest.
There are two good places to extract data for comparison purposes.
One is the model tree, which has the advantage of seeing things like the component parameters as mentioned just below (Putting the pieces together) It also includes markers in the form of Group names, so that one can see the logical structure of an assembly, which can be handy in diagnosing differences with external lists. The faster one can answer the question "what do each of these parts do," the better. It also can include feature/component names, so that parts can be identified by their particular function in the assembly.
The other is from the Windchill Structure. The Windchill Structure Table view can be customized to show a number of pieces of information, but (I think) cannot see parameters that have not been Declared. It can see component names, but cannot see features or groups. It can see a lot of status information, much of which is available to the model tree, but to get that info to the model tree requires transfer of Windchill status info to the Windchill client workspace and then to Creo - it is nearly instantaneous in Windchill and like a slug getting to Creo.
One thing I have found handy, and the reason for the section title, is using Excel to manipulate the information in ways that Windchill doesn't. For example, there is a spreadsheet laid out for planning the transition from one product line to another. This is not possible in Windchill as the new parts and assemblies don't exist, so how does one: A) identify the candidates for change in the current product structure; B) see that the change was correctly performed?
My go-to pair of Excel functions are Match and Index. Given an input, Match looks in a list and returns the position in the list, if there is one. Index, given a list and a position returns the value of the cell at that position in the list. The big advantage to Match and Index over VLookup is that VLookup requires the data to be organized in a particular way, and Match and Index can be applied no matter what. For example, if you want to find a New number that might be in column C, but the matching Old number in column A then Match on Column C and use Index on column A. This would not work with VLookup.
One problem to be overcome either way is that Match and VLookup are cell type sensitive. If one cell contains an entry that Excel considers to be a number and the comparison list has values that Excel has marked as text, the comparison can fail and Match/VLookup won't find an item even though, side-by-side, the items look identical.
Since Excel doesn't believe in coercing types, there's no function designed for fixing this comparison failure, but there is a way to take a whack at it.
Suppose the basis for search is in cell A1. Then =MATCH(--$A$1, find_in_range) will do a double negation on the value in A1. If A is a number, this results in a number. If it is text that looks like a number, Excel will do the conversion to make it a number so the double negation will work. Alternatively, =MATCH($A$1 & "", find_in_range) will force Excel to convert a number in A1 to be a string so that it can append the null string ("") to it. To ensure that it doesn't matter which one works, combine them into a common formula:
=IFERROR(MATCH(--$A$1, find_in_range),"") & IFERROR(MATCH($A$1 & "", find_in_range),"")
will try both versions, one of which will fail because the type won't match, but it doesn't matter, because the other one will work, if there is a match available. I prefer the use of named ranges in Excel because it is a lot easier to change what the ranges refer to -and- cutting and pasting cells from part of the range does not affect named range references.
a
Putting the pieces together
This is something that came out remarkably well - Component Parameters in assemblies. The first step is the hardest, but it gets easy quickly.
Select the Parameter icon and select Component from the drop down, then pick a component in the assembly (preferably one that is at the top level, not in a subassembly.)
Then create a new parameter - I used "Sort_String* (Item_Number or Find_Number would also work) and gave it a string type and string version of a number. Then go to the Model Tree and add a column from the Features group and type the name "Sort_String" in the blank box at the bottom of the list. Even though it is a Component Parameter, each individual component is actually a feature of the assembly.
The parameter can be accessed by clicking on the Row/Column in the model tree that corresponds to the component of interest. If the component has a Component parameter already assigned, selecting it will pick the value for editing. If one hasn't been assigned yet, the Create Parameter dialog box opens. Set the type and the value and pick OK to add the parameter to the Component. Use the Find box to find all identical components (1/4-20 x 1 inch screws, for example) and select them (turn off submodels check mark.) This will expand groups and they will remain highlighted so that locating and putting the right find number next to each one is just a matter of clicking. One thing I wish would work is Mapkeys, but they don't seem able to recognize this pick. AutoIt would most likely work by recognizing the Parameter window was open and active and could automate the selection of the desired parameter type as well as assigning a repeated value.
Note - this parameter is not in the underlying Part/Assembly, but is associated to the particular assembly component. The underlying Part/Assembly can already be locked and released and it makes no difference. This only affects the working assembly. It won't show up with the same number in other assemblies. As a result, if a component is assembled multiple times, this operation will be repeated for each one. It's tedious, but not difficult.
The following rewards come from this bit of tedium.
Once this is in place a Repeat Region can be created using Sort_String as asm.mbr.cparam.sort_string. Set the sort order to use Sort_String to get the parts in Sort/Find/Item number order. Set the Table BOM symbol (Pick a cell, select the entire table, then pick Properties) to Sort_string (default is rpt.index) and the the BOM balloons will be driven from the sort_string. This means that the same sort_string can drive every Repeat Region with the same settings (save the table and Insert Table From File,) so if a Simplified Rep is used to make a view on a drawing, it can have its own Repeat Region to drive balloons that are identically numbered to those driven by a table that is based on the Master Rep or any other Rep.
Also, no more fixing/unfixing an index. The Item numbers can be added when the assembly is made, in advance of the drawing. The numbers are available for model-based definition. If a component is replaced, the parameter stays with the Component entry in the Model tree, so the same item number is retained. If that's not desired, the item number can be changed at the time of replacement and the BOM Repeat Region will be automatically in order.
To debug the Repeat Region/assigned numbers, the sort order can be set to the Common_Name or Name, so that any duplicates will reveal components with mis-matched or missing Sort/Find/Item numbers. If the Repeat Region is set to Duplicates, one can edit the Sort/Find/Item values in the table. Unfortunately parameters cannot be created from the table, but it's easy enough from the model tree.
The Repeat Region can be filtered to exclude items without a Sort/Find/Item parameter, or a special value can be used to distinguish rows that should be excluded.
The possibilities aren't endless, but there are enough of them to be very useful.
Another day, another 'Feature'
I was making some electrical cable models. Fun stuff. Basically abusing sweeps to simulate wires going into connectors. So I set up some axes on the connector terminals, some datum points offset to steer the splines into the terminals and some mid-way points to straighten the splines to fit into a cable sheath. Works great. At first. I create all the features and then sweep to create the wire. Then group the bunch so I only have one copy/paste-advanced. Just pick matching terminal surfaces and the second one goes in. This works great for a while, but then I hit the wall. Creo discovers it's favorite trick, and mine - Cannot Intersect Model. What it really means is that the algorithm for determining intersections between the new geometry and existing geometry has failed, even though the geometry definitely does intersect. I can even see it intersecting in the preview. Whatever.
The punch in the gut is that because this last step has failed, the entire paste fails. Creo could let me suppress that last Sweep feature so I can poke around at changing the locations of the intermediate points to a place where Creo can find a solution to it's problem, but the actual options are to Delete the Sweep or cancel the entire paste operation.
Of interest is that if I suppress the Sweep in the group and copy the Group, it excludes the suppressed member, rather than copying it in the suppressed state. But I can independently Resume the Sweep, Copy/Paste Advanced and pick the Spline and then re-group the separate sweep with the originally Copied Group.
Update: One thing I found surprising was that sometimes reversing the end of the trajectory the sweep starts from will sometimes allow a solid feature to be created when starting at the default end causes the feature to fail.
Sizing things up
I have a fun situation. Many parts in an assembly have been moved from being in inches to millimeters. Hurray. So I change the units from inches to mm, and tell it to convert the dimensions. This part works ok. 1 inch long parts are now 25.4mm long parts.
Where it fails is in the retrieval of the next assemblies. It's like PTC helpfully builds a separate scaling value into the assembly to account for the difference in units between the assembly units and the component units. Why does it get saved? Why is it not dynamic upon opening the component? In any case I have parts that pop up as 25.4 times life size while the assembly is being opened. After the assembly is opened it gets sorted out, but while opening it looks like a disfigured mutant.
This is in Creo 2, but I've had this happen before, in WF5 and the assembly failed to ever update. In fact I could assemble an item a second time and it was at a different scale. Side by side, two different sizes for the exact same part. If there was some control in Creo to do that when I wanted it would be a feature. In this case it's a bug that makes Creo look sloppily made.
Sorting things out
I am still working on the non-family tables (formerly family tables, now exploded) and came across a noticeable annoyance. When humans use non-alphanumeric characters to separate segments of a piece of text they expect that each sub-segment stands alone, but that is not the way CS grads see it. They have the notion that all are of equal significance and move along without distinction.
What would be nice is if the the segments were considered in the sorting. Sorted that way the dash numbers would match the order in the part drawing. Does anyone really like 1, 11, ... 19, 2, 20, ... 29, 3, 30, ...?
Curiouser and Curiouser
I am working with parts that were burst from a family table. This poses a problem in maintaining commonality among the parameters in the parts. Since their creation there have been changes in what parameters should be in parts and the format for their values. In addition, the problem of making sure the defining drawing changes are certainly reflected in the parts it represents is of interest. To counter this I created an assembly of the parts that used to be in the family table. Being as lazy about this as possible, because there is no geometric value in this specialized assembly, I just let Creo drop the parts in and select 'Done' to leave them all packaged.
What is curious is that the distance between the parts (just washers or screws or nuts) expands with each item added to the assembly to the point that where they start one diameter apart and end up 50 or 60 apart. So far apart that after 20 or 30 parts, zooming out to see the whole means the components are too small to see and the OpenGL routines just cull them completely.
The other part of this that is interesting is the Repeat Region in the drawing. I understand that if there is no parameter in a part there is no way to show the related nonexistent-value, though it would be nice to have some indicator that differentiates between the lack of a value and a null value. If the parameter exists but the value is null, then the value of the parameter cannot be updated by changing the value of the cell in the repeat region. If the value is even a single space it can be edited, but if null - no go.
I do realize that I could use a repeat region relation to flag missing parameters, but that would mean adding a separate visible indicator on the table; if it was in-line with the parameter values, the relation prevents altering the value of the model parameter.
The final advantage to the family (not table) assembly is that all the parts need to be promoted simultaneously and it is easy to select the assembly, expand the structure and select all, then Promote. I wish the same was true for creating new Revisions. There were almost 100 parts in one of them and it brings me to tears to grab them one at a time for a new Revision.
The Trouble with Decals
I like decals. They can save a lot of time when they can substitute a picture for a lot of geometry. However, the interface to place them, at least through Creo 2, is still painful.
Most painful is the difficulty in updating the decal. It is preferable to keep the same bitmap name for image editing and book-keeping purposes, but Creo won't load a new version of the bitmap if it keeps the same name. Creo allows the user to delete a decal from the Appearance, select the new version of the bitmap, and then Creo ignores the new selection and reuses the old, deleted one.
On a related note, a co-worker is not too smart. We all have them, right? He used Powerpoint to add an object to a drawing that is roughly aligned to a part and is intended to represent a name plate. But the name plate part had some datum curves to represent the printing on the plate. The thing is, it looks OK in the drawing in Creo, but Creo Save-As -> Export -> PDF screws this up and does not clip the vector output from the datum curves where it lies behind the Powerpoint OLE object. Being the smart guy he is, he put those curves on a layer and blanked them in the drawing. Just kidding. He suppressed them in the model to remove them in the drawing.
Model tree expansion
The model tree is a list that typically contains several sublists. For example, in an assembly each component will be on the main list. But each component also has a list of placement constraints and a list of sub-parts or features. This can go for a large number of levels. Mixed in with the component lists are Groups.
Unfortunately there are limited tools for dealing with these lists. For example, it would be a nice thing to be able to expand -only- the Groups defined in the top level assembly, to expose the components that are directly part of the assembly. However there is no method for doing this besides individually selecting the groups, negating the convenience of using groups.
Selecting Expand All results in a veritable explosion in the model tree, expanding subassemblies and so on to the bottom-most levels. Collapse all results in only the top item, and there is little use to that.
Why not: Expand Level and Collapse Level in addition to Expand All and have Collapse All reduce to the base level one sees on opening the assembly? And have these as fixed buttons at the top of the tree, rather than pulling down menus?
A use I made today of the expanded model tree was to locate all the components that a user had applied the Fix constraint to, rather than just correcting missing references. I don't mind 'Fix,' but in this case it was used in a way that guarantees problems in the future, instead of making a couple of placement selections.
Why are formats not embedded?
Is there ever a reason that a format for a drawing should be automatically be changed by changing the .frm file? I mean, it's not like the tables on the changed format update the drawing - nope those are just copied the first time the format is used.
I ask because, in the old days, when a drawing was made, the format was an inseparable part of the drawing - often it was a pre-printed part of the drawing. And it didn't get changed.
I get that it is nice to be able to update the format, and there's a function for that. Instead I see a bunch of drawings done over a period of time suffering from differing opinions about where the borders should be. This means that when opening an old drawing to update it, (if it can be found) the new border is used, but the old tables don't line up with them. Since the tables are an all-or-nothing selection, there's not an automatic function to move the non-parameterized data from tables that were originally on the drawing to the new tables that will replace then. Instead the new tables typically almost overlap the old ones, if retained, making a mess of the working environment. If the format can't be found, then the border is simply missing. Makes me wish for the days of paper and mylar (but not linen.)
I want to get off the grid.
I needed to change a format, but the tools available to sketch with in the Format mode are pretty terrible. So I set a grid to snap to and set the Format mode preference to snap to the grid. That was OK, a workaround, but OK. Then I went on to other things, like changing table cell widths, which caused the table origin to move. That was a pain also.
However, then I went to fix some parts, in particular sketches for features within parts. Suddenly I could not place any sketch feature where I wanted it to go. The preview of the selection spot would jump seemingly randomly around the screen, as if - as if I turned on snap-to-grid in Sketcher.
No doubt someone will be bursting to tell me there is a toggle for snap-to-grid in Sketcher, but it wasn't under Grid and I soon tired of looking for it. If there is such a thing keep it to yourself. I intend to spend however long it takes to search the entire interface to see where that Sketcher grid-snap toggle is hiding. (Update: Found it. Creo Help says "Tools->Environment" but it does not apply to Creo. File->Options->Sketcher leads to options, most of which are in the Ribbon, but not one that is most likely to need to be toggled. But why does a Drawing Mode setting change a Sketcher Mode setting?)
An aside - I would like to know why the table origin doesn't stay fixed in Format mode. When I changed the width of a cell on the left side, it seemed to affect the right side margin. When I changed the width of a cell on the right, it moved the left margin.
OTOH, perhaps it was frustration with the tables on the format. For some reason a cell-based table that was effectively 6 cells wide was made up 15 cells with various combinations of cell-merge going on. I guess that the table has been worked and worked and worked, but never fixed.
What's wrong with CSV and drawing tables? (Creo 2. Maybe it is fixed in Creo 3 or is planned to be fixed in Creo 4 or 5)
I select Save as CSV for a table, and Creo creates a file, but it's not exactly what I want. In fact it's just a little more than I want. It includes a numeric suffix, which means that Excel, the primary target for a CSV file, doesn't see it as a CSV file, and since Creo install registers the low number suffixes as Creo files, double clicking tries to fire up not-Excel. So I have to go to the OS, find and open the folder the file is in, then rename the file to remove the unwanted suffix to convert it from a .1 file to a .csv file, and Windows gets to stop my work to prompt me that changing the suffix may prevent the file from being found correctly.
The part that's odd is that it's (thankfully!) not symmetric, so creating a table from a CSV file doesn't require the numeric suffix.
Perhaps I could open it as a text file (maybe?) but then I have to select the format for the separator and decide the column types, and so on instead of double-click and open or just open CSV type files.
Unfortunately, my earlier suggestion for fixing this is not usable because AutoIT is not allowed by the customer. But here this is:Saving table as CSV without the .# extention(topic title misspelled by original poster.)
What's the common name?
I looked for, but did not find, a way to display the WC Common name in the model tree. I suppose the same is true for the WC Number. I would think that making the Common name and the Number easily visible to the user would be a good idea.
As pointed out below, the answer is to not expect help from the interface, but to note that it is an invisible model parameter 'ptc_common_name' which must be manually entered.
Where did the sketched spline curvature dimension go?
I was looking at some old Pro/E tips and found one that indicated that in 2000i or so one could select the end of a spline in a sketch and select the end vertex and then right button to add a curvature dimension. Now, in Creo2 it tells me it can't create that type of dimension, but if I convert the spline to be polygon controlled it tells me that it can't create a curvature dimension for a polygon controlled spline. So it's like Creo could create the dimension, but it is programmed not to.
I guess they got rid of it because its main function was to match curvature with arcs, but I suppose the tangent control does that automatically. Too bad that's not the only function for it.
It is still there, but only for splines with a tangent constraint at the desired vertex. Searching for help on Spline produced the entry at suggestion 79, which was far beyond my willingness to look. It followed a bunch of entries on 2D interface consideration and wasn't linked to any of the entries on creating or modifying a spline.
Word Wrap table fail
I tried word wrap in table cells on the off chance that it would be easier to extract text from an exported PDF. But what I got was disappointment. The text did wrap, but the center justification still took the space characters as printable characters, forcing the results to be not center justified. Plus, one of the cells was a bit narrow and it word-wrapped a letter off by itself. So I guess I'm back to removing spaces and adding carriage returns, just like always; at least like 1990s word processors anyways.
What else is wrong?
I get the Stop sign from Windchill Event manager in the Creo session. When I look at the Event monitor, there are no errors listed. False alarms are so nice in a busy work schedule.
What's wrong?
I get a message a lot - one that tells me that Creo is unable to write something somewhere. It's always nice to have meaningful error messages. It would probably take a second to fix, but Creo leaves me in the dark. It's too hard to write "Unable to open filename.ext in drive/folder/et al. because [destination doesn't exist | user has insufficient permission]"
Simplified again.
At least for the version of Creo 2 I am using, the last user defined simplified rep is placed after the default simplified reps - below Master, Geometry, Symbolic. I finally clued to the fact that it's always the last named one and just made an empty rep called "Z_Z" to plug that hole and keep the reps in the rational order.
How simple
I started to create a simplified rep. I typed the name and then selected Edit. It let me make a number of selections and I switched back to the names dialog. I tried to close the Simplified rep box, but it would not let me - the text cursor was still next to the name. So I clicked next to the name and hit 'Enter' and Creo created the new simplified rep, but not before throwing away the changes I had made.
Layer it on.
I wanted to put some temporary drawing symbols on a layer - they are used to mark locations of revision changes. So I select New Layer and pick the symbols on the sheet, then I pick the next sheet. The new layer box disappears and with it the items I selected. Poof. Gone. So I start over. Create the layer, save the layer, open the layer again, put an item on the layer, save the layer, select next sheet, open the layer, pick an item, save the layer, select the next sheet ... So two more picks per sheet to avoid the pie in the face from the GUI principal that select-sheet == Cancel. Who wrote the spec to cancel layers on sheet changes when it doesn't cancel other functions?
Then I wanted to be sure the next user would see the layer. For some reason this assembly has 5 different names for each type of geometry because no reason. I see that the first layer on the list is "1" and rename the layer "0_Revision_symbols" It should be just before "1", but it isn't. It is down the list after a pile of "01_"... I have to rename it to "000_Revision_symbols" to get it near the top of the list, but it still can't end up before "1" because name length is more important than character precedence.
Not a core PTC problem, but this business of putting items on layers based on type is ridiculous. The items already have a type and can already be selected and operated on by type. There is some slight reason for some things to be on layers, but only when all items of the type will always get the same treatment making re-selecting a time cost.
Instead it's better to place them on layers according to function. If a bunch of geometry is to serve as the basis for other features, then it is construction geometry; use the Construction layer. If a feature is a pipe feature then it needs to go on a pipe_centerline layer to allow controlling the visibility of the pipe centerline, which has (afaik) no other visibility control. And the top item - SHOWN DATUMS. With no other control to turn them off when they are not appropriate (that is, outside of the part or assembly level where they are defined) layers is the only sure way to shut off these pustules of datum junkiness.
Zoooom!
I am working on a drawing and select zoom to fit. It sure does fit - it's about 50% the size of the available screen area. If I select Windowed zoom and carefully select the border extents, it sometimes gets smaller. Unlike all other computer graphics software I have ever used, Detail allows the image to get -smaller- when zooming in. It should scale the selected area to fit either the height or the width of the graphics view port, which ever comes first, like all other computer graphics software does.
Can't use negative increments in Explode editor
I tried - typed in a negative number and as soon as I hit 'Enter' the minus sign was stolen away. Result was still the same, a value that is an integer multiple of the offset from zero in the positive direction.
Explode down the rabbit hole - update
Just after I posted it dawned on me what is happening. When going backwards from a position, Creo is actually counting forward. When I divided the resulting angle (the value I did not want) by the increment it was a whole multiple from zero. I don't know why anyone would create a function that works like this - a single step in one direction = desired angle; steps in the opposite direction = floor or ceil((360-n*desired angle)/desired angle) * desired angle. (fixed the formula, though even this isn't as weird as it appears to work)
When I changed the increment to 360-(desired angle) and used that it clicked into the desired position. I'm pretty sure I tried a negative increment, but will have to check again to be sure about whether it works. I know for certain the increment requester is limited to 2 places for angles which is an irritant as well. If the transformation matrix is not double precision then that might explain the errors I see in generating explode lines.
Which brings me to another, continuous irritant - being unable to control the sense of the angle.
The angle reference I chose was an axis, and an axis should have a direction vector associated with it, so that I could define the positive, right-hand-rule direction.
Update fake-out
I open an embedded browser to my local workspace cache and see a number of items are out of date. So I select them all and select 'Update' and change the option to force download. When it completes, the embedded browser shows a small number of items that are out-of-date. But I've seen this before and know that it just isn't true and to update the out-of-date status indicators, I have to Synchronize to get the local listing to be correct. In past encounters I selected the items marked with out-of-date indicators that remain, picked Update and was told nothing qualified for update.
Explode down the rabbit hole
I had a view of an assembly in a certain configuration. Part of that configuration has a door that has to be open to a particular angle, which should be easy, right? So I measure the angle between where the door is and where it should be, then fire up the Explode state editor. I pick rotation as the movement type, pick the hinge axis as the rotation reference, and then I plug in the angle into the 'increment' option. I grab the door and move it one increment and it's in the wrong place, by a lot. I wanted 30.35 degrees and get around 25 something, 4.15 degrees short. I then tried using that as the increment and the increment ends up more than 1 degree short. I reset this all and tried again. I then look at the indicator at the top of the screen that shows the angle doesn't change by the increment given, but by a different, smaller amount. What's really odd is that when I changed the increment from 30 something to 1 and moved it one degree at a time, when the indicator showed it had moved 30 degrees, the door was close to where it was supposed to be. Change the increment to .5 and it's closer.
I can spend more time debugging the explode software tomorrow. Solved - see Update above.
Moving views and details
I get that a view needs a place to be and that the center of the view as established by the 'extents' is a good place to start, but since views change extents based on changes to their related model, this creates the appearance that the part/assembly wanders about the drawing. So it is good that the view origin can be changed to be a point on the model, effectively a push-pin to stop the geometry from wandering about, but it would be nice if it was the default and would prompt during view placement.
However, any draft entities placed relative to a view are still subject to the view extents. And this is a problem because it affects things that are difficult to fix (as in film, not as repair)
For example, if an axis is shown in an exploded non-orthographic view it is possible to grab the axis drag handles to simulate an explode line, but if the extents change, so do the locations of the drag handles, even if the underlying related geometry doesn't change. And this change is not proportional to the change in extents, it can cause a radical change causing the axis to appear distant from the intended location.
Otherwise, things like symbols and notes with leaders also wander off; if the view expands, they end up far away. If the view extents contract, they can end up overlapping geometry, concealing them. In either case, it is most often the wrong thing to do. But for some reason it was decided that rather than offsetting along a fixed vector from the view origin, they are located along that direction, but as a ratio to the extents, which is not how people place such things. That is, I don't pick a spot and say that it represents 114% of the diagonal distance across corners of the extents as projected onto the view. Instead I pick a spot on the drawing that's a fixed distance; emphasis on fixed.
Save-As PDF Exports wrong
I have a drawing where some lines are sketched in to represent cables and wires. Some of the actual cables pass under objects and to simulate them as hidden lines they were given a dashed font. When I use Print->Generic Postscript, the dashes on the output look exactly like the dashes on the screen, which is fine. When I use Save-As PDF and Export the drawing, a different dash spacing is used - one so large that it isn't clear the splines are dashed as much as distantly separated unrelated segments. I tried the 'use_software_linefonts' - no difference. And the dash line scale option - no difference, the Export output is still defective.
Can all the features work. Together. At the same time. All the time?
I have a model of a strip hinge that's built as an assembly. To get the right length there's an assembly cut. Rather than having multiple users figure out how to create this cut (people forget that the cut needs to handle the hinge movement) this cut length is set as a flexible item, and so is the hinge open angle. Turns out only the angle is flexible and that interferes with the assembly cut.
But it turns out in the next assembly where these two values are where this angle is used to regenerate the installed hinge, that the regeneration code often skips over the cut. I can open the hinge, hit regen, and the cut doesn't happen. But when I move the insert point in the immediate assembly above the hinge and then cancel the insert, the assembly cut is correctly regenerated.
This little part sits about 5 levels of assembly down, so I'll need to add a note outside the drawing border that says if the hinge doesn't regen right, just jiggle the (insert) handle.
Just a moment ...
I was removing some ghost objects from a drawing today. There's a hidden config item to tell Creo to disconnect non-existent items when the drawing is opened from outside a Workspace and the first step is backing up the drawing to the file system. So I do the Save-As Backup and motor over to the desired location and then select the Save button. I then switch over to the Explorer window to see the files show up. And they don't. Why? Because after working for a few moments, Creo stops to inform me that some part needs to be given a density so that it's mass properties can be calculated. I'm making a back-up outside Windchill, so there is nothing that cares what the density is. So I click the green button and it waits a while and then stops again for another part.
I have only one task in mind. Backing up the drawing, and then deleting -all- the files that aren't the drawing, so when I re-open the drawing, the secret option will cause Creo to delete the ghost references. Creo programmers think that instead of doing this regeneration when the files are first retrieved or skipping it altogether, that interrupting an annoying task that should be a one-click selection (File->Delete Incomplete References) is a great option.
How about this, Creo developers - just before the compiler does the linking, it stops and does a spell check on all the library source files, and stops to prompt Y/N for if it's OK on every word that's not in the dictionary and won't finish the compile until the programmer has responded. That's what it feels like.
Ghost Items.
I worked on a drawing, saved it and found the Workspace filled with ghosts. Where did they come from? Well, a number of them seemingly showed up because of the assembly mode Replace function. It seems that software developers want to make the CAD system do the work of the PDM system and remember what used to be in an assembly, by default. This leaves references to parts that aren't used anymore, but because they aren't used any more they don't get checked-in/out. Thanks software developers. Made a 10 minute change take about an hour. There's a button to turn remembering off, but by default it remembers so the PDM system can have bunches of ghost objects to deal with.
The other thing that's a great deal of fun is that I can't just search for these references from the Reference Viewer; instead I have to manually scroll through hundreds of parts. And when I find and delete the reference, the Reference Viewer resets the position back to the top, so I have to scroll and scroll and scroll to get back to where I was looking for the next one. But i can't use the reference viewer with a drawing. Even though drawings can maintain references to parts that used to be there (at least that's what Windchill reports when I ask about references in the workspace) I can't see or delete them from the drawing.
Because I can't search for them using the regular Find function, I also have a hard time finding ones in subassemblies. The Reference Viewer is not much help there. Often it resets the 'top' level to some mid-level assembly and then it's stuck, so traversing the branches is not simple.
I did run across a handy feature - the Red X. Instead of telling me that the part is purposely suppressed and that's why it wasn't retrieved, I have to guess that maybe it wasn't found.
Pen Widths (again)
These are all applied on a per-color-type. That is that certain curve/text elements will be associated with certain pen numbers. Solid geometry edges are always 'white' regardless of actual color, and are associated with pen 1. Draft items and datum curves can be associated to different colors.
Figuring out what the printed width is a process. It all starts with penX_line_weight in the config. By default there are some widths assigned in .005 inch increments, so a weight of 16 is .080 inch wide. These can be over-ridden by specifying a particular width for a particular draft item in a drawing. Pretty sure width can't be applied to solid geometry, but haven't checked.Then comes the pen table. The pen table functions just like real pens. If I told you to draw a 1/4 inch line and gave you a fine-tip ball point, you would draw a fine line. If I set the line width for white (pen1) to .250 and set the pen table to use a .001 line, the line is going to be .001. So the only way around this is to omit the corresponding pen width from the pen table; much as if I'd asked for 1/4 inch line and let you find a magic marker.
If only there were -real- pen plotters in use today, and not raster printers that can provide lines of any width limited only by paper size and laser/inkjet resolution.
The best part is this. When I change the penX_line_weight and don't use a pen table, the line width only changes for Postscript output, not PDF export.
So, for the 40,000th time, Creo should do the following for Postscript:
1) Set the header and footer as -external- files, not baked in to the Creo executable, so that secondary software can fix things
2) Let Postscript scale the output instead of baking the scale and then applying pen widths (ratio of line width to length is not currently preserved)
3) Change the priority so that -assigned- weights have the highest priority instead of fictional pen assignments
4) Change the setlinecap and setlinejoin to rounded for both, like every actual pen and engraver and router is, not the butt and miter which aren't
5) Include the font descriptions in the Postscript output so that Distiller or similar can create searchable PDFs; this means the font 'font' as well as the other PTC plotter fonts.
6) Feel free to include the other PDF directives that are used to generate layers and bookmarks
7) Just generally - I never want a plot that is based on the 'zoom' factor. If I want it I can get Acrobat to do it.
Fun with table cells.
I wanted a little space at the left end of some table cells. Since there's no 'Tab' setting in cells I decided it would work to insert a column and blank the mutual line.I was soon reminded that 'Insert Column' and 'Insert Row' are sticky - choose one of them, insert a row/column, and shift to another tab and it's still stuck trying to insert a column/row. Need to use Ctrl-A to cause it to reset. Then it took a while to find out how to make the 'blank border' button work. Hovering over the inactive button didn't produce instructions on what was missing to activate it. Turns out one has to first select a cell, then Select Table to get the table selected before a border can be blanked. It's like how Move Special can only be applied when an entire table is selected (but if it's applied when two tables are selected only one table moves.)
I also tried to display the symbolic name of a dimension in a view, and the value of the dimension in a cell in a table as part of documenting how a template part worked so the user could see them both at the same time. No go. It seems if a dimension is in a note or a cell, it copies the displayed condition for the dimension. Of some use is that the first time a dimension is put in a note the dimension is removed from the drawing. The second time it's in a note, the first note is unchanged. If one of the notes is deleted the dimension is restored and the other note remains; I was just hoping it kept the current display status and tried switching from &D to &S between the first and second cells.
Embedding a spreadsheet
I Inserted an Excel spreadsheet object into a drawing. But if I 'Open' it that's it. Help says that I should select "Close and Return" but that entry is not part of the Excel menu. If I select "Close" from Excel the image still appears on the drawing, but it can no longer be edited. Creo complains the OLE object can't be found. Not that it matters, as it is embedded as a bitmap. When creating a PDF via Save-As/Export, the compression is of low quality.
Copying and pasting patterned features.
It seemed to work pretty well, but then failed to produce the expected results. It turns out that when a pattern is copied that has pattern relations in it, the relations are not copied.
Can't reroute dimensions for features that are patterned.
Even though the direction of the dimension would be the same, it's necessary to unwind all pattern references to re-define a feature reference. Of course Creo will let a user redefine a patterned feature and, after the effort goes into that, spring the message "Pattern will be deleted." Which is what the user was trying to avoid.
Detailed views
Sometimes 'Fill' works and sometimes it doesn't.
One thing that doesn't work is if the parent view has fill, the detail will probably not use it; instead the filled areas will be blank, just like one would not expect.
What does work is cranking down the hatch spacing until the lines are closer together than the pixels are, which means even a solid appearing hatch in the main view will have gaps in the detail.
Move to sheet
This is a wonderful trap to have on the detail menu. If there is only one sheet Creo automatically creates a new sheet, unasked, and moves the item to that sheet. Since the number of times I want this to happen -ever- I can count on one hand, there is no reason to place it on the fast access, and easily mis-clicked pop-up menu, where it has caused multiple instances of frustration.
Set Datums
An oldie but a goodie. Someone working on a component decides to 'Set Datum' and 5 assembly levels up, the top level 15 sheet drawing that takes a minute per-sheet to regen now requires going over with a fine toothed comb to manually blank each and every 'datum' that pops up. Nothing like time wasted due to the auto-appearance feature that Shown Datums have.