On 08/05/2019 11:36 PM, Paul Bender wrote:

Billlybob,

On 08/05/2019 11:13 PM, billybob experimenter wrote:

Simply removing the first 4 bytes will NOT result in a valid LocoNet message! The first byte of a LocoNet message (the "OpCode" byte) _must_ have its most-significant bit set. Using your process, the first byte of the LocoNet message would be 0x01, which is not a valid LocoNet "OpCode".

Regardless of whether or not the LocoNet payload in the message is
valid, the Z21's A4 opcode indicates the payload is a LocoNet Detection
message and we aren't currently passing that to the LocoNet stack.

If I am not mistaken, the Z21 just passes the information it receives
from the LocoNet to us.

For what it's worth, the example message in the Z21's documentation is:
0x07 0x00 0xA4 0x00 0x81 0xF8 0x03

that makes the loconet message 0x81 0xF8 0x03.

Paul

Be careful when interpreting the "track status" messages shown in the LocoNet slot data (and visualized in the LocoNet monitor).

Some command stations provide erroneous information about track status, especially following command station power-up, before any LocoNet message tries to control the DCC track power. This is a known problem with certain DCS100 command stations with early firmware. It may also affect other DCS100 firmware versions and possibly other command station types.

So far as I can tell, this problem only affects a small number of DCS100s, and the vast majority of users do not use any hardware or software which makes any use of the erroneous data, so the effect of the problem is nearly non-existent, at worst.

There is _nothing_ that JMRI can do when the command station provides this erroneous track power status - JMRI cannot predict whether the data is correct or wrong, so it can _only_ report the data that the command station provides.

The best way to avoid the problem (if you have a command station which exhibits this problem) is to send a LocoNet message to turn track power off then turn track power on using your favorite method (i.e. Throttle, properly-configured DS54 input pushbuttons, DCS50/51/52 front-panel pushbutton, or via computer software). JMRI sees the LocoNet messages to turn track power off and on, and follows that status appropriately.

So far as I know, the JMRI "Power Control" tool (under "Tools"->"Power Control") will send the proper messages to LocoNet, so long as the JMRI configuration profile has properly indicated the correct connection for the "Power Control" setting in the "defaults" preferences. I believe that the same holds true for the "track power" button on the DecoderPro window - if the "defaults" have the correct "connection" specified for "Power Control", then the pushbutton will send the correct messages.

The only track-power "oddness" I am aware of is how certain command stations behave with respect to the LocoNet request to "IDLE" the DCC track signal. Older command stations support the concept, while some newer Digitrax command stations appear to treat the LocoNet "Track IDLE" request as a request to turn track power "ON". I do not see this as a shortcoming of JMRI.

If there are additional issues with JMRI and track power control of Digitrax command stations, I would love to hear the details (in a separate thread!)

Regards,
Billybob

Billlybob,

On 08/05/2019 11:13 PM, billybob experimenter wrote:

Simply removing the first 4 bytes will NOT result in a valid LocoNet message! The first byte of a LocoNet message (the "OpCode" byte) _must_ have its most-significant bit set. Using your process, the first byte of the LocoNet message would be 0x01, which is not a valid LocoNet "OpCode".

Regardless of whether or not the LocoNet payload in the message is
valid, the Z21's A4 opcode indicates the payload is a LocoNet Detection
message and we aren't currently passing that to the LocoNet stack.

If I am not mistaken, the Z21 just passes the information it receives
from the LocoNet to us.

Paul

Steve G,

Strange, I've not heard of problems with using JMRI for control of the
layout power. Yes, issues with the built in USB on the newer command
stations. Do you have a GitHub issue id I should read about?

I know a number of layouts that use the JMRI control of track power on
Digitrax systems. Granted none of them are using the latest command
stations.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Paul,

Simply removing the first 4 bytes will NOT result in a valid LocoNet message! The first byte of a LocoNet message (the "OpCode" byte) _must_ have its most-significant bit set. Using your process, the first byte of the LocoNet message would be 0x01, which is not a valid LocoNet "OpCode".

Regards,
Billybob

On Aug 5, 2019, at 6:32 PM, bossevest@... wrote:
Z21 Traffic JMRI

<snip>

23:39:40.763: [08 00 A4 00 01 91 01 01] 08 00 A4 00 01 91 01 01
23:39:41.179: [08 00 A4 00 01 CB 00 00] 08 00 A4 00 01 CB 00 00
23:39:43.894: [08 00 A4 00 01 CC 00 01] 08 00 A4 00 01 CC 00 01

I believe the problem is that messages like the ones above should be translated by the Z21 code into LocoNet messages, but that isn’t happening.

The good news is that should be quick to fix if that is the case. The first 4 bytes of those messages ( 08 00 A4 00 ) are the Z21 header. The rest of it should be a LocoNet message.

Paul

