Cut Start with Ruida starts from the origin, instead of first vertex

[jnweiger]

Seen with Visicut 1.9.0 compiled with liblasercut from https://github.com/t-oster/LibLaserCut/pull/186

The attached SVG should produce a regular 6 pointed star. The preview in visicut shows the star correctly, but when sent to the laser, the first line starts at the top left origin, instead of at the first vertex. It is shown incorrect in the machine display, and it also cuts incorrectly.  

Assign to @kkaempf

[t-oster]

Hi, does this also occur if you compile without #186. Is the problem only in the ruida driver, or can you confirm it in other drivers?

[jnweiger]

ah, good question! Re-testing with the same binary, but with the Epilog Zing driver: No problem, everything works fine. ( @t-oster Entwarnung for you :innocent: )

More SVGs with more tricks:

• Adding a very small line near the origin fixes the issue:

• And a variant, that is even weirder: The preview in the Ruida Controller now disagrees with what the machine actually cuts. The preview shows, that the erratic line starts at the bottom right, but in reality it starts (as before) from the top left.  

[kkaempf]

Hmm, disassembling the generated .rd file from Ruida.java:

...
Blow_on                         ca 01 13 
Speed_C9 0.1mm/s                    c9 02 00 00 00 00 64 
Laser_1_Min_Pow_C6_01 10%               c6 01 0c 66 
Laser_1_Max_Pow_C6_02 0%                c6 02 00 00 
CA_03 0f                        ca 03 0f 
CA 10 00                        ca 10 00 
Mov_Abs 49.222mm 46.213mm               88 00 00 03 00 46 00 00 02 69 05 
Cut_Abs 31.351mm 40.147mm               a8 00 00 01 74 77 00 00 02 39 53 
Cut_Abs 22.541mm 56.837mm               a8 00 00 01 30 0d 00 00 03 3c 05 

comparing this with https://github.com/t-oster/LibLaserCut/blob/bc3f41385535869d6c47f158ddb7fdb48a2997dd/src/main/java/de/thomas_oster/liblasercut/drivers/Ruida.java#L585-L595 I'd say that the initial MOVE is coming from LibLaserCut.

[t-oster]

It looks like the code does make no difference between moveto and lineto commands...lineto commands should be without laser on

[jnweiger]

Hmm, I doubt that a simple moveto lineto confusion is the issues. If so, we should see one more lines than expected. But we see exactly 12 line segments.

Thomas Oster @.***> schrieb am Sa., 1. Apr. 2023, 10:29:

It looks like the code does make no difference between moveto and lineto commands...lineto commands should be without laser on

— Reply to this email directly, view it on GitHub https://github.com/t-oster/LibLaserCut/issues/189#issuecomment-1492877707, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOUQQKPG6M7B4LLI6D2QLW67RMZANCNFSM6AAAAAAWMPCMPQ . You are receiving this because you authored the thread.Message ID: @.***>

[kkaempf]

Just tested on Nova35 - everything's fine.

A Java version issue (again ?!) 😱

My environment:

> java -version
openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+0-suse-1.1-x8664)
OpenJDK 64-Bit Server VM (build 17.0.7+0-suse-1.1-x8664, mixed mode, sharing)
> javac -version
javac 17.0.7

[mgmax]

Can you please compare the resulting RD files from the good and bad version?

[kkaempf]

It looks like the code does make no difference between moveto and lineto commands...lineto commands should be without laser on

No worries, it does :wink: https://github.com/t-oster/LibLaserCut/blob/bc3f41385535869d6c47f158ddb7fdb48a2997dd/src/main/java/de/thomas_oster/liblasercut/drivers/Ruida.java#L595

[fblaese]

The issue probably is that the last laser position is remembered. If the destination is equal to this position, no move is generated. The remebered position is assumed to be [0,0] on first instantiation. However, this assumption fails in two cases:

• The laser is not positioned at the origion at the start of a program
• The machine code is generated by VisiCut without a restart. In this case, the class instance is reused and the last position of the previous program is used. However, the controller moves the laser back to the origin on program end automatically

I will send a Pull Request to fix this issue soon.

[mgmax]

I don't know the details of your driver, but typically you need to set last_x=NaN; last_y=NaN; (or similar) at/near the start of writeJobCode, e.g., here: https://github.com/t-oster/LibLaserCut/blob/bc3f41385535869d6c47f158ddb7fdb48a2997dd/src/main/java/de/thomas_oster/liblasercut/drivers/Ruida.java#L534

Also, your functions need to handle the case where last_x is NaN (meaning "last position unknown").

Alternatively, you could add an absolute move to (0,0) at the start of the job, if this is the intended behavior that the original driver also uses.