DS64's, jmri, routes, and all that

[carlso]

Ben and Bill,

I hope that I am not hi-jacking this thread but I have a question that is DS-64 realetd and may have some value for others.

Our club layout is using, I think 10 DS-64's, to control our turnouts. I set up about 1/2 of them and another person the other 1/2 and we still need 2 more DS-64's. Here is the problem - - - after the layout has been totally turned off for a period of a few hours or several days, the first time we fire it up, or I should say, power up the DS-64's go bananas and through the switches. I and another man have contacted Digitrax and they could not say why that is happening. The have recently admitted that they could duplicate the problem but still have no answer. Perhaps an additional booster they say. We have tried track power as well as wall warts only, with the same problem.

Have any of you experienced this situation and if so what have you been able to do to stop it? ?

Thank you in advance for any help,

Carl

[Bangorboy]

Hi Carl,

I have five fully-populated DS64s.  Most of my turnouts never do this.  I have a couple that seem to cycle for no reason when I turn on the power, but only sometimes.  I don't know why. 

I've never looked into it, because it isn't on my priority list.  It disturbs me that somehting is happening that I don't understand, but for now I have my JMRI programmed with a route that sets all mainline turnouts to a known position.  All other turnouts get set as desired when I call a route.  So for now, I just live with it. 

I'm putting my time into progressing toward an operational and at least partially scenicked layout.  After that, I'll have more time and may start to look into this, unless something more important or more irritating to me comes along.

It's intriguing that Digitrax can duplicate the random movements but doesn't know why they happen.  Makes me wonder if trying to troubleshoot would be futile anyway.  Thank heavens and JMRI that I have a workaround.

[GaryHinshaw]

I have not experienced this either Carl, but it is still early days for me. I'll keep an eye out for this as I get more units installed and power cycled.  Just to clarify: when you say the DS64's "go bananas", do you mean that individual turnouts are thrown more than once, or just that many turnouts are each thrown once?  In theory, the DS64's should come back online to their previous state if OpSw6 is thrown (the default).  If it's not thrown, the units will boot up with the outputs powered off until commanded.  BTW, are you using stall motors or solenoids?

Bill, I set the internal sensors to activate a particular route and to display one way or another depending on which route was selected.  I have made no attempt to link these sensors to single turnout states, but I suppose I could.  I am away from home right now, but I'll play with it some more when I return, and maybe post a few sample panel images to illustrate.  I'm pretty sure there is a way to manage this better than I have.

[John]

unless you need routes in DS64s, disable that ..

[Bangorboy]

Bill, I set the internal sensors to activate a particular route and to display one way or another depending on which route was selected.  I have made no attempt to link these sensors to single turnout states, but I suppose I could.  I am away from home right now, but I'll play with it some more when I return, and maybe post a few sample panel images to illustrate.  I'm pretty sure there is a way to manage this better than I have.

<<<Edit:  I don't use sensors or lights for individual turnouts, either. End edit >>>  For my route indications, I have not used the internal sensors the way you appear to mean.  There is a sensor on the panel outside the track plan which uses the IS&S lights for icons, looks like the green light on a CTC panel.  If the route is selected, the light is bright green, if any turnout is set away from the route, it goes dark.  (Other states exist, too.  The icons are black with a white question mark when power first comes on as state of turnout is unknown, and black with a white X if there's conflicting data in JMRI about the turnout.  Don't know how that state occurs, never seen it.  But that's the choices I set up in the icon settings for the sensor.)

Each route into my staging yard has a similar light which goes bright when all the turnouts to that track are set properly.  So each end of the yard has dark green lights on all tracks except one.  If you change one turnout by direct addressing with a handheld or a pushbutton, that light goes dark and the appropriate one for the new selected route goes bright.   Again, each of these sensors is set to the true state whenever the route to that track is satisfied, and the false state if the route is not satisfied.  These sensors are not used to trigger the route, only to show the state of the route output sensor.  I use a separate icon like a red pushbutton to trigger the route.

I tried to use the lights to trigger the route and have them change to show the route was selected, but that's where I ran into the perpetual loop where most of the routes worked fine, but a couple would cycle the turnout, set the sensor, retrigger the route, reset the sensor , retrigger.......

Bill

[GaryHinshaw]

Bill,

Thanks for taking the time to describe your setup so thoroughly.  However, part of your write-up still eludes me:

There is a sensor on the panel outside the track plan which uses the IS&S lights for icons, looks like the green light on a CTC panel.  If the route is selected, the light is bright green, if any turnout is set away from the route, it goes dark.

Perhaps this will become more clear to me when I get home and can play with this some more, but I would be grateful if you could expand on the concept of "a sensor on the panel outside the track plan".  Is this sensor set up by you in the sensor table, then linked in the route table?  Something else?

