How to detect a 'usable' layer?

Am 13.02.2020 um 22:09 schrieb leo potjewijd:

running 5.12.0

Inside an ULP I want to know what layers in a board are available.

When I loop through the layers in a board with an ULP (like: board(B) B.layers(L) {some code using L} ) I get all signal layers (with 2-15 always marked as hidden); the layer list in the board editor only shows the ones defined in the DRC.

When a script tries to access one of the layers not listed in the editor, an error pops up stating that that layer is not available (which is IMO correct) and continues to use the next available layer.

 

Is there a way for an ULP to detect if a hidden layer is just hidden or not available at all, to prevent this from happening in a generated script?

 

--

To view any images and attachments in this post, visit:

https://www.element14.com/community/message/288316

 

Layers available depends on your license. In a professional license all

layers (16) are available, but in your DRC setup you decide which of

those are useable and which are hidden.

In Standard and other Licensees amount of layers (and other things) are

limited.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

I know that (running full pro license), but how can an ULP distinghuish between a usable and an unusable layer?

What are you trying to achieve with this ULP?. What's the problem it will solve for you? I suspect there may be a different approach possible.

You cannot determine the layers available by cycling through the Board object. As you have noticed, they are all listed there. You can only report if a layer is unused (dirty) and if it is being displayed (visible) or not.

Which layers you can you can write to depends on the Eagle Edition you have.

Which layers are shown with a ulp by cycling through the Board object. depends on the Edition and the source of the board file. In the Light version , a board started there only returns layers 1 and 16. But I can load a 2 layer board made in a 16 layer edition and it returns 16 layers.

Note that you can open a 16 layer board in the Light (2 layers) version. You see the full design (16 layers in the layer drop down) but in the Light version you can only edit layers 1 and 16.of that design.

Even reading the layer setup in the DRC does not help because that can be for a 2 layer board in a 16 layer capable edition. and visa versa.

So for a script that must run on different editions, it must determine which layers are valid for that edition.

Are you are saying that a 'usable layer' must be a layer quoted in the DRC layer setup ?

OK, replying again.

Assuming you want to get the  DRC layer setup e.g. (1*16) or maybe its (1+2*15+16)

It lives in the .brd file and you have to parse the board file to extract it.

This is easier in later versions because they are human readable. v5.12 is binary, but it appears you get lucky. You can see plain text in some of it and I can see the info you need.

Open the board file in a text editor and search for </language

A few characters after that you will see the familiar DRC layer setup e.g. (1+2*15+16)

HTH

Warren

This ULP I'm working on is to import a DXF file into an Eagle object; be it a board, schematic, symbol or package.

It offers a choice of what and how to import, a choice for the layer to put it on, various scaling and offset options and in a library environment a choice for the package or symbol to put it in ('new' being an option).

This all functions well, except for the layer list in the board environment: you can select a layer that is not in the DRC list (and thus not editable).In that case the generated script fails and I want to prevent that.

Generating a correct layer list for the package, symbol and schematic is easy enough: all layers reported by the layer() loop are fair game (barring the obvious nogo ones).

In the board the DRC setup complicates matters, since it effectively 'cancels out' some of the reported layers.

Parsing the board file in the ULP is an option: I know what to look for; I just hope that it can be avoided.

I was (and still am) looking for an easier way to produce the correct layer list to choose from in a board environment...

Here's a way if you wish to avoid deducing the regular expression to extract the layer setup from the board file. .

You can save a DRC file and it's in clear text .

The first line in the saved file, after the description of the DRC, is the data you need and looks like this, for example:

layerSetup = (1*16)

So you have the ULP be one that runs twice when the editor is a board or run in a schematic and you use 'project.board' to perform actions on the board if the board editor is also open.

In the first pass the ULP builds the editor commands to save the DRU file and call itself again .

In the second pass, you already know where you put the saved file and what it's called so you open the DRU file and extract the layer setup.

Read the DRU into array.

Move through the array until yuo find one that starts 'layerSetup'

Take everything after the '='

Remove white space from that string and you have the setup e.g. [3:(1+(2*3)+(4*5)+(6*7)+16):6]

Then extract the numeric layers form that string.

HTH

Warren

Well, I bit the bullet so to speak and hacked a bit into the binary (after all, the board file is the only thing I'm certain of when the ULP is running)...

In short, it turns out that the binary is structured into records of 24 bytes; the first byte being the record type: type 0x13 is a layer definition where byte 3 is the layer number.

Byte 2 contains flags: bit 0 tells if the layer is valid for this editor and bit 1 tells if the layer is editable (active).

The layer name is only inside the record if it is 9 characters or shorter (and not easy to extract otherwise), but a layers() loop will get the name easy enough.

This functions well, although this may not work as expected if the Eagle license does not allow all layers listed in the board's DRC (I have currently no way of testing this).

From what I see in later versions that use the easier to parse XML format, the critical layer parameter there is "active" (albeit that I do not have much to compare here).