Set location in API

[ryansturmer]

Even though a g-code exists for this (G28.3) I think an API function to set an axis location manually to a specific coordinate should exist, and convenience helper functions should exist for it in fabmo.js

[gordonab]

Are G54 to G59 implemented in G2? These allow setting X,Y,Z,A,B&C to a specified location. It works almost exactly as the VA command in OpenSBP.

[ryansturmer]

G54 to G59 are actually for setting "work offsets" (which are localized coordinate frames relative to the "absolute machine coordinate system") - You can use those to set a sort of virtual offset for each axis, or you can use the G28.3 command to change the actual absolute machine coordinates. - The effect is the same, in most cases.

In either case, what I'm proposing here is that the API expose this functionality (and use one G-Code or the other or some combination of both under the covers) - just for convenience sake.

[aldenhart]

You are both correct. G28.3 is for setting the absolute coordinate system to an arbitrary point. This is useful for un-indexed rotary axes, and for infinite axes like the Y bed on the Othercutter (pinch rollers)

[gordonab]

Looks like once we've set the parameters for each axis G28.2 will take care of touching off the switches, back off and then set the home position for the machine. This sounds great for setting the machine coordinate system. This will be critical for setting up a machine with a tool changer or returning back to the machine coordinate system once you're done using a offset home position.

Won't using G28.3 change this machine home position? The only type of axis I see this would be safe to use on would be a rotary axis or similar.

Ryan, were you originally referring to setting the absolute machine position home to an abitrary position not associated with the homing switch or a need for a offset home position that a user would set manually as a reference home for running files? Say, if they were cutting a file at a specific location on a sheet that isn't the home corner or if they had a file that was output to the center of a blank or even to a fixture at an arbitrary location on the table. In the g-codes purest form a G10 command would be used to set the origin of this coordinate system. My understanding from the NIST specification is that this command takes an offset value and applies it to the designated axis/axes that are being changed and applies them to a work coordinate system.

Sorry if I seem a little dense. I'm just trying to get a good feel for the scope of your request and the depth of the helper functions that may be needed.

On Mon, Jul 7, 2014 at 6:32 AM, Alden Hart notifications@github.com wrote:

You are both correct. G28.3 is for setting the absolute coordinate system to an arbitrary point. This is useful for un-indexed rotary axes, and for infinite axes like the Y bed on the Othercutter (pinch rollers)

— Reply to this email directly or view it on GitHub https://github.com/ShopBotTools/FabMo-Engine/issues/13#issuecomment-48163086 .

Gordon Bergfors

Wake Forest, NC

[ryansturmer]

There are a couple of use cases here, that can use a couple of different combinations of G28.2, G28.3, and the G54 to G59 commands. What I'm proposing is providing convenience wrappers in the FabMo API for some or all of them, or an alternative tactic for communicating complex operations that involve both the reconfiguration of G2 and the execution of g-code commands.

Use Case 1: Absolute Machine Origin This is where we want to touch off the prox switches, and find the absolute bounds of the machine, and set that to 0. This can be acheived with a single G28.2 X0 Y0 Z0 (A0 B0 C0) command and nothing else, so long as the tool is configured with the proper limit settings.

Use Case 2: Touching off the z-zero plate Here we want to use the homing plate to find the working surface and set the location of that surface to Z=0 If the tool is configured with the limit settings for Use Case 1 listed above, it actually has to be re-configured (using JSON commands to G2) to approach the zero plate in the correct direction, and use the right values for jerk, speed, and backoff, before issuing a G28.2. Once the tool finds home by touching off the plate, per the G28.2 routine, it will have set the surface of the plate to be Z=0, which is not the intended behavior. A follow-up G54-59 command (or G28.3) command is required to set the Z location to account for the offset introduced by the thickness of the plate.

