Support Forum
Problem with our e-beam system
User
LayoutEditorFull
Friday 12th April 2019 Using GDS files created by the LayoutEditor are not fully exposed. Some rectangle are missing. GDS designs created with other tools work fine. What is the problem?
LayoutEditorFull
Friday 12th April 2019 Using GDS files created by the LayoutEditor are not fully exposed. Some rectangle are missing. GDS designs created with other tools work fine. What is the problem?
Jürgen
LayoutEditorFull
Friday 12th April 2019
Attachments:
(only for registered users)
setup.png
This is caused by the e-beam software that does not support box element in the GDS file. These box elements were introduced more than 30 years ago, but still not supported by all software tools. If this is the case, please activate the option 'box element are saved as polygons' under setup/fileformat/GDS before saving the design to disc. In that case all box elements are converted to polygons before and will be read correctly by your e-beam tool. 
LayoutEditorFull
Friday 12th April 2019
Attachments:
(only for registered users)
setup.png
This is caused by the e-beam software that does not support box element in the GDS file. These box elements were introduced more than 30 years ago, but still not supported by all software tools. If this is the case, please activate the option 'box element are saved as polygons' under setup/fileformat/GDS before saving the design to disc. In that case all box elements are converted to polygons before and will be read correctly by your e-beam tool. 
User
LayoutEditorFull
Tuesday 30th April 2019 Is there a way to push these sorts of changes back into whatever sets them up in the first place? Seems like settings changes in the GUI "don't stick" with just clicking "OK", across exit / restart. A complete initialization chain that the user or the project "owns", is what I would want. Taking this problem as an example, how would I change and then "freeze" this one checkbox change so it never comes undone, never needs to be remembered again (and again)?
LayoutEditorFull
Tuesday 30th April 2019 Is there a way to push these sorts of changes back into whatever sets them up in the first place? Seems like settings changes in the GUI "don't stick" with just clicking "OK", across exit / restart. A complete initialization chain that the user or the project "owns", is what I would want. Taking this problem as an example, how would I change and then "freeze" this one checkbox change so it never comes undone, never needs to be remembered again (and again)?
Jürgen
LayoutEditorFull
Tuesday 30th April 2019 All settings are stored with the shutdown of the LayoutEditor and restored with the next start of it. So a control/remembering of the setting is usually not required. However 'problems' can occur when running more than one instance of the LayoutEditor concurrently. Each instance of the LayoutEditor will have its own settings. Having the instances opened, the setting of the last closed design will be stored and used with the next restart. Changes in the setup with the other instances will not be respected.
LayoutEditorFull
Tuesday 30th April 2019 All settings are stored with the shutdown of the LayoutEditor and restored with the next start of it. So a control/remembering of the setting is usually not required. However 'problems' can occur when running more than one instance of the LayoutEditor concurrently. Each instance of the LayoutEditor will have its own settings. Having the instances opened, the setting of the last closed design will be stored and used with the next restart. Changes in the setup with the other instances will not be respected.
User
LayoutEditorFull
Tuesday 30th April 2019 What about the scenario where LayoutEditor is used serially, back and forth, for very different technologies / projects? This is where I've had trouble with other tools, "cross-contamination" of project specific settings (library paths, layers, etc.). So I am interested in absolute authority, on startup, and how to make everything explictly set regardless of recent history.
LayoutEditorFull
Tuesday 30th April 2019 What about the scenario where LayoutEditor is used serially, back and forth, for very different technologies / projects? This is where I've had trouble with other tools, "cross-contamination" of project specific settings (library paths, layers, etc.). So I am interested in absolute authority, on startup, and how to make everything explictly set regardless of recent history.
Jürgen
LayoutEditorFull
Wednesday 1st May 2019 If you use different technologies i recommend to use a macro doing all the required setup for one technology. Then you can switch between the technology just by calling a single macro.
LayoutEditorFull
Wednesday 1st May 2019 If you use different technologies i recommend to use a macro doing all the required setup for one technology. Then you can switch between the technology just by calling a single macro.
User
20190913
Friday 3rd May 2019 Exactly. This is what I'm after, a "bulletproof" initialization macro (or macro-chain) that leaves nothing to chance or to "cruft". But I am not finding documentation on the startup chain of events, autoload behaviors (search and choose which), default paths and path augmentation, shell variables and all that. Can you direct me to any of this? Is there, say, a template project management example (starting from .bashrc settings, to project home dotfiles, to macro invocations by command line or autoload-by-default-name - the whole chain of events, end to end, annotated)? If not maybe we can work through making one; it has to be helpful to others.
20190913
Friday 3rd May 2019 Exactly. This is what I'm after, a "bulletproof" initialization macro (or macro-chain) that leaves nothing to chance or to "cruft". But I am not finding documentation on the startup chain of events, autoload behaviors (search and choose which), default paths and path augmentation, shell variables and all that. Can you direct me to any of this? Is there, say, a template project management example (starting from .bashrc settings, to project home dotfiles, to macro invocations by command line or autoload-by-default-name - the whole chain of events, end to end, annotated)? If not maybe we can work through making one; it has to be helpful to others.
Jürgen
LayoutEditorFull
Saturday 4th May 2019 The LayoutEditor does not use any shell variables, .bashrc, and project paths. Anything that can be setup is done in the setup dialog and can be set by a macro with the class *setup*. The LayoutEditor is shipped with a factor default macro, that switches anything back to the default. Maybe this is a good starting point for your macro. The only exception where a shell variable is used are OpenAccess extensions like PyCell. Here a *CNI_ROOT* environment can by used to set the used OpenAccess library when it is activated in the setup.
LayoutEditorFull
Saturday 4th May 2019 The LayoutEditor does not use any shell variables, .bashrc, and project paths. Anything that can be setup is done in the setup dialog and can be set by a macro with the class *setup*. The LayoutEditor is shipped with a factor default macro, that switches anything back to the default. Maybe this is a good starting point for your macro. The only exception where a shell variable is used are OpenAccess extensions like PyCell. Here a *CNI_ROOT* environment can by used to set the used OpenAccess library when it is activated in the setup.