One day me ARG says, “ARG, go to ARG and get the ARG to ARG the mainsail.” I says to me ARG, “ARG went yesterday. The ARG is over yonder by the ARG and the rum! Ha-ha-ha-ha-ARG!!”
Yeah… pirate jokes don’t work so well when the same ARG is used in too many places. The same goes for command snippets.
Summary Note: This article got longer than I intended, so here is a summary of the important points.
1. When using multiple Command Objects in a single mechanical session, the ARG variables initialized in earlier scripts are still active in later snippets if the ARG values for that snippet are not filled in the details window. Don’t assume the ARG values are zero, unless you set them to zero.
2. Output arguments are evaluated at the end of the MAPDL run. If the same variable name is used in multiple command objects, all the snippets will show the same output value, which is the value of that variable at the end of the solution process.
Now you can keep reading if you’re bored, or curious, or just confused. 
Up until a few days ago, I was under the impression that each command snippet that was added to a Workbench Mechanical had it’s own set of ‘ARG’ variables, like MAPDL does for macros, since each one has a details window with it’s own set of ARG Variables. Well, they don’t.
When you hit the ‘Solve’ button in Mechanical, it builds one large input file that it sends to MAPDL. This input file contains all the nodes and elements, loads and supports. It also contains any command snippets that you have in the model. All command snippets are run in the main namespace. ARGS from one snippet carry over to another.
As an example I set up a small command snippet with the details from the above picture. It uses two arguments, ARG1 and ARG2. Below shows exactly what get added to the overall input file.
The first two lines are added by Workbench to initialize the variables. All looks good and works fine, until I add another command snippet. This one is even simpler and just stores the ARG variable to defined variables that Workbench will then read back to the details window, which is discussed below.
As you can see below, the ARG1 and ARG2 variables are left blank, but the two output variables match what was set in the previous command snippet. This is because the*SET commands that Workbench adds, are only added when the details window has values given. So ARG1 and ARG2 are never overwritten from the previous command snippet. The way to avoid the overlapping of input variables is to fill in the Input Arguments with zeros whenever using multiple command snippets.
Which brings up another point, about output variables. As many of you know, but some may not, each command snippet has a “Parameter Search Prefix”, which is set to “my_” by default. This allows Mechanical to search through your snippet and find any variables that you define that start with “MY_”. In the example above, the output variables are MY_ARG1 and MY_ARG2. (Remember that MAPDL stores all variable in uppercase.) The values of these variables are then pulled out of the MAPDL database and shown in the details window for that command snippet. The values are taken at the end of the solution phase, and not at the time they are defined. So this means that if two or more command objects use the same output variable names, whatever value the last command object set for the variables, that is going to be the same value read back in and displayed for all of the command objects using that variable. The best way to avoid this is to use different output variable names in each command object.
Since I already gave you the good points in the summary, I won’t restate them here. I will just add that command objects are great for adding functionality to your Workbench Mechanical runs. Just be cautious ARGS when using multiple objects. (Or pirate jokes, for that matter.)
