Re: Lahman, how ya doing?

In article <9_qje.11131$Y36.5049@trndny05>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>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

Yep. Basically everything is hardware except the controller, getting a
delta-V in and directing a V out.

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

delta-V is the temperature, T-T0. In a somewhat abstract way, the number
that the controller calculates is a power, except scaled by non-Watt
units. Then the square root is taken, converting it to a voltage, but it
becomes power again in the heater resistor. The square root linearizes
the output from the heater, not the output from the DAC.

>
>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?

The output circuit looks like

r1 shunt heater
Vout ----/\/\/-+--/\/\/----/\/\/--
| |
/ gnd
r2 \
/
|
gnd

r1 and r2 form a resistaive divider, Vout'=Vout*r2/(r1+r2). Since it's
digitized (13 bits) there's a minimum voltage step dV, therefore a minimum
power step dP=(dV)^2/4R. A 1/20 attenuator increases the power resolution
by a factor of 400, at the cost of losing some dynamic range.

The shunt resistor is a precision Vishay resistor, about 20K, the voltage
across that gives the current since I=V/R. The controller isn't involved
in that, it's just saved to disk for later analysis. And the heater
resistor is a metal film resistor, also 20K, epoxied to the target, the
voltage across that is measured, and again saved to disk for later
analysis. And the power delivered is P=IV.

>
>>>>/*
>>>> 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.

Okay, it's all making sense.

>
>>>>>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.

That's limited by ADCs rather than GHz processors. I don't know off-hand
how fast they are, but the faster ones are pricier. But they're fast
enough.

Then again, I don't know about microcontrollers. Small memory, lots
of features like ADCs included, but I don't think they're GHz. It's
common to sprinkle microcontrollers around in a machine instead of
calculating all of the control actions centrally. The "brains" would then
tell each part where to be, not how to get there.

>
>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.

That sounds like fun. Except for the part about stripping the wire with
your teeth. I've applied for a position as a plant engineer, at a power
plant, which promised a lot of climbing, crawling, and working outside in
extreme weather, and the plant being in the middle of a company-owned
nature preserve. It's just about the best I could hope for.

--
"Are those morons getting dumber or just louder?" -- Mayor Quimby
.

Relevant Pages

  • Re: Lahman, how ya doing?
    ... 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 goes through an attenuator which reduces the size of the finite voltage steps of the DAC, through a shunt resistor, through the heater resistor... ... The controller just puts out a number. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... A 1/20 attenuator increases the power resolution by a factor of 400, at the cost of losing some dynamic range. ... The shunt resistor is a precision Vishay resistor, about 20K, the voltage across that gives the current since I=V/R. ... The controller isn't involved in that, it's just saved to disk for later analysis. ...
    (comp.object)
  • Re: Havent done anything real with OOP yet.
    ... >>is what I was thinking of as the HVAC hardware. ... >>whether it includes the resistor or not. ... rather than a separate Controller. ... inclination to put this calculation in Cell. ...
    (comp.object)
  • Re: Grow-Tron, For Sale!
    ... Then, with the controller logic removed, there are questions about ... "DO NOT PLUG THE GROW-TRON POWER SUPPLY JACK PLUGS INTO THE MEDIA CARD ... So, that levity aside as I'm still an idiot about the LEDs, hmm... ...
    (rec.gardens)
  • Re: Computer always restarts
    ... S5" option in the power tab of BIOS is inaccessible-both in the BIOS ... controller, then it cannot command power off. ... in HAL) for that particular motherboard. ...
    (microsoft.public.windowsxp.hardware)