JMRI Lenz Bugs

#### CRITICAL: Consecutive turnouts cause spurious time-outs, locks layout operations for 5 seconds

Justification: Can degrade or burn solenoids physically. Causes long delays in railroad operations.

Affects: Nano-X

Tested: Nano-X

Cause: Nano-X sends a feedback message as \*only\* confirmation for a turnout. Feedback contains items for 2 turnouts with consecutive numbers. When turnouts are switched in a sequence, the reply is incorrectly paired with different command; the correct one then "does not receive" a reply and times out. This is an amplified effect of the other 'turnout interference' bugs.

#### CRITICAL: JMRI sends operational command even if the command station is in service mode.

Affects: DR5000, Nano-X

Tested: DR5000, Nano-X

If a handheld enters service mode, JMRI receives Service Mode broadcasts, but still attempts to send normal commands, e.g. turnout switch or throttle to the command station. It requires either ethernet connection (DR5000), or a dumb LI\* interface (DIGI-CZ GEN-LI) to reach the command station, but such behaviour violates XPressNet specification. Potentially affects Lenz command stations as well, subject to further testing.

#### MAJOR: Turnout OFF messages can be delayed by 1000-2500ms

Justification: Can degrade or burn solenoids physically.

Affects: LZV100

Tested: LZV100

Cause: OFF messages are sent when the command queue is empty. Transient errors to nomral errors commands (command station busy) will delay them by increasing timeout. The tested Lenz LZV100 + Lenz LI-USB routinely issued 2-3 Busy errors during setting up Route with 4 turnouts in it, the shortest delay between ON-OFF was approx 1000ms.

#### BUG: Turnout OFF messages are lost

Affects: All XPressNet command stations

Tested: none.

Justification: if all OFF messages are lost (incidentally), solenoids may burn

Cause: The code ignores transient errors when it sends OFF messages. Normal messages are repeated; OFF messages are not. If 3 transient errors are received, all OFFs are silently discarded and never repeated. Not MAJOR, since not confirmed that OFF message can be rejected with a transient error; but the error handling is missing from the code.

#### BUG: Turnout OFF messages can be delayed by 1000+ms

Affects: All XPressNet command stations, DCC++

Tested: DR5000, Nano-X, Lenz LZV100

Cause: OFF messages are sent when the command queue is empty, after a delay (100ms). Further 100ms delay between each two OFFs. OFFs are (see other issue) fired in bursts, each single item adding 100ms. If Route posts 4 turnouts, the last one will start to send OFFs after at least 3 \* 3 \* 100ms (LZV100), or 3 \* 4 \* 100ms (DR5000). The long is the route, the longer the OFF messages may take to start.

#### BUG: Consecutive switched turnouts change state temporarily

Affects: All XPressNet command stations

Tested: DR5000, Nano-X, Lenz LZV100

Cause: Once turnout receives a command, it changes CommandedState immediately to the new state, and KnownState to inconsistent, to indicate an operation is pending with unknown. If consecutive turnouts are operated, a turnout MAY receive and process feedback actually generated beacuse of the other turnout in a pair. That feedback MAY precede the time its OWN command is sent to the layout. Then the turnout's state

changes (suppose it was commanded to THROWN):

* CommandedState: (closed) -> THROWN -> CLOSED -> THROWN
* KnownState: (closed) -> INCONSISTENT -> CLOSED -> THROWN

The extra transitions can provoke scripting actions or, cause visual flickering, if handled fast enough (or if messages are sent slow enough).

#### BUG: OFF messages can be postponed by other comands indefinitely

Affects: All XPressNet command stations

Tested: DR5000, Nano-X, Lenz LZV100

Cause: OFF messages are documented as 'high priority'; they effectively terminate the Turnout command as if handheld's button was released after press. They are passed for transmission through poll interface, which only polls if no other commands are waiting. If any other command is already queued, or is generated into queue within 100ms after \*any\* command (including the Turnout's one), OFF message is postponed after this new entry. Classified as BUG not MAJOR, as it requires "unfortunate" timing and repeated commands from a script or automaton to happen.

#### PERFORMANCE: OFF messages are sent long after the original command

Affects: All XPressNet command stations, DCC++

Tested: DR5000, Nano-X, Lenz LZV100

Cause: there is 100ms delay between subsequent OFF commands. For each acting turnout command, 3-4 OFFs are fired, depending on command station and other operations pending. Although the command's transmission (including mandatory OFF) can end in ~40ms, it lasts for ~300-400ms. Other layout operation are not blocked/delayed, however.

#### PERFORMANCE: OFF messages are replicated unnecessarily.

Affects: All XPressNet command stations

Tested: DR5000, Nano-X, Lenz LZV100

Cause: For each reply to the Turnout command the command station sends, an OFF message should be generated, according to Paul Bender (the official JMRI XpressNet support author). In fact 1-3 messages are generated, depending on other pending operations and the command station. This creates unnecessary traffic on rather slow XPressNet bus (62.5kbps) and LI\* interface (9.6kbps), and may fill up LI\* device buffers.

This bug amplifies effects of the other ones described here.

#### PERFORMANCE: Service mode command exits the service mode first, if already in service mode.

Affects: Nano-X + GEN-LI

Cause: GEN-LI emulates the LI-100 device. LI-100 adapter hardcodes exit from the service mode to normal before write service mode instructions. This may be required by Lenz/LI-100, but is not necessary for GEN-LI.