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

Added support for gcode states and work coordinates #1078

Merged
merged 14 commits into from
Jul 16, 2018

Conversation

breiler
Copy link
Collaborator

@breiler breiler commented Jul 11, 2018

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

@codecov-io
Copy link

codecov-io commented Jul 11, 2018

Codecov Report

Merging #1078 into master will increase coverage by 0.5%.
The diff coverage is 73.52%.

Impacted file tree graph

@@             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
Impacted Files Coverage Δ Complexity Δ
...iversalgcodesender/model/WorkCoordinateSystem.java 100% <100%> (+100%) 9 <7> (+9) ⬆️
...llwinder/universalgcodesender/TinyGController.java 53.9% <58.33%> (+1.34%) 25 <1> (ø) ⬇️
...om/willwinder/universalgcodesender/TinyGUtils.java 71.65% <69.44%> (+8.27%) 42 <18> (+17) ⬆️
...inder/universalgcodesender/AbstractController.java 60.97% <0%> (+0.24%) 95% <0%> (+1%) ⬆️
...ersalgcodesender/gcode/GcodePreprocessorUtils.java 78.21% <0%> (+0.38%) 92% <0%> (+1%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update afde061...9395392. Read the comment docs.

axis.name() + Utils.formatter.format(coordinate);
}

private static int convertOffsetGcodeToCode(Code offsetGcode) {
Copy link
Owner

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();

Copy link
Owner

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) {
Copy link
Owner

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

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.

Copy link
Owner

@winder winder left a 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.

@breiler
Copy link
Collaborator Author

breiler commented Jul 12, 2018

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!

Copy link
Owner

@winder winder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 👍

@breiler
Copy link
Collaborator Author

breiler commented Jul 12, 2018

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

@winder
Copy link
Owner

winder commented Jul 12, 2018

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.

@breiler
Copy link
Collaborator Author

breiler commented Jul 12, 2018

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.
@breiler
Copy link
Collaborator Author

breiler commented Jul 13, 2018

There was a bit back and forth with this, but I'm starting to feel satisfied.
Does this work for you @winder?

@Override
public void performHomingCycle() throws Exception {
sendCommandImmediately(new GcodeCommand("G28.2 Z0 X0 Y0"));
sendCommandImmediately(new GcodeCommand("G28.2 X0 Y0 Z0"));
Copy link
Contributor

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.

Copy link
Collaborator Author

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries at all. 😄

@winder
Copy link
Owner

winder commented Jul 16, 2018

@breiler looks good to me!

@breiler breiler merged commit e159183 into winder:master Jul 16, 2018
@justinclift
Copy link
Contributor

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? 😄

@breiler
Copy link
Collaborator Author

breiler commented Jul 17, 2018

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.

@justinclift
Copy link
Contributor

Ahhh, good point. Yeah, that's probably the thing I'm hitting. I'll drop back to 100.26, and see how that goes. 😄

@justinclift
Copy link
Contributor

Yep, 100.26 is working properly. Thanks @breiler. 😄

@justinclift
Copy link
Contributor

justinclift commented Jul 17, 2018

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?

@justinclift
Copy link
Contributor

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.

@breiler
Copy link
Collaborator Author

breiler commented Jul 18, 2018

Hmm, I'm not able to reproduce this. The common actions panel checks if the controller has homing by its capabilities:

boolean hasHoming = backend.isConnected() && backend.getController().getCapabilities().hasHoming();

The capability is populated when connecting to the TinyG/g2core controller:

capabilities.addCapability(CapabilitiesConstants.HOMING);

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.

@justinclift
Copy link
Contributor

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

@justinclift
Copy link
Contributor

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):

dscn0130_v1

And when mounted (the one on the right). The one on the left was yesterday's work, done in 0.75mm aluminium:

dscn0134

UGS seems to be working pretty well for this already. 😄

@breiler
Copy link
Collaborator Author

breiler commented Jul 19, 2018

This is awesome, thanks for showing this! 😃

@justinclift
Copy link
Contributor

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

MHQH19B full height brackets

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.

4 participants