Now that a basic control interface is ready, I can begin with the power electronics library. Main focus would be on the diode and IGBT (or simply an ideal switch). With these, the intent would be to start rigorously testing the circuit solver. Something which I put off before because I wanted to get to the power electronics library ASAP.
A basic problem has arisen particularly in the solving of stiff equations. A single phase diode bridge rectifier threw this error up. It it in the way the loops are rewritten whenever a diode turns on and off.
Found out the problem this afternoon and will figure it out tomorrow.
Thursday, May 23, 2013
Wednesday, May 22, 2013
Version 0.2.0 released
Releasing version 0.2.0 with controlled voltage source as library element.
http://sourceforge.net/projects/pythonpowerelec/
Just realized while moving version 0.1.5 to the archives that the zip archive was empty. Added another zip file in the archives. In case of doubts, email to pythonpowerelectronics@gmail.com.
http://sourceforge.net/projects/pythonpowerelec/
Just realized while moving version 0.1.5 to the archives that the zip archive was empty. Added another zip file in the archives. In case of doubts, email to pythonpowerelectronics@gmail.com.
Controlled Voltage Source
Think I got a basic code working for a controlled voltage source. To begin with here is the code for the class (click on "view raw" below the code box to see the code in a new window):
The only difference between a normal voltage source is that it has two lists control_tag and control_values. The control tag is the name of the control input and the corresponding index in the other list is its value. These are lists because there can be multiple control inputs to any controllable device.
Next in the main program "circuit_solver.py". The first stage is to get the names of the control codes from the user. Then generate "descriptor" files for each of these control codes. Check if they exist. If they don't create blank templates (check the previous blog entry). This is the code (click on "view raw" below the code box to see it in a new window):
The next step is to take in the descriptor parameters. These will be used to update the dictionaries for the inputs, outputs, staticvariables and time events. Here is the code (click on "view raw" below the code box to see it in a new window):
The next step was a bit tricky. The idea is to write all these different control codes into one main program called __control.py and import this file. Each control code will be written as a function.
So basically, define the function, assign the input to variables, assign the static variables to local variables, assign the time events to local variables. And then finally embed the control code. Then assign the local variables to outputs, reassign local variables to static variables and time events as applicable to take these back to the main program.
Here is the code (click on "view raw" below the code box to see it in a new window):
Anyway, a basic circuit with a controlled voltage source works. So I'll just release this as the next minor version.
The only difference between a normal voltage source is that it has two lists control_tag and control_values. The control tag is the name of the control input and the corresponding index in the other list is its value. These are lists because there can be multiple control inputs to any controllable device.
Next in the main program "circuit_solver.py". The first stage is to get the names of the control codes from the user. Then generate "descriptor" files for each of these control codes. Check if they exist. If they don't create blank templates (check the previous blog entry). This is the code (click on "view raw" below the code box to see it in a new window):
The next step is to take in the descriptor parameters. These will be used to update the dictionaries for the inputs, outputs, staticvariables and time events. Here is the code (click on "view raw" below the code box to see it in a new window):
The next step was a bit tricky. The idea is to write all these different control codes into one main program called __control.py and import this file. Each control code will be written as a function.
So basically, define the function, assign the input to variables, assign the static variables to local variables, assign the time events to local variables. And then finally embed the control code. Then assign the local variables to outputs, reassign local variables to static variables and time events as applicable to take these back to the main program.
Here is the code (click on "view raw" below the code box to see it in a new window):
Anyway, a basic circuit with a controlled voltage source works. So I'll just release this as the next minor version.
Control interface - code
Here's the code for just the basic design of the control interface (click on "view raw" to view it in another window):
Tuesday, May 21, 2013
Control interface design
I have been thinking of how the control interface would be like for the user. A user needs a few essentials:
1. An easy way to define inputs, outputs. So, in the same was you would join an ammeter output to an in-port, you need to be able to define such a connection and use the variable inside the code. Also, the output of a block should be connected to a controllable device. In case the controllable device has multiple controls, the user should be able to define which controls get what variables.
2. Time events: The simplest thing to do would be to define a constant sampling frequency but this would make multi-rate sampling impossible. Also, ideally, the user should be able to decide when the code will run next. As a reference, the user will be given the current simulation time as t_clock. Really, that is also not needed, because the user needs to define "after" how much time the control code will run again and not "at" what time the control code will run again.
3. The nature of the code: One of the reasons for using Python was to be able to combine some of the other efforts in signal processing, linear algebra etc that are happening and give the user the chance to write advanced control code. So the user can write anything that is valid code. For that matter I am not sure if it is possible to embed a C program/function within a Python program. But if that is possible, why not? Essentially, anything that you can do in Python in general.
So this is what the code I have written has designed so far.
1. Take from the user the name of the control files that he wants to use. For every control file, there will be a "descriptor" file with a _desc. This will be a CSV file. This file contains four keywords - "Input", "Output", "StaticVariable" and "TimeEvent".
2. As a framework, a sample of all these will be provided in every descriptor file. So there will be one of each to tell the user how to do the rest.
3. An "Input" will be from a meter. So the user will need to specify the name of the meter as in the circuit spreadsheet and the variable name by which they want to refer to it in the control code.
An "Output" will be at a controllable device and additionally a control tag to account for devices that have multiple control inputs and finally the variable name in the control code.
"StaticVariables" will be variables that will continue to be available with their latest values in the control code. So these will passed back and forth with the main program. All other variables used in the code will be temporary and will exist only in the control code (local variables).
"TimeEvent" will be when the code runs next. Here not fully sure what to do. Supposing there are multiple blocks of code the user wants to execute at different rates - say 100 microseconds and 145 microseconds. The user can define two time events. A simple way would be let the user take the simulation time in the form of "t_clock" and compare t_clock with the time events. A more elaborate way would be define any tevent as tevent=tevent+x. x could be constant or variable. And tevent can be initialized by the user.
4. With every control file, there will be a descriptor file. So there can be multiple control codes.
5. Once this is defined, the user writes the control code. The program takes the control code, embeds it inside a function and maps the inputs, outputs etc to variables passed from the main program. All this will be written automatically into another program with any import statements the user includes. This program will be imported by the main program and the functions will be executed automatically.
So this is the plan. Steps 1, 2, 3 and 4 are done. The code is almost ready and I need to think over it. Step 5 will then follow.
1. An easy way to define inputs, outputs. So, in the same was you would join an ammeter output to an in-port, you need to be able to define such a connection and use the variable inside the code. Also, the output of a block should be connected to a controllable device. In case the controllable device has multiple controls, the user should be able to define which controls get what variables.
2. Time events: The simplest thing to do would be to define a constant sampling frequency but this would make multi-rate sampling impossible. Also, ideally, the user should be able to decide when the code will run next. As a reference, the user will be given the current simulation time as t_clock. Really, that is also not needed, because the user needs to define "after" how much time the control code will run again and not "at" what time the control code will run again.
3. The nature of the code: One of the reasons for using Python was to be able to combine some of the other efforts in signal processing, linear algebra etc that are happening and give the user the chance to write advanced control code. So the user can write anything that is valid code. For that matter I am not sure if it is possible to embed a C program/function within a Python program. But if that is possible, why not? Essentially, anything that you can do in Python in general.
So this is what the code I have written has designed so far.
1. Take from the user the name of the control files that he wants to use. For every control file, there will be a "descriptor" file with a _desc. This will be a CSV file. This file contains four keywords - "Input", "Output", "StaticVariable" and "TimeEvent".
2. As a framework, a sample of all these will be provided in every descriptor file. So there will be one of each to tell the user how to do the rest.
3. An "Input" will be from a meter. So the user will need to specify the name of the meter as in the circuit spreadsheet and the variable name by which they want to refer to it in the control code.
An "Output" will be at a controllable device and additionally a control tag to account for devices that have multiple control inputs and finally the variable name in the control code.
"StaticVariables" will be variables that will continue to be available with their latest values in the control code. So these will passed back and forth with the main program. All other variables used in the code will be temporary and will exist only in the control code (local variables).
"TimeEvent" will be when the code runs next. Here not fully sure what to do. Supposing there are multiple blocks of code the user wants to execute at different rates - say 100 microseconds and 145 microseconds. The user can define two time events. A simple way would be let the user take the simulation time in the form of "t_clock" and compare t_clock with the time events. A more elaborate way would be define any tevent as tevent=tevent+x. x could be constant or variable. And tevent can be initialized by the user.
4. With every control file, there will be a descriptor file. So there can be multiple control codes.
5. Once this is defined, the user writes the control code. The program takes the control code, embeds it inside a function and maps the inputs, outputs etc to variables passed from the main program. All this will be written automatically into another program with any import statements the user includes. This program will be imported by the main program and the functions will be executed automatically.
So this is the plan. Steps 1, 2, 3 and 4 are done. The code is almost ready and I need to think over it. Step 5 will then follow.
Thursday, May 9, 2013
Next step - controlled sources and power electronics
The thought of spending the next few weeks sorting out the exception handling put me off completely. So I decided to skip that stage and move on to expanding the library instead. Whats the point of having my own project if I can't do what I want?
So, now designing the interface for a controllable object for example a controllable voltage source. The primary objective with this software is that an advanced user should be able to code whatever he wants as the control code. Taking my requirements specifically, I would like the control code that I write to be able to translate into a C program that I can compile into a DSP.
So, with any controllable object, what are the major interface requirements?
1. Inputs - preferrably in the form of meaurements from meters
2. Control outputs - can be defined in the parameter specification sheet.
3. An event generator - when must the control values be updated.
With no. 1 and no. 2 the objective will be that the user should have convenient interface to access the outputs of measurement meters and update the controls without getting too much into the way objects are defined. So this means, I would have to add another layer between the "component_objects" dictionary in the main circuit_solver.py and the control code. So the next question, how will this interface be decided? In most simulators, input ports are defined and these are connected to signals in the outer layer. This might be one way to design an interface. Ask the user to choose what are the inputs to the control code.
With no. 3 the purpose of an event generator is that different objects have to be upated at different rates - i.e multi-rate sampling. So the control code must execute when the object with the nearest update time is called. Also, how to ensure that objects are updated only when necessary?
So, now designing the interface for a controllable object for example a controllable voltage source. The primary objective with this software is that an advanced user should be able to code whatever he wants as the control code. Taking my requirements specifically, I would like the control code that I write to be able to translate into a C program that I can compile into a DSP.
So, with any controllable object, what are the major interface requirements?
1. Inputs - preferrably in the form of meaurements from meters
2. Control outputs - can be defined in the parameter specification sheet.
3. An event generator - when must the control values be updated.
With no. 1 and no. 2 the objective will be that the user should have convenient interface to access the outputs of measurement meters and update the controls without getting too much into the way objects are defined. So this means, I would have to add another layer between the "component_objects" dictionary in the main circuit_solver.py and the control code. So the next question, how will this interface be decided? In most simulators, input ports are defined and these are connected to signals in the outer layer. This might be one way to design an interface. Ask the user to choose what are the inputs to the control code.
With no. 3 the purpose of an event generator is that different objects have to be upated at different rates - i.e multi-rate sampling. So the control code must execute when the object with the nearest update time is called. Also, how to ensure that objects are updated only when necessary?
Sunday, May 5, 2013
Version 0.1.5 released
Version 0.1.5 released.
http://sourceforge.net/projects/pythonpowerelec/?source=navbar
Also, just in case, since some of the blog may be written in a cryptic manner, specific questions can be directed to pythonpowerelectronics@gmail.com
http://sourceforge.net/projects/pythonpowerelec/?source=navbar
Also, just in case, since some of the blog may be written in a cryptic manner, specific questions can be directed to pythonpowerelectronics@gmail.com
Current Source
This current source turned out to be a little more tricky that I thought because I was looking for an elegant solution, something with cool network tricks or that uses object oriented programming inheritance techniques. Ended up using the easiest way - model the current source as a voltage source in series with a resistance. The end result is a little dirty - calculate one temporary value to update another temporary value. This is evident from the glitches in the first quarter cycle. Will have to test how this works particularly in an inductive-capacitive circuit. So nothing final yet.
Been a while since I released a version, so I am going to release it soon. Also, the next step will be to move on to version 0.2.0 which will look at structural changes to the code that will bring in error messages and directions of usage.
Anyway, here is the code (click on "view raw" below the code box to see it in a new window):
Been a while since I released a version, so I am going to release it soon. Also, the next step will be to move on to version 0.2.0 which will look at structural changes to the code that will bring in error messages and directions of usage.
Anyway, here is the code (click on "view raw" below the code box to see it in a new window):
Wednesday, May 1, 2013
User defined objects - II
Spent a couple of days thinking about ways in which a user can define a "block" that could be connected repeatedly in the circuit. But something similar has made that half-possible already - the "jump" labels.
A crude way of defining blocks would be to simply describe a part of a circuit (for example an RLC circuit or a three-phase inverter) and connect it to the rest of the circuit using jump labels. The reason this would be crude is that the entire sub-circuit would have to be copied that many number of times and for each object, the constituent components would have to be given separate labels.
A much more elegant manner would be to define a single sub-circuit as the base class. The main circuit will then contain references to this class and the connections could be made by jump labels with additional unique identifiers. For example a RL sub-circuit could have a jump1 and jump2 labels as connectors. The main circuit can have jump labels as jump1_RL1 and jump2_RL1 to signify a component RL1. The extention "RL1" will result in labels RL1 automatically created that will be appended to the resistor and inductor within the sub-circuit.
The problem with this method is that in a very large circuit with several sub-components repeated, it may be necessary to change the parameters of some of them to simulate special conditions such as nonideal parameters. So by having a single block, additional changes to the structure won't be possible. So, by copying the sub-circuit again and again, this flexibility is provided. The only drawback is that the user will have to edit all the component labels. But that may not be such a bad thing because the program does the error checking for duplicate labels. So a circuit will not run with multiple labels if the user accidentally forgets to edit some of the labels.
So this option of copying a circuit as many times as you need in the circuit is not such a bad idea because even for the sake of appearance, you can have these blocks anywhere in the spreadhseet, not necesarily bang in the middle of the main circuit.
So, now all I have to do is define a current source and I'll be done with the first set of elements.
A crude way of defining blocks would be to simply describe a part of a circuit (for example an RLC circuit or a three-phase inverter) and connect it to the rest of the circuit using jump labels. The reason this would be crude is that the entire sub-circuit would have to be copied that many number of times and for each object, the constituent components would have to be given separate labels.
A much more elegant manner would be to define a single sub-circuit as the base class. The main circuit will then contain references to this class and the connections could be made by jump labels with additional unique identifiers. For example a RL sub-circuit could have a jump1 and jump2 labels as connectors. The main circuit can have jump labels as jump1_RL1 and jump2_RL1 to signify a component RL1. The extention "RL1" will result in labels RL1 automatically created that will be appended to the resistor and inductor within the sub-circuit.
The problem with this method is that in a very large circuit with several sub-components repeated, it may be necessary to change the parameters of some of them to simulate special conditions such as nonideal parameters. So by having a single block, additional changes to the structure won't be possible. So, by copying the sub-circuit again and again, this flexibility is provided. The only drawback is that the user will have to edit all the component labels. But that may not be such a bad thing because the program does the error checking for duplicate labels. So a circuit will not run with multiple labels if the user accidentally forgets to edit some of the labels.
So this option of copying a circuit as many times as you need in the circuit is not such a bad idea because even for the sake of appearance, you can have these blocks anywhere in the spreadhseet, not necesarily bang in the middle of the main circuit.
So, now all I have to do is define a current source and I'll be done with the first set of elements.
Subscribe to:
Posts (Atom)