On Jan 4, 2019, at 2:09 PM, Peter Ross <peterr@...> wrote:

Thank you Bob, that has been quite helpful. For example, based on using the Help explanations, why not put "Recover data from the decoder" instead of "Read changes on sheet”?

Because that’s not what it does. Your phrase hasn’t captured that it’s only “recover(ing)” _some_ of the data, and which data will be recovered.

And something like, "Write only what has changed" instead of "Write changes on sheet”.

Because that’s not what it does. It only writes what was changed _on_this_sheet_. Changes that have been made on other sheets are not written by that button. There is another button, which uses the word “all” for those. You also made it longer by changing “changes” to “only what was changed”. Maybe “changes" is too short, so "changed values" might do, but “what was changed” is verbose and “only” is redundant: _Everything_ only does what it does.

Likewise, "Read all from the decoder" instead of "Read changes on all sheets”?

Because that’s not what it does. It only reads what was _changed_.

And, "Write all to the decoder"?
So (within the limitations of this text format), we could have (note preamble to each row of buttons):
"For CVs on this pane only: Recover values from decoder/Write changes to decoder/Read all from decoder/Write all to decoder."
"For the entire range of CVs: Recover values from decoder/Write changes to decoder/Read all from decoder/Write all to decoder.”

What’s the difference between “recover” and “read”? Perhaps I’m not understanding some change in how the program works that you’re proposing. (I’m also not sure what “entire range of CVs” means: What range? The visible things on the page are variables, not CVs: They may or may not correspond to a particular set of CVs that appear on other pages too)

In general, it’s less confusing if a button says what it does. Having two buttons with exactly the same language right over each other that do different things is not generally viewed as quick & easy to understand:

Necktie [Put On] [Take Off]
All Clothes [Put On] [Take Off]

Which button do I press when I get on the bus home? (.c.f one of my favorite Farside cartoons about UI design: )

Bob

--
Bob Jacobsen
rgj1927@...

I had to think about it for a few seconds when i came across the terminology in JMRI. Then realised. Think of each decoder as a booklet or loose leaf folder of instructions. These are grouped into sheets in this folder. Each sheet of instructions (or CV's) can be read or written separately, as well as a whole folder. Simples

Just internally translate 'Sheet" to "Tab" or "current page with data".
Like when the folks across the pond say 'Bonnet" you think "Hood". (Or is that "Trunk"? Car part anyway.)
And 'Fair Dinkum" means happy Aussie or some such.

Any new company or group has its own terminology. Learn the lingo and you get the precise meaning.

Thomas
DeSoto, TX

That would be the railcom that I turn off in all my Loksound decoders.
Only a small subset of decoders have that feature, and older decoders of the same brand may not work the same..And we never throw out a working decoder, right?
You are asking for a feature that cannot be retrofitted, and that the Decoder makers see no profit in providing.

At the Club ( with hundreds of roster entries) we make use of the Owner data field. If you get duplicate matches, look at the owner.
And if you have more than one copy of a Lok learn how to renumber the thing. (I have about 6 duplicates on that list).

Someone years ago suggested using CV 105 & 106 as extra match fields. Most NMRA decoders have those. (more than have RailCom) Did that fall out?
The user would have to put data in those CVs, but they are right there on the basic sheet. Maybe too easy?

Thomas
DeSoto, TX

[If JMRI is running on an RPi and talking to the layout via LocoNetOverTcp, there’s no need for a panel to be open on the main machine. It can be opened independently on the client RPi (or not). As far as that client is concerned, it thinks it’s directly connected to the layout and can do whatever it wants independently.

If you’re talking about LayoutEditor panels, you have to be a bit careful because they’re also a way to instantiate layout _logic_. You want some machine, but only one machine, to be running the signals, for example.]
So what it appears I can do is have the 'dispatcher' JMRI instance run with its LayoutEditor panels for real time and linkage.? PanelEditor panels on Pi ZX's with touch screens with their own JMRI instance(s).? As long as the switch addresses (tables) are congruent across all the instances (back end a front end of the yards have the same addresses - no conflict with the mainline). No signaling in the yards.??

The single Loconet-USB at the dispatcher station should not get overrun?

One benefit of this is that the main 'layout' xml file gets smaller (currently ~25k lines) and making changes for UI or operations at a particular area can be done independently?

Thanks for all your assistance,
Martin Booker

Thank you Bob, that has been quite helpful. For example, based on using the Help explanations, why not put "Recover data from the decoder" instead of "Read changes on sheet"? And something like, "Write only what has changed" instead of "Write changes on sheet". Likewise, "Read all from the decoder" instead of "Read changes on all sheets"? And, "Write all to the decoder"?
So (within the limitations of this text format), we could have (note preamble to each row of buttons):
"For CVs on this pane only: Recover values from decoder/Write changes to decoder/Read all from decoder/Write all to decoder."
"For the entire range of CVs: Recover values from decoder/Write changes to decoder/Read all from decoder/Write all to decoder."
Regards
Peter

开云体育

Dave

The miss understanding is probably because we are upside down and see things differently!

Gerry

It seems my antipodean sense of humour/satire/frustration gets lost other side of the pond.

Infernals is a play on words, describing the consequences and support nightmare created by the unfortunate code decision that caused connection preferences to be set to Internal if hardware was temporarily absent.

Here is the text snippet I usually posted in response to this problem:

"If you get "Found mfg 123 (Masoth Electronic, GMBH) version 123; no such decoder defined.", and/or all CVs return a value of 123 and long address 15,227 it is 100% certain that you cannot communicate with the decoder and that one of two possibilities have happened:
1) Preferences->Defaults has Service Programmer (and possibly other items) set to Infernal.
2) Preferences->Connections has System Connection set to Simulator.

