Is the problem involving JMRI 4.16 and Locobuffer USB a factor? If so, upgrading to 4.17 is apparently the fix.

/g/Digitrax-Users/message/220164

Jan

I used Steve Todd's JMRI image to install working JMRI on my newish Raspberry Pi 3B+. PanelPro is finally working properly on it with simulated connections to my railroad. WiThrottle is working, too. Hurray!

Next, I want to get DecoderPro ready to program and keep a roster of my locos and their decoders, using my EasyDCC Command Station to program them. I created a rister for my existing loco fleet on my desktop PC, and used sneakernet to copy it onto the RPi. All is in readiness. Then, I noticed I have no DecoderPro icon to click to launch DecoderPro, and couldn't find another way to do it. That leaves questions:

As a complete JMRI installation, I'd expect Steve's image to include DecoderPro. Does it?

Might I somehow have not installed or not activated it when I first launched JMRI on the RPi?

If it's there, but not activated, is there some way to restore it and its icon?

Must I reinstall Steve's JMRI image to make it work? And, will that do it?

Don Weigt
Connecticut, USA

Your 3 files are now located here:
/g/jmriusers/files/ProblemsBeingWorkedOn/Haltz

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -

--

Haltz,

And now to a real kicker: I'd like to make my panels (xml file) and 2 scripts available to the forum. I just tried uploading 3 files (names all begin with "haltz"), but have no idea where to find them. Can someone tell me? Thanks.

By going to the Files folder for this group and clicking twice on the word "Uploaded" near the upper right corner of the page, two sorts are provided. The first sort gives us the oldest upload at the top.

Apparently, your files are in the root directory for the Files, and hence most easily lost in the clutter. There are subfolders such as "Problems being worked on" and you can create a uniquely named subfolder there to make it easier for us to find. This also allows you to delete them easily when they are no longer pertinent, and help with the future clutter issues.

As the member who uploaded them, you are able to move these files to a more appropriate location.

The three most recently uploaded files are at:

/g/jmriusers/files/haltz%20run2warrants.py
/g/jmriusers/files/haltz%200blocks1.xml
/g/jmriusers/files/haltz%20stop2warrants.py

Also, anyone uploading a file can do what I just did. Right click (with Windows) on the new filename after it appears in the listing, and then select "Copy link to location" and finally paste the copy in your message.

Maybe that info belongs in a "How to" segment for Groups.io, or maybe it is but not easily remembered.

Cliff in Baja SoCal

I seem to have this problem with one train. The train is a 7 car turn.I use 7 moves in the outgoing yard. When I build the train I show only 6 cars.I cannot find anything in the build report to answer the problem. I have tried increasing the number of moves without any solution. I have longer trains that build without this problem.?
Jerry Hampton?

Don,

Don W,

One important detail: do you still have the original panel file?

Second, a comment about the preferences. I think you said you were using
CMRI, if so, read on, if not skip the rest as not important.

It is easy for a CMRI configured profile to lose the node information. It is
kept with the connection details and things like a port not found or
changing between a physical port and simulator sometimes lose that
information. Then when you start up, it says any of the CMRI devices are
invalid since it doesn't think the matching nodes and boards exist. Any
panel file saved under that condition will not have any of those sensors or
turnouts.

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

开云体育

One way to do something like this would be to turn on the Wiki feature of the group. By selecting the “subscribers and moderators can view and edit” (which means the public can’t, i.e. you have to have joined the group), individuals would be able to set up a Wiki page describing some topic: a particular solution, step-by-step operations, how to debug something, whatever.

There are certainly risks: Unlike the messages, there’s no mechanism for moderation. There’s no access control, so John can change Bill’s writeup, which might be good but might not be appreciated. Somebody could join and dump their manifesto in the JMRI wiki, and it might take time for that to be noticed and fixed, etc. (There is logging and a limited ability to revert changes, so we’d know who did it and could fix minor vandalism quickly)

I don’t know how to evaluate the size of those risks. The hard-working group moderators probably have a better feel for that than I do.

And I’m not sure how many people will step up to write things. The best content for things like this on other projects tends to come from somebody who’s just found a solution, perhaps with help from the group, and writes it up in his own words so it’s understandable by people in that situation. But often people who just solved a tough problem want to move on, not spend more time on it for writing.

It’s an easy experiment to try and it would be easy to end.

Bob

On Aug 23, 2019, at 6:09 AM, Robert Schworm <rkschworm@...> wrote:

Hello fellow modelers.

