-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot set Value2 with AscEditor #46
Comments
Hello @hb020, This one is a tricky one. This requires some code updates. I'll let you know when I have a solution for it. Best Regards, |
There is a comparable functionality mismatch with the setting of the model of a device, like an opamp. With SpiceEditor, I can say set_component_value("XU1", "OPAx189")
There are 2 options: make asceditor and spiceeditor having the same interface, or make asceditor follow the LTSpice model closely. I am making a tool that uses the 2 editors interchangeably, so I selfishly would prefer the first option. But I do understand the rationale behind the second option: it is the most clean, provided the other simulators behave like ltspice. |
I have committed into the branch v1.1.3 a version that tackles this problem. The Value and Value 2 are joined together into a single parameter. This works because when writing back to the .asc file, the LTspice is smart enough to redistribute the values again between Value and Value2. It suffices to read the file and save it. Regarding the comment of having the consistency between all editors. That has been my goals since I've started supporting more than one simulation tool. However, I must draw a line in some cases. In order to achieve that, some assumptions need to be made, and they may not always be correct. I have also introduced two new methods. set_component_parameters() and get_component_parameters(). Cheers, |
Closing this issue since 1.1.3 is already the current version. |
Hello @nunobrum I updated to the latest version 1.1.3 of spicelib In my schematic, I use the generic OpAmp (level 2) schematic included with LTSpice. The Schematic contains these lines:
When the asc file is read with AscEditor, the symbol is read and parsed correctly
I would like to edit the "Value2" attribute of the schematic to change the Avol, GBW and Slew parameters, like it's possible to do by using CTRL+A in the Symbol Editor: The component associated with the InstName "U1" however is read in as a subcircuit: print(opamp_circuit.get_component_info("U1"))
And I can list the subcircuits' components individually: print([opamp_circuit.get_subcircuit("U1").get_component_info(elem) for elem in opamp_circuit.get_subcircuit("U1").get_components()])
But I cannot see the "Value2" of that OpAmp model and the new method get_component_parameters returns an empty dict: print(f'{opamp_circuit.get_component_parameters("U1")}')
For reference, using LTSpice, I am able to see those parameters in the generated netlist that is available after running the simulation:
Am I misunderstanding the usage of the AscEditor class? Thank you Nuno |
On a non modified subcircuit, Once you modified some of the attributes, you should in theory be able to see something like this in the ASC file:
and this when you call
Asc files use 4 groups of parameters: "Value","Value2,"SpiceLine","SpiceLine2".
So:
Note that if you use |
There are 2 possible improvements here:
@nunobrum, what do you think of that? |
Imagine this circuit:
The problem is that I can find GBW in the opamp ( |
Hello All, The analysis done by @hb020 is correct. AscEditor as of today identify the parameters that do not yet exist on the .asc file. On the improvement propositions @hb020, I think they came as a natural consequence of the having the AscEditor return a SpiceSubcircuit instance. However, I do think that the implementation as it is today, kind of violates the very basic design principle of encapsulation. Now we are going in the direction of having components, inside sub-circuits inside a non sub-circuit object. In my view this obliges us to take a look back into the structure of classes we have in place. Moving forward, I think this pushes the design in the direction of having components as an object on its own. Instead of or instead of
I have reopened this issue, so we can discuss these ideas. Since this is a very huge step away from the current concept, this needs to be very well thought of. |
In what regards AscEditor, I think we should limit ourselves to what we can find on the netlists. We can create an interface to the user to set not known attributes, but, it should ultimately up to the user to manage it. |
Agree, as this risks taking us down a deep rabbit hole. What about ngspice compatibility for example? The main goal was to make netlists modifiable. If we want to maintain GUI functionality compatibility, then that is entirely other goal. To me, it is entirely justifiable to say "You can use the AscEditor for simple things, but full functionality is only available with the netlist editor that is SpiceEditor.". We will have to make it explicit and explain what the limitations are. We can of strive to make these limitations minimal, but there will be. |
Totally agree. The AscEditor came out of the fact that LTSpice didn't create a netlist on the mac platform. Since I had experience with .asc files(**) , it seemed a fun thing to do to be able to also modify schematics. This would allow adding Montecarlo or Worst Case Analysis testbenches to a schematic, and still enjoy the benefits of the LTSpice GUI to analyse data. (**) another project I have which exports and imports .asc to Altium Designer. |
Coming week I plan to work a bit more on Linux/MacOS compatibility (and logging of that), and I can add some explanations of the limitations of AscEditor (will do in another branch, and that will be mainly in readme.md). |
I have just pushed a new branch called component-object where a new Component Class is introduced and makes all the manipulations that are related with components. This now allows this I'll merge this back to the main when this approach is also implemented on the remaining Editors. |
looks good. Just afraid that doing it for AscEditor is going to be complicated. |
Holidays and a lot of work slows this implementation. |
This was finally integrated in v1.2.0 |
There is an incoherence between SpiceEditor and AscEditor:
SpiceEditor
handles all components of the values of a component as one value, and they can be set viaset_component_value
.AscEditor
has properties "Value" and "Value2". The latter has no possibility to be set.Example: "V3 0 AC 2": that is a Voltage source of 0 volt, but with AC small signal analysis voltage of 2.
With SpiceEditor, the value of V3 = "V3 0 AC 2". If I do
set_component_value({"V3":"0"})
, the AC part disappears.With AscEditor, the value of V3 = "0", and Value2 = "AC 2". If I do
set_component_value({"V3":"0"})
, the AC part remains intact, and there is no possibility to modify it.Question:
AscEditor.set_component_value()
set all sections of a value, just likeSpiceEditor.set_component_value()
?The text was updated successfully, but these errors were encountered: