FVM GP60M Plug and Play - or not

[peteski]

Philip - did you ever resolve this problem?  If yes, I'm sure that all of us who contributed to this thread would want to find out what the solution was.

[Philip H]

No resolution yet. I've been on the road for both work and helping my folks successfully through some medical issues. I'm home tonight and tomorrow night to reload the suitcase, so it may be a while til I get back at it.

[peteski]

Thanks for replying, and I'm sorry to hear about your problems.

[Philip H]

With the discussion here (https://www.therailwire.net/forum/index.php?topic=32343.0) I pulled out the Kapton tape and went to town following Mike Fifer's suggestions.  I now have a loco that doesn't show a short on the decoder, and will accept both loco numbering and operations commands - e.g. I can take it off the programming track and run it back and forth under proper control on the layout by its assigned cab number.  Interestingly, I've lost the headlights . . .  . . . which now no longer illuminate at all.  Frankly, just to see the thing run is enough since its a beautiful model.

[peteski]

So, what is the diagnosis?  Was there a short between the uninsulated chassis and components on the decoder?  Was the original problem (where motor was activated by turning on the headlights) caused by the decoder installed upside down?  Inquiry mind wants to know. 

With the current headlight problem, if you reinstall the dummy decoder plug, do the headlights work ok?

If yes, then the problem is with the decoder. It can be hardware-related (blown headlight function outputs) or possibly software-based (some CV setting which reprogrammed the headlight functionality).

Another clue might be to (in a darkened room) remove and apply power to the decoder (by tilting one side of the loco off the track and putting it back on the track).  When the power to the decoder is initially applied, most Digitrax decoders will produce a very short and dim pulse to the headlights.  If you see that flash then there is a good chance that the decoder hardware is ok (the problem is most likely with the CV programming).

Welcome to the wonderful world of DCC. This is what happens when we start installing programmable computers (that is what a DCC decoder is) in our tiny toys. 

[Philip H]

Another clue might be to (in a darkened room) remove and apply power to the decoder (by tilting one side of the loco off the track and putting it back on the track).  When the power to the decoder is initially applied, most Digitrax decoders will produce a very short and dim pulse to the headlights.  If you see that flash then there is a good chance that the decoder hardware is ok (the problem is most likely with the CV programming).

I saw similar behavior when I put the loco on the layout after programming.  SO I concur from my seriously limited experience that its a CV issue. 

As to a diagnosis - I have yet to visually see anything that would have created a short between the loco frame halves or the motor or anything else. But adding the next round of Kapton - and replacing some I did earlier but applied poorly seems to have cleared it up.

[peteski]

I saw similar behavior when I put the loco on the layout after programming.  SO I concur from my seriously limited experience that its a CV issue. 

As to a diagnosis - I have yet to visually see anything that would have created a short between the loco frame halves or the motor or anything else. But adding the next round of Kapton - and replacing some I did earlier but applied poorly seems to have cleared it up.

So, you are able to see the headlights flash (even if they do not work in the conventional sense).  That does seem to indicate a programming (CV) problem. Try resetting the decoder (on programming track, write a value of 8 to CV08 http://www.digitrax.com/tsd/KB675/resetting-a-mobile-decoder-to-factory-settings/ ) . That should fix the problem.

The lights flash in the programming track during programming (align with the motor "twitching") because the decoder needs to create an electrical load to acknowledge the programming commands.  So yes, that is also a good way to check the decoders hardware functionality.

As far as the other question goes, I guess that since the problem went away when you made sure that the chassis was properly isolated from the decoder (by applying more caption tape), the logic would dictate that a short between exposed decoder circuitry and the chassis was causing the strange behavior.