Thanks again Paul,
As for the memory being within the LH100, I agree that it has memory, but I don't think it is to hold the function and speed between sessions, it is to hold the loco list (12 in 3.6). Certainly, using the same LH100 on a LZV100 and the DR5000 and having multiple sessions on each has different outcomes. The LZV setup maintains Function states on the Bit row of the display. The DR5000 does not, any set bits in the session will no longer show on the LH100 (with the DR5000 as command station), although the decoder will still have these bits set (lights, sound etc). Testing with an ESU V4 Loksound, with the speed set, a loco will continue to run after a re-boot of both systems but on the DR5000 for example, if the speed was set to 14, the loco will continue at that, but when notching down one step on the LH100, it stops, as it notches from 0 to 0 - as the speed has not been retained in the LH100.
Thanks for the info on the XpressNet Vendor info. It's a shame, it makes writing classes for different manufacturers somewhat "iffy"!
With regard the LH100 Stop and Power off, the same LH100 is used. It turns off the power to the LZV100 but not the DR5000. It will turn the power on on both. In contrast, JMRI will turn power off on the DR5000, but does not receive a response from the command station of this state, therefore the power button on the throttle window goes yellow unknown state, and power cannot be restored.
This is using the DR5000s LAN connection, but I am sure I also tried the LAN/USB by Lenz with the DR5000.
The stack is the area I am concentrating on right now, since this is where my app is hanging, it (currently) requires the stack to be readable (and writeable), but it looks like I may have to change that!
It has to implement some version of the stack. The stack is how any Lenz command station keeps track of what mobile decoders need to have data transmitted to them. I agree, the Lenz one is also only 256 locos long if memory serves, which has become problematic when using the same Lenz kit on multiple layouts at shows etc! This is another reason it would be better for me to be able to read the stack, since then entries can be deleted that are no longer relevant should the user wish, rather than having to delete the whole lot.
Thanks
Mike
