BUG; Odd behaviour creating toolpath

[HJ Seef]

In addition to the Topic "Odd behaviour creating toolpath", I have done the same job all over again.

Unfortunately is the odd behaviour reproducable, and therefore a bug.

[CVH]

Hi,

A reproducible bug is best reported using QCAD Bugtracker
You need to file for an account there because it is not related to the forum account.


Whether it is resolved depends on goodwill, time and how many users that might be affected.
Perhaps it can be fixed but I am about certain that the origin is not to be found in the CAM resources.
If vectorTo(), angleTo() and other similar low level resources are already so and so ...

As said, OQ works but that might also fail in certain places, especially with a multi offset.
For OQ the solution is to scale the project up and scale it back down with the results.
Then you can still add profiles 'On path' from the results.

For things in CAM blocks, on CAM layers or simply in 3D, scaling is not an option.
Neither are CAM properties stored in the document, block, layer or CAM entity scaled up and back down.


Unless you use my micron approach, where the CNC-driver thinks that the G-code in mm is.
For that my axis-drivers are also fooled to step in microns per unit.

Regards,
CVH

[CVH]

In addition to the Topic "Odd behaviour creating toolpath", I have done the same job all over again.

Starting over, re-doing on a new copy, reloading a saved file, moving it all a fraction of a unit can have an influence.

I have a file with a Hatch that posed no problem before.
Until I saved and opened it for the Nth time and now the patterned fill is incorrect for one horizontal level.
Redone the Hatch from original data and the rendering of the pattern is fine again.

One reason is that data is stored in DXF with not more than 16 significant decimal digits.
Theoretically the 10 based log of 2 to the power 53 or approximately 15.95... decimal digits on average.
Or that there is 0.3% chance that the recorded 16th decimal digit is incorrect.
In reality and in the current running session 15-17 decimal digits, all disregarding the location of the decimal point.

It are numbers like 0.100 that are the bigger problem because they can not be represented in binary.
0.1 + 0.2 is almost but less than 0.3 and a test for equal, larger or smaller must account for that.

However, the more calculations, the more the uncertainty of an intermediate result grows.
Like entropy the uncertainty can only increase.
Deviating from is equal, is less or is more varies per value and increases as the uncertainty increases.
A larger fixed build in tolerance for comparing only works up to a point.

Regards,
CVH

[CVH]

When we explode the shapes on layer B_CU using nothing more than the same resources as QCAD/CAM does ...
... Current result is far better than the original boundaries. Nice work .
... One can still detect some peculiarities.
- Line segments with a 360° angle or exactly 2Pi.
- Non-reversed CCW Arcs with a starting angle of 360° or exactly 2Pi.
- Reversed CW Arcs with an ending angle of 360° or exactly 2Pi.

You can filter them out with the QCAD Selection Filter but that method has some tolerance.
I do filter them script based and then on larger than 6.283185307179585 what is just not quite 2Pi.
Not that exactly 2Pi does not exist using 53 binary bits.

Is that an error? No, not really because normalized those orientations would be zero.
But then the resource that masters these must normalize angles and not all intermediates are normalized or treated as not-normalized.
The flaw sits here: FS#2703 The calculation of a vector its angle.

Code: Select all

RLine -> startVertex.getAngleTo(endVertex) = (endVertex - startVertex).getAngle()
RArc -> centerVector.getAngleTo(endingVertex) = (endingVertex - centerVector).getAngle()

For that we unify the resulting vector and use acos(dX) to get an angle in quadrant I or II.
Basic trigonometry, the cosine of the enclosed angle is dX divided by the hypotenuse, here the vector length or 1.0 unified.
When dY is negative it must be projected to quadrant III or IV.
Correction: When the unified dY is negative it must be projected.

The difference: |result_dY| might be very near zero and thus result_dY slightly negative.
Unified dY = result_dY / radius and very near zero becomes zero for a meaningful Line or Arc or minus zero in the worst case.

As is: While dX is treated as unified, dY is treated as not unified and typically much larger in absolute.
It takes one division extra to fix things and comparing with zero or any number must account for a machine epsilon or other tolerance.


Agreed, extra calculations and thus a fraction slower for every RVector.getAngle().
But you could compensate that with eliminating:

Code: Select all

double dp = getDotProduct(*this, RVector(1.0, 0.0));

dp is nothing more than the vector (*this) its X value.
And that because Y and Z are ruled out by a valid RVector(1.0, 0.0) = RVector(1.0, 0.0, 0.0, true)

Code: Select all

double dp = v.x * 1.0 + v.y * 0.0 + v.z * 0.0

In my book that is simply equal to the X value of the vector.

The real solution is RVector::getUnitVector() what are 3 divisions, a test on valid, a root, 3 multiplications and 2 additions.
A bit clumsy when the magnitude m of the vector is already known.

In the mean time I would not divide dp by m three consecutive times.

Regards,
CVH