Paul, thanks again.
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).
You are confusing two different things here, both of which Lenz calls a stack.
Lenz LH100 and Lenz LH90 have an address recall stack. This lets
those throttles recall an address that was used recently quickly.
This address recall stack only stores addresses.
Lenz command stations also have a stack. This is the database that
the command station uses to maintain 1) which locomotives are
currently running. 2) Function on/off status 3) function
momentary/continuous status 3) Consist information (for both MU and DH
consists).
(in both cases, the term stack isn't the technical term I would have
used, but that's the terminology Lenz used in their documentation, so
we're stuck with).
I don't think I am confusing the two types of stacks, as I have described exactly as you say, that the LH100 maintains the 12 addresses, and the Command station maintains the decoder info (or does not in the case of the DR5000!) :p
I agree that I would not have called either a stack... either!
> 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).
Right, because the function status is maintained by the command
station, not the throttle. It's the command station's stack that
maintains those function states.
> 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.
It's possible the Loksound is doing something I haven't seen.
Typically when I start up an LZV100 based system (which I almost
always set to auto mode) the functions will come on with power up, but
the speed is set to step 0. (although I may not have tried recently,
so my memory may be a little foggy. )
The setting to speed step 0 is certainly consistent with the DR5000
not retaining information between sessions, and is the same behavior
seen on a Lenz compact or Atlas Commander (and other command stations)
which don't retain the stack data between sessions.
I have contacted Digikeijs about this, so hopefully I will hear back soon, if it is something they can address (if they want to add a retained stack). However, if it does not retain the stack between sessions, at least it will not run into the problem that the Lenz has!
> Thanks for the info on the XpressNet Vendor info. It's a shame, it makes writing classes for different manufacturers somewhat "iffy"!
It makes automatic identification iffy, but handling different vendors
isn't actually a significant problem. We just make a new selection in
our system selection menu for users to choose, and then trigger the
appropriate class there (so no autoidentification of command station,
but that isn't a big deal typically).
I agree for JMRI, but for TouchCab, auto discovery is one of the main benefits :-) There are of course workarounds, but a vendor ID and model ID would make it definitive.
> 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.
We can write a version of the XPressNet power manager to handle that
case. We may actually already have one available (I'm thinking the
Hornby Elite does something similar).
Excellent, let me know if you need any help with this. Interesting you mention the Hornby Elite, I think it'll be one of the next ones to support for me. I have a Select here, but I'm pretty sure I'll be peeing in the wind with that one!
> This is using the DR5000s LAN connection, but I am sure I also tried the LAN/USB by Lenz with the DR5000.
DR5000 has Wi-Fi, LAN and XpressNet (as well as LocoNet etc). However, the LAN and Wi-Fi are routed to a serial adaptor. They use Port 5550 (same as the 23151). There is also USB but I have not used it with JMRI since I am trying to develop for iPhone - USB is not much use to me. However, I have just setup the DR5000 as a Lenz XpressNet LAN/USB in JMRI, with the appropriate IP Address. The Wi-Fi is a router, so is a DHCP server also. The "LAN" (presumably this option configures both WiFi and LAN) comes un set, and can be set to XpressNet over LAN as well as others such as LocoNet over LAN. I am obviously using XpressNet over LAN for this testing - LocoNet will come later! However, having it's own class, and therefore a Digikeijs selection in the connection menu, would allow the command station to be handled differently. I will test later with it setup as a Hornby elite and see how that works...
How do you have JMRI configured to talk to the DR5000 when using it's
LAN connection. I'm going to start work on a DR5000 specific
connection class, so we can handle the issues you find, and I want to
know what to base it on.
> 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's possible that there is another method provided by the
manufacturer. I haven't looked at the link you sent if that sheds any
light on the situation.
> 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.
Well, if you can't find out what's contained in the stack, you can't
delete individual entries.
True, and if the stack deletes itself between sessions, then I guess it doesn't matter. I can just store this info within TouchCab on the device for the XpressNet command stations that do not have any searchable stack.
Thanks
Mike
