search

synthetos / g2

g2core - The Next Generation
Other
622 stars 296 forks source link

Documentation is confusing and inconsistent regarding axis support #465

Closed bobobo1618 closed 1 year ago

bobobo1618 commented 4 years ago

The software sounds great, so I've been trying to figure out whether I can "plug and play" this to work with my mill and there's a bunch of inconsistent information:

MitchBradley commented 4 years ago

Recent versions of the code support up to 9 axes. My setup uses Due + gShield + some external drivers for 4 axes. I have external drivers (ihsv57 integrated closed loop steppers) on X and Y, and Z and A ordinary steppers are driven from the gShield. This required creating a custom configuration file to assign the pins correctly.

You could also use two gShields. One would stack on top of the Due and the other would be off to the side, connected via Dupont wires to available Due GPIOs.

justinclift commented 4 years ago

Can I buy another board that supports more axes?

The general approach people seem to go with (for up to 6 axes) is grabbing an Arduino Due, plus an appropriate carrier board for their drivers. eg:

The gQuadratic and gQuintic boards are still in development (yeah, it's been a while) and aren't available yet. Some day they will be. :innocent:

What's the project you have in mind, for potentially using g2core with?

bobobo1618 commented 4 years ago

@justinclift I have a Nomad 883 Pro milling machine and I'm unhappy with the undocumented stock controller board (which I fried and is expensive), I'd like to replace it with something more open (and replaceable).

When I wrote this, I thought I had two steppers on the Y-axis, so I'd need a 4-axis board but it looks like there are only 3, so I could get away with the stock gShield.

Thanks for those links! I'm tempted to go for the latter so I can try out different stepper controllers. Can't help but wonder if Trinamic's silent drivers can quieten my (currently DRV8818-driven) steppers a bit.

justinclift commented 4 years ago

Ahhh, the Nomad's have a decent reputation for rigidity. I've not used one personally, though I used to have a Shapeoko 3 (my entry to the CNC world :grin:).

I'm tempted to go for the latter so I can try out different stepper controllers. Can't help but wonder if Trinamic's silent drivers can quieten my (currently DRV8818-driven) steppers a bit.

Not sure personally, but wouldn't be surprised either way. Um... one way to find out? :smile:

justinclift commented 4 years ago

Hmmm, looking around quickly for Trinamic drivers that might fit into either of those Djuke g2shield boards. Not seeing anything obvious though.

Hopefully I'm just being blind, and there are options that work...? :smile:

justinclift commented 4 years ago

Ahhh, these look roughly like the correct form factor. Haven't checked the pinouts (etc) to make sure they'd really be ok though:

    https://shop.watterott.com/Motor-driver

That's something someone with a bit more electronics clue than myself should probably do. :smile:

MitchBradley commented 4 years ago

Search for "silent step stick" and also see this compatibility note. Some of the Triaminic parts need to be configured with SPI, but others can be configured with strapping pins, like on other stepper modules. There are some videos on YouTube explaining it.

bobobo1618 commented 4 years ago

Thanks for the help! Yes, I'd like to use the Watterott drivers.

It looks like my biggest obstacle is that there are no premade boards to support a bunch of drivers with SPI. I think my best option there is probably to just forgo the board and use a bunch of breadboard to connect things to the Arduino "directly".

And then I need to write some code here to support the SPI setup for the driver but I see there's already some code for another Trinamic driver so I can generalize/copy that I suppose.

MitchBradley commented 4 years ago

Contact me directly via the email address in my GitHub profile and I will walk you through some options.

jeaton2411 commented 3 years ago

It seems like the broader issue flagged here and elsewhere (multiple issues point to this) persists across G2core documentation sources. I (for example) am interested in utilizing the increased processing power of a Due and the additional axis potential and jerk control features of G2core on a dual Y motor router mill running off board TB6600 controllers. I would prefer to use stable master branch code. (Maybe edge is reasonably stable but there are warnings indicating it is more of a beta build). Also the lack of activity is a little off putting to me as potential user (last commit is pre-COVID...)

A clean connection platform like: https://webshop.djuke.nl/kits/g2shield-external-kit would be ideal for users desiring a 4+ motor machine, but the documentation for this option suggests the need for using an edge fork and a custom configuration and compile. Which is a bit intimidating.

Alternatively, a definitive pinout for G2core Master branch would access to a Master branch derived build for those of us who would prefer to stay at the user depth of engagement (as opposed to the developer level). The pinout documentation for g2core on the Due states:

"Caution: g2core and Ardunio DUE enable significant flexibility in Pin-out assignments. There is no definitive pin-out, as pin assignments are a compile time option in the build process."

I know there are those who would criticize the desire to be handheld more in the documentation as perhaps lazy, but if the goal of the project is to improve the capabilities of CNC electronics, improving the accessibility of the platform for user level engagement seems relevant to that goal.

What is the path forward for utilizing G2core on a build (especially beyond the 3 axis limitations of gShield v5) and are there any initiatives to expand user level hardware options, documentation, examples, or support?

justinclift commented 3 years ago

@jeaton2411 Good point. :smile:

Some general thoughts, in case they help:

So, if you're ok with the pins selected there (which work fine!) then you don't need to adjust any pin assignments,

jeaton2411 commented 3 years ago

Good to know that those are the default pinouts for the Due. It might be a quick helpful fix to say so explicitly on that Wiki page right near the warning about them being a starting place.

I think my path forward is going to be to build the full mill assembly and to get it working under grbl so I'm not fighting software and hardware battles at the same time, then to document my upgrade to G2core with the hope that sharing my process can help close the documentation gap somewhat.

I can empathize with you being out of your shop as I spent most of Covid time barred from mine. Here's hoping you can get back soon!

JE

On Sun, Jul 5, 2020, 7:13 PM Justin Clift notifications@github.com wrote:

@jeaton2411 https://github.com/jeaton2411 Good point. 😄

Some general thoughts, in case they help:

So, if you're ok with the pins selected there (which work fine!) then you don't need to adjust any pin assignments,

  • I have a rough plan to improve the g2 docs for using the Due, but haven't been able to do so as all my gear is at a local Makerspace that's temporarily closed due to the Coronavirus lockdown in my location.
    • No idea when that's going to be lifted, so if anyone else is up for doing it instead they shouldn't wait for me. 😉

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/synthetos/g2/issues/465#issuecomment-653979483, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALB5DHKQNODNXQKS3LQMAGDR2EXLHANCNFSM4M433X7Q .

justinclift commented 3 years ago

Yeah, it's frustrating. :frowning:

Your plan sounds sensible too. :smile:

willmackey2nd commented 3 years ago

But these prebuilt bins pointed for every newbie dont have any motors enabled, which is quite confusing(?) Wiki should state clearly that one basically has to build a custom bin to get anything working.

justinclift commented 3 years ago

Good point @willmackey2nd. Everyone has write access to the wiki, so would you be up for adding an appropriate note about that?

Something that lets people know they need to manually enable the motors after connecting to g2core, unless they've compiled g2core with their own settings file.

I'd do it, but am super tired atm and am about to hit the sack. Figuring out good wording for this is beyond my thinking skill right atm. :wink:

willmackey2nd commented 3 years ago

@justinclift I'm fresh in this whole TinyG/G2/GRBL playground and just recently started looking into it in search for upgrading my Chinese 3040 and its crappy BOB (that only works with the old pirated PlanetCNC software they kindly provided sigh). I could help with updating the wiki but need to dig myself a bit deeper into all this first. Some issues I faced and what most newbies will probably face and that could be mentioned in wiki. I'll just barf this pain out here for now.

It was just quite overwhelming to figure out the pieces as the wiki is quite outdated as is most of the info found around web from random discussions. Maybe if I was familiar with GRBL before starting it would have made more sense. The lack of a simple config file and instead these serial commands to configure stuff is just so different compared other system architectures. Then incompatible (or buggy?) interfacing with Chilipeppr and it's config widget helped to make it even more confusing.

For me it seems to make most sense to use CNCjs (at least it worked like charm out of the box) and instead of running some startup macros to configure my router every time, just compile the proper settings to a custom binary.

There lied another trap: I had first tested the basics by flashing g2core v87.xx using Chilipeppr's integrated tool and it kinda worked (with glitches). Then after I flashed latest edge-branch I was left wondering why motors didn't work, until I found out that the default settings in new versions disable all axes and motors. Then I noticed that settings widget in Chilipeppr didn't seem to be able to send the proper configuration to the board either. Then after figuring out the setting files and pin configs I managed to compile my own version (on Ubuntu, didn't even bother to try compiling on Windows as it looked so horrid) I was yet let down by motor problems, till I found a discussion where it was mentioned that the common enable pin wasn't controlled in recent builds. After that, by remapping motor 1 enable pin and setting the motor power modes to 'MOTOR_POWERED_IN_CYCLE' I was able to run my test bench somewhat normally. Oh, but not before noticing that Chilipeppr flasher suddenly decided to crap out on me and reported 100% completed while actually skipping half of the download. This made my DUE to show up in device manager as Bossa Program Port which I first though was because of a failed build but then noticed CP finishing the flash process way too fast. After that I just used the bossac.exe without problems (yes, well that one was guided in the wiki so can only blame myself :) ).

Yes yes I know I'm about to face plenty of other glitches like arc problems etc. if they're still around but took good 2 days to get even the basic stuff done and if I would have known all these pitfalls it would have been just few hours to set up.

Anyhow, thank you for everyone involved in G2 development (and in any of the mentioned projects) and besides the outdated documentation it seems really great platform for a cheap CNC build!

ril3y commented 1 year ago

Thanks for the comment. We are working on updating documentation to this day :)