# Frame grounding, data & power - EMI

I'm looking into building some large robotics with (ofcourse) a frame, (shielded) data/communication cables - EtherCAT, and power lines.

Now different 'experts', websites and people say all different kinds of things in order to prevent noise on the data lines, to prevent ground loops and to use the frame as ground.

What we have figured out now is to use the frame as 'ground' for the data cable shielding. Connect both ends to the frame and connect the frame to battery ground on one point only as close as possible to the battery.

How does this not create ground-loops in the shielding? Or have we figured it out wrong? Shouldn't the electrical components' ground plate be connected to the frame on multiple points? Or should they best be electrically isolated from the frame? And if the latter is true, how about capacitances between the frame and ground plates of these components? What if we have to thermally cool these components on the frame?

What is true and what is false? Because we can't see the wood for the trees any longer. Tips & tricks to keep in mind?

I added a diagram as requested with maybe some clarification. The green 'frame' is electrically connected (green lines represent the connection) and the purple boxes are motor controllers creating some noise when powering and moving the motors represented by the yellow circles. The data cables are shielded EtherCAT cables.

• We can't see your schematic so it's unanswerable without you providing more information. An example of what you are talking about as a diagram would be a good start. Nov 11, 2020 at 15:31
• To evaluate the risks, you need to do this: + define the acceptable error rates on your data transmissions + define the necessary Signal Noise Ratio for achieving that error rate + draw a very detailed system disgram, indicating transient upsets and DC_upsets to Ground potentials + define capacitances between cables and Ground, at various points in your system + using SlewRates (from rise times) and Capacitances, compute the transient currents thru the risky paths + knowing (estimating) inductances, compute the inductive "bounce" or upset from V = L * dI/dT Now you have "noise" (deterministic, Nov 11, 2020 at 17:27
• Frames of some size are usually connected to earth. It's not good practice to mix earth ground and system ground. (Thought opinions differs about this.) If each cable shielding are connected together and then connected to system ground, it should work. Maybe adding a parallel wire for system ground to offer additional anchors to the shields could improve the circuit. Nov 11, 2020 at 22:11
• Thanks @Fredled . Could you elaborate a bit more on the reasoning of your statements? Thats what makes this all interesting. And will this not add ground-loops?
– Mart
Nov 11, 2020 at 22:26
• Some communication systems like USB and ethernet should not have signal ground tied to chassis/earth/shield ground but cable shield must be tied to earth. In other cases, they can or should be connected at a single point with a bolt on the chassis. I prefer to separate signal ground from chassis/earth ground completely but other disagree. In fact "it depends". The literature about that is endless. More reading here: electronics.stackexchange.com/questions/19561/… Nov 11, 2020 at 23:18

I would highly recommend that you read ETG1600: Guideline for Planning, Assembling and Commissioning of EtherCAT Networks , a public white sheet that covers the suggestions for system design and covers grounding considerations.

In EtherCAT the signal processing chain is digitized and goes through an EtherCAT slave controller or equivalent on every single device.

EtherCAT Network Topology courtesy of Beckhoff

Therefore, The Daisy chain topology of EtherCAT is not actually a physical daisy chain and does not resemble a traditional bus interface of E.G RS485 or CAN.

Signal processing chain inside the slave device, note that up to 4 ports are allowed allowing for a star topology, but typically 2 are seen on devices, the ethernet frame processing occurs in the "EtherCAT processing unit" between the input port and any subsequent network segments. Courtesy of Beckhoff

Furthermore, EtherCAT relies on specific physical layer requirements for isolation and grounding. 100 Mbit Ethernet over CAT5/CAT5e should be isolated to 1KV via transformer. As long as your frame voltage does not exceed 1KV between two nodes, you should not have any impact from frame coupling the devices.

In fact, the typical recommended scheme specifically recommends against connecting frame shield to ethernet shield in either case. Although this will not necessarily be enforced by spec.

Ethernet Grounding recomendations for EtherCAT slave device developers Beckhoff ET1100 Datasheet

EtherCAT does not address power grounding requirements, this is left to sector/industry/product specific requirements. Furthermore, EtherCAT does not specify a novel physical layer, but relies on existing specifications for physical layer (e.g. fiber, gigabit, ethernet)

Ultimately it is up to the system designer and in some cases an industry consortium to decide what is the grounding scheme for their systems. For example

If isolation and/or long distances (1KM-20KM) are required - a fiber physical layer is completely isolated.

Ultimately, if the typical isolation grounding scheme of ethernet devices, in particular the tendency to couple frame ground to ethernet shield, in case of shielded cables, may present a challenge if you are also using frame-coupled DC distribution systems.

Conflict of Interest Disclosure: I have some affiliation with ETG

I dont know if this is still relevant, but I would suggest keeping three "ground" lines in mind. Data Ground, Chassis Ground, and Power Supply Negative.

Have these three grounds connect at only one place, and possibly at some (3in-6in min) length from the battery. I would only suggest connecting the CAT shielding to the computer's chassis, nothing more. In some cases, the Power Supply Negative is actually not connected to chassis ground of the computer or the motor controllers, where most of the problem usually resides.

There is a possibility the chassis of the motor controllers are introducing noise which you cannot control. These motor controllers could potentially be connected to your CAT shielding. You will need to determine if that is necessary or not.

Good luck!

• If i Connect my shielding to computer chassis, only The first cat cable’s shielding will be connected? How about The other cat cables?
– Mart
Nov 21, 2020 at 17:20

How does this not create ground-loops in the shielding?

If the shield is tied to both locations at the "purple" boxes, It does create a ground loop in the shielding (as the red arrows show below). Check to see if the shield on the cable is actually tied to the connector. It would be unlikely that this would be the case, since ethercat or ethernet cables do not have a shield that connects to the housing of the connector. However, this may not be a problem for several reasons:

1. There needs to be a changing magnetic field, otherwise no current will be generated
2. The majority of the magnetic field needs to be perpendicular to the loop (if it is parallel no current will be generated). The loop area also needs to be large enough to generate a sufficient current.
3. Even if there is a current generated in a shield, it's only a problem if the signal inductively couples to the inner conductors
4. Ethercat uses a design with differential pair and common mode transformers that is immune to common mode noise, and is the best reason for why you probably won't have problem with this design. Even if a large shield current did couple from the outside of the shield to the inner conductors, it would be the same for both conductors and would be canceled out.

In short you should be fine using ethercat for a comm system which is isolated and prevents ground loops (but not on the shield). Coupling should be low

Shouldn't the electrical components' ground plate be connected to the frame on multiple points?

This depends on if the design could be susceptible to common mode noise coming from the grounding system with the battery. A 1A current on 1m of 24awg cable will generate 84mV of voltage, on 10m of cable will be 840mV. And if the current is switching this means that the ground of the device on the end of the cable will be moving up and down by the same amount. (so don't run 1A of switching current on a long 24awg cable. At some point digital electronics will not be happy about this as most digital electronics Vol is in that range. The problem is exacerbated further when devices are daisy chained (serial connected grounds) as device that has a switching current down the chain will affect devices upstream from it.

My point is you need to understand common mode noise through grounds, the easiest thing to do is calculate the switching current and size the cable accordingly or go to a parallel scheme or using isolators if necessary.

Common mode noise in this manner wont affect ethernet or ethercat, as they are galvanically isolated and uses differential pair signaling (which is why we use these for communication). But other digital signals could be.

If you were using TTL serial between the purple boxes I would be concerned, it really matter what your using.

What is true and what is false? Because we can't see the wood for the trees any longer. Tips & tricks to keep in mind?

Usually its easier to build the system and measure noise than to simulate it.

The first thing is measure noise, find out if noise is a problem by measuring the voltage between power and ground coming into the device, do this by putting the meter in AC/RMS mode and measure the noise, for digital electronics I would start to be concerned if the value was more that 10mV's (like 50mV). Measure along the cable from point to point and find the common mode noise.

Get Electromagnetic Compatibility Engineering. by Henry W. Ott. There are many principles that can help you identify problems in a design before you start.

Now different 'experts', websites and people say all different kinds of things in order to prevent noise on the data lines, to prevent ground loops and to use the frame as ground.

Electromagnetic compatibility is an art not a science, what works for one design probably won't translate to another design because there are so many variables involved. Using basic principles can help the designer find the best solutions.

• Electromagnetic compatibility is not a science? Nov 21, 2020 at 6:39
• Not in my book, the principals used to design, develop and test electromagnetic systems are, they way to use them is more of an art. You can believe what you want Nov 21, 2020 at 17:00
• Are you Henry Ott? Nov 21, 2020 at 17:38
• Nope, but I really like the books he produces, I couldn't do my job without them, I think every EE should have Otts book and art of electionics Nov 21, 2020 at 17:52
• There is no shield in Cat 5E used for 100BASE-TX!!! Nov 23, 2020 at 18:15

Ground loops cause a voltage differential between two points in the ground system. This can appear as noise on signals that are referenced to this ground. EMF through the loop induces current that must travel through the loop.

The key thing to remember is that the voltage will be equal to this current times the impedance. If your frame is a big hunk of metal that impedance is likely very low, so you won't actually be generating significant voltage differences in your ground.

When you really get down to it, RF interference, conducted noise, and ground loops are all separate problems which require different solutions.

Ground loops

These occurs when high current devices start raising the ground level locally. It's not an issue within that device, but when it tries to talk to a different device with a lower ground level, the signal is distorted. This can be an issue with analog circuits that are sensitive to the supply voltage. It can be mitigated by using heavier gauge ground wires and better connections. Basically you want to reduce the ground impedance so the ground voltage changes less throughout the system. It can also be eliminated in some cases by using opto-isolators or transformers on your signals. These allow the signal to cross between two devices with slightly different ground voltages. Very useful for example to supply logic signals to a device which is drawing a lot of current and generally wreaking havoc on the power planes.

Conducted Noise

Some devices draw very fast bursts of current, or produce other transient effects on the power rails. This can effect other devices using the same power. Decoupling capacitors near the noisy devices are the best way to mitigate this. They do so by allowing the noisy devices to draw those quick bursts without pulling down the whole system voltage. For high frequency noise in the uS range, use ceramic caps near the source. For lower frequency noise use large electrolytic caps. I often try both. LC and other types of power filters can also help, and you may need them in some cases, but they're a last resort in my opinion, because they often cause additional problems.

RF Noise

Note that reducing conducted noise will also reduce RF noise, because noisy power cables will produce RF noise which nearby wires will receive. In addition, you can mitigate this noise by using shielding around sensitive wires. Ground them on one side, to earth or the chassis ground if possible. You can attenuate RF, and make wires worse antennas by adding clip on ferrites.

This is one of my favourite topics :) You have to understand where what current flows. I usually divide things into three categories:

1. DC - you only want to flow on your power lines, hence you will only connect your GND to the shield at one point.

upd: why would you connect it even once? Because the frame is the safe spot to touch, it's grounded to the building PE (well, it should be), and for safety reasons, you will want your connectors to be safe- because you can touch them.

1. Low AC (for instance, anything up to a few hundred kHz)- this you want to keep inside your motor drives. Use line filters on the power lines, and you are safe- just be sure you have enough capacitance, so the current will not cause high voltage ripples.

2. Higher AC- usually in these systems it's anything between 1MHz to 100MHz. This crap is generated by motor drives, can easily flow through air to the shield and cause a lot of trouble. This is why you will want to have a good "contact" in the AC domain between cable shields and the frame, also between GND and the frame everywhere. This is what you do with capacitors- normally pairs of 10nF and 1uF. Just be careful, safety and other issues may require special capacitors.

Basically, this is a simple grounding policy that you can use. I usually draw every current on the system diagram to try and find where it can go.

Remember, you don't want a motor AC interference to go to communication cables. If it finds its a way- you have to provide a "better alternative", to a route with lower impedance towards the frame. Usually, it means capacitors in parallel, ferrite beads and chokes in series with the cable.

Hope that helps :)

