Engines catching fire!!!

this may sound silly but are the wicks correct, and what is the smoke fluid. 

Yes that is all OK.

I doesn't have anything to do with that.

The smoke resistors glow cherry red and that is what is igniting the smoke fluid. After about 3 seconds the resistors are toast, but the fire keeps going as long as that fan is running.

I have to admit, it really looks neat, but it is not a good thing.

Hi Chuck,

The high pitch sound at the end of the sound file installation is quite common when working with "blank" boards from an upgrade kit.  The flame is definitely NOT normal or common.

You say you were converting an S-2 turbine and Alco PA.  Who is the manufacturer of these engines?  Are you re-using the stock smoke units or did you install new MTH PS2 smoke units?

I had a smoke resistor burn out on a smoking caboose in a short time.(TMCC on old smoking caboose, resistor burned into several pieces) But here were no flames but LOTTS of SMOKE!!! Don

Hi Dave,

The S2 was a PS1, the Alco, I was loading on my PS2 test rig.

sounds like the program allowed full voltage to the smoke element, instead of PWM.  Interesting this happen to 2 engines.  So the second one blew your PS-2 testor smoke unit?  G

Hello GGG,

Well I  unplugged it immediately, and did not plug it back in yet to test it.

I may have caught that one in time. I was across the room for the S2.

I've done a number of upgrades, and I have to say, I've never gotten flames!  Might be a neat effect, other than replacing the smoke resistors every 30 seconds.

Did you figure this one out?  Are you sure you don't have a short to the frame somewhere in the smoke unit wiring?

I've had the same happen..and quite often. Doing a factory reset is always a must and I've found that after resetting that if I let the engine sit for awhile with no power to it that will help. It's like the boards memory gets wacky and needs to settle down.

It is impressive with the fire shooting out the stack  

I'll have to keep that in mind for my next upgrades, they're sitting on the shelf here!  I don't want flames from the stack, impressive or not!

......albeit prototypical......

I've seen those videos Rick, but they don't have to take the locomotive apart after 30 seconds to replace something to continue!

Gee, my father could have avoided driving his 8-cylinder Studebaker to clean out the carbon.

OK Guys,

I am on vacation but when I get back later this week I am going to load the sound file into the SD45 conversion still lying on the work bench from when I left.

What was the resolution here?

Was it the sound file or was something else wrong?

I agree Rick. Nothing makes a better smoke and flame show than a TE-10. 

Someone should do an experiment; take some smoke fluid outside and try to get it to burn.   I was under the impression that it did not burn. (I have been wrong before) Don

I'm sure if you get it hot enough, it'll burn.

I think I have already proved that smoke fluid will indeed burn.

At least JT's Mega smoke.

Yes, but you omitted the photographic evidence!

Normally that fire ball is an electronic flash with some fine particles when the resistor shorts and about 24VDC is shorted out to ground.  Normally you will find the resistor fractured.  G

I'm surprised the electronics can put out enough voltage to fry the resistors, that seems pretty odd!

I agree and with two happening like that with all the hundreds we have done would make me thin k there is another answer. Lets see what MTH says....... if they ever respond.

Remember it has full positive voltage at the input coming from Track Voltage rectified to DC.  In this case via the 8 amp Rectifier.  So if the smoke FET which also can handle greater current is commanded open, you get the full boosted DC voltage of about 22-24VDC, and if the smoke element is touching ground or shorts, it will be quite impressive display of sparks.  G

That would assume the smoke unit was improperly grounded as I read this.  I've only installed half a dozen of these, but I've never taken any precautions with the smoke unit, and I've never had one burst into flames.  Are you saying you can command this behavior and cook the smoke unit?  If so, that's a pretty poor design!

AS you may recall G, when my 0-8-0 smoke unit found ground by itself, it blew out the board not the smoke unit. I hate to say this, but two instances within a short period at the same location kind of points to some kind of an error at that location. That being said, I also find it hard to believe as 'crummy' as a sound file may be, I cannot see how it could effect the resistors. Never mind for me though, it is simple enough to pull the 4 pin connector, load the file, do a factory reset, add the engine, re-plug and move on.

What really gets me on this whole issue is Jeff's lack of response to one of his repair centers. Years back when I was in the repair center business shoes, I gave him a pass for not faithfully replying, because everything was in 'start up' mode and he was a busy guy. You repair center guys deserve better support today. You have a tough job!

I have repaired smoke unit where owners said they had a single fire ball come out of the unit.  The smoke elements are found burned and fractured.  Normally wick is burned also.

I am not saying you can command this behavior, but if a file doesn't load right I assume it is possible.  I haven't had too much trouble loading sound files, but I had one that the motor took off at full speed (loading file with board tester) and one with weird speaker sounds.  So I assume anything is possible.

The board design is such that a "hot" power source is available to the accessory at all times and the FET controls the circuit completion to DC Ground.  So the Smoke element and motor and lights all have 20-24VDC sitting on one lead in the Command Mode (18-20VAC on the track).

Same for the 5VDC which powers smoke fan, tach, speaker and LEDs.  If the 5VDC is shorted to AC ground (chassis) you normally have an immediate catastrophic damage to the electronic components on the boards that are powered by the 5VDC.  The chips don't like AC and the high currents.

For the Positive Voltage ground, this is not always damaging to the boards. Motor FET don't seem to burn up when motor leads get grounded unless prolonged operation with the short.  I assume a heater FET can handle it also since it has a high rating, but again only for a short period.

