[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coupling vs secondary voltage chart

Original poster: Terry Fritz <teslalist@xxxxxxxxxxxxxxxxxxxxxxx>

Hi Antonio,

The problem I ran into was knowing "NewVin" in the case of a primary current controlled DRSSTC. In order to know NewVin, I would have to know NewIprimary ( Xo[4}(t+dt) ) which I will not have until the simulation cycle ends. The NewVin is controlled by the primary current NewIpri. When the cycle starts, I don't know what NewIpri will be.

So I set the NewVin equal to the LastVin. This will cause Vin to actually switch one cycle later. But that really is the case in a real DRSSTC since the electronics take time to switch. In fact, a 100kHz DRSSTC simulation running at 100 steps per cycle will be delayed 1/100000 / 100 = 100nS. That really is sort of near the time delay for the transition in a real DRSSTC. If I artificially rand the delay to say 1uS, you would see the little transition blips caused buy the switching delay. Considering all this, I thought letting NewVin equal LastVin would be fine.

Unlike a sine input case, Vin is always +- the rail voltage or zero. I probably should set Vin = -Vin after the dwell time ends to simulate energy recycling we all seem to use in our DRSSTCs. But that effect on things is tiny too and it make fail the simulation if Ipri ever gets back near zero again. That is a concern if T1_stop gets to be like 250mS to simulate many bursts. That could be programmed out too... From Gerry's discussion, the program will probably have to run much longer simulations over many firing cycles...

It is possible to predict the switch time in the program, and in real coil switching too (Steve Conner's phased locked loop control). But I thought that was getting too detailed and it was best to do it this way.

In the case of the conventional coil, NewVin and LastVin are always zero, so it does not matter.

The code could be optimized more for speed I am sure. Since it was working, I did not want to go messing with it. Also keeping the code as is preserves the theory behind it so it remains easy to see what is going on and make changes if needed.

Cheers,

        Terry


At 07:43 AM 6/18/2005, you wrote:
Tesla list wrote: 
Original poster: Terry Fritz <teslalist@xxxxxxxxxxxxxxxxxxxxxxx>
Hi Steve,
I am using primary feedback.
==========
for (T1 = T1_start; T1 <= T1_stop; T1 = T1 + T1_inc)
  {
  if (X0[4] >= 0) Vin=Vrail; else Vin=-Vrail;   //inputs Vin for DRSSTC case
  if (T1 > DwellTime) Vin = 0.0;
.
.
.
==========


Looking at the code, I see a (small) problem:

/* X1=X0+(dt/2)*[A]*X0+(dt/2)*B*(vin(t0)+vin(t0+dt)) */
      for (j=1; j<6; j++) {
        X1[j]=X0[j];
        for (k=1; k<6; k++) X1[j]+=(T1_inc/2)*(A[j][k]*X0[k]);
        X1[j]+=(T1_inc/2)*B[j]*(Vin+Vin);
      }

The "Vin+Vin" should be something as "LastVin + NewVin".
In this way there is an integration error added at each transition.
A better version could be something as:
LastVin=0;
...
Compute NewVin
In the j loop: ...LastVin+NewVin...
At the end of the time loop:
LastVin=NewVin;

The term T1_inc/2 could be precomputed. But probably code optimization
already does this.

Antonio Carlos M. de Queiroz