Design and Manufacturing solutions through Digital Prototyping and Interoperability

PLM 360 | Scripting Efficiency Tip

While developing the multi-discipline management profile in Autodesk PLM 360, I have been meticulously been trying to make every mistake possible. Here’s something that might help you as you move into customization.

First there is nothing wrong with the out of the box PLM 360. However if you desire to manage a little differently, then you’ll probably run into scripting. I’s not difficult to pick up, and there are numerous examples to copy and work with.

Building a Bridge

imageThis tip relates to how the PLM 360 database passes information. Each workspace is a collection of various types of data. Unfortunately there is no current method of querying data stored in separate workspace types using scripts. That means that if you are scripting in an Items and BOMs workspace, you cannot query data from the Project workspace. Therefore different workspaces can contain fields with the exact same Field ID, such as ‘CONTROL_ID’ field I have in four different workspaces.

There is however, a clever way to connect workspaces by adding a field with a ‘Linking Picklist’ type. This field then:

  • Displays the information picked
  • Creates an active link that users can  pick in order to jump to the linked workspace data
  • Creates a data tie between the current workspace and the other
  • Adding a Linking Picklist to the Workspace items creates a bridge that scripts can use to jump to the other workspace in order to extract data. What I want to discuss today is being very careful with your setup so that your scripts are as efficient as possible.

Efficient Scripting

I was cascading numbers from one workspace to another different workspace type. I had developed 3 separate scripts that do exactly the same thing. However, I realized why the PLM team used the same exact name for each workspace identifier – ‘NUMBER’. This way, any script designed to perform a task with a workspace identifier, could be used in any workspace.

What I did was go back and start over, and ensure that every new field, similar in function with other workspaces, has the same Field ID. Not the Field name you see labeled, but the Field ID that you don’t.

Then I was able to revise one script to perform exactly the same task in each existing (and potentially future) workspaces.

image

In the example below I got rid of three fields that had very specific names related to this workspace, yet did exactly the same job in other workspaces. By naming them the same across all workspaces, I can simplify scripts, and more easily remember the Field ID conventions.

image

You will notice when adding the fields to workspaces, that the Field ID name gets locked so that it cannot be changed once you create it. The Field names however can be changed as much as you like. When the fields are created, the Field Name, and Field ID are the same. It is recommended that you leave the field name as is until the troubleshooting and tuning is complete. Change these displayed names as a last step in the database cleanup.

In the example below, the Control ID is being built properly by the script now. This number was automatically cascaded in each workspace to develop a [Project]-[Section]-[Group] numbering convention.

image

Also notice the The PARENT display name will be changed to Parent Design Section, or something similarly more descriptive once all the development is complete.

Final Thoughts

I suspect that the PLM 360 database is a series of fields in the database instance, that are only tied by the workspace interface. This gives the user the ultimate creativity at the UI level, and protects the database from being torn up and corrupted. The flipside is the inability to query data collections remote, without a pre-specified link. Even with the link, there are limitations.

I believe that Autodesk is continuing to shape the PLM 360 product in order to make it the best platform for all of its customers. I also expect there to be a rocky road where trying to implement these types of functional improvements in an existing database platform. Autodesk does however surprise me on a regular basis.

In any case, Scott and I will continue to leverage the technology and ask for the obvious things that users need. Keep checking back for more of our management articles.

  • http://beyondplm.com Oleg Shilovitsky

    John, I’ve been experimenting with Bill of Materials in PLM 360 for the last couple of weeks. I stack with the same limitation you nailed down in your post:

    >>>
    I suspect that the PLM 360 database is a series of fields in the database instance, that are only tied by the workspace interface. This gives the user the ultimate creativity at the UI level, and protects the database from being torn up and corrupted. The flipside is the inability to query data collections remote, without a pre-specified link. Even with the link, there are limitations.
    >>>

    According to my understanding, there is only one link type for BOM in the workspace. Also, I cannot define multiple link instances in the BOM structure. I’m trying to think how to handle Bill of Materials in the way described by Steve Bodnar here –

    http://beyondplm.com/2012/03/09/cloud-plm-and-bill-of-material-question/
    >>>>
    Our approach is to enable the BOM strategy our customer prefers. If they want a single place where all their views can be accessed, then certainly Autodesk PLM 360 can do that for them. I suspect, however, that even in that case, the system-of-record for any given view might be different. For example, the as-designed bill’s system-of-record might be their PDM system. The as-built might be in their MRP system. We can connect to those systems and maintain a reference bill in PLM 360, while possibly being the system of record for their conceptual bill, as-maintained bill, or whatever. Of course, they could choose to use PLM 360 as their overall system-of-record, but that’s completely up to the customer. One important aspect of our strategy is that we don’t have the audacity to tell our customers how to run their business. We have plenty of ideas and suggestions and are happy to provide them with templates if they choose to use them, but our system is designed to fit their processes – in what we believe is the most effective manner on the market given all the inherent complexities.
    >>>>

    Any thoughts on this?

    Thanks, Oleg

  • http://johnevansdesign.net/about/ John Evans

    Oleg,
    This kind of thing would warrant a chat I think.
    We are all struggling to develop some framework that suites not only us now, but one that can be modified as we see issues arise ( ans wont be a setback). Equally frustrating is the attempt for those of us that assist others, to make a framework that can suit the vast majority, not to tell them how it should be but provide a launchpad into what they want.

    I think we can look at some settings that might help ease some of your frustrations. Relationship settings and permissions may help.

    I think I can get you past some roadblocks on Skype.

  • Pingback: PLM, Multiple BOMs and Cross-Functional Teams

Join the Community