Modular Power Conversion System
A modular power conversion system. The modular power conversion system includes at least one first electric resource, a modular power stage, at least one second electric resource, and wherein the modular power stage comprising at last one module including power electronics for converting power between the at least one first electronic resource and the at least one second electric resource.
Latest Deka Products Limited Partnership Patents:
The present application is a Continuation-In-Part of U.S. patent application Ser. No. 13/447,897, filed Apr. 16, 2012 and entitled Modular Power Conversion System (Attorney Docket No. J36), which claims priority to U.S. Provisional Patent Application Ser. No. 61/476,153, filed Apr. 15, 2011 and entitled Modular Power Conversion System, Method and Apparatus (Attorney Docket No. 137), each of which is hereby incorporated herein by reference in its entirety.
TECHNICAL FIELDThe present invention relates to a modular power conversion system for distributed power generation, storage and dispersed loads, and in particular to a modular power conversion system and power electronics which facilitates integration of the distributed power generation, storage and dispersed loads to a flexible smart grid, microgrid or microgrid clusters.
BACKGROUNDThe electrical grid in the United States, or in any developed nation or continent for that matter, is the power industry's electrical network which essentially organizes four critical operations, (1) electricity generation, (2) power transmission, (3) power distribution and (4) electricity control. The “grid” can also refer in certain instances to a regional electrical network or even a local utility's transmission and distribution grid.
Electricity generation is traditionally accomplished by large generating plants such as nuclear reactors, hydro-electric dams, coal and gas fired boilers. The electric power which is generated is stepped up to a higher voltage—at which it connects to the transmission network. The transmission network will move, i.e. “wheel”, the power long distances until it arrives at a local utility distribution network, where at a substation, the power will be stepped down in voltage—from a transmission level voltage to a distribution level voltage. As it exits the substation, it enters the distribution network. Finally, upon arrival at the service location such as a residential home or commercial user, the power is stepped down again from the distribution voltage to the required service voltage(s).
The traditional grid, along with its regional distinctions, are currently subject to the introduction of more efficient and smarter, although often smaller power generation technologies. Regional and local grids are now subject to low level dispersed power generation from regional large and small wind applications, small hydro-electric facilities and even commercial and residential photovoltaic installations for example. As such regional and local power producers come on-line the characteristics of power generation can in some new grids be entirely opposite of those listed above. Generation may occur throughout the grid at low levels in dispersed locations. Such characteristics could be attractive for some locales, and can be implemented in the form of what is termed a “smart grid” using a combination of new design options such as net metering, electric cars as a temporary energy source, and/or distributed generation. The modular power conversion system described below is an example of at least a portion of the developing “smart grid” technology.
SUMMARYIn accordance with one aspect of the present invention, a modular power conversion system is disclosed. The modular power conversion system includes at least one first electric resource, a modular power stage, at least one second electric resource, and wherein the modular power stage comprising at last one module including power electronics for converting power between the at least one first electronic resource and the at least one second electric resource.
Some embodiments of this aspect of the invention may include one or more of the following. Wherein the system further includes a brake module. Wherein the at least one first electric resource includes a wind turbine. Wherein the at least one first electric resource includes a photovoltaic array. Wherein the at least one first electric resource includes a Stirling generator. Wherein the at least one second electric resource includes an end consumer. Wherein the end consumer includes a building. Wherein the at least one second electric resource includes battery energy storage. Wherein the modular power stage facilitates electricity conversion between the at least one first and the at least one second electric resources and allocates the most efficient distribution of electricity based on produce and cost. Where the system further includes a conditioner for conditioning the electricity for power transmission. Wherein the modular power stage is communitively connected to a remote control. Where the system further includes a three phase inverter module to connect a three phase grid. Where the three phase inverter module further includes three half bridges connected to a high and low side of a DC bus. Wherein the system further includes a motor controller for a permanent magnetic synchronous motor which includes an analog/digital converter that converts analog sensor signals from the permanent magnetic synchronous motor to digital signals for use by a digital signal processor including half bridges across a DC bus and an inductor-capacitor-inductor filter that produce three phase AC power at a predetermined voltage and frequency, at least one voltage sensor and at least one current sensor for three-phase demodulation of the three phase signals and converting the three-phase signals to a two-phase orthogonal reference frame, and a position/velocity estimator for receiving speed sensor signals from the motor and compiling a position and velocity estimation of the motor.
In accordance with one aspect of the present invention, a method for controlling a modular power conversion system is disclosed. The method includes drawing power from the least expensive source, as demand increases, drawing power from the second least expensive source, directing power to the highest priority circuits, and if the load of the highest priority circuits is met, then directing power to the second highest priority circuits.
Some embodiments of this aspect of the invention may include one or more of the following. Wherein drawing power from the least expensive source includes drawing power from a photovoltaic array. Wherein directing power to the highest priority circuits includes directing power to a battery.
In accordance with one aspect of the present invention, a motor controller for a permanent magnetic synchronous motor is disclosed. The motor controller includes an analog/digital converter that converts analog sensor signals from the permanent magnetic synchronous motor to digital signals for use by a digital signal processor comprising half bridges across a DC bus and an inductor-capacitor-inductor filter that produce three phase AC power at a predetermined voltage and frequency, at least one voltage sensor and at least one current sensor for three-phase demodulation of the three phase signals and converting the three-phase signals to a two-phase orthogonal reference frame, and a position/velocity estimator for receiving speed sensor signals from the motor and compiling a position and velocity estimation of the motor.
In accordance with one aspect of the present invention, a modular power conversion system is disclosed. The system includes a backplane, a housing and a data connection port and one or more modules that plug into said backplane, wherein the backplane comprises at least one direct current (DC) bus with positive and negative leads, a data connection for each module, connections for electrical power inputs to the module, connections for electrical outputs from the module.
Some embodiments of this aspect of the invention may include one or more of the following. Wherein the modules are comprised of a microprocessor, one or more half-bridge circuits, power conditioning elements such as inductors, capacitors, voltage and current sensors, electrical connections. Wherein the modular power system may connect rotating power generators including but not limited to diesel gensets, Stirling gensets, and wind power, may connect DC power sources including but not limited to solar photovoltaic arrays, fuel cells, may connect to the AC electrical grid with one or more phases, may connect to an AC electrical load with one or more phases, may connect to a rechargeable battery, may connect to an electrical shunt. Wherein one or more of the modules the microprocessors controls the power flow through the module in an attempt to control the DC bus voltage to a given set-point. Wherein voltage set-points of some modules are set to different voltages. Wherein the voltage set-points of different modules are selected so only one module is varying its output at a time in the set of modules in the modular power conversion system. Wherein one or more modules are set to produce power at a range of voltages and the microprocessors do not varying the power flow to control the DC bus voltage. Wherein the voltage set points are selected to prefer renewable energy producers over fossil fuel powered producers.
In accordance with one aspect of the present invention, a method to control the speed during startup and run time of a brushless motor/generator in a Stirling engine where the slow changing sinusoidal speed fluctuations of said motor/generator are filtered out and the underlying speed controlled is disclosed.
In accordance with one aspect of the present invention, a method to start and run a brushless motor/generator in a Stirling engine by scheduling the controller gains based on engine speed thresholds is disclosed.
In accordance with one aspect of the present invention, a method for displaying data values in real time from a microprocessor that broadcasts data to a user interface is disclosed.
In accordance with one aspect of the present invention, A method for annotating software variables in an embedded software system with engineering unit and scaling factors by associating engineering and scaling factors with variable types in a way that may be read from compiled binary file on a user interface to display embedded system variables with engineering units is disclosed.
In accordance with one aspect of the present invention, a method for declaring Boolean status bits in a file at design time where the file read by a 2nd file to generate code in a 3rd file for an embedded system and which can be read by a user interface device to display binary data from an embedded system in meaningful form to indicate value is disclosed.
Some embodiments of this aspect of the invention may include one or more of the following. Wherein the values are displayed on the user interface to show the status bits in one of 3 conditions which include no fault condition, no fault condition now, but a fault has occurred previously and fault condition.
In accordance with one aspect of the present invention, a modular power conversion system and power electronics scheme enabling any power production device or entity to connect to any load or electrical grid is disclosed. This is at a fundamental level power conversion i.e. electricity conversion, between “electric resources” (An electric resource is an electrical entity which can act as a load, generator or storage). At a more involved level as in the embodiments discussed herein, this is more specifically, electricity conversion for example from low level producer(s) such as a diesel or gas generator, Stirling engine, wind turbine or photovoltaic array, to a consumer such as a commercial or residential building, either directly or via the grid. As described below, the goal is more specifically a hardware and software power electronics design and implementation of a modular power stage, i.e. a modular power conversion system which aggregates different power production entities, transmission systems, consumption and loads as well as energy storage.
In accordance with one aspect of the present invention, a modular power conversion system capable of facilitating and synchronizing a variety of power production, transmission, consumption and storage entities for connection with a smart grid electrical distribution network is disclosed.
In accordance with one aspect of the present invention, a power electronic system including power electronics circuits and software for managing the power production entities and the conversion of produced power to a single or multi-phase current for transmission to an electrical grid or load.
In accordance with one aspect of the present invention, each module or “block” of the modular power conversion system is interchangeable in the system to facilitate electricity conversion between electric resources. For example one module or block could convert energy from a desired producer directly to a commercial building power type including but not limited to for example 220 VAC Single Phase, 240/120 VAC Split Phase, 208/120 3-phase, or 380/220 as is prevalent in Europe and China. The module or block is not limited to any specific conversion or operating parameters but is intended to convert produced energy into any world-wide standard.
In accordance with one aspect of the present invention, modules or blocks relating to power transmission of produced electricity to grids, micro grids, smart grids or energy storage entities are disclosed.
The modular power conversion system and power electronics of the present invention may allocate the most efficient production, transmission and distribution of electricity based on available power production entities and cost to lower a consumers cost as well as lower the necessity for over-generation i.e. spinning reserves at a national and regional scale and lessen the potential for under-generation and power failures. The power electronics are the vehicle for communication between the modules which facilitates the plug-in nature of any compatible module into the modular power conversion system.
In accordance with one aspect of the present invention, a modular power conversion system is disclosed. The system includes a first electric resource, a modular power stage, a second electric resource and wherein the modular power stage includes at last one module including power electronics for converting power between the first and second electric resources.
These aspects of the invention are not meant to be exclusive and other features, aspects, and advantages of the present invention will be readily apparent to those of ordinary skill in the art when read in conjunction with the appended claims and accompanying drawings.
These and other features and advantages of the present invention will be better understood by reading the following detailed description, taken together with the drawings wherein:
Like reference symbols in the various drawings indicate like elements.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTSThe electrical grid and its various regional and local distinctions are currently subject to the introduction of more efficient and smarter, although often substantially smaller power generation technologies. Regional and local grids are now subject to low level dispersed power generation from regional large and small wind applications, small hydro-electric facilities and even commercial and residential photovoltaic installations for example. As such regional and local power producers come on-line the characteristics of power generation may in some new grids be entirely opposite of traditional power generation by large mega-watt producing hydro-electric, nuclear and gas-turbine power facilities. Generation may occur throughout the grid at low levels in dispersed locations. Such characteristics could be attractive for some locales, and may be implemented in the form of what is termed a “smart grid” shown in
A highly efficient grid having a field area network 100 would enable the economical and efficient management of all resources on the grid such as large power production from bulk wind 102 or other proprietary power and asset production entities. The field area network 100 would communicate and interact directly with residential and commercial loads and the modular power conversion system described below is an example of at least a portion of the developing “smart grid” technology which would assist in the efficient handling of distributed resources as they are applied to the smart grid.
Turning to
Efficient use of electricity production given the available supply, the average demand and the peak demand, requires dynamic aggregation of electric resources. “Aggregation” is used here to refer to the ability to control electricity flow into and out of different electrical resources. Electricity delivered during peak demand is expensive, costing significantly more than off-peak power. A modular power conversion system 212 which allocates the most efficient distribution of electricity based on production and cost may lower a consumers cost first and foremost and in a broader nature lower the necessity for over-generation i.e. spinning reserves at a national and regional scale and lessen the potential for under-generation and power failures.
As described, the disclosed embodiments relate to a hardware and software design and implementation of a modular power conversion system 212, where each module or “block” is interchangeable in the modular power conversion system to facilitate electricity conversion between electric resources. As described above one module or block could convert energy from a producer 214 directly to a commercial building power type for example 220 VAC Single Phase, 240/120 VAC Split Phase, 208/120 3-phase, or 380/220 as is prevalent in Europe and China. Again, the module or block is not limited to any specific conversion or operating parameters but is intended to convert produced energy into any world-wide standard.
A second block could condition the electricity for power transmission 216 to be added to and distributed by the grid. Additional blocks for other power production 214 such as from photo-voltaic or fuel cells, or for energy storage 218 such as battery energy storage or for power consumption 220 using a power quality inverter and/or telecom system are also contemplated. Grid tie management and management of power distribution in general, for the modular power conversion system 212 is a particularly important aspect whether the grid is a conventional wide area grid network or a smart-grid application. Underlying the hardware of the grid tie system are software applications which scale the power for use.
Some embodiments of the modular power conversion system 212 may be as shown in
An alternative embodiment may place all the computing power in the master controller 252. Thus the operation of each module including the bridge circuits would be fully under the control of one or more DSPs in the master controller 254.
Examples of the hardware topology for the modules in
In some embodiments, the hardware topology module 216 to connect to a 3-phase utility grid and a 3-phase load may be that which is shown in
Alternative topologies/embodiments to connect DC elements to the higher voltage DC bus 250 are presented in
A hardware topology to connect DC bus 250 to an electrically isolated second DC bus 251 is shown in
An embodiment of a three phase inverter module to connect a 3-phase grid is presented in
An embodiment of a three phase inverter module to connect to a 3-phase load is presented in
In some embodiments, a module to connect a single phase generator is presented in
An embodiment of a single phase inverter module to provide AC power to a single phase load is shown in
An embodiment of a single phase inverter module to provide AC power to a single phase grid is shown in
In some embodiments, an inverter module with a grid-tie contactor and a transfer switch, such as the embodiments shown in
In some embodiments, the modular power conversion system 212 may direct the power from a number of sources to one or more loads or sinks of power. The power sources may include, but are not limited to, one or more of the following: internal combustion engine generators, Stirling generator, external combustion engine generators, renewable power generators, battery and the electrical grid. Renewable power generators may include, but are not limited to, one or more of the following: solar photovoltaic, wind turbine generators, hydro power generators, etc. In some embodiments, the sinks or users of power may include the electric grid, in plant AC loads, DC loads, battery charging, brake or shunt. The following describes an embodiment of a modular power conversion system 212 designed such that energy flows as desired. In general, it is desirable to draw power from the least expensive source of power first and as the demand for additional power increases, use the next least expensive power and so on until that last source of power engaged is the most expensive power. Similarly, in some embodiments, the power flows to the highest priority circuits first and when the load of the highest priority circuits is met, power is supplied to secondary and tertiary circuits. By way of example a modular power conversion system connecting a PV circuit, the grid, a local load and a battery may be organized to take power from the PV first, the grid second and the battery last. The same system might charge the battery first and then supply power to the load and grid. Embodiments of circuits to connect these sources and loads are presented in
In some embodiments, prioritization may be achieved by assigning a specific and different operating point to each energy producer or consumer “node”. This operating point is assigned in terms of a voltage regulation point on a common DC bus (i.e. shared by all such nodes). Each node embodies a voltage regulating control which in operation attempts to bring the common DC bus voltage equal to its assigned operating point. In some embodiments, the node does this by either causing current to flow into the common DC bus thereby raising its voltage, or causing current to flow out of the common DC bus thereby lowering its voltage. In some embodiments, each node causes current to flow in a direction that balances the current flow from other nodes such that the desired bus voltage is maintained. In some embodiments, the voltage regulators of each node are setup so that only one node at a time is not in saturation, meaning that all but one node are either fully open or fully closed to power flow and one node is actively varying the power flow to or from the DC bus to control the DC bus voltage. Alternative systems may be setup with nodes that do not attempt to control the DC bus voltage. Examples of such nodes may include a PV array operating with a maximum power point tracking and an engine-driven generator operating at a fixed or system-commanded engine speed. In some embodiments, the operating points of each energy producing or consumer node may be changed any time the system is on including, but not limited to, while the system is running. In some embodiments, the operating points may be changed using a user interface. In some embodiments, an overvoltage level may be set on the DC bus 250 so that if the DC bus voltage reaches a set voltage, the system will shut off. In some embodiments, the overvoltage level of the DC bus 250 may be changed any time the system is on including, but not limited to, while the system is running. In some embodiments, the overvoltage level of the DC bus 250 may be changed using a user interface.
A PV array operating with a maximum power point tracking (MPPT) algorithm. In this case the PV subsystem will attempt to seek out the combination of voltage and current at the PV array that result in the greatest supply of power from the array. Maximum power does not correspond with either maximum voltage or maximum current and therefore it is counterproductive to require the MPPT implementation to operate at a fixed voltage target. Instead the MPPT PV node is allowed to operate over any range of voltage that it can achieve while other consumer nodes continue operate at fixed voltage points and consume the energy that is available from the PV.
An engine-driven generator operating at a fixed or system-commanded engine speed. In this case the generator will deliver whatever net energy remains from the raw energy (fuel) that is supplied to its engine. Like the MPPT example above, other nodes will consume as much of this available energy as they able up to their respective limits.
This type of node, as an energy producer, always supplies all of its capacity to the common bus, even when that capacity exceeds the combined demand of the consumer nodes.
In various embodiments, a given node may be of a type that may provide current flow in either direction, or only in one direction or the other. For example a grid-tied inverter may be designed to permit current flow in either direction; a photovoltaic array can only provide current flow into the common bus. It cannot consume current flowing out of the bus.
In various embodiments, it may be assumed that each node also embodies a current regulating or limiting control. The value assigned to each node's current control is chosen according to the physical limits or needs of that node (or the broader physical constraints of the overall system if they are more restrictive). For example, a battery charger node may be configured with current limits according to the physical requirements of the attached batteries, and possibly further restricted by the current carrying capacity of associated components and wiring that make up the charging system. In some embodiments, the value assigned to each node's current control may be changed any time the system is on including, but not limited to, while the system is running. In some embodiments, each node's current control may be changed using a user interface.
In various embodiments, the current limits of each node, when and if they are reached, will override the node's voltage regulating control and at this point the node will cease its ability to regulate the bus voltage and enter a mode of constant current regulation. Each node will act up to the limits of its ability, expressed in terms of current flow in one direction or the other, to maintain the common DC bus at its assigned voltage level. Once this limit is reached, that node continues to operate at its maximum capacity but inherently yields its control of the bus voltage to other nodes which have greater capacity.
Backup Power SystemReferring now to an embodiments of a power system
The generator module 222 as described above is a power source that converts the polyphase electrical power from the electric generator 222A into DC power on the DC bus 250. The AC Inverter module 220 is a power sink that converts DC bus power to AC power and delivers it to an external load 249. The battery module 218 may be act as either a sink or a source of power to the DC bus 250.
In various embodiments, the Stirling generator may be one of the various embodiments shown and described in U.S. patent application Ser. No. 12/829,320 filed Jul. 1, 2010, now U.S. Publication No. US-2011-0011078-A1 published Jan. 20, 2011 and entitled Stirling Cycle Machine (Attorney Docket No. 178), which is hereby incorporated herein by reference in its entirety.
The prioritization of the nodes or modules may be conceptualized in
An embodiments of a system including a grid-tied inverter and a solar PV array is sketched in
In some embodiments, the elements in
The systems shown in
Observing
Once the wave form is determined in the rotating Udq reference frame, a general feedback loop 305 is provided to a controller 307 where an operator, engineer or computer program may analyze the rotating Udq reference frame and determine and regulate via read/write how much current is desirable to send to the grid for example, or to any other component of the system for that matter. So once this determination is made, for example how much current to return to the utility grid, the Udq rotating frame is converted back to the stationary frame through the inverse Park transform 309 and the quadrature Vxy vector component is transformed via the inverse Clarke transform 311 back into a 3-phase Vabc component and system hardware shown as block 313 takes the 3-phase signal and generates a duty cycle for the PWM 315.
In some embodiments, the computer code transforming the power to facilitate analysis and generation of desired power distribution to the grid or otherwise may be altered for a single phase inverter and a single phase grid. Referring now to
In some embodiments, once the wave form is determined in the rotating Udq reference frame, a general feedback loop 34112 is provided to a controller 34108 where a computer program may analyze the rotating Udq reference frame and determine and regulate how much current is desirable to send to the grid, in some embodiments, or to any other component of the system for that in other embodiments. In some embodiments, once this determination is made, for example, how much current to return to the utility grid (in some embodiments), the Udq rotating frame is converted back to the stationary frame through the inverse Park transform 34106, and the system hardware shown as block 34110 takes the single phase signal and generates a duty cycle for the PWM 34114.
In some embodiments, the analysis obtained from the Park Transformation 303 of the three phase voltage waveform may be used to match the voltage and phase of the inverter to the grid for grid tie. In some embodiments, the inverter's phase locked loop actively adjusts the inverter's Udq reference frame to match the grid's phase and drive the q voltage measurement to zero.
In some embodiments, the analysis obtained from the Park Transformation 34102 of the single phase voltage waveform may be used to match the voltage and phase of the grid. In some embodiments, only the d components of the grid and inverter voltages may be measured as the q components of the grid and inverter voltages are implicitly zero when the phase locked loop is locked. In some embodiments, the q components of the grid and inverter voltages may also be measured. In some embodiments, the analysis obtained from the Park Transformation 34102 of the single phase current waveform may be used to perform current control in both the d and q axes.
Referring now to
Referring now to
In some embodiments, the inverter may have an off grid control circuit 36002 as shown in
In some embodiments, the inverter may have a grid tied control circuit as shown in
Referring now also to
In some embodiments, the difference 37106 may be multiplied by a constant, Ki 37116, in an integrator 37108. In some embodiments, Ki 37116 may be set to a value from 0 to +1 (0≦Ki≦1). In some embodiments, the integrator 37108 may then continuously integrate the result of difference 37106*Ki 37116 to update whether the current level is above or below the nominal current threshold 37114 and to determine the amount by which the current level is above or below the nominal current threshold 37114. In some embodiments, the value of Ki 37116 may be chosen to be in proportion to the periodic computation rate of the system so that the difference 37106 values are integrated in proportion to the actual amount of time that has passed. For example, if the system executes these computations at a rate of 10 kHz, then Ki 37116 may be set to 1/10,000, and a constant value of Id+q 37112=10 would integrate to about 10 amp-seconds after about one second of continuous integration.
In some embodiments, the output of the integrator 37120 may be designed to saturate to zero in the negative direction so that the output of the integrator 37120 may be any real number in the range of 0 to +1. In some embodiments, the range of 0 to +1 may represent a range of 0 to +100% of the full-scale current measurement range of the system and the number of amp-seconds of operation above the nominal level. In some embodiments, the output of the integrator 37120 may be compared 37110 to a fault threshold 37118. In some embodiments, the fault threshold 37118 may be set to a value below the operating limit of the transistors in terms of the transistors' ability to tolerate current above their nominal rating for a certain period of time. In some embodiments, an event where the output of the integrator 37120 is greater than the fault threshold 37118 may indicate that the inverter has operated beyond its nominal rating for a duration of time that may be long enough that it is nearing the safe operating limit of the transistors. In some embodiments, when there is an indication that the inverter has operated beyond its nominal rating for long enough that it is nearing the safe operating limit of the transistors, a fault may be signaled, and the inverter may be shut down to prevent damage to the transistors.
Referring now to
In some embodiments, the inverter may also contain active harmonic current detection and correction circuits for three phase current waveforms. In some embodiments, the active harmonic detection and correction circuits for the three phase current waveforms may be similar to the active harmonic detection and correction circuits 38000 for the single phase waveforms with added Clarke Transforms before the Parks Transforms and inverse Clarke Transforms after the inverse Park Transforms. In some embodiments, the 3rd harmonic may not be corrected in the three phase current waveforms.
A current embodiment of the modular power conversion system is discussed in detail below in relation to a thermal engine, in this case a Stirling engine. In some embodiments, the Stirling engine may be one described in, or one similar to one described in, Appendix A. However, various other Stirling engines may be used. The Stirling engine may be grid-tied or non grid-tied into consumer (load) to supplement/supplant grid distributed electricity. From a system standpoint what is unique about such a modular interchangeable system is initially the packaging of the modular power conversion and the power electronics and software control of a large range of applications (electrical resources) by the individual modules which may be interchanged, replaced and customized in any given package to accommodate many different power production, transmission and load characteristics. The modules themselves may be consolidated in a cabinet and interconnected for example via an isolated CAN 2.0b or other electrical interface(s) which facilitate communication and data processing between controllers and computers. In more complex systems further modules may be added to handle additional electrical resources. The system may include an LCD front display panel having multiple user GUI's for basic system status monitoring and control inputs. Alternatively, a user's PC may be accommodated by USB, Ethernet, internet, wireless or other known communications format, to enable monitoring and control of the modular power conversion system.
The power electronics which control the power conversion from mechanical to a desired form of electrical power from the Stirling engine are critical for efficient and safe electric power generation. In general, the power electronics in any electro-mechanical system facilitate the conversion of raw power input 414 to a desired output power 420 for efficient use by a load 424 as shown in
As shown in
Referring now to
In some embodiments, the power inverter 642 include three (3) half bridges 641 across the DC bus 250 and an LCL filter 643. The half bridges 641 and LCL filter produce three (3) phase AC power at the desired voltage and frequency. The three (3)3 phase AC power is provided to the utility grid 625 and/or load 624 via an contactor 626 and a grid-connect and transfer switch 627.
An embodiment of a control loop 750 structure including the power electronic circuit 722 for a 3-phase PMSM 734 is shown in
The power electronics is generally composed of two main parts, the power electronic circuits 426 and the controller 428, shown at a higher level in
The specific nature of the power electronics in this embodiment is critical because of the nature of a thermal engine, in this case a Stirling engine 530. The Stirling engine does not produce constant output torque, so as it operates, the torque oscillates up and down making motor control a critical issue which must be addressed. It is important in this system to control the motor torque of the PMSM motor/generator 734 and hence the velocity, using the feedback loop to the controller so that the variable torque from the Stirling and the resultant DC power do not detrimentally effect the PMSM motor/generator 734. One way to do this is vector control of the PMSM motor/generator with a velocity control state machine using essentially three different control states: start-up, starting and running states.
A difficulty in controlling the velocity based on input from a Stirling engine is that the Stirling engine torque τst has high spatial harmonics:
τst==τ0+τ1f(θm)
Where τ0 and τ1 are functions of the slowly changing variables of head temperature and pressure, and f(θm) is a periodic function of amplitude, where 1 is a periodic function of angular position with an amplitude 1 and zero mean, e.g. sin θm.
At start-up of a Stirling engine the start-up torque τst is negative and typically varies significantly as the engine turns through a complete revolution. One of the Stirling pistons is compressing gas during part of a revolution leading to more negative torque. In a later part of the revolution, the piston is allowing the gas to expand producing a less negative torque or even a positive torque. This change in torque over small angles i.e. τst≈−k θm. leads to highly variable torque output (
Ideally, the motor controller should counteract or dampen the “springiness” of the engine at low speeds, and not use excess torque in accelerating the engine. The costs of excess torque are excess heating and excess power draw. Also, start-up and starting torque may exceed average running torque by a factor of 2 or 3 in typical engines, so it is start-up and starting torque that dictates the peak power handling capability of the motor controller. A proportional-integral (PI) controller of speed will work in this application, but it is important to determine the integral of start-up and starting torque that works well for the Stirling engine application.
Once the engine is rotating at sufficient speed, motor torque τm needs to be negative to counteract the engine's average torque and maintain roughly constant speed. The motor controller yields generated power from the motor/generator as a side effect of speed control. Once the Stirling is running, the same PI controller gains used for start-up and starting states will not work well for running state. At running speeds, the gains should be low so that the motor speed controller does not fight the oscillating Stirling torque fluctuations. The gains should maintain a slowly changing generating torque to counteract the average torque from the engine, while allowing moderate speed fluctuation.
One solution to the substantial differences between start-up and running torque utilizes a velocity controller state machine with three (3) states as shown in
|ωm|<thresh_lo or |ωm|>thresh_hi where ωm is the measured or estimated motor velocity. A maximum speed command max_cmd parameter limits the input to the PI velocity control loop to be within the range of +/−max_cmd. Kp and Ki are tuned according to the desired behavior of each state. An example of some parameter sets for the start-up, starting and a flow diagram in
Kp, Ki tuned for optimal torque ramp rate
Thresh_lo=0
Thresh_hi=600 rpm
Max_cmd=650 rpm (transition to starting state when speed>600 rpm just slightly greater than the transition threshold.)
Starting:Kp, Ki tuned for fast speed control without overshoot
Thresh_lo=0
Thresh_hi=900 rpm
Max_cmd=950 rpm (transition to starting state when speed>900 rpm just slightly greater than the transition threshold.) Running:
Kp, Ki tuned for low bandwidth speed control;
Thresh_lo=600
Thresh_hi=spd_max (max detectable speed)
Max_cmd=spd_max (no limit)
One alternative to the above parameters is to override motor speed in all states besides the running state, instead of limiting it. Controlling the motor speed with a feedback PI loop on the motor speed depends on a varying instantaneous motor speed over each revolution during starting as the torque varies (
ωm′=ωm−Kc*cos(θm)−Ks*sin(θm)
and control speed based on this estimate of ωm′.
In a further embodiment of motor control architecture a vector control motors which may use variable frequency drives to control the torque, and thus the speed of 3-phase electric motor/generators by controlling the current fed to the machine is used. Different motor types are possible such as induction motors, permanent magnet synchronous motors (PMSM) and synchronous reluctance motors (Synch Rel) for instance with PMSM motors used by way of example for the present embodiment. PMSM motors are relatively simple motors where the permanent magnets on the rotor are pulled in one direction or another by the relative position of the stator and rotor fields. Because the rotor field is fixed in orientation with the rotor, torque production and control requires knowledge of rotor position.
There are a number of ways to write the torque equation for a PMSM motor, for example;
where V is the terminal voltage, I is the motor current, Kc is the back-emf constant, ωm is the mechanical rotational frequency of the rotor, ωe=ωmP/2 is electrical rotational frequency of the rotor, P is the number of poles, and L and R are the inductance and resistance.
The equation is written in the rotor (dq-) reference frame with
with λm=rotor magnet flux, which may then be used to write out the state equation in scalar form as
The cross terms (with we) result from reference frame rotation (similar to Coriolis “force”); in the stator (xy-) reference frame, they are not present but the LdI/dt and Keωm terms are more complicated. The cross terms are a complicating force in control loop design as they couple the two equations at nonzero speed. The torque equation is
which consists of a reluctance torque term due to rotor saliency (Lq≠Ld) and an alignment torque term.
In the present embodiment a PMSM motor with the torque control loop structure could utilize a sine-drive or a six-step drive. The six-step drive is simpler and a good match for digital Hall sensors but the performance risks are substantial where commutation represents an extra disturbance due to the controller switching electrical angle instantaneously, especially at high speeds. Utilizing a sine-drive, the choice of torque loop may be decoupled from the choice of position/speed sensor.
This embodiment contemplates the speed controller as a proportional-integral (PI) controller to monitor and maintain a proportional-integral loop with current error as input, and desired voltage as output. In this way it is possible to limit output to an acceptable range and stop integrating in the direction of continued error when a range limit is reached. Proportional gain gives a more stable controller but not zero steady state error. It is better to control/command torque with PI controllers based on speed error. The Stirling engine does not produce constant torque as discussed above so as it spins the torque oscillates back and forth significantly. This makes for a difficult mechanical load to control, where the Stirling is highly time variant as to its speed-torque. The goal of the power electronics here is to provide a method to most efficiently control the Stirling or any torque producing machine for that matter.
Thus, the nature of the Stirling which acts very different in start-up, as opposed to running state, is that it does not work well with standard PI controllers with high proportional gain. A better method is to use a PI controller with a low proportional gain, so the speed controller does not fight the natural speed fluctuation of the Stirling engine. The PI controller 980 is tuned for at least two or three different states of the motor, start-up 981, starting 985 and running 987 and the different gains depending upon what state the motor is in are used. A simple state machine with the three states, startup, starting and running state with their own proportional integral gain as discussed above is preferable. Speed is measured and compared to a known threshold; if the threshold is crossed the PI controller is transitioned to the next state. There is a maximum speed setting with each state, for example start-up state 881 has a maximum speed of 600 rpm 984. The starting state 985 is a transition state which ensures that a smooth transition takes place between start-up state 981 and running state 987. In any event, for all the states what is very important for the controller 980 is that an accurate value for speed of the motor be determined.
Position/velocity estimation may be accomplished with position sensors, for example a resolver, or three (3) Hall sensors at 60 degrees. Using Hall sensors in their stateless form it is possible to decode the sector from the Hall sensor and compute position increment and unwrap. This provides no speed estimate, just a raw Hall angle. But it gives a good indication of which positional motor segment the rotor is in. In order to obtain the necessary motor speed estimate for the controller, it is now necessary to go from position to speed. A typical solution would be to take the position and differentiate it however this is a relatively noisy solution and may introduce substantial error.
Another solution is to use a feedback loop as shown in
From the Hall sensors one obtains digital signals 10102 for a raw estimate of angle of the rotor 10103 with each 60 degree step of the motor cycle, which are then unwrapped by extending the lowest significant bits of sensor information over time to obtain a bit extended input position 10104. The input position may then be put through a deadband block 10105 which transforms the sawtooth error from the Hall sensor narrowing the input position value that is then compared to the estimate position. The deadband range compensates for the + and −30 degree limit of known natural error of a Hall sensor. The deadband range is 70-80% of this limit of natural error and therefore everything outside the error which exists within the deadband range may be essentially disregarded and/or moved towards a zero value. Error may also be limited by the use of techniques and methods for dynamically setting limits on the commanded current.
Current limits are used in electronic circuitry in order to prevent excessive current that may result in catastrophic failure of electronic components, in this case the motor/generator. In the present embodiment one method is the generation of commands for current which prevent the current from exceeding a dynamically predetermined limit. The limit may be determined for example as a function of power dissipation in a component as estimated from a measured current level and as a function of a measured temperature proximate to the component. Other methods and techniques for limiting current are possible as well. Some of these are described in U.S. Pat. No. 6,992,452 hereby incorporated by reference.
From the standpoint of an output limiter, the input sensor has some inaccuracies, Hall sensor to 30 degrees, a resolver to 5 degrees for instance, so no matter what the estimator does, input sensor overrides if the error between input sensor and estimate is too high. For example, if Hall sensor measurement is 5 degrees different from the raw input estimate, then the estimated value is used. On the other hand if the error is within 70 degrees it is more feasible to clip the difference 10110 between the Hall sensor and the estimate to a desired range, for instance an error_threshold of 35-45 degrees, this limits the error value to a band around the desired angle. Other threshold errors could also be used as well.
Referring now also to
From the resolvers one obtains digital signals 10202 for a position of the rotor 10203. The input position may then be put through a deadband block 10105 which transforms the sawtooth error from the resolver narrowing the input position value that is then compared to the estimate position. The deadband range compensates for the + and −5 degree limit of known natural error of a resolver. The deadband range is 70-80% of this limit of natural error and therefore everything outside the error which exists within the deadband range may be essentially disregarded and/or moved towards a zero value. Error may also be limited by the use of techniques and methods for dynamically setting limits on the commanded current.
In order for the power electronics system 522 discussed above to function properly it must ensure that the subsystems such as the motor controller 536, battery controller 538, brake controller 540 and power quality inverter 542 communicate their messages, demands and conditions effectively to one another so that the most important demands and conditions are acted on first by the system. The communication system described below also operates to control the communication between the power electronics for motor control as well as the actual Stirling engine control 530 of the present embodiment. In the present embodiment a CAN bus is used to connect the various subsystems in the power electronics 522, Stirling controller 532, and various control actuators and/or receive feedback from various sensors and ensure that the appropriate messages are timely delivered to the appropriate subsystem to be evaluated and acted on by the power electronics. In using a CAN bus, each message from an electronic control unit of the power electronics is transmitted serially onto the bus in a time dependent and orderly manner, and where two messages are transmitted to the bus at the same time, standard protocols for priority using a dominant or recessive id of an entire message are known to ensure the most important message is acted upon first.
However, an important feature disclosed is that the message id is split into a priority field and a general identifier field, with the priority field at the most significant bits to ensure that critical system control messages do not get superseded by less important messages. The general identifier field provides specific information and details of the message on system operational status, control commands and system faults. To ensure that such messages are prioritized, any messages for the power electronics system may be set at any priority using the bits of the priority field of the message id, a value which ultimately sets the priority in the bus arbitration, with the lowest numbered id's having the highest priority. This is a particular artifact of this message schema and not part of any available CAN bus specification. Standard priority protocols using a CAN bus always arbitrate bus access using the entire message id and do not interpret the meaning of any user-defined scheme.
Using a 29 bit extended mode message identifier, from 0-28, the message priority is defined by the top 3 bits, 28, 27, 26 with zero being the highest priority. Messages at the same priority will be arbitrated by the remainder of the message ID bits. The priority zero (highest) is used only for the most critical control and alarm functions. The highest bits are used to define priority because similar to standard arbitration protocols if two messages are transmitted at the same time as soon as a recessive (1 value bit) is seen for a lower priority message transmission, the message is stopped and a higher priority message with a dominant (0 value bit) is sent unimpeded to the CAN bus. For example a message with the bits 28, 27 and 26 set to zero is the highest priority message that may be set. On the other hand if these same bits are all set to 1, this is the lowest priority that may be set for a message, but a recessive value at any bit location would stop transmission of the message if another message being transmitted has a dominant bit value at the same location. The impeded message is then transmitted based on its priority after the higher priority message. This provides for a total of eight different priority combinations or definitions where each bit is either 0 or 1 in binary notation, and thus with 3 bits the total number of permutations is 2×2×2=8 combinations or definitions for message priority.
After transmission of the message priority 11120, the remainder of the bits are utilized as the message definitions body themselves and these definitions are divided into a series of groups as shown in
The System Group 11122 is currently allocated 3 bits with only single value 25 assigned to a power electronics system. Other configurations for the power electronics systems may be assigned using other bit value combinations. The Functional Group 11124 is assigned to each of its 4 bits the subgroups of: power production, power transmission, power consumption and energy storage, other subgroups may be defined as well here. The Module Group 11126 relates specifically to the modular power conversion system which permits this power electronics system to work with numerous different power production, transmission and consumption devices and methods, for example engines such as diesel and gas generators, thermal engines such as Stirling engines, wind turbines, photovoltaic systems, fuel cells, power transmission grid tied inverters, static transfer switches, power quality inverters, and for energy storage with battery storage systems and battery charging systems.
So understanding that in the present embodiment there may be over 2000 messages defined in the Message Group 11128, for example for any given message it may apply to a different Module for instance a wind turbine generator or for a Stirling engine, which may then be further defined by the Functional Group 11124 as power production and then assuming only the power electronics system in the System Group 11122 for the moment, given a desired message priority the CAN bus may now evaluate that message and arbitration may occur with the highest priority messages being given the higher priority. One of the important aspects of this scheme is that in the event that it is determined that messages are not being given the appropriate priority during operation of the power electronics and underlying power system, only the priority of any individual message need be changed to raise, or lower the priority of that message.
For example, if a message from the Message Group 11128 indicating motor velocity is too low/high, etc, and that this critical message is being superseded by other less critical messages, the operator need merely set the Message Priority bits 11120 to a value which trumps the priority of other less critical messages, and no other change need be made to the remaining message bits of any of the motor velocity messages. Another example as shown in
It is also important that we not use up all of the values defined by the adjacent possible combinations of bits in each of the Groups. For instance as shown in
An example of certain currently constructed messages for control of the power electronics system and the Stirling controller as well, is shown in
Next, is the Message Group 18128,
This is not the only selection or arrangement of message identifiers which may be determined and other arrangements and definitions of messages are certainly contemplated. What is important from the standpoint of control messaging is that this message format for controlling the power electronics in the present Stirling embodiment, and even in other embodiments as shown in the Module Group 17126, provides a hierarchical system management format which defines unique and specific identifiers for the critical system priorities, system components, functions, modules and every specific message to be communicated across the system power electronics. These specific and unique identifiers not only readily allow orderly communication of messages across the CAN bus, but also tell the controllers what the message is, and may contain associated measured or sensed data which permits the controller to determine appropriate commands for controlling the various modules or system components.
Measured or sensed data and other arbitrary information from the embedded power electronics system 1922 must be collected in real-time to diagnose errors and/or debug issues. A digital signal processor or DSP 19140 as shown in
In implementation of the system, the information available to both the DSP 19140 and PC 19142 ahead of time includes how to communicate via the protocol, as well as how to build metadata including the following data that are generated at the time the DSP program was compiled:
-
- date and time the DSP program was compiled
- a unique 128-bit ID generated per the standard Universally Unique Identifier (UUID) mechanism
- program identifier (a human-readable string to distinguish varying types of DSP programs)
- version number that corresponds to the version of the source code stored in a source control repository such as SurroundSCM, Clearcase, or Subversion
The build metadata 19146 is stored within the executable file 19148 that is generated at compile time. The DSP 19140 is programmed using this executable file 19148. If the PC 19142 has access to this executable file 19148, it then has access to the same build metadata 19146. The executable file 19148 also has the DSP symbol table: given the name of a variable on the DSP 19140 which has a fixed memory location, this allows the PC 19142 to determine what type of variable it is (e.g. 16-bit unsigned integer, 32-bit pointer, structure, union, etc.), and where it is located in the DSP's memory.
In implementation the system may use a 2.34375 Mbaud serial port with the standard UART configuration of one start bit, 8 data bits, and one stop bit per byte, or 234375 bytes per second maximum throughput in each direction. A diagnostic kernel routine on the DSP executes at a 10 kHz rate meaning that the diagnostic kernel may send and receive at most 23.4 bytes on average; data that exceeds that length is enqueued or dequeued in a buffer.
Each packet 19150 consists of;
-
- a header 19152
- a message digest 19154
- data (varies depending on the type of packet) 19156
- a delimiting mechanism 19158
The delimiting mechanism 19158 provides a determination of when one packet ends and the next packet begins. Consistent Overhead Byte Stuffing or COBS, as described in the 1997 paper of the same name by Stuart Cheshire and Mary Baker of Stanford University is used providing a fixed overhead of 2 bytes for packets of less than 255 data bytes (one extra byte per packet for encoding, and one extra byte for delimiting), thereby efficiently encoding and decoding each packet.
A message digest 19154 provides a means for detecting transmission errors by adding extra bytes at the end of the packet 19150 which are a function of the previous bytes in the packet, so that a receiver of the packet may compute the same message digest 19154, and if it matches the one transmitted, there is high probability that the packet 19150 has arrived without errors. A 16-bit CRC is used in the present embodiment as a message digest, adding 2 bytes overhead.
Before transmission, the packet 19150 is first formed as a raw data packet, which then gets the 2 byte CRC appended to it, and is then encoded with COBS. The header consists of at least one byte at the beginning of the raw data packet that determines which type of packet it is. Each header 19152 starts with a tag that is a prefix code, i.e. within the set of possible header tags, no tag is the prefix of any other tag (e.g. the header tags 0xff, 0xfe00, and 0xfe01 are a valid set, but the header tags 0xff, 0xff00 are an invalid set because 0xff is a prefix of 0xff00). Using this method 256 valid one byte header tags may be developed and more if more than one byte for some of the header tags is used. As a result, the overhead for packet encoding is at least 1 byte for the header tag, 2 bytes for the CRC, and 2 bytes for COBS, or 5 bytes per packet.
There are a number of different packet types that have been developed and may be used for communication protocols. Some that are commonly used are provided as an example;
Ping packet—sent from DSP 19140 to PC 19142 on a periodic basis, or in response to a ping request packet. It contains a counter incremented each time a ping packet is sent (this allows the PC to detect missing packets), a 16-bit timestamp, and critical message counters (described later).
Ping request packet—sent from PC 19142 to DSP 19140 on an arbitrary basis. For “keepalive” purposes, a predetermined timeout of approx 100 msec is used both for ping packets and ping request packets: namely, that both PC 19142 and DSP 19140 will transmit the corresponding packet during each timeout interval, and if a timeout interval elapses without receiving the corresponding packet, then something is wrong and the communications connection may be considered to be interrupted.
Memory read request—sent from PC 19142 to DSP 19140 on an arbitrary basis. Contains an 8-bit read request ID, 8 bits of flags, an 8-bit byte count, and a 32-bit starting address. The flags include 1 bit determining whether the address points to absolute memory or “virtual memory” (described later). Upon receiving this, the DSP 19140 will read the requested memory and respond with a memory read response.
Memory read response—sent from DSP 19140 to PC 19142 in response to a memory read request. Contains the 8-bit read request ID, and data corresponding to the memory read request. The request ID is so that the PC 19142 may request several different pieces of data and may match up the responses with its requests, since there may be some delay before receiving those responses. If a read response is not received, the PC 19142 may re-issue the read request.
Memory write request—sent from PC 19142 to DSP 19140 on an arbitrary basis. Contains an 8-bit critical message count, 8 bits of flags, a 32-bit starting address, and data. The flags include 1 bit determining whether the address points to absolute memory or “virtual memory” (described later). Upon receiving this, the DSP 19140 will write the requested memory. The DSP's critical message count is maintained by the DSP 19140 and reported in its ping packet. For packet types which are considered critical messages (including memory write requests), the DSP 19140 will ignore any message where the received critical message count does not match its internal counter. If the critical message counts match, the DSP 19140 acts increments its critical message count and acts upon the received message. This allows the DSP 19140 and the PC 19140 to stay in sync with respect to critical messages: if messages are improperly received, they will be ignored, and the PC 19142 may detect this and decide to re-send messages. If the same message is received twice, it will be acted upon at most once.
Broadcast packet—sent from DSP 19140 to PC 19142. This consists of a packet ID header tag, an 8-bit counter field, and data. The 128 header tags 0x00-0x7f for broadcast packets are reserved, leaving tags 0x80-0xff for the packet types described above as well as application-specific packets not discussed in this document. A broadcast packet is sent once each time the DSP's diagnostic kernel executes and the DSP 19140 has detected valid communications from the PC 19142 (e.g. it has received a ping request packet within its timeout). The packet ID header tag allows 28 different sets of data to be sent.
Each data set may have arbitrary data, to the extent that it may fit within the available bandwidth. In practical terms 23 bytes are available with 4 bytes overhead for COBS and the CRC, −1 byte for the packet header tag and 1 byte for the counter field, leaving 17 bytes left for data. In practice normally 14 bytes (7 16-bit words) are used at most.
The 8 bit counter field consists of a 3-bit change counter and a 5-bit tick count. The change counter is incremented once each time the DSP 19140 executes a memory write request that could affect the contents of the broadcast packet, so that, for example, if the PC 19142 sends a request to write memory that would change the contents of the DSP's broadcast packet, the PC 19142 may determine exactly when the DSP is sending new data.
The 5-bit tick count provides a fine-grained timestamp 20160 for the data that was sent. This allows for up to 31 broadcast packets to be lost while still maintaining a valid timestamp 20161. The ping packet 20162 contains the same timestamp but uses a full 16 bits. The combination of these two timestamps allows the PC to track timestamps even in the presence of missing packets (t4, t5, t6) and extrapolate received data for example from measured or sensed voltage data as shown in
The PC includes a copy of the DSP's executable file containing the symbol file, providing the PC with access to the DSP's memory. There are, however, certain items of data which, in order to access reliably, cannot be accessed by absolute DSP memory address, because this address may vary as the DSP program changes. Therefore a limited area of “virtual memory” 21164 where the DSP must translate well-known fixed virtual addresses as shown in
This includes the following items:
-
- Build metadata (discussed earlier)—this lets the PC determine that a given executable file is appropriate to use on the DSP. If the build metadata in its executable file does not match the build metadata received from the DSP, then it cannot reliably read or write data using the absolute addresses found in the symbol table of the executable file.
- Session ID—this is an arbitrary number created by the PC each time it first contacts a DSP. As shown in
FIG. 21 , the DSP scrambles 21176 its session ID 21166 every time it resets 21172. This allows the PC to determine what happens when it experiences a communications interruption (via ping packet timeouts). It may read the session ID 21166 from the DSP, and if the session ID 21166 changes, then either the DSP has been reset, or the PC has been connected to a different PC. If the session ID 21166 is the same, it may assume that it was merely a temporary communications interruption and the DSP is the same one. - Metadata for broadcast packets: see below.
- CPU metadata, including flags that determine
- whether the CPU uses 8-bit or 16-bit memory words
- whether the CPU uses 16-bit or 32-bit pointers for memory addressing
- whether multiple-word quantities are most-significant-word first or least-significant-word first
- whether memory address alignment is 1-byte-aligned, 2-byte-aligned, 4-byte-aligned, or 8-byte-aligned
The DSP uses a particular block of virtual addresses to determine which data it sends over broadcast packets, including the schedule table, the data palette, (both described below) and a few counters. As implemented in a first embodiment and as shown in
For example, if schedule table row 0 contains A index 1, A count 3, B index 80, B count 2, then the DSP broadcast packet id 0 will send the contents of data palette addresses #1, #2, #3, #80, and #81. If schedule table row 1 contains A index 30, A count 5, B index 45, B count 1, then the DSP broadcast packet id 1 will send the contents of data palette addresses #30, #31, #32, #33, #34, and #45. Typically the A data series is for several words of data that are broadcast at every 10 kHz cycle, or every other 10 kHz cycle, whereas the B data series is for 1 or 2 words of data that cycles through a long list of data, thereby creating a “fast” set of a few data words, and a “slow” set of many data words, making for a flexible system for data transfer.
If the PC sets the contents of the data palette 22186 and the schedule table 22184, then it may unambiguously interpret the contents of each broadcast packet and associate it with the appropriate DSP memory locations that it selects. In the present embodiment, the DSP cycles through schedule table rows 0 to SCHEDPERIOD-1, where SCHEDPERIOD is a counter located in the virtual address space and may be set by the PC. It is possible, however, for the DSP to use any arbitrary ordering of schedule table rows (e.g. 0,1,0,2,0,3,0,4,0,1,0,2,0,3,0,4, etc). Since the schedule table row # is transmitted as the packet ID of broadcast data packets, the PC does not need to know about this ordering to be able to interpret it correctly, but a mechanism is provided that sets up the desired ordering.
Another aspect disclosed herein relates to a debugging/diagnostic system and user interface (DiagUI) for indicating and relaying engine operational data from the Stirling engine to technicians, operators and engineers. Operational data for the engine itself may be collected from a plurality of engine sensors and from the DSP and engine controller system hardware and software. The operational data may be optionally stored in a memory storage device, or relayed directly through the DiagUI to the operator. The diagnostic system and DiagUI is essentially a computer program which enables an operator to easily read and write data to the DSP of the Stirling engine, as well as monitor the engine and DSP and attend to data logging of predetermined operational data to evaluate and analyze operational conditions of the Stirling engine. The diagnostic system may accomplish these tasks in a number of ways, for instance in real time using for example a high bandwidth data communication channel, or the system may buffer data within a given time frame, or take a snapshot of desired sensor data at some point in time of the operating data from the Stirling engine and present the data in a coherent form for analysis.
There are several critical tasks to accomplish for a robust debugging/diagnostics system for the Stirling engine. The first is the necessity to read/write data to and from desired variables of the Stirling controller. The read/write function is essentially an on-demand task for the diagnostic system and is essentially a one-time task, meaning although repetitive from the operator's perspective; the read/write function to any particular variable is begun and completed in a short one-time task. Another important task is monitoring of the proceeding engine operations which means that the DiagUI displays desired variable values on the screen, i.e. through the DiagUI for immediate evaluation of engine operation, and data logging i.e. the recording of desired data in a time frame for specific analysis by the operator or engineer.
Reading and writing of variables for example includes determining and selecting a desired variable to write to, for example a control parameter for the engine which the operator desires to modify such as a voltage gain threshold limit which the engineer or operator desires to change to improve engine operations. Monitoring of a desired variable includes for instance displaying a real time motor current in a table of the DiagUI and then logging that value to a data file for subsequent analysis. In various embodiments, the desired variables may be any variable from the executable file. The system only need know how to translate a variable name to an address and the system accomplishes this by reading the executable file.
Each of these tasks are facilitated through the DiagUI 23200 shown in
At the top of the window there is a series of vertically adjacent icons, with each icon containing a specific symbol, this is referred to as a Build ID indicator 23218. The issue addressed by the Build ID indicator 23218 component of the diagnostic screen is to provide an easily identifiable symbol to the operator which indicates that the version of the diagnostic program executable file matches the version of the DSP executable file. At start up a communication link between the DiagUI and the DSP is initiated and a version indicator for the DSP 23220 and for the DiagUI 23222 is displayed as a hexadecimal number below the Build ID indicator icons 23218. The version indicator 23220, 23222 is a hex translation of the date, time and version of each of the executable files. However, the version displayed in hexadecimal form is not as straightforward to read and compare and an operator may make a visual error in comparing the two numbers. The use of simple symbols provides an easily read indication of differences in software versions and therefore the hex number of each version is translated into the Build ID indicator 23218 with a first set 23224 of the symbolic icons displayed for the software version of the DSP and a second set 23226 of symbolic icons displayed for the DiagUI. If the symbols of the first 23224 and second 23226 sets match the version of software of the DSP and DiagUI are the same. If one or more symbols between the two sets do not match the DiagUI and DSP do not have the same version of software. It is important to quickly identify a difference in software versions where the disparity may result in calls to variables at incorrect address locations and writing and language errors in resolving or transmitting data between the DiagUI and the DSP.
An indication of a mismatch in software versions on initiation of the communications link between the DiagUI and DSP provides for an operator to quickly scan the date 23230, time 23232 and build version 23228 of the source code displayed next to the Build ID indicator 23218 and determine if a new version of software must be installed for either the DiagUI or DSP. This initial data exchange and version indication reduces transmission errors and saves time as errors attributable to the incompatibility of software versions are removed.
Also provided in the diagnostic window is a counter 23234 to account for issues in the communications packet stream. The DSP may send, as an example 10,000 communications packets per second, and a counter which identifies bad, i.e. unreadable or corrupted packets, is important to the operator to ensure that the communications packets are being properly received. The counter may also be reset if necessary.
The diagnostic window 24214 as shown in
The symbolic access display 24238 has two sections, the watch item table window 24252 and as previously mentioned the data log palette 24246. The watch item table 24252 provides access to any variable using a scroll bar 24254 to move up and down through a list of variables. The address 24260, raw value 24262 and the engineering value 24264 of a watch item 24266 is displayed and one or more parameters may be read and adjusted to desired values in the engine controller by utilizing the “read selected item” 24256 and “write selected item” 24258 buttons to the right of the watch item table 24252. Alternatively, the operator who generally has knowledge of the variables in the program may select the variable in the data log palette 24246 to have the value displayed in the watch item table 24252. The watch item variable 24266 symbol information may be shown in binary, decimal or hex notation by selecting the symbol information button 24268 and selecting the appropriate radio button 24270 to format the variable symbol information.
Below the watch item table 25252, as shown in
By way of further explanation the DSP program contains the variables which represent quantities that have associated physical units, e.g. battery temperature, motor current, bus voltage. The program is provided with a conversion ratio between integer counts in a program variable and an engineering value, for example:
-
- 100 counts=1° C.
- 215=32768 counts=732 V
- 215=32768 counts=256 A
A variable is associated with a unit definition by encoding for example a voltage unit as 732.0Q15V wherein 732.0 is the unit conversion factor and the Q value 15 is an arbitrarily chosen modifier to adequately represent an engineering value with integer mathematics. The rest of the definition is merely the unit name, i.e. descriptive nomenclature such as V for volts, A for amps, or any other descriptive markers the programmer believes are necessary. For example an engineering value of 366 volts maybe converted to a raw value of counts by dividing the engineering value by the conversion factor and multiplying 2 to the Q modifier power as shown below.
(366.0 volts/732.0 volts)×215=16384 counts
To associate specific unit definitions with DSP program variables it may be helpful to use typedef declarations to identify a variable by the unit of measure that it represents. From a programming standpoint each DSP variable is associated with a variable type, e.g. uint32_t, an unsigned 32 bit, int16_t, signed 16 bit, and uint8_t, unsigned 8 bit. The typedef declaration is an understandable synonym used in place of a data type to more easily associate that variable with specific data, such as a voltage, current, temperature, etc.
Typedef int int16_t; creates the type “int16_t” as an equivalent to type “int” As shown below diagrammatically using typedef declarations a string of variables equivalent to the following is shown:
This assignment is show schematically in
In this example foo is a synonym for data type int 16_t which is a synonym for data type int meaning foo is of data type int. In this way a synonym of an easily understandable term may be used to name a variable. The use of typedef declarations provides clarity to programmers and users and provides a methodology to automatically associate a DSP variable with a unit definition as described herein. Any variable or set of variables may be defined; for example a set of current and voltage readings may be defined as current1_S16, voltage1_S16, temp1_S16, current2_U32, voltage2_U32, etc. with each of these unit types resolved to a C/C++ native data type. Variable names may be created with specific metadata such as an identifier, in this example a suffix that includes the unit type. The identifiers may be grouped as members into a data structure providing for the group of identifiers to be called under one name, the name being a new valid type name the same as the fundamental types such as int or long. The structure name may then be used in a particular namespace context allowing for variables having the special group identifier to be recognized be selected from other variables.
For example a typedef declaration is made for each identifier and these identifiers are grouped under a data structure with a special pre-arranged name such as _Unit_Base_Marker_as shown below. A typedef declaration is also made for each variable to point to each of the appropriate identifiers. In this way each variable string contains the unit base marker suffix and may be recognized from other similarly named variables that are not within the same context as those variables of the _Unit_Base_Marker type.
This assignment is show schematically in
This provides for a variable string having raw value data to be automatically associated with a unit definition and thereby convert the raw data value to an engineering value using the conversion factor as described above. In operation, the DiagUI executable program provides a set of global variables that each include a unit name, a static address and unit type. Using the specific address information, the DiagUI extracts data from the DSP and associates this reading or measurement with the specific global variable having that address information and creates a variable string that includes the unit name, identifier unit type, and the DSP data. As an example for a variable string;
-
- Voltage1_S16 Vbat;
Using typedef and the stored metadata defining the string the diagnostic tool enables DSP data to be associated with unit definitions in the following manner:
(1) The DSP output data file with symbol string information may be read to detect a program variable's type.
(2) The typedef chain is compared to the data structure type for the special _Unit_Base_Marker_and if the typedef chain is defined within the context of that data structure type, a unit definition may be associated with the variable.
(3) If the variable type is descended from one of a unit base type, the name is analyzed to determine if the name ends in one of the members of the data structure, in this example one of the suffixes _S16, _U16, _S32, _U32.
(4) If the variable name contains one of the suffixes, the variable data is resolved to remove of the identifying suffix from the unit name to determine the global variable, here for example the variable “Voltage1_S16 Vbat” has an inferred unit name “Voltage1”.
(5) The unit name is searched for in the encoded unit definition string, here “732.0Q15V”
(6) The unit definition is interpreted as 215 counts=732.0V and this data is associated with the program variable, Vbat thereby converting the raw value DSP data to an engineering value.
In some embodiments, the unit definition for any variable in the system may be changed using the DiagUI any time the DiagUI is turned on including, but not limited to, while the system is running. In some embodiments, the DiagUI may only update the unit definitions for variables when it is turned on or when it is reinitialized. In some embodiments, the DiagUI may be programmed to update the unit definitions for variables at any time including, but not limited to, when a user requests the DiagUI to update the unit definitions for variables, at specific time intervals, and whenever a unit definition for a variable has been updated using the DiagUI. In some embodiments, when a unit definition of a variable has been changed using the DiagUI, the DSP will update the unit definition of that variable and any unit definitions of variables dependent on the unit definition of that variable. For example, the unit definition of power may depend on the unit definitions of voltage and current; therefore if the unit definition of voltage and/or current are changed, the DSP will not only update the unit definitions of voltage and/or current, but also the unit definition of power.
The scripting display window 26298 accessed by selecting the scripting tab 26216 is another important aspect of the DiagUI. As is well known in the art a scripting program is essentially a series of instructions interpreted at one time by a software application in a given system. The script is not usually part of the source code of the software application and may be a different language from the source code as well. Scripts are generally stored in a location from which an operator may retrieve and run the script to accomplish the specific and often dedicated commands in the script.
As seen in
A variable may be given a verbose name by a programmer therefore the scripting program allows the use of an alias for a variable. The alias may be used in the script to perform an action on, evaluate or change a value of a variable. An address defines the location of the variable in the DSP. Statistical analysis of the variable may also be provided within a time window, for example a mean value over 5 seconds, best fit value, max and min as well as std. deviation may be helpful. The data unit for example Amps may be used in a script.
A first embodiment of an errorlog 27308 is shown in
In some embodiments, the DiagUI may display a large number of state bits in the symbolic access display 24238. In some embodiments, these state bits may be Boolean and indicate a variety of conditions including but not limited to one or more of the following: batteryUnderVoltageSoftware, transistorOvertempD, inverterOvertemp, GridPllLocked, bridgeDisableABCD. In some embodiments, some of these state bits may be latched values meaning that if the value of the bit changes from its initial value, then it remains at the 2nd value until the values are reset. By way of an example, in some embodiments, if the motorspeed bit momentarily displays a fault state and then returns to the run state, the latched motorspeed bit remains in the fault state until reset. In some embodiments, the state bits may be displayed to allow easy assessment of the condition: bits in the no fault state show an empty box, bits that show a past fault, but not currently in the fault state (latched fault) show as a grey box with an X on it and bits that show an active fault show a box with a red X on it.
The state bits used in the DSP and displayed in the DiagUI may be changed, in some embodiments, and may, in some embodiments, be pre-determined/preprogrammed. The state bits may be changed by modifying the C++ code for the DSP and the Java code for the DiagUI. However, those changes may be complex and, in some embodiments, are coordinated between the C++ and Java code. In some embodiments, the method described below may be used. Therefore, in some embodiments, the system may include a method to auto-generate C++ code that is compiled with the rest of the code that in part controls the DSP and can be read by the DiagUI.
In some embodiments, the process to implement changes to the displayed state bits is presented schematically in
The auto-generated source code files cmdstatus.cpp and cmdstatus.h 33010 may be compiled with the rest of the C++ files required to program the DSP 754 and then may be linked with at least the object file cmdstatus-events.sml.obj 33022 to produce the execute able file dpe-modpwr.out 33042. The DiagUI, which, in some embodiments, runs on a separate computer that is linked to the DSP 754 via a communication cable, accesses the executable file dpe-modpwr.out 33042. The DiagUI reads the executable file dpe-modpwr.out 33042 to extract cmdstatus-events.xml and decode the events sent from the DSP into meaningful displayed values. As noted previously, the DiagUI displays the version of the executable used by the DSP and DiagUI to confirm that they match.
In some embodiments, the structure of the software to start the AC inverter is presented in
The inverter system is not in an error and in a runnable condition if the following conditions are true:
a) the inverter is enabled
b) no system faults comprising:
-
- i. DC bus overvoltage
- ii. Inverter drive bridge overcurrent (measured per phase, for hardware protection)
- iii. Inverter output overcurrent (measured as the sum of the phases, for general operating limits)
- iv. Inverter drive bridge gate fault
- v. Inverter drive bridge disabled (i.e. some other part of the system has commanded the bridge circuitry to be disabled independently of the inverter)
- vi. Invalid system configuration data (this is a specific check made on the configuration data stored in non-volatile memory)
- vii. Faults-measurement DAC (digital to analog converter) not programmed (i.e. certain fault conditions cannot be reliably detected because part of the measurement system is non-operational)
c) the inverter output circuit breaker is closed.
In some embodiments, in the Determine state 2920 the software determines if the utility grid is 625 is present by measuring the voltage on the lines connected to the grid. If no voltage is detected on the lines connected to the grid, the inverter state machine proceeds to Configure for Standalone state 2930, where the inverter frequency and output voltage are set to fixed values and the drive circuits that control the IGBTs 658 are enabled. The software in Configure for Standalone state 2930 closes the external contactor 626 then the state machine transitions to Run Standalone state 2940. In some embodiments, the output contactor 627 transfers the load to the inverter output when the grid is not present. In some embodiments, the inverter runs in standalone mode in state 2940 until commanded off or an error conditions occurs.
In some embodiments, every state will transition to the OFF state in the case of an error condition. If the error condition is removed then the inverter will again move through the various states toward either the Run Standalone state 2940 or Grid-Tied state 2980.
The state machine transitions form the Determine state 2920 to the Pre-Grid Tie state 2950 if the correct voltage is detected on the grid power lines and the external contactor is not closed. In some embodiments, in the Pre-Grid Tie state 2950, the drive circuits are enabled and controller monitors the grid voltage for amplitude, frequency and phase. The Pre-Grid Tie state 2950 adjusts the output of the bridges 659 to produce AC voltage at the output contactor 626 that matches the grid voltage and is phase-locked with the grid. In some embodiments, the state machine transitions from the Pre-Grid Tie state 2950 to the Close Output Contactor state 2960 when the inverter output is stabilized, matches the grid voltage and has established phase lock with the grid. In the Close Output Contactor state 2960, the output contactor 626 is closed. The state machine transitions to the Wait for External Contactor state 2960, where the software waits until the external contactor 627 has closed before transitioning to the Grid-Tied state 2980. In the Grid-Tied state 2980, the inverter controller adjusts the power flow through the bridges 659 to regulate the voltage of the DC bus 250.
In some embodiments, the state machine remains in the Grid-Tied state 2980 until the inverter output goes out of tolerance or either of the two contactors 626, 627 are opened. The state machine will transition to the Lost Grid-Tie state 2990 if either the voltage or the phase lock between the inverter output and the grid goes out of their respective tolerance range. The state machine will also transition to the Lost Grid-Tie state 2990 if the output contactor 627 or external contactor 626 are opened.
In some embodiments, the state machine transitions from the Determine state 2920 to the Hot Grid Tie state 2955 if the correct voltage is detected on the grid power lines and the external contactor is closed. In some embodiments, in the Hot Grid Tie state 2955, the drive circuits controlling the bridges 659 are enabled and output contactor 627 remains open while the controller matches the voltage and phase of the inverter output to the measured values for the Grid 625. In some embodiments, the state machine transitions from the Hot Grid Tie state 2955 to the Locked state 2965 which runs a timer. If phase lock or voltage match is lost while the timer runs, the state machine transitions back to the Hot Grid Tie state 2955. Otherwise the state machine transitions to the Close Output Contactor state 2975 when the timer expires. In the Close Output Contactor state 2975 the software commands the output contactor 627 closed and waits until the contactor has closed before transitioning to the Grid-Tied state 2980.
In some embodiments, the structure of the software to operate the AC inverter is presented in
As stated above, in some embodiments, the inverter may be in the Close Output Contactor state 2960 or Close Output Contactor state 2975 and may proceed to an OFF state 2910 if an error is detected. In some embodiments, one possible error is that a timer may start running when the inverter enters either state, and the timer may send the inverter an error if the timer reaches a preset amount of time and the inverter has not proceeded to a new state.
Referring now also to
In some embodiments, the output relay control and contactor 40400 may be programmed to connect the local load 40200 to the grid 40300 as the local load's 40200 normal power supply. In some embodiments, the output relay control and contactor 40400 may be programmed to switch the connection to the modular power conversion system 40100 under various circumstances. For example, in some embodiments, the output relay control and contactor 40400 may switch the connection to the modular power conversion system 40100 if the grid 40300 is lost and the modular power conversion system 40100 is supplying enough power to support the local load 40200.
In some embodiments, the modular power conversion system 40100 may connect to the grid 40300 via an external relay control and contactor 40500 under various circumstances. For example, in some embodiments, the external relay control and contactor 40500 may be programmed to connect the modular power conversion system 40100 and the grid 40300 if the modular power conversion system 40100 is producing voltage that matches the grid's 40300 and has established phase lock with the grid 40300 and the output relay control and contactor 40400 is connecting the local load 40200 to the modular power conversion system 40100.
In some embodiments, various temperatures in the system may be measured including, but not limited to, battery temperature, motor temperature, ambient air temperature in the cabinet, and the heat sink temperature. In some embodiments, the battery temperature may alter the behavior of the battery charging algorithm (for example, in some embodiments, based on the battery manufacturer's specification). In some embodiments, the motor and/or heat sink temperature measurements may be used to measure how much power is flowing in the system. In some embodiments, the motor and/or heat sink and/or cabinet ambient air temperature measurements may be used as a basis for throttling down the engine or lowering the current limits in the system to reduce heat to safe levels. In some embodiments, the motor and/or heat sink and/or cabinet ambient air temperature measurements may be used as a basis for running the system at less than the optimal power point to allow the system to cool. In some embodiments, the motor and/or heat sink and/or cabinet ambient air temperature measurements may be used to measure the efficiency of the cooling system.
While the principles of the invention have been described herein, it is to be understood by those skilled in the art that this description is made only by way of example and not as a limitation as to the scope of the invention. Other embodiments are contemplated within the scope of the present invention in addition to the exemplary embodiments shown and described herein. Modifications and substitutions by one of ordinary skill in the art are considered to be within the scope of the present invention.
Claims
1. A modular power conversion system comprising:
- at least one first electric resource;
- a modular power stage;
- at least one second electric resource; and
- wherein the modular power stage comprising at last one module including power electronics for converting power between the at least one first electronic resource and the at least one second electric resource.
2. The system of claim 1 further comprising a brake module.
3. The system of claim 1 wherein the at least one first electric resource comprising a wind turbine.
4. The system of claim 1 wherein the at least one first electric resource comprising a photovoltaic array.
5. The system of claim 1 wherein the at least one first electric resource comprising a Stirling generator.
6. The system of claim 1 wherein the at least one second electric resource comprising an end consumer.
7. The system of claim 7 wherein the end consumer comprising a building.
8. The system of claim 1 wherein the at least one second electric resource comprising battery energy storage
9. The system of claim 1 wherein the modular power stage facilitates electricity conversion between the at least one first and the at least one second electric resources and allocates the most efficient distribution of electricity based on produce and cost.
10. The system of claim 1 further comprising a conditioner for conditioning the electricity for power transmission.
11. The system of claim 1 wherein the modular power stage is communitively connected to a remote control.
12. The system of claim 1, further comprising a three phase inverter module to connect a three phase grid.
13. The system of claim 12, the three phase inverter module further comprising three half bridges connected to a high and low side of a DC bus.
14. The system of claim 1 further comprising a motor controller for a permanent magnetic synchronous motor comprising:
- an analog/digital converter that converts analog sensor signals from the permanent magnetic synchronous motor to digital signals for use by a digital signal processor comprising half bridges across a DC bus and an inductor-capacitor-inductor filter that produce three phase AC power at a predetermined voltage and frequency;
- at least one voltage sensor and at least one current sensor for three-phase demodulation of the three phase signals and converting the three-phase signals to a two-phase orthogonal reference frame; and
- a position/velocity estimator for receiving speed sensor signals from the motor and compiling a position and velocity estimation of the motor.
15. A method for controlling a modular power conversion system comprising:
- drawing power from the least expensive source;
- as demand increases, drawing power from the second least expensive source;
- directing power to the highest priority circuits; and
- if the load of the highest priority circuits is met, then directing power to the second highest priority circuits.
16. The method of claim 15 wherein drawing power from the least expensive source comprising drawing power from a photovoltaic array.
17. The method of claim 15 wherein directing power to the highest priority circuits comprising directing power to a battery.
18. A motor controller for a permanent magnetic synchronous motor comprising:
- an analog/digital converter that converts analog sensor signals from the permanent magnetic synchronous motor to digital signals for use by a digital signal processor comprising half bridges across a DC bus and an inductor-capacitor-inductor filter that produce three phase AC power at a predetermined voltage and frequency;
- at least one voltage sensor and at least one current sensor for three-phase demodulation of the three phase signals and converting the three-phase signals to a two-phase orthogonal reference frame; and
- a position/velocity estimator for receiving speed sensor signals from the motor and compiling a position and velocity estimation of the motor.
Type: Application
Filed: Mar 14, 2013
Publication Date: Apr 3, 2014
Applicant: Deka Products Limited Partnership (Manchester, NH)
Inventors: Donald J. Lucas (Windham, NH), Jason M. Sachs (Chandler, AZ)
Application Number: 13/827,140
International Classification: H02J 3/46 (20060101); H02P 25/02 (20060101);
