Make Y-Axis Inversion configurable

[patjenl]

Describe the bug
Y-Axis Jog control from Octodash inverted compared to Octoprint

To Reproduce
When using the control option in Octodash pressing the Down arrow (Negative Y-Axis movement) the Y actually moves away from the front of the printer (positive Y movement). In Octoprint Y-axis control works the opposite and the down arrow results in correct negative Y-Movement.

Expected behavior
When using Y-Axis control on Octodash, using the down arrow results in negative Y movement (to the front of the printer).

Screenshots
NA

General Information:

• Raspberry PI 4
• OctoPI 0.17.0
• OctoDash Issue is present in version 2.0 and 2.1
• OctoPrint 1.4.2

Additional context
I tried inverting the axis in the Octoprint printer profile but as expected the issue reverses (Octoprint works wrong way around and Octodash works correct).
When checking the terminal in Octoprint:

10mm Y move from Octodash (down arrow)
Send: G91
Recv: ok
Send: G1 Y10 X0 Z0 F9000
Recv: ok
Send: G90
Recv: ok

10mm Y move from Octoprint (down arrow)
Send: G91
Recv: ok
Send: G1 Y-10 F6000
Recv: ok
Send: G90
Recv: ok

[UnchartedBull]

That's by design for OctoDash. I find it really unintuitive to press up to bring the bed towards you, that's why OctoDash chooses the bottom arrow to be positive and the top arrow negative movement.

[patjenl]

Ah ... that's exactly it ! Now I understand why it is designed like this.
I have a Voron 2.4 printer so the bed is stationary and the gantry moves X and Y.
So definitely no bug.
Maybe you can take this in consideration to introduce a config item to invert the Y axis ?

[krudoy]

Can the same be done for Z Axes? Useful for Ender 5

[UnchartedBull]

Should be possible.

[komandrik]

There is also Core_XY in which the table is stationary along the Y axis.

[mikekscholz]

I was tinkering with the source code a little, and found that setting the Y inverted to true in the control.component.ts didn't seem to have any effect on the motion directions. I have the Y inversion enabled in Octoprint's core settings, and switching the up arrow to + and down to - in the control.component.html made my Y motion consistent across all interfaces, so I'm assuming that Octoprint isn't doing the inversion at the UI level.

[UnchartedBull]

Did you change the JSON at the top of the file @mikekscholz? This will be overwritten with the default printer profile if available, so that's maybe why you didn't see anything change. Could you maybe check if your printer configuration in OctoPrint has it's axis inverted as well? If so OctoDash should pick that up. I'm talking about setting the checkbox here:

[mikekscholz]

Yes I have my Y inverted on that screen you posted. After I changed the .ts file back to the defaults I changed the html to up +, down - and ended up with expected motion. I looked at the Octoprint source afterward and found that with the invert Y checked, the button for up was still sending +1 and down -1, so Octoprint is doing the inversion behind the scenes.

[UnchartedBull]

Oh ok, that is weird. That means if you set the axis inversion in OctoPrint, OctoPrint will invert all axis commands before they are send to the printer. Because OctoDash is also aware of the inversion, OctoDash is inverting the axis prior to sending it over to OctoPrint and then OctoPrint is inverting the axis again, which results in no visible inversion to the user.

That's really interesting, since that definitely has changed in one of the last versions then. I'll dig through the changelog and try to find the change. Will probably remove axis inversion from OctoDash then if OctoPrint handles them behind the scenes.

[UnchartedBull]

According to this file: https://github.com/OctoPrint/OctoPrint/blob/f67c15a9a47794a68be9aed4f2d5a12a87e70179/src/octoprint/static/js/app/viewmodels/control.js#L319 OctoPrint is still doing the axis inversion on a UI level. So theoretically the OctoDash axis inversion should work.

[mikekscholz]

[mikekscholz]

It looks to me like its line 333 that does the inversion right before it gets sent to the printer by multiplying everything by -1, inside the sendJogCommand function, the values the UI passes to the function don't change though. I could be completely wrong about the JavaScript back-end, but the click functions in the HTML definitely never change... Edit, I was just thinking that even if Octodash isn't using control.js and is inverting itself by reading the printer profile, Having the HTML buttons already reversed is canceling itself out as well.

[mikulik86]

That's by design for OctoDash. I find it really unintuitive to press up to bring the bed towards you...

Yeah, me too. But I'd like to have it so in both OctoPrint UI and OctoDash. Now, when I invert the Y control in the OctoPrint, the OctoDash control is wrong and vice versa. Please, turn off the inversion so that people can choose to invert the Axis control in the OctoPrint settings and have it same in both UIs.

[UnchartedBull]

The inversion currently is taking from OctoPrint. I'll add a config option so you can invert OctoDash controls to match OctoPrint controls.

[SaKiEQ]

has there been any work on this ?

I am running into the same issue. OctoPrint is configured so the axis match the webcam view.
Yet when I am standing at the machine with OctoDash running on touchscreen all is reverse.

There is much confusion that goes as far as Z-Offset since it follows the defaults. (for regular cartesian printer).
This is a core X/Y machine so really difficult to deal with, when axis on UI can't be configured separately.

[EmEiBee]

The same here. At least one heatbed crash per day... ^^
But that's probably one of those things that somehow never gets changed...