Move menu issues

[RH3D]

Hello!
I noticed two issues (or intension that I didn't figure out?) in the move menu.

1. When moving one axes few times in a row, sometimes the value that should be added to the current position will be set as the new position. For example moving Z axis +10 mm and pushing the button few times in a row, sometimes the Z position will be set to 10mm, not Z +10mm. I think it happens only if I push the button few times when the printer didn't finish the move yet.

2. When moving axis over the limit, it will skip back to the min value, for example my Y max is 245mm and when I move there and press +1 mm, it goes to 1 mm instead of staying at the Y max position.
   EDIT: this is not an issue - after further trying, I found that this is caused by previous issue.

I made a video of those two issues. (time stamp of those moments in the video description)
https://youtu.be/JDpRCueV6Ig

3. This is definitely not an issue but I was thinking if there was consideration of different move axis layout - I personaly prefer the cross pattern and I think it could be more readable/space saving and would allow for more preset values. I made a quick layout rearrangement to show what I was thinking about.
   

Thank you for all the work and amazing project!

[suchmememanyskill]

Do you by default set your printer in absolute or relative mode? Cyd klipper when the printer is set to absolute should first set the printer to relative, do the move, then set back to absolute

The first issue i've experienced before, moving the printer is a blocking operation and the printer doesn't really respond or receive new gcode while moving

For the 2nd issue, this sounds very odd. I've always had klipper block the move operation when i went out of bounds, it never went around to the other side.

Can you check what gcode is being executed in the terminal of mailsail or fluidd? Cyd-klipper also logs all sent gcode if you hook it up to the console viewer built into the installer

(For the cross pattern ui, i personally dislike it especially on such a small screen. I do agree that this isn't perfect but i don't think a cross pattern mover is the solution)

[RH3D]

You mean the default settings for slicing? Or is there a default mode in Klipper itself too? As I haven't found one.
For slicing, I am using absolute coordinates and relative for extruder as default.

---

I am so sorry for the second issue but I have been slowly checking it all again and found that this one is not really there and it's all the first issue causing it. I don't know how I missed that but it has happened to me several times in basically the same situation so I thought it is what I said. It probably happens because I go by 1mm few times in a row at the end of the Y and then the 1st issue happens.

---

1st issue
I was looking at the gcodes and found the issue even in Mainsail web interface although it acts differently:

Through Mainsail web interface when the printer is in relative mode the command looks like this:

G91
G1 Z+10 F1500

in absolute mode it looks like this:

G91
G1 Z+10 F1500
G90

When the issue happens through Mainsail web - clicking the move button quickly many times in a row, it suddenly starts sending commands without the G90 and all upcoming moves are send as in a relative mode so it still keeps the position properly although it switches to relative mode.

While on CYD-Klipper - relative mode sends:

G1 Z+10.000 F6000

absolute mode sends:

G91
G1 Z+10.000 F6000
G90

When the issue happens, it sneaks in one command in the relative mode form so it doesn't go +10 mm but goes to 10mm and then continues sending commands for the absolute mode. So the sequence from LOG looks like this:

G91
G1 Z+10.000 F6000
G90
G1 Z+10.000 F6000 (faulty one)
G91
G1 Z+10.000 F6000
G90

---

(Cross pattern ui - I totally understand, this is absolutely an individual thing and was just an idea. I may like the cross pattern more but I am totally fine with the current layout.)

[suchmememanyskill]

A background thread is still running and fetching data while gcode is being sent. It's possible that during a move, data is fetched, which would fetch that the printer is in relative mode, then quickly after that another move is requested (but now adjusted for relative mode, so it doesn't set the printer to relative) before the move mode can be corrected

I'm suprised i never noticed this

[suchmememanyskill]

@RH3D Can you try the following build?

Instructions: https://github.com/suchmememanyskill/CYD-Klipper/blob/dev/Manual_Install.md
Build: https://github.com/suchmememanyskill/CYD-Klipper/actions/runs/9038585463

This should make the move menu more responsive and should fix the issue of the printer moving to an absolute position when it shouldn't

[RH3D]

@suchmememanyskill

Tested and so far it is a huge improvement, I was clicking like crazy and it is responding better and I couldn't get into the same issue like before.

I was also checking the log for commands and only once there was some failure but I didn't notice the change during the testing - the position stayed where it was and was moving like it should. And as said - it was only once during the time trying and I was really pushing it hard so I'd say this is great now.

part of the LOG from the CYD where I noticed the failure:

Sending gcode: G91
G1 Y+1.000 F6000
G90
Sending gcode: G91
G1 Y+1.000 F6000
G90
Failed to fetch printer data: -1
Sending gcode: G1 Y-10.000 F6000
Sending gcode: G1 Y+1.000 F6000