Crossovers can have one to four turnout actuators (and I¡¯ve seen all combinations on real layouts) but only two actual useful states. There¡¯s little advantage to having any additoinal turnout actuators at different addresses. I¡¯ve only ever seen them all share the same address.
If your heart is set on using different address (for what ever reason you¡¯ve contrived) you could ¡°build your own¡± crossover using two left hand or two right hand (for single crossovers) or both and a level crossing (diamond) (for dual crossovers).
|
The MOLE I switch machine I designed has a double ended throw side arm, so that, using tube in wire, connected at each end, it can operate throws in opposite directions simultaneously. The MOLE itself is hidden in this clip, but you can see it throwing both points of one end of a double crossover in the street track progress you tube video ? ?starting at ~ 15 seconds in. The Proto:87 SIG has developed a lot of inexpensive technology for Proto:87, that is just as useful for regular HO. Andy ?On 11/28/2018 2:18 PM, Don Weigt wrote: I defy you to make a real crossover with only one turnout.
Logically it may have only two states, and one JMRI "turnout" definition may suffice to control it. But, having the JMRI configuration not match the physical one only makes it that much harder for us newbies to fathom how all this works on our physical layouts... One to one mapping is much easier to understand!
On a sad note, I learned today that Sudro Brown has passed. He has been mentioned here as a JMRI expert in central Massachusetts. He was a local JMRI hero. Hearing Sudro demonstrate and expound the advantages of JMRI is what made me consider trying it. He'd say, "If you're not using JMRI, why aren't you?!"
I will miss having a JMRI expert in my NMRA division covering Connecticut and part of Massachusetts. It makes me even more appreciative of the time and effort knowledgeable members of this group spend helping the rest of us. Thank you all!
Don Weigt
--- This email has been checked for viruses by AVG.
|
Locked
Re: Reading and programming new BLI PRR T1 - PROBLEM
Hi Peter:
The decoder will NOT identify of I "Read type from decoder".
I have not yet tried different programming modes.? I use Direct, having been warned that this is the most reliable.? I can try other modes.
In manual decoder selection, I specifically selected the Paragon 3 "Steam" definition; I did NOT select the "Rolling Thunder" definition.
My Power Supply has output of 18 V, 1 AMP.
I am also having trouble reliably reading all CVs of other BLI Paragon 3 decoders.? And had problems reading the new Piko BR 82, which nominally has an ESU Dekoder.
So far the only way I have been able to program the addresses for these Locos is to select NMRA Standard Definition and only program the address.? That works!? But it leaves me high and dry if I ever have to reprogram the whole decoder!!
Cheers,
Michael
|
Locked
Re: Dispatcher - SML - auto-allocation problem
Mitchell
I did take a cursory glance at the fail safe, it only works after you have gone by a red light, so doesn't apply here.
Steve G.?
|
Locked
Re: possible bug, LocoNet slot monitor
Hi
I agree that the four check boxes approach aint the greatest for general use.?
The generalised approach would be the Excel one of right clicking the column header and selecting the filter options, a lot of work to develop.
The default was to show anything not free. So Common, idle, In Use. It could be reprogrammed to that.
While the discussion goes on, try selecting show all slots and then sort descending on loco number column (click on the header column name). It will get you to the same place.
You can click on any of the headers to sort on that column.
My biggest problem on this screen is that the default direction column width is too small and that it doesn't remember my choices. With some direction we can fix this up. Colours, any one want colours?
Steve G.
|
Don,
I have several on my layout. They consist of a single turnout motor driving a bar pivoted at the center point between the two switch points. (under the roadbed) Think a piece of a yardstick, but it is actually just a wooden stick about that size. Each end of the bar has a piano wire mounted vertically that passes up through the roadbed to each throw bar. This results in the points moving in opposite directions as needed for a crossover. The flex in the piano wire accounts for any small errors in alignment between the two ends of the actuator bar. Because of the length of the bar the motion at the pivot is very small and I expect them to last well past the 15-20 years that they have been installed. One actually has dual bars that control a double crossover. (two machines, and 3 positions, left, straight, and right) That one has the pivots offset from the centers of the bars so that they don't both need to be at the same spot.
Dick :)
toggle quoted message
Show quoted text
On 11/28/2018 5:18 PM, Don Weigt wrote: I defy you to make a real crossover with only one turnout.
|
I defy you to make a real crossover with only one turnout.
Logically it may have only two states, and one JMRI "turnout" definition may suffice to control it. But, having the JMRI configuration not match the physical one only makes it that much harder for us newbies to fathom how all this works on our physical layouts... One to one mapping is much easier to understand!
On a sad note, I learned today that Sudro Brown has passed. He has been mentioned here as a JMRI expert in central Massachusetts. He was a local JMRI hero. Hearing Sudro demonstrate and expound the advantages of JMRI is what made me consider trying it. He'd say, "If you're not using JMRI, why aren't you?!"
I will miss having a JMRI expert in my NMRA division covering Connecticut and part of Massachusetts. It makes me even more appreciative of the time and effort knowledgeable members of this group spend helping the rest of us. Thank you all!
Don Weigt
|
>>>?However, since Crossovers require two Turnouts
Crossovers don¡¯t require two turnouts¡ they really only have two usable states: ¡°Normal¡± and ¡°Diverging¡±. These two states can apply to multiple turnout actuators but aren¡¯t ¡°required¡±.
|
Locked
Re: possible bug, LocoNet slot monitor
Bob J does a good job of focusing the problem on a key question (like he usually does!): What do we want the JMRI "LocoNet Slot Monitor" tool to do?
Whatever we come up with, I think we need a simple-to-use mechanism with a carefully-chosen default setting.
For the existing GUI, I would argue that the "default" mode of operation (i.e. "show unused slots" checkbox unchecked) should show any slot which can be actively controlled by a throttle (JMRI, Wi, Digitrax, or otherwise). This interpretation means, I believe, that "IN_USE" state _and_ "COMMON" state slots should always be shown, and "checking" the "show unused slots" checkbox would enable display of "FREE" state and "IDLE" state slots.
I do not support the idea of replacing the simple "show unused slots" checkbox with four checkboxes, one for each slot "state". The typical LocoNet/JMRI user doesn't have a clue about "slot state" values. Implementing four checkboxes, one for each state would cause massive confusion in the user-base, and would require significant re-training and support.
However, I and other power-users have uses for the four-checkbox approach. We could implement an option where the user could fiddle something like a checkbox in a new menu item on the Slot Monitor tool to swap out the simple "show unused slots" checkbox for the four "checkbox per slot status value" checkboxes.
Regards,
Billybob
|
Locked
Re: Multisensor Icon Rotation in CPE
Bob, thats a great point about Multisensors generally being used with levers, and needing to be defined as getting clicked left/right or up/down. In my case, the multisensors will be disabled, as the icons are only information feedback in their use.
As a workaround, I just rotated the original graphic to the needed orientation outside of JMRI. Working great and moving along once again.
Thanks
Steven
|
Locked
Re: possible bug, LocoNet slot monitor
I agree, lots of other things in that commit. I would say the change from
looking for LOCO_IN_USE to != LOCO_FREE would come closest to the older
results. My other thought was if anything had a throttle speed != 0, that
should always return true also.
I see the filter being nice an clean compared to old way.
I don't have a working repository right now or those two things are what I'd
consider doing.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: possible bug, LocoNet slot monitor
I suspect from reading the github pages that the original intention was to offer more checkboxes to choose which things to display. So, my ideal solution would be to have checkboxes for all of the states available at the top of the listing, and the user selects the ones they want, and that selection would be persistent between JMRI sessions.
If that's too much work (and I appreciate I'm asking someone else to do work), then of the states listed by Bob, I'd pick all of them except "LOCO_FREE =0"
- Nigel
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] [mailto: [email protected]] On Behalf Of Bob Jacobsen Sent: 28 November 2018 16:11 To: [email protected]Subject: Re: [jmriusers] possible bug, LocoNet slot monitor That particular PR includes a lot of good stuff besides this change to the filter logic. The filter part seems to boil down to a line that says (effectively) ¡°if no checkboxes are selected, display slots that have status ¡°LOCO_IN_USE¡±. The older code was so messy (and I can say that, as I wrote it) that it¡¯s not clear to me what it was doing before. Which of these states should it (by default) show now? * LOCO_IN_USE which is defined as STAT1_SL_BUSY | STAT1_SL_ACTIVE (this is happening now) * LOCO_IDLE = STAT1_SL_BUSY * LOCO_COMMON = STAT1_SL_ACTIVE * LOCO_FREE = 0 Bob On Nov 28, 2018, at 7:55 AM, John Griffin <johng.sst@...> wrote:
I think this should be reverted before the release of 4.15 If I could convince myself to participate in the development of this product I would do it but I've been retired for just 1 year and need to get away from Java for a while (java engineer for many years).
On Wed, Nov 28, 2018 at 12:08 AM Bob Jacobsen <rgj1927@...> wrote:
If somebody wants to look into restoring the previous behavior, the commit that changed this was
commit 7cc228bfaf451520ea16cb8e18b950050d1f9a4d
Date: Tue Dec 19 19:59:16 2017 -0500
Partly add filtering to Slot Monitor table
Need to use filtering instead of manipulating the model to implement checkboxes showing/hiding certain types of slots.
:040000 040000 e4378d76dab518e516a5ef33130d95bdfc1db7d0 d8cfda18046228b646c8ead203ceabd08b7bf201 M java You can see the full set of changes here:
The PR that included it is here:
It¡¯s called "Fix errors reading slots in Slot Monitor¡±
It doesn¡¯t look to me like the Zephyr behavior change was intended, but rather an unintended part of fixing some intermittent failures under load.
It first appeared in JMRI 4.11.1 on December 24th, 2017.
Bob
--
Bob Jacobsen
rgj1927@...
--
John Griffin
_______________________________
If today was your last day, you would...
-- Bob Jacobsen rgj1927@...
|
Locked
Re: possible bug, LocoNet slot monitor
Just a cursory look but it appears removing the right side of the && at line 182 would fix it.?
On Wed, Nov 28, 2018 at 9:11 AM Bob Jacobsen < rgj1927@...> wrote: That particular PR includes a lot of good stuff besides this change to the filter logic.
The filter part seems to boil down to a line that says (effectively) ¡°if no checkboxes are selected, display slots that have status ¡°LOCO_IN_USE¡±.? The older code was so messy (and I can say that, as I wrote it) that it¡¯s not clear to me what it was doing before.
Which of these states should it (by default) show now?
* LOCO_IN_USE which is defined as STAT1_SL_BUSY | STAT1_SL_ACTIVE? (this is happening now)
* LOCO_IDLE = STAT1_SL_BUSY
* LOCO_COMMON = STAT1_SL_ACTIVE
* LOCO_FREE = 0
Bob
> On Nov 28, 2018, at 7:55 AM, John Griffin <johng.sst@...> wrote:
>
> I think this should be reverted before the release of 4.15 If I could convince myself to participate in the development of this product I would do it but I've been retired for just 1 year and need to get away from Java for a while (java engineer for many years).
>
> On Wed, Nov 28, 2018 at 12:08 AM Bob Jacobsen <rgj1927@...> wrote:
> If somebody wants to look into restoring the previous behavior, the commit that changed this was
>
> > commit 7cc228bfaf451520ea16cb8e18b950050d1f9a4d
> > Date:? ?Tue Dec 19 19:59:16 2017 -0500
> >
> >? ? ?Partly add filtering to Slot Monitor table
> >? ? ?
> >? ? ?Need to use filtering instead of manipulating the model to implement checkboxes showing/hiding certain types of slots.
> >
> > :040000 040000 e4378d76dab518e516a5ef33130d95bdfc1db7d0 d8cfda18046228b646c8ead203ceabd08b7bf201 M? ? java
>
> You can see the full set of changes here:?
>
> The PR that included it is here:?
> It¡¯s called "Fix errors reading slots in Slot Monitor¡±
>
> It doesn¡¯t look to me like the Zephyr behavior change was intended, but rather an unintended part of fixing some intermittent failures under load.
>
> It first appeared in JMRI 4.11.1 on December 24th, 2017.
>
> Bob
> --
> Bob Jacobsen
> rgj1927@...
>
>
>
>
>
>
>
>
> --
> John Griffin? ? ? ? ? ? ? ? ?
> _______________________________
> If today was your last day, you would...
>
--
Bob Jacobsen
rgj1927@...
-- John Griffin? ? ? ? ? ? ? ? ? _______________________________ If today was your last day, you would...
|
Locked
Re: possible bug, LocoNet slot monitor
That particular PR includes a lot of good stuff besides this change to the filter logic. The filter part seems to boil down to a line that says (effectively) ¡°if no checkboxes are selected, display slots that have status ¡°LOCO_IN_USE¡±. The older code was so messy (and I can say that, as I wrote it) that it¡¯s not clear to me what it was doing before. Which of these states should it (by default) show now? * LOCO_IN_USE which is defined as STAT1_SL_BUSY | STAT1_SL_ACTIVE (this is happening now) * LOCO_IDLE = STAT1_SL_BUSY * LOCO_COMMON = STAT1_SL_ACTIVE * LOCO_FREE = 0 Bob On Nov 28, 2018, at 7:55 AM, John Griffin <johng.sst@...> wrote:
I think this should be reverted before the release of 4.15 If I could convince myself to participate in the development of this product I would do it but I've been retired for just 1 year and need to get away from Java for a while (java engineer for many years).
On Wed, Nov 28, 2018 at 12:08 AM Bob Jacobsen <rgj1927@...> wrote:
If somebody wants to look into restoring the previous behavior, the commit that changed this was
commit 7cc228bfaf451520ea16cb8e18b950050d1f9a4d
Date: Tue Dec 19 19:59:16 2017 -0500
Partly add filtering to Slot Monitor table
Need to use filtering instead of manipulating the model to implement checkboxes showing/hiding certain types of slots.
:040000 040000 e4378d76dab518e516a5ef33130d95bdfc1db7d0 d8cfda18046228b646c8ead203ceabd08b7bf201 M java You can see the full set of changes here:
The PR that included it is here:
It¡¯s called "Fix errors reading slots in Slot Monitor¡±
It doesn¡¯t look to me like the Zephyr behavior change was intended, but rather an unintended part of fixing some intermittent failures under load.
It first appeared in JMRI 4.11.1 on December 24th, 2017.
Bob
--
Bob Jacobsen
rgj1927@...
--
John Griffin
_______________________________
If today was your last day, you would...
-- Bob Jacobsen rgj1927@...
|
Locked
Re: possible bug, LocoNet slot monitor
I think this should be reverted before the release of 4.15. If I could convince myself to participate in the development of this product I would do it but I've been retired for just 1 year and need to get away from Java for a while (java engineer for many years).?
On Wed, Nov 28, 2018 at 12:08 AM Bob Jacobsen < rgj1927@...> wrote: If somebody wants to look into restoring the previous behavior, the commit that changed this was
> commit 7cc228bfaf451520ea16cb8e18b950050d1f9a4d
> Date:? ?Tue Dec 19 19:59:16 2017 -0500
>
>? ? ?Partly add filtering to Slot Monitor table
>? ? ?
>? ? ?Need to use filtering instead of manipulating the model to implement checkboxes showing/hiding certain types of slots.
>
> :040000 040000 e4378d76dab518e516a5ef33130d95bdfc1db7d0 d8cfda18046228b646c8ead203ceabd08b7bf201 M? ? java
You can see the full set of changes here:?
The PR that included it is here:?
It¡¯s called "Fix errors reading slots in Slot Monitor¡±
It doesn¡¯t look to me like the Zephyr behavior change was intended, but rather an unintended part of fixing some intermittent failures under load.
It first appeared in JMRI 4.11.1 on December 24th, 2017.
Bob
--
Bob Jacobsen
rgj1927@...
-- John Griffin? ? ? ? ? ? ? ? ? _______________________________ If today was your last day, you would...
|
Locked
Re: Reading and programming new BLI PRR T1 - PROBLEM
Michael:
Okay the PR3 should have enough power to program the decoder. But I've seen some BLI P3's not like the programming track, in my case on an NCE PowerCab.
Need for power... the decoder doesn't actually send data back it compares what's being sent to what's stored in it's memory and if it agrees with what's there it turn the motor on and that causes a current spike that the programmer see as confirmation and flags the value as being what it just sent.
Some sound decoders either are already drawing enough current to confuse the process or with larger capacitors on the board draw too much current when the motor pulses... that also confuses the programming circuitry.
Digitrax went to a higher current supply with the PR series of programmers to work around this... However further changes in the decoders and the addition of smoke units confuse the programmers even further.
Since BLI ships smoking locomotives without fluid it's always best to turn it off with the switch under the cab of the locomotive at first (or permanently, our club has banished smoke.)? That however isn't the problem here, these engines can be a problem on the programming track.
With JMRI I build a roster entry for the new engine and then use the programming on the main to do any further programming. That's a problem with the PR3 not being connected to the railroad's main system.
Anyone have any other suggestions?
Jim Albanowski
|
Locked
Re: possible bug, LocoNet slot monitor
If somebody wants to look into restoring the previous behavior, the commit that changed this was commit 7cc228bfaf451520ea16cb8e18b950050d1f9a4d
Date: Tue Dec 19 19:59:16 2017 -0500
Partly add filtering to Slot Monitor table
Need to use filtering instead of manipulating the model to implement checkboxes showing/hiding certain types of slots.
:040000 040000 e4378d76dab518e516a5ef33130d95bdfc1db7d0 d8cfda18046228b646c8ead203ceabd08b7bf201 M java You can see the full set of changes here: The PR that included it is here: It¡¯s called "Fix errors reading slots in Slot Monitor¡± It doesn¡¯t look to me like the Zephyr behavior change was intended, but rather an unintended part of fixing some intermittent failures under load. It first appeared in JMRI 4.11.1 on December 24th, 2017. Bob -- Bob Jacobsen rgj1927@...
|
Locked
Re: possible bug, LocoNet slot monitor
I will add my vote to Dale and Ken. I do not like the change at all. I use a DCS100, so all 120 slots are 'real', but very annoying that I have to select "show all slots" to see what is there. In the case of "Common" slots the Digitrax DCS100 will not write over those slots, so it is very important to know which slots were dispatched but left in "Common". Barry Draper ________________________________________ From: [email protected] < [email protected]> on behalf of Dale Gloer <dale.gloer@...> Sent: Tuesday, November 27, 2018 7:32 AM To: [email protected]Subject: Re: [jmriusers] possible bug, LocoNet slot monitor I do not like the new slot monitor display which shows only locos in use. I would prefer the previous method which displays all slot that have a loco number in them, regardless of the status. Dale Gloer </https:></mailto: [email protected]></https:></https:></https:></mailto:dale.gloer@...?subject=private:%20re:%20re%3a%20%5bjmriusers%5d%20possible%20bug%2c%20loconet%20slot%20monitor></mailto: [email protected]?subject=re:%20re%3a%20%5bjmriusers%5d%20possible%20bug%2c%20loconet%20slot%20monitor></https:></dale.gloer@...></ [email protected]>
|
Locked
Re: Multisensor Icon Rotation in CPE
Steven,
I am not a developer, but the multi sensor icon was designed to be activated by clicking it either up-down or right-left. As such, I don't believe it is possible to rotate them, say 45 degrees. I believe you still will have to touch the proper half of the icon area. of course, you can rotate the displayed image however you desire. I did create some wide three position lever icons which just have a wider transparent area to click for the lever action. You can find them in the resources/icons/USS/plate/levers directory. You can see the difference in the original and wide versions on this web page:
For example, compare l-left.gif and lever-left-wide.gif
They will look alike on the panel but the wide version is much easier to activate with a mouse click or on my touch screen CTC panel.
Bob Bucklew
toggle quoted message
Show quoted text
----- Original Message ----- From: stevelton17@... To: "jmriusers" < [email protected]> Sent: Tuesday, November 27, 2018 9:06:08 PM Subject: [jmriusers] Multisensor Icon Rotation in CPE Building a new panel in CPE, using the latest version of JMRI. I'm drawing my own graphics to link with multisensor icons and placing them on the control panel editor window to create my dispatcher screen. I rotated a few of these graphics and saved the xml file so I could work on another project. When I came back and restarted JMRI, it would not load my xml file. The reason given was "attribute 'degrees' is not allowed for multisensoricon". I ran the script to turn off xml validation so I could at least open my file. I thought at the very least I could reset those affected icons back to zero degrees, but that didn't have any affect. The only thing that will let me open the file with validation was to completely remove the icons which had been rotated. I need to be able to keep working, so in the mean time I will draw separate icons with the needed rotation already drawn in to the graphic. But wondering if this has been mentioned, if it is even a bug, or if rotating multisensors was never planned into JMRI? Thanks Steven
|
Locked
Re: Reading and programming new BLI PRR T1 - PROBLEM
The Silk City Model Railroad Club in Manchester, CT also uses DecoderPro attached to PR3 with 18VDC supply as a dedicated programmer. When we switched to an 18V supply, we no longer needed a programming track booster. However, Paragon 3 decoders are hit or miss and MTH, forget it. You can¡¯t read the CVs. Only a SprogIIv3 as programmer seems to work for those. ? Mark Granville ?
|
George Warner
Ken Cameron
Bob Jacobsen