Many issues, main is power wire heat and no photos for electronics assembly

Not sure if anyone except the person I bought this kit from EEMLLC are in here to assist but worth a shot.

I have been screwing with this assembly for over a month now and am about to give up.

The PDFs for building the machine are very well done, easy to follow and with my experience building an Ender Pro and a C02 laser it was very easy to assemble.

First issue was it has no table for X axis. I had bought the GG AR jig and there was no way to mount it. EEMLLC sent me 2 extruded aluminum bars a week later but the GG jig did not fit them. another week later EEMLLC sent me 3D print files of a jig I got to fit to the machine by cutting off the inner right leg of the X fork and now it fits fine. I grabbed a few M5 screws at 20mm and 45mm with wing nuts to mount the jig and AR firm in the machine. That issue is solved.

The problems started with ZERO documentation and ZERO photos for the electronics and wiring assembly. Another week later I finally got emailed the TXT instructions and using Google images to compare was able to get the Arduino aligned with the CNC shield and the stepper drivers aligned. I soldered ends on the Shield red/black power cord for a good connection to the shield.

There are NO photos online of any stepper motors with the same colored wires as I received to know if they were in correct or upside down? So I guessed and can always flip.

I later was mailed jumpers, so I placed those to clone X to A in order to run both stepper motors for the X table. I also was instructed to change jumper settings under the stepper drivers to 1/8 with 3 jumpers on all 6 posts for the 4988 drivers.

Before I fired it up EEMLLC sent me End-stops and different stepper drivers purple in color 8825. These drivers need only 2 jumpers on post sets 1 and 2 and none on post 3.

There was NO photos on where to mount the end-stops NOR how to plug them in to the shield. I figured out X mounting point just fine. But the YZ area has 2 screws it could mount to. I chose the one with a nut as it fit best there, but was not touching the Z carriage bearing housing. So I had to 3D print a small tab and glue it to the carriage. Now the tab touches fine to the switch.

I have guessed even though the endstops have 3 wires but the posts for them only have 2 pins to just hang the green wire off the side not using it. So only red and black wires are plugged in but I do not know if it matters which post is red or black? Many google photos show the green plugged in so that I am not sure works yet...

The MAIN issue is something I hope someone can assist with;

I installed the new 8825 drivers with only 2 jumpers installed. 1 and 2 jumped, nothing on 3. When I supply power to the shield and then USB to the Arduino, DDcut does connect to the GGFlex! Success. HOWEVER, the red and black power wire to the Shield gets so hot they start to smoke and burn my hand to touch so I have to unplug all quickly.

During that time I have checked power to the drivers and get 1.6 more or less on Z,A,Y but there was only 0.6 on X which is cloned to A with 2 jumpers. I switched the drivers and the 1 at 0.6 is still that low, so it does not matter where it is plugged in. And I can not adjust it as the screw is rounded out and came that way on all of them. NO small phillips fits them. So I removed that driver, and using JUST the three 1.6's on X,Y,Z I still get SUPER HOT power wire! It will melt.

I removed all 4 of the 8825 drivers and went back to the original 4988 drivers. I removed the 3rd jumpers for the 8825 drivers. So I placed the 3rd jumper back and have jumpers on ALL 6 pins. I checked all power and they were all at around 1.6. So I powered the shield 1st, then plugged in USB and that's normally when the power wire gets super hot. With these drivers the red/black shield power stayed cool. NO heat, and also no driver hissing like with the 8825s.

I thought that might solve my issues, but nope. Now I launch DDcut and it does not see the machine now. No flex connected nor found.

I open GRBL and UGS both set to baud rate of 115200 and neither find the GGflex.

So just to see if my boards were OK, I switched all back to the purple 8825 drivers and DDcut finds the machine again just fine. But melts the power cord.

So I removed the purple 8825 drivers, went back to the 4988 drivers with NO jumpers and still DDcut, GRBL nor UGS find the GGflex.

Only DDcut finds the flex but ONLY if the 8825 drivers are installed, but those will cause a fire and melt the power cord?!?!

So I have unplugged all and turned to this board for help. Any ideas?

This morning I have done some more testing…

DDcut connects to the Arduino and CNC shield using the purple 8825 drivers and 2 micro-step jumpers. But 12v CNC shield power cord will melt or catch fire due to heat up right away.

I removed the Shield from the Arduino, turned on my laptop and opened DDcut. I plugged the USB into the Arduino and the USB connection sound happened and the DDcut said connected.

I then unplugged the USB from the Arduino.

I then replaced the CNC Shield back to the Arduino aligning pins perfectly.

I supplied 12V power to the CNC Shield.

I plugged in the USB to the Arduino and there was NO USB connection sound from the laptop.

DDcut states NOT connected.

My CNC shield is set up as follows;
Four drivers that came with it, green in color 4988.
3 jumpers in each of the micro stepping pins under drivers.
2 jumpers across X clone.
X,Y,A stepper motors plugged in with blue wire at top.
Z stepper motor plugged in to run backwards for DDcut, black wire facing up.
Probe wires plugged into the Z+ pair (not touching anything at other ends)
Limit switches plugged into Y+, X+ and SpnEn (with red wire on pin 1, black wire on pin 2 and green off the side.)

Should I just order a new CNC shield and 4 new stepper drivers on Amazon today and replace to same Arduino? It’s only $18.

I would say go the route of a new CNC shield. It does sound like it may just be a faulty product.

Interested if anyone has any input or insights on this one, or if anyone has had a similar issue pop up?

The standard drivers included with the kits were just the A4988's, so the DRV8825's are less of a concern... but it is extremely odd that they function (albeit hot) in the same overall configuration that the A4988's don't function in. If anything, the 8825's being the higher current should fail before the 4988's if something is wrong with the shield or power. To my knowledge this is the only case of this happening among all the electronics kits I've packed/sent. If anyone has had similar issues, I'd love to get any details they can provide (and also supply replacement parts as needed, as is always the case!).

We're currently operating under the assumption that one or more of the A4988's is faulty or possibly a trace or contact on the Shield is screwy, but I've never come across this particular issue even with a ton of time spent with other projects that used these CNC Shields.
Specifically, even with burnt out or overvolted/shut down StepSticks, the CNC Shield and attached Arduino have always remained operational and visible when connected to a PC host. The VDD is upstream from any logic circuit and isolated from the Atmega's own supply... even the CNC Shield's VMOT is contained and not attached to the Uno through any supply or ground points.

The only similar issue I've seen documented was a screw overtightened by the Reset pad (top-left on the CNC Shield) that would trip and force a reset by contacting a machine ground. It only did this when plugged into a high power voltage source but functioned fine when powered over USB, which resulted in a lot of confusion.
The FLEX doesn't have any frame grounding points though, and I'm not aware of any mechanical issues in this particular case that might be causing the reset to trip with 4988's installed but not the higher current 8825's...

OK, I have made a small amount of positive progress forward.

I ordered a NEW CNC shield and 4 new RED colored A4988 drivers. Not sure if they are the same as the green drivers that came with my machine that would not connect to DDcut.

I powered the CNC Shield and plugged in the USB. (It made the USB connection sound this time.)

Measured driver power and got 0.6 on all 4.

I then opened DDcut and it showed the GGflex ONLINE this time (great).

However DDcut stated "Machine locked" error after pressing start. Nothing moved at all.
It used to move a bit when using the PURPLE drivers but those were causing my power cord to get so hot it would smoke.

But with these new red drivers I get NO power cord heat, so that's a plus.

To test movement I opened both GRBL and UGS still wont find the GGflex.

I even changed to a new USB port and nothing.
So I then tested a new USB cable and still nothing.

Should I buy new purple drivers and retest?????????????

FYI: Nothing is binding, all axis move freely with one finger turn of the stepper collars. I checked all movement for perfect alignment.

OK, further success. To test I installed DDcut to a different laptop.

I powered up the GGflex, opened DDcut and it was connected.

I clicked start and the Z axis moved backwards very smooth, clicked the limit switch, stopped and DDcut said "Machine is locked due to an error" again and would not proceed.

I have movement.

Now need to troubleshoot DDcut not understanding the end stop was clicked?

I have the probe wire (not hooked to any parts at the moment) on Z + pair. With red on left pin, black on right pin.

(is this why Z moves back and stops, and DDcut thinks its locked up?)

I have the Z carriage end stop/limit switch on "SpinEn" as I was instructed. With red on left pin, black on right pin and green off side.

I have Y and X on their + pairs With red on left pin, black on right pin and green off side.

As a last attempt I installed GRBL, it did connect on this laptop. But when I try to move ANY axis it states ERROR LOCKED.

I opened DDcut again to see if I touched my Z + probe wires together it would stop rearward travel and this time NO movement when start was clicked. Just Machine locked error again... All I can think is I either have limit switches plugged in wrong (no instructions provided) or bad limit switches? or also a bad Arduino???

(With what seems like no one in this forum, has ANYONE that has bought a GGflex actually cut an AR lower with it? I am starting to feel as I am the first to try...)

This photo online shows the green wire on pin 1, the black wire on pin 2 with red hanging off. Should I change to this???

