-
-
Notifications
You must be signed in to change notification settings - Fork 766
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
Added support for gcode states and work coordinates #1078
Conversation
…ort for changing work coordinates.
…ender into feature/tinyg Conflicts: ugs-core/src/com/willwinder/universalgcodesender/TinyGController.java
Codecov Report
@@ Coverage Diff @@
## master #1078 +/- ##
===========================================
+ Coverage 30.09% 30.59% +0.5%
- Complexity 1087 1115 +28
===========================================
Files 153 153
Lines 10431 10502 +71
Branches 943 963 +20
===========================================
+ Hits 3139 3213 +74
+ Misses 6989 6978 -11
- Partials 303 311 +8
Continue to review full report at Codecov.
|
axis.name() + Utils.formatter.format(coordinate); | ||
} | ||
|
||
private static int convertOffsetGcodeToCode(Code offsetGcode) { |
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.
This could go right into GcodeUtils.java, maybe even some of the other WCS helpers you have here as well. There is also WorkCoordinateSystem.java, so something like this might technically work:
WorkCoordinateSystem.valueOf(offsetGcode.toString()).getPValue();
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'd probably lean towards keeping your static method and maybe getting rid of WorkCoordinateSystem
* @param controller the controller to update | ||
* @param response the response to parse the gcode state from | ||
*/ | ||
public static void updateGcodeState(TinyGController controller, JsonObject response) { |
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.
Not a big fan of the side effects in here, is there any reason why this can't be merged with the code updating the ControllerStatus
? You could check with getCurrentParserState
to get the state.
The GRBL version could be updated to use getCurrentParserState
instead of GrblFeedbackMessage
. The second line here literally sends the grbl $G
output to the gcode parser to make sure it is up to date:
else if (GrblUtils.isGrblFeedbackMessage(response, capabilities)) {
GrblFeedbackMessage grblFeedbackMessage = new GrblFeedbackMessage(response);
// Convert feedback message to raw commands to update modal state.
this.updateParserModalState(new GcodeCommand(GrblUtils.parseFeedbackMessage(response, capabilities)));
this.verboseMessageForConsole(grblFeedbackMessage.toString() + "\n");
setDistanceModeCode(grblFeedbackMessage.getDistanceMode());
setUnitsCode(grblFeedbackMessage.getUnits());
dispatchStateChange(COMM_IDLE);
}
GcodeCommand gcodeCommand = new GcodeCommand(gcode); | ||
super.updateParserModalState(gcodeCommand); | ||
} | ||
// This is handled by the rawResponseHandler |
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.
This calls parser.addCommand
which updates the on-the-fly GcodeParser, that may need to be called somewhere. I think my plan was to deprecate distanceModeCode / unitsCode in favor of the real gcode parser.
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.
The only critical feedback is to make sure the gcode parser stays up to date with the tinyg state responses. Some other minor feedback in addition to that.
It seems that I've been missing a key feature by not adding the parser. =) I figured that because the controller reports all state changes in the status report I don't need to parse the sent gcode. The way I'm updating the state felt a bit dodgy from the start so this clearly needs to be updated. I'll see what I can do! |
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.
Thanks 👍
Are you referring to the machine coordinates? Yes according to the documentation they are always in MM: https://github.com/synthetos/g2/wiki/Status-Reports |
This reverts commit b77ec1c.
Yes, maybe put a comment there. Looked strange since the other coordinates were in the current units. Those comments were made directly in a commit, I’m not sure why github didn’t show the context. |
…oring codacy warnings).
I noticed some problems with the distance mode parsing, need to test it further later. |
…ixes problem with parsing of gcode state for arc-distance mode.
There was a bit back and forth with this, but I'm starting to feel satisfied. |
…ing error messages
@Override | ||
public void performHomingCycle() throws Exception { | ||
sendCommandImmediately(new GcodeCommand("G28.2 Z0 X0 Y0")); | ||
sendCommandImmediately(new GcodeCommand("G28.2 X0 Y0 Z0")); |
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.
As a data point, this won't make any functional difference. The Z axis will be homed first anyway, as g2core regards that as being safer than homing it after the others.
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.
Sorry, this is from a bad merge. It's better having the Z probe first as it will reflect the correct order in g2core, will fix this soon!
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.
No worries at all. 😄
@breiler looks good to me! |
Just tried the newest build which according to the Jenkins job info includes this... and the state change bits don't seem to be working right. If I go to the State tab and change (say) the Units mode from G21 to G20, the "Controller state" (DRO) goes to "RUN" and keeps there. It doesn't seem to recognise that the state change has completed. I need to press the Cancel button in the toolbar to get the DRO back to IDLE. Is this expected? 😄 |
I had the same issue when running g2core 101.03 which doesn't report the correct status. I posted a bug report for this in synthetos/g2#367 I could create a timer that polls the status, but it felt wrong when g2core has this status report function. |
Ahhh, good point. Yeah, that's probably the thing I'm hitting. I'll drop back to 100.26, and see how that goes. 😄 |
Yep, 100.26 is working properly. Thanks @breiler. 😄 |
Found what seems like a bug in this, when testing today on a Win 7 x64 PC. Although the state change bit works, the "Home Machine" button is greyed out. Maybe another side effect of the bad merge? |
Oh that's weird. Now the "Home Machine" button isn't being greyed out. Same Win7 PC, but it's been restarted. For the past few hours (actually using UGS to cut stuff), I've been having to manually type G28.2 (etc) to home things. I'll keep an eye on this, and let you know if the homing button starts playing up again. |
Hmm, I'm not able to reproduce this. The common actions panel checks if the controller has homing by its capabilities: Line 114 in d071e25
The capability is populated when connecting to the TinyG/g2core controller: Universal-G-Code-Sender/ugs-core/src/com/willwinder/universalgcodesender/TinyGController.java Line 168 in d071e25
So this should work. =/ I've seen cases though when connecting to the controller the initialising commands can't be properly sent. The only way to resolve this is to disconnect the controller so that it can reboot and connect it again. |
Thanks @breiler. The PC it was connected to turned out to have some hardware problems, so took some time to rebuild it from the ground up. Just got it all together again and configured. This time UGS is showing the homing button. I've captured the contents of the initial UGS<->g2core exchange from the console to a text file, so if the homing problem does show up again I'll have something to compare against. Hopefully it was just a transient weirdness from the failing PC yesterday. 😄 |
Cutting stuff today, and no issues at all. Guess it really was some kind of weirdness from the failing PC. 😄 Just as a random data point, the stuff cut today was some PC expansion port brackets for network cards that came without them. This was today's (in 0.75mm steel): And when mounted (the one on the right). The one on the left was yesterday's work, done in 0.75mm aluminium: UGS seems to be working pretty well for this already. 😄 |
This is awesome, thanks for showing this! 😃 |
Todays ones, using the same UGS build. This looks to be a decent way to create full height brackets for cheapo Mellanox 10GbE network cards from Ebay that come with half height brackets only. 😄 |
Added support for handling gcode states from the responses of the controller. It's also now possible to set and handle work coordinates.
Further improvements for #1071
A small demo can be found here:
https://www.youtube.com/watch?v=_kmXCvtE1Pc