Autoleveler - Apply to Gcode - incorrect first movements

[pagabee]

Describe the bug
The first movements are incorrect if the scanned surface coordinates are applied to the gcode.
There is a first unwanted engraved line.

Version
UGS Platform 2.0.7

Operating system (please complete the following information):
Raspberry PI 3B+; Raspberry Pi OS with desktop

Gcode generator
Fusion360

Original Gcode:

(1001)
G90 G94
G17
G21

(Engrave3)
S24000 M3
G54
G0 X-12.409 Y-19.818
Z4
Z2
G1 Z0 F750
X-12.389 Y-19.812 Z-0.025
X-12.329 Y-19.794
X-8.821 Y-21.581
...

Leveled Gcode:

(1001)
G90G94
G17
G21

(Engrave3)
S24000M3
G4P5.00
G54
G0X-0.517Y-0.8257Z-0.1674
G0X-1.0341Y-1.6515Z-0.1719
G0X-1.5511Y-2.4773Z-0.1765
G0X-2.0682Y-3.303Z-0.1813
G0X-2.5852Y-4.1288Z-0.1861
G0X-3.1023Y-4.9545Z-0.191
G0X-3.6193Y-5.7803Z-0.196
G0X-4.1363Y-6.606Z-0.2012
G0X-4.6534Y-7.4318Z-0.2064
G0X-5.1704Y-8.2575Z-0.2117
G0X-5.6875Y-9.0833Z-0.2172
G0X-6.2045Y-9.909Z-0.2227
G0X-6.7215Y-10.7348Z-0.2269
G0X-7.2386Y-11.5605Z-0.2307
G0X-7.7556Y-12.3863Z-0.234
G0X-8.2727Y-13.212Z-0.237
G0X-8.7897Y-14.0378Z-0.2397
G0X-9.3068Y-14.8635Z-0.2419
G0X-9.8238Y-15.6893Z-0.2439
G0X-10.3408Y-16.515Z-0.2466
G0X-10.8579Y-17.3407Z-0.2499
G0X-11.3749Y-18.1665Z-0.2532
G0X-11.892Y-18.9923Z-0.2567
G0X-12.409Y-19.818Z-0.2602
G0X-12.409Y-19.818Z0.7398
G0X-12.409Y-19.818Z1.7398
G0X-12.409Y-19.818Z2.7398
G0X-12.409Y-19.818Z3.7398
G0X-12.409Y-19.818Z2.7398
G0X-12.409Y-19.818Z1.7398
F750
G1X-12.409Y-19.818Z0.7398
G1X-12.409Y-19.818Z-0.2602
G1X-12.389Y-19.812Z-0.285
...

I think that, the autoleveler function calculates the first movements ( from G0 X-12.409 Y-19.818) incorrectly.

[pagabee]

I made some investigation...
I wrote a simple g-code to present what I found, the movement is a simple rectangle. (gcode.txt)

I think that the problem is, the autoleveler takes the origo (0:0:0) as the first point, because of this the cnc goes from home at first into the origo then to the actual first point.
This causes the unwanted first engraved line.

If the g-code lines (marked with yellow) are deleted, the engraving is fine. (gcode.apply.gcode.docx)

The first movement (yellow line) goes on the surface, from the origo, not from the first point:

gcode.txt
gcode.apply.gcode.docx
Surface test Data.txt

Another issue: feedrate
The leveled g-code does not contain the F1500

[zdima]

I am having the same issue with first unwanted line.
This make result mostly unusable especially when spindle have to move all across the board.

Is there any way to save updated G-code into a file?
Once saved, I could edit the file by removing the portion of code for unwanted line?

I also noticed the issue with federate set to crawl. Would be great if this can be fixed too, but not critical.

The plugin is very much works for me (if not these two issues) - great job guys!

[zdima]

Disclaimer: this is my first time I am looking at UGS code.
I look at parsing code and it seems G28 command is incorrectly handled by parser.
The G28 command is common to see in a program preamble (for example 'G28 G91 Z0').

The updatePointWithCommand is not aware of mechanics of the G28 and how it affect the new positions.
The handleGCode does not tell updatePointWithCommand about G28 nor attempt to handle it.

Because Z0 found in the command arguments, the parser assume a move of Z-axis to coordinate 0 (active coordinate system?).
However, this is not what machine dose for G28:
G28 - makes a rapid traverse move from the current position to the absolute position of the values in parameters 5161-5166. The parameter values are in terms of the absolute coordinate system and the machine’s native coordinate system.

At this point the parser assumes location as X,Y,0. The next command that move spindle to work position X,Y calculate Z axis based on current value of 0, and spindle dive with first move command to Z=0+-adjustment.

I believe, the issue with unwanted line can be resolve if handleGCode can properly recognize and appropriately update X,Y,Z.

[LoicLac]

Hello everyone,
Is there any news concerning this issue ?
Apart these two problems , Auto Level in UGS is really impressive and i like it much more than other implementation .
@zdima , did you find a way to save the updated level code to a file ?
And how do you find your way to use Auto-Level despite this bugs ?
Thank you ,
L

