svenhb / GRBL-Plotter

A GCode sender (not only for lasers or plotters) for up to two GRBL controller. SVG, DXF, HPGL import. 6 axis DRO.
https://grbl-plotter.de/
GNU General Public License v3.0
647 stars 172 forks source link

Version V1.7.1.1.a: The plotter software encountered an error while reading entities stored in blocks with inconsistent scaling ratios in the X and Y directions #375

Closed lianzaozi closed 1 month ago

lianzaozi commented 5 months ago

Version V1.7.1.1.a: The plotter software encountered an error while reading entities stored in blocks with inconsistent scaling ratios in the X and Y directions.

The different scaling ratios in the X and Y directions of the entities in the block in the dfx file can cause errors in the plotter software's reading.

The software version of the plotter used for testing is v1.7.1.1.a, and I guess this issue should exist in all versions.

1 Screenshot of CAD software

2 Screenshot of the plotter software

The dxf file used for testing 1 - (2).zip

The color display of graphics in the drawing software when reading dxf is different from what is displayed in the CAD software The display colors of the elements indicated by 1, 2, and 3 in the screenshot are different 3

svenhb commented 5 months ago

Thanks again for finding a bug šŸ˜‰ I found the problem, will release a new version soon.

svenhb commented 5 months ago

Check latest release: https://github.com/svenhb/GRBL-Plotter/releases

lianzaozi commented 5 months ago

Thank you very much for your hard work. There are still some issues with version v1.7.1.2, and the areas indicated by A, B, and C circled in the screenshot still have issues.

00

The polyline and point at point A are saved in the same block. I guess the problem at point A is related to rotation

The arc and line at point B are saved in the same block.

The circle and line at point C are saved in the same block.

There is still an issue with parsing circles, arcs, and polylines in the block.

There is still a problem with the resolution of graphic colors. The colors displayed on the plotter are different from those in CAD.

22

svenhb commented 5 months ago

My reference is LibreCAD, there your drawing looks like this, which is close to the GRBL-Plotter output: Perhaps there are incompatibility problems with AutoCAD versions? LibreCAD can save up to "DXF 2007". image

lianzaozi commented 5 months ago

I am using AutoCAD, and the version saved in DXF is 2018. I guess LibreCAD doesn't support dxf very well. The dxf format was created by AutoCAD, so AutoCAD has better support for the dxf format.

The following screenshot is a screenshot of me using AutoCAD to open dxf image

svenhb commented 5 months ago

Can you save with an older DXF version? I can't support the latest AutoCAD feature because there's no information to be found on the internet - I just found DXF 2012. To be fair, you should use freeware tools to test GRBL-Plotter. BTW. also Inkscape can't read your DXF file....

lianzaozi commented 5 months ago

Latest dxf format reference document

https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-A85E8E67-27CD-4C59-BE61-4DC9FADBE74A

The screenshot below shows the use of a plotter software to read the 2007 version of dxf. The plotter software still has issues parsing the 2007 version of dxf files. image

2007 version of dxf file 1 - 2007.zip

The arcs and circles stored in the block look like ellipses when inserted into dxf if the ratio of the X and Y directions is different, because the arcs and circles are stretched in the X or Y direction

When the scaling ratios of the arcs and circles stored in the block are not consistent in the X and Y directions when inserting the block, the circles and arcs should be converted into ellipses for processing and analysis. The ratio of the major and minor axes of the ellipse is the ratio between the scaling coefficients in the X and Y directions when inserting the block. A new algorithm should be added to handle this situation separately

svenhb commented 4 months ago

Try new release: https://github.com/svenhb/GRBL-Plotter/releases

lianzaozi commented 4 months ago

Try new release: https://github.com/svenhb/GRBL-Plotter/releases

Thank you for updating the new version. When testing version 1.7.3.0 of the plotter software, I found some issues. In the dxf file, point 1 in the following image coincides with the endpoint 3 of the elliptical arc, while points 2 and 4 coincide; However, when using version 1.7.3.0 plotter to read dxf, point 1 does not coincide with endpoint 3 of the elliptical arc, and points 2 and 4 do not coincide

When I draw the graph, the endpoints of the points and elliptical arcs coincide.

The resolution of coordinate values for the starting and ending points of elliptical arcs is incorrect in the latest version of the plotter software

image

image Screenshot of CAD software

The screenshot below shows the difference in the coordinates of the endpoint of the elliptical arc displayed in CAD and plotter. A is the coordinate value of the endpoint of the elliptical arc displayed in CAD, and point B is the coordinate value of the endpoint of the elliptical arc displayed in plotter 1 2

lianzaozi commented 4 months ago

Version 1.7.3.0 of the plotter software can only generate G01 when reading circles stored in blocks. After unchecking "Process drawn line pattern", arcs and circles will not generate G02 and G03.

