Using DCS on a Club Layout

It seems like the biggest underlying issue is that even when using Super Mode, the DCS Remotes retain an association from Engine to TIU.   It would seem that logically in Super Mode all engines should be associated with all/any TIUs set up in the remote.

If that restriction was removed (eg DCS reprogrammed) then the rules would be simple.

All clubs would set their equipment to Super Mode.

At a show allocate and setup TIU address numbers among clubs. 

Each remote for each club set to the TIU numbers allocated to the club.

The computer scientist in me realizes that the true deep issue is that the TIUs are numbered and not Named.  Add a name to the protocol between tiu and remote and everything is suddenly simple.  The the TIUs and Remotes were known by a (group/super) name like CLUB-A then they could ignore all messages to the wrong name.

Each club could just set their club name as the name for the each remote and tiu.  No changes needed when going to a show or from home to club.

You're suggesting the tiu should have a name along with a number. I don't know anything about software but it seems reasonable.  We know  engine names don't really mean much  because it's  the engine's ID is what counts.... Maybe the option of   giving a     tiu  multiple numbers  something like a phone number. 

Anyway we're not there yet.  However it  seems you have a good handle on things though  Bill.

Bill,

 It would seem that logically in Super Mode all engines should be associated with all/any TIUs set up in the remote.

Why would that seem "logical"?

DCS relies upon an engine being associated with only one TIU at a time. Super TIU mode is really a misnomer. It doesn't do anything to the TIU or the engine.

What Super TIU mode does is to tell a remote to send all commands for all engines to all TIUs, rather than only to the TIU with which the engine was last associated.

Add a name to the protocol between tiu and remote and everything is suddenly simple.

No, nothing is magically made "simple". Adding a "name" to a TIU is no additional way for a remote to identify it. A name would be redundant and serve no purpose.

Then the TIUs and Remotes were known by a (group/super) name like CLUB-A then they could ignore all messages to the wrong name.

OK, fine. Now, what if someone else were to name their "TIU Group" the same as your "CLUB-A"? Then,you're right back where you started from.

The relationship of the remote to the TIU to the DCS engines is at the very heart of DCS, and is most likely never going to be changed, unless and until DCS is completely rewritten. That's something that is, at best, several years away, if it happens at all.

Don't hold your breath.  

Barry,

Why would that seem "logical"?

Here is my thinking.

The purpose of Super Mode is to allow an engine to be controlled by any TIU and across TIUs on the layout.

Therefore it is illogical in Super Mode to associate an engine with a specific TIU. 

That is contrary to the purpose of super mode, e.g. not tying an engine to one TIU, but allowing it to roam free...

Logically the engine can be on *any* TIU at any time as it moves around the layout.

Regarding naming.

If you add a "layout name" to all communication from remote to TIU and back you now have created a new Virtual channel of communication exclusive to that name.  Even though all hardware is using the same radio channels etc, each layout is effectively ignoring traffic not addressed to its name.  Its really just another layer of multiplexing like addressing different engines by ID.  Or how the internet works by routing and ignoring packets not addressed to a target.

As a software change its actually really straight forward just add a name into the packet and change your listeners. 

As far as clubs using the same name, yes that's possible but far less likely than you might think and something clubs could very, very easily coordinate.

In the worst case if two clubs pick the same name and go to the same show, one just needs to rename, that would be simple enough.

The relationship of the remote to the TIU to the DCS engines is at the very heart of DCS,

 

In my opinion, the "heart of DCS" is relaying commands and responses from the remote to the engine and back...

As always just my $0.02

Bill,

Nice ideas, however, they're completely undoable in DCS.

Barry,

Yes the current software does not provide these capabilities.  

I will document the concept in more detail and pass it along to MTH for their consideration in a future release. 

For DCS 4.3 clubs need clear procedures for being able to manage so that we can use DCS at home, clubhouses and at shows without pulling out what little collective hair we have left :-)

I think the basic bits for those procedures are here thanks to the collective brain power of the forum. 

Here is an early draft, definitely not final!  I think this ultimately needs to spell out exact procedures in detail like (Power on remote, click menu, select system, ...)

* MTH DCS For Clubs

A set of guidelines, procedures and best practices to allow Clubs to get the best use of DCS at home, club and at shows.

* Background:

It is desirable to to be able to bring DCS engines from home layouts to club layouts and to modular show layouts with minimal fuss.

It is also desirable for club member to be able to bring their own remotes from home to club and or to shows.

* Challenges include:

Varying TIU address numbers and issues arising when adding or removing TIUs from remotes.

Conflicting assignments of engine numbers.

Cross club layout control at shows.

* Rules to allow clubs to manage these issues

1) Get all DCS TIUs and Remotes to DCS release 4.3

2) Always run in Super mode, (at home, club and shows)

3) Always use a dedicated setup track with a dedicated TIU numbered 1.

4) Always use a tether on the setup track.

5) Turn the setup track TIU off when not in active use.

6) All engines must be added to remotes on the setup track.

7) Each club must assign engine numbers to club members.  A club member must change a newly added engine to one of their assigned numbers if the engine is to be used at club or show. (Does not matter for engines that stay at home)

8) At home you may simply have TIU 1 for the entire layout and add engines anywhere. (But not at the club or show!)

9) The club layout will use TIU 2 for the main track and may also use more TIU (3,4,5) depending on the size of the layout etc.

10) At shows you need to get all DCS users together to plan out TIU numbering.  To work all clubs at the show must follow these rules.  

11) At shows each club keeps a TIU 1 as dedicated tethered setup track.  However the rest of the TIU Numbers must be divided up.

12) At shows the TIUs beyond 1 get renumbered.

13) At shows the Remotes drop and add TIUs beyond 1 as allocated.

Bill:

Here's the theory I was operating under. Under this theory (I may be all wet on this, but experience with duplicate TIU's implies this would work):

• Each modular group by agreement has TIU Address #1 dedicated for adding/re-programming engines with a tethered connection.
• The layout TIU(s) would be fixed to a single address (see illustration).
• Both #1 and that chosen address would be in each club remote with Normal TIU mode chosen. No other addresses would be in the remote. The reason for this is that once the locomotive is added to the remote, when placed on the layout, a read would be done to let the remote know that the locomotive is within the layout TIU's zone of influence.
• No AIU's can be used on the modular setup and under no circumstances should an engine be added on the layout.
• The engine, after being added, should show up when on the layout's yard when a read is executed.
• As with any situation, cooperation and communication is the key here.

This works in theory and I haven't had a chance to field test it. As with any configuration, the TIU's would need to have the hot leads isolated from each other to prevent feedback.

Because each group is using a different address, there shouldn't be any issue regarding cross-talk or operating neighboring engines. This is on the proviso that ONLY address #1 and the modular groups assigned layout TIU addresses are the only ones in the groups remotes.

Barry's suggestion of backing up remotes is a great suggestion because using a cleared remote in this context would be a much better starting point -- i.e., reset the remote beforehand. This ensures that only the locomotives and TIU's in question for the particular group's layout are in the remote.

Wait, you can have multiple TIU's with the same address?

Yes. There are two catches to this.

First, you can't add locomotives to the TIU with a duplicate address as it will associate the locomotives in an ambiguous manner -- i.e., you don't know which #2 it's actually associated with.

Second, you can't have AIU's on the duplicated TIU's.

This is definitely not something I'd recommend doing on a permanent layout unless there's no alternative. We haven't experienced any problems doing this with duplicate #5's. The duplicate #1 is the tethered unit we use on the setup track and it's never transmitting it's address since it's either off or tethered.

Matt,

What is the advantage of Normal mode over Super mode in this situation? 

I thought in normal mode, your engine was *Stuck* to the TIU it was added to? EG 1 in this case?

I think I need to upgrade to  Barry's edition 2 book and re-read.  There are parts of how the communication protocols work here that are not making sense for me, which in turn makes it hard to figure out what will work and what wont.

Having 2 tiu with the same address really doesn't work that well unless  the remote is "out of range of one of the tius.

Engine are associated with the tiu they've been added to.   However the "read" is King of association , It will move a engine's association  from one  tiu to another. It just takes time.  Normally moving a engine   from one tiu to another in normal mode  would be to delete it and add it again, The read will move it over and the engine is now associated  that tiu. Of course in super it's not a  problem.

That's the key. Super TIU mode would also work, but the reason I suggested Normal is for those individuals who have the other TIU addresses being used by the other groups in their remotes. The mindset is to lock the individual into his/her group's layout. This is the "wild card" part of things.

Let's say that on the read, the locomotive is associated with TIU #2. Since the remote carries all of the information and the TIU's both have address 2, in theory it should talk to the engine when in either TIU #2 zone even in Normal mode. In Super mode (with more than addresses 1 and 2 in the remote) it would talk to #'s 3, 4, & 5 and hit engines with the same address.

What's going to be interesting to see is how the WiFi system plays into things.