The ethernet cable has an external jacket and you shouldn't be modifying that jacket, so you won't be doing any shield connecting unless you add shielded female-to-female couplers and have two patch cables per segment - a bad idea. So I'm not even sure how "connecting the cable shield option" even came up? How did you plan to actually implement it, in physical terms? In industrial applications you should be using premade well shielded CAT6 (or better) cables, rated for flex use in your case, and you should not be modifying them unless you have the engineering resources to fully characterize such modifications (it's not a trivial matter even if you're an experienced manufacturer of such cable assemblies).

Once that's out of the way, it's clear to me that what everyone intends is for the endpoints to provide some high frequency coupling between the shield and the local earth or case of the device, but it shouldn't do much at the typical operating frequencies of motor drives/inverters, and certainly not at DC - because the impedance of those connections between PE and the shields are the only real ways to direct the unintended currents away from the data/signal cables, and if they are "zero" then you have effectively no control (ferrites won't help much with servo inverter frequencies). Some designs where this wasn't well understood will connect the ethernet jack shields directly to the metal case, and that's often a problem and may even disqualify products from certain applications (I, for one, wouldn't want to deal with it) - even if it may make passing EMC testing easier.

You can use a plain old multimeter to measure resistance between the metal case/PE terminal of the various elements of your system and the shield of the ethernet jack. As long as no more than one endpoint of each connection has a low impedance "short" between the cable shield and the frame, you'll be fine. As an example: to the best of my knowledge, on all modern Beckhoff components that have a plastic case around the EtherCAT jacks, there is no low impedance DC path between Ethernet jack shields and PE/frame/enclosure (e.g. drives in metal enclosures have a plastic panel where the signal connectors are).

If you're serious about reliability, the motion controller should keep an angle totalizer on all rotary joints, and a displacement totalizer on all sliding joints, and the HMI/OPC interface should provide maintenance alerts once your estimated flex life of any of the cables is "coming up" and eventually when it gets used up, as it ultimately will unless your manipulator will have very low duty cycles (that may well be in some applications - you have to engineer that). You'll need such totalization anyway to estimate bearing life of the joints, to diagnose apparently premature wear/failure of components, etc. In my experience, few people do that, and it always turns out to be a serious shortcoming when something fails/wears out and there are easy questions with no answers (e.g. "how much rotation did this gearbox survive?"). And make sure the values of those totalizers are not lost across PLC upgrades - typically you'd want them in a dedicated record/structure type, and declared persistent (do invest in the "second UPS" for the PLC/controller so it can persist those when power is removed - you don't want to be scribbling on flash storage continuously, and you won't win any friends if the service/plant maintenance people will have to pry the data from some OPC overlords who collect the data in their ivory siloes; think of the common man!). In robotic applications I prefer to keep an angle/displacement totalizer, as well as (angle or displacement)^n*(bearing load)^m product totalizer (at least for n=m=1, but depending on your wear models you may wish to store a couple different exponent combinations - it's way less data than logging everything, and sometimes when things go seriously wrong the large-scale log storage may be unavailable for examination, so totalized data stored in a dedicated EtherCAT-based nonvolatile memory module can be a lifesaver).

