Reply
Highlighted
Super Contributor

Re: Flash files

[ Edited ]

I wish there was a better course of education on the controls in general, I have been fortunate over the years to be in a position to work on the leadng edge of technology, mostly applying engines in strict emissions areas long before it common in other areas, forced a better level of understanding. I have also worked a number of years as a contractor to CAT in commissioning of large gas and diesel engine powered systems, and got the opportunity a few times to be part of field programming efforts.

 

Unfortunately regulatory agencies force CAT and other manufacturer's to severly limit access to the core perfomamce programming of modern engines, mostly in the name of limiting engine emissions output. So even if you bought the right hardware and software to get onto the primary data links, unless you have the right access you can't read it.

 

About all anyone can do these days is to learn to use the service tool, and to be able to go beyond what the laptop tells you.  In most cases electronic engines have wiring and connections problems the most, then sensor issues, then programmiing problems. You have to apply a good amount of common sense to the trooubleshooting process, if it is a new unit with low hours and the wiring and connections are in excellent condition, do you really need to peel the wiring apart?

 

In my own experience I have found that the ability to use the ET tool to it's fullest extent, including the datalogging (which frankly I think the CAT training does a piss poor job of), and then to use other diagnostic tools in conjuction with the PC based service tool. I have found a rugged o-scope (I use Fluke Scopemeter products) to be invaluable, as well as a top quality DMM with logging/recording features, neither are much talked about in CAT service training classes or manuals, I think there is still a resistance to seeing a need to fully address signals as they actually exist in the engines and generators. Another area is how CAT (and other manufacturers) have you troubleshoot engine sensors, frankly a bit of basic instrumentation training goes a long way in helping understanding linearity and hysterisis, engine sensors are the "eyes and ears" of the engine control, but the testing and calibration procedures are usually single point go no-go type propositions. Maybe its more important to sell parts than to actually solve problems.

 

Another area I think is essential is the ability to read the available schematics, and the ability to follow them and understand common circuits, such as power supplies and commons, and how they affect overall operation. I hate CAT schematics, too much info crammed into a single large page too large to deal with in the field most times, I was much happier when engine control prints were 11X17, and could be printed and copied fairly easily, especially if you needed to trace or markup as needed.

 

Just my opinions, hope it helps, Mike L.

Contributor

Re: Flash files

The stability issue with the c-15; the only indication of the issue was found in the data log/ recorder. There was a correlation issue between FRC/ rated fuel limit & fuel position. Ended up being the flash file..... As always thanks for the information mike. Is there anyway I can educate myself on these electronics. You know like the programming language Etc... I hate bothering you with these remedial questions?????
Super Contributor

Re: Flash files

In general, hardware type problems, including power supply issues, wiring and connector problems, and hardware problems like sensors or controllers failing tend to start out erratic or intermittiant and get worse as time goes on.

 

Flash file type problems can be a bit harder to figure out, but usually are an unexpected response to a event or parameter change that is repeatable and consistant. A simple example from a few years ago, an engine would shutdown on High Jacket Water Temperature, the setpoint, parameter reading and actual temperature all appeared correct. The flash file had a scaling error in the protection routine. I have also seen flash files errors cause instability, recently I had an older electronic engine that had a snychronizing problem, in short, found the response to a change in desired speed always seemed to lag, even with changes in what governing settings I could make, the response for a change in desired speed always seemed the same. Even though not listed as a "fix" in the flash file index, found a later flash file, installed it and problem appears to have been resolved.

 

From my own experience the best tool for trying to figure out what is going on is a well setup and evaluated datalog. I am amazed at how many experienced technicians I deal with that don't have a good grasp on how to setup, apply and read a datalog in ET. Yet as a troubleshooting tool is VERY valuable. Also knowing how to apply a good quality DMM, I still run across a number of problems associated with bad power supplies, including issues with chargers, alternators and batteries. If you are trying to figure out a "strange" problem, using not only the DC scale but the AC scale as well can provide valuable insight. If you really want to move ahead get a good quality field o-scope, like a Fluke Scopemeter with the associated software, and learn how to use it, it is especially useful in figuring out sensor and power supply issues, as well as external control issues.

 

Hope that helps, Mike L.

Contributor
Accepted Solution

Flash files

I've been seeing a lot of software issues, including but not limited to the EMCP3 controllers and c15 engine ECMs. I understand there are firmware updated &amp; one can look for service letters regarding there issues if suspect. However it is ever difficult to distinguish between software and hardware issues.<br><br>My question- what are some key indication of coding errors/bugs?<br>What are some bigger known issues to keep an eye out for?