-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
a and b with origin_axis #110
Conversation
made some observations. we probably want to keep {original} in there. I don't think octoprint cares what comes after the position update message it recognizes... this is may be why you're not seeing any errors when adding A and B. I'm on the fence atm on how to handle this. |
the original message is retained in the response, but I have simply concatenated it after the rest of the response is generated: |
yeah, I think that would cover it.....
I'm still not sure if any of this even matters. octoprint is likely going to ignore A and B anyway. A way to test this would be to check the position update event and see what is coming in its payload. that's what this does behind the scenes. |
I have a couple free minutes so I can dabble:
That's this code after I moved x -50 / y -50 after homing:
See how octoprint emits z,x, y, e, f, and t? e is your extrusion rate, f is feedrate, and t is tool number. I'm going to dummy up this response to include A and B but my gut tells me Octoprint is going to ignore it. And we don't have to worry about it getting lost because it is still included in {original}. |
Yeah, this isn't good.
When I dummy up A and B, octoprint stops firing its PositionUpdate event. |
OK. Makes sense. So remove the A and B modifications to the response. Unfortunately, it was part of a larger commit, so I can't roll that one back, so it will have to be a corrective commit. I have also included A and B for the |
cleaned PR for a and b now in origin_axis