Drawing Program Master

[MGleason_1983]

Using Creo 9.0.1.0

I have a drawing program watching the state in Windchill (InWork, Under Review, Released, etc) as the state changes the drawing program updates a parameter with a message displayed on the border of the title block (“InWork - not for production use”)

I need to update that program to include a new state with a new message. Right now the drawing program is unique to each drawing file. Is there a setting to reference a file that can be updated in a single location? Or any way to make a bulk update using a script Creo|SON or anything other than opening each file every time a program update is needed?

[Michael]

Updating a drawing program for multiple Creo Parametric files to reflect a new state in Windchill can indeed be a challenging task, especially if you want to avoid manually editing each file. Here are some potential solutions to streamline the process:

1. **External Reference File**:
- Instead of embedding the logic directly into each drawing, consider using an external text file or a similar resource that the drawing program reads from. This file would contain the necessary parameters or states.
- Update the drawing program in each file to read this external file. This way, when you need to change the message or add a new state, you only need to update this external file.

2. **Creo Parametric Toolkit (Creo|TK) or J-Link**:
- Utilize Creo's Toolkit API or J-Link, which are powerful for automation tasks. You can write a script that iteratively opens each drawing, updates the program with the new state, and then saves the file.
- This approach is more technical but can save a considerable amount of time, especially if you have a large number of files to update.

3. **ModelCHECK**:
- Creo's ModelCHECK utility can be used to automate the process of updating parameters across multiple files.
- You can configure ModelCHECK to update the drawing parameters based on certain criteria or states.

4. **Windchill Workflows**:
- If the state changes are managed in Windchill, consider integrating this update process into your Windchill workflows.
- Customizing the workflow to trigger a script or an action when a state change occurs might help automate the parameter update in the Creo files.

5. **Batch Processing Script**:
- A custom batch processing script outside of Creo, possibly using Python or a similar language, could interact with the Creo files, updating the necessary parameters. This requires a good understanding of Creo file structures and might involve some trial and error.

6. **Centralized Drawing Template**:
- If feasible, modify your process to use a centralized drawing template that includes this program. All new drawings would inherit this template, ensuring consistency and ease of updates in the future.

Each of these methods has its pros and cons, and the best choice depends on your specific environment, the number of files you need to update, your familiarity with scripting, and the integration level with Windchill. If you provide more specific details about your current setup or constraints, I can offer more targeted advice.

[MGleason_1983]

Michael,

Thanks for the reply; your content on LinkedIn is always super interesting.

Thanks for the feedback. We are using drawing templates already, so that is an easy update that will continue with new objects from now on.

I have looked all over the documentation for an **External Reference File** example of being used in the context of a drawing program, and I can't find anything. I have been through all the options within the drawing.dtl and config files to see if there was a way to reference an external file, and I can't seem to find anything. Is there a syntax within the drawing program file that can be used to reference an external file?

If you have any examples of how to use any of the other options, that would be super helpful. Below is a copy of the drawing program I have been using for you to see what we are doing. The program works great, I wish I had a way to update it without manually opening each file.

IF PTC_WM_LIFECYCLE_STATE:D == "In Work"
STATE_MESSAGE:D = "NOT FOR PRODUCTION USE"
DRW_REV:D = PTC_WM_VERSION:D
ENDIF
IF PTC_WM_LIFECYCLE_STATE:D == "Prototype"
STATE_MESSAGE:D = "PROTOTYPE USE ONLY"
DRW_REV:D = PTC_WM_REVISION:D
ENDIF
IF PTC_WM_LIFECYCLE_STATE:D == "Production Change"
STATE_MESSAGE:D = "UNDERGOING CHANGE - NOT FOR PRODUCTION USE"
DRW_REV:D = PTC_WM_VERSION:D
ENDIF
IF PTC_WM_LIFECYCLE_STATE:D == "Preproduction"
STATE_MESSAGE:D = "PRE-PRODUCTION USE ONLY"
DRW_REV:D = PTC_WM_REVISION:D
ENDIF
IF PTC_WM_LIFECYCLE_STATE:D == "Released"
STATE_MESSAGE:D = "RELEASED FOR PRODUCTION USE"
DRW_REV:D = PTC_WM_REVISION:D
ENDIF
IF PTC_WM_LIFECYCLE_STATE:D == "Under Review"
STATE_MESSAGE:D = "UNDER REVIEW - NOT FOR PRODUCTION USE"
DRW_REV:D = PTC_WM_VERSION:D
ENDIF
IF PTC_WM_LIFECYCLE_STATE:D == "Obsolete"
STATE_MESSAGE:D = "OBSOLETE"
DRW_REV:D = PTC_WM_REVISION:D
ENDIF
IF PTC_WM_LIFECYCLE_STATE:D == "Locked"
STATE_MESSAGE:D = "LOCKED"
DRW_REV:D = PTC_WM_VERSION:D
ENDIF

CB_NL1:D = search(PTC_WM_CREATED_BY:D," ")+1
CB_NL2:D = search(PTC_WM_CREATED_BY:D,"(")-1
CB_NL3:D = CB_NL2:D - CB_NL1:D
CB_FIRST_INITIAL:D = extract(PTC_WM_CREATED_BY:D,1,1)
CB_LAST_NAME:D = extract(PTC_WM_CREATED_BY:D,CB_NL1:D,CB_NL3:D)
CREATED_BY:D = CB_FIRST_INITIAL:D+"."+CB_LAST_NAME:D

MB_NL1:D = search(PTC_WM_MODIFIED_BY:D," ")+1
MB_NL2:D = search(PTC_WM_MODIFIED_BY:D,"(")-1
MB_NL3:D = MB_NL2:D - MB_NL1:D
MB_FIRST_INITIAL:D = extract(PTC_WM_MODIFIED_BY:D,1,1)
MB_LAST_NAME:D = extract(PTC_WM_MODIFIED_BY:D,MB_NL1:D,MB_NL3:D)
MODIFIED_BY:D = MB_FIRST_INITIAL:D+"."+MB_LAST_NAME:D

[Chris3]

We did this for a while. We had a 1 cell repeat region in which we had some relations not unlike what is posted above which checked the state of the component and then changed the revision text to be what we wanted. It worked ok except for when there were multiple parts added to a drawing. In those cases the relations would pull the state from the wrong session component. In some cases we had the right parameter on SH1 but then the wrong parameter on SH2. It became a mess and we reverted back to just using the PTC_WM_LIFECYCLE_STATE parameter for the drawing. The drawing should update on a republish without you manually having to open it.

[MGleason_1983]

Chris,

You are correct, the boarder messaging I have driven by PTC_WM_LIFECYCLE_STATE updates perfectly on the Windchill state change without having to manually reopen it. The drawing publishing is not the issue. The issue is that the Drawing Program appears to be static to the unique .Drw file and cannot use an external reference file or be updated in a bulk way. There are similarities between the Drawing Program and ProProgram, but they are not the same, the Drawing Program appears to be more limited. For instance you are limited to 80 characters per row for some reason. I originally had a simpler program but I had a few rows that exceeded the 80 characters limit and the code was truncated.

zero complaints about the functionality once I got it figured out, but I would like to be able to push an update out to these files without having to manually open each one to edit the Drawing Program.

[Chris3]

In general the concept of something being "static" IE not updating without opening the Creo file is baked into the logic of configuration control. If you save or release a drawing in general you don't want modifications to that unless there is a way to create a record of that change.

External references aside, I can't think of a part of the program that reaches out to an external data source without having to click something in the user interface and resave the drawing.

You could certainly automate this with a mapkey, trail file or one of the APIs.

It is true that there is a 80 character limit:

https://www.ptc.com/en/support/article/CS34738 

[MGleason_1983]

I have a semi functional mapkey, but it stops working once the file edit screen pops up. From there I have to manually browse to the text file I have with the latest program, copy the text and paste it into the edit screen. If I could figure out how to automate that part of the process it would still be annoying, but semi bearable. Right now it takes me about 45 seconds to check-out a drawing, update the program, regenerate, save, and check-in. As you pointed out, due to these files being in controlled states I have to do these updates as an admin and then republish the viewable. Not something that can be done by just any user.

[YaroslavSin]

Take a look at About Table-restricted Parameters 

I think this will can solve your main goal to load params value from an external file.

But, updating of this parameters has some trouble too. And need to opening drawings in case of batch updates.

[Chris3]

Table restricted parameters still need to be updated from the UI

[MGleason_1983]

YaroslavSin,

This is super interesting, I haven’t tried this approach but will explore this a bit today. Thanks for the suggestion!

[Chris3]

You need to paste in the entire path to the file name in the file open box. IE: C:\Folder\SubFolder\File.txt

Then the path will be recorded in the mapkey and you can automate it completely.

[MGleason_1983]

Chris,

Thanks for the suggestion, I’ll give this a try.

[RPN · Accepted solution]

You need to to have an event fired after opening a drawing. This will check the version of you drawing program. If this is not matching you need to have a predefined mapkey, because toolkit does NOT support this kind of a feature. Every user should have the DLL loaded, and you can drive this completely by env variables. So nothing must be hardcoded in the c program. On top I would use a custom parameter, where you see that the drawing is from you company. 

The logic is only, if the saved version does not match the current version, run the mapkey and update the saved version (external data or a drawing parameter). And do nothing if one env param is missing.

You need minimum this 2 env vars, set in any client psf. Like this:

• CUST_CREO_DRAWING_PROGRAM_VERSION=1
  • The current version of your program (keep it simple use an int value)
• CUST_CREO_DRAWING_PROGRAM_MAPKEY=_xx_udp
  • the mapkey to be fired, use %_xx_udp; ( _xx_udp is predefined in your config.pro, update drawing program)

If every user load this simple DLL, you drawing program can be update on every machine where a user has setup this simple env. I even guess for a worker, but for this I’m not sure, because I guess no menu is picked.

Now you need only to ask someone in your team to write the code 🙂 (less than 200 lines) with some tests 1 Day of work. For a guru 45 min for the code 🙂 For me about 2 hours to make it save.

Table restricted Parameter are NOT dynamically updated on open, For me this is a semi, not so hot feature 😩

[MGleason_1983]

 Thank you for all your suggestions. Several were very helpful and eye-opening to additional Creo capabilities.

 To follow up, I realized that the mapkey functionality was not working due to the drawing program being edited in a text editor outside of Creo. Once that application popped up, the mapkey could not continue recording outside of the Creo environment. The Edit Program menu has the option to insert and delete lines. Using these options, I was able to create a mapkey that would remove all the existing lines and replace them with the updated program. This is still not my favorite solution, but I'm now at least able to share that mapkey with our team of engineers from a single source. I'm still considering RPN's suggestion at the bottom of using a DLL to automatically run the mapkey as needed. I wish there were an easier way to manage the program with an external reference file, but I agree with one of the earlier comments that this could potentially violate the integrity of released content. I've shared the mapkey in the attachments in case you're interested. This obviously works in combination with various parameters within our template.

You are all very talented and experienced PTC users, wanted to share another topic with you that I would like your feedback on or support to elevate the need for this feature within Windchill ProjectLink. Revise from ProjectLink back to PDM If you feel the need is there please vote. If you feel there is a better approach, please share your thoughts.

Thanks