¿ªÔÆÌåÓý

Date

Locked Re: Mobile Control II and Side bottons

 

This is the question I asked them.

Topic:???????????????? Mobile Control II
Your question:?
I have bought a Mobile Control II and use it together with
the Enginee Driver app. I have programmed the upper left side button to function 2 and this function is set to latching. I can get a long horn sound when I keep the function button on the screen pressed down but I can\'t get a long horn sound when I use the side button.

I have asked a question on the JMRI forum and got an answer that this was hardware related. I also got another reply that one person had one Mobile Control II with the same problem as I have but he also had one Mobile Control II were he could get a long horn sound when he pressed the side button.

Have you changed the hardware anytime which could explain this difference.

Roland Levin?


Locked Re: Mobile Control II and Side bottons

 

Hi Matt
I have the same 'Kernel version' and 'Build number' as you but my 'ESU Input Services' - is only version 1.06. Your version 1.07 is the latest acccordingbtomtheir Update software for Mobile control II.

I did your test with the ESU software and the upper right key activates then immediately de-activates the horn.

I have written a question to ESU about this and asked them if they have changed the hardware.

Best regards?
Roland L


Locked Re: Complex use of logix to ensure a particular order of execution

 

Just noticed the change of subject.
You can have many conditionals in a Logix, they are calculated from the top to bottom, you can move them around so make sure the ones that overwrite another comes later.
I have some Logix with over 30 conditionals in them. Usually for the modular layout I have one Logix per interlocking, that would be up to four signal heads and several turnouts each.

Mike


Locked Re: How to install JMRI using OPENJDK

 

Sorry Matt, installing on a windows 10 machine. And installing JMRI v4.14.4.?


Locked Re: Injecting a delay between turnout operations

 

It appears from a quick test that a route triggers in order of turnout number, not internal or sensors. So a turnout with a number higher than the turnouts in the route should react after the last turnout command is given.
I'm running into a similar problem on my old module that I've just installed signals on. It used to use routes for setting the turnouts (I did it quick for a modular meeting), but the decoder has a long delay between starting each motor (it only does one at a time) and the max delay in a route is 1s, much shorter than the decoder, meaning I can't get the program to workout when they have finished, so would have to have a 1 minute delay for the signals to ensure all turnouts have moved. Looks like I'll have to put this one into Logix where delays can be long enough. At least it will then be compatible with the newer modules, and I can have parallel moves.

Mike


Locked Re: How to install JMRI using OPENJDK

 

Peter,

Which operating system and version are you attempting the install on?

Best regards,

Matt H


Locked Re: Complex use of logix to ensure a particular order of execution

 

Dave,

Thanks I think I get all that.? I'll experiment with getting it right over the weekend.

You mention "conditionals" rather than Logix.? Are you suggesting I can merge these three into one Logix with 3 conditionals within it, or is it just a turn of phrase?

The conditional for the first set of actions will actually be destroyed by the second set - since the original tests that the routes are clear, and the second then sets the routes as occupied.? So the third action would probably need to be separate.

To be honest I have no idea how to nest these conditionals anyway!

Iain


Locked Re: Controlling loco from JMRI

 

Thanks Dave. You are absolutely right. I now have 2 throttles in JMRI, each independently controlling each of the 2 locos I have.
Yippeee? ?!!!!!!


Locked Re: Interpreting decoder type

 

Thanks Dave -> Changing Preferences -> Defaults from internal to NCE solved the problem.?
Thanks once again.?
Woohooo ... Now, I can play with this some more :-)


Locked Re: Controlling loco from JMRI

 

¿ªÔÆÌåÓý

This problem has the same cause as your other question about interpreting decoder type. See my answer to that question:

--?
Dave in Australia

On 10 Nov 2018, at 1:34 PM, tnmkumar_us <tnkumar@...> wrote:

I connected my JMRI through NCE USB to NCE Powercab.?
I can see the Powercab on my JMRI NCE -> NCE show cabs
In NCE -> Show NCE cabs, when I refresh, I see commands in NCE: Command monitor and also see the status of the Powercab - e.g. speed = 020 or 024
This tells me that a read communication between NCE Powercab and JMRI has been established
How can I control my locomotive from JMRI -> send control commands to the Powercab?


Locked Re: Interpreting decoder type

 

¿ªÔÆÌåÓý

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:

--?
Dave in Australia

On 10 Nov 2018, at 1:44 PM, tnmkumar_us <tnkumar@...> wrote:

In Create New Loco, when I "Read type from decoder, it says "Found mfg 123 (Massoth Elektronik GmbH) version 123; no such decoder defined". What do I need to do?


Locked Interpreting decoder type

 

In Create New Loco, when I "Read type from decoder, it says "Found mfg 123 (Massoth Elektronik GmbH) version 123; no such decoder defined". What do I need to do?


Locked Controlling loco from JMRI

 

