开云体育

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

开云体育

开云体育

Glossary and didn't find INFERNALS.
Can someone define INFERNALS for us "ignoratti"?

??? When you go to Preferences, Default you will find (in my case LocoNet) and Internal (which is a Simulation mode).? I think because on one of the releases it set this to "Simulation" which created many emails "why doesn't it work".?? I think Dave refers to it as "infernal".

-- 
Jon Miller
For me time stopped in 1941
Digitrax  Chief/Zephyr systems, 
SPROG, JMRI User
NMRA Life member #2623
Member SFRH&MS

Like Jon Miller, I at first thought INFERNALS was a joke, or JMRI's tongue in cheek substitute for internal. But, I still don't know what it means, or its proper use. I just checked the JMRI Help Glossary and didn't find INFERNALS.
Can someone define INFERNALS for us "ignoratti"?
Can someone add a definition to the HELP GLOSSARY?

I appreciate that the programming of JMRI, and those giving aid to the group, know far more about programming and software than I. You perform a great service for the rest of us. But, we sometimes find your writings incomprehensible. Adding more terminology to the GLOSSARY would be very helpful!

Don Weigt

with you guys'?advice back in july, i simply replaced the suspect adapter with a new one, and all has been great. until now :(

all of a sudden, the pi does not know the serial assignments for the usb dongles at boot-up. (one for cmri, one for nce command station). if i unplug them both and plug them back in, then they are there and everything works fine. i forget which pi version this is, it has 4 usb ports but pre-wifi.

anyway, i see this system on thursdays, and next week i plan to try some persistence tricks with /etc/udev/rules.d/* and symlink. i just think it is odd that it has worked fine until now.

thanks for any thoughts.
calvin.

Where in central Minnesota?? I live in St. Paul, but I occasionally travel for work...

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.

Bob

On Jan 3, 2019, at 8:17 PM, mabooker76 <mabooker76@...> wrote:

Then the decision is which client/server protocol to use to get a JMRI yard panel 'subset', a single panel 'screen' to work on the zeros for the yard operators. Those yard screens are actually iconified on the main computer that is running primarily for dispatching functions.

--
Bob Jacobsen
rgj1927@...

If you want to connect to actual layout hardware, e.g. C/MRI or LocoNet or whatever, there really isn’t a true distributed option. Most hardware systems have a single point of connection; some (like LocoNet) allow more connections, but don’t make the complete state available that way. (OpenLCB was intended to be full distributed, but even that seems to have recently taken some steps toward localization)

But in the end, it’s just a model railroad. There’s not really a problem with having one machine connect to the layout and provide services to the rest.

So that’s the approach that most people have taken: One primary layout computer which handles the main connection, and some number of web browsers (i.e. tablets) and/or full JMRI instances (i.e. RPis) talking to it and hence to the layout.

The size you’re talking about below is not very hard for a JMRI instance on a real computer to keep up with. The remote RPs could work as web browsers or run JMRI to locally display the panels; that mostly depends on which you find simpler to set up and maintain.

Bob

On Jan 4, 2019, at 8:58 AM, mabooker76 <mabooker76@...> wrote:

We envisioned replacing 24 anodized push button/toggled real panels (heavily wired with tons of relay logic that no one understands anymore) with 6 or 7 'virtual panels' with mapping to the three large yards, 2 Engine service areas (for consisting, and loco roster), a couple displays in the operators' gallery (no walk around capability so something to show where trains are and virtual signals) and a two monitor dispatch area (the layout is 5k square feet - everything is at least 35 feet from everything else). We have dismantled the 10 'cabs' already - replaced with DCC throttles and plugins as well as wireless.

iPads are $250-$300 (Amazon) and cannot run java. A Pi ZW is $25 - touch screens $140ish, and can be embedded into the real panel - moving from the analog toggles/buttons to a virtual PanelPro screen as progress continues. A Pi ZW attached to a donated 40 inch HDMI with just a block detected and virtual signal panel seems to work for operators (but that is for output only).

There does not seem to be a lot of data on 'distributed JMRI', at least not what I can find in the blog?

--
Bob Jacobsen
rgj1927@...

[Moderator:? if this needs to be a new topic please advise]

I guess the decision is having a single instance of JMRI/Web versus multiple versions running specific 'applications', i.e. layout areas.? My old IT work was with multiple smaller systems (clusters, etc.) working across a network versus a monolithic single system.

We envisioned replacing 24 anodized push button/toggled real panels (heavily wired with tons of relay logic that no one understands anymore) with 6 or 7 'virtual panels' with mapping to the three large yards, 2 Engine service areas (for consisting, and loco roster), a couple displays in the operators' gallery (no walk around capability so something to show where trains are and virtual signals) and a two monitor dispatch area (the layout is 5k square feet - everything is at least 35 feet from everything else).? We have dismantled the 10 'cabs' already - replaced with DCC throttles and plugins as well as wireless.

iPads are $250-$300 (Amazon) and cannot run java.? A Pi ZW is $25 - touch screens $140ish, and can be embedded into the real panel - moving from the analog toggles/buttons to a virtual PanelPro screen as progress continues.? A Pi ZW attached to a donated 40 inch HDMI with just a block detected and virtual signal panel seems to work for operators (but that is for output only).?

There does not seem to be a lot of data on 'distributed JMRI', at least not what I can find in the blog?

Martin Booker?