Support X and Y axis flip

[kkaempf]

Introduce two new settings

• Flip X Axis
• Flip Y Axis

to support lasercutters with a non-standard (not "top left") origin.

Fixes #198

[mgmax]

It would be interesting to know if engraving also works or if some further changes are needed for that.

[pimsierhuis]

We are currently also trying to get our new laser cutter to work and have the same problem (machine origin at top right). But, we do want to set the origin in the machine panel itself (so we can use jogging to position the origin at the workpiece) and therefore we only want to invert x/y and not translate with the bed width/height. I even implemented it (pimsierhuis@50e9cf6) before searching the PR's :)

Can you live with the same solution? Or can we for example have an extra option for the translation by bed width/height?

[kkaempf]

I even implemented it (pimsierhuis@50e9cf6) before searching the PR's :)

That's exactly what this PR does !?

[mgmax]

The distinction is between relative and absolute coordinates.
yNew = - yOld (@pimsierhuis) vs yNew = height - yOld (@kkaempf). The second one is correct.

I'm not sure how well documented the interface is, so here is a longer explanation:

VisiCut sends absolute coordinates to LibLaserCut. The window and rulers in VisiCut is supposed to match the full laser bed of your cutter, so "top left in VisiCut" is "top left edge of your laser bed". The zero point of your lasercutter must be at the top left edge of the bed (or some other well-known position, if the driver converts to that other position.)

The intended usage is that you find the relevant point using one of

• the camera view in VisiCut
• the rulers at the lasercutter
• if your machine has it, using the machine position display.
• if your machine supports it, right click - "move to position" in VisiCut

