Re: Lahman, how ya doing?

In article <Xq6ie.3088$Vu6.1200@trndny03>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>Responding to Hansen...
>
>>>Is there an echo...
>>
>>
>>>...echo...
>>
>>
>>>...echo...
>>
>>
>> Sometimes it takes me a while to catch on. You make more sense now than
>> you did last week.
>
>Natural language is a tough medium of communication, especially when the
>parties have quite different world views. That's why my messages tend
>to be long; I push at the world view as well as the point in hand.
>
>OTOH, I did have a minor substance abuse problem last week...
>
>>>>Is this a reasonable alternative? Thinking specifically of a simulation,
>>>>the Sampler, representing the hardware interface to the lock-in, gets its
>>>>ticks reliably from a high priority queue. It always has a timely
>>>>temperature sample and time of sample, ready for whoever wants to read it.
>>>>Thermometer, representing the part of the digital world that records the
>>>>temperature for system use, the code that can be delayed, is on the low
>>>>priority queue. Its processing can be delayed, and Sampler can keep right
>>>>on sampling without it. But when Thermometer does receive a Get Sample
>>>>event, it gets whatever sample and time of sample that Sampler has at the
>>>>time. No instance handles in the events.
>>>
>>>Remember my context. My assumption was that in the real controller the
>>>thing that got skipped was the actual sample on a given time tick
>>>because that sampling was in a lower priority thread. To emulate that
>>>Sampler needs to run in a lower priority thread in the simulation.
>>>Since the goal is to emulate sample skips, it doesn't need to trigger
>>>off the real schedule events. So it can be daisy-chained to
>>>Thermometer's processing of the real schedule events. Intuitively that
>>>makes at least some sense because I delegated Sampler from Thermometer
>>>in the first place.
>>
>>
>> I can think of two ways now of simulating a delay if I decide I want to
>> simulate a delay, and they express slightly different types of delays.
>> There might be another echo here, I struggled to comprehend your
>> solution. But one version filters data, the other filters events. In a
>> pure simulated mode,
>>
>> Controller -> Target -> Thermometer
>> | |
>> ----<--- Delay <--------
>>
>> Delay gets a temperature and sample time from Thermometer, Controller gets
>> a temperature and sample time from Delay. Normally it just goes right
>> through. But when Delay gets a delay event, it returns an old value of
>> temperature for one tick. Whether it returns an old or current value of
>> the sample time depends on the details of what you're trying to simulate,
>> but one way or the other is not hard to do.
>
>That's certainly viable. It also addresses the point I was pushing
>about dealing with skips separately from Timer's view of what the
>schedule should be and separately from what Thermometer and Controller
>live to do.
>
>I would probably opt for this sort of thing if the delay were something
>like a settling time that was proportional to the gradient. IOW, some
>feature of the system that could be explicitly modeled with dynamic
>behavior.
>
>>
>> The second way.
>>
>> Controller -> Target -> Thermometer
>> | |
>> -----------<------------
>>
>> Straightforward diagram right out of a control theory text (not really an
>> OOA diagram). Normally Controller would be sent a control event, and
>> would then get a temperature and sample time from Thermometer and
>> calculate a control action. Instead, ControllerSubstitute would be sent
>> a control event. Usually it would immediately send a control event to
>> Controller. But if it had previously received a delay event, it would
>> send a control event to Controller on the next tick. If it is sent two or
>> three delay events in succession (two or three identical events sent to
>> the same object on a single tick), it can delay two or three ticks.
>
>But ControllerSubstitute just seems like another name for Delay above.
>It still seems like something inserted into the feedback loop after
>Thermometer and before Controller.
>
>When I saw the diagram I thought you were going to suggest that the
>event that triggers Controller is generated by Thermometer rather than
>Timer. IOW, if nothing has changed because of the delay, Controller
>doesn't do anything.

That's a data flow diagram like you'd get in a control theory book, not an
event flow diagram. The event flows would look like

Timer --> SubstituteController -> Controller
|
-> Target
|
-> Thermometer

Controller still gets its data from Thermometer, Thermometer from Target,
Target from Controller. SubstituteController doesn't get data at all, it
just gets events. And it's the only object besides Timer that generates
any events. It's a substitute as far as Timer sending control events is
concerned, not as far as Target and Thermometer are concerned. Too many
arrows for ASCII, and Greg's not really sure how to represent it with
pencil and paper anyway, and perhaps his naming conventions aren't always
the best.

>
>As I recall your original description, the feedback loop actually has a
>lot of processing in with filters, FFTs, etc. that chews on a large
>number of samples gathered over a relatively long period compared to the
>sampling rate. So you really have:
>
>Controller ---> Target ---> Thermometer
> ^ |
> | |
> +------- Analysis <----------+
>
>Once the Analysis is done, one knows what the Controller needs to do, so
>one could trigger Controller as soon as Analysis finishes. If when
>Analysis finishes varies for whatever reason relative to Timer's ideal
>schedule one could insert a delay mechanism to defer Timer's event to
>Controller. But wouldn't it be simpler to just let Analysis generate
>the event when it is done with the current pile of data?
>
>Similarly, Analysis should be able to kick off its processing whenever
>there are enough data samples available from Thermometer. [An obvious
>exception is the 7/60 adjustment for 60 cycle noise that I assume is
>part of Analysis. But hopefully that can be split out as a preliminary
>preprocessing of the sample set and this discussion would apply to the
>stuff after that.] Again, any skips/delays seem upstream and Analysis
>could get triggered by whoever deems there are enough <preprocessed>
>samples rather than by Timer.
>

I include Analysis with Controller. Controller gets an error signal,
V_temperature - V_setpoint. It's sensible, I think, to include the
lock-in with Thermometer, and the output is a voltage, not a temperature.
And it's a differential measurement, so the lock-in output is the error
signal. So I didn't really have an Analysis block in there. I had a
Delay block in the first diagram, but that's specifically a delay, it
doesn't analyze anything.

The timing would then be Controller, 7/60; Target, analog; Thermometer,
analog. Anything analog I assume will be at the highest time resolution
the simulation offers, whatever that might be.

>So the Timer would only synchronize the events that trigger gathering
>and preprocessing the temperature samples. Once the samples were
>gathered and preprocessed -- in however much time it took -- everything
>else in the feedback look could be daisy-chained from the owner of the
>samples (presumably Thermometer). If so,...
>
>>
>> And in an explicit concession to you making more sense now, that
>> relationship can be expressed in main() by registering events with Timer
>> to ControllerSubstitute, but not to Controller. Controller
>> is registered with ControllerSubstitute. And then Controller doesn't
>> know it's not getting its events from Timer, it just knows that sometimes
>> it gets events.
>
>...the feedback loop events don't need to be registered because they
>aren't issued by Timer on a fixed schedule.

I don't know. Say Controller receives a control event every 7 ticks and
the other parts receive an analog time evolution event every tick. Then
something would have to count out 7 ticks before sending a control event
to Controller, and that would essentially be a Timer. You could stick a
second Timer in the loop that receives tick events from Thermometer and
sends control events to Controller.

But I don't really think of, say, Thermometer telling Controller what to
do. Thermometer just has data for Controller when Controller needs it.

--
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it. "
-- Gene Spafford, 1992
.

Relevant Pages