Thanks again, -gfh

[carlso]

Thanks to all for the input, I appreciate.

Let me back up to the beginning and say that this layout is totally Digitrax, we used Unitrak, Unitrak turnouts as well, so they are solenoids thrown. I really don't remember if there are 8 or 10 DS-64's that are fully-populated. The system works very well with single turnout action or with routes of multiple turnouts. One of the routes I had to use the nesting procedure and it works well. Everything about them is fine except the cycling when we power up the layout. It is a pain to close turnouts before running.

Gary, when I said they went bananas I suppose that was the wrong choice of word. They each go into the thrown position, only once, but when we were first setting these up we did have some that cycled thrown to closed to thrown.
That isn't happening now. The OpSW6 may be the key here except that according to the DS-64 manual "If the DS-64 OpSW6 is in thrown position (default) at power on, all DS-64's and their 4 outputs power up automatically to their last state. That doesn't seem to be happening and I think none of those OpSW's have been changed from default. I am beginning to think that the "fix" will be to put OpSW6 into closed  so that at power up, the DS-64 powers up and the 4 outputs do not power up until they receive a command

I will be in Las Cruces Wednesday and will try that on some of the DS-64's.

Thanks again to all for the replies.

Carl

PS: I think we may want to change OpSW8 that controls the startup delay. We tried that with a mini timer but still experienced the problem because all of the DS-64's powerd up at the same time. With OpSW8 in the thrown postition the startup time is 65ms times the number assigned to output 1 on the DS-64. Therefore each DS-64 will power up at different times with each one progressively being a longer delay. Clear as mud huh, must be, it came from DS-64 manual

[Bangorboy]

Sorry my description isn't clearer.  Let's try this:

On each end each of my yard tracks, there are two sensors placed directly on the line depicting the track.  Looking at one end, there's a sensor/icon representing a red button to trigger the route to that track.  Next to it is a green light sensor/icon which is dark unless the route is selected, in which case it's bright.  Originally, I designed the green light icons as the sensor to trigger the route in each case, but had the cycling, never-ending loop problem with some routes.  Talking with the JMRI guys, they say they never intended the sensors to work the way I was using them, so they don't know why I ran into the problem.  For uniformity, I added the red buttons to all the tracks on both ends of the yard.

Normally, I use the mainline route only when I first fire up the layout for a known starting condition.  There didn't seem to be a place on the track diagram which would be appropriate and intuitive, so I just placed a green light sensor/icon down in the bottom corner of the track diagram panel, away from the displayed tracks, but similar to the ones on the yard tracks.  It is bright if all the mainline turnouts are lined for through trains, and goes dark if any of those turnouts is not aligned to the main.  I didn't have any problems with this route cycling when I used the light to trigger the route by clicking on it, so I never added a red button to trigger that one.  And it "illuminates" again if the turnouts are all returned to alignment for the main

[GaryHinshaw]

Carl, my guess is that switching OpSw6 could solve your issue, but I'm only 51% confident of that.     I doubt that introducing a lag with OpSw8 will make any difference to your specific problem because you already seem to have enough power to drive all the turnouts at once (whether intended or not).  It couldn't hurt to try it though.

Bill, that is more clear, thanks.  It sounds like my current sensor setup is similar to your first incarnation with a single sensor per track that acted as both a trigger and display.  (Happily I never encountered an infinite loop.)  Now to drill a bit deeper, could I ask you how you activate the green sensor?  Here is how I did mine: I defined N internal sensors, ISn, where n=1,2,3,...,N and N is the total number of tracks in my yards.  I then defined routes for each yard track, n, and added a condition for each route to activate ISn, and deactivate the other N-1 IS's when that route was selected.  This worked fine for both triggering routes and displaying route status (I still have the route table set up to use these same IS's as triggers).  The problem came when I threw a turnout in the ladder independently of selecting a route (something I would not generally do).  In that case, the set of sensors did not pick up the change and update the display to the newly-selected track.   Perhaps separating trigger and display functions as you have done will remedy this?  It's not obvious to me why that would make a difference, but maybe I'm not using the sensors as the jmri folks intended...

[Chinapig]

Carl, I must admit that I get this problem as well.  I've never actually determined whether the turnouts always throw to the same position - it seems fairly random to me and  I can't check at the moment as I'm in the middle of a major layout upheaval.  I'll also look at OpSw6 and OpSw8 when I'm up and running again.  I've found the only way I can stop the problem is to power up the DS64s a second or two after the command station is powered up.  This always does the job but is a bit of a pain.
Ted

[Bangorboy]

  Now to drill a bit deeper, could I ask you how you activate the green sensor? 