Possibility (1) is the most likely. It would most likely have occurred due to a previous failure to open a connection. If there is no alternative to Infernal, you currently have a problem with the connection to your DCC system and you need to resolve the connection problem before proceeding. If an alternative is available select that, restart JMRI and try again.

Warning, the Infernal problem can happen again in the future if you have any connection problems. See comments at:
/g/jmriusers/message/153294

This has hopefully been fixed in JMRI V4.14"

-- 
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator

Try "Read Full Sheet" on the CVs pane instead. It is less likely to cause errors when reading a decoder with lots of CVs.

Once finished, some may be missed (displayed in red). Use "Read Changes on Sheet" until no red items remain.

Hint: Click on the Status column until you see a down arrow. All the Red items will be at the top.
--
Dave in Australia

开云体育

开云体育

I am using Decoder Pro 4.12, Windows 7 and a Sprog II with an isolated programming track.? I recently purchased an Athearn RTR SD-50 with an Econami sound decoder.? When I go to make a new roster entry will I have any problem with Decoder Pro recognizing that decoder in that engine?? This is my first Econami decoder equipped loco and I want to know if I am going to have to jump thru any special hoops.
Thanks,
Bob

开云体育

Andy,

There are no dumb questions!

When you look at the 3-way turnout's hardware itself, there are 2 sets of switch points and they need to move, Thrown or Closed. 2 Tortoises, 2 servos, 2 manual gadgets or 2 something elses. So, yes, in JMRI it is currently done with 2 turnouts. Fairly easy to use Routes in JMRI to control the thrown and close of the needed turnouts to get you to the 1st, 2nd or 3rd path by activating a sensor. So, if we put Routes in MQTT, then the relevant subscribers could be told to do something when topic DFW/clublayout/module001/yardladder/route gets a message like "3".