The replacement parts I sent include a spare Uno in case it is also part of the problem (it shouldn't be, since it is isolated from the higher voltage functions of the shield... but just in case...)
It may be to blame for your PC not recognizing the Uno, if none of the other issues.
Do you have multiple COM devices, and have you tried connecting to each of them? USB port reservations and other hardware like wifi that initialize on boot will usually take the lower port numbers and GRBL devices will appear higher up. Again, very odd if DDCut recognizes the FLEX but other hosts don't.

I haven't machined one personally but have done a contour and finish pass on one face of a "0%" (block of 7075 billet). I'm currently working to produce a lower clone of a Falkor Petra in tandem with our 4th axis integration, but have a ways to go on the engineering and setup side.
There was a video on LBRY of one of our beta units machining a P80 and another doing the pocketing operation on a lower, but that was somebody within the dev group.

Pegasus wrote:

This photo online shows the green wire on pin 1, the black wire on pin 2 with red hanging off. Should I change to this???

Yes, the Mk3 endstops I've been including with the upgrade kits should be connected by the black and green wire as shown in the picture you posted. They can also be configured as "Normally Closed" by using the red/black pair, but that is not standard for the FLEX's application.

Both laptops only have 2 USB ports.

OK, I will change the limit switches to be Green on post 1 and black on post 2 and nothing on red.

Maybe with them flipped GGcut thinks they are on.

But how will GGcut know the Z carriage has moved back to + if there is NO limit switch / end stop wired to z+ pins???

Currently I was instructed to put the Z limit switch on the SpnEn pins.

If you aren't using the probe, disconnect it just in case it grounds out or gives some other false positive.

Correct, Z is to the SpnEn pair; green and black.

DDCut (more specifically the DD firmware) uses an older GRBL version that had the pins assigned differently. What was the Z ends back then is now the Spindle Enable switch, which is why the CNC Shield is misnomered.


0% in progress, have loads of people asking lately.
It's not economical currently... takes over ten setups and relocations of coordinates, five different tools and counting... and the jigs are a little questionable. Even the billet at this size runs about $65 if you're buying single chunks.
It's a good learning project though, especially to familiarize oneself with all the different tooling processes that go into a finished part.
Current work was done on a FLEX with a 100mm larger X and 150mm larger Y axis.
1/4" 2F AlTiN endmill, 1.25" LOC, 3" OAL. Around an hour and forty minutes with 0.10" stepdown and 0.075" stepover. 16 contours in Z, 0.03" leftover, single finish passes at 0.375" depths.

Well, I swapped the limit switches to green black, no red and that did nothing to resolve the issues.

Opening DDcut, Flex is connected, click Start and NO movement "machine locked due to error".

Opening GRBL, Flex is connected click any axis direction and get ERROR LOCK.

Now I am not getting any movement at all with new CNC shield and new red drivers...

What purpose are the 2 black buttons on the Arduino and Shield, should I press either of those to reset something?

With ZERO electronic documentation and ZERO electronics setup photos, a buyer is really in the dark on getting this machine working for paying $500+ for it...

However I appricate your support. I have a business to run and can not keep screwing with this indefinitely. It was purchased to run about 2-5 lowers a day and now after a month still wont even MOVE 1 axis...

Section 6.4 of the GG2 Manual;
https://ghostgunner.net/wp-content/uploads/2018/10/Ghost-Gunner-2-Operators-Manual-2018.pdf
Ctrl X and $X being the DDCut soft reset and GRBL alarm clears respectively.

For other GRBL commands (on all GRBL hardware, not just DD installs);
https://www.diymachining.com/downloads/GRBL_Settings_Pocket_Guide_Rev_B.pdf

So, what do I try now??? I have NO movement when using DDcut nor GRBL

Is the procedure outlined in the manual not working?

It can be overkill and there are some alarms that take multiple attempts to clear.
You can always reinstall the firmware (under the settings window in DDCut), it actually tends to be faster than jogging through the soft and hard limit options and manually resetting each possible alarm.

OK, this morning I have tried again.

Inserting the GGflex USB after powering the shield I have opened DDcut.

As suggested instead of clearing error codes I went to settings, software and updated the Arduino firmware. it completed.

I then ran the AR cut program, pressed start and the SAME thing happened.

The Z carriage moves rearward, clicks the limit switch and stops. Up comes an error the "machine is locked".

Correct me if I am wrong, but if pressing start moves the Z carriage all the way + (rearward).

But hitting the Z+ (SpnEn) limit switch always errors the machine.

How would this ever function????

Page 19 of DDcut mentions "enable soft limits". Do I need to let it know not to crash when seeking its limit???

On top of that I have reloaded the firmware again, rebooted. Opened GRBL, gone to advanced and clicked soft reset. I then try to move any axis and get "ALARM LOCK" no movement.

This is not the proper function of the endstops; the alarm is either being thrown by something contacting an endstop or probe that it shouldn't, a switch being configured Normally Closed when it should be Normally Open, or something in the step resolution causing the motor to not back off when it's supposed to.

To confirm, the alarm is thrown as soon as the carriage hits the endstop? It doesn't back off, then come back and make contact again before throwing the alarm?
All endstops are swapped to have the green and black wire pairs connected to the shield's pins, but otherwise in the same positions pictured above? And none of the endstops start in a closed state when the machine is turned on? (If a prior homing operation did leave the axis homed you can just move it off the switch by hand while the machine is disconnected).
The probe wire is not connected to anything that might be shorting and completing the probe loop, causing it to trigger when it shouldn't? And you haven't shorted any of the +/-/GND/5V supply pins that you'd previously inquired about?

Oh, and soft limits will not affect the homing operations by G-code commands sent to the machine; they only disable the alarm if the machine (or a piece of scrap or something) bumps one of the endstops while the machine is mid-operation and shouldn't be touching axis ends.

To confirm, the alarm is thrown as soon as the carriage hits the endstop? It doesn't back off, then come back and make contact again before throwing the alarm?

-YES, before powering on, I turn the axis to full Z - (forward). When DDcut starts, the Z carriage begins + travel (rearward), it clicks the limit switch and stops. Holding it down. DDcut states as usual "Machine locked due to error"

All endstops are swapped to have the green and black wire pairs connected to the shield's pins, but otherwise in the same positions pictured above?

-YES, all end stops are green wire on left pin and black wire on right pin with red wire hanging off right side.

And none of the endstops start in a closed state when the machine is turned on? (If a prior homing operation did leave the axis homed you can just move it off the switch by hand while the machine is disconnected).

-NO end stops are closed when turning on, all axis are in centered state away from all limit switches.

The probe wire is not connected to anything that might be shorting and completing the probe loop, causing it to trigger when it shouldn't?

-NO I have both pins of the probe wire tapped with electrical tape floating in the air. NOT touching anything.

And you haven't shorted any of the +/-/GND/5V supply pins that you'd previously inquired about?

-I have NOT shorted anything. Only jumpers on the shield are clone X axis and 3 below each driver for micro stepping.

-Could the limit switch be bad? I can not see how if the machine touches it and knows to stop???

FYI: I have never plugged in Arduino USB without 1st plugging in the Shield power supply. I have never powered a stepper driver without a motor plugged in.

Have you been able to get UGS or GRBLController connected? They have a little more diagnostic capability and manually jogging the axis or homing a single axis might yield more info. The only other controls fault that I can think of is if the direction pin for Z was somehow stuck and the driver faults whenever it tries to switch back to moving Z-...

Barring the Uno having some issue (which is possible, your replacement should be showing up soon just in case), I'm not aware of any other issue that could be causing this.
I forwarded to the dev chat to see if anyone has other ideas.

UGS/GBC can't connect to the COM port while DDCut is open, FYI.
DDCut automatically connects and reserves the port, and these old school serial chips/Arduinos don't play well with multiple host/master devices.

No, using 2 different laptops with 2 different Windows versions UGS wont even open. I get the splash screen and then nothing... Trying both .exe in BIN folders.

Trying GRBL with fresh firmware from DDcut and DDcut NOT open, not connected I get GRBL to connect fine to the GGflex. But when I press a button to move any axis. I get ALARM LOCK error. ZERO movement what so ever.

Looking through this forum, it appears in the other post DDcut integration issues. Others have NOT got DDcut working with the GGflex either... If that is the case, this may be a lost cause. I purchased under the impression this was functional as a working Ghost clone....

I did see you mentioned DDcut works with only a few types of limit switches, so could the switches be the issue?

The issue mentioned in the other topic was resolved with the endstop update; our old jumper method was causing immediate alarms due to some change in firmware from what we were using in beta - at least as far as I can tell, the source for DD's firmware is closed so we can only see what we find through other host software.

The firmware always throws an alarm if initialized by a controller other than DDCut due to DDCut's serial command structure. $X clears that alarm, as previously discussed. You can then proceed to check if you can manually jog axes through GBC.

Yours is the only instance of this persisting beyond the troubleshooting we've gone through (and then some).
I've had a handful of folks who had the same surface issue; all those have been resolved.
A couple had the endstops swapped, another had a short on one of the endstop headers, another had the wires forced in backwards so they were triggering NC off the voltage supply pin.

EDIT: Also worth checking $H in GBC just in case it's something weird in the .dd file you're trying to run.
EDIT 2: "G28.1 Z0" is the command to home just the Z-axis, by the way. Can be used for other axes as well.

$X clears that alarm, as previously discussed.
--OK, so I entered the command $X after connection. It reads Caution: Unlocked. I then clicked any arrow up or down and it reads: ALARM: Hard limit Reset to continue G91.

I believe the issue has been the same from the start (other than over heat of power cord with purple drivers). First start up the Z carriage moved forward, so we flipped the stepper plug over. Second start up the Z carriage moved backward, hit the end stop and errored. That locked up the board.
So unlocking it was the firmware reset in DDcut.

If others had end stop issues, perhaps my limit switch is bad? I can test by swappin board with Y and manually pressing the Y endstop as Z is traveling back?