Sure!  When I open the route table edit window for my route to trigger the mainline, the entries are:
Route User Name:  Staging Main Selected
Included Turnouts:  LT950 Closed, LT951 Closed, LT952 Thrown, LT954 Thrown, LT991 Thrown, LT997 Thrown, LT998 Thrown  (1)
Included Sensors:  {None}
Enter Sensor that Activates when Route Turnouts are correctly aligned (optional):  Btn_Set_Stg_Mainline, which is LS2048 in the Sensor Table  (2)
Enter Sensors that trigger this Route (optional):  Btn_Set_Stg_Mainline  On Active (3)
All remaining entries in this edit window are blank or left at default (some say Thrown, but no turnout is specified)

Notes:

(1)  These turnouts are numbered on the layout diagram I posted earlier.  I arbitrarily numbered my staging level turnouts downward from 999.

(2)  This is the Green Light labeled "Set Staging Mainline" and answers your question about how it gets turned on if the turnouts are aligned individually or by selecting the route.

(3)  Here is where you'd think I might get an endless loop going, if it were not already active and the route became aligned, it would go active.  You'd expect that to trigger the route again if it were not active already.  But I guess what happens is, it does that but the second iteration the sensor is already active so it doesn't change, therefore doesn't trigger the route and the cycle ends, so quickly it isn't noticeable when it happens.  Don't know why that didn't happen on all my routes, and some kept cycling.  Guess I'll do some more research into that, because the panel looked less cluttered without the red buttons.

I also want to play with Logix a bit.  Don't have anything in the Logix table yet, but maybe that would be a better way to go about it.

   Perhaps separating trigger and display functions as you have done will remedy this?  It's not obvious to me why that would make a difference, but maybe I'm not using the sensors as the jmri folks intended...

Don't know if that will fix it.  Seems it did mine, but some of them worked fine with the trigger sensor also being the display sensor.  Where I had the biggest problem was with the LT999 turnout which selects the two ramp tracks and LT 998 which controls the two turnouts for the crossover into the staging yard instead of going up the ramp.  The two LT998 turnouts would continuously cycle Thrown, Closed, Thrown...  A couple other routes occasionally hiccuped, but this one was almost always doing it when I tried to set it for the yard.  It would stop when the route to the ramps was selected.  I suspect it was programmer error.  What the nerds refer to as an I D 10 T error (ID10T at the keyboard).

Bill

[carlso]

Ted,

In response to your comment regarding a delayed power up of the DS-64's. we tried that by attaching a mini timer to the track buses and set it for 2 minutes. The command station powered up, then the timer powered up the DS-64's and guess what, we still had the problem. They do not all cycle at the same time but rather one at a time, You can hear the turnouts throwing and follow the sound around the layout.

You know, earlier in my first post I said that Digitrax told my compadre that they had duplicated the problem but were not sure what was causing it. Seems odd to me that the manufacturer of the item does something to cause the duplication but they don't know what.    We will trudge on and hopefully one of the above mentioned scenarios will stop it.

Carl

[carlso]

I just returned home from the layout in Las Cruces. We have 12 DS-64's and all are fully inhabited. To change the OpSw's is a rather easy thing to do, so we changed all 12 to set OpSw6 to closed and OpSw8 to closed. Powered down the layout from an hour to an hour and a half. When we powered up the layout we had no cycling turnouts. We will have to check it after 2-3 days of being off as that is when we have the cycling every time. We are optimistic !

Carl

[GaryHinshaw]

Included Sensors:  {None}
Enter Sensor that Activates when Route Turnouts are correctly aligned (optional):  Btn_Set_Stg_Mainline, which is LS2048 in the Sensor Table  (2)

Bingo!  The second line quoted above is the one I was missing, whereas I had populated the Included Sensors list with the sensors to activate/deactivate by hand (which you left blank).   I'll try that tonight and confirm, but it sure sounds like the missing link.

Carl - that sounds promising!  Things are looking up all around.   

[GaryHinshaw]

Ugh.  Now that I understood the sensor issue (thanks again Bill!) I was excited to push ahead with the final wiring of the yard throat, only to encounter a new issue.  I have two DS64's for the 8 turnouts in the throat and the first DS64 seems to be working fine, but the second one has a bizarre problem with outputs 3 and 4.  If I have nothing hooked up to the outputs and I use a DVM to read the voltage, I see it toggle between +/− 11 V as I toggle the input command (as expected).  But when I add a Tortoise to the output, the voltage on output 3 toggles between +/− 0.25 V, and on output 4 it toggles between +11 V and −0.25 V.  (Outputs 1 and 2 toggle between +/− 11 V even with a Tortoise hooked up.)  This problem is very robust to how I power the DS64, or what turnout addresses I have assigned to the outputs.

I know it's a long shot, but has anyone seen this kind of issue before?  I have sent Digitrax Tech Support a detailed description.