There are a number of issues around Digitrax track power that have not yet been resolved. The best advice is to ensure that track power is on before starting JMRI PanelPro or DecoderPro. And do not turn it off or on from JMRI.
The problem is particularly acute with any of the command stations with built in USB ports, and/or slow computers (think Acer One or Pi 2's.)
Steve G.

开云体育

On Tue, Jul 30, 2019 at 11:46 AM, Paul Bender wrote:

My intention is to use that second file as a guide for writing the script, with the changes required to make this work within JMRI.

?

Paul, this sounds great! I use lots of servos on my layout, currently driven by the excellent Tam Valley QuadLN-S boards, but I also have the SparkFun pHat board and would love to be able to use it from JMRI. I'd be glad to help with testing or even coding once you get the basic JMRI framework in place.
--SteveT

Thank you.?

THANK YOU. I checked the “Requires Drive Sound” and that solved the problem. I also reduced the volume. It was a fan on the prime mover and now it too shuts down when I click (shift F-8).?
PROBLEM SOLVED. THANK YOU?
Frank?

The slot monitor messages also contain the power on/off bit. If JMRI is, for some reason, not seeing messages come back from the LocoNet, the slot monitor messages might be fooling it into thinking that it knows the status anyway.

Bob

On Aug 5, 2019, at 5:22 PM, Ross Kudlick <Ross_Kudlick@...> wrote:

We use a LocoBuffer-USB ver 2.070. No dip switches.

What's interesting is seeming having communication with the Slot Monitor open.

--
Bob Jacobsen
rgj1927@...

Bob,

We use a LocoBuffer-USB ver 2.070. No dip switches.

What's interesting is seeming having communication with the Slot Monitor open.

Ken Cameron reviewed the 'debugging' information I posted. I've got some things to check tomorrow.

Thank you for all the help.

Ross

Just an update for those interested: Travis discovered that Windows 10 treats normal users different than Administrators when it comes to opening TCP/IP connections as used for MQTT in JMRI.

So if anyone else ever experience this kind of problem, please suggest to run JMRI (like PanelPro) with "Run As Administrator", until we know a little more!

Speed

Bosse,

What I would like to know is which of these messages is supposed to be associated with the operation you are having problems with? Simply having a log of bunch of traffic does not help me understand where the problem might be.

You could help us understand the problem by telling us the exact sequence of events you expect. When I work on issues like this, I like to annotate _each line_ of the log file(s) to describe the events on the layout. Something like "this message happened when block X was occupied".

Did _anything_ cause the position of a turnout to change during this sequence of events? Is the "LT112 switch input is closed" happening to indicate that the occupancy of a particular block has changed?

Regards,
Billybob

Since you can turn track power off from JMRI, messages are getting from JMRI through the LocoBuffer to the LocoNet and thence to the command station.

Since JMRI doesn’t see that that has happened, that means that (some or all) messages are not getting _back_ from the LocoNet through the LocoBuffer to JMRI.

I’m sorry, but I don’t remember which LocoBuffer you have. Is it possible that you have one of the early ones that have a DIP switch that selects whether transmitted messages are echoed back?

Bob

On Aug 5, 2019, at 1:22 PM, Ross Kudlick <Ross_Kudlick@...> wrote:

I made an unexpected discovery today when I was able to make a short visit to our club.

If track power is on when DecoderPro starts the icon at the top of the roster correctly shows the track power on state. I can turn track power off but the icon changes to the yellow ‘unknown’ state. I’m not able to turn track power on from DecoderPro. (I turned track power back on using the throttle.)

I added the PowerOn.py script to the startup and the behavior was the same as above.

When I opened the slot monitor I could control track power from the icon. Control was again lost when I closed the slot monitor.

I ‘uploaded debugging info’ titled “NVMR Win10 New Computer” in case it will provide any helpful clues.

Will be back at the club tomorrow to continue working on this.

Ross

--
Bob Jacobsen
rgj1927@...

Partly, you have to expect to spend a bit of time working with it to figure out how the various controls work: What you have to fill in before you can drag something, what you do from the edit window vs what you do with a ctrl-click of the mouse, etc. Since the Panel Editor and Control Panel Editor do lots of things, there are lots of things to learn how to do.

It’s certainly possible that there are bugs. But Panel Editor has been part of JMRI since 2002, Control Panel Editor since 2008, so large parts of them probably work OK.

If something doesn’t seem to work, the best approach is to say “How else can I do this?” or “What might I have to do first?” or things like that. Saying “well, it’s probably broken and I can’’t do it”, although it might be true, is probably not the best way to get to know how to do things.

If you’re falling at the first fence, perhaps you should look around for the gate.

Bob

On Aug 5, 2019, at 2:46 PM, Terry Metcalfe via Groups.Io <terrymetcalfe@...> wrote:

ps why is it i get the feeling that this has either not been fully debugged or am I doing the debugging? :-))

--
Bob Jacobsen
rgj1927@...

Terry,

? ? Look up in the far left top side of your panel and try to click on what ever is up there and drag to where you want it.

Roger

Dave S,

I figured I'd stick to the default mode for LE. I suspect that's what most
users use. I wanted to make sure he'd know which was which that he was
looking at.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org