Try to avoid acar.bin. Save/reload sessions, if you want to save/start at certain points of a previous session.
acar.cmd is being serached in site-dir (if defined), homedir and working dir.
You can have multiple acar.cmds in these directories, but the issue is that A/Car stops searching when it has found the first one. As a result code may neo be eceuted that you wented to be executed.
So there's the "additional" acar.cmds that are executed "before start" (= BS) or "after start" (= AS).
My philosophy is to use the acarBS/AS stuff in my homedirectory to include machine wide settings that I want to be active all the time (like changing background color or loading some own plugins).
I'm only using acar.cmd files in the working directory (which is usually assiogned to a project).
So this contains project-specific stuff like opening a base model, changing it to a desired state, maybe eveb run some analysis and postprocess the results.
Do not over-use these files. A good percentage of user-issues have their roots in own cmd-files being executed automatically.
You need to turn these off, when debugging issues in ADAMS, but the more you have, the more you can forget ...
Try to avoid acar.bin. Save/reload sessions, if you want to save/start at certain points of a previous session.
acar.cmd is being serached in site-dir (if defined), homedir and working dir.
You can have multiple acar.cmds in these directories, but the issue is that A/Car stops searching when it has found the first one. As a result code may neo be eceuted that you wented to be executed.
So there's the "additional" acar.cmds that are executed "before start" (= BS) or "after start" (= AS).
My philosophy is to use the acarBS/AS stuff in my homedirectory to include machine wide settings that I want to be active all the time (like changing background color or loading some own plugins).
I'm only using acar.cmd files in the working directory (which is usually assiogned to a project).
So this contains project-specific stuff like opening a base model, changing it to a desired state, maybe eveb run some analysis and postprocess the results.
Do not over-use these files. A good percentage of user-issues have their roots in own cmd-files being executed automatically.
You need to turn these off, when debugging issues in ADAMS, but the more you have, the more you can forget ...
