DDCut integration issues

Not sure if anyone has had any success in setting up the software side of the GGFlex yet, figured I'd ask. I originally tried setting the arduino with grbl 1.1, and was able to run some simple gcode to verify that the axes were set up in the right orientation. DDcut would recognize the system no problem. Also tried flashing the arduino with the last gg2 firmware, that seemed to work also, although its using an older version of grbl.

Problem now is two fold, first I think I need to calibrate the system (steps per rotation, distance per rotation, etc.) Can anyone recommend a good grbl primer for cnc?

Second, DDcut obviously assumes that you have some hardware beyond what is in the GGFlex BoM, specifically an endmill probe set up and probably limit stop switches. (Or soft limits based on calibrated working space? Both?) Rather than using the canned DDcut app with the configuration assumptions, maybe it would be easier to pull out the gcode from the .dd files and run it that way? If anyone has had success milling using the GGFlex, I'd love to hear how you did it!

DDCut/DD2v7 is indeed using an older GRBL version, but is completely good to go in its precompiled form (anyone picking up one of my "Complete Kits" gets an R3 that comes pre-flashed with DD2V7 firmware onboard and shouldn't need further calibration). If you install a newer GRBL version the settings would have to be manually set... I don't have the complete config in any GRBL variant handy, but will try to get a copy together. What I do have in hardcopy are the homing/physical/travel settings, which are:

DD2v7 grbl wrote:

$4=0
$5=0
$6=0
$20=1
$21=1
$22=1
$23=1
$100=400
$101=400
$102=400
$110=1000
$111=1000
$112=1000
$120=30
$121=30
$122=30
$130=75
$131=176
$132=60.5

Again, this won't be necessary to configure boards that I sent with DD firmware pre-installed... but if you want to use a newer GRBL version with another host software setup, these would be the main configurations to make. These values can all be configured via any serial console (usually the one within the host software) by just sending each value, $___=___ as commands

Regarding limits, in development we had been working with absolute positioning (dead reckoning) to initialize and then the material probing for zeroing. Through a weird (possibly intentional?) feature of DD's firmware, throwing jumpers on the low and limit pins of the CNC Shield allowed DDCut to function without issues in its homing procedure - we suspected that DD2v7 looks for the pin to go low when executing a homing move, and then otherwise only looks for a state change in functioning as hard limits. In this way, users could just place jumpers on the endstop pins, manually adjust the machine to a rough mechanical zero, attach a wire between a D12-low pair to their endmill and workpiece, and then allow the local home/material probing to produce an accurate zero. I have a text writeup of the process but haven't had time to add images and publish as a PDF due to workload this past week... will try to update with what I have shortly...

Longer term, we've had some hardware hiccups (dropped USB being the worst... it will reset the alarm on the jumped home pins and cause the machine to think it hit a limit) that have pushed us to implement more standard homing methods. I have files for a variety of endstop switches in final revision and have been working to calibrate inductive and IR sensors for material probing instead of the endmill method (which doesn't really cut it for polymer or passivated/anodized metal parts).

[[[Also just FYI, I'll supply anyone who's gotten a complete kit from me with the updated endstop variant parts when they're released (as well as a couple other variant parts that I've changed since the 2.0 release in light of user feedback).]]]

In future development, pulling Gcode from the .dd files will be the way to go... though particularly with the addition of the 4th axis, a lot of the .dd toolpaths will be comparably inefficient. We're migrating to 32-bit controllers though with no obvious way of integrating DDCut support, so using the plain code will be a must for backwards compatibility.

Thanks for the info. Could you please confirm the pitch? I tried measuring myself and got 4mm with a 200 step NEMA17 putting $100 etc at 50 with the default a4988 stepper driver (unless you have microstepping enabled?). Thanks!

Iresh wrote:

Thanks for the info. Could you please confirm the pitch? I tried measuring myself and got 4mm with a 200 step NEMA17 putting $100 etc at 50 with the default a4988 stepper driver (unless you have microstepping enabled?).  Thanks!

Yes, the ballscrews are 4mm lead and the factory DD setting is at 1/8 microstepping for 400steps/mm. Microstepping is nice but definitely isn't necessary if you're manually plugging in settings, should have mentioned...

Cool, well, just an FYI, I am working off of the eBay kit. Maybe I'm mistaken but it looks like the A4988 drivers need two jumpers per driver to set to 1/8 microsteps. These weren't included in the kit, so if the user wants to use the flashed arduino as provided they'd have to rig it somehow, or change the configuration.

I took a look at the CNC shield pinout re: the work around for the homing, but it's not clear which pins you're referring to (low and limit pins). Could you point them out using their silkscreened designations?

Also, I took a look in the .dd files, they left some notes in there that really help someone like me with limited grbl experience. For those interested in looking, they're renamed .zip libraries. I like how they probe the mag well to define center-x of the workpiece.

EEM-LLC wrote:

