Hi,
we are facing the problem, that we have several sites and we do some concurrent designing. Now the problem is, that every site has its own DxDatabook configuration file.
Is there a way to change the used configuration file via automation?
I see a way to do it via modification of the project file, but this seems a little bit risky for concurrent designs.
Regards,
Markus
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?
We have two servers, one server for each facility. These servers provide identical content, access from one site to the other server is possible, but the transfer rate and response times are sometimes very low, so we have for each site an individual configuration file. The configuration files are nearly identical, only the address of the servers are different.
So we end up using two different dbc files.
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
So you also don't know any other way to modify the project settings without modifying the project file itself?
I was just thinking about a solution like for setting the borders.ini file.
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
Thank you for this information, I didn't know that.
Regards,
Markus
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
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.
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:
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 :-)
Unfortunately this seems not to be possible yet for the partlister configuration file, since beginning with VX you need to define the dbc configuration file when generating variant part lists. But the partlister doesn't accept the variables there . So there is still space for improvement.
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.
The problems I had with the partlister was, that my variable looked like
DBC_FILE = PATH_TO_DBC\OUR_DBC_CONFIGURATION.DBC
which worked perfekt within the project file, but I wasn't able to use it that way in der partlister configuration file.
So we changed it to
DBC_FILE = PATH_TO_DBC
And now it works
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