Re: Block occupancy without resistive wheelsets
Roger,
With turnouts in a separate block, and not even very long trains, you'd see the occupancy indicator of the turnout go off while both blocks at either side remain on - unless there's added logic.
Wouter
My mainline freights always have a last car with a FRED which is drawing power. A lighted caboose would be the same. So the occupancy light trips as soon as the loco enters, and doesn't release until the last car leaves. No need for resistor wheels on intermediate rolling stock.
|
Re: The future of control and automation - thoughts?
But also remember that a lot of us like to drive the trains and operate the layout entirely manually. Automation holds absolutely no attention from me.??
Same here. OperationsPro is my sole use of JMRI these days. (And occasionally DecoderPro, but mostly LokProgrammer)
?
So in that vein, I've begun to wonder if I could use AI (namely, v0.dev) to write code modifications for OpsPro to mold it more to my niche-prototype likings. Would love to have suggestions on how specifically to do so if anyone has any, as I'm willing to learn but would prefer not to if I can help it. Am the wrong kind of engineer by trade!
?
More to OP's original question, I think Bluetooth is the future (especially for loco-to-loco comms) but the current offerings (namely Blunami & RailPro) are neither mature nor featured enough to get me to switch from DCC.
?
Isaac
|
Re: The future of control and automation - thoughts?
At Wed, 19 Mar 2025 04:55:45 -0400 "Mick Moignard" <mick@...> wrote: Don't forget that Soundtraxx offer Bluetooth-controllable decoders as well.
But also remember that a lot of us like to drive the trains and operate the
layout entirely manually. Automation holds absolutely no attention from me. Sometimes it can be more interesting to have an additional train or two operated "by the computer" along with the one mnually operated train.
I'd also point out that a software controlled block detection which attempts
to detect when a block ceases to be occupied by seeing the loco, and
estimating block clearance by working with throttle setting and train length
is bound to fail - derailed trains, split trains, train stopping in section,
not moving at the expected speed, and so on. All of those are why the
prototype would only rely on actual detections, and then fail safe. Isn't it
just easier and waaaaay faster and probably cheaper too, as well as more
accurate and prototypical to add resistor wheel sets to the last vehicle in
a train, typically a caboose/brake van or parlour car?
It is effectively prototypial to have "resistive" wheelsets, if you count a solid steel axle as a "resistor"...
Mick
________________________________
Mick Moignard
Specialising in DCC Sound
m: +44 7774 652504
The week may start M,T but it always ends WTF.
-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services -- Linux Administration Services heller@... -- Webhosting Services
|
Re: Block occupancy without resistive wheelsets
The dispatcher functionality was only implemented from 5.10. I need to update and have a look. I was impressed by which implements a solution in the detector hardware (arduino) to calculate (estimate) the end of train position. It will be interesting to compare all the options!?
|
Returning to the original question in this thread: Would an Apple Silicon Mac, e.g. an M4, be able to run a DMX512 connection natively?
I’ve made some more progress on this: I have been able to set up a M1 Mac with the right native libraries (as opposed to x86_64 Intel libraries) and JMRI is able to make a HID connection to another device in the same way an Anyma connection would be made. So that works.
I think the answer is “Yes, if the Mac is set up with native libraries”. I don’t have an actual Anyma DMX512 system to check with, so I can’t be 100% sure.
Bob
—
Bob Jacobsen
rgj1927@...
|
Re: Signal Mast Logic
#sml
On 3/19/2025 7:43 AM, David Smith via groups.io wrote: Can I also please ask, if ?I add a mast that is not visible on the panel, is there a way to see or edit it afterwards ? Sure there is. "Tools"->"Tables"->"Signals"->"Signal Masts" . Or "Tools"->"Tables"->"Signals"->"Signal Mast Logic" . As appropriate. Also, can I ask why all of the signal heads appear in the Turnouts table ? It depends on how you have defined the signals. If you build a JMRI "Signal Head" or a JMRI "Signal Mast" using individual JMRI "Turnout"s, by definition JMRI _must_ define the turnouts before it can use those "Turnout"s. (This goes back to the original NMRA DCC specifications where where the only way to control anything of an "accessory" nature was via a DCC turnout. JMRI followed this assumption. And the majority of Signal hardware uses that same assumption. Where a hardware signaling device _does not_ use a DCC "Turnout" address, that device will generally not use a JMRI "Turnout".)
|
Re: Block occupancy without resistive wheelsets
Hi
Dispatcher runs trains automatically or with manual drivers need only the head of the train detectable and a length for the train.
After the head leaves a block it shows that the block is unoccupied but allocated (so it cannot be allocated to another train) until the calculated end of the train exits the block.
It uses pessamistic assumptions about the position of the head in an occupied block.
You can also use Head and tail detection so a single car detected car at the rear is required. Lighted caboose , track powered FRED.
The major down side of head only is the failure to detect broken trains, so I would never use them for an exhibition piece.
Steve G.
?
|
Re: Block occupancy without resistive wheelsets
My mainline freights always have a last car with a FRED which is drawing power. A lighted caboose would be the same. So the occupancy light trips as soon as the loco enters, and doesn't release until the last car leaves. No need for resistor wheels on intermediate rolling stock.
|
Hi All,
?
I have added the panel file ?exhib.xml to the David Smith folder in ProblemsBeingWorked?
There are some issues with some of the signal masts.
Could someone please advise what the problem may be ?
?
Buffer masts Mst_Buff_SdS4, Mst_Buff_SdS5, Mst_Buff_SdS6 are set to Unknown
?
Mst_SE3, Mst_SE2, Mst_SW3e, Mst_SW3f, Mst_W4 signal logic does not see other masts correctly
( I am aware that I could fix the issues by manually editing the signal logic but would prefer not to )
?
Can I also please ask, if ?I add a mast that is not visible on the panel, is there a way to see or edit it afterwards ?
?
Also, can I ask why all of the signal heads appear in the Turnouts table ?
?
Thanks
Dave
|
Now in JMRI GitHub as issue #13945
And from there, should find its way through approvals to a JMRI test release.??
- Nigel
toggle quoted message
Show quoted text
------ Original Message ------
Date 14/03/2025 14:50:26
Subject Re: [jmriusers] Zimo MS450P22 CVs above #841 #zimo #definitions
OK,? now added to my local file.? ? I've also removed the comments around the MS540E24 decoder, as I think its likely available.??
They'll be in the update when it goes to the JMRI approvals processes.??
- Nigel
------ Original Message ------
Date 14/03/2025 13:03:58
Subject Re: [jmriusers] Zimo MS450P22 CVs above #841 #zimo #definitions
Can you also add the new MS decoder MS591N18 CV250=15 ?
?
The type of decoder can be read out from the value of CV #250 if required:
?1 = MS500 2 = MS480 3 = MS490 4 = MS440 5 = MS580
?6 = MS450 7 = MS990 8 = MS590 9 = MS950 10 = MS560
11 = MS001* 12 = MS491 13 = MS581 14 = MS540 15 = MS591
16 = MS481 *?
119 = MN140 120 = MN250 121 = MN150 122 = MN160 123 = MN340
124 = MN170 125 = MN300 126 = MN330 127 = MN180
|
Re: Block occupancy without resistive wheelsets
It can be done in Java. I? fact, I am doing something in Java on topmof JMRI that has train lengths (standard jmri doesn't have it for running trains, only for the relatively stand-alone "operations").
Using the information for positioning is not at all straightforward, though, because the positioning "brains" must at all times be aware of speed changes, too.
A further complication is, that this would be relatively easy for standard trains, but when adding and removing wagons the overhead of people having to add those changes to the "train" (a concept not present in java!) is considerable unless it can be automated with strategically placed RFID units. So a layout that uses unchanging passenger trains would be better served than one with lots of shunting of goods trains.
In short: it sounds much easier than it is.
Wouter
To ensure the whole train is considered when assessing block occupancy by current sensors and not just the current drawing locomotive the standard solution is resistive wheelsets. However JMRI knows (with speed profiling) the speed of a train and can also record its length. Along with block length these values would allow a calculation of the block occupied by the end of the train. Would it therefore not be possible to show a block as occupied until the end of the train had left it? I can't find any information on this functionality within JMRI. Is this something that could be implemented on top of JMRI in (say) python or java? Anyone explored this? Any ideas?
|
Re: The future of control and automation - thoughts?
Don’t forget that Soundtraxx offer Bluetooth-controllable decoders as well.
But also remember that a lot of us like to drive the trains and operate the layout entirely manually. ?Automation holds absolutely no attention from me. ?
I’d also point out that a software controlled block detection which attempts to detect when a block ceases to be occupied by seeing the loco, and estimating block clearance by working with throttle setting and train length is bound to fail - derailed trains, split trains, train stopping in section, not moving at the expected speed, and so on. All of those are why the prototype would only rely on actual detections, and then fail safe. ?Isn’t it just easier and waaaaay faster and probably cheaper too, as well as more accurate and prototypical to add resistor wheel sets to the last vehicle in a train, typically a caboose/brake van or parlour car?
Mick ________________________________ Mick Moignard Specialising in DCC Soundm: +44 7774 652504
The week may start M,T but it always ends WTF.
|
Re: The future of control and automation - thoughts?
CAN stands for "Controller Area Network," a peer-peer network standard.
?
-- Andy
|
Re: Block occupancy without resistive wheelsets
Operations has a max train length value. ?This is used to limit train sizes between switching locations.
Dispatcher has a max train length for automatically controlled trains.
I am not aware of any other places where train length might be stored. ?
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Block occupancy without resistive wheelsets
Date: Tuesday, March 18, 2025 9:48 PM
That JMRI has the facility to store the train length. This would allow the calculation of the position of the end of the train.
|
Re: Block occupancy without resistive wheelsets
That JMRI has the facility to store the train length. This would allow the calculation of the position of the end of the train.
|
Re: Block occupancy without resistive wheelsets
What do you mean by "record its length"? ?
Dave Sand
----- Original message -----
Subject: [jmriusers] Block occupancy without resistive wheelsets
Date: Tuesday, March 18, 2025 7:28 PM
To ensure the whole train is considered when assessing block occupancy by current sensors and not just the current drawing locomotive the standard solution is resistive wheelsets. However JMRI knows (with speed profiling) the speed of a train and can also record its length. Along with block length these values would allow a calculation of the block occupied by the end of the train. Would it therefore not be possible to show a block as occupied until the end of the train had left it? I can't find any information on this functionality within JMRI. Is this something that could be implemented on top of JMRI in (say) python or java? Anyone explored this? Any ideas?
|
Re: Block occupancy without resistive wheelsets
yes adding further physical detectors is a solution.? however surely there is a software solution?
|
Re: Block occupancy without resistive wheelsets
Here a method used by the modular Free-mo groups that do signaling. It is call MSS for Modular Signal Standard. It uses block track detectors to see the locos and anything drawing power from the rails. But to catch all the cars that likely do not have resistive wheelsets they use an optic detector at each block boundary. What it does it holds each block as active until the optic detector is no longer triggered. ? When I train is passing from one block to the next, first the loco triggers the optic but then continues on and keeps the track block detector active. Next the cars keep both blocks active until the last car passes the optic detector. At that point the prior block clears. Now if the loco hasn’t reached the other end of the block, that block is active because of the loco. However it the loco has hit the next block, then the cars behind it are triggering the local block (and the next block too). This keeps this block active as if all those cars had resistors. ? If you look at the website, you might get the clues from the graphics and other explanations there. Now you don’t need that interconnecting for a normal layout. All that’s because we never know which way the modules end up getting placed into the layout. ? But the idea of combining current detection with the optic at the boundaries is really pretty good at giving the right results regardless of how many cars have resistive wheelsets. Only catch is they won’t detect a broken train that lost a car in the middle of a block. ? -Ken Cameron, Member JMRI Dev Team
? ?
|
Re: The future of control and automation - thoughts?
Peter,
?
Just a couple of things I know about relating to some of your questions:
?
- I believe Hornby have implemented Bluetooth control in some of their recent TT scale locomotives, using their HM7000 decoder
- There is a project called 'EX-SensorCAM' that the DCCEX team are working on to use a camera watching a layout to provide the equivalent of block detection.? Have a look here:
- I have personally used 2 x WiFi connected lights to provide scene ambient lighting (Night > Dawn > Morning > Midday > Afternoon > Dusk > Night) for my model railway layout.? Using 2 lamps (1 in the East and the other in the West) provides a shift in the light direction as well as varying the light intensity and colour.? I control the lighting via Jython scripts in JMRI, which sends data out of JMRI to control the lights.
- One of the clubs I'm a member of has a string of W2812 style RGB LED strip for creating lighting effects controlled by an Arduino system.? This could be adjusted to be controlled from a DCC command station
- The DCCEX project has recently included code to allow control of NeoPixel lights directly from the DCCEX command station, using their EXRAIL scripting system:
- I believe some people have used AI to generate Jython code for JMRI, but (not having done this myself) I understand the AI generated code isn't perfect and needs some adjustment.? I have seen people post AI generated code in this group in the past.
So those are just some things I'm aware of that you might be interested in checking out.
?
Trevor.
|
Block occupancy without resistive wheelsets
To ensure the whole train is considered when assessing block occupancy by current sensors and not just the current drawing locomotive the standard solution is resistive wheelsets. However JMRI knows (with speed profiling) the speed of a train and can also record its length. Along with block length these values would allow a calculation of the block occupied by the end of the train. Would it therefore not be possible to show a block as occupied until the end of the train had left it? I can't find any information on this functionality within JMRI. Is this something that could be implemented on top of JMRI in (say) python or java? Anyone explored this? Any ideas?
|
Bob Jacobsen
Ken Cameron