Does anybody know if there is a potential problem with DCC switch machines (e.g. Circuitron Smail or Cobalt IP Digital) when the system powers up, especially following a power interruption?
I am thinking of the case where there may be a train standing over a turnout when power is interrupted - when power is restored, would these machines under any circumstances try to move the points, and so cause problems? Some sort of default position, perhaps initiated by the controller so it knows what its starting state is?
It clearly shouldn't be an issue with direct-switched machines, like an old DC Tortoise or the equivalent Cobalt, and that is still one option for me. But the idea of using the DCC ones so I can set up routes has some appeal, and I'm now working through the pros and cons.
Any advice welcomed. Thanks.
Bob
Here in the UK I have a model railway I take to exhibitions.
I use a Gaugemaster Prodigy DCC system with Lenz stationary decoders powering Tortoise switch motors.
I use route setting on the DCC handset to align the Tortoise motors.
At two recent exhibitions the power to the hall failed abruptly - at power up, the switches "remembered" their alignment and did not move.
In normal use, each time the layout is powered up, the switch machines stay in the alignment they were in when the layout was powered down.
Trevor
Thanks Trevor. That is sort of what I expected should happen, as it seems logical and safe.
I have an ESU ECoS controller but no switch motors as yet (just on the verge of starting layout construction). So thinking through the possible issues before committing.
Where in UK are you? I am in South Cambs.
West Allotment in North Tyneside
The layout is Roundtrees Sidings
https://roundtreessidings.wordpress.com/
Home Layout
https://kaleyyard.wordpress.com/
I use NCE Switch-it and Switch8 boards for Tortoise/turnout control. Their default behavior is to STAY in the same position as they were when powered down, however they have an option to have them 'exercise' the turnout motor on power-up by changing the position and then moving back to the original position.
Modeling an HO gauge freelance version of the Union Pacific Oregon Short Line and the Utah Railway around 1957 in a world where Pirates from the Great Salt Lake founded Ogden, UT.
- Photo album of layout construction -
Thanks, OneWolf. That, plus the 'route' facility that most controllers have, suggests to me that whatever controller is being used, it must have the ability to read back the position of the switch motor so it can properly represent its position on whatever track diagram it shows. If I were to change the position of a switch manually by means of a push button wired to the Smail, for example, then doesn't that new position have to find its way back to the controller somehow?
Or maybe they don't bother? As I said, I haven't deployed any of these things yet, so just trying to get all the details straight in my head first.
That may happen with ESU systems. The only other one I know this happens with is Digitrax with Loconet. Assuming the stationary decoder is compatible with Loconet and not a standalone device like a Smail.
For example, the Digitrix DS64 stationary decoder works via commands sent from the DCC controller, PLUS it can have local pushbuttons connected. When using this with a Digitrax system, if you look on the throttle and check the turnout address and it shows closed, if you press the pushbutton connected to that DS64 to change the points and then look on the controller again, it will show thrown.
However, this matters a lot less than you might thing. It doesn;t really matter which way the controller thinks the points are, if you tell it to set the points the same way they already appear to be, it will still send a DCC command out. What's important, and most every DCC stationary decoder does this, is that the actual decoder remembers the last position so that at power up, all the point motors don't go nuts trying to change to random positions.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Thanks for all your input. I shall assume that this won't be a concern, and move on to whatever comes next!
rrinkerHowever, this matters a lot less than you might thing. It doesn;t really matter which way the controller thinks the points are, if you tell it to set the points the same way they already appear to be,
randy,
with your servo controller board, how do you determine the turnout position at start up?
greg - Philadelphia & Reading / Reading
LOL. I was going to add another sentence or two about my homemade controller, but since it's not DCC I changed my mind.
I write the position to the EEPROM on the mico after each state change, and read the EEPROM on power up to determine where it should be.
The only reason it would move on power up is if comeone manually turned the servo to the opposite side.
ANd no, I do not continuously write to the same location, I actually implemented a scheme to spread out the writes across the entire memory to maximizes the total number of writes within the datasheet specifications for write endurance. It's fairly low, like 10K writes is all the guarantee. My scheme needs 2 bytes, one for a counter and one for the two servo positions (top 4 bits are one server, bottom 4 are the other - so valid values are 0x00, 0x0F, 0xF0, or 0xFF). It writes 255 times to each location, then goes to the next (increments the address by 2) and writes 255 times there, and so on. When it reaches the end of the EEPROM, it's not 128K writes but no more than 255 per memory location, and loops around and repeats. In doing so, there is one more pointer to the current memory location, which has only gotten written about 500 times - this is the limiting factor, but by the time that location has 10K writes, there have been some 2.5 MILLION position saves. Assuming you move one or the other servo 100 times a day, every day, that's 70 years worth, minimum guaranteed by Atmel/Microchip. I won't be here when it fails, and some people have written tortouse tests on ATMega chips and gotten close to 10x the rated duration without any bit errors. Plus there's zero chance a given turnout will be changed 100 times a day, every single day of every week of every year. Even after I am retired there are other things I like to do besides run trains all day (shocking, I know).
I implemented a test mode in my original code with #IFDEF that did all the sequencing without actually writing, and it all imcremented as expected. I also marked the 328 that is currently sitting in the prototype board so that is my 'tester' which has also been reprogrammed many times - that one will not go on a production board that gets mounted on the layout.
It also only counts a completed movement - so if you press the button adn when the servo is halfway you realize you hit the wrong turnout and put it back to where it originally came from, it doesn't count as a movement. Only if it completes a cycle AND ends up opposite where it started from does it write to EEPROM.
I spent a bit of time overthinking this until I started running the numbers and realized that even abused, it will last more years than I realistically have left, and it someone is even still making 8 bit Atmel micros 50+ years from now, it would be a miracle. I'm just hoping they'll be around long enough for me to finish this all, so I don;t have to start all over on some other architecture.