[andrewmurraydavid]

@zdima were you ever able to find a way to bypass that? Either by updating the code or by changing settings?

@breiler are there any thoughts on if this would ever get fixed?

[zdima]

@zdima were you ever able to find a way to bypass that? Either by updating the code or by changing settings?

@breiler are there any thoughts on if this would ever get fixed?

Sorry, I didn’t had a chance to work on it and I can’t say when I can look into this.

[andrewmurraydavid]

No worries, @zdima!
I ended up finding a temporary fix by adding a raise Z in my Gcode before moving to the first desired XY coords. Couldn't find a way to do that automatically in Fusion360, and it's a but annoying since I have over 50 files that needed to have a single line added, but at least no more starched on the piece and broken tools because of the bug in UGS.

[breiler]

@andrewmurraydavid can you post a sample file without the fix for us to test with?

[andrewmurraydavid]

Here's a sample @breiler, hope it's useful:

(1004)
G90 G94
G17
G21
(Engrave1 4)
T8 M6
S12000 M3
G17 G90 G94
G54
(this is where UGS calls the end mill "home")
; Z5 (this is the line I added to avoid collision with the piece and that extra line)
G0 X46.868 Y6.316
Z12
G1 Z1.82 F2000
Z-0.05 F500
X46.873 Y6.412 F2000
Y7.43
X46.885 Y7.777
Y7.779
X46.914 Y7.949
(keeps on going for another 5000 lines)
Z12

M5
M30

[breiler]

Thanks, I have made a small code change which seems to fix this. The change may be small but it is a very central part so I need to do a lot of testing before I dare merging it. Thanks for the patience.

[breiler]

It is merged and available in the latest nightly build:
https://github.com/winder/Universal-G-Code-Sender/?tab=readme-ov-file#downloads

I would appreciate help testing this.

[andrewmurraydavid]

Thank you, @breiler!
I noticed the PR yesterday and I tried pulling it locally and testing it out. I've encountered a build issue (I'm sure it's just a local setup issue, though I don't understand why it randomly started happening since I've had my local working just last week). Since my machine runs the advanced macros I built, I'm a bit blocked until I get the setup running again. I should be able to dig into it more after work.

For reference the issue I'm getting is not finding a resource:

java: No key 'mainWindow.swing.baudrate.toolbarTitle' found in resources.MessagesBundle

Happy to connect with you if needed. My email should be in my github profile.

[andrewmurraydavid]

So far it works great! I don't find any breaking changes! Thank you, @breiler !

A quick question I have about the leveler Z adjustment, what's the speed the Z is adjusted with? I couldn't find that information in the code after a quick search. Could you point me in the right direction?

Thanks!

[breiler]

I am not sure what you are asking for. But all settings for the auto leveler is handled here:
https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-platform/ugs-platform-surfacescanner/src/main/java/com/willwinder/ugs/platform/surfacescanner/ui/AutoLevelerSettingsPanel.java#L100

[andrewmurraydavid]

Right, I see why the comment can be confusing. So let's take this example:

G1 F1000 X12 Y23

And let's say the Z offset for that point is 0.5 from the leveler. Does that translate to:

G1 F1000 X12 Y23 Z0.5

;  or

G0 Z0.5 ; or G1 F? Z0.5
G1 F1000 X12 Y23

Hope that makes more sense. The reason I'm asking is because my program uses F1000, but when the level mesh is applied to the gcode the feedrate doesn't go over 500 (when overridden to 200%). And obviously the program runs much slower.

[breiler]

Does your program have arcs which could cause this problem #2430?

[andrewmurraydavid]

Not G2 or G3 arcs, but arcs made via smaller lines.
I attached the file. If it's a problem with my file, no problem. I was just trying to find a way to optimize the process. I've got another 36 wedding cards to make and only one face (the one shared here) takes 10-ish minutes 😵‍💫

File is txt as github doesn't accept .nc files.
instructions.txt

[andrewmurraydavid]

I just found the generated gcode with the applied Z offests. Maybe this helps too?

instructions.nc_ugs_1705622747872.txt

[breiler]

Your gcode has plenty of small details which you are trying to run at a feed rate of 3000 mm/min. If I have to guess, your machines acceleration/deceleration settings are set in a way that don't allow it to reach your desired speed.

If I use the default acceleration setting of 10 mm/sec2 I also get around 500mm/min. If I increase this to 100mm/sec2 it will acheive much higher speeds. But then there is also a risk that the stepper motors will loose steps...

I don't think that there is much we can do about this from UGS point of view.

[andrewmurraydavid]

Thank you for helping me understand the cause. Sorry to have bugged you on a weekend.
It now makes sense why it's slower with the lever mesh applied since it has the extra Z movement it needs to account for and my Z acceleration is much slower than my XY acceleration.

Thank you again!

Also, I've been running the machine all day with the the update you made for the original issue I commented about and I haven't have any issues! Thanks for the fix!!

[breiler]

Closing this as it seems to be working now.