Our club layout uses a Gaugemaster Prodigy 2 DCC controller with three handsets. (For those of you based in the USA, the Gaugemaster unit is an MRC unit rebadged for sale in the UK>)
Our layout has a bus controlling the trains and a separate bus for control of accessory decoders to throw turnouts and change colour light signals.
We have had no problems running trains or using accessory decoders when we use unique addresses for each turnout and signal.
We have set up routes, and we now have problems.
Our intention was to set a route on the handset and for the turnouts to throw and then the signal to change to signify that the route was set.
The turnouts throw in what appears to be a random order and one point takes about thirty seconds before it throws. The signal has changed before the route has set!
Why does a route not follow the sequence we entered, and why should one turnout take so long before it throws?
Is there any way we can control the timing and the sequence that each accessory changes? Is it even possible to control the sequence and delay period?
Our fault finding has included deleting all routes and rentering them an address at a time. Three points will throw fine in a couple of seconds. Four or more accessories causes a time delay and appears to randomise the sequence. Because we cannot get the signals to change at the end of the route setting sequence, we cannot operate the layout and drive the trains in a prototypical way.
So the switches do NOT throw in the order entered? That may be quirk of the system, but could also depend on the way that you have designated the addresses of the turnout controls. If the system throws them in numerical order, no matter what arrangement you’ve entered, you may have to go back and re-address the turnouts to arrange them in an order the system will handle correctly.
I’ve never used a MRC, but have heard they have some quirks and limitations. Maybe someone with more specific expertise knows?
our turnouts are addressed between 1 and 24 and our five signals are addressed between 53 and 65. This was not planned, it just happened. One of my colleagues thinks that only one point shows the delay, it just happens to be the most important one on the whole layout and is involved in seven of our 12+ routes.
Do you think there are settings in the Lenz stationary decoders we are using that could be causing our problem? A random throw of points is not important, we do need the signal to change after the points to indicate the route is set.
I don’t think its the way you have the turnouts vs signals grouped as number. I suspect it may be that the MRC throws the turnouts in numerical order, while you want to program a more random arrangement that is based on the path through them? Or does that seem incorrect?
I’m a NCE guy, so am used to talking about Macros, which I think is basically the same thing as the routes you describe.
You may be right the issue is an incompatability between the MRC and the Lenz accessory decoders, but I have no idea other than checking a Lenz or MRc forum to see if others have noted the issue.
all points throw and signals change imediately when we use each individual accessory address. No problems when we set a route with just two or three accessories, just when we go to four or more.
A work around solution is to use two route numbers to achieve the required routes.
Which Lenz stationary decoders are you using? One of them will ignore any subsequenct commands sent to it if it is still processing the previous command, as we discovered setting up a friend’s layout with one of them. It’s meant for solenoid motors but there is an adjustable pulse time that can be set reather long which worked for Tortoise machines (the small N scale rail meant the Tortoise had no problems holding position with the power off). However, during the 5 seconds of outputting the ‘pulse’ on say output 1, you could keep sending commands for outputs 2-4 and they would be totally ignored. The turnout that lags - is that on the same stationary decoder as one of the others that are part of the same macro? This could be the problem, in that it gets the switch command but will only operate one output at a time and needs to wait until that completes first.