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!
|
Locked
Re: Copying config files
Dan K,
It is considerably more than just changing the I to M. Instead you should be
having user names assigned to your sensors and turnouts. Then it is a right
click on the username and 'Move' to pick the new system name to go with it.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: Bachmann Street Car
Hi Marc, ? ?No one other than you has replied as far as I know. ?The guy in my local train store said I could choose and decoder to more or less check the box and move on to entering the street car in decoder Pro as long as I did not program it. ?For now I have changed the DCC address and everything works so for now I am good. ?I did check out and saved the pdf you linked so thanks for that and the response. ?Ken
toggle quoted message
Show quoted text
On May 29, 2019, at 2:28 AM, forfoum@... wrote: The reason for this is simple:? there is no documentation re the Bachmann SoundValue Electric decoders. All that exists is the CV listing available from Soundtraxx for the GG1 and PCC trolley. This lack of info makes it hard to write up a definition. Closest documentation would be the Econami Electric. But there are quite a few differences involved that writing up a definition based on it is not so simple.?
Unless Soundtraxx can provide the details, I believe things will not change. What is required is a technical manual for these, discontinued, decoders.
Bowser has a PCC in there Executive line that uses Tsunami, but nothing to match the SoundValue Bachmann uses.
Marc
|
Locked
Re: Copying config files
Ken:
I think I have found my problem. I understand how to glue files from different sources into a new configuration profile. The problem I face (I think) is the files (block, sensor, turnout and panels) are being generated from a profile specifying the connection as none and the target profile has the connection set to OpenLCB... two different system names. Can system names be edited To change the prefix from I (internal) ?to M for OpenLCB.
Dan Kubarych
ARHS
|
Locked
Re: IR Block Occupancy Sensors - Entrance and Exit
Hi Stephen,
This is not a million miles away from what I am planning to do. So I hope it's not going to be software-intensive, and I think it won't be. Determining speed and direction are both not going to be trivial. For the former, there will need to be calibration (I plan to make an automatic calibration process that will measure speed through a block at every speed step and in both directions, kept in a configuration table, or a number of configuration tables) and for the latter at some point someone will have to tell the software which side of the engine is facing forward - ther's no getting around that unless the software is going to be allowed to tentatively move an engine until it hits the next block - which I am not willing to do.
Plenty of issues to resolve after that: coping with momentum settings, with changes over time (short term: engine warming up, long term: engine becoming older) and probably loads more that I'm not yet aware of, but I'm hoping it'll work within certain tolerances.
I will get the speed and direction information from sniffing the DCC track signal, so non-DCC throttles will not pose a problem.
Wouter
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
|
Locked
Re: IR Block Occupancy Sensors - Entrance and Exit
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.
toggle quoted message
Show quoted text
-----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
|
Locked
Re: Bucklew's Tutorial Part 2
Haltz,
It hs been more than 5 years since I wrote the tutorial, but I looked back and see that IS801-IS806 are the block sensors that show as small lights or lamps on the track sections. These are internal sensors.
The sensors NS801-NS806 are pictured as switch icons and are used to activate the block sensors so you can test your panel Logix and operation without connecting to any hardware. Logix later created on page 35 will activate Block IS801 when switch NS801 is turned on.
Bob Bucklew
toggle quoted message
Show quoted text
----- Original Message ----- From: haltz@... To: "jmriusers" < [email protected]> Sent: Tuesday, June 4, 2019 4:23:16 PM Subject: [jmriusers] Bucklew's Tutorial Part 2 Hi again. Still a newbie, I am working through these tutorials and am baffled by a couple of things. Block sensors IS801-806 get added p. 30 and on. Detectors NS801-806 get added p. 32 and on. I'm not yet sure how these work and interact (especially since in English the terms sensor and detector are pretty much synonymous) but I'm sure I'll learn once I study, reread some more, and? study the Logix better. Also, interlock sensors get added to 4 turnouts, around page 30. My question is about what appears? and doesn't appear on picture of the resulting panel (Fig. 71, p. 34).. 1. The red dots on the turnouts are the interlock sensors, right? 2. The 6 icons (4 below, 2 above the tracks) represent the detectors, right? 3. So I assume the other red dots on the tracks represent the block sensors, yes? But I followed the instructions on p. 30, where it says "we''ll use the standard sensors here"and I ended up with icons that look like switches, on the tracks. What am I missing? Maybe I should do a Change Icon before I place them? Thanks!
|
Locked
Re: Storing roster (and other) files under different customized names
There are 21 Marklin decoders - they are under Trix in the index.
If you ask Decoder Pro to identify the decoder - the right decoder will be found.
Thank you Gerry for that piece of advice. Regards Joern
|
Locked
Bucklew's Tutorial Part 2
Hi again. Still a newbie, I am working through these tutorials and am baffled by a couple of things. Block sensors IS801-806 get added p. 30 and on. Detectors NS801-806 get added p. 32 and on. I'm not yet sure how these work and interact (especially since in English the terms sensor and detector are pretty much synonymous) but I'm sure I'll learn once I study, reread some more, and? study the Logix better. Also, interlock sensors get added to 4 turnouts, around page 30. My question is about what appears? and doesn't appear on picture of the resulting panel (Fig. 71, p. 34)..
1. The red dots on the turnouts are the interlock sensors, right?
2. The 6 icons (4 below, 2 above the tracks) represent the detectors, right?
3. So I assume the other red dots on the tracks represent the block sensors, yes? But I followed the instructions on p. 30, where it says "we''ll use the standard sensors here"and I ended up with icons that look like switches, on the tracks. What am I missing? Maybe I should do a Change Icon before I place them?
Thanks!
|
Locked
Re: Storing roster (and other) files under different customized names
Joern
There are 21 Marklin decoders - they are under Trix in the index.
If you ask Decoder Pro to identify the decoder - the right
decoder will be found.
Gerry
On 4/06/2019 9:53 pm, Dr. Joern Behnke
wrote:
@ Dave
???? Jan
???? Mick
Thanks for your helpful answers.
Indeed "Duplicate" may serve as substitution for "save as ...".
Not quite as elegant and simple since you need to do it before
customising, but still.
Apart from that:
Any idea, why M?rklin decoders are not listet in DecoderPro?
Regards
Joern
--
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder
NMRA Australasian Region
Contest & AP Chairman
Web Administrator
|
Locked
Re: Storing roster (and other) files under different customized names
@ Dave
???? Jan
???? Mick
Thanks for your helpful answers.
Indeed "Duplicate" may serve as substitution for "save as ...". Not quite as elegant and simple since you need to do it before customising, but still.
Apart from that:
Any idea, why M?rklin decoders are not listet in DecoderPro?
Regards
Joern
|
Tim
Bob Jacobsen
SwissChris
Ken Cameron