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

[Feature Request] send gcode #66

Closed
goscicki opened this issue Apr 11, 2019 · 20 comments
Closed

[Feature Request] send gcode #66

goscicki opened this issue Apr 11, 2019 · 20 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@goscicki
Copy link

I think it would be helpful to be able to send gcode commands. For example /systemcommand gcode/M303.

@cameroncros
Copy link
Owner

I have considered this before, but it is a very dangerous ability to open up to discord. A bad user could either accidentally or intentionally burn down your printer/house. Once the proper access controls are in, I'm happy to consider it, but I still feel a bit uncomfortable about it

@goscicki
Copy link
Author

Yeah, that makes sense. Couldn't your plugin simply filter gcode for safety? The only things that can be dangerous would be heating commands like "M104 S999". Even then the firmware should block anything above its safe limit. It's not like someone could flash dangerous firmware with gcode. You could make the plugin refuse anything above "M104 S250" or so. (also M109, M140, M190)

@goscicki
Copy link
Author

Or even just block heating commands if you have to.

@cameroncros
Copy link
Owner

Even move commands could be dangerous to your printer, or anyone using the printer (repeatedly slam the motor into an axis until it breaks, move the bed or hot end rapidly while someone us pulling their print off, etc). I don't want to be responsible for maintaining the list of "unsafe" commands. (if I go through with it, I would be more inclined to make the gcode commands a whitelist the user has to fill in)

@cameroncros
Copy link
Owner

Plunging into the object mid print is also a fire risk

@goscicki
Copy link
Author

I understand. I like the whitelist idea.

@cameroncros
Copy link
Owner

Okay, well, i will see if I can implement this, but I am particularly busy atm, so it might take some time.

@cameroncros cameroncros added good first issue Good for newcomers help wanted Extra attention is needed labels Apr 11, 2019
@goscicki
Copy link
Author

Ok, that's fine. I appreciate that you even responded. Thanks!

@goscicki goscicki changed the title [Feature Request] [Feature Request] send gcode Apr 11, 2019
@goscicki
Copy link
Author

goscicki commented Apr 21, 2019

I have been testing this (DR-66) today and it seems great! My only suggestion would be to make the gcode non case sensitive.
The same goes for file names in the /print command. It is a pain printing files with lots of uppercase from my phone.

@cameroncros
Copy link
Owner

cameroncros commented Apr 21, 2019

Thanks for testing!!, case insensitivity should be easy enough.

  • case insensitivity for matching valid gcodes

I'll add a new issue ticket for /print case insensitivity, that could be a bit harder

@cameroncros cameroncros mentioned this issue Apr 21, 2019
@goscicki
Copy link
Author

I have been testing the case insensitivity today. It accepts lower-case gcode now, but the printer still only responds if it is upper-case. Perhaps it still needs to be converted to upper-case before sending it. I believe Marlin only accepts upper-case gcode. (The OctoPrint terminal converts it to upper-case.)

@cameroncros
Copy link
Owner

That would make sense, I will convert it to upper before sending then

@goscicki
Copy link
Author

Awesome! It works great now. Thank you so much for all your hard work.

@cameroncros
Copy link
Owner

No problem, thanks for your help testing it. I will release it in the next few days.

@goscicki
Copy link
Author

I just noticed this doesn't seem to work with "gcode system commands" plugin that allows OctoPrint to respond to custom gcode like OCTO0, OCTO1 etc. despite having them in the whitelist.

@cameroncros
Copy link
Owner

Yep, according to the gcode specification, only G and M are valid codes. So I intentionally ignored other gcodes. I'll change it to be more open.

@cameroncros cameroncros reopened this Apr 28, 2019
cameroncros added a commit that referenced this issue Apr 28, 2019
@cameroncros
Copy link
Owner

Fixed. And released.

@goscicki
Copy link
Author

Thank you so much!

@goscicki
Copy link
Author

goscicki commented Apr 29, 2019

This works great in the DR-66 branch. It doesn't seem to work on the master release though. Is it not merged? I love the new granular permissions by the way!

@cameroncros
Copy link
Owner

Yup, somehow didnt merge DR-66 in properly. Will fix and re-release

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants