I use three Modellbau Union new turnout decoders on my layout. Each controls eight turnouts (Kato Unitrack, with no feedback). They work great when turnouts are changed individually, but when more are changed in a fast sequence, the decoder is apparently not able to process it and only one or a couple of turnouts are switched, the others are omitted...

?

I encountered this problem first defining routes, but I fixed it easily by adding delay in the route configuration. Now routes take longer time to be set, but they work fine.

?

But I cannot find a solution for the Dispatcher... :(?

When it allocates sections, it apparently sends commands to all turnouts in those sections simultaneously (or in a very fast sequence). And my turnout decoders can't handle it - only the first called turnout on each decoder receives the command properly and changes, the others don't... And because there is no feedback available, JMRI thinks the turnout were changed fine, while in fact they were not, so the trains continue running onto wrong tracks with quite unpleasant results...

?

Does anyone have any idea if there is a way to inject delays between turnouts commands sent by the Dispatcher, when it allocates sections, like I did with the routes? I'm pretty sure there is no such option available in the standard JMRI interface, but maybe something can be scripted?

Or some other trick that I could use to make me setup work with the Dispatcher?...

Dispatcher simply sends the turnout commands, it is up to the turnout handler for a given interface? to know how to pace them.

?

For example? digitrax configurations have a setting Turnout Command Handling which can be set to "Spread" and/or an output interval.

?

Steve G.

?

?

?

?

On Sun, Dec 1, 2024 at 03:25 AM, <pawel.k@...> wrote:

Or some other trick that I could use to make me setup work with the Dispatcher?...

Just putting it out there, how about LogixNG with Execute Delayed to throw the subsequent turnouts.

This would run shortly after the first turnout changes, and progressively for each turnout.

?

--

Thanks a lot for the suggestion of putting the delay in the connection settings - it worked great for routes: I removed the additional delay in the route configuration and routes work well now using the "main" delay set in the connection.

?

Unfortunately Dispatcher seems to ignore that setting... As soon as it starts allocating sections, it sends several turnout commands almost simultaneously and only some of them are executed by my decoder... :(

?

Pawel

I'm sure it's a very good suggestion, unfortunately I'm new to the JMRI and I don't understand much of what you wrote... :(

Obviously I'm new to these Groups too :)? The reply above was to Nags :)

On Sun, Dec 1, 2024 at 08:53 AM, <pawel.k@...> wrote:

I'm sure it's a very good suggestion, unfortunately I'm new to the JMRI and I don't understand much of what you wrote... :(

Yep, us mere mortals start off that way.

LogixNG isn't too hard to learn. Basically, it gives you a relatively easy way to get JMRI to "do stuff' using commands.

?

--

It is not the job of Dispatcher or Routes or wifi throttle etc to throttle turnouts changes, or any other commands.

If your connection does not already have a method available to do that then ask that the connection provides the capability.

Steve G.

?

On Sun, Dec 1, 2024 at 03:25 AM, <pawel.k@...> wrote:

But I cannot find a solution for the Dispatcher... :(?

When it allocates sections, it apparently sends commands to all turnouts in those sections

I use warrants so I only need to deal with blocks not sections as well.

Don't know if it would work but perhaps limit the number of sections allocated and each turnout in its own one block section.

?

I think the LogixNG option should work, but don't know how to easily explain the steps.

--

There's an example of using LogixNG to throw a turnout here.?

Try working through it it yourself and you should be able to progress on that it to do what I suggested.

?

--

Sure, but then why Routes include the option to delay consecutive turnout commands, but Dispatcher does not? Inconsistency... Neither should have it, if what your wrote was strictly followed.

?

My connection is DCC++/DCC-EX. There doesn't seem to be an option available in DCC-EX to throttle turnout commands. I could probably try to modify the DCC-EX Arduino IDE code itself, but I'd rather not go that route, as it would be a nightmare to keep the DCC-EX up to date later... And EX-RAIL language available for automation seems to be too limited to do it...

?

I'll look into LogixNG...

?

Thanks a lot, I'll look into it!

On Sat, Nov 30, 2024 at 11:10 PM, Ken Cameron wrote:

?Ken Cameron?

Nov 30???#236889???

Pawel,

?

Use the LocoNet Monitor and turn on timestamps to measure the delay or absence of delay. I would consider it a fault if Dispatcher was somehow bypassing the delay. But a trace with those timestamps would prove it.

?

It is not the job of dispatcher to pace the commands, the fact that someone put it a delay in routes when it should not have been placed?

On Sun, Dec 1, 2024 at 10:03 AM, <pawel.k@...> wrote:

And now Dispatcher with the same settings:

600ms delay setting was completely ignored... Just 31ms between the first two commands, and no more than 256ms between any other...

I also just noticed that Dispatcher duplicated some of the commands. In fact there were supposed to be only 7 turnouts set by Dispatcher in this case, but it sent 10 commands.

1 - Routes - It can add delays, but the basic delay configured per connection, is in the _turnoutmanager_. When they added the code they did not apply it to all turnout changes only ones coming from the route manager. That change was in the correct place but could have been implemented better so it applied to all sources. I can look at that.
2 - The multiple commands to the same turnout is likely due to a bad choice of settings in the turnout ?concerning feed back and repeats, or certain turnouts such as 4 way slips keep setting both motors, even though only one has changed.
3 - You hace, of coarse, set the Trust Known turnout positions in the dispatcher options to avoid unnessassary switch setting.

Steve G.

?

I have the retry automation set to Off for all turnouts, so it's not that, what causes the duplicates.

?

My turnouts have no feedback and can be switched manually, plus when Dispatcher sends commands that are not executed, the state of the turnout in JMRI no longer corresponds to the actual setting on the layout. For that reason I cannot have the "Trust known position" option set, as quite easily the physical state and JMRI state can get out of sync... The only way to be sure that the turnout setting is correct is to send the command regardless of what "know position" is.

?

Just for test though, I set the option to "Trust" and started the same train again. Indeed now there were no duplicate commands. Yet, the commands were sent so quickly anyway that most of my turnouts didn't switch. And that caused JMRI turnout states to become out of sync with my actual layout, as I mentioned earlier...