In a recent post 1F says “We do not recommend having any part of the CNC plugged into a GFCI outlet or breaker.” I have a recently constructed shop behind my house. When I was building it, the electrical was installed per the NEC, which requires ALL outlets in such a structure to have each circuit on either GFCI breakers or 1st in line GFCI outlets. It passed inspection and is in full compliance with code. Your statement is effectively saying, “disregard the NEC”. Might not be the same in Canada, but here the code requirements are pretty clear.
1 Like
Your VFD for the spindle will pop the gfi
1 Like
Yep. That’s what they’re saying. Virtually all of our installs are in garages, basements or out buildings - all of which are required to have GFCI or AFCI breakers. The NEC code for that goes back several years so it’s not something that was just added.
That’s the only OF recommended EMI “fix” I haven’t implemented because I’m not about to put the house or my insurance at risk. So I live with it using manual workarounds to be able to recover from HMI failures.
Ok - so I’m a little confused. Let’s break this down. A GFCI works by sensing the current difference between the load side (i.e., “hot”) and the neutral side. This is usually not a problem for most capacitive or resistive loads as the current is “in phase” with the voltage. It is a massive problem for any purely inductive load as the current is 90 degrees out of phase and that lag usually causes a GCFI to trip.
I don’t get the relation to electromagnetic interference? I have to believe a GFCI outlet or breaker would not be affected emitted radiation. I guess it is possible there is some effect from conducted radiation? Though I also have to believe the GFCI would only help reduce conducted emissions rather than enhance them in some way?
As for the VFD, this is a computer controlled motor, where integrated circuits control the electromagnetic force applied to the motor by modulating the periodicity of the pulses. That makes the spindle an entirely capacitive load - which should not disrupt the GFCI.
The VFD, as a square wave, will certainly generate harmonics into the high MHz range if not GHz. Those square waves will also cause sudden spikes in current requirements as the motor “engages” with each cycle, but from a power supply problem, that is a capacity load, no?
Certainly the VFD will radiate because of the current spikes and I’m sure that will be both emissive and conductive radiation. Probably a lot of it given the loads being switched.
Is the problem the radiated or conducted emissions maybe “mistaken” for leakage current and will trip the GFCI? If so, a properly designed controller should mitigate the issue. If not, how would pass EMI testing and certification?
Would an in-line filter help?
I also feel like google can answer this for me, but I’m curious if anyone here has direct practical experience.
-Tom
1 Like
Contrary to those who say the VFD or other parts of our systems will trip a GFCI, that’s not been my experience. Maybe they have faulty GFCI outlets or breakers. All of my shop equipment is attached to either GFCI outlets or GFCI or AFCI breakers because it’s a lower level shop (below grade on one side, above grade on the other due to ground slope) and that’s the NEC requirement.
I do have unresolved EMI for my OF.
I’ve been chasing EMI issues since upgrading from the BB to the Redline motion controller and HMI. My VFD has always been on a dedicated 220V circuit with no GFCI support. However, my HMI system was on a GFCI-protected circuit. I had frequent issues with my HMI losing coordinates. Actually, they weren’t “lost”; they were consistently turned 90 degrees. I could get around the issue by figuring out where the cursor would be if it wasn’t turned 90 degrees - at least enough to do a graceful restart.
Replacing the GFCI circuit breaker with a standard breaker from the HMI circuit reduced the number of issues I experienced with the coordinates being turned 90 degrees. It still happens occasionally, surprisingly when I’m not using my spindle but using other equipment in the shop. I suspect my dust collector is the source of the problem, but I’ve done everything I can to reduce its impact, including moving the monitor away from the dust collector, running a ground wire through the ducts, and adding ferrite cores to every cable in my shop.
This appears to be a frequent issue for Redline controller users, especially those who have upgraded from BB and have never experienced an EMI issue with BB. I don’t understand the specifics of EMI, or whether it is an issue with the current getting to the machine or a lack of shielding in the Redline equipment, but it has been a frustrating experience. OF has said that all CNCs experience EMI, but such a significant change after upgrading from BB to Redline suggests a Redline issue (to me).
My apologies for a long rant…
1 Like
did you try putting magnetic collars on your HMI wires?
Yes, I have ferrite cores on all cables in my shop. I assume that is what you mean by magnetic. Ferrite cores are not magnetic. Is that something else?
1 Like
Omg yes, apparently I need more coffee.
The touch screen touch being off by 90 degrees is part of how the Raspberry PI firmware is programmed. It’s really odd that would be an intermittent problem. I would email RealTime CNC. They have been very helpful any time I have reached out. I am using the HMI image on a raspberry pi 5 and have not seen this happen, but I haven’t done any long runs with the set up yet either. I do know for a fact, even if the touch input is rotated, that a mouse will still work FYI. My controller ran fine on GFI but my spindle would pop the GFI. I think for home use most GFI have a pretty low current threshold. Not sure where to find ones with higher threshold.
1 Like
and also, I have noted that pretty much any
GFI will go bad after five years sometimes less.
One would think with many users are having issues with EMI and the Redline unit, and that it warranted a special “announcement”, 1F would be pursuing a solution such as shielding for interior of the case, cables, etc. Also at the price point, expecting a solution is not unreasonable. Just my two cents from the cheap seats…
1 Like
I have removed the GFI breaker from the circuit the HMI is on, but the issue remains, though less often. Per another user’s suggestion, I’ve sent an email to Realtime CNC for their opinion. It is sort of odd that my issue is ALWAYS the touch coordinate system turning 90 degrees.
I wonder if this same 90 degree turn is experienced by anyone else?
1 Like
What’s happening here comes down to how capacitive touchscreens work and how they react to EMI/static.
The Redline HMI screen detects touch by measuring very small electrical changes when your finger touches the glass. Because of that, it’s naturally sensitive to electrical noise. In a CNC environment, the biggest source of that noise is almost always static/EMI — and 99% of the time that’s coming from dust collection.
When a static discharge or EMI event happens, it can basically “zap” the touch controller. It doesn’t damage anything, but it can cause the touch system to momentarily reset.
Here’s where the orientation piece comes in:
The screen hardware is natively landscape (horizontal), but we run it in portrait (vertical) on the Redline HMI. During a normal boot, the realtime OS tells both the display and the touch controller to operate in portrait mode.
But if the touch controller resets on its own (from EMI), it comes back in its default state — which is landscape — while the display is still in portrait.
So now they don’t match:
- The screen is vertical
- The touch is horizontal
That’s why when you go to press something, it doesn’t line up with your finger.
When you reboot, everything initializes together again and the system reapplies the correct orientation — so it lines back up.
The important part here is that the root cause isn’t the screen — it’s the EMI/static event triggering that reset. Dust collection systems are by far the most common cause, but spindles, wiring, and grounding can all play a role too.
If you reduce the EMI, the issue goes away. Some have grounded their hose and collector, and moved their dust collection farther way to stop these issues.
These are the two best resources to go through:
- Redline Controller Grounding FAQ
- EMI | Screen Flickering, Blank, or Black Screen, Randomly Loosing Zeros, Freezing, Disconnecting or Random Happenings
Hope that helps explain what you’re seeing
1 Like
Thanks for the explanation on the 90-degree pivot on the touch coordinates. Now I see why it always the same orientation when it happens.
I have red your FAQ a few times, and I’ve done all I can to address the dust vac-related issue. I’ve run copper wire through the hose, removed the GFCI breaker on the circuit to the HMI/motion controller, put the HMI/motion controller, dust collector, and 220v spindle on different circuits, and moved the monitor to the other side of the table, away from the dust extractor. I was desperate and bought an electromagnetic sensor and found the biggest sources were the dust collector, the spindle, and the breaker panel (which is on the other side of the room). A big surprise was the Ring camera I use as a security camera and doubles as a remote monitoring camera for my jobs. It had a surprisingly high E-field output, while the dust collector had a high M-field output. I moved the ring camera away from my table. Do you know if the HMI is more sensitive to electric fields or magnetic fields?
I keep hoping Redline will come up with the magic fix to address this…
Thanks again.
1 Like
Maybe in future versions of the HMI there could be one extra button for screen reset. I can confirm the is a bit of extra programming to match the touch orientation to match the screen orientation (thanks L.M!) Keep a USB or wireless mouse handy if and when the problem comes up because the mouse will not be inverted and you can at least finish you job with without fighting touch screen inversion. I’m no grounding expert but star grounding comes to mind? CorvetteGuy knows some stuff… https://youtu.be/Ma-q0aArEhE?si=jL1enUJ7q1Oy9rZG
2 Likes
I still call bull— especially when I’ve had the original controller glitch while running on a UPS that’s completely isolated from the VFD circuit.
If the controller freaks out on a clean, conditioned, battery‑buffered feed, the problem isn’t upstream.
The problem is downstream, inside the controller.
What you’re describing isn’t some mysterious “static event” or a cosmic dust‑collector anomaly — it’s exactly what happens when a controller with zero real EMI immunity gets dropped into a CNC environment and asked to pretend it’s industrial‑grade.
Capacitive touchscreens don’t magically flip orientation because a dust hose sneezes.
They flip because the touch controller is resetting under EMI load, which only happens when the system isn’t properly filtered, shielded, or grounded at the controller level.
And the whole “the screen is landscape but we run it in portrait” explanation?
That’s not a root cause — that’s an admission that the hardware is being pushed outside its native spec and falls apart the moment noise hits it.
If the EMI environment were actually handled correctly:
-
The touch controller wouldn’t reset
-
The orientation wouldn’t desync
-
The UI wouldn’t freeze
-
The machine wouldn’t drop zeros
-
And users wouldn’t be told to rearrange their entire shop to accommodate a sensitive Raspberry‑Pi‑based controller
Industrial machines don’t do this because they use proper filtering, isolation, and hardened electronics.
A $60 line reactor and a $40 EMI filter would solve 90% of what’s being blamed on dust collection.
So let’s call it what it is:
This isn’t a dust‑collector problem.
It’s an EMI‑sensitive controller problem.
Grounding a hose is good practice — but it shouldn’t be the difference between a working CNC and a touchscreen that suddenly thinks it’s sideways.
And when the controller glitches even on a UPS — isolated, conditioned, and completely separated from the VFD — that tells you everything you need to know about where the real weakness is.
Bovis
Is this something that could be added to existing controllers and how would you go about installing them?
I’ve gotten the “EMI is the problem” reply from OF as well . I wonder how many instances of this problem are happening perphaps a poll of users is in order. I asked OF SUPPORT if the masso controller has this issue but didn’t get a reply. My issue has been tool path just stopping randomly luckily jump to line seems to work for restarting but I’ve had as many as 4 or 5 time on a long (one hour) tool path. I didn’t have the issue on my older buildbotics
I would also be interested in “EMI proofing” my new redline. I have yet to use it as i have been busy making My ultra-low-profile clamps for people. but I will soon have some time to work on the fun stuff. hilljackfab.com