"Dead" PS3 engine after interrupting a "Flash Code" update… Help !

The longer cable is a know issue so you could have asked vice experimenting....

 

As far as why you can't reload I am not sure.  I have aborted PS-2 loads, and you can go back in and reload.

 

I can see the engine being "dead" operations with an aborted flash code, but I am not sure why the board can't be seen and the flash code reloaded.  I would go back and check your set up with the longer cable.  G

 

Thanks for the reply GGG.

 

I did retry with the longer cable, but I am getting the attached critical error.

 

Daniel

 

Delete this engine from the remote.  Without loader program can the engine be found in DCS when you try and add?  If not try a recover engine?  If either is successful, go back and using the loader program try again.  I would just make sure you have all the wiring hooked up correctly.  G

I think I read in a MTH service update a while ago, that if the program was lost or interrupted while loading a PS3 of flash file it would have to go back to MTH for them to correct. Might give MTH a call today to see if that is correct if you have no luck recovering your engine. MTH # is 410-381-2580.

 

Nor the "Recover Engine" nor the "Add MTH Engine" are giving any results. ("No Engine to Add"  / "No Engine Recovered") 

 

I am 99% sure about the wiring to the Programming Track.

 

If possible, could anybody share the mentioned "MTH service update" talking about "... interrupted while loading a PS3..." (ref: previous message from Chuck Sartor)

 

Thanks

 

 

 

I called MTH support and here is what they told me:

 

"On PS3, if the Flash Update interruption occurs at some steps, the Engine would get stuck and not be resetable by normal means, nor be re-programmable via the track (TIU).

 

In these cases, special equipment only available at MTH would need to be used to directly re-program the PS3 board.

 

Conclusion 1:  Avoid clicking the "Cancel" button during a PS3 Flash Update...

 

Conclusion 2:  The MTH Loader should have a "Clean" way to terminate the PS3 Flash Update when the "Cancel" button is used.  Using this button should not react like removing the Engine from the track or cutting the power. 

 

 

Welcome to you new member from Quebec canada.ON est plusieurs du Québec sur le site.Norm!! 

The longer cable is a know issue so you could have asked vice experimenting..

 

Educate me please, GGG.  What is the known issue?

I have no dog in this fight, but I have to ask: Why do they have a cancel button if you cannot use it?
Every PC I've worked on (lots) have warnings not to interrupt a flash bios upgrade.

Robert,

 

The "known issue" is that MTH recommends that a longer cable be used with a Rev. L TIU when transferring chain files.

Barry,

 

Why is the loader telling Daniel to make sure the engine address NOT set to 0 when you have been told there is no address zero?

Barry, I don't recall seeing any such notice to the public.  How long should the cable be?  What about Revs G, H, & I?

Joe,

Why is the loader telling Daniel to make sure the engine address NOT set to 0 when you have been told there is no address zero?

Where is that reference in this thread? I just read back thought the thread and can't seem to find it.

 

Regardless, I've found that, rather than attempt to explain the actual way that DCS engine ID#'s really work, the preference often is to use a simpler, dumbed-down nomenclature. That nomenclature postulates the existence of a DCS ID# of zero.

 

While I'm certain that zero can be a value in the engine's DCS ID# field, it's not a value that any process puts there deliberately.

 

Further, I can assure you that the concept of a DCS engine with a zero address is not the address with which an engine comes from the factory.

Chuck,

I think I read in a MTH service update a while ago, that if the program was lost or interrupted while loading a PS3 of flash file it would have to go back to MTH for them to correct.

You might be remembering the following from page 213 of The DCS O Gauge Companion 2nd Edition: (I also posted something similar to this on  the forum several years ago)

Appendix I: Avoiding a Problem When Upgrading PS3 Engine Sound Files

When DCS 4.20 and Loader Program 2.20 became available, it became possible to damage the electronics in a PS3 engine (HO or O gauge) when using a Loader Program earlier than version 2.20 to upgrade the engine's sound file.

 

The following information is intended to provide a better understanding of why this is so, what exactly is the damage to the PS3 engine, how to avoid damaging the PS3 engine, and what to do if damage does result.

 

Why Damage May Result

The new Loader Program 2.20 is the first Loader Program developed that is aware that PS3 engines exist, and that their on-board memory format is very different from that of a PS2 engine's. This allows the Loader Program 2.20 to effectively update the sound file in a PS3 engine where previous Loader Programs are unable to do so. If a Loader Program version earlier than 2.20 attempts to update the sound file in a PS3 engine, the wrong memory locations will be overwritten causing the PS3 engine to become non-functional.

 