and use drag-and-drop or the "Position panel" in VisiCut, or adjust the position in your original vector graphics file (top left of page = top left of VisiCut if you don't move anything)

Relative coordinates are an edge case, which has some limitations (e.g. VisiCut can't check if the job exceeds the laser bed because it doesn't know where exactly the user set their zero point). The intended usage is that in VisiCut,

1. you place your job at any position (doesn't matter). For example, at a position similar to the absolute position on the laser bed.
2. You right click on the point in your job where your lasercutter zero point should be, choose "Set start point"
3. The driver accordingly switches to relative coordinates (Either call job.applyStartPoint() to transform to relative coordinates, or use job.startX and .startY for some calculations).

(Note that by design, "Set start point" to the top left edge has no effect -- to the driver, it even looks the same as if no start point was set at all.)

[khenriks]

I tried this out and it doesn't seem to be working for me. I suspect that find_and_write_bounding_box also needs to be updated. In addition, it might make sense to consider changes to other locations in the code that call px2mm.

[matthijskooijman]

@mgmax Thanks for your detailed response! I'm working on the same machine as @pimsierhuis and have some cents to add :-)

yNew = - yOld (@pimsierhuis) vs yNew = height - yOld (@kkaempf). The second one is correct.

I would not say that either of these is more or less correct - it depends on the machine which one you need (but maybe no machines exist in practice that need the former?).

Essentially, @pimsierhuis's approach just inverts the coordinate, mirroring over the 0 axis. @kkaempf's "flip" aproach (which is also used on other drivers AFAIU) does the same, but additionally translates coordinates by the bed size (together effectively mirroring over the center of the bed). Whether the inversion is needed depends on the machine travel direction. But whether this translation is also needed, depends on the place of the machine origin (relative to Visicut's origin).

Visicut has its origin top left, with positive space (positive coordinates to the right and bottom).

Our machine has a configurable origin, with positive coordinates to left and bottom. This means the Y axis is good as-is, but for X we need at least inversion, and depending on where we place the machine origin, also translation. I can also imagine that there might be machines that are less configurable, and so might need inversion without translation (or maybe even translation without inversion - at first glance the CNC mill practice of origin top right with negative space seems to need this?).

For maximum flexibility (and ignoring existing implementation and compatibility), I can imagine it could be useful to allow independently configuring axis inversion and translation (maybe even driver-independent).

However, as stated below, for our machine the current "flip" setting seems to be enough for now, so I'll leave this as a thought for consideration (that very likely has been considered and maybe has been rejected before, I can imagine).

The intended usage is that you find the relevant point using one of

This is indeed how we've been using Visicut so far, but we are now working on a new machine that has easy jogging, so it seems a better workflow based on positioning the head over the workpiece (instead of precisely positioning the workpiece on the bed) would be possible. We thought to implement this by moving the machine origin, but we did not know about the "relative positioning" mode, using "Set start point" in visicut until now. Having seen that, that is an even superior workflow. It also removes our need for modifying the machine origin for positioning (and thus the direct need for an invert-without-translation setting for absolute positioning).

We've tried this relative positioning mode, and it seems to work on our machine as well. There is, however, one caveat: It only works with our "invert" implementation (without translation). With the "flip" implementation (with translation), the design is executed one bed width to far too the right (confirmed by making the visicut bed width artificially small).

This makes sense: AFAIU the relative mode puts the effective visicut origin at the place where you do "Set start position", and the machine origin (I presume some temporary work origin) is put at the current head position. This means the visicut and (effective) machine origin align, so there is no translation needed to match a top-left visicut origin with a top-right machine origin.

I believe this is generically applicable - regardless of the particular machine used, relative mode will always have matched origins, so no translation needed. I suspect this means that the current/proposed implementation of "flip", at least in the ruida driver, has a bug and relative mode does not work when combined with the flip setting.

An obvious fix would be to just skip the translation part of the "flip" when operating in relative mode. I haven't checked the code to see if any of the other drivers already implement this, but if not, then I guess this is something to fix in all other drivers too.

Writing this, I realize some of this might be getting a bit off-topic from this particular PR, so if you prefer separate issues (one for splitting inversion and translation, and one for relative mode with flip I guess), let me know and I can create them.

[mgmax]

I get your point. I would suggest that as a first step we get absolute positioning working, because it is the basic case from VisiCut's point of view.

The "relative" mode should be a separate second step. I want to avoid that we add config options that make no sense if you use VisiCut as intended, so it's good to have these discussions.

Looks like we need to invest more thoughts into how the flipping works interacts with relative mode, especially with applyStartPoint(). I haven't fully understood it yet. Maybe you can make a drawing? Assuming you are right, then: There is a design error in all drivers (e.g. GCode) that support flipping and use applyStartPoint(): The current applyStartPoint() and startX / startY interface is not good enough for machines where the origin is not at top-left. Currently we can not distinguish between "relative mode, start point top left" and "absolute mode" - these are both represented by the same values of startX =0 and startY = 0. A possible solution would be to use NaN to represent absolute mode. Then the driver can react as you described (translate only in absolute mode). Hopefully the whole relative/absolute/translation/flipping logic can be put into a function that is used across drivers, similar to how applyStartPoint() is used now.

How does the original driver/software handle all this? Do they have an extra input field to select relative or absolute mode, and then enable/disable translation based on that? Or is their "relative start point" not at the top left of the drawing but e.g. at the top right?

[TheAssassin]

To make relative coordinates work, one needs to (properly) support different origins in LibLaserCut, but this is out of scope of this PR. This PR is a first attempt to make newer Ruida devices work that have their origin on the top right and whose coordinate system is basically mirrored around the Y axis. I suggest the discussion on proper support for relative focus with origins other than top left needs to be done separately.

I propose that this is merged for now as a form of "basic support".

[TheAssassin]

By the way, I just thought it might be easier to support some "get current position" from VisiCut (see also t-oster/VisiCut#706) which can then be displayed in VisiCut's user interface. But as said, this needs more discussion. It's entirely out of scope for this PR.

[mgmax]

There was a lot of discussion and I'm slightly confused what is the current status. Can someone please confirm that their machine needs one of these "axis flip" settings AND then works correctly with absolute positioning mode?

[TheAssassin]

I just tested this. The patch appears to be incomplete, as reported earlier. I'll try to fix the problem, it is most likely the missing changes to the submitted bounding box proposed earlier.

Honestly, I cannot image that this was tested on an actual device beforehand...

[mgmax]

Marking as draft - Please mark as ready once the reported problems are fixed

[mgmax]

continued in #223