Light FETs usually do burn up because of their low rating.  This at times can cause collateral damage on the board.

If you want to believe the smoke fluid exploded, then you still needed an extremely hot source to cause that.  Explosions from oils usually require a spray and atomization.  

If a smoke element isn't transferring heat because of damaged wick and full voltage is applied you have 1.5 amps going to each element (3 amps total).  24 volts divided by 16 ohms time 2.  3 amps time 24 volts is 72 watts in the smoke unit with limited to no heat transfer.  When they fracture I am pretty sure you will get a pretty good arc, plus some combustion of wick particles, and at that point some atomized mineral oil.  G

What you seem to be saying is the usual cause of this would be a short in the wiring.  However, I'm thinking about Hugh's method of loading without anything like smoke units and motors connected first and then do a reset and plug them in.

Can be wire or accessory itself. 

Yep, you only need 7 pin connector installed to load the file.  G

Of course, if there really is a short in the smoke unit, when you do connect it up, I can't see why it won't die at that point...

There was no short in the smoke unit. Remember the first one I was loading right into the engine on the tracks. The second one I was using the PS2 test fixture. When the squealing started I went to unplug it and I saw a red glow in the smoke unit indicating that the resistors were glowing cherry red. then the fluid ignited.

True, but I didn't say a short had to be the only issue.  My original point was if the FET is commanded open and stays in a conducting state, you are dropping 20-24VDC across a 8 ohms effective resistance.  I did misquote the early rating as each resistor is 16 ohms, so it is 1.5 amps max per element or 3 amps total.  Again with no heat transfer due to dry wick or burned wick, you are heating with 75 watts.  Then they can short or fracture.  At that point with a temporary drop of resistance amps will go way up an provide the arcing.  G

You know guys that there is a clear warning in the upgrade instructions that the (2) two resistors must be in parallel or the board can be damaged. We do not know what Chuck was working with. In this last upgrade, I had to rewire the resistors from series to parallel because it was a smoke unit I never saw before. The manual said the resistors should be 8 ohms, the ones in the unit I just worked on were 11 ohms. I paid little attention and left them there anyway. It is a good smoker! But it did bring up the subject for me of what ohms are tolerable and what is not. After reading the warning, I went to my parts bin and in there all mixed up together were about 20 resistors. I know that some were from Lionel and some were from KLINE and some had to be from MTH. None of them were 8 ohms????

I'm still trying to understand why occasionally the FET would be commanded to conduct continuously.  That clearly seems to be a major design flaw.

Hugh, 2 16 ohm resistors in parallel will read 8 ohms  Each gets the 1.5 amps for a total of three amps which is an equivalent 8 ohms in circuit analysis.  Same as working with speakers.  The FET can actually handle 2 smoke units in parallel which is the equivalent of 4 ohms.

John I think we were surmising that a software load problem (corrupt file)  could cause it.  Of course a FET that fails in a shorted manner behaves the same way.  Light FETs and the occasional smoke fan, motor FET have done this.  Bulbs will burn bright enough to melt plastic before the bulb burns out.  G

I understand if the FET fails that almost anything can happen.  I'm disappointed that MTH would have a design that lets a corrupt file do bad things!

Any firmware designer that's worth their pay that's ever done remote downloads has long ago learned that there should be a check mechanism to insure a good download image before passing control to the downloaded code.  That's firmware downloading 101!  I personally favor a 32 bit CRC for downloads, but I've worked with systems that used 16 bit CRC and even 16 bit LRC.  It's hard to believe they have no checking.

I've seen bulbs melt things, and when the Lionel smoke regulator board goes, you get some excitement at times as well.

John:

I have to agree with you on your displeasure of the design.

I personally will not design anything that leaves more voltage sitting on an input unless that item can flow the resulting current forever if shorted out.

I dislike low side switching for this reason. It leaves wires sitting around with voltage in them to short out.

You must have constant power on the Power input lines, everything else can be switched hi side and maintain a constant ground. (OK, my 4-20mA loops are lo side control for cost reasons, but I design in components that can withstand a short to ground forever.)

Yep, having the circuit hot all the time seems like a poor design decision to me, especially when it's not current limited!

I guess we have to keep reminding ourselves that these are toys.

Your not looking at things the right way esp. with the design of PS2..everything is being feed or "sees" full track voltage. PWM determines how long the "on" segment of the square sine wave lasts. Just because a download didn't take isn't the DCS loader fault as there's plenty to go wrong with the data stream from the time it leaves the MTH app. Has to travel thru the hardware on a PC thru a TIU and down the rails into the PS2 boards. 

Sorry, but I believe it's you that is looking at things the wrong way. 

A reasonable design would have the checking at the destination before the new program is written to the flash, so all that stuff you mentioned doesn't apply.  The loader is obviously already resident at the destination and loads the new operating code.  If I'm to believe what you say, they do no checking of the integrity of the transfer across all those noisy links! 

That would be REALLY bad design, and quite frankly, inexcusably poor design!  However, if you actually do what is reasonable, and industry standard for downloadable code since basically forever, the check data, be it CRC or checksum, is embedded in the data stream to be checked at the destination.  If it's not done that way, shame on MTH!

Before some other MTH defender leaps in to shield MTH's honor, I don't know that they don't check at the destination, I'm just responding to Chuck's reasoning of how it's done.  Truthfully, it's pretty hard for me to believe they didn't check the download at the destination.