New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Power management and shapeoko setting fixes #258
Conversation
…bility with chilipeppr -fixed some shapeoko configs, changed shapeoko2 config to single motor Y and added a dual Y config -fixed power management with gshield using the workaround described in issue #212
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this! There are a few questions, but there's no reason we can't pull this once we figure out these little things.
@@ -258,12 +258,12 @@ pin_number kADC14_PinNumber = -1; // Not physially pinned out | |||
|
|||
|
|||
// GRBL / gShield compatibility pins -- Due board ONLY | |||
|
|||
// NOTE: These dont appear to work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. These should be removed, and inputs made on these pins and preconfigured with the correct actions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do that, however INPUT_ACTION_CYCLE_START and INPUT_ACTION_RESET aren't implemented (afaik) and my attempts to make them work were not successful. INPUT_ACTION_HOLD is weird because I cant figure out how to unhold...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
INPUT_ACTION_CYCLE_START
is interesting. We automatically cycle-start, so we'd have to find a way to make that non-automatic. I guess for now that can be removed and just treated as a plain input (if it's not already, it may be). It would be easy to fake the wait-for-button-push-to-start by making the first line in the gcode something like M101 ({in7:t})
(replacing 7 with whatever input it is).
INPUT_ACTION_RESET
is also interesting. I don't recall the intention for that. I presume it's not board reset, there's already one of those, so maybe it's supposed to mean reset as in M30
? @aldenhart would know.
INPUT_ACTION_HOLD
should be identical to sending a !
with the important exception that Chili (or whatever UI) didn't see it, and if they're not watching stat
to see if we went into hold, they might not offer to resume. If the UI allows it, a ~
should do the trick, just like after a !
. (AFAIK, this has not been tested, and if it doesn't work then please make an issue.)
Again, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I assumed INPUT_ACTION_CYCLE_START
would work exactly like a ~
but bypassing serial, same with INPUT_ACTION_HOLD
(but it doesnt work as intended), anyways i will mess around with these and try to make them work in my branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh sorry I made a mistake its INPUT_ACTION_HALT
not INPUT_ACTION_HOLD
. I just tested and INPUT_ACTION_STOP
appears to work properly and can be cleared with a ~
.
@@ -54,6 +54,7 @@ | |||
|
|||
// Communications and reporting settings | |||
|
|||
#define USB_SERIAL_PORTS_EXPOSED 2 // 1=single endpoint usb, 2=dual endpoint usb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't chili have trouble when dual serial ports are exposed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I havent had any issues, on the contrary its nice to be able to send ! around the queue, however I dont know if anyone else had problems. The only issue may be that sometimes the due needs to be physically (button push) reset, and the serial ports refreshed before chili can connect.
Looks good. We'll merge these into the next release. |
-{me:null} and {md:null} now enable or disable all motors for compatability with chilipeppr -fixed some shapeoko configs, changed shapeoko2 config to single motor Y and added a dualY config based on the previous one
-fixed power management with gshield using the workaround described in issue #212