Larry,
Focus on getting the turnouts working right from the turnout table first.
Each turnout is a pair of events, thrown/closed. The feedback is normally
MONITORING. Once that is correct, then the Routes would be a route has one
or more turnouts, each turnout is selected to be thrown or closed. Keep in
mind for a given route you may have one to N turnouts in that path, you set
what they need for direction. Other turnouts are not included in the route.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Larry,
Turnouts should never use 'toggle'. They should always use two
events, one for normal and the other for reverse. The only time
you would use 'Toggle' (alt action) is if you are controlling
something with a single local push button. (or a button with
feedback controlling an indicator) The problem with 'toggle' is
that you can not follow the turnout state. (as you have
discovered)
Dick :)
On 6/5/2019 6:56 PM, Larry Sloan via
Groups.Io wrote:
toggle quoted message
Show quoted text
OK¡ so that may have resolved the startup issue. ?But when I build
a route and click on the route all the turnouts just change to
their opposite state. ?I was thinking this has something to do
with the Event 1 and Event 2 being set to Toggle.
Larry Sloan
On Jun 5, 2019, at 11:47 AM, Larry Sloan via
Groups.Io < larrylsloan@...>
wrote:
My
node is 02.01.57.00.00.DD
I just updated it. ?I will see
what happens.
Larry
|
No. JMRI routes set JMRI Turnouts to a specific direction. There¡¯s no need to create a workaround to do that, that¡¯s what they should already be doing. If you¡¯re not getting consistent operation between the JMRI Turnout and the physical layout turnout, you should fix that first instead of creating a workaround. (If you¡¯re using JMRI Sensors to control physical layout turnouts, you should fix that even before) Bob On Jun 5, 2019, at 4:24 PM, Larry Sloan via Groups.Io <larrylsloan@...> wrote:
So I¡¯ve figured out that if I want to build a route that I want to *always* go a certain way, that I almost need to configure a turnout as two separate turnouts. One for each route that I want the turnout to be a part of. Would you guys say that is accurate? -- Bob Jacobsen rgj1927@...
|
Locked
Re: Reporting a decoder file error in TCS FL2/4 function decoder
I suggest you open an issue on Github you need to create an account to do so.
It would also be helpful to provide an updated definition if possible.
--
Peter Ulvestad
JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -
|
Locked
Reporting a decoder file error in TCS FL2/4 function decoder
A few years ago I reported an error in the light function settings in the TCS function decoders, today I found the same error is still in place so am reporting it once again. I don't remember if at the time I checked the other settings, but the ones I needed at the time and are still incorrect are for ditch lights. The result is one ditch light is the ditch light of the opposite phase, the other result is a constant dim light instead of the 2nd ditch light. I haven't evaluated what other function settings might be incorrect
copied from the original post:
In the TCS FL4and FL2 function decoders, one of the values to make a function perform as a ditch light is incorrect. The CV value choices should be 10 or 11 for forward operation, 25 and 26 for reverse, and 41 and 42 for non-directional operation. The present values are a value of one too low, making one output non-operational when one uses a value of 9, 24, or 40 that are stored in the DecoderPro files.
Lyle Dowell
|
So I¡¯ve figured out that if I want to build a route that I want to *always* go a certain way, that I almost need to configure a turnout as two separate turnouts. ?One for each route that I want the turnout to be a part of. ?Would you guys say that is accurate?
toggle quoted message
Show quoted text
On Jun 5, 2019, at 3:56 PM, Larry Sloan via Groups.Io < larrylsloan@...> wrote:
OK¡ so that may have resolved the startup issue. ?But when I build a route and click on the route all the turnouts just change to their opposite state. ?I was thinking this has something to do with the Event 1 and Event 2 being set to Toggle.
Larry Sloan On Jun 5, 2019, at 11:47 AM, Larry Sloan via Groups.Io < larrylsloan@...> wrote:
My node is 02.01.57.00.00.DD
I just updated it. ?I will see what happens.
Larry
|
OK¡ so that may have resolved the startup issue. ?But when I build a route and click on the route all the turnouts just change to their opposite state. ?I was thinking this has something to do with the Event 1 and Event 2 being set to Toggle.
toggle quoted message
Show quoted text
On Jun 5, 2019, at 11:47 AM, Larry Sloan via Groups.Io < larrylsloan@...> wrote:
My node is 02.01.57.00.00.DD
I just updated it. ?I will see what happens.
Larry
|
Locked
Re: Tips for splitting my Loconet in two
Steve,
I have done some searching and cannot find the test files that I was using to verify what follows.? So, here are a couple of answers, starting with the one I am most confident about.
Since the throttles are being separated from the signal hardware, usually, all the throttles are placed on the throttle bus and all the signaling hardware (SE8Cs, RR-Cirkits, etc.) on the signal bus.? If all the signal hardware will play together, then that is the preferred way to go.? In that scenario, in JMRI, define the two Loconet interfaces in Edit-Preferences.? The signal bus connection is identified with the "L" system prefix and the throttle bus interface with your favorite prefix.? Under Preferences->Defaults, select the throttle bus interface for hosting Throttles, Power Control, Command Station, Service Programmer, Ops Mode Programmer, and Consists (i.e. simply check all those buttons, moving the filled in dots from the Loconet row to the throttle bus row).
If you cannot completely segregate the throttle hardware from the signal hardware, then things get a little more complicated.? Two buses (connections) must still be defined, as above.? However, CATS accepts only a single letter prefix (some of this stuff is old).? I recommend that you set up the JMRI profile, first, so that you can pick a prefix that will work.? I think JMRI reserves "I", so pick another one.? In designer, Devices->JMRI Devices.? Create two new rows via the Add button or overwrite the "JMRI Class" column on the two existing rows with the desired second prefix from your JMRI profile.? For example, suppose you want to use ES and ET as your sensor and turnout system names for the second Loconet connection.? You would add a row with prefix "ES", Type Sensor, and check the Select box.? The linkage between the JMRI system name and CATS is what goes in the "JMRI Class" column.? Copy the contents of the "JMRI Class" column for the LS row (jmri.jmrix.loconet.LnSensorManager) to the same column for the ES row. Do the same for the LT row to the ET row.? In the rest of the designer layout file, use the appropriate system prefix for each decoder address.
It would be best to be on a fairly recent version of JMRI (and CATS) for this to work.
Rodney
|
Locked
Re: Bachmann Street Car
There aren't many sounds on a trolley, that couldn't just as easily be played on speakers hidden at trolley stops. The running motor noise might be able to be simulated by amplifying and playing the model motor current waveform. I haven't got around to trying that yet, so can't provide a circuit for until a few months time. Andy On 6/5/2019 2:36 PM, forfoum@... wrote: Unfortunately being "close"? may not be good enough.
Comparing this Bachmann SNDValue cv listing that is available from Soundtraxx? to say a Tsunami 1000 (or another SndValue), a few CV's will be lost in the shuffle.? Not many but a few.? The function mapping also use bit 5 that most Tsunami do not (reserved), add to this the naming in the function mapping is different. Those cv's relating to pantograph, arcing, FX functions (the pantograph flicker)? will not get picked up.
If you want to go the? route Jan proposes and save the current CV listing,? use the NMRA , RAW CV's 1-255? definition so you capture it all.
If you want the factory defaults, reset the decoder and read it using the NMRA RAW definitions again.
This will, unfortunately, not tell you who is who and who does what.
I've been trying to work on a definition file for this but JMRI uses a slight variant for the function mapping that, at the bit level, is not matching the SOUNDTRAXX examples in the manuals. Without exact info it is a tad convoluted for me to get it right. It's all guess work and I am not about to pay 200$ Cdn for this trolley.
What would be good is someone who replaced this SNDValue decoder with a Tsunami-2? and would willing? to part with his SNDValue :- )
Marc
--- This email has been checked for viruses by AVG.
|
My node is 02.01.57.00.00.DD
I just updated it. I will see what happens.
Larry
toggle quoted message
Show quoted text
On Jun 5, 2019, at 10:54 AM, dick bronson via Groups.Io <dick@...> wrote:
Larry,
I'm not sure why Turnouts shouldn't be called Turnouts and entered in the JMRI Turnout table. There is a button in the CDI to do just this. Your friend is correct that there is no actual distinction. However, in general you should probably call turnouts turnouts and sensors sensors in JMRI to avoid confusing the troops.
However I am more concerned with the statement that the Tower LCC does not remember the state. The Tower LCC node has always remembered the state of its outputs when it powers up again. However there was a firmware bug in the very early nodes that failed to report the state correctly to JMRI. That was fixed a couple of years ago. If you happen to have one of those early nodes be sure to upgrade it to the current version of firmware. See:
The LCC protocol actually implements a very robust synchronization between nodes, of which JMRI is one. It does not even matter what order the nodes are powered up, they will still synchronize with one another properly. They should never require any scripts or special query messages to get this information like some other systems do.
Dick :)
|
I just described how I used LCC to control a staging yard over on layoutcommandcontrol here on groups.io, but it's only 3 tracks and 2 turnouts and doesn't use JMRI, so I'm not sure it would be any help.
Tim Rumph
Lancaster, SC
|
Larry,
I'm not sure why Turnouts shouldn't be called Turnouts and entered in the JMRI Turnout table. There is a button in the CDI to do just this. Your friend is correct that there is no actual distinction. However, in general you should probably call turnouts turnouts and sensors sensors in JMRI to avoid confusing the troops.
However I am more concerned with the statement that the Tower LCC does not remember the state. The Tower LCC node has always remembered the state of its outputs when it powers up again. However there was a firmware bug in the very early nodes that failed to report the state correctly to JMRI. That was fixed a couple of years ago. If you happen to have one of those early nodes be sure to upgrade it to the current version of firmware. See:
The LCC protocol actually implements a very robust synchronization between nodes, of which JMRI is one. It does not even matter what order the nodes are powered up, they will still synchronize with one another properly. They should never require any scripts or special query messages to get this information like some other systems do.
Dick :)
toggle quoted message
Show quoted text
On 6/5/2019 12:36 PM, Larry Sloan via Groups.Io wrote: Hi all,
I¡¯m working on implementing LCC on some modules I have, where I have an auto delivery facility. I have a Tower LCC, and an SMD8 connected to Tortoises. I was told by a friend who knows a lot more about this than I do, that I would control the turnouts as ¡°sensors¡± on the table in Panel Pro 4.14. The friend is currently otherwise occupied with life, as often happens. I did that and got as far as getting it so that I could control the direction of the turnouts by clicking on them in the sensor table. That works. But I¡¯m noticing that when I start up the whole thing, the Tower doesn¡¯t seem to ¡°remember" what Inactive/Active means for a particular sensor. The turnout might be thrown or closed. Since I was planning on setting a route, this would be an important thing. So my question is - is there something I¡¯m missing here?
Larry Sloan
Kent, WA
|
I actually think it¡¯s more likely that he¡¯s thinking about the grand scheme of things as it were. The Person I¡¯m usually talking to installed and programmed layout command control for the entire 11 track yard and wye for the group and all of that works really well. But I have a couple of days off and I wanted to work on it while I have the time.
That said, I will do some more tinkering.
Larry
toggle quoted message
Show quoted text
On Jun 5, 2019, at 10:33 AM, Bob Jacobsen <rgj1927@...> wrote:
Perhaps you misunderstood what your friend said, or you got some not-so-good advice.
The Tortoises on your layout should be controlled by Turnouts in JMRI, i.e. via the Turnout table.
Yes, there are other ways to do it, but they make things difficult, confusing, and unreliable. Sort of like using a screwdriver to drive nails¡
Bob
|
Perhaps you misunderstood what your friend said, or you got some not-so-good advice. The Tortoises on your layout should be controlled by Turnouts in JMRI, i.e. via the Turnout table. Yes, there are other ways to do it, but they make things difficult, confusing, and unreliable. Sort of like using a screwdriver to drive nails¡ Bob On Jun 5, 2019, at 9:36 AM, Larry Sloan via Groups.Io <larrylsloan@...> wrote:
Hi all,
I¡¯m working on implementing LCC on some modules I have, where I have an auto delivery facility. I have a Tower LCC, and an SMD8 connected to Tortoises. I was told by a friend who knows a lot more about this than I do, that I would control the turnouts as ¡°sensors¡± on the table in Panel Pro 4.14. The friend is currently otherwise occupied with life, as often happens. I did that and got as far as getting it so that I could control the direction of the turnouts by clicking on them in the sensor table. That works. But I¡¯m noticing that when I start up the whole thing, the Tower doesn¡¯t seem to ¡°remember" what Inactive/Active means for a particular sensor. The turnout might be thrown or closed. Since I was planning on setting a route, this would be an important thing. So my question is - is there something I¡¯m missing here?
Larry Sloan
Kent, WA -- Bob Jacobsen jacobsen@... +1-510-708-5988 AIM, Skype JacobsenRG
|
The thing that is more concerning to me is - the system won¡¯t set a turnout consistently with it¡¯s status. ?IOW, it could say ¡°Active¡± and be Thrown or Closed. ?How do your program a route if the system can¡¯t even remember a status?
Or maybe the route is not saved in the Tower the way I¡¯m doing it? ?So like you say JMRI isn¡¯t remembering it so the route is getting messed up that way¡ ?hmm¡
toggle quoted message
Show quoted text
On Jun 5, 2019, at 10:07 AM, SwissChris < chris@...> wrote:
Hi Larry. on Start-up, JMRI doesn't remember the status of anything.There are a couple of scripts which set switches and sensors but it's all one way or the other. I don't know if anybody has written a script which saves the state of everything which could be run just before closing the system down, and then another which reads the info back into JMRI. I'd have a go but I don't know or understand the script language well enough to do it.
_.
|
Hi Larry. on Start-up, JMRI doesn't remember the status of anything.There are a couple of scripts which set switches and sensors but it's all one way or the other. I don't know if anybody has written a script which saves the state of everything which could be run just before closing the system down, and then another which reads the info back into JMRI. I'd have a go but I don't know or understand the script language well enough to do it.
|
Locked
Re: Bachmann Street Car
Ken: Perhaps stating the obvious but having selected a decoder that seems like it might be close and thus "checked the box", it is a good idea to read all the CV values and save them as the default. You can then make copies of this default to experiment with safe in the knowledge you can always reload the default values if necessary. The best way to read the CV values is using "read full sheet" from the "CV" tab.
Jan
|
Hi all,
I¡¯m working on implementing LCC on some modules I have, where I have an auto delivery facility. I have a Tower LCC, and an SMD8 connected to Tortoises. I was told by a friend who knows a lot more about this than I do, that I would control the turnouts as ¡°sensors¡± on the table in Panel Pro 4.14. The friend is currently otherwise occupied with life, as often happens. I did that and got as far as getting it so that I could control the direction of the turnouts by clicking on them in the sensor table. That works. But I¡¯m noticing that when I start up the whole thing, the Tower doesn¡¯t seem to ¡°remember" what Inactive/Active means for a particular sensor. The turnout might be thrown or closed. Since I was planning on setting a route, this would be an important thing. So my question is - is there something I¡¯m missing here?
Larry Sloan
Kent, WA
|
Locked
Re: IR Block Occupancy Sensors - Entrance and Exit
That¡¯s not hard. It¡¯s already in the JMRI block tracking. It follows a single mainline train well. But it¡¯s not always sufficient for more complicated things without lots of detected blocks. For example, if a train enters block A or C from some _other_ block, you¡¯ll incorrectly move TrainID. You have to have at least _two_ blocks between trains. You also need to have all spurs detected (or a train will disappear and it¡¯s tracking lost), have to have blocks shorter than whatever following length your trains have (and some trains really do tuck right up behind others), etc Mostly, it¡¯s a matter of thinking through how complicated you want the automated tracking to be. Bob On Jun 5, 2019, at 12:03 AM, Stephen Grant Brown <steve.brown_nbn@...> wrote:
Hi There,
What I am about to suggest to probably far too software intensive.
Let us assume that there can be no train or at most one train in any block.
Is it possible to determine the speed and direction of train?.
If "yes" would the following work?
Let us assume that we know that there is a train in block B that is called TrainID.
We can easily determine that if TrainID is moving forward, it will enter Block A.
We can easily determine that if TrainID is moving backward , it will enter Block C.
If we monitor the speed and direction of TrainID and see that it is going forward, we can determine that when TrainID is no longer detected in Block B, it must be in Block A, as verified by the Block Occupancy detectors for Block A and Block B.
If we know the speed of TrainID and the length of Block A and the time it entered Block A, it can be determined when TrainID will leave Block A and enter Block Z.
Is this too software intensive?
Stephen.
-----Original Message----- From: Ken Cameron
Sent: Tuesday, June 4, 2019 8:58 PM
To: [email protected]
Subject: Re: [jmriusers] IR Block Occupancy Sensors - Entrance and Exit
Maybe borrowing from the prototype might help. As I understand it, some
country's prototype railroads use optic sensors. Here a sensor spot is
really two sensors very close together. The result is that it knows which
direction (and speed) the train is passing. It then is doing an axle
counting to tell if a train has finished passing or not. So if 50 axles
passed into a block, it doesn't consider the block empty until 50 have left.
These might not be just optic sensors but what I read said it was a place on
the track to determine when the block was clear or not by doing the axle
counting.
The worst case to figure out is when a train stops over the sensor spot,
then the train goes into reverse. Give it some thought and you would see
getting it right every time is not simple.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
-- Bob Jacobsen rgj1927@...
|
Locked
Re: Bucklew's Tutorial Part 2
Thank you all. I forgot to mention, as I did in my last post, how absolutely? great I think the tutorials are. And I apologize that, as another poster from Quebec (who for some reason no longer appears in this thread) pointed out, I failed to put the link to the tutorials in my post. Thanks again!
|
Ken Cameron
Bob Jacobsen
Peter Ulvestad
Lyle Dowell
Tim
SwissChris