Parse MPD description line on insert MULTI_STEP BEGIN command

[technicbasics]

Subject

In the BOM, some submodels are show as complete part.

Environment

• Version of LPub3D - 2.4.7r52
• Operating system - Windows 11, Home Edition 64bit Processor 11th Gen Intel(R) Core(TM) i9-11900H @ 2.50GHz 2.50 GHz RAM 16,0 GB Grafik NVIDIA RTX 3600, 6GB

Model files are located in our sharepoint. If you no longer have the link, let me know and I'll send a new one.

[technicbasics]

Update: Almost all sub-models are now displayed in the BOM. Version: 2.4.7r53 also 2.4.7r52

[trevorsandy]

Thank you for reporting this behaviour.

Is this behaviour new for you on 2.4.7r52 ?

I'll take a look.

Cheers,

[technicbasics]

Hi Trevor

Here a small list of versions and there behaviour: Render type: Native, Last file version is in the cloud.

2.4.6.352 --> crash 2.4.6.363 --> crash 2.4.7.0 --> crash 2.4.7.5 --> crash 2.4.7.19 --> same behaviour 2.4.7.29 --> same behaviour 2.4.7.52 --> same behaviour 2.4.7.53 --> same behaviour

Crash window:

Do you need anything else?

Johann

[trevorsandy]

Hello Johann,

all sub-models are now displayed in the BOM.

So if I well understand, you have been seeing this behaviour since 2.4.7.19 ?

Do you need anything else?

I downloaded the latest bundle from your cloud repo - Thanks.

Cheers,

[technicbasics]

So if I well understand, you have been seeing this behaviour since 2.4.7.19 ?

I didn't tested it before, with models. But I think, it's a problem with my file, because with the "Pisten Bully" file it's work's fine. (2.4.7r52) But i am not sure, if the part count is correct. (no cross-check performed) I have uploaded the Pisten Bully file also in the cloud.

[trevorsandy]

But I think, it's a problem with my file, because with the "Pisten Bully" file it's work's fine. (2.4.7r52)

I saw the following lines that may present unexpected behaviour as the current page definition 0 !LPUB MULTI_STEP BEGIN starts before the submodel header (Name, Author) is completely parsed:

0 FILE submodel-56.ldr
0 !LPUB MULTI_STEP BEGIN
0 [redacted]
0 Name: subModel-56.ldr
0 Author: [redacted]
0 !LICENSE Redistributable under CCAL version 4.0 : see CAreadme.txt

Try placing the MULTI_STEP BEGIN meta command after the header meta commands.

Submodel-56.ldr is the 8th part down on the left-most column.

Cheers,

[technicbasics]

Hi Played a lot around... Adding Multi step command by using right mouse click and "Add next step" have two different behavior: Normal model: and if the model begins with a "ROTSTEP"

After a long search why this is so, i found the solution. This behavior is shown, if the file was cleanuped with LDCad and the header option "Official order" is enabled. This has the consequence that an empty line is inserted after the header, which in turn has the consequence that when the submodel is called in LPub3D, the file is marked in the first line. (See first picture). If this empty line is not present, or the file begins with a "ROTSTEP" the file is marked before the first part. The generated "MULTI_STEP" command is inserted exactly at this mark. This explains at least once why the "MULTI_STEP" command has slipped into the header. Now that I have moved the "MULTISTEP" lines down before the first part in all submodels, the behavior of the BOM is exactly the same as in the first two pictures at the beginning. What is strange is that the parts in the BOM are created in different colors. This explains at least once why the "MULTI_STEP" command has slipped into the header. Now that I have moved the command down before the first one in all submodels, the behavior of the BOM is exactly the same as in the first two pictures at the beginning. It is also noticeable that the parts in the BOM are created in different colors. For example, Submodel 5 that was inserted into the model both times with the color "16", is shown in the BOM in black and lbg. The other two submodels are displayed in the colors they were inserted with.

So, that's it for now, maybe I'll get to some more tests tomorrow.

Johann

[trevorsandy]

Thank you for the update.

It is also noticeable that the parts in the BOM are created in different colors

Can you attach a copy of the LPub3D log - see Help->View Runtime Log...

Cheers,

[technicbasics]

LPub3DLog.txt.zip

[technicbasics]

After a long search why this is so, i found the solution. This behavior is shown, if the file was cleanuped with LDCad and the header option "Official order" is enabled. This has ....

command back: It is not the blank line that is the problem, this is automatically removed by LPub3D when loading the model. The problem is the option "Sync description" when clean up the file with LDCad, this inserts a line with the description. If this line is present, LPub3D jumps to the wrong line when loading the submodel.

[trevorsandy]

Indeed. The routine to insert a MULTI_STEP BEGIN command did not take into account a description line at the start of a multi-part document (MPD) file since descriptions are usually only present on parts. A description line is defined in the Official Library Header Specification - for parts. The MPD format does not specifically define a description line. Nevertheless, as one can choose to include this line in MPD files, I've updated the parse routine to take it into account.

This behaviour has been corrected.

Cheers,

[technicbasics]

..... A description line is defined in the Official Library Header Specification - for parts. The MPD format does not specifically define a description line. ...

The description line is defined in the OMR Header Specification. https://www.ldraw.org/article/593.html

For this reason, the Cleanup function has been integrated into LDCad to adjust model files for the OMR.

But back to the original problem, there are still some submodels displayed in the BOM. Do you know why this is?

[trevorsandy]

The description line is defined in the OMR Header Specification.

I was checking the MPD specification; I didn't see the OMR specification. So indeed. this correction was necessary.

But back to the original problem, there are still some submodels displayed in the BOM. Do you know why this is?

I'll take another look.

Does Submodel-56.ldr still appear in the BOM ? If no, can you identify by FILE name some specific submodels that continue to appear in the BOM ? This will make my debug much faster than having to parse and generate a BOM for the entire large model file. Thanks.

Cheers,

[technicbasics]

Hi Trevor

Currently following submodels are shown: submodel-2 submodel-5 (in two different colors) submodel-3

[technicbasics]

But it looks like I have the problem only with this model file. With the Pisten Bully it seems to work correctly.

[trevorsandy]

But back to the original problem, there are still some submodels displayed in the BOM. Do you know why this is?

After a careful review, I was able to isolate and correct this behavour.

I moved this behaviour content to it's own ticket. You can see details in #739.

Cheers,