How to detect a 'usable' layer?

Question

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; the layer list in the board editor only shows the ones defined in the DRC.The ones not defined in the DRC are reported as hidden to the ULP.

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?

WarrenBrayshaw · Answer

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

fatbeard · Answer

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

WarrenBrayshaw · Answer

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