This may help.
From The DCS O Gauge Companion 2nd Edition, pages 164-165:
When train club members bring their own DCS Remote to operate their engines on a club layout, there is the potential for real operating confusion. When a DCS Remote starts up an engine, it does so by engine ID#. It doesn't look for a particular engine with that ID#, rather, any one with that ID# will do. If more than one engine on the tracks has the same DCS ID#, as when two club members bring their own engines and DCS Remotes to a club operating session, multiple PS2 engines may start up together since different DCS Remotes may have different engines with the same DCS ID#. For example, if two remotes have an engine #12 in their Engine Lists, when one remote attempts to start up its engine #12, there's no telling which engine, or engines, with #12 will start up.
It's worth noting that this problem is not restricted to DCS. This same problem exists with other command control systems, as well.
Fortunately, the problem may be entirely avoided if simple rules are followed. It's just a matter of not adding foreign engines and foreign remotes to the club layout indiscriminately.
If someone wants to control a PS2 engine belonging to someone else that's on the layout, they should first ensure that there is an open DCS ID# with that engine's current DCS ID# in their own DCS Remote. Otherwise, when the PS2 engine is added to their DCS Remote, its ID# will be changed, and any remote in which it was previously entered will be unable to find it. If there is not an open slot with that ID#, one must be made available in their own DCS Remote before attempting to add the engine.
If someone wants to operate their own personal PS2 engine on the layout, they must first ensure that the engine's ID# is not already in use by a club PS2 engine. If it is, a separate programming track should be used to change their engine's DCS ID# to one that's not in use. It would be a good idea to have a group of guest engine ID#s that are never used for club engines, available for this purpose.
Lastly, each DCS Remote should have a unique ID#. This will prevent an entirely different problem where spurious errors are displayed on a DCS Remote because it sees a TIU response for a command sent by a different remote with the same remote ID#.
The rules for effective operation of foreign PS2 engines and DCS Remotes can be summarized as follows:
• Each PS2 engine that will participate in the club operating session must have a unique DCS ID#
• Once the PS2 engine DCS ID#'s are made to be different from each other, each DCS Remote that will control an engine during the operating session must have that engine added according to its now unique DCS ID#
• Each remote should have a unique DCS ID# of its own that is different from all other remotes in the operating session
• A separate programming track that is powered on while all other tracks are powered off can be a big help. First, determine unique DCS ID#s for all the engines that will participate in the session. Then, each member uses their own DCS Remote to change the DCS ID# of their own engine to its assigned number while it's on the programming track. If it's not feasible to turn off all other tracks while adding member engines or editing their DCS ID#s, a separate TIU that has the same number as one of the TIU's on the club layout, may be used while tethered to each DCS Remote in turn
• Members should move any PS2 engines they are not operating to the Inactive Engine List in their DCS Remotes
• Operators should ensure that only those PS2 engines that are to participate in the operating session are on the tracks.
If the club has few enough members that own PS2 engines, it's a good idea to assign each of them a few DCS ID#s for their PS2 engines in advance. That way, they can pre-set the DCS ID#s of their PS2 engines and DCS Remotes prior to arriving for the operating session.
This and a whole lot more is all in MTH’s “The DCS O Gauge Companion 2nd Edition", available for purchase as an eBook or a printed book at MTH's web store!