Should the user be allowed to choose whether to generate G01 or G02/G03 for arcs when the scaling ratios in the x and Y directions of the circles and arcs stored in the block are the same; When the scaling ratios of circles and arcs stored in the block are different in the x and Y directions, arcs can only generate G01. image

svenhb commented 4 months ago

Will change the code: If dashpattern is enabled, but pattern is empty, then use G02/G03, otherwise G01 to be able to apply the pattern.

svenhb commented 3 months ago

Check latest release: https://github.com/svenhb/GRBL-Plotter/releases

lianzaozi commented 3 months ago

Thank you for releasing the new version. I will conduct some testing

lianzaozi commented 3 months ago

Version V1.7.3.1 still does not solve the problem of parsing the coordinate points stored in the block after the elliptical arc is rotated and scaled in the X and Y directions. I drew two points at the starting and ending points of the elliptical arc. If I observe that the starting and ending points of the elliptical arc do not coincide with the point in the plotter, it indicates that the coordinate values of the starting and ending points of the elliptical arc are parsed incorrectly. I did this to facilitate the observation of whether the calculated coordinate values are incorrect in the plotter after parsing.

At the same time, I will take screenshots of the coordinate values displayed in CAD and plotter for comparison of this dxf file

1 2 3 4 5

test dxf file 1 - (2).zip

lianzaozi commented 3 months ago

Version 1.7.3.1 of the software does not have settings that allow users to decide whether circles and arcs should generate g02/g03 or g01. Currently, this version can only generate g02/g03 for circles.

svenhb commented 3 months ago

Version 1.7.3.1 of the software does not have settings that allow users to decide whether circles and arcs should generate g02/g03

No need for an extra setting: if (scaling.X == scaling.Y) G02/G03 will be used (if enabled).

lianzaozi commented 3 months ago

Where is (if enabled) enabled?

If scaling X=scaling Y, what should I do to make the circle generate G01? If scaling X=scaling Y, what should I do to make the circle generate G02?

svenhb commented 3 months ago

Where is (if enabled) enabled? If scaling X=scaling Y, what should I do to make the circle generate G02?

This checkbox must not be checked: image

If scaling X=scaling Y, what should I do to make the circle generate G01?

Then check "Avoid G2/3"

lianzaozi commented 3 months ago

Thank you

lianzaozi commented 3 months ago

What is the difference between checking and not checking "Process Dashed Line Pattern"? Will this checkbox affect circle generation G01/G02/G03?

image

svenhb commented 3 months ago

If you have a dashed line and want to plot it you need to check this option, then, G02/G03 can't be used, because of the interruptions in the drawing path. Otherwise a normal line will be drawn, even if the property is "dashed". image

lianzaozi commented 3 months ago

Check ā€œProcess dashed line patteā€and uncheckā€œAvoid G2/3 (Arc Move) commands, draw arcs/circles with line s Adā€,So, the dotted circle generates G01, and the solid circle generates G02. Is that correct?

svenhb commented 3 months ago

Yes

lianzaozi commented 3 months ago

Thank you for your reply. After conducting some tests, the following are the test results, and one of them is incorrect

image

svenhb commented 3 months ago

Then perhaps an other option was also enabled? image

lianzaozi commented 3 months ago

I haven't changed any other options. I'll upload the file I used for testing and give it a try test.zip image

svenhb commented 3 months ago

Ok, there's a bug with DXF import: once the line pattern was set, it couldn't be reset.

svenhb commented 3 months ago

About dash pattern: Try test version https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_Setup_1731a.exe

The other problem (start / end pos of ellipse) I can't fix for now. Must be a rounding error, when converting angles back an forth.

lianzaozi commented 3 months ago

About dash pattern: Try test version https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_Setup_1731a.exe

The other problem (start / end pos of ellipse) I can't fix for now. Must be a rounding error, when converting angles back an forth.

Thank you for your hard work. I will conduct some tests.

After my testing, if the elliptical arc does not exist in the block, the starting and ending coordinates parsed by the plotter software are correct. However, if the elliptical arc exists in the block, and the block is rotated and scaled, the plotter software will read the starting and ending coordinates parsed by the block again, which will be incorrect.

lianzaozi commented 3 months ago

image

Elliptical arcs stored in blocks, incorrect resolution of starting and ending coordinates 1

It is not an elliptical arc stored in a block, and the resolution of the starting and ending coordinates is correct 2

test file 1 - (2) -.zip

lianzaozi commented 3 months ago

image image

The starting angle of an elliptical arc (45/180)*3.1415926=0.785398163ā‰  0.79741212786 (a2)

Termination angle of elliptical arc (342.097334/180)*3.1415926=5.97072484ā‰  5.0571035 (a1)

