开云体育

Thanks, Peter.

Those changes looked good and were easy to pull into my copy. I've committed them to JMRI/EngineDriver. You'll want to update your repo from there (or refork) before adding other changes.


Please proceed with the other changes the same way. then, when we've got JMRI/EngineDriver all caught up, I'm going to proceed to:
1) update all source files to match latest JMRI standard (Linux line endings, spaces instead of tabs). I'll push in this change with no functional changes mixed in.
2) move ED into Android Studio, and push this change in. Again, no functional changes mixed.


Thanks!
SteveT

Dave,
Having read your advice in the link?NCE Consisting - Mark Gurries?I have the following question, which arises from a problem with consisting on my layout: ?As you say, when setting up advance consists with NCE, the first one defaults to the address 127. ?I have discovered that, retaining that number, when I then select ?the lead locos address in order to drive the consist, a lot of my turnouts change! ?I am using mainly Hornby point motors and accessory decoders but also some Peco point motors. ?If I change the consist address to 126, the problem disappears. ?I appreciate that this is not a JMRI problem but, as I have been unable to get an answer elsewhere, I am wondering if you can explain it.
Kind regards,Harold.

|
| |
NCE Consisting - Mark Gurries
Education about Digital Command Control (DCC) used in model railroads to run trains. This site is also a distri... | |

|




[Non-text portions of this message have been removed]

Paul, thanks again. I have re-posted the reply, as I see the colour I used in replies has been stripped!
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.

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 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... Let me know if you need any help in this too.
*/

> 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

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

Walt & Ken,

The particular situation where JMRI “normalizes” the “user names” and maybe the “system names” does not prevent the panel from being loaded. There is a “WARN” message in the console log identifying the “user name” or “system name” that was normalized. No indication on how to permanently fix the issue. Now I know that the “fix” is to save the panel OR as I did use an editor to fix the problem.

Marshall

From: mailto:jmriusers@...
Sent: Tuesday, June 20, 2017 10:23 PM
To: jmriusers@...
Subject: [jmriusers] Re: Problem with leading spaces in a sensor "username".


Ken; This is the closest I find
"JMRI applications will not load a panel file that fails XML validation; an error will be shown that should explains the error, allowing it to be fixed using an editor. (The explanations remain a work in progress.)"
from

Walt


[Non-text portions of this message have been removed]

Mike,

On Wed, Jun 21, 2017 at 3:08 AM, mike@... [jmriusers]
<jmriusers@...> wrote:

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).

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).

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.

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).

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).

This is using the DR5000s LAN connection, but I am sure I also tried the LAN/USB by Lenz with the DR5000.

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.

Paul

Hi Bob,

