DxDatabook configuration file autoload via automation

Can you explain more about how you end up using different dbc files?  Do you have different libraries too?  If two sites can access the same network file location to do concurrent design, why can't they also use the same dbc setup?

Then you can modify the project file with a script.  But if you do that and have 2 people from different sites working on the design at one time, one of them is going to have the slow access time because the design will be configured to access the distant server. No matter how you change the dbc configuration, the effect to a remote user will be the same. If only one person is working at a time, the project file can be modified to suit the current user and it will not be a problem.

Just keep those libraries in sync

Yes, you can do exactly what you want. My employer has multiple sites and we copy the library locally to each one. The trick is to use environment variables in the .prj file, like this:

KEY CentralLibrary "${LIB_PATH}\ReleaseLib.lmc"

KEY DBCFile "${LIB_PATH}\ReleaseLib.dbc"

Now each site can have its own local copy of the library and your global .prj file just needs to reference the environment variables; add suitable variable values to each client PC. Note that syntax is important when you define the KEY lines above; the example works for both linux and Windows OS.

Regards,

Andy

AGreen,

Great answer and even better to address both platforms.

What I like most about your solution is that it is not your standard vanilla fix. It helps users to understand the system better, not the help files.

Good one!

Mike

Agreed.  This is a great way to to do it.  Well done.

I can't claim credit for this; the info was in a tech note all along:

http://supportnet.mentor.com/docs/201105004/docs/htmldocs/mgchelp.htm#context=xtreme_admin_gd&tag=9321&tab=0&id=17

As far as I can remember I just figured out the syntax to get Expedition to recognise the variable definition. BTW, I just got notified that one of my ideas got implemented in VX (sound of jaw dropping...) so we will be able to define the RSCM server name as a variable too :-)

The support for variables throughout the flow has always relied on the ${var name} syntax, some applications support other syntax such as %var name% but Mentor doesn't guarantee that these alternatives will work. If you find the supported syntax of ${} does not work please notify us so that we can address such cases. Also note that the variable can only support a path, it does not support a file location, so in the examples provided by Andy this works:

KEY CentralLibrary "${LIB_PATH}\ReleaseLib.lmc"

Where the library file itself is declared separately to the variable, but if you were to make the LIB_PATH variable include the ReleaseLib.lmc and declare the key as:

KEY CentralLibrary "${LIB_PATH}

it would fail.

The feature to support Variants from the Part Lister rather than just the Variant Manager BOM report is new in VX.1. If you are having issues with getting variables to work here please log it with Mentor's support organization so that we can get it addressed.