g2
g2 copied to clipboard
GRBL control inputs not working in g2
I have an arduino Due with the gShield and have wired normally open control buttons for reset (gblrst/D54), feed hold (gblfrh/D55) and cycle start (gblcyst/D56) and when I bring the inputs LOW, none of them seem to do anything. I looked through the latest edge branch code, and the only places these pins are referenced is in the gShield-pinout.h and then in TinyG2/hardware.h, but oddly, they seem to be declared as output pins, not input. But no actual code seems to use these pins.
The due pinout diagram pdf sure makes it seem like they are usable, but have they been implemented in g2? If not, is there some other way to have a hardware feed hold and resume button? I see that I can possibly use one of the 12 generic inputs as an ALARM input, but I didn't see any way to map an input into to CLEAR the alarm.
For what its worth, I am creating a g2 breakout board that makes it real easy for people to use a gShield with g2: https://github.com/makerhqsac/tinyg_g2_breakout
All is working well, except for these last control input issues.
These pins are reserved but not implemented yet. We are working on a branch that will expose these functions.
I looked for this, too. A hardware feedhold input would be awesome for my setup. When feeding from chilipeppr there's a a big delay on its feedhold command,presumably due to buffered commands, but feedhold really needs to be instantaneous rather than "maybe you could feedhold at some unspecified point in the future please?" ;-)
Because of the lack of instantaneous feedhold, I've resorted to using the estop that kills stepper power, but since that causes loss of position you don't really want to use it unless something really bad is happening.
Any updates on the feedhold and cycle start pins?
I was also researching on this topic. Having an extrernal feed hold and resume button would be great! Any progress on this? Thanks!
I am very intressed of feedhold and cycle start pins/buttons too. This can very usefull for my machine.
I am also getting more interested in this since I'm about to upgrade my mill to use Clearpath servos. They have a status output that indicates if they shut down for some reason, and it would be very nice if these could be linked to an emergency stop input so the program doesn't just keep running with one axis shut down since that would be a recipe for a severe crash.
You can use some digital inputs for this. You can configurate them as
INPUT_ACTION_STOP
INPUT_ACTION_FAST_STOP
INPUT_ACTION_HALT
or
INPUT_FUNCTION_INTERLOCK
INPUT_FUNCTION_PANIC
Perhaps you should just use one input and combine your servo signals with an OR gate
Any update on pinouts? It has been a long time. I am also interested in hard wired feedhold, cycle start, reset, etc.
Sorry for the slow response. I’ll look into this and respond later today. On Wed, Mar 6, 2019 at 3:20 AM karoria [email protected] wrote:
Any update on pinouts? It has been a long time. I am also interested in hard wired feedhold, cycle start, reset, etc.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/synthetos/g2/issues/145#issuecomment-470031384, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXj0cESm8vrXJCWk3_2-fPKv0rAxpHnks5vT4hLgaJpZM4JO_Au .
So, as @aldenhart pointed out these are not yet implemented.
The dev-168-gquintic branch shows some of where we are headed with GPIO processing. Input and output pins will be more capable and more configurable.
One thing we are working on as well is better feedhold handling. Part of this requires careful syncing with the controlling UI, which is complicated if we allow pins to trigger feedholds. We have been trying to sort out how best to handle this, but we may not solve this on the first pass in order to get the other features to you all.
-Rob
GPIO is configurable at build time for such specific use cases.