Implementing A-Axes

[cprezzi]

Since I have added an A-axes to grbl-LPC, we also need to add it to LW4 ;)

I did add a "Machine A Stage" toggle switch to the machine settings (corresponding to "Machine Z Stage") and included the A-axes in the DRO including Jog buttons (only shown if the "A Stage" is active).

Know, how do we want to show the A position on the workspace?

[cprezzi]

If A is a rotary axes, we could map A to X or Y (depending on axis orientation). What do you think? @openhardwarecoza @jorgerobles @tbfleming

[jorgerobles]

Good question. Should we put a flat compass overlay on a workspace corner? A position will rotate the compass. Could be an svg with css transform, no webgl required...

El 13 may. 2017 16:28, "Claudio Prezzi" notifications@github.com escribió:

Since I have added an A-axes to grbl-LPC, we also need to add it to LW4 ;)

I did add a "Machine A Stage" toggle switch to the machine settings (corresponding to "Machine Z Stage") and included the A-axes in the DRO including Jog buttons (only shown if the "A Stage" is active).

Know, how do we want to show the A position on the workspace?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/304, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYAfCcW2ttkBtAJLpx8D95QpPLFERks5r5b4JgaJpZM4NaFi2 .

[cprezzi]

The question is also, how we can show the gcode in the workspace?

[jorgerobles]

That's harder. @tbfleming?

El 13 may. 2017 4:37 p. m., "Claudio Prezzi" notifications@github.com escribió:

The question is also, how we can show the gcode in the workspace?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/304#issuecomment-301252298, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYHHiHbGLu2UM7iIVYbPgQ9eLXFRlks5r5cA1gaJpZM4NaFi2 .

[tbfleming]

Since I have added an A-axes to grbl-LPC, we also need to add it to LW4 ;)

I laughed when I read this. It implies that other firmware isn't worth it...

The question is also, how we can show the gcode in the workspace?

This gets tricky:

1. The gcode spec says A is parallel to X. Do we hold to that spec and prevent users from positioning A differently?
2. We need a way to specify where the A axis is, unless we fix it to Y=0, Z=0. If we fix it there, then we enter Y negative space. Do we drop the recommendation that X, Y shouldn't go negative?
3. An A axis move turns a line into a curve. Option 1A: we could do this conversion before WebGL, which is easy to implement, easy to explain, but can slow down execution and adds a new segment length config. Option 1B: draw curves on the GPU, which takes us further down the path of no one else understanding the WebGL code.
4. I used a Smoothie-specific approach on the CAM side which changes the A units from degrees to mm on the cylinder surface. We probably need to drop that approach and switch it to degrees.

[cprezzi]

@tbfleming You are right could be missunderstud ;) Was just meant that I am right in a flow...

[cprezzi]

1. It's hard to prevent users from doing anything if you don't stand by their side ;) but I would go with the gcode spec.
2. We already dropped this recommendation by adding the workspace origin offset. This makes absolute sense for milling, but A origin offsets are needed to be universal.
3. I'm a noob in this field.
4. Good question. What is the most usecase for a rotary axes? Projection of a 2d vector grafic to the surface of a zylinder? That could at least be a good starting point. It would clearly be nice to show the zylinder projection in the workspace, but an easyer solution could be to just take A as Y (flat).

[jorgerobles]

1.gcode spec

3. I would go for 1A for the moment. Adding a new segment length is not a big issue.
4. I should use the flat projection. If not, the cylinder has to be parametrized also.

:)

[tbfleming]

Flat projection means we won't have to deal with curves and segment length.

[jorgerobles]

Oh, I misread. Go for it :)

[tbfleming]

Did the easy part 1st. The preview now adds A to Y. This comes out right for the existing CAM, but the scale will be off once the CAM switches A to degrees.

[tbfleming]

Path CAM is now degrees. Untested.

[cprezzi]

Can we reatch it somehow, that the A to Y scaling is 1:1? I mean, if the document shows 100mm in Y, then also A shows 100mm in grid Y? How can I feedback the tool position? Could you add a A axis, or should I just feed A as Y?

[tbfleming]

We need to make a choice: do we scale A to Y in the gcode preview to match mm on a cylinder, or do we scale A to Y in the gcode preview to be degrees?

[cprezzi]

Good question. I think the first would lead to less questions from normal users, as this is what they expect when they engrave on a cylinder. Although the second would probably be correct from a proffesional gcode viewpoint (not sure).

[jorgerobles]

I would go for be easy for base user. Any professional guy should know what it's done and why (At least for a first approach)

[jorgerobles]

One noob question. If I got my roller at the middle of the bed, say Y100 of 200, how do I move it to that position, then start to engrave over the cylinder, and how is that represented in a easy to user way? I know using A is not noob task but I think is confusing right now isn't it? Indeed I made a roller a couple weeks ago, lying around and I'm dying to use it :D

[jorgerobles]

Should we use Y axis machine offset to begin A projection?

[cprezzi]

I see the process like this:

1. Jog to X/Y (/Z) origin of rotary axes (via Macro, if rotary axes has a fixed position).
2. SetZero
3. Start Job in X/A axis

With this process, the gcode should be in X+/A+ quadrant. The workspace origin (can/should) represent the rotary axis origin position (XY).

[tbfleming]

I've always been uneasy with shifting the grid. That screenshot reinforces my unease. gcode is in wpos so we should draw wpos.

[tbfleming]

Here's how shifting the grid is biting us:

• I'm using drawnY = gcodeY + gcodeA.
• To correct for the grid I'd have to change it to drawnY = gcodeY + gcodeA + correction.
• The correction shifts it so that when gcodeY=0 and gcodeA=0 it appears on the grid's Y=0.

