Skip to main content

I bought a set 30-4227-1 on Jan 5th 2015 (2-8-0 Steam Passenger R-T-R Train Set w/Proto-Sound 3.0) and got the annoying smoke issue described in the post https://ogrforum.com/t...-for-ps3-rtr-engines.

 

As expected (Great!), the issue got resolved by doing the recommended “Chain File” update (Flash Code r141_f_280_3244_code.zip) using a Rev-L TIU (V4.3) and the DCS Consumer Loader V2.34.

 

While doing the update, I noticed many messages saying something like “…re-trying at a slower rate…”, but it did complete normally. 

 

As I was using a short cable (2 ft) between the TIU and the Programming Track, I decided to re-do the same “Chain File” update a second time using a 15ft cable.  That time, the update completed a lot faster, and without any “…re-trying at a slower rate…” message. (Great!)

 

As I wanted to be absolutely sure that the 2ft cable was the source of the slower update and the “…re-trying at a slower rate…” messages, I decided to try the same update a 3rd time by re-using the previous 2ft cable…

…Bingo ! The “…re-trying at a slower rate…” messages were back, proving that the 2ft cable was causing the slower update.

 

Now, the best is coming…  While I was getting the slow update experience, I did not wait for the update to complete and stopped it by hitting the nice “Cancel” button on the DCS Loader V2.34… 

 

…Since that event, the Engine appears to be “Dead”. 

 

The TIU does not see the Engine anymore, nor the DCS Loader.  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.

 

Can anybody help me with a procedure to get back the Engine alive ?  Thanks !

 

Daniel

 

Last edited by Daniel Auger
Original Post

Replies sorted oldest to newest

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

 

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. 

 

 

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.

Last edited by Barry Broskowitz

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!

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

 

 

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.  

Last edited by Barry Broskowitz

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.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

Attachments

Images (2)
  • Critical Error using Windows XP
  • Critical Error using Windows 7
Last edited by Daniel Auger

Add Reply

Post
The DCS Forum is sponsored by

OGR Publishing, Inc., 1310 Eastside Centre Ct, Ste 6, Mountain Home, AR 72653
800-980-OGRR (6477)
www.ogaugerr.com

×
×
×
×
Link copied to your clipboard.
×
×