If you wanted to have signal logic in only one place (perhaps a good idea for a model railroad, but not what the prototype does in most CTC cases), then having Held be one of the set of aspects might work sometimes. JMRI could display the “Held” state on its panels, which is the default behavior. There’s an option to display the underlying aspect, which wouldn’t be available, but I’m not sure how often that’s used. I don’t know how CTC would work in this case as JMRI wouldn’t be able to tell “Held-but-otherwise-Clear” from “Held-but-otherwise-Approach”, for example, but that’s a problem for the logic which would (have to be) fully outside JMRI.

Lit vs dark is another matter. They’re not the same. Of the people using e.g. approach lighting for their signals (including at least one local layout), some large fraction have their panels display the current appearance of the signal even when it’s set to “unlit”. I’m not sure how many of them use a true “dark” appearance for an aspect, though.

So JMRI could _mostly_ follow, with some exceptions, the state of a signal mast driven externally. When we tried to do that with SE8c heads (not masts), the exceptions caused a lot of confusion and the layout listening was eventually removed. But perhaps the application of masts would be OK with limitations.

Bob

On Nov 24, 2019, at 11:01 AM, billybob experimenter <jawhugrps@...> wrote:

Bob J. wrote: "Is it really known to be true that there’s enough information in the DCC messages to do that for "DCC Signal Mast Decoder"? I.e. there’s a way to tell held or not, lit or not from just the messages?"

Generally, the NMRA standard for "Extended Accessory Decoder Control Packet"s defines a signal mast number and a five-bit aspect value (for up to 32 possible aspects). Other than aspect 0 being "absolute stop", it does not define any specific aspect/value pairing - the user or the hardware implementation gets to decide the other aspect/value pairings.

Specifically, JMRI's "Dark" aspect is typically conveyed to a DCC extended accessory decoder as a unique "aspect number", with the mast hardware using that aspect number to turn off all lamps in the signal. Presumably the DCC extended accessory decoder supports a dark mast. JMRI already has the capability to express "dark" as a signal mast aspect. For those system JMRI configurations which support monitoring externally-generated aspect changes, such as "LNCP Signal Mast"s when operating on a LocoNet connection, JMRI will follow such external aspect changes.

Specifically, JMRI's "Held" condition is an internal state of JMRI and, so far as I can tell, is not (typically) exposed in the DCC message.

There is no reason why one could not map the "held" condition to an aspect on an extended accessory decoder, so long as there is only one aspect used in the "held" case. That "held" aspect could duplicate the appearance of another aspect, such as "absolute stop", but use a different, unused DCC aspect number. Hardware would interpret that new aspect number as an appropriate appearance. This would allow communication of the "held" state on the control communication media.

In the user's specific case, with the suggestion made above, this unique LocoNet message for the "held" state would be uniquely conveyed via LocoNet, and JMRI would be able to "detect" the message, regardless of the message's source. A JMRI mast configured as an LNCP Signal Mast, via a LocoNet connection, would have this capability, without any JMRI Java coding changes, for any signal system which defined a unique aspect for the "held" state.

So far as I know, no existing JMRI Signal System definition defines the "held" aspect as a unique aspect; I believe they all simply declare the "held" state to be equivalent to the "Stop" aspect or some similar aspect. But a simple set of changes to the user's "signal system definition" would enable this functionality.

The only limitation I can think of to such a solution to convey "held" information on the communication media is that there are only 32 possible mast aspect numbers in the DCC Extended Accessory Decoder packet. Any existing mast which implements 32 unique aspects without a defined "held aspect" would not allow adding an additional aspect for the "held" case.

Regards,
Billybob

--
Bob Jacobsen
rgj1927@...

?

Hi Ross,
I read the spec sheet I got with the loco and it says that the decoder has 28 step capability. And the decoder is an E-Z command decoder.
I placed the loco on the programming track and used the Digitrax Zepher to "status? edit" and set it to 28? speed steps.

?

• ‘Status editing’ the address to 28 speed-steps would be correct for this decoder.

?

• Changing ‘speed steps’ will not affect the speed range of the locomotive.? Decoders do not have a continuously variable output – their output is in ‘distinct’ steps across the speed range.? A decoder operating at 28 speed steps will have 28 distinct speeds from stop to maximum; a decoder operating at 128 speed steps will have 128 distinct steps from stop to maximum.? Maximum speed will be the same in both cases

?

?

And as I said before using the speed table did nothing to change the speed slow or fast. I even set the table to go all out 255, but have found since that the decoder will not allow that.

?

• AFAIK, none of the E-Z Command decoders have speed adjustment other than V-start.? I just noticed that the DecoderPro definition for the 4-function E=Z Command decoder includes a speed table.? I couldn’t find a reference to a speed table in any online Bachmann documentation.? This may be an error in the DecoderPro decoder definition.? Your spec sheet should indicate the appropriate speed control CVs if they are implemented in your decoder.

You are saying that the decoders in the two locos that I am trying to speed step cannot be adjusted that way? Would that be a non NRA compliant decoder? I thought that Bachmann has been up to the standard?

?

• NMRA Conforming requires that the NMRA ‘mandatory’ CVs be implemented per the NMRA specs.? If any ‘recommended’ or ‘optional’ CVs are implemented they must follow the NMRA specs for those CVs.? ?None of the speed control CVs are mandatory thus not required for a ‘minimum’ NMRA Conforming decoder.

?

I looked for a compatible decoder to replace the board on the Bachmann locos, but could not find an exact match. I have not done much looking for decoders as all of my engines are mostly Bachmann or Digitrax, mostly Digitrx. Is there a way to find a decoder board that has the head and rear light built in that will fit?
into a SD9 or GP30?

?

• The Digitrax ‘Decoder Selector” might help you.? Other decoder manufacturers have similar selectors on their web sites.? You can also ask for help on the Digitrax forum – not suitable here on the Jmriusers forum (IMHO).? I don’t recall you mentioning scale – although your comment on including lights leads me to believe these are N-scale models.

?

?

Thanks
George
?

Dag Cato,

I recommend that you keep your scripts in the user files location.? In Preferences >> File Locations, set the script path.? This way JMRI upgrades don't affect your custom scripts.

Dave Sand

----- Original message -----

From: "Dag Cato Sk?rvik" <dag.cato.skarvik@...>

To: [email protected]

Subject: Re: [jmriusers] Scripting, Jython and importing selfwritten functions - crash and burn

Date: Sunday, November 24, 2019 11:25 AM

Hi Dave.? Thanks for you help. It wasn't the dash that was the original problem. (There where no dash in the original file) But you did point me in the right direction. After changing the filename I tried again without help.

Then I decided I would run the main script from the panels/run script command. When the dialogbox opened I saw that it was pointing to the jython-directory. I stored my files in another directory. So when I moved to function file to the jython directory it worked :-)

Dag Cato

s?n. 24. nov. 2019 kl. 17:50 skrev Dave Sand <ds@...>:

Dag Cato,

The problem appears to be the dash in the "my-functions" name.? The underscore character works.

Dave Sand

----- Original message -----

From: "Dag Cato Sk?rvik" <dag.cato.skarvik@...>

To: [email protected]

Subject: [jmriusers] Scripting, Jython and importing selfwritten functions - crash and burn

Date: Sunday, November 24, 2019 6:14 AM

Hello guys,

behind this heading lies nothing more than the wish two write functions in jython, saving them in a separate file and calling them from the main script.

Why? Just to try to keep the code more manageable.

I am no programmer at all. Learnt a little bit of Pascal and C/C++ in my youth.

My computer is a Elitebook bought on a fleamarket many years ago.

Java version is 11.0.5 64-bit

Windows 10 Version 1903 for x64 (KB4522741)

JMRI 4.17.3

Loconet simulator

Python has a import function.

If I hava a function test in a file called my-functions.py

I hoped that I was able to import?the function with this code

import my-functions

my-functions.test()

I doesn't work. Nothing happenes.

Well the latter is not quite the truth :-)

When i run the code with the Message Log window open?the whole JMRI crashes. I even have to go kill Java manually to start JMRI again. Without the Log Window opened I can just continue, everything is just fine.

But my question is about the import function. Can I use it in jython or do I have to live with having the functions in the main script?

MVH

Dag Cato