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

When switching jog units from in/mm, convert feed rate and step size units too #1010

Closed
RecceDG opened this issue Apr 16, 2018 · 3 comments
Closed
Assignees

Comments

@RecceDG
Copy link

RecceDG commented Apr 16, 2018

So it turns out that if you have the Z axis step size set to 5mm, then press the UI button to set units to "inches", then jog Z+ one step, you get a 5 INCH jog.

Flipping that switch should also convert the jog sizes and feed rates so that actual jog travel/rate remains constant after a units switch.

@breiler
Copy link
Collaborator

breiler commented Aug 5, 2018

@winder the changes I've made may not have been optimal and I need your input on how to proceed.

I thought that it would be a good idea to have the controller return coordinates in any unit it liked and then have the GUI convert it to the user preferences. I think that this is working pretty well in my tests:

  • I can toggle MM/Inches as the preferred units in the jog panel and it also changes the units in the DRO.
  • I can change the G20/G21 without having the units changed in the GUI (I figured that this is only interesting when the data is sent to the controller not how things should be displayed, so it shouldn't affect the presentation)
  • I can change the setting $13 without it messing with GUI presentation of the coordinates (I figured that this is a setting for how the controller is reporting it's units and shouldn't be used for the presentation).

As far as for the coordinates I think this works. But with the feed rate there is no gcode state telling me the unit for the speed. I can think of one way to solve this by having a special data type for speeds that also includes the unit "mm/min" or "inch/min". Then the controller implementation should be responsible for setting these unit types when returning the speed (In GRBL we could use the setting $13 and in TinyG it's reported in the status report).

I did notice a bug in the visualiser for the machine boundaries (soft limits) when changing the $13 to inches. To fix this the coordinates sent to the visualiser module needs what units they are in. I'll look into this later.

@winder
Copy link
Owner

winder commented Aug 5, 2018

Lots of people have wanted this feature for a long time, I've always left it to the Controller and pretty much ignored the problem in UGS (as you're finding).

  • I can toggle MM/Inches as the preferred units in the jog panel and it also changes the units in the DRO.
  • I can change the G20/G21 without having the units changed in the GUI (I figured that this is only interesting when the data is sent to the controller not how things should be displayed, so it shouldn't affect the presentation)
  • I can change the setting $13 without it messing with GUI presentation of the coordinates (I figured that this is a setting for how the controller is reporting it's units and shouldn't be used for the presentation).

These all sound good to me, exactly what I would hope. I think it limits any assumptions the UI needs to make about the controller.

I didn't realize that GRBL uses $13 for the feeds... hmm. That is tricky.

I'm not sure we need a special type for this one since it should change so rarely.

The Visualizer doesn't do anything with the feeds other than scaling them up/down by a percentage, so there shouldn't be anything to worry about there.

Maybe a speedUnits field could be added to ControllerStatus? In GRBL it could be passed in the getStatusFromStatusString method in the same way as getReportingUnits. TinyG could add it there as well since it is already part of it's standard status report. Now it would be available in backend.getController().getControllerStatus() for JogService to check when scaling the values. Alternatively, it's probably fine to cache it in the Settings object as well since it should rarely change. That would make it a bit easier to access directly, and on startup, like getPreferredUnits.

@breiler
Copy link
Collaborator

breiler commented Aug 5, 2018

The jog command needs to be splitted in the tinyg-implementation according to synthetos/g2#374

@breiler breiler self-assigned this Aug 6, 2018
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

No branches or pull requests

3 participants