(There are probably other use cases when you get into customized tools, rotary axes, ATC, etc, but let's stick with the basics)

There are a few ways to tackle this.

1. Make homing (or use case 2, which the synthetos team calls "probing" but shopbot has always called "homing") a high level function of the API, and let it do the reconfiguring of the tool behind the scenes. The homing function call would simply take arguments such as speed, direction, backoff, and final offset, and the appropriate configuration would be loaded into G2 before the G28.2 was issued, and the appropriate coordinates set once homing was complete.
2. OR provide a way of sending a "hybrid program" that includes reconfiguration JSON commands intermixed with G-Codes. This way the "homing routine" is simply a custom program file (just as it is in shopbot with say, the 'C2' command) that can be edited and made to fit.

I think ideally, long-term, G2 might support homing and probing seamlessly, using only G-Code commands, although handling the usability stuff in the FabMo engine for now is exactly what it is designed for.

FWIW, homing and probing works currently on the latest version of the engine and firmware, these distinctions are more philosophical, and are aimed at streamlining the API and providing convenience for developers, not enabling basic functionality.

[aldenhart]

I would recommend using the probe function for touch-off. See G38.2 code. Touch off should not re-home the machine. The machine coordinates are the machine coordinates. All else is offsets (G10 L2s). When the probe has found it's mark you use the coordinates of the system to set offsets in the G55 (or higher) coordinate system.

By convention people reserve the G54 coordinate system for absolute coordinates (all offsets = 0). This way moves in absolute coordinates can be persistent, unlike using a G53 which is only good for that move and needs to be repeated on each line. They you can use G55 for you user-reference coord system (or any of the others up to G59).

Preserving absolute coords (and not using G28.3 for anything) allows you to use G28.1 and G30.1 as tool changer locations and things like that. That's all out the window if you reset the machine coords to the work.

[ryansturmer]

Is G38.2 implemented? Is there documentation for it, or is that something I can help generate?

[aldenhart]

Yes, it is implemented, no it is not yet documented. The file is cycle_probing.cpp

Technically it's a G38.3, which is a probe that does not signal an error if contact is not made. I aim to fix that sometime.

Love for any help on the wiki documentation. You may also want tot look at the cycle_jogging. Tom at Other Machine is working on this, or has in the past.

[ryansturmer]

I will happily contribute to the documentation - this is also possibly something @gordonab could look into, since C/C++ is one of his strengths.

[ryansturmer]

G38.2 works with some finesse in our version (some of these functions were commented out)

I get unexpected behavior however if I do a probe operation followed immediately by another g-code.... the probe operation appears to leave the system in the COMBINED_HOLD state and does not continue executing codes in the queue until provoked. It's possible that this is intended behavior.

@aldenhart - my intent is to run this probe routine, and follow it up with a G55 and then a backoff move (since the probe operation doesn't backoff on its own) - can you explain the steps in the sequence for that? (How to use the G55) - Im not getting the behavior i expect

[ryansturmer]

@aldenhart Also - if I document the probe function - where should that go, the tinyg wiki, or in the G2 tree somewhere?

[aldenhart]

Ryan - I'll look into that command sequence. Probing may need to be filled out a bit. In particular moving the existing behavior to G38.3 and adding G38.2 that returns an error if the limit is not reached (for adherence to Gcode standards).

Here's the place to document the probing operation. This is on the TinyG wiki, but once the code bases merge it will all be on the TinyG wiki. Or we'll move it all. Not sure yet. https://github.com/synthetos/TinyG/wiki/Probing-Description-and-Operation

You can use this page for reference and for a convenient place to grab table formatting and other useful things: https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation

Table formatting is tricky in that you have to enter a tab before things. I can't seem to do this from my keyboard (mac) so I just copy and paste from an earlier table. Which raises the interesting question about where the first one came from....

[gordonab]

Alden-

Back to to understanding the G2 coordinate system configuration. Is there a way to query G2 for the offsets between the base coordinate system (G54) and the work coordinate system (say, G55)?

Also, would you clarify that G2 uses G10 L2 P1 as the base coordinate system and not G10 L2 P0. Does this mean that G28.3 only affects G54?

Would you explain G28.1 a little further and how it works?

Thanks, Gordon

On Tue, Jul 8, 2014 at 5:50 AM, Alden Hart notifications@github.com wrote:

Ryan - I'll look into that command sequence. Probing may need to be filled out a bit. In particular moving the existing behavior to G38.3 and adding G38.2 that returns an error if the limit is not reached (for adherence to Gcode standards).

Here's the place to document the probing operation. This is on the TinyG wiki, but once the code bases merge it will all be on the TinyG wiki. Or we'll move it all. Not sure yet. https://github.com/synthetos/TinyG/wiki/Probing-Description-and-Operation

You can use this page for reference and for a convenient place to grab table formatting and other useful things: https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation

Table formatting is tricky in that you have to enter a tab before things. I can't seem to do this from my keyboard (mac) so I just copy and paste from an earlier table. Which raises the interesting question about where the first one came from....

— Reply to this email directly or view it on GitHub https://github.com/ShopBotTools/FabMo-Engine/issues/13#issuecomment-48292400 .

Gordon Bergfors

Wake Forest, NC

[gordonab]

Hi Alden,

I think I'm getting this.

Is G28.1 the same as G10 L2 P1 X0 Y0 Z0...?

Is it a safe assumption that when a G28.1 is issued the coordinate system is returned to using the base coordinate system (G54)?

Does G30 refer to the offsets in G55? Does G30.1 record the current offset from G54 into G55?

Here is an example of how a ShopBotter would currently use these commands:

G28.2 // C3 (ShopBot command) 'Home the tool using the prox switches at the front left corner of the machine G0 X48 Y24 Z0 //J2,48,24 'Jog to the center of the table G30.1 // Z3 'Zero X, Y & Z work offset (screen reads 0,0,0) ... //Do some operations G54 M6 //to change tool G55 //return to user defined work coordinates

G28 Z1 // 'Jog to the machine home (front left corner of the machine) to return the machine to the machine coordinate system

Am I getting this correct?

Now that the machine has jogged back to the machine 0,0 is G2 operating using the G54 coordinate system?

Thanks,

Gordon

On Fri, Jul 11, 2014 at 11:28 AM, Gordon Bergfors gordonab@gmail.com wrote:

Alden-

Back to to understanding the G2 coordinate system configuration. Is there a way to query G2 for the offsets between the base coordinate system (G54) and the work coordinate system (say, G55)?

Also, would you clarify that G2 uses G10 L2 P1 as the base coordinate system and not G10 L2 P0. Does this mean that G28.3 only affects G54?

Would you explain G28.1 a little further and how it works?

Thanks, Gordon

On Tue, Jul 8, 2014 at 5:50 AM, Alden Hart notifications@github.com wrote:

Ryan - I'll look into that command sequence. Probing may need to be filled out a bit. In particular moving the existing behavior to G38.3 and adding G38.2 that returns an error if the limit is not reached (for adherence to Gcode standards).

Here's the place to document the probing operation. This is on the TinyG wiki, but once the code bases merge it will all be on the TinyG wiki. Or we'll move it all. Not sure yet. https://github.com/synthetos/TinyG/wiki/Probing-Description-and-Operation

You can use this page for reference and for a convenient place to grab table formatting and other useful things: https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation

Table formatting is tricky in that you have to enter a tab before things. I can't seem to do this from my keyboard (mac) so I just copy and paste from an earlier table. Which raises the interesting question about where the first one came from....

— Reply to this email directly or view it on GitHub https://github.com/ShopBotTools/FabMo-Engine/issues/13#issuecomment-48292400 .

Gordon Bergfors

Wake Forest, NC

Gordon Bergfors

Wake Forest, NC

[aldenhart]

Almost, but there are some differences. G28.1 is not the same as G10 L2 P1 X0 Y0 Z0. Let me walk through the coordinate systems first then come back to G28.1 and G30.1 which are special cases.

I think the best way to do this is to put it on the TinyG wiki and refer to it, as this will likely be a rather lengthy text. I'll report back when I have it done - hopefully some time this evening. Hey, it's Friday in the burbs.

[aldenhart]

I've started this page to better explain coordinate systems and their use: https://github.com/synthetos/TinyG/wiki/Coordinate-Systems