I connected my JMRI through NCE USB to NCE Powercab.?
I can see the Powercab on my JMRI NCE -> NCE show cabs
In NCE -> Show NCE cabs, when I refresh, I see commands in NCE: Command monitor and also see the status of the Powercab - e.g. speed = 020 or 024
This tells me that a read communication between NCE Powercab and JMRI has been established
How can I control my locomotive from JMRI -> send control commands to the Powercab?


Locked Re: Dispatcher - SML - auto-allocation problem

 

¿ªÔÆÌåÓý

NotePad doesn't work well with many JMRI files. It doesn't understand the Mac/UNIX style LF line terminators we use, expecting the Windows CRLF style. As a result, all the file may show on a very long first line.

WordPad is fine, but I'm sure NotePad++ has better features for JMRI work.

--?
Dave in Australia


On 10 Nov 2018, at 12:12 PM, Steve_G <RailRodder@...> wrote:

As I recall notepad should work, turning off line wrap helps.
Otherwise there is notepad++ that can be found here


Locked Re: Dispatcher - SML - auto-allocation problem

 

Yep, just worked it out as you replied.. haha

Okay, I added sensors to my panel for simulating trains running around the inner circle and coming across the crossover into the inner circle.

Setting starting sensors to active, creating auto-active trains for each train, and then clicking through the route of 50037 from block 01 to block 05

As soon as block 01 goes in-active, 37254 allocates to S06. And then 50037 allocates over the top. If I keep 50037 going, the both legs of a turnout that they depart using the same route, both go allocated for their seperate transits, showign that they are both deffinitely allocating at the same time and continuing on to their seperate destintions.

When the initial overlap happens at LT5, JMRI system console spits out the following:
?
118089 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118102 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118105 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118309 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118310 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118311 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118313 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118315 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118316 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118317 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118318 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118319 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09

I think this is telling me that it was EXPECTING 37254 but 50037 allocated anyway, or the other way around.. either way it is logging the conflict we are seeing. In a way, I am relived I'm not crazy!

--
Thanks
Mitch


Locked Re: Dispatcher - SML - auto-allocation problem

 

As I recall notepad should work, turning off line wrap helps.
Otherwise there is notepad++ that can be found here

Steve G.


On November 9, 2018 9:27:23 AM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote:
Thanks Steve,

is there any particular program I can use on Windows to edit the file? I seem to remember notepad gives a very weird format.

I will take out all the stop sensors from the sections and see how the layout reacts.

My trains are varying between block length and half block length of the main running lines, excluding smaller turnout blocks etc obviously. usually loco + 4-5 coaches.
all wheel are resistance wheels, track is cleaned regularly.

i don¡¯t think the sensors are going active/inactive/active, however I do have one block that goes inactive even though the BDL168 sensor is still active (I suspect one of my Logix has a mis-informed conditional, even my turnout controlled turntable moves occasionally). This block is no-where near the problem area, though.
I feel it¡¯s unrelated because I don¡¯t see sensors change state when the overlap occurs, I¡¯ve repeated it every time I¡¯ve run dispatcher watching sensors, blocks etc to see any oddities and I¡¯ve been dumbfounded trying to find evidence of why, which is what I¡¯m sure you¡¯re experiencing too.

I will also try a ¡°disconnected¡± version of my panel file. Loconet simulator and panel sensors to emulate blocks being occupied, and attempt to cause it manually.

Failing that, I¡¯ll edit the default file, however I do that, and debug it and do a video as well just to prove I¡¯m not crazy


although we are all a little crazy, let¡¯s be honest.

thanks! Sorry this has been such a pain.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Locked Re: Complex use of logix to ensure a particular order of execution

 

Iain,

The Route duration will be the sum of the delays between turnouts. Without feedback, the last turnout will still be moving when the completion sensor has been set.

I would not worry about block setting and final signal mast changes. It is possible the signal will change a few ms before the last block changes, but I doubt it will be noticeable.

The additional sensor and conditional actually compensates for the lack of feedback with the added value of insuring that the blocks are set before the mast. With testing, the optimum delay time can be determined.

In summary:
- conditional 1: Triggered by panel button, check for valid states, set Route if OK.
- conditional 2: Triggered by route sensor, set blocks, set sensor with delay to compensate for lack of feedback.
- conditional 3: Triggered by delayed sensor, set signal mast.

Dave Sand

On Nov 9, 2018, at 4:00 PM, Iain <iain@...> wrote:

Thanks Dave. I have found the box on the Route table. It's obvious when you know to look for it!

Using that will provide me with a sensor set, then I write the next Logix for the block setting triggered by that sensor. But that too will need to point to yet another Logix to set the signal, otherwise the signal may be set before the route is illuminated fully (longest is 8 blocks at the moment). Unless there is a similar trigger that I haven't yet seen, I can only do that by making the signal trigger sensor a delayed set? Maybe just a couple of seconds?

Basically you are saying my interpretation of what I have read and what you have said is correct??

Iain


Locked Re: Complex use of logix to ensure a particular order of execution

 

Thanks Dave.? I have found the box on the Route table. It's obvious when you know to look for it!

