Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Locked DR5000 XpressNet
|
Hi, I am trying to get to grips with the DR5000 with JMRI on XpressNet over LAN or WiFi.
So far, I am having some issues, so I am wondering if anyone has come across them or know of fixes! Firstly, is the DR5000's XpressNet implementation somewhat buggy? For example, when I plug in an LH100 Lenz handheld, Pessing the power off / on button does restore the track power, but does not cut it out, is this by design in the DR5000? Secondly, when I connect to JMRI via the LAN (with XpressNet setup) I cannot seem to get a consistent connection. The XpressNet Activity monitor keeps trying to get the command station status but gets no response. Also, I can use a throttle window to control a loco, but when I hit the power button it turns the track voltage off, but will not then re-store it? I assume it is because the command station is not responding to the request, or actually, not giving a status update that it has carried out the shutdown event. Any thoughts? Thanks Mike |
|
Further testing has found that the stack appears to not work. When I set the stack to be available, it does not appear to respond to the XpressNet command to view the stack. The response given back is that the command station does not know what the request is/does not support the command. Has this been found by the JMRI developers also?
Thanks Mike |
|
Mike,
On Jun 17, 2017, at 11:30 AM, mike@... [jmriusers] <jmriusers@...> wrote:On the LH100, I believe there is a setting that sets whether the stop button sends an off or an emergency stop. ( I may have that confused with another device though, not looking at a manual and my LH100 is not unpacked yet.) Secondly, when I connect to JMRI via the LAN (with XpressNet setup) I cannot seem to get a consistent connection.Is this via an LIUSB-Ethernet, or some other connection? Do I remember correctly that the DR5000 has an Ethernet port of its own? I may have asked for this before, Is there a manual for the DR5000, preferably in English. The XpressNet Activity monitor keeps trying to get the command station status but gets no response. Also, I can use a throttle window to control a loco, but when I hit the power button it turns the track voltage off, but will not then re-store it? I assume it is because the command station is not responding to the request, or actually, not giving a status update that it has carried out the shutdown event.Any of that is possible. Every manufacturer seems to interpret the XPressNet protocol slightly differently. Sometimes each device has a different implementation ( this is true even with the Lenz interfaces... ) I can tell you this, if you're you are using the Lenz LIUSB-Ethernet, I wouldn't expect anything to work correctly in JMRI that doesn't work correctly using the LH100. Paul |
|
Thanks Paul.
The DR5000 has Wi-fi (router) and lan built in. I have tried to use LAN, Wi-fi and also a Lenz 23151 LAN/USB with XpressNet to the DR5000 I have got a set 100 also, which I¡¯ve tested with for a datum. You may be right on the lh100 but I think it¡¯s the LZV100 that has different options, for auto, manual startup etc. 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. I get this same behaviour on all connection types: Wi-fi , LAN and XpressNet on Lenz interface. 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. 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. This leads me to think that the DR5000 is not implementing the stack, despite the option being checked. Indeed, when using JMRI¡¯s stack manager, the activity monitor just keeps ¡°waiting for reply from command station¡± (quote from my memory!) 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). 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? 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? Thanks for the help Mike |
|
Mike,
On Jun 20, 2017, at 11:41 PM, mike@... [jmriusers] <jmriusers@...> wrote: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.comNo. 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 |
|
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 |
|
Mike,
On Wed, Jun 21, 2017 at 3:08 AM, mike@... [jmriusers] <jmriusers@...> wrote: Thanks again Paul,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.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 theIt'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 |
|
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 willRight, 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'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 |
|
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 willRight, 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'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 |
|
Mike,
On Jun 21, 2017, at 10:54 AM, mike@... [jmriusers] <jmriusers@...> wrote:Our Elite support took quite a bit of work. Hornby decided to do things that no other XPressNet vendor has done, including ignoring required responses.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 I would try setting the DR5000 up as a Loconet connection and see what happens when you configure JMRI to connect to it using Loconet over tcp/ip configuration ). Loconet throttles require the ability to modify a slot ( Digitrax' equivalent to a Lenz command station stack entry ) to change information about a mobile decoder. From the JMRI perspective, if that behaves correctly, that may be the best way to use the DR5000.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 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.Let me see what I can do. That may take a day or two to get to. 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.You probably won't see much improvement. In fact, things could be worse. 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 theLooking at the manual ( which provides no real technical details for us ) I get the impression this just isn't supported. One of the software configuration screens shown basically says "ignore the previous state". Paul |
|
To access the loco slots on a DR5000 you need to connect to it via a Digitrax connection. I normally connect via the USB port which allows JMRI to connect by both Loconet and Xpressnet and also the DR5000 configuration software all at the same time on virtual com ports with the one cable.
From JMRI's Digitrax slot monitor you can clear slots etc. On Xpressnet, loco function setting (F1), MU, stack and other functions do not work. It also doesn't report stack full, but will report slots full on a Digitrax throttle. As the DR5000 is updatable, they may add these functions in the future. The RS bus has been added in the last year and a WiFi throttle is supposed to be in the works, I haven't had success connecting a computer by WiFi, but have only tried once and the tablet I use doesn't have ethernet, so haven't done that either. I have used a LIUSB on Xpressnet which also works with JMRI. Mike Ruby |
|
Mike R,
On 06/21/2017 01:16 PM, mike_rby@... [jmriusers] wrote: To access the loco slots on a DR5000 you need to connect to it via a Digitrax connection. I normally connect via the USB port which allows JMRI to connect by both Loconet and Xpressnet and also the DR5000 configuration software all at the same time on virtual com ports with the one cable.When you connected via the LIUSB, does the system have the same limitations as when connected via the DR5000's USB port? Just checking because it sounds to me like the device may be a bit of a work in progress, a moving target of sorts, and we may not want to put anything special to handle it in JMRI until everything settles out with the development. (plus, from the JMRI perspective, if the LocoNet side of things works, we should be able to do everything there we would do from the XPressNet side of things.) Paul |
|
Yes no matter how the xpressnet is connected (USB or xpressnet) you get the same functionality. POM and accessories (up to 256) also work. I'm still experimenting and don't use it as a main system myself at present. We found a lot of this out at a recent modular meeting where we had Loconet, Xpressnet and wifi throttles connected connected to a DR5000. The Lenz throttles stopped adding new locos with no reason showing. It wasn't until someone noticed slot full on a Digitrax throttle that we realisied the problem. The Lenz data base didn't work, but running Decoderpro with a Digitrax connection we could access it under the Loconet monitor slots, where we could clear unused slots and the Lenz throttles worked again.
It did prove the DR5000 works with both systems, running both types of boosters and throttles, just make sure railcom is off (on by default) when using boosters without it, that caused problems all weekend! We didn't figure it out until later when trying to reproduce the problem. I have tested the RS feedback bus and that works correctly on the DR5000, so long as the address offset is set to zero it matches a Lenz system. A while back I did enquire about Lenz consisting and was told it was in the next update, but wasn't! I now consist using CV's 29 & 19, which also gets past the Lenz no consist function problem when running on Lenz. The system is still being developed and is easily updated from a download via the configuration software. Mike |
|
Thanks for the info guys.
It appears that the stack is not yet implemented correctly in the DR5000. Having spoken to them, it may be that we come up with a beta software for the DR5000 to then develop with for JMRI and from my point of view for TouchCab. If we can get the beta software working correctly, in theory, there should be little work to do from a JMRI point of view to support the DR5000 fully, since it should currently do everything the LZV100 does with the exception of consisting. It should then just need a few identity tweaks for the XpressNet Info tool in JMRI. Paul, when I get the time to look into this more, I'll give you a PM to discuss if OK! Thanks Mike |
|
For USB you just need to connect to the DR5000 direct. Three com ports are then made, one for the DR5000, plus Loconet and Xpressnet ones, JMRI can then connect via either or both. The DR5000 software can also run at the same time. An LiUSB can be used if further from the DR5000 than a USB lead reaches.
Mike Ruby |
|
I managed to get JRMI on a Macintosh working with the DR5000 with your help and another?post. ?
After making sure I had the correct drivers from??I connect the?Macintosh directly?to the ?DR 5000 to the using a USB cable. I set the DecoderPro preferences just like the link you sent me New Connection?LocoNet System Manufacturer?Digitrax System connection?Loconet LocoBuffer-USB Serial Port?cu.usbmodem411 Command station type?DSC100 (Chief) Connection Prefix?L Connection name?Loconet I did not adjust the additional settings. To?programme decoders, I set the Program Type to?Direct Byte in the Roster window It works very well now. ?I can use all the features now. ? the?z21?app on my phone works, a wired Roco throttle works via XpressNet, and DecoderPro works via a USB Cable. All at the same time. Thanks for your help |
John Kabesh
Petr ?¨ªdlo
to navigate to use esc to dismiss