users could just place jumpers on the endstop pins, manually adjust the machine to a rough mechanical zero, attach a wire between a D12-low pair to their endmill and workpiece, and then allow the local home/material probing to produce an accurate zero.

Just as a follow up, I've tried jumping all of the endstop pins, but DDCut still tries to $H on starting the AR15 .dd script and fails, ending the run. I've been able to rig the conductive Z probe, though, so that's a thing.

Iresh wrote:

Just as a follow up, I've tried jumping all of the endstop pins, but DDCut still tries to $H on starting the AR15 .dd script and fails, ending the run.  I've been able to rig the conductive Z probe, though, so that's a thing.

We've classically used three jumpers - one on either X+ or X-, one on either Y+ or Y-, and one on the 'SpinEn' pins (which is misidentified for our purposes and actually the pin assigned to Z+/-).

In testing with the current hardware setup (the R3 + CNC Shield Combo) and numerous .dd files provided by folks troubleshooting their machines, it's become apparent that this jumper trick isn't working for everyone. As far as I know the DD2v7 firmware is still the same we've been using all along, and I have two machines running older .dd files on slightly different controllers without issue, so it is likely either some slight difference in controller components or the .dd files...

For folks for whom the jumper trick isn't working this brings up two important things;

1. Without any other easy hardware hacks (an option I'm exploring but not finding any obvious answers to), the easiest way to run current generation .dd files that force the full homing routine is to go in and edit the Gcode in the .dd package to omit the $H and work coordinate operations (or in some cases you can just remove the whole subroutine/file). This isn't a great solution though and obviously isn't safe for a lot of the currently supported projects.
2. I'm going to push the 2.1 Release package early (on my own fork of the project) to include the endstop parts (which weirdly enough I was already slated to publish this weekend). These endstops are mounted to the same locations as the factory GG2's and support a small variety of different switches currently. I'll make a more in-depth post, but basically the files should be out by Sunday and I'll be sending anyone who has sourced their kits from me a set of these printed endstop mounts and a 3-pack of switches.

I'm still dealing with periodic utility outages where I am due to snow (which is why I've had very sporadic activity the last 2 days), but the endstop parts are already through testing so I just have to publish them and update the instructions as best I can. Will try to keep everyone posted!

Yeah, I tried jumping the SpinEn pins and that solved the z-axis movement on $h, but the system still throws an alarm. This happens in non-DDcut gcode senders as well. Thanks for setting up some stop limit switches for people who ordered the kits, I'll keep an eye out.

EEM-LLC wrote:

Iresh wrote:

Just as a follow up, I've tried jumping all of the endstop pins, but DDCut still tries to $H on starting the AR15 .dd script and fails, ending the run.  I've been able to rig the conductive Z probe, though, so that's a thing.

We've classically used three jumpers - one on either X+ or X-, one on either Y+ or Y-, and one on the 'SpinEn' pins (which is misidentified for our purposes and actually the pin assigned to Z+/-).

In testing with the current hardware setup (the R3 + CNC Shield Combo) and numerous .dd files provided by folks troubleshooting their machines, it's become apparent that this jumper trick isn't working for everyone. As far as I know the DD2v7 firmware is still the same we've been using all along, and I have two machines running older .dd files on slightly different controllers without issue, so it is likely either some slight difference in controller components or the .dd files...

For folks for whom the jumper trick isn't working this brings up two important things;

1. Without any other easy hardware hacks (an option I'm exploring but not finding any obvious answers to), the easiest way to run current generation .dd files that force the full homing routine is to go in and edit the Gcode in the .dd package to omit the $H and work coordinate operations (or in some cases you can just remove the whole subroutine/file). This isn't a great solution though and obviously isn't safe for a lot of the currently supported projects.
2. I'm going to push the 2.1 Release package early (on my own fork of the project) to include the endstop parts (which weirdly enough I was already slated to publish this weekend). These endstops are mounted to the same locations as the factory GG2's and support a small variety of different switches currently. I'll make a more in-depth post, but basically the files should be out by Sunday and I'll be sending anyone who has sourced their kits from me a set of these printed endstop mounts and a 3-pack of switches.

I'm still dealing with periodic utility outages where I am due to snow (which is why I've had very sporadic activity the last 2 days), but the endstop parts are already through testing so I just have to publish them and update the instructions as best I can. Will try to keep everyone posted!

Just curious as to your progress on this post - I am probably as far along as Iresh in that I've got everything wired up and can complete basic operations like table movement but cannot run any .dd programs.  Will be sweet to see homing/endstop additions....

Text version of the Uno/CNC instructions were just updated (added at https://github.com/EEMLLC/GGFlex/blob/master/UNO%2BCNC_instructions_(FLEX-2A).txt on my fork) with PDF available in a couple hours.

The wiki within the main distribution by insurgent should also have a page added within a couple days. Finally getting somewhere with GitHub unlocking it.

i posted new topic on how i got it to home bro