What Exactly is Damaged

The PS3 engine's electronics are not permanently damaged. Rather, the engine's firmware code is overwritten and the engine's processor no longer has an operational program to follow. Therefore, the board's processor shuts down and the engine is no longer functional. Unfortunately, the correction of this problem is beyond the ability of the DCS operator to effect, since doing so requires the use of factory-type procedures that are currently available only to MTH.

 

How Damage May be Avoided

When upgrading the sound file in a PS3 engine, a successful outcome is expected if, and only if, the Loader Program 2.20 is being used to do the sound file update and the TIU being utilized for the sound file update is running DCS 4.20. It is important to note the following: 

• Any combination of Loader Program, TIU hardware model and DCS version may be used to update the sound file in any PS2 engine 

• Any TIU model may be used in the sound file update process for PS3 engines 

• If Loader Program 2.20 is used with a DCS version other than DCS 4.20 in an attempt to update the sound file in a PS3 engine, the sound file update will fail with an error message. However, the PS3 engine will be unaffected 

• It is only if a Loader Program earlier than version 2.20 is used with any release of DCS to attempt to update the sound file in a PS3 engine that the PS3 engine will be rendered inoperable • The only way to update the sound file in a PS3 engine effectively is to use Loader Program 2.20 and any model TIU with DCS 4.20 installed.

 

What to Do if Damage Does Result

If a failed sound file update attempt of a PS3 engine causes the engine to become inoperable, the only recourse is to contact MTH, obtain an RMA (return merchandise authorization) number and send the engine to MTH for reprogramming of the engine's PS3 board. At present, neither DCS operators nor MTH Authorized Service Centers have the factory-type capability to effect the required repair.

 

Why it's Not Possible to Completely Avoid the Problem

The architecture of the DCS TIU does not permit the TIU to initiate communication with the Loader Program. All it is able to do is respond to queries from the Loader Program. Therefore, it's impossible for the TIU to learn the version number of the Loader Program, and advise the Loader Program to halt the sound file update operation if the Loader program is a version earlier than 2.20.

 

Further, since Loader Programs previous to version 2.20 were completely unaware of the differences in the memory structure of PS3 engines as compared to PS2 engines, they have no way to avoid the problem.

 

This and a whole lot more is all in MTH’s “The DCS O Gauge Companion 2nd Edition", available for purchase as an eBook or a printed book at MTH's web store!

Robert,

I don't recall seeing any such notice to the public. 

That's because there wasn't one.

 How long should the cable be?

On the order of 25 feet.

  What about Revs G, H, & I?

It's not necessary.

25 feet is a loooong cable.  Was any technical reason given?  Can there be any untoward result other than a slow load?

 

I won't comment on MTH's failure to make this idiosyncrasy known.

 

I think I'll stick with my Rev G's & Rev H.  If there's any issue, it will have been noted on this forum over the last 12 years

 

 

Barry,

 

It was in the third box down from the top in the photo attachment made by Daniel in response to GGG. Click on the photo for the critical error report from the loader.

Barry,

 I thought the memo came from MTH, but it could have come from you also.

Robert,

 

The Rev. L listens better than previous TIUs because it has an FPGA DSP. The same is true of PS3 engines vs. PS2 engines.

 

The 25' of cable is to simulate a layout's tracks and minimize the possibilty of the TIU and the engine talking too loudly to each other.

 

I've only recently put a Rev. L on the test track and haven't loaded any chain files with it as of yet, so I cannot comment as regards a longer cable makes any difference for my setup.

I think I'll stick with my Rev G's & Rev H.  If there's any issue, it will have been noted on this forum over the last 12 years

The Rev. G, even when upgraded by MTH as yours was, still lacks fuses and has all of the Commons tied together. Both the Rev. G and Rev. H are far inferior to the Rev. L as regards signal strength, and the number of blocks and number of feet of track that each channel can support.

Joe,

It was in the third box down from the top in the photo attachment made by Daniel in response to GGG. Click on the photo for the critical error report from the loader.

OK, got it!

 

That message is reminiscent of some dumb messages that I put in programs that I wrote back in the day. Like mine, that message is meaningless to everyone except the programmer.  

Chuck, I think you are right and if not in a service note it was addressed at PS-3 training.

 

It has to do with impedance matching according to MTH.  For what ever reason it increases the speed of the load.  Nothing more.

 

Joe, I have seen that message before also.  I just reattempt and it takes.  G

What version of Windows are you using in your pc?

Barry, I consider the 20-amp internal fuses to be a useless accouterment.  In fact, it's worse than useless because it is misleading users into believing it can save their TIUs from overload.  I have not heard anyone allege that a TIU circuit can continuously carry 20 amps without damage.  In fact, given the blow time of fuses, the TIU could be subject to greater amperage.  I also am not aware of any UL approved model train transformers that can provide 20 amps without breakers opening.  In my opinion, since it has customers who aren't aware of the benefits of external fuses, MTH should have used smaller ampacity fuses and made provision for easy replacement without opening the case.  Externally accessible fuse holders are available. 

 

As to having grounds connected internally, what;s wrong with that?  They are connected at the transformer, or properly phased transformers, and again on the layout.

 

There does appear to be considerable evidence that the Rev L gives a better signal, and I do not question that.  But if I can get 9s & 10s all over the layout, what would I gain?

 

I think my biggest problem, which a Rev L won't cure, is that the grandkids like to duck under the table and come up through access hols in the middle, to run trains from there.  I'm not going to stop them because I want them to enjoy the layout (some of the older ones already don't say "Let's run trains" when they stop by).  But when they go under, they break wires.  If it's a hot wire, I know because something won't work.  If it's a common, I don't always know when and where, but it can affect and has affected DCS signal.

 

As to Daniel's issue at the head of the post, MTH could have included wire length guidance in the on-screen instructions in the program.  I will not criticize MTH for not doing so, because this is 20-20 hindsight on my part.

 

Hi everyone and thanks for your help/support on my problem… which, btw, is still not resolved.

 

I thought that re-summarizing the situation, while answering some questions would be appropriate at this point.  So, here it is:

 

Engine:  30-4227-1 (2-8-0 Steam Passenger R-T-R Train Set w/Proto-Sound 3.0

TIU: Rev-L (V4.3)

DCS Consumer Loader V2.34

PC(s):  Windows XP (32bits) and Windows 7 (64bits) ==> Yes, I tried it with 2 different PCs, and I am getting the same results – see attached error messages.  So, nothing to suspect on that side.

 

Events: 

 

1-      The annoying smoke issue described in the post https://ogrforum.ogaugerr.com/t...-for-ps3-rtr-engines was resolved by doing a FIRST Flash Update “r141_f_280_3244_code.zip” using a 2ft cable between the TIU and the programming track.  The update was slow but it did complete while giving messages like “…re-trying at a slower rate…”.

 

2-      I did a SECOND Flash Update (same file) using a 15ft cable between the TIU and the programming track.  This time the flash update went a lot faster, without any messages

 

3-      I did a THIRD Flash Update (same file) with the 2ft cable to re-confirm the effect of the cable length, and when I did confirm that it was doing the slow update again and the “…re-trying at a slower rate…” messages, I interrupted the Flash Update in the middle of its process by hitting the “Cancel” button on the DCS Loader V2.34… …Since that event, the Engine appears to be “Dead”. 

 

“Dead” means: 

 

Engine does not make any sound, does not move, nothing.  I also check to see that the potentiometers are not at zero.

 

The TIU does not see the Engine anymore; Nor the "Recover Engine" nor the "Add MTH Engine" are giving any results. ("No Engine to Add"  / "No Engine Recovered").  Factory Reset executed from the TIU does not do anything.

 

The “Factory Reset” procedure using the basic “DCS Remote Commander” (SND+DIR+”-" does not do anything).  

 

Applying Z-500 direct power to the tracks does not do anything neither.

 

The DCS Loader does not see that Engine and is giving the “critical errors” attached.

 

On a call with MTH support (technical), I got told:

 

"On PS3, if the Flash Update interruption occurs at some steps, the Engine would get stuck and not be resetable by normal means, nor be re-programmable via the track (TIU).

In these cases, special equipment only available at MTH would need to be used to directly re-program the PS3 board."

 

At that point, I really and strongly suspect that the "Cancel" button did the "firmware damage" which unfortunately only appears to be curable using a special MTH factory loader.

 

If the "Cancel" button really caused the problem (and I have all reasons to believe that it is the case), I would add something about it in the section "How Damage May be Avoided" of Barry's reply above.

 

I will let you know how this story ends when it does, but meanwhile, all help or experience/solution on similar problems is of course welcome !

 

Note: All this to resolve a "smoke" issue at start !

 

Thanks,

Daniel