Project

General

Profile

Actions

Bug #58

closed

Incorrect line/move commands during engraving

Added by jaap over 11 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
firmware
Target version:
Start date:
2012-11-24
Due date:
% Done:

0%

Estimated time:

Description

While engraving, the laser was sometimes moving to the wrong position. This resulted in some engraving-lines being engraved on the wrong place. In the image below, you can see that the wrong lines often went to the same (or a simular) point outside the image.

Now the interesting part: when I send the same .lgc file again, I get the same errors! So this cannot be some strange glitch in my machine, it must be something in the firmware.

In the image you can see two engravings. Note that the lines going out of the image are the same. The .lgc file is also attached. It does not contain the strange dislocations.


Files

engraving-test.jpg (776 KB) engraving-test.jpg Engraving test jaap, 2012-11-24 16:27
123.lgc (27.6 KB) 123.lgc Engraving source file jaap, 2012-11-24 16:27
Actions #1

Updated by KalleP over 11 years ago

jaap wrote:

While engraving, the laser was sometimes moving to the wrong position. This resulted in some engraving-lines being engraved on the wrong place. In the image below, you can see that the wrong lines often went to the same (or a simular) point outside the image.

Very interesting to see that the lines do contain some (perhaps correct) raster data and only the vector moves are at fault here.

The fact that the incorrect moves are the same in a relative, on repeat runs, way may offer some insight into the failure mechanism.

The fact that the image engraving continues correctly after the glitch shows that the data is correctly read and the syncronisation is not lost. I wonder if the faulty lines would still engrave incorrectly if some/all other data lines around/near them were removed.

I do not know also makes me think that the vector move calculations have somehow been corupted due to calculation overflow in some strange way. The sample file appears to have no strange jumps or errors in the move commands.

I wonder if there is a way to check if the file is uploading correctly.

Actions #2

Updated by peter about 11 years ago

Seems to be related to the incorrect handling of SVG sub-paths. At the end of each subpath a line is drawn to the start of the path.
In Inkscape subpaths can be avoided by ungrouping all objects, convert all objects to paths and then split all paths.

Actions #3

Updated by peteruithoven over 9 years ago

  • Status changed from New to Closed

I have never seen this, so I'm closing this for now.

Actions

Also available in: Atom PDF