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

[lianzaozi]

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.

Screenshot of CAD software

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

[svenhb]

Thanks again for finding a bug 😉
I found the problem, will release a new version soon.

[svenhb]

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

[lianzaozi]

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.

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.

[svenhb]

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".

[lianzaozi]

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

[svenhb]

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]

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.

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]

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

[lianzaozi]

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

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

[lianzaozi]

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.

[svenhb]

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]

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

[lianzaozi]

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

[lianzaozi]

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

test dxf file
1 - (2).zip

[lianzaozi]

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]

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]

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]

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:

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

Then check "Avoid G2/3"

[lianzaozi]

Thank you

[lianzaozi]

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

[svenhb]

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".

[lianzaozi]

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]

Yes

[lianzaozi]

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

[svenhb]

Then perhaps an other option was also enabled?

[lianzaozi]

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

[svenhb]

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

[svenhb]

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]

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]

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

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

test file
1 - (2) -.zip

[lianzaozi]

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]

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]

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]

How to output these logs

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

[svenhb]

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

[lianzaozi]

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

[lianzaozi]

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

What does the variable a represent below???

[svenhb]

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]

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?

[lianzaozi]

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

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

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

[lianzaozi]

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

[svenhb]

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]

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

[svenhb]

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

[lianzaozi]

Hello, where are these logs stored?

[svenhb]

Go to the Data Path/logfiles:

Or check path of last opened logfile:

[lianzaozi]

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.

[lianzaozi]

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

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

[lianzaozi]

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

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

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

[lianzaozi]

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

test dxf file
123.zip

[svenhb]

I assume the current order is wrong: now 1st I apply xy scaling to the ellipse-properties, then I calculate the ellipse points.
I will try to calculate ellipse points 1st, then apply xy scaling - but it is a huge work.

[lianzaozi]

Firstly, obtain the coordinates before scaling, then use matrix operations to calculate the scaled coordinates, and then use the calculated coordinates to form a transformed ellipse. As I am not very familiar with programming, I can only provide you with the conclusion I have drawn after verification in CAD to provide you with an idea

[svenhb]

I hope now it is correct, check https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_Setup_1731g.exe

[svenhb]

There is still a bug for circle with blockScaling.X != blockScaling.Y. But the fundamental problem has been found...

[lianzaozi]

Thank you for updating the software. I will conduct some necessary tests.

[svenhb]

Should be fixed now: https://github.com/svenhb/GRBL-Plotter/releases