Re: Lahman, how ya doing?

Responding to Hansen...

Is there any software at all involved in producing the delta V? If not, then this doesn't seem interesting to the simulation because it will all be replaced by your heat flow calculation that produces the delta V. (I had that heat flow calculation living in Target and responding to the E1 event.)


No software at all in producing delta V, it's just something read out over the GPIB.

So when you say, "Input is temperature, output is a voltage difference" you mean the hardware is observing a temperature and presenting its value as a delta-V, right? Does the feedback control processing deal directly in delta-V values or is a software driver converting the delta-V to a temperature as it is sampled and before it is processed?


It's a raw delta-V. Our thermometers aren't calibrated, so we don't know exactly what the temperature is, anyway. We just need to keep delta-V near zero. Even better is that the thermometer is in an AC bridge with a ratio transformer on the warm end. Switching the transformer changes the setpoint, but it also changes dV/dT.

As if that's not enough, when a control action is calculate, the program takes the square root of the result and outputs it as a voltage. That makes the output linear in power, since P=V^2/R. But the output isn't really a power. It goes through an attenuator which reduces the size of the finite voltage steps of the DAC, through a shunt resistor, through the heater resistor... you can't know what the actual power is unless you run through the chain and work it out. The controller just puts out a number.

One of the problems I am having in understanding this is that I don't know what is hardware and what is software in the real controller and how they interact. So far my guess is (in order of appearance):

Thermometer: HW
AC Bridge: HW
ratio transformer: HW
"program" that compute square root: SW
Attenuator: HW
DAC: HW
shunt resistor: HW
heater resistor: HW
"controller": SW

Is the "number" put out (by "controller"?) what you were calling delta-V? Or a pseudo power? Or a pseudo temperature?

The previous message indicated that software was reading the DAC. That suggests the resistors are actually before the DAC in the signal propagation. It also seems odd that "program" would be in the middle of the hardware processing if it is software. Is that really part of what "controller" does after reading the DAC?

/*
 read target x
*/
 r->runData[targInChan] = SR530ReadX(r->l[targLoop].ibnum);
 if (fabs(r->runData[targInChan]) > r->maxX[targLoop])
   r->maxX[targLoop] = fabs(r->runData[targInChan]);
/*
 read target y
*/
 r->runData[targSinChan] = SR530ReadY(r->l[targLoop].ibnum);
 if (fabs(r->runData[targSinChan]) > r->maxY[targLoop])
   r->maxY[targLoop] = fabs(r->runData[targSinChan]);
/*
 control target
/*
 if (r->loopMode[targLoop] == controlOn)
 {
   /* calculate new output */
   TempControl(r,targLoop);
   SR530Dac5Out(r->l[targLoop].ibnum, r->runData[targOutChan]);
 }

The SR530 functions are vendor supplied, r is a big data structure that holds all the parameters. TempControl() calculates a control action and places it in r. target x is the usual output from a lock-in, target y is the output with the reference signal shifted 90 degrees, x^2+y^2=V^2, and we trim the bridge to keep y near zero.

Right; this is actually doing pretty close to what I suggest above. The SR530 is the low (GPIB) level driver API I mentioned. However, in an OO design one would have something like:

class Target
{
public:
   float getX(int i) {return SR530ReadX(i);};
   float getY(int i) {return SR530ReadY(i);};
   void setZ (int i, float f) {SR530Dac5Out(i, f);}
   ...
}

where Target is a surrogate for the HW, probably at a higher level of abstraction than an individual ADC. When creating HW surrogates for


I suppose even in a real system you would use Target. Inputs and outputs would be referred to Target, and you would just let physics determine what the temperature is instead of calculating it. The SR530 functions are at too low a level to be addressed at that level.

Then when you want to simulate it, you would replace Target with one that calculates the time evolution. Nothing else needs to be changed. 

Exactly.

Also, I thought the 7/60th ticks were used to filter out 60 Hz pick-up. I assumed that was done in software but this suggests the hardware is making that adjustment. If so, that could be completely ignored because your simulation won't have any 60-cycle pickup in the delta-Vs because they are computed in the simulation.


Is that what it suggests. Well, it's software. It could be any number, we've just traditionally ran with 7/60.

Sending the 7/60th tick event to a hardware element rather than a software element is what suggested that to me.

However, if that processing is about eliminating 60-cycle harmonics, it might not be necessary to your simulation. OTOH, if it is deemed necessary, then you have to insert the noise in your simulation of the temperature samples. B-) Also, I suspect a prime number that is not a divisor of 60 would be better than others.


I don't think it really matters since the system time constants are much longer than 7/60 second. There actually are issues with digital versus analog controllers because of the discrete sampling time of the digital controller-- the system can change between sampling times and will be less stable under a digital controller. But when the characteristic times of system changes are orders of magnitude longer than the sampling time, it really doesn't matter much.

In these days of cheap GHz processors I would expect the digitization effect would be pretty rare.

OTOH, 60 cycle pickup can be substantial. I used to do deep crustal resistivity surveys where one lays out 1/2- to 3-mile grounded dipoles on the roadside. (I was a geophysicist in my misspent youth.) One rainy day we had a line break and I went out to fix it. I forgot my wire strippers so I stripped the wire with my teeth while my wet boots were in mud. Afterwards I measured 60V of 60 cycle on the dipole. It was more than enough the make personal wire stripping an adventure.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • XPC target sampling period.
    ... and it worked perfectly when running a normal simulation in simulink. ... When running this simulation in XPC target i always lose the connection to the target computer if the blocks connected to the s-function block do not have sampling time defined as "inf". ...
    (comp.soft-sys.matlab)
  • Re: Havent done anything real with OOP yet.
    ... solid target, 30 minutes for the liquid He-3 filled target. ... That's one user-adjustable time constant. ... filter; you don't have a lock-in amplifier unless you have a filter. ... signal from the lock-in, calculates a control action, and signals a DC ...
    (comp.object)
  • Re: More Dim Mak Lunacy
    ... right alignment on a moving target who is protecting his vulnerable areas. ... With Tai Chi, everyone seems to make the assumption that the Chi in the name ... "flow") yet are in complete control of the situation. ... "intent" is important. ...
    (rec.martial-arts)
  • Re: Are you being Gang Stalked by Stasi tactics ?
    ... Gang Stalking is a systemic form of control, ... part of this ongoing never ending systemic form of control and harassment. ... These actions are specifically designed to control the target and to keep ...
    (uk.local.kent)
  • Re: drop in demand for US bonds
    ... >>rate means that the economy wants more than the Fed is supplying, ... So the Fed changes the interest rate target to ... > The short term interest rate is a control variable, ... they recalibrate this indicator every month, ...
    (sci.econ)