H2-ECOM100 Error Light

[MarkTTU]

For the first time I'm making use of the ECIPSUP, ECWRMID, and ECWRNAM iBoxes. In the office and during testing in the office my code worked ok. Sometimes it took a while to get things set on the ECOMs, but eventually they would get set and life would go on smoothly.

I first ran into an issue when trying this out in our shop. I'd put new ECOM100s into my PLC (I'm using 3 in a 9 slot base) and when I powered up and the setup stage ran I'd occasionally wind up with an ECOM that had a red error light that wouldn't even respond to NetEdit. Through trial and error I found that if I let the ECOMs cool off a bit they seemed to work fine. Since it was ~120 in the shop that day I didn't worry about it too much as our customers never operate in those kinds of conditions.

Today one of our guys is setting up the first of these new products in the field. Its a 90 degree day and raining and he's running into the same problem so now I'm very concerned that the ECOM iBoxes may be doing something to corrupt my ECOMs.

I've attached the stage where I do ECOM setup. My program jumps to this stage and doesn't do anything until the stage is reset at the end.

Anyone have any advice?

[franji1]

First question - is it possible the PLC is being powered down?  There was a customer who was "setting up" the CPUs by powering them up, downloading the program, switching to RUN, then powering down.  The ECOM100s write this data to FLASH, and that takes time.  Each "write" IBox takes time, so they all have to finish.

It's possible to corrupt your ECOM when configuring them either through NetEdit or via IBox instructions if you power down the module/base in the middle of writing to it.

Looking at your logic, it looks like you are doing this with multiple ECOMs serially, which is okay - just make sure you are not powering down anytime during this sequence.

How often does Stage S1 get run - hopefully just once at power up?

[MarkTTU]

Its possible they were powered down, but they would have been powered for a while (a minute or two at least) before being powered down.

Once the red error light is on and the module doesn't show up in NetEdit anymore I found that after putting the module inside in the air conditioning for a few hours I could then "see" it with NetEdit and reload the firmware (it was v0).

S1 only runs at power up and no other stages are allowed to run until S1 is reset.

How long should S1 take at worst case?

[franji1]

How long should S1 take at worst case?

A long time if the FLASH has been written to Xthousands of times.  Flash gets slower and slower.  So if you write to it a million times, it will be REALLY SLOW (progress from seconds to minutes, etc.).  If you can close-loop it, as long as S1 is ON, do not power down.  Or, look at the ROM LED on the ECOM100 modules.

[MarkTTU]

In the case of what happened today in the field they were brand new ECOMs so the FLASH should have had very few writes to it.

ROM LED on the ECOM100? Which one is the ROM LED?

[franji1]

My bad - there's no ROM LED on the ECOM100s.

[MarkTTU]

No worries Mark.

I just changed my code to look like the attached and it sure is faster to get everything set... at least in my nice cool office. Is what I'm doing here any better or worse than what I was doing before?

[franji1]

The earlier version was clearer (less dependency on T0 in first version).  The 2nd file you posted has lots of documentation - you may want to remove it from that post.

[MarkTTU]

In the earlier version if one of the ECOMs didn't have success then they'd all have to be triggered again; I'm wondering if writing to the FLASH over and over again in a 1 second interval was overflowing a buffer or leading to excessive heat (I keep coming back to heat, but its all I've got). In the new version once a setting is written successfully I stop trying to write that setting and everything doesn't have to succeed in 1 second or risk being done again... at least that was my thinking behind the new version... think I'm running down the wrong path?

Thanks for the note about the file, I've edited it and replaced with one that only has the pertinent documentation.

[Controls Guy]

A long time if the FLASH has been written to Xthousands of times.  Flash gets slower and slower.  So if you write to it a million times, it will be REALLY SLOW (progress from seconds to minutes, etc.).  If you can close-loop it, as long as S1 is ON, do not power down.  Or, look at the ROM LED on the ECOM100 modules.

That's good to know in a case like this where the intent is to write on every Program-run transition / power up.  Is there a way to read the same registers and not write if they're already at the desired values?

[Greg]

We suspect it is not being caused by the PLC instructions. To test this, is it possible to disable running the EC* IBoxes and power up and see if the red light still comes on, on the "hot" units?

[BobO]

...and we would really love to hear a specific description of the lights while the units are coming up/failing. The sequence of LEDs can tell us a great deal about what might be happening.

[MarkTTU]

My guy on the ground has already moved on to the next customer location (they won't actually be running for a few more weeks), but he will be back either later today or later this week. I'll get him to shoot a video using his phone of the ECOM lights as the PLC powers up. I'll also have him power up the ECOMs without S1 enabled.

He did try two new ECOMs he had with him and each of them wound up with their ERROR lights on and unresponsive after being powered up with the first program I attached.

He's also tried moving an ECOM that has an error light to a different PLC and the error light stayed on and it was still unresponsive to NetEdit. Taking an ECOM from this other PLC and putting it in the one that's been causing problems caused the "good" ECOM to stop responding to NetEdit and have its error light come on.

[BobO]

Hmmm...maybe that does sound like code after all...

The other info we haven't mentioned is that we are chasing a strange Ethernet power up issue on a 275, where it gets hung on power up when it is warm...never happens cold. We think it is related to the PHY chip, which happens to be the same one on the ECOM100. There was enough similarity that we were considering a possible common problem. We do not really think this is systemic, as we only see it on a single 275 CPU, so it may just be a bad PHY chip...but we have learned to be sensitive to failure reports since they have a habit of cropping up at 3 or 4 places at the same time.

[MarkTTU]

Oh how I know that one... I had a software bug crop up in a core function of one of my products that had been on the market for 5-6 years before it reared its ugly head. Then of course it reared its head at several places within a few days of each other. We threw parts at the problem for a while before finding the bug in the code. How it had never been an issue before baffled us all.

At any rate, my guy is back and has shot two videos of the ECOMs at power up. One has the CPU in the base so my S1 code is being executed. For the other he just pulled the CPU out and powered it up with no CPU so S1 shouldn't have run that time