Perhaps the insufficient accuracy of the numerical values read in dxflib resulted in inaccurate angle values for the starting and ending points of the elliptical arc

test dxf 1 - (4).zip

lianzaozi commented 3 months ago

image I tried to draw more points on the elliptical arc and found that the coordinate values resolved by the entire elliptical arc are not accurate. In dxf, these points are completely on the elliptical arc. I will spend some time trying to solve this problem

svenhb commented 3 months ago

Yes, as soon as there are different scalings for X and Y inside the block, the angles a1, a2 are no longer correct. If scalings are the same, then there is no problem. Could not figure out why, up to now.

lianzaozi commented 3 months ago

How to output these logs

image

My settings are as follows, but during debugging, there was no output of print logs image

svenhb commented 3 months ago

You may enable extend logging, by clicking into the marked area image

lianzaozi commented 3 months ago

I clicked on the part you selected in the red box, do I need to set any other options?

lianzaozi commented 3 months ago

Hello, excuse me, I need your help What does the variable diff represent below? What does the condition for determining if here mean? image

What does the variable a represent below??? image

svenhb commented 3 months ago

the "large" variable is needed to determine the arc behavior: a is the axis-rotation https://www.w3.org/TR/SVG2/paths.html#PathDataEllipticalArcCommands

lianzaozi commented 3 months ago

From what I understand the variable a in the program should compute t1; But the actual variable a in plotter is equal to t2

I don't really understand why I'm calculating Angle t2, right? Can you help me explain?

image

image

lianzaozi commented 3 months ago

I finally found the reason, not because the scaling ratio of x direction and Y direction was inconsistent, but because the elliptic arc was stored in the block with an Angle, which was 13.178191. The elliptic arc in plotter's parsing block did not take into account that the elliptic arc in the block also had an Angle. Now I have adjusted the Angle to 0, and plotter will The parsing is normal. So we should take this into account when analyzing the elliptic arc in the block

The elliptic arc in the block has no Angle screenshot The elliptic arc in the block has no Angle.zip

image

Angular screenshot of the elliptic arc in the block The elliptic arc in the block has an Angle.zip

image

Open the Elliptic Arc Block editor to measure the Angle of the screenshot image

lianzaozi commented 3 months ago

The x and y scales of the above two screenshot blocks are both 2:1

svenhb commented 3 months ago

but because the elliptic arc was stored in the block with an Angle, which was 13.178191

This angle is given by ellipse.MainAxis coordinates. (Endpoint of major axis, relative to the center)

lianzaozi commented 3 months ago

YES,Does the current code include 13.178191 when calculating coordinates?

svenhb commented 3 months ago

Does the current code include 13.178191 when calculating coordinates?

Yes: Coordinates are Ellipse center: 407.181; 143.770 Mainaxis -386.528; 90.504 -386.528; 90.504 results to an angle of -13.17 image

lianzaozi commented 3 months ago

Hello, where are these logs stored?

image

svenhb commented 3 months ago

Go to the Data Path/logfiles: image

Or check path of last opened logfile: image

lianzaozi commented 3 months ago

I know why the problem happened,(double w = ellipse.AxisRatio * (double)scaling.Y/(double)scaling.X;) By default, the major axis of the ellipse is parallel to the X-axis of the coordinate system, and the minor axis of the ellipse is parallel to the Y-axis of the coordinate system, but if the ellipse in the block has an Angle, the value of the variable w is not correct, and I think it should be calculated by affine transformation company.

image

lianzaozi commented 3 months ago

.NET open source library for matrix operations, which I thought I might use when parsing ellipses

https://github.com/MKL-NET/MKL.NET

lianzaozi commented 2 months ago

I have pinpointed the direction of the problem, or did I encounter a problem while parsing the scaling of the elliptical block? Period If I set the scaling in the x and y directions separately, there will be problems. The problem caused by scaling in the x direction is greater

Sx: Scale in the x direction Sy: Scale in the y-direction Theta: Rotation angle

sx=0 16 test dxf(sx=0.16 sy=1 theta=0) sx=0.16.zip

sy=0 08 test dxf(sx=1 sy=0.08 theta=0) sy=0.08.zip

lianzaozi commented 2 months ago

I have identified the real reason for the incorrect parsing of ellipses and arcs within a block. The different scaling ratios in the X and Y directions are not the cause of this problem. The real reason is that if there are angles between the elliptical arcs and arcs within the block (the major axis of the ellipse is not parallel to the X direction of the coordinate system), this problem will occur

The difference between Ellipse 1 and Ellipse 2 in the ArSeg diagram is that Ellipse 1 has an angle within the block, while Ellipse 2 has no angle within the block; When inserting ellipses 1 and 2, the scaling ratios in the X and Y directions are different, but ellipses 1 are parsed correctly and ellipses 2 are parsed incorrectly 123

test dxf file 123.zip