Improve support for TinyG / g2core

[breiler]

Feature request

Improve the support for TinyG and g2core by adding or improve the support for:

• Streaming file, pausing and stopping
• Status report for machine coordinates
• Status report for work coordinates
• Handling gcode states
• Jogging
• Homing
• Firmware settings

[justinclift]

Ahhh, just came here to report "I can't seem to enable homing". Turns out it's a known thing. 😉

For me in testing now, using firmware version 101.03 (our latest edge build), and the nightly build downloaded just now (using CentOS 7 x64):

• Jogging is working
• Pause/resume is working
• Stopping works too
• Streaming a file seems to be working (did it with the motors off, and it's still running atm).

Homing works if done via the "Command" line (eg G28.2 Z0 X0 Y0), and the XYZ co-ordinates are correctly set when the homing operation completes.

Noticed two bits of weirdness. One is probably just me 😉, while the other one might not be an issue or may need thinking about:

• "XY Step size" seems to be applied to Z movements too. That wasn't obvious until trying it out and hitting my Z limit switch. Should the title of that be "XYZ Step size" or is it expected to change the Z step size somewhere?
• Default feed rate (for me) was "10". That's super slow. With my Shapeoko 3 my normal feed rate is around 10-15k. I don't remember if the feedrate is much lower with the stock Shapeoko 3 board though, as I haven't used that in ages. It might well be.

Anyway, so far things look good. Nothing terrible is jumping out at me anyway. 😄

[justinclift]

Hmmm, noticing one thing that I'm not sure about. In the "Controller State (DRO)" Window, the line at the bottom looks like it's supposed to be the currently executing G-Code. That's not changing for me atm, even though a file is being streamed. The feed rate value and XYZ coordinates are changing dynamically though.

Should I take a screenshot and add it here?

[justinclift]

#1075 updates the Help info to be more controller agnostic too. Probably useful. 😄

[justinclift]

The file I was streaming (with motors off) finished successfully from the UGS perspective just now, so looks like that's good too. 😄

[justinclift]

In the "Controller State (DRO)" Window, the line at the bottom looks like it's supposed to be the currently executing G-Code.

Ahhh, ignore that. Just realised that's the "gcode state" mentioned in the welcome page tab. No worries. 😄

[breiler]

"XY Step size" seems to be applied to Z movements too. That wasn't obvious until trying it out and hitting my Z limit switch. Should the title of that be "XYZ Step size" or is it expected to change the Z step size somewhere?

This is my "fault". I created a new plugin for jogging that would scale better in the UI and provide continuous jogging (you can find it under Window -> Plugins -> Jog controller). I didn't want to mess with the existing working module. To save space in the new plugin I decided we could use the same step size for XY and Z as default with the possibility to activate separate:

Default feed rate (for me) was "10". That's super slow. With my Shapeoko 3 my normal feed rate is around 10-15k. I don't remember if the feedrate is much lower with the stock Shapeoko 3 board though, as I haven't used that in ages. It might well be.

That is correct, it's the default. 😃

[justinclift]

Nifty, thanks. 😄

[justinclift]

Out of curiosity, is support for ABC (etc) axes in the forseeable future?

Just kind of thinking that might be useful, as it's one of the strengths of g2core compared to GRBL.

[winder]

That's a work in progress hopefully I can keep finding time to work on it: #1068 (comment)

[justinclift]

Ooooo Aaaaaa! Very nifty @winder. 😄

I hadn't come across the grbl-Mega-5X project before either. Looks like several microcontroller based systems are starting to bring "5 axes" to the general public then. Hopefully at least one breaks through to getting it "mainstream". 😄

[justinclift]

[continuing a conversation from related #1072]

@scotthz With the testing I'm doing, that's been with 101.03 as well. I'm not a java person either, so my knowledge of exactly what's needed is probably a bit iffy too.

The "UGS Platform" nightly build is the one I've tested. After unpacking the .zip, I changed into the ugsplatform/bin directory then launched ./ugsplatform. That "just worked", so I didn't need to muck around with any switches or similar to get it started. This is on my CentOS 7 x64 desktop, using the OS provided OpenJDK v8:

• java-1.8.0-openjdk-1.8.0.171-8.b10.el7_5.x86_64
• java-1.8.0-openjdk-devel-1.8.0.171-8.b10.el7_5.x86_64
• java-1.8.0-openjdk-headless-1.8.0.171-8.b10.el7_5.x86_64

Those java packages were already installed on my desktop, but I'm not sure if that's because they're standard things or because some other previous thing I've used needed them.

Not sure how it'll all go on a Pi with Raspbian, but hoping it's ok. 😄

[scotthz]

In a nutshell, my experience was pretty much same as your own, @justinclift . I ran it on a Pi 3, because generally, that's what's attached to my machine, but I expect it would be the same running natively on my mac laptop.

I say "natively" because I tried to run it as a remote X11 client, with UGS running on the Pi and the UI running on my laptop, but that wasn't a lot of fun. It sort of works, but UGS doesn't appear to target this use case, and macOS isn't a great host for X11 clients in general. It makes the UI very slow and not suitable for a system that targets a realtime motion system.

Being able to separate the UI from the "engine" is a key feature for me. This draws me to options like CNC.js, FabMo, and Chilipeppr. I'm ambivalent about Chilipepper. Some good ideas, but so javascript-centric that it's not all that fun if you're not already in that world. CNC.js has some of the same downside, but not as bad and I find it a lot more usable. FabMo seems to be a great idea, but too focused on ShopBot and/or too little interest in other platforms to seed much of a non-ShopBot community.

I am sure that UGS is pretty awesome for the GRBL world, but I am committed to G2, so for now, UGS is not compelling enough for me to want to use it given that it requires an attached computer, Pi or laptop, for the UI. Maybe when more of the basics are functional, like homing, WCS configuration, etc. I'd like to play more with the visualizer and other UI elements at that time.

[breiler]

Thanks for giving this a try @scotthz, and you are right that running UGS like this is maybe not the primary use case. I'll keep working on the other base functions.

[justinclift]

@scotthz Cool, thanks for giving it a go too. 😄

Sounds like for the "remote X" use case the hmmm... G-Code sending bit of UGS would need to be decoupled from the UI updating bit, to make sure the sending doesn't block. No idea personally how much effort that would take. 😄

With the various G-Code senders, so far I've had good results with CNCjs (mostly "just works" for me), haven't yet tried FabMo (sounds complicated to set up), and I've never had the Chilipeppr UI actually load properly.

With Chilipeppr, my guess is it's because it apparently relies on Google services, and I use adblockers (UBlock Origin) which I'm not willing to make exceptions for. Also, my use case is mainly targeted to doing things "off line", and Chilipeppr seems to be targeted for online only use. Not my cup of tea. 🙄

UGS looks like it'd be useful as-is already for people who don't need homing (eg no limit switches installed on their machine). For me, I think I'll continue to try it out and see how it develops over time, and also keep using CNCjs as well. 😄

[winder]

Thanks for the feedback.

The remote use case definitely isn’t a supported one. That said there is a web pendant that can be launched for remote access without sending the entire application. The “classic” UI is much lighter than the platform and may work better with that sort of configuration.

@scotthz Regarding the missing features, UGS has a controller abstraction layer so it is mainly a matter of implementing the missing features according to TinyG requirements. No feature in UGS is GRBL-Specific. Assuming the core TinyG operations work and people are interested, the remaining features are largely a matter of filling in the blanks. This includes the advanced widgest like probing and the configuration wizard.

[justinclift]

For the filling in the blanks... does that mean things like the homing cycle are just a matter of making a PR with (say) something like:

sendCommandImmediately(new GcodeCommand("G28.2 Z0 X0 Y0"));

... in the right place?

[winder]

Exactly

…

On Tue, Jul 10, 2018 at 8:51 AM Justin Clift ***@***.***> wrote: For the filling in the blanks... does that mean things like the homing cycle are just a matter of making a PR with (say) something like? sendCommandImmediately(new GcodeCommand("G28.2 Z0 X0 Y0")); — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1071 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHqRZ9gyN7F1t41_uoRodiF-FDUezjCks5uFKNIgaJpZM4U_zxn> .

[justinclift]

Cool #1076 created.

Completely untested. The G-Code itself is correct for XYZ homing though. 😉

[breiler]

I didn't want to add stuff that I couldn't properly try out for my self but I made the exact same code change (+ one extra line) that you made but got this error while trying it out and i didn't have time to look into it:

{"r":{"msg":"Z axis Homing Err - Homing input is misconfigured"},"f":[1,240,1]}

[justinclift]

Ahhh, that just means your g2core settings aren't yet set up correctly. It's saying that it'd really like to do the homing thing, but isn't sure which digital inputs are used for each of your limit switches.

When you have a few minutes spare to look again, you're welcome to ping me and I can walk you through it if that helps. 😄

[justinclift]

As a thought, this might be a useful reference to look at:

• justinclift/g2@ca4e95d

They're the settings I use for my Shapeoko 3, which has X, Y, and Z limit switches.

Note the #define Z_HOMING_INPUT 6 change on line 159. Complete guess, but that's probably the kind of thing you'll need to change as well.

[breiler]

Thanks!

I'm currently working on getting the gcode states working, such as which coordinate systems is in use. And I couldn't get the "plan" attribute to be returned. Once I activated it using {sr:{... plan:t}} it's now working properly. This will also help getting WCS working.

[justinclift]

Excellent. 😄

[justinclift]

Just gave the most recent nightly builds (both Classic and Platform) a go - with the recently merged homing code - on my 3-axis g2core converted Shapeoko 3.

Works perfectly (for me). Excellent. 😄

Haven't tried cutting anything yet (it's too late at night, neighbours would be very unhappy), but probably will tomorrow. Not expecting any weirdness, but if I do hit anything I'll file an appropriate bug report. 😄

[justinclift]

Ahhh, just found one weirdness. Not sure if it's TinyG specific, though guessing it might be.

With the "UGS Platform" nightly, in the "State" tab there is a drop down for Units.

I clicked on it (just to see what happens) and chose "Inches (G20)" - Note, I'm a mm guy, I was just experimenting. The UI seems to hmm... get stuck?

"Get stuck" is probably not the correct term. In the "Controller State (DRO)" tab the status changes from "IDLE" to "RUN", and never leaves it. The fields in the State tab are greyed out meanwhile (eg permanently).

It's possible to click the Stop button in the toolbar, which seems to cancel the change properly.

Looking in the Console tab, a G20 was clearly sent and accepted. I'm guessing here, but maybe the code to handle the return status from g2core isn't in place (yet) for changes driven by the "State" tab?

Should I file a separate issue for this?

[breiler]

No you don't need to file a report. A fix is coming, it's just waiting on a code review. 😃
Thanks for testing, soon you'll be able to use work coordinates as well.

[justinclift]

Ahhh, and now I notice #1078 exists. Cool. 😄

[justinclift]

This is my "fault". I created a new plugin for jogging that would scale better in the UI and provide continuous jogging (you can find it under Window -> Plugins -> Jog controller). I didn't want to mess with the existing working module.

Your new jogging plugin seems pretty good, and an improvement over the existing default one.

Is there any chance of getting that enabled by default for new users? Preferably with the separate XY/Z step enabled too, but that step thing might just be me. Not sure if people using GRBL commonly keep the step sizes the same or not. 😄

[justinclift]

And now I found a bug in it. Can't seem to change the feed rate from 10k by typing a new number in. eg Typing 5000 then pressing enter ... the number goes straight back to 10,000.

Doing the same in the old controller works.

Should I create a new Issue for this?

[breiler]

Fixed the feed rate limit: #1088
Added issue to make the new jog module the default: #1089

[breiler]

The last piece to make a tinyg/g2core controller operable in UGS is in place. It now provides a small gui for handling firmware settings.

There are still empty method implementations in TinyGFirmwareSettings that are used by the setup wizard. I'm going to open a new issue for these as it requires a bit refactoring to support the vast configurability in TinyG.

[justinclift]

Excellent @breiler!

I'll give the new nightly build tomorrow a go then too, and report success/failure bits as appropriate. 😄

[breiler]

Closing this, start a new issue if problems occur.