MQTT is not a wireless protocol, TCP/IP is all you need. It became very popular with IOT devices, and that gave it the wireless flavor. The fear about the adjacent layouts being controlled by the same MQTT subscription will need to be just as you would if they were DCC controlled accessories on the same command station. If two modules both use the same DCC address (example #145) for a turnout, both will move. For an MQTT implementation, DFW/clublayout/module001/turnout002 would not interfere with DFW/clublayout/module006/turnout002 or myownlayout/module001/turnout002, if they where to connect to the same MQTT broker. And then of course, JMRI would also need to have all the turnouts in the same table, and thus unique as well. (One of the smart things in LCC/OpenLCB is the 64-bit addressing that would help keep all LCC devices on the planet unique.)

Back to the wired versus wireless question, with a NodeMcu now costing , I do not know how a "wired" Ethernet implementation would beat that! Noise is a good topic, but not for this thread, this is MQTT in JMRI, and not a "wireless" thread.

Speed

--

Simply saving with no EXIF data doesn't help at all unless the software has actually read, rotated and resaved the image (usually a lossy procedure for JPEG files).
--
Dave in Australia

It seems my antipodean sense of humour/satire/frustration gets lost other side of the pond.

Infernals is a play on words, describing the consequences and support nightmare created by the unfortunate code decision that caused connection preferences to be set to Internal if hardware was temporarily absent.

Here is the text snippet I usually posted in response to this problem:

"If you get "Found mfg 123 (Masoth Electronic, GMBH) version 123; no such decoder defined.", and/or all CVs return a value of 123 and long address 15,227 it is 100% certain that you cannot communicate with the decoder and that one of two possibilities have happened:
1) Preferences->Defaults has Service Programmer (and possibly other items) set to Infernal.
2) Preferences->Connections has System Connection set to Simulator.

Possibility (1) is the most likely. It would most likely have occurred due to a previous failure to open a connection. If there is no alternative to Infernal, you currently have a problem with the connection to your DCC system and you need to resolve the connection problem before proceeding. If an alternative is available select that, restart JMRI and try again.

Warning, the Infernal problem can happen again in the future if you have any connection problems. See comments at:
/g/jmriusers/message/153294

This has hopefully been fixed in JMRI V4.14"
--
Dave in Australia

I have a bunch of probably dumb questions, but here goes...

I keep seeing references to turnouts having only two states.? How many states are they allowed to have, or is there another entity that can be used to control more complex track work?? E.g my old club has a 5 way turnout and 3-way turnouts are not unusual.

I myself am planning a traverser for one of my trolley barns. That will have at least two input tracks and a lot of barn output tracks. Presumably I don't have to treat that as some large number of multiple 2 state turnouts ?

While I'm not contemplating reading up on MQTT anytime soon, I was wondering if the simplified text string addressing mentioned is confined to a single or defined limited group of connected RF networks.? I'd hate to see a model railroad exhibition where ". . . /turnout/7/thrown" operated that same numbered turnout on half a dozen adjacent layouts.

Having a somewhat noisy and jumbled industrial environment where I test run various types of model trains, I tend to to follow my thrifty instincts and only use wireless where at least one device in a network (or sub-link) is mobile. If all relevant devices are fixed, then wire suffices and is typically far less costly.? Is this group similarly minded, or is there an underlying agenda make all comms wireless for consistency (or fun) ?

Andy



On 1/3/2019 9:49 PM, Dave wrote:

Thanks Chris, clearly we can exceed 64 bytes with ESP8266?devices?- your example has 207. Perhaps when the 64 character limit was mentioned, it was with some other device in mind.

I have looked further into the possible inconsistencies between Heads and Masts I mentioned yesterday.
Flashing is no issue. the xml files for appearances use "flashred" but when a head is included in a mast, the head shows this as "Flashing Red"
Regarding Lunar, it depends on which options you choose in creating the head. Virtual Heads do not have Lunar as an option. If you include that in a Signal Head Controlled Mast, the head appearance becomes null so could be considered as a bug or limitation in the current use of Virtual Heads with Signal Head Controlled Masts.?This digresses a bit from the objective of this discussion but worth mentioning as a reminder when coding for MQTT signal heads that Lunar and Flashing Lunar should be permitted. If we could add flashing frequency to it, I could say the Lunar ticks are on the Mast (apologies to Pink Floyd and everyone reading this, there's someone in my head but it's not me.)

Getting back to business, the objectives here are to define precisely what content and syntax will be created by JMRI for MQTT messages from the information held in JMRI and for sensors, to define the content and syntax of MQTT messages created by a remote sensor when it announces its state so that JMRI can interpret that message to identify which JMRI sensor it is and update its status in JMRI. Then Bob can do the coding.