Using that will provide me with a sensor set, then I write the next Logix for the block setting triggered by that sensor.? But that too will need to point to yet another Logix to set the signal, otherwise the signal may be set before the route is illuminated fully (longest is 8 blocks at the moment).? Unless there is a similar trigger that I haven't yet seen, I can only do that by making the signal trigger sensor a delayed set?? Maybe just a couple of seconds?

Basically you are saying my interpretation of what I have read and what you have said is correct??

Iain


Locked Re: Complex use of logix to ensure a particular order of execution

 

Iain,

Going off the deep end, think about this solution:

A Route table entry has the ability to set a sensor state when the turnouts have reached the desired state. The could be used to trigger the final actions.

I created a script that I use to simulate TWOSENSOR feedback when I am developing away from the layout. This could be adapted to provide virtual turnout feedback with an appropriate delay after 1 sensor goes Inactive and the other one Active. This emulates the behavior of a Tortoise.

Dave Sand

On Nov 9, 2018, at 2:56 PM, Iain <iain@...> wrote:

I have an understanding problem. It has been clarified to me (and the manual does say it!) that Logix actions are NOT necessarily performed in a strict order, and will be executed "as convenient".

My problem is in route (note little "r" not meaning use of Routes) setting for my layout panel. May I please pick brains to get to the most effective way for my layout and current equipment.

I seek to have a process whereby three separate but tightly related activities take place in sequence, with each step being completed entirely before the next is commenced.

When a sensor is set (a button click on the panel) the Logix conditions will ensure that the process cannot start unless certain sensors (from blocks) are inactive (I.e. the route is free)

If true (1) THEN the necessary turnouts are set (I use a Route for this so I can have an Additional Delay" between turnout commands - technical problem of possible bus overload so this is a workround which works for me).

When (and only when) the turnouts have completely set (I do NOT have feedback so I rely on delay), (2) THEN the blocks which the route will follow will be set active (note these are those very sensors from the fist condition above so the first condition test will fail subsequently)

(3) THEN when all is complete the signals controlling the route are set.

My logical problem is this. The Logix does not maintain a sequence, so what is below does not work but it expresses what I need if the sequence were strictly followed: [comments not in the original]

IX:AUTO:0011C1 C1
[x] R1 IF Sensor "RQL1toP1a" state is "Sensor Active" [button on panel
[x] R2 AND Sensor "SP1a" state is "Sensor Inactive" [block on route which needs to be clear
[x] R3 AND Sensor "SLa" state is "Sensor Inactive" [block on route which needs to be clear
THEN
On Change To True, Set Sensor, "RQL1toP1a" to Inactive [reset button
On Change To True, Set Signal Mast Aspect, "P1aS" to Danger [signal on clashing route - should be Danger but do it just in case
On Change To True, Set Signal Mast Aspect, "P1aSf" to Zero [signal on clashing route
On Change To True, Set Turnout, "Crossover" to Thrown [turnout movement which needs additional delay - use a Route
On Change To True, Set Turnout, "QL1" to Thrown [turnout movement which needs additional delay - use a Route with above
On Change To True, Set Sensor, "SP1a" to Active [set block to be used
On Change To True, Set Sensor, "SLa" to Active [set block to be used
On Change To True, Set Sensor, "SQL1" to Active [set block to be used
On Change To True, Set Signal Mast Aspect, "QL1toP1ag" to Off [set signal controlling route - at the very end when all else is complete

Currently even if the "set turnout" operations were set to "delayed set turnout" the blocks would be set active, and even the signal, before the turnout operations are complete.
Moving the turnouts into a Route helps to keep the turnout sequence separate - but the sequence still continues on whilst the Route is executing, and some routes have 10 turnouts.

I cannot move the sensor setting into the Route because they will be set asynchronously to the turnouts, so the route will be coloured in before the turnouts are correctly set.

There is no way to delay a signal mast setting.

I need a foolproof way of identifying that the turnout switching is complete before moving on to set the block sensors as occupied. It was suggested that another sensor could be defined and when that was set another Logix would fire up which would contain the route sensor setting and signals. But since the new sensor will be set immediately after the Route is activated, this won't help me. I could perhaps call the Route from a Logix and do a delayed sensor set at an appropriate delay for all the turnout operations to be complete. Crude but may be all I can do.

The problem with delaying the signal setting would need to be met in the same way - several sensor sets for the blocks - followed by a delayed sensor setting for another new sensor which would then fire another Logix to set the signal(s).

I now have something like 2 extra Logix, a Route and 2 extra sensors to meet what seemed to me to be a fairly straightforward requirement.

Have I analysed this right or am I an idiot?

Your thoughts and suggestions are humbly requested. Solutions requiring changing hardware, wiring, new equipment are not likely to be acted on. I just want to use JMRI software effectively to meet my needs if that is at all possible.

Many thanks for taking the time to read this.


Locked Re: UK 3 aspect signal with feather using NCE PowerCab and TrainTech signal

 

Cracked it!!!

I assumed I was supposed to change the turnout state in the Logix, which certainly worked on the physical light.? Now changed to the Signal Mast Aspect and everything is now hunky dory!!
Thanks for the pointers - I knew it must be me being dense!

Torben