You also need to bypass as much current as you reasonably can around bearings. Some joint assemblies for use in robotics have built-in grounding wipers with a specified life, qualified for use as PE connections, so you won't need your own grounding then. But that would be explicitly specified for those components. Otherwise you'll need to design the flexible bonding straps between the manipulator segments to have sufficiently low impedance - especially in light of the common-sense requirement of testing the impedance of such connections even if they may otherwise fly under the radar. And you'll need to ensure that the production does not let a DC grounding continuity test that failed "high impedance" around a moving joint pass unnoticed: sometimes even a single such test can pre-wear the bearings enough that their life goes down by a factor of 10 or worse. Connecting a 100A ground bond tester across a rotary or sliding rolling element bearing joint with the bonding straps missing can be the equivalent of pouring some sand into the bearings. Or not. But I imagine that you'll be dealing with expensive mechanical components, so it's best to avoid even the potentiality of such inadvertent damage. And of course ground bond testing must be done with all other cables but the ground strap unplugged - just because the motors may be "grounded" via their power cable shields doesn't make it acceptable nor sufficient, and you really don't want to push ground bond test currents through those).

Ah, of course the ground bonding flex straps will have a different life than the Ethernet cables, and potentially also than other cables, so you have to keep separate totalizers for each class of cable, so that they can be replaced for preventive maintenance, and your field monitoring should have a process to inspect those grounding straps, and amend their life estimates based on field experience, and field maintenance by factory reps should definitely include a cable test on all industrial ethernet segments using a cable certifier - at least until you develop some field experience and have enough accumulated motion to make statistical predictions to guide your cable maintenance/replacement intervals. I don't know your exact application, of course, so these may not be a big concern, but there must be some engineering done to support that, and it costs infinitely less to replace the cables before they fail.

I shouldn't be mentioning that you should be running totalizers for EtherCAT physical layer errors for all nodes as well. My limited field experience indicates that even if your system is well integrated into the factory environment and the diagnostic data is streamed to higher level systems, getting timely and flexible access to it may be an insurmountable problem. So, from a manufacturer or integrator's viewpoint, whatever diagnostic data you hand off to others for "safekeeping" is best presumed absent when truly needed. This stuff may seem far removed from frame grounding, but the weakest link is always the critical one - and when you face field failures, having reliable diagnostic data that you have unquestioned access to is a difference between trusting your system vs. witch hunts.