The current format already in JMRI for turnouts only is /trains/track/turnout/{number} {state}? ?e.g. ?/trains/track/turnout/27 THROWN
The hardware address is MT{number)? e.g. MT27? where M is the prefix assigned to the MQTT connection and T for Turnouts. The prefix may not always be "M", MQTT connections do not have exclusive rights to the letter M so another connection may already have used "M".

For the topic, I think there is general acceptance that we retain the existing topic syntax though allow the first two components can be user choice and number can be text of user choice.? I suggest Bob can decide whether or not it should include the two character prefix, currently it doesn't, perhaps it should. Technically, the first two topic levels (trains/track)?are actually the second and third levels, with the top level, the bit before the first slash, being null so that means we could use that extra level if we want without breaking compatibility with the existing structure. Sensors may need to be pinned down a bit more so that JMRI can be programmed to handle it.


For payloads, in the interests of keeping things simple and clear, I'm suggesting the payload be the state (or equivalent) as shown in JMRI,

Device type? -? ?Payload options
Turnout? ? - Closed | Thrown
Sensor? ? ?- Active | Inactive
Light? ? ? ? -? On | Off
Signal Head - Red | Yellow | Green | Lunar | Dark | Flashing Red | Flashing Yellow | Flashing Green | Flashing Lunar

This doesn't rule out extending this list to other items in future.
These could be simple text or in JSON form like {"state"="ACTIVE"}

I think this will get a lot of people a long way but there are cases where more complexity may be required. I think we're a long way from deciding what else people might want, where the information might be stored in JMRI? and what to do with it? so we may need to leave that for an "Advanced Settings" future option when people get a better idea of what is useful and how it will come together.

The JMRI sensor handler can subscribe to "+/+/+/sensor/#"? to capture all sensor input.The topic level following "sensor" should match the hardware address for the relevant sensor.? The preceding levels can be used as optional filters if desired.

I'm happy for other suggestions but we need to be specific so we have a tangible specification for programmers to work with.

Kind regards, David.

---
This email has been checked for viruses by AVG.

Long button names like “write to the decoder those variable values that are showing here as changes on this screen now, but not those that are showing as changed when you select a different one of the tabs at the top” can be helpful for beginners, but they’re a pain once people have read them once or twice: You have to look hard at long sentences to figure out how it differs from some other one, like "write to the decoder all variable values that are showing here on this screen now, but not those that are show when you select a different one of the tabs at the top"

Short messages like “Do!” or an emoji are an over-reaction to that, clearly, but there is some value in having short button names.

Luckily for beginners, we’ve got pretty extensive help pages that people have been writing & indexing over time. So, for example, if one went to and put “write sheets” in the search block, you’d find:



which explains exactly what’s going on with those buttons. (Lots of other search strings get there too)

If people want to propose clearer _and_ short terminology, that’s great. Particularly if they put a bit of time into understand what the buttons do first.

Bob

Could I just say that as a relative newcomer I still find the term "sheet" confusing. You obviously know what you mean but at best the word seems superfluous and at worst confusing. If you mean "read decoder", why not say so? And for "write changes", why not something like "write changes to file". If I recall correctly "sheet" is mentioned four times with what seem to be four different meanings.

Not that I don't appreciate what you do for us, just saying that from this user's perspective the terminology is not helpful.

--
Bob Jacobsen
jacobsen@... +1-510-708-5988 AIM, Skype JacobsenRG

I put some tests of the current RosterFrame behavior in java/test/jmri/jmrit/roster/swing/RosterFrameTest.java on my bobjacobsen/add-roster-loco-id-checks branch available in GitHub.

To help with exploration, they leave the window open for some seconds at the end so one can see what’s happening (i.e. they need a bit more work before being merged)

The tests confirm that the RosterFrame’s Ident button does use CV7 and CV8 if there are duplicates of the address. If does _not_ check those for a match if there are no duplicates (I can see that going either way)

Right now, allowing multiple selection is (inconsistently) discussed in the code, but it doesn’t seem to actually happen. The act of selecting a line updates the information on the bottom of the frame with the specifics of _one_ entry. So even when there are two matching entries in the Roster, and the Roster query returned them both, only one is displayed.

Given the desire to have that bottom-of-screen info, I’m not sure what the right user experience is.

Bob
--
Bob Jacobsen
rgj1927@...

开云体育