Skip to content
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

Merged
merged 2 commits into from Apr 21, 2017
Merged

Power management and shapeoko setting fixes #258

merged 2 commits into from Apr 21, 2017

Conversation

ghost
Copy link

@ghost ghost commented Mar 28, 2017

-{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

…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
Copy link
Member

@giseburt giseburt left a 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
Copy link
Member

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.

Copy link
Author

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...

Copy link
Member

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!

Copy link
Author

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.

Copy link
Author

@ghost ghost Mar 28, 2017

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
Copy link
Member

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?

Copy link
Author

@ghost ghost Mar 28, 2017

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.

@giseburt
Copy link
Member

Looks good. We'll merge these into the next release.

@giseburt giseburt merged commit d852cee into synthetos:edge Apr 21, 2017
giseburt added a commit that referenced this pull request Apr 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant