GE EGD Comm Problems

K

Thread Starter

Keith Muchnick

We are operating a GE LM6000PC with a 90/70 sequencer, MarkVI FC w/ a genious network and BOP consists of 90/30s and Genious. It transfers data with CEMS and the SCR through EGD.

Over the past few days my boss informed me that every time a start is initiated, our CEMS setpoints reverted back to the default setpoints and our SCR controller started acting erratically. After trying anything he could to fix the problem with no success he re-booted the Hirshmann switches. This seemed to correct the problem. These systems trade info via EGD. It seems everything that went beserk was due to a EGD problem.

Back 2-3 years ago we had a Control Engineer here that said we have excessive "packets crashing" and over time it will become an issue. He said that we needed approx. $100,000 to upgrade the system and make it reliable. Unfortunatly I pitched this to my superiors and they did not entertain it whatsoever. It seems to me this might be what is going on now. Does anyone know of an easy way to check this and confirm whether this is what is happeneing or it is something else?

Keith

P.S. Please forgive me in advance for my lack of knowledge in this field. The only time I get to learn is when something breaks and fortunately it does not happen to often.
 
An upgrade to new switches (Cisco) is probably in order.

Many tools are available to troubleshoot ethernet network. They will graph the collisions, ethernet frame errors, etc.

If you do not feel confortable with using these network tools, bring in a IT consultant. If you have an IT department in your organization, they can generally evaluate your network and find the weak links.
 
Your Control Engineer might be correct--but is it a GE EGD problem or a problem with the programming of all the devices on the network?

A high amount of EGD traffic could be indicative of a lot of excessive programming, duplication of EGD signal names in the various equipment. It's happened several times on several sites where control system integrators have provided GE-Fanuc PLCs as part of the BOP control system communicating on the . Whole databases were duplicated on multiple PLCs, which were polling for the same data.

When a number of small changes were subsequently made on various PLCs and control systems and those changes weren't transferred to the other PLCs and control systems all manner of unusual problems started occurring.

When it comes to this type of situation, it's generally best to get more than one opinion. The problem with that is, if they're not the same, or even close, someone has to choose which one is best or seems closest to the most plausible scenario. And, the likelihood of finding persons who can understand the application and all the various PLCs and control systems and how they should work together is pretty slim, too.

This is not an enviable situation to be in. Your best chance at solving the problem lies in finding a knowledgeable person or firm to help with the analysis of the problem or problems, because there may be more than one problem in a situation like this.

Personally, I don't think the problem is hardware.
If there's too much traffic or if devices are asking for the same information from multiple devices, the hardware can only handle so much.
 
Another place to check. Do not broadcast EGD. The EGD publisher should direct its traffic directly to the EGD reciever and vice versa.

Broadcast floods can bring an Ethernet network down very quickly. This type of broadcast flood has been used by hackers very effectively in the past.
 
Top