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.