The community will undergo maintenance on October 16th at 10:00 PM PDT and will be unavailable for up to one hour.
I have a really weird bug that maybe someone can help me with. I have been using ProE since ProE2001, so I know the program well. but I haven't seen this before.
On sheet 1 of my drawing, the BOM table appears to be missing my second part in my assembly. But when I click on the table cell, the data is still there. It comes back once I right click each one, and middle click to accept. If I change sheets and come back, second part row goes blank again. If I print or save to PDF, the tables print empty.
Same thing happens with the drawing block on Sheet 2. Except it's true for the entire title block. Every single cell in the block is empty, unless I click and accept each one. If I change sheets and come back, it goes blank again. If I print or save to PDF, the tables print empty unless the text appears on the screen.
HELP please.... anyone know what's going on and how to fix it?
-Fong
Solved! Go to Solution.
Generally speaking, 'update_drawing all' is a good thing, in that any future change in behavior is from one deemed buggy to a fixed version. However, it does mean that you need to inspect your drawing to be sure that any immediate change is as desired. For example, if there was once a bug that caused (say) a note leader to disappear when it shouldn't, and afterwards you had added a new leader, then updating to the fix could cause the first leader to show, and now you have two, and would want to pick one to keep. This work of inspection may be too cumbersome, either in itself or satisfying your company protocols on approving changes to the drawing. But future changes will generally be all for the good.
Hi Liu,
I was facing similar kind of issue with BOM Ballooning, which used to disappear.
When I added the config option “update_drawing all” in detailing options, this issue gets resolved. But we have to always add this config at every new session of Creo.
Another thing you can try out is Prepare & save the template BOM tables (especially repeat regions) in a .frm file and then use them. This is because when you create the BOM templates in a drw file, some feature IDs gets added with the the BOM Parameters, which are also responsible for vanishing kind of issues.
If you need any more details please let me know.
Thanks,
Sachin
Just want to mention that using the "update_drawing all" as a standard method in your drawing is probably not a good thing. What it does is apply every known bug-fix available into your drawing. It is impossible to see any future consequences from doing his.
What you -can- say however is that there probably -was/is- a bug, as your drawing actually is fixed by this action. You should contact PTC support (or do some serious digging) to find the actual bug you suffer from. Typical use would then be "update_drawing <SPR-Number>".
Generally speaking, 'update_drawing all' is a good thing, in that any future change in behavior is from one deemed buggy to a fixed version. However, it does mean that you need to inspect your drawing to be sure that any immediate change is as desired. For example, if there was once a bug that caused (say) a note leader to disappear when it shouldn't, and afterwards you had added a new leader, then updating to the fix could cause the first leader to show, and now you have two, and would want to pick one to keep. This work of inspection may be too cumbersome, either in itself or satisfying your company protocols on approving changes to the drawing. But future changes will generally be all for the good.
Had the same problem until I removed Repeat region from those cells
There might be something else going on, but the first thing I would check is whether you have a blanked layer that includes these notes (including the case where they are on a layer and some other layer is isolated).
Thank you, your answer solved my problem.
I have a layer called "note", which includes all the text inside my table. When I hide all layers, the text also disappear and I didn't know it was because of the note layers.
Thank you so much.
I had something similar in an early datecode of Creo 3 (M020 maybe?). The problem disappeared when changing datecode to M040/M050. Try it if you haven't already.
We had a similar issue with Creo 4.0 M040. It was corrected in Creo 4.0 M060. See CS282069.
It was a layer issue with my drawing.Might wanna check the layers on the drawing. Solved the issue in my case as I was having the exact same problem.