dwgnest list of layer order

[estibalizEchevarria]

Hello Everyone!
When I run dwgnest, I provide a list of layers as input, using the command:
"~/opt/qcadcam-3.29.3-pro-linux-x86_64/dwgnest -f -sheets=bandeja -parts={} -n 20 -m 20 -a 0 -e 0 -i 10 -o {}_{}.dxf {}.dxf -platform offscreen".format(capas[1:], out_path.replace(" ","\ "), count, in_path.replace(" ","\ "))

-sheets=bandeja specifies the layer used for nesting.
-parts=capas[1:] provides a list of layers like this:

['Pieza7_1',
'Pieza7_2',
'Pieza7_3',
'Pieza7_4',
'Pieza7_5',
'Pieza7_6',
'Pieza7_7',.....]

Since all layers are identical, I assumed the layers inside would follow a specific order. However, the layers inside bandeja appear as follows:

['Pieza7_35',
'Pieza7_40',
'Pieza7_41',
'Pieza7_33',
'Pieza7_42',
'Pieza7_59',
'Pieza7_36',
'Pieza7_34',
'Pieza7_38',
'Pieza7_45',
'Pieza7_32',
'Pieza7_53']
What criteria does dwgnest use for selecting these layers? Is it possible to make dwgnest arrange the layers in a specific sequence, like this:

['Pieza7_1',
'Pieza7_2',
'Pieza7_3',
'Pieza7_4',
'Pieza7_5',
'Pieza7_6',
'Pieza7_7',
'Pieza7_8',
'Pieza7_9',
'Pieza7_10',
'Pieza7_11',
'Pieza7_12']
Thanks in advance!

out_10mm_1.dxf

nesting

(300.06 KiB) Downloaded 765 times

[CVH]

Hi,

I can't even verify 'However, the layers inside bandeja appear as follows:
35, 40, 41, ... 45, 32, 53 '

In the attached dxf file:
- Entities of Pieza7_36 are placed top left on the sheet.
- Entities of Pieza7_38 are placed bottom right.
- Pieza7_35 is at the left, the third one down.
- 12 out of 48 are placed, they match your list by number but are in a different order ...
... At the bottom it is 45, 53, 38 from left to right and that doesn't correlates with the order you listed in any way.
- Your last list is for only 12 ... Was capas[1:] 12 items or 48 items long?

Since all layers are identical, I assumed the layers inside would follow a specific order. However, the layers inside bandeja appear as follows:

It doesn't really matter if all layers (aka all parts) are identical.
The result is the best out of 10 iterations arranged at the bottom left with a default rotations of 4. (See command line syntax)
I don't think that there is 'A certain fixed order of nesting' and that it tests all parts in a random order.

Especially with arbitrary shapes, at random would yield the least amount of used space ...

For the record: Although the 48 parts would fit on the given sheet in a straight forward manner ...
... 4 rows of 13 parts straight up = 52 or 8 rows of 6 parts on their side = 48 ...
... On my first attempt it would take QCAD 239 trials to place them all without any exception using the QCAD/CAM GUI.
And that results in a random order and with random rotations.

Regards,
CVH

[estibalizEchevarria]

Hello @CVH
Thank you very much for the reply.
I've attached another example to provide more clarity. The capas[1:] is a list containing 60 layers. Here, the "bandeja" layer is fully packed with 49 pieces, and the following 11 pieces are left outside:
['Pieza7_40',
'Pieza7_41',
'Pieza7_50',
'Pieza7_33',
'Pieza7_54',
'Pieza7_34',
'Pieza7_52',
'Pieza7_55',
'Pieza7_39',
'Pieza7_38',
'Pieza7_53']

out_10mm_0 3.dxf

(300.96 KiB) Downloaded 685 times

I'm curious about why layers 1 to 49 aren't all contained within the "bandeja" layer. My implementation involves multiple nesting attempts until all pieces are allocated across different "bandeja" layers. Those left outside are placed in another nesting. However, with my CPU, the program slows down significantly if there are more than 100 layers to place.

Could we control the layer placement order to optimize and minimize the nesting attempts required? When working with identical shapes, optimizations are more straightforward, but arbitrary shapes lead to higher CPU usage and don't always yield the best packing.

Is there a way to establish a fixed nesting order?

Thanks in advance

[CVH]

Hi,

They are not '100 layers to place', they are entities that lives on 100 layers to place.
By definition not limited to one part on each layer and each part not limited to one contour.
By definition not limited to loose entities that form closed contours.

Those left outside are placed in another nesting

Why not defining more than one sheet?
At a certain point the time invested to optimize is no longer in relation with the achieved gain of using less material.
Production time will hardly reduce.

However, with my CPU, the program slows down significantly if there are more than 100 layers to place.

With more parts the number of permutations grows faster and faster, for 100 parts that are about 9.3 E+157 different permutations.
>> ... An integer value with at least 157 digits ...
It is not really the CPU or the system that slows down ... It is the workload that increases exponentially
Another thing to consider is the huge amount of (cached) memory that is required.

Could we control the layer placement order to optimize and minimize the nesting attempts required?

Is there a way to establish a fixed nesting order?

Counter productive ...
Part(n) would be chosen over smaller part(n+1) & part(n+2) or parts(n+10 to n+20) simply because of the layer they are on.
Even if part(n) is practically impossible to place or unfit to add on this sheet.

Nesting based on alphabetical layer order would mean: Place the first cluster of parts on the first layer in the left lower corner,
if it fits place the second cluster beside that, if it fits the third beside those , .... Until the next no longer fits or the sheet is full.

It is simply a constrain that would have adverse effects in many to most applications.
The random trial of parts ensures that every new trial may be more densely packed than any other before.

Are you aware that:
- Nesting 52 copies of Pieza7_0 in the former dxf is done within the first trial with success?
- Minor issue but absolute positions near 254.100,00 are less accurate simply because of the floating point number system?
At some point that starts to play a role when arcs need to fit at endpoints because they have no ending points.
Arcs are basically in polar notation and have end angles. Polar to Cartesian or in reverse is not exact.

... but arbitrary shapes lead to higher CPU usage and don't always yield the best packing.

Perhaps QCAD nesting is not really intended for this usage, there are probably better equipped, and also costly, other solutions.
Or maybe the plan of attack has to be revised, filtering on similar shapes, easy shapes, straightforward solutions, ....

The nest N times was also an advice in your former topic.

Regards,
CVH