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 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 out-of-date items 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.
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 - 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 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 a solid appearing hatch 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 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.