i.e. the way to fix the problem is to abandon mpos.

[jorgerobles]

Many people don't have so abstract view and expect the workspace resemble their machine (a la reprap). Currently grid shifting is only visual :)

[tbfleming]

It is only visual, but look at the confusion it causes when you don't position the rotary at MPos Y=0.

[cprezzi]

@tbfleming You are kind of right. At the moment we mix wpos and mpos, as gcode relates to wco origin, but workspace has machine size!

[jorgerobles]

We are f***up already :rofl:

[tbfleming]

I'm starting to think of it this way:

• Users who understand mpos vs. wpos expect the grid to show wpos like other tools do.
• Users who don't understand mpos vs. wpos shouldn't ever monkey with mpos. They should drag the documents to the target position instead.

[cprezzi]

What if we read the real work offset from the machine and move the work origin (including gcode) on the workspace to that location? The workspace total size would stay like it is and represent the machine size. This would mean we just have to store additional work offsets in the workspace.

[jorgerobles]

That idea came to my mind a while ago when included machine offset setting... I don't remember right now the issue when had mentioned​.

[tbfleming]

What if we read the real work offset from the machine and move the work origin (including gcode) on the workspace to that location? The workspace total size would stay like it is and represent the machine size.

This would still throw off the rotary position.

How about this?

• Grid, documents, and gcode preview all show wpos
• Grid goes positive and negative in both X and Y
• Grid size setting is separate from machine size setting
• A new set of markers would indicate machine bounds. They would move when the work origin changes.

Screen mock up:

[tbfleming]

I didn't have negative area to work with when drawing that. Usually the lower-left marker would be at 0,0 or go into negative space.

[jorgerobles]

I think that should work lovely and will teach mpos and wpos easy.

[tbfleming]

Since the wpos origin would only affect the markers, it would be easy in the future to support machines where MPos 0,0 isn't the lower-left corner. Professional machines are often not like that, which is why GRBL isn't like that.

[tbfleming]

@cprezzi I'm getting "error: undefined" with Set Zero on grbl-lpc

[tbfleming]

I must be missing something. I got set zero to work, but it doesn't cause the grid to shift. I tried with both grbl and smoothie. @jorgerobles how do you shift the grid like in your screenshot?

[jorgerobles]

Settings- machine - machine origin :)

El 14 may. 2017 8:28 p. m., "Todd Fleming" notifications@github.com escribió:

I must be missing something. I got set zero to work, but it doesn't cause the grid to shift. I tried with both grbl and smoothie. @jorgerobles https://github.com/jorgerobles how do you shift the grid like in your screenshot?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/304#issuecomment-301330682, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYHsCo_EPe5a9ubBdZi9RgWPOsJJ3ks5r50fHgaJpZM4NaFi2 .

[tbfleming]

Ah. I thought grid shift was tied to the wpos origin. So right now users have to set up their wpos origin and type that value into the config separately?

[jorgerobles]

Is unfinished (or fake) right now only paints baselines in other positions and coords numbering

El 14 may. 2017 8:33 p. m., "Todd Fleming" notifications@github.com escribió:

Ah. I thought grid shift was tied to the wpos origin. So right now users have to set up their wpos origin and type that value into the config separately?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/304#issuecomment-301330984, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYBCoibO2CoFd5b7jiTdeZ4ViGFGRks5r50kQgaJpZM4NaFi2 .

[tbfleming]

Is there a way to get the wpos origin?

[jorgerobles]

Em nop that i know. Should be get from machine isn't it? Sorry i'm a bit confused.

El 14 may. 2017 8:40 p. m., "Todd Fleming" notifications@github.com escribió:

Is there a way to get the wpos origin?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/304#issuecomment-301331322, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYGAWcbeM1eG-Xhgoj4FuAbKKDQEEks5r50qIgaJpZM4NaFi2 .

[tbfleming]

Yes. We need to get the wpos origin from the machine.

[tbfleming]

Screenshot:

• Grid size controlled by: Settings -> Application -> Grid Width and Grid Height
• Machine size controlled by: Settings -> Machine -> Machine Width and Machine Height
• Machine position controlled by: Settings -> Machine -> Machine Origin X and Machine Origin Y
  • Temporary. It should be controlled by retrieving the WPos offset from the machine.

[jorgerobles]

Cooool. :) Will test tomorrow

[tbfleming]

Made it stand out more:

[ghost]

I missed the comments that this thread also talked about the new grid size. Sorry @jorgerobles

Anyways, to answer @cprezzi 's "The question is also, how we can show the gcode in the workspace?" in LW3 we had been working toward doing rotary preview like this: https://github.com/LaserWeb/deprecated-LaserWeb3/issues/51#issuecomment-236152662

(@HakanBastedt had the parser calculate it and segment it into a radius, then calculated XYZ positions to show it)

And threejs had an easy way to draw the helper

Just never got finished adding both together

[cprezzi]

@tbfleming We can get the work offset from the firmwares. It's just not programmed yet.

[cprezzi]

@tbfleming Question: What sense does it make that the grid is shown bigger than the machine? The user is always limited by the machine size. Theoretically, the grid (virtual) space is infinite, but users are used that only the machine space is shown (Repetier, Cura, Mach3...).

[tbfleming]

We could limit it to the machine size, or we could let the user choose.

[cprezzi]

I can see a case, where the part is bigger than the machine. For this case, it's bether like it is now, so the user could see the whole part and the limited machine space.

[cprezzi]

@openhardwarecoza @jorgerobles @tbfleming Did you realize that I have removed the Z-axes DRO and Jog buttons, if Z-Stage is not active in machine settings? Same for A-axes. Is this ok for you?

[tbfleming]

@cprezzi Makes sense to hide those.