Intellibox turnout speeds and special option 13

XTrnt response codes

I turned on the logging I have in my software and noticed that I was getting a lot of responses from my Intellibox warning me that the turnout buffer was 75% full, and also numerous rejections of turnout commands when the buffer was completely full. When this happens, my software throws the failed commands back into its own command queue so that it eventually gets accepted, so once the Intellibox buffer fills up, I get many rejections until the buffer is no longer full.

In looking at it, I wondered if the Special Option (SO) 13 was influencing how long it took the Intellibox to process turnout requests. SO 13 sets the duration of how long the turnout motor is powered on when switching, specifically the minimum time in units of 50ms. My Intellibox was set to 3, so it was turning the turnouts on for 150ms each time. I reduced that to 2 (the default).

I wrote some code to send 100 turnout changes (P50x command Xtrnt) in rapid succession to the Intellibox and I compared the times in my log from the first buffer warning to when the last warning was given. Note that the Intellibox turnout command buffer has a size of 16, so the 13th command might give the 75% buffer full warning, and then accept another three commands before rejecting the 17th. In addition to the 100 turnout commands, I was still polling the Intellibox a few times per second.

With the combination of my hardware and software, it typically took 52 seconds to get all 100 done.

I then changed the special option from 2 to 1 and ran the same tests again.

The times were reduced to 45 seconds! That is about 70ms faster per turnout, pretty close to the theoretical difference of 50ms. This is evidence that the speed at which the Intellibox can handle turnout commands, depends on the time the solenoid is kept powered on. This is not exactly surprising.

I use full flow control for the serial port communications with the Intellibox. This is the correct way to do it and is needed in order to get faster throughput. Many people who do not fully understand serial communication flow control suggest waiting for the response from each command before trying the next command. Software written using that approach will be less likely to fill the turnout buffer but will also not be able to take full advantage of the speed available. It is very easy to run into situations where 16 or more turnouts need to be set at once, for example when a route with 10 turnouts and 6 signals is set. Running multiple trains that could trigger such demands will easily exceed the buffer, so getting the commands processed fast is important.

So, if you find that your layout is getting bottle-necked by the Intellibox throughput, consider reducing the value of SO 13. If you do, check that your turnouts are still getting switched properly.