When you connect your phone to your desired network, is there an "exclamation point" on your wifi icon at the top? (your screenshot doesn't show the entire screen).


If so, that exclamation point may indicate the root of your problem. Some newer phones ignore wifi connections that cannot reach the Internet. See here; . androidpolice.com/2014/10/18/ lollipop-feature-spotlight- android-now-defaults-to- mobile-data-when-wi-fi-has-no- internet-access-signal-icon- adds-a-for-no-connection/
If that's your issue, you need to turn off this "feature'. On my phone, under Wifi, Advanced, the option is called "Smart Network Switch". Turn that off and see if you can connect.


This is becoming a common issue for Android users trying to connect to a wifi network without Internet connection.


HTH,
SteveT

OK, so last night I tried again with the same results. I even went out to Staples and purchased a new router to see if that was the problem. It was not. Finally, I decided to try going through my home wireless network, which is connected to the Internet. It worked! Apparently there must have been a setting I made (or didn't make) on the stand alone router that prevented Engine Driver from connecting.

I really don't want to use the home wireless network, but for now it's working. Would anyone have any ideas why the stand alone router wouldn't work?


Thanks,


Bob Z

ok, I have (hopefully) made one of the simple changes in a fork




Peter

Possibly, but just a quick look showed that that folder structure is very different. It does not look like it would be simple to manually recreate the changes.


Peter


---In jmriusers@..., <rhwood@...> wrote :

It is possible that if almost every single file is showing changes that your editor has changed the line endings on the file.

It is possible that if almost every single file is showing changes that your editor has changed the line endings on the file.

Hi Dave

Thanks for taking a look at my problem. Rest assured that my signals files are all located where they should be in my own files area. The signals are in C:&#92;Users&#92;Fraser&#92;Documents&#92;Railway&#92;JMRI&#92;xml and the icons in C:&#92;Users&#92;Fraser&#92;Documents&#92;Railway&#92;JMRI&#92; resources. That way they are all included in my Synology synchronisation of My Documents across three computers. All the signals display correctly including the animated gifs for the flashing aspects. That is why I have eights sets of icons for eight compass points so I can use the nearest angle to suit the section of track. By the way is there any way of stopping the automatic rotation of the icons when placing the masts as it would have been easier if they had all come in at zero degrees rotation.
As you have noticed I am using the standard BR2003 and my own version of BR2003 FWS using the Matrix signal mast system but there doesn't appear to be any problem with this as all the possible paths from the two approach tracks to the terminus have worked out correctly. There has been a problem for some platform paths in some attempts but this time all these have worked.
The problem as I noted before is on the two entries to the fiddle yard. The signals affected are Fid1a, Fid2a, Fid3a but not Fid4a being the top right turnouts of the yard and Fid5a, Fid6a, Fid7a but again not Fid8a on the bottom left of the yard. In Block CC03 the valid path is from CC02 to Fid1a and in Fid1a, the first turnout of the fiddle yard, the valid paths are CC03 to Fid2a, the straight on line to the second turnout and CC03 to Fid11 the first right hand storage road. If I try Discover on Signal Fid1a it only picks up the path to Fid2a. The same sort of thing applies to the other 5 that aren't working. I'm sure I can use the manual entry method to get these going but if 90% of the layout works why won't it do these? I think I have been absolutely meticulous in defining the unidirectional blocks as that was part of my past problems. It seems very odd that this problem is now concentrated in the entries to the fiddle yard but that it doesn't affect the fourth one in each direction. In previous attempts at this (I've been at this on and off for well over a year now) the problems have been more wide spread around the layout but my increasing uderstanding of what was going wrong has eliminated the other areas.

Again thanks for taking time to look at this.

Fraser

ps when do you ever get time to do any modelling? You must spend an enormous proportion of your time answering questions on here.

---In jmriusers@..., <dave@...> wrote :

Fraser,

I recommend that you move your custom signal mast system to your user files location. This eliminates the need to update the JMRI install location each time you install a different release. Your "user files location" appears to be "/C:/Users/Fraser/Documents/Railway/JMRI/".

The structure that I would use is "resources/signals/BR-2003 fws". The aspect and appearance files go here and the icons would be in an icons directory: resources/signals/BR-2003 fws/icons.

The initial migration is a BIG job. The <imagelink> entries in the appearance xml files need to have the path changed. There might be other required changes but I have not done this recently.

One issue that I see is that you are using both "BR-2003" and "BR-2003 fws" signal systems. This can cause discovery problems. You will need to add the required entries from BR-2003 to the "fws" version. It appears that the only mast type that you are using from BR-2003 is "buffer-stop". After you add that appearance file and related icons to "fws", then you need to edit the 23 occurrences in the panel xml to use custom signal mast system name.

Do you have a couple of specific masts that we can concentrate on?

Dave Sand

I doubt that the CS is in stop mode if functions work. Functions working
on locos implies that function packets are being sent to the loco. In
stop mode there are no track packets.

Other ideas to be shot down
- DCS240 Command station with early firmware? I had similar issues with
one of these
- bad checksums in some packets - the decoder will inore these . That was
the core of the DCS240 issues I had
- JMRI Preferences cocked up: check the defaults pane to ensure that all
items are set to Loconet, and that the connection to the CS is as
expected.

Mick
______________________________________________________________________
Mick Moignard
Specialising in DCC Sound
p: +44 7774 652504
e: mick@...
skype: mickmoignard
IBM Notes and Domino: still has what it takes as an App Dev and
Collaboration platform.

Ok, I will start by making one of the changes in the fork.

However that approach is not really going to be a good long-term solution.

Peter

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

Ken; This is the closest I find
"JMRI applications will not load a panel file that fails XML validation; an error will be shown that should explains the error, allowing it to be fixed using an editor. (The explanations remain a work in progress.)"
from

Walt

Mike,

On Jun 20, 2017, at 11:41 PM, mike@... [jmriusers] <jmriusers@...> wrote:
You may be right on the lh100 but I think it’s the LZV100 that has different options, for auto, manual startup etc.

That isn't what I was referring to. There is an option on one of the throttles ( it may be the LH90 ) for setting the stop button to send an off or an emergency stop.

The manual/auto power up option on the LZ100 and LZV100 has to do with whether or not the system turns functions back on after startup.

So far, I’ve found that the command station has provided an interface version and XpressNet version (3.6) but replies with the command station does not know this command (61 82) to a request for the stack (e3 5 0 0). I know this from monitoring the IP network and also from Xcode debugger. JMRI displays waiting for response from command station in its activity monitor.

If we are getting a command not implemented response, then that particular function ( the stack in this case ) won't work, but that doesn't keep JMRI from proceeding. ( it may keep the

I get this same behaviour on all connection types: Wi-fi , LAN and XpressNet on Lenz interface.

How do you have JMRI configured?

With the LH100 I have tested the DR5000 and the Set 100 and found that the LH100 “remembers” loco function status, speedster etc and rebroadcasts this after a power cycle of the LZV100. This is not the case with the DR5000 which the LH100 assumes all locos are set to stop and all functions off.

That is certainly allowed. The LZV100 has an eeprom that it uses to record the status of functions when the power is turned off. Other command stations ( such as the Lenz Compact ) don't store this information between sessions, so the DR5000 isn't acting strange in this case.

This information is not broadcast though as any running loco will keep running after a power cycle until it has some sort of update such as function changed. This is presumably because the decoder is using its memory and after cycling the DR5000 power it’s not instructed to do anything different.

I don't know of any decoder that would do that. When a decoder looses power, it requires a packet to know what to do next.... unless it is set to run with analog conversion enabled, in which case it may interpret a distorted signal as an analog signal.

This leads me to think that the DR5000 is not implementing the stack, despite the option being checked.

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.

You may not be able to search the stack, but ,that doesn't mean it doesn't exist.

Indeed, when using JMRI’s stack manager, the activity monitor just keeps “waiting for reply from command station” (quote from my memory!)

The stack monitor might do this, but the stack monitor isn't the important thang here.

The real question is how does a throttle behave. The throttle will ask for status of a specific address ( it doesn't search ) and it will either get a response it can use or it will move on.

FYI, the DR5000 has an English manual at www.digikeijs.com

I have a couple of questions you may be able to help with.

1. Is there a vendor ID in the XpressNet protocol? I don’t see any reference but this would be useful for auto discovery. (Much like the vendor ID for decoders).

No. All it has is a command station type and version.

2. Does XpressNet have any more detail for command station type than the 3 in the XpressNet protocol manual from Lenz? I.e. That manual specifies Le/LZV100. LV200 and Compact. Do you know if hardware vendors are assigned or supposed to use their own identifier? The DR5000 appears to identify itself as an LZV100, does the Z21 for example do the same?

Officially only the 3 in the XPressNet manual are allowed. I know Roco has defined their own values, but those are not official.

3. Do any other XpressNet devices you’ve worked with other than Lenz implement the stack ok? I.e. Do they respond to e3 5 0 0 with a valid response?

Some do, some don't. As I said before, searching the stack isn't important.

Paul

Ken,

Again thanks. I read all the release notes for 4.7.x and didn’t see anything regarding normalizing names that have leading space(s). Not sure if trailing spaces are included in the process.

Marshall

From: mailto:jmriusers@...
Sent: Tuesday, June 20, 2017 12:36 PM
To: jmriusers@...
Subject: RE: [jmriusers] Re: Problem with leading spaces in a sensor "username".


I checked and 7.4.2 was the beginning of it, but I think there were more
changes a bit later. But I'd ask if you think you see mention of it in the
notes. Sometimes what gets entered into the notes is not the best wording.
It may have made sense to the coder but not the user. If you think it isn't
mentioned in one of those, or was poorly worded, let us know.

-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

The first thing is to ensure that you have reinstalled the SiLabs CP210x drivers from the SiLabs website:
<>
and that the driver is loading and at which COM port (a Windows reinstall will quite likely change this).

Please check the above and then
- Tell us what jumpers you have on the NCE USB.
- Start JMRI, immediately go to the Help->System Console menu item and click on "Copy to Clipboard". Paste this into a post for us all to see. Without a Console Log we are advising blind - we can tell a lot from the console log.
--
Dave in Australia

Armidale NSW 2350, Australia

Jim: I saw you signature after I had posted. If "Breezlys" fix did not fix it, can you control the locos with a Digitrax hand held throttle?
Walt