It appears that many of us are either confused with a concept, a feature of jmri, or how to implement a scheme or strategy. Might I suggest a "how to" depository of solutions, and some training on the concepts of jmri and how to implement them. One person has difficulty with understanding signals and masts, the concept, and the implementation. Along with a detail of a implementation. This would help the rest of us to go to this depository, and study up on a solution. Otherwise, there is great email activity, and the threads are lost after the solution has been achieved, only for the issue to raise it's head later. Thank you for your thoughts on this.

An example is one that crossed me up for many weeks. You have to "open" a turnout xml file before you can see it, and it has to be opened if you expect to see it in the web server.
By simply asking for the turnout table does not mean that jmri will open it first.

Another big one is the complete solution to go from a sensor, into an arduino, to jmri, to the sensor table, to the turnout table, back out to an arduino, to a pin, to a servo or relay, up to the turnout itself. This would include electrical, wiring and sketches.

I apologize if this is already in place and I am not aware of it.

Bob S

--
Bob Jacobsen
rgj1927@...

I think that the most likely cause of the service track failure-to-program is that the Digikeijs DR5000 doesn’t understand the particular LocoNet commands JMRI is using to request a programming operation.

In the past, with other non-Digitrax hardware, that’s been a small matter of a couple options bits in the messages. If we can find those from documentation or some other way, we just create a new command station type in JMRI that sends the needed message content.

But there have also been times when the command station creator didn’t forsee programming operations via the LocoNet connection. That’s harder, because it’ll require a command station update to fix.

Your best bet might be to set the JMRI connection to DCS100 (which uses the Digitrax-recommended messages), get a trace (with box labelled “show raw data” checked) and send that with a question to Mr. Deloof. He might be able to see the issue right off.

Bob

On Aug 23, 2019, at 7:39 AM, James E. Petts via Groups.Io <jamespetts@...> wrote:

Thank you both for your replies.

Bob: I do not have any hand held throttles to use for testing, as the layout is intended to be computer controlled entirely. As to incompatible commands, I have e-mailed Mr. Deloof to ask which command station setting should be used in JMRI. I have not yet had a reply, although I only e-mailed him earlier to-day.

BillyBob - I tried both programming on the main and programming on the programming track, both with the same error message, as reproduced above. I am not too concerned about not being able to read values on the main if this is an inherent limitation: I only tried to do this because I could not get it to work on the programming track. Reading values (other than the address) on the main does work with my Digikeijs DR5000 command station (but not with JMRI - I cannot get any reading to work with JMRI, as described above).

As to the programming on the programming track issues, I will address these in turn.

? Insufficient electrical connectivity with the decoder: I do not think that this is an issue as turning the lights on and off works without problem, as does moving the locomotive.
? Insufficient voltage to program a decoder: I am not sure why this would be the case. There is sufficient voltage to run the locomotive at a moderate speed, so this seems unlikely.
? Using a programming mode not compatible with the decoder or programming device: I have tried both Direct Byte and paged. What other modes would you suggest? I understand that the others are rare and that Direct Byte is generally recommended
? Decoder is malfunctioning: I do not think that this is the case, as I am able to read and write values without difficulty using the DR5000 and its native software.
? Programming device is malfunctioning: this is possible, I suppose, but I am not sure how to test for this, and it is suspicious that I am getting the same fault with JMRI with two separate command stations. Nonetheless, I have written to Mr. Deloof to query the problems that I am having.
? Programming tool is configured to program a decoder type which is not matched to the actual decoder: I have set the correct decoder type in DecoderPro (a Zimo MX617N), so I do not think that it is this. In any event, I am trying to read an individual CV value, so this seems doubtful.
? Programming tool is configured to use the wrong programming interface: there is only one programming interface, unless I have misunderstood what you mean here by "programming interface", being the LocoBuffer USB.
? Programming tool is configured in a way which does not communicate with the programming hardware: I am not sure what this would entail or how to deal with this. However, if I understand what you mean correctly, this seems unlikely: I able to turn on or off the lights and move the locomotive on the programming track using the very same hardware, software and interface that fails when attempting to read CVs.

Thank you again for your assistance: this is most helpful.

--
Bob Jacobsen
rgj1927@...

Thank you both for your replies.

Bob: I do not have any hand held throttles to use for testing, as the layout is intended to be computer controlled entirely. As to incompatible commands, I have e-mailed Mr. Deloof to ask which command station setting should be used in JMRI. I have not yet had a reply, although I only e-mailed him earlier to-day.

BillyBob - I tried both programming on the main and programming on the programming track, both with the same error message, as reproduced above. I am not too concerned about not being able to read values on the main if this is an inherent limitation: I only tried to do this because I could not get it to work on the programming track. Reading values (other than the address) on the main does work with my Digikeijs DR5000 command station (but not with JMRI - I cannot get any reading to work with JMRI, as described above).

As to the programming on the programming track issues, I will address these in turn.

1. Insufficient electrical connectivity with the decoder: I do not think that this is an issue as turning the lights on and off works without problem, as does moving the locomotive.
2. Insufficient voltage to program a decoder: I am not sure why this would be the case. There is sufficient voltage to run the locomotive at a moderate speed, so this seems unlikely.
3. Using a programming mode not compatible with the decoder or programming device: I have tried both Direct Byte and paged. What other modes would you suggest? I understand that the others are rare and that Direct Byte is generally recommended
4. Decoder is malfunctioning: I do not think that this is the case, as I am able to read and write values without difficulty using the DR5000 and its native software.
5. Programming device is malfunctioning: this is possible, I suppose, but I am not sure how to test for this, and it is suspicious that I am getting the same fault with JMRI with two separate command stations. Nonetheless, I have written to Mr. Deloof to query the problems that I am having.
6. Programming tool is configured to program a decoder type which is not matched to the actual decoder: I have set the correct decoder type in DecoderPro (a Zimo MX617N), so I do not think that it is this. In any event, I am trying to read an individual CV value, so this seems doubtful.
7. Programming tool is configured to use the wrong programming interface: there is only one programming interface, unless I have misunderstood what you mean here by "programming interface", being the LocoBuffer USB.
8. Programming tool is configured in a way which does not communicate with the programming hardware: I am not sure what this would entail or how to deal with this. However, if I understand what you mean correctly, this seems unlikely: I able to turn on or off the lights and move the locomotive on the programming track using the very same hardware, software and interface that fails when attempting to read CVs.

Thank you again for your assistance: this is most helpful.

开云体育

James,

Unless you have "special hardware", NMRA's "programming on the main" operations are unable to _read_ CV values. This is a limitation of the original NMRA specification, and is a limitation of most DCC systems and DCC mobile decoders.

There are exceptions, though. All exceptions requrie "special hardware". Do you have appropriate the "special hardware" installed? "Special hardware" means either of:
- a fully-functioning "Digitrax transponding" installation and appropriate decoder, a Digitrax transponding-equipped decoder enabled for transponding, located in a transponding zone, or
- a fully-functioning "RailCom" detection system installation, and appropriate decoder, a RailCom-capable decoder with enabled RailCom feature, located in a RailCom detection zone. For Digitrax layouts implementing RailCom detection, some sort of a "RailCom cutout" device must also be installed.

Failure to meet any of the requirements listed above will prevent CV readback when programming on the main, and will result in the LocoNet activity you see. Other restrictions may apply, possibly including restrictions of what other mobile decoders are in the Transponding/RailCom zone, or even outside of the Transponding/RailCom zone but in the same booster district.

The LocoNet Monitor log info you provided seems to imply that you do have neither of the above hardware installed and properly functioning with appropriate mobile decoder capabilities enabled:

- The command station sees the programming request.
- The command station issues the "LONG_ACK: Function not implemented, no reply will follow." message to state that it does not implement the "feature" to get any read data back from the decoder.
- Because there is no additional LocoNet message (after the command station's LONG_ACK message) from the BDL16x/BXP88/BXPA1 device, or from a RailCom detection device, there is no read data availble, so neither JMRI nor a throttle can present any CV read data from that programming-on-the-main CV read request.

So you should not expect to see programming-on-the-main CV reads functioning correctly!

In short:
- For most users and situations, programming-on-the-main is only usable for CV write operations; CV read operations typically will not provide read data when using programming-on-the-main
- For some users with appropriate installed hardware (and meeting other restrictions listed above), programming-on-the-main can be able to read CV values.
- If you want to read CV values, doing so via the service-mode programming track is the primary method.

If you have problems reading CV values on the service-mode programming track, then you probably are experiencing one of these:
- insufficient electrical connectivity with the decoder (i.e. dirty track, dirty wheels);
- insufficient voltage to program a decoder;
- sound decoder requires more power than provided by programming track output;
- using a programming mode which is not compatible with the decoder or the programming device;
- decoder is malfunctioning;
- programming device is malfunctioning;
- programming tool is configured to program a decoder type which is not matched to the actual decoder;
- programming tool is configured to program using the wrong programming interface;
- programming tool is configured in a way which does not communicate with the programming hardware.

Regards,
Billybob

Richard, that sounds great. Any chance of getting the panel (xml) and/or script files?

Hi Mike,
The Model Electronic Railway Group (merg.org.uk) might well prove to be a source of useful information for you. Their members have designed and produced a range of kits, available only to members, that can monitor and control a whole host of things. Prices are barely more than the cost of the components if you were buying them in bulk so if you can solder electronics and follow instructions they are very cost effective. MERG CBUS is also catered for by JMRI so easy to incorporate into your scheme.
HTH
Fraser