Serious control problem with Atlas Gold Series S2s - help needed

[mark dance]

BTW, my three are also in CP, so, solely as a charitable act to help out a fellow Vancouver modeller, I could bring them to the op session . . .

David

Dave, that is a very kind offer.

md

[davefoxx]

THat is an excellent advice.  If that was the case, it would explain why Atlas didn't find any problems.  Just in case something is still missed during troubleshooting I would temporarily set the misbehaving loco's address to an address you would  have unlikely used in the past (probably something like 1313, 9999, or some other address you don't ever recall using) and see how the loco behaves under that address.

How about trying to run this locomotive on another layout?  This could confirm the behavior under the power of another command station, and might show what Atlas saw during warranty repair service.

DFF

[jdcolombo]

great ideas everyone.  I have to work the balance of the day but will try them this weekend.

By the way John, the digitrax "memory purge" is setting the command station op switch #39 to "closed", correct? 

I believe this wipes out all consisting as well doesn't it?  But it doesn't effect things like stationary controller addresses or fast clock settings does it?  Just want to know what I am getting into...

md

Don't set #39.  That clears EVERYTHING, including routes, and essentially sets the command station to factory default.  I might do this as a very last resort, but not at first.  Use Op Switch #36, which just clears the slots and mobile decoder info.  Yes, you will lose the consists when you do this and will need to re-consist everything that was done using Digitrax Universal Consisting.

http://www.digitrax.com/tsd/KB595/command-station-option-switches-clear-slots-and-fa/

Peteski's suggestion to set the decoder address to something you've never used before is a good one, too. 

John C.

[mark dance]

Don't set #39.  That clears EVERYTHING, including routes, and essentially sets the command station to factory default.  I might do this as a very last resort, but not at first.  Use Op Switch #36, which just clears the slots and mobile decoder info.  Yes, you will lose the consists when you do this and will need to re-consist everything that was done using Digitrax Universal Consisting.

http://www.digitrax.com/tsd/KB595/command-station-option-switches-clear-slots-and-fa/

Peteski's suggestion to set the decoder address to something you've never used before is a good one, too. 

John C.

glad I asked!

md

[GaryHinshaw]

Yes, clearing the mobile decoder info is a good idea.  [I thought you did that fairly routinely...]

I recommend doing this via jmri.  First you can see which slots (addresses) are in use using Loconet/Monitor Slots from the menu.  You can then close opsw #36 using the Loconet/Configure Command Station menu item.  If you keep the slot monitor window open when you do, you'll see a real time confirmation that slots are being cleared.

[mark dance]

For completeness...I just got a call from Atlas Service following up. 

They did change out the ESU board (which might explain why the performance changed...even though it got worse).  I told him I got lots of great suggestions from this forum for me to follow up with over the weekend and I would let him know Monday how it all turned out.

md

[Chris333]

I don't know about the DCC stuff, but when I took my S2 apart to paint one truck would roll forever and the other one wouldn't roll at all. I took that truck apart and found a booger on one of the gears and picked it off with a knife. Both trucks roll forever now.

[Atlas Paul]

What a drag.  I assume, from your comment, that swapping decoders between a well-functioning and poorly-functioning unit is difficult?  Were all 4 units programmed the same way, to your knowledge?  If so, CV settings are probably not an issue.

My theory is that there is a cracked trace on the ESU board that opens when it gets warm (e.g. when current flows), then closes back up again when current stops [and repeats].

Paul Graf (Atlas Paul) does participate here.  You could send him a PM.

-gfh

As soon as I saw this posted I contacted our Repair Department, and as you can see further down this thread, Don contacted him.

[mark dance]

As soon as I saw this posted I contacted our Repair Department, and as you can see further down this thread, Don contacted him.

Thank you Paul

md [him]

[peteski]

How about trying to run this locomotive on another layout?  This could confirm the behavior under the power of another command station, and might show what Atlas saw during warranty repair service.

DFF

That is a valid option.

[signalmaintainer]

@mark dance: Sorry to hear that, Mark. Perhaps Atlas just needs to replace them and send the offending units back to ESU for further diagnosis. Yes, tough on the short-term P&L statement, but happy customers keep small companies such as Atlas in the black.

@John C.: That is the most detailed explanation of setting up the BEMF functions for the S-2 I've encountered. Now, while my S-2 runs great (after fiddling with the CVs you mention using my LokProgrammer), wish I'd read this beforehand. As it is, I'm copying your text into a Word document and putting it into my ESU folder.

[mark dance]

I did a fast test by following a suggestion on here to reprogram the loco road number to a number I have never used before... and the oscillating speed went away!  So the problem is *definitely* on my side somehow associated with the commands that are being sent to that road number.   

The additional auto-calibrate wasn't too bad as a first pass tweak of the PID variables but the result isn't good enough to match my old LifeLike SW1200s' performance.  Thank you John for the details on how to manually tweak. that is my next step ...after clearing all the addresses and rebuilding 20+ consists!

Thanks everyone for all the help! (and Paul I have already emailed Don to thank him for his help)

md

[tom mann]

Thanks @Atlas Paul !

[jdcolombo]

I did a fast test by following a suggestion on here to reprogram the loco road number to a number I have never used before... and the oscillating speed went away!  So the problem is *definitely* on my side somehow associated with the commands that are being sent to that road number.   

The additional auto-calibrate wasn't too bad as a first pass tweak of the PID variables but the result isn't good enough to match my old LifeLike SW1200s' performance.  Thank you John for the details on how to manually tweak. that is my next step ...after clearing all the addresses and rebuilding 20+ consists!

Thanks everyone for all the help! (and Paul I have already emailed Don to thank him for his help)

md

Excellent! (Well, excellent that you've isolated the problem; there's still a long road ahead).

John C.

[peteski]

I did a fast test by following a suggestion on here to reprogram the loco road number to a number I have never used before... and the oscillating speed went away!  So the problem is *definitely* on my side somehow associated with the commands that are being sent to that road number.   

Good to know that the troubleshooting is making progress.
That also explains why Atlas didn't find anything wrong with them. If they replaced the (fairly pricey) sound decoder, that was mighty nice of them.