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!
|
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
|
Lyle Dowell
Tim
Bob Jacobsen
SwissChris
Ken Cameron