Re: Lahman, how ya doing?

In article <oXrie.6725$_f7.4143@trndny01>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>Responding to Hansen...
>
>>>>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.
>
>Who's Greg? If we are doing tag teams I will have to get a partner.

You'll need more than one, because I have Me, Myself, and I working on
this.

>
>I am arguing for eliminating SubstituteController because all it is
>really doing is delaying the Controller processing until Thermometer has
>the data ready. So let Thermometer announce to Controller that the data
>is ready directly and then let Controller do it thing with the data.
>Then there is no need for a delay because Thermometer issues the event
>when it is done -- whenever that is. [Any delay that emulates witching
>tick delays in the real controller is handled by using two threads whose
>priorities are tinkered with until the simulation provides a faithful
>emulation of skipped processing. However, as I discovered further
>below, that won't work. But as an academic exercise...]
>
>A UML Sequence Diagram or Collaboration Diagram does a good job of
>representing events. Check it out in your new book. B-) What I am
>arguing for is essentially (assuming some content from previous missives):
>
>Timer Thermometer Sampler Controller Target
> | | | | |
> | E1:one tick | | | |
> |------------->| | | |
> | | E2:sample | | |
> | |---------------->| | |
> | | | | |
> | | E6:sampled | | |
> | |<----------------| | |
> | | | | |
> | E3:60th tick | | | |
> |------------->| | | |
> | | E4:analyze | | |
> | |----------------------------->| |
> | | | | E5:change |
> | | | |------------>|
> | | | | |
> | E1:one tick | | | |
> |---------------------------------------------------------->|
> | | | | |
> | | | | E7:done |
> |<----------------------------------------------------------|
> | | | | |
>
>This is the Collaboration Diagram form where the sequence is not
>absolute in time (e.g., there are many E1 -> E2 -> E6 sequences for each
>E3 -> E4 -> E5 sequence). So Thermometer could get another E1 tick
>before Sampler generates the E6 event. Here Thermometer and Sampler run
>in different threads, as I assumed previously. So on a witching tick
>the slower Sampler thread will result in a skipped E1 tick sample.

Let's see if I can hang with this game. What I'd assumed before was that
parts should be combined to reduce unnecessary units. So, for instance,
I'd combined the germanium resistor, bridge circuit, AC supply,
lock-in, analog to digital converter, and GPIB into a single Thermometer.
Input is temperature, output is a voltage difference (V=0 at the
setpoint). And I had the control logic, digital to analog converter,
an attenuator, and heater resistor as Controller, with input being a
voltage difference and output a heat. Technically everything after the
DAC is analog, but it faithfully changes only when the controller tells
it to change, there was no independent time evolution, and combining them
let me get rid of a square root calculation, so it was as good
as part of the controller. And the target itself was just a chunk of
metal.

We could factor the ADC out of Thermometer (I believe that would be your
Sampler), and factor the DAC out of Controller. Also, the controller gets
a temperature every 7 ticks, a chart gets a temperature every 60 ticks.
And the controller calculates a control action on a schedule, not on the
command of the thermometer or ADC. In the non-OOP real program there's a
big loop that includes a section that checks to see if it's time to do a
control action. If so, it read a temperature and then calls the
controller function. That's a lot like calling the Sampler on a schedule,
and then the Sampler kicking Controller.

So let's see...

Timer Thermometer ADC Controller DAC Target Chart
| | | | | | |
| E1:1 tick | | | | | |
------------>| | | | | |
| | | | | | |
| E1:1 tick | | | | | |
--------------------------------------------------->| |
| | | | | | |
| E2:60 ticks | | | | | |
----------------------------------------------------------->|
| | | | | | |
| E3:600 ticks| | | | | |
----------------------------------------------------------->|
| | | | | | |
| E4:sample, 7 ticks | | | | |
---------------------->| | | | |
| | |E5:control| | | |
| | |--------->|E6:change| | |
| | | |-------->| | |
|E7:1 tick | | | | | |
|------ | | | | | |
| | | | | | | |
|<----- | | | | | |

No events are going to Target or Thermometer other than E1, "analog time
evolution", or being generated by them, because they have the role of
passive elements that always do what they do, and always have their
outputs ready for whoever wants to read them.

The way I'd had elements combined,

Timer->ADC->Controller->DAC => Timer->Controller

And I wanted to see what that self-directed event at the end would look
like.

>
>I am also assuming Controller is doing the heavyweight data analysis and
>Target just emulates the initial response to whatever Controller has
>defined as the new stimuli state. I also assume Target is the front end
>for the heat flow calculations needed to produce a temperature value on
>each tick in the simulation. So Target also needs to get an E1 event
>from Timer to trigger that computation. When that <presumably lengthy>
>computation is done, one is ready for another Timer tick so Target sends
>the E7 event (as an alternative to a self-directed event by Timer).

The calculation is actually good for a single line of arithmetic. Heat
pulses travel surprisingly quickly in this low temperature regime due to
low heat capacity and high thermal conductivity, so the operating equation
is just

delta Q = C delta T


>(1) Insert a "delay" between whoever generates the normally scheduled
>event and whoever responds with the processing that must be skipped for
>the current tick. In effect the delay is such that when the incoming
>event is re-dispatched it is in the next tick. (This was your first
>feedback loop diagram.) I think finding a reasonable mechanism for the
>delay would be tricky, given the disparities in processing time. It
>also gets a bit hoaky because the "delay" may get another tickle in the
>next tick and it should not double dispatch in that tick. In that
>situation one is essentially doing (4) below.

What it should do would depend on the details. But if there was
a Delay catching sample events, it only needs one vacancy and then can
discard any following sample events until the first is dispatched. Other
events, like reset, are sort of meta-simulation and should be passed
immediately.

>
>(2) Find a way to sequence events to take care of the problem as a
>faithful emulation of the real controller. For example,
>
>Timer Target Thermometer ...
> | | |
> | E1:one tick | |
> |------------->| |
> | | |
> | | E7:done |
> |<-----------------------------|
> | | |
> | E1:one tick | |
> |----------------------------->|
> | | | E2:sample
> | | |------------>
> [Remainder same as above]
>
>In this case Timer always sends the E1 event to Target as the first
>thing done in a "simulation tick". Only when it gets back the E7 event
>does is burst out the events in eventList. Now that the simulation
>calculations are out of the way we can revert to the thread priority
>solution for the witching ticks as discussed previously. (Of course one
>now has to have some other means of telling Timer it is time to kick off
>a new simulation tick, like the self-directed event.)
>
>(3) Have Timer determine whether an event should be sent on a given tick
>or deferred. We've been around on this before and I don't like it
>because it trashes Timer's cohesion as a provider of just the Master
>Schedule.
>
>(4) Have whoever owns the processing to be skipped decide if it should
>be ignored. I don't have a problem with this per se, but I would be
>very cautious about what the decision semantics should be. That is, I
>wouldn't want that object to have to understand the semantics around
>skips (e.g., what a witching tick is). Asking Timer for an event count
>on the tick and then comparing that to a <parameterized> attribute to
>determine whether it should skip the processing is pretty abstracted
>(i.e., it doesn't need to know anything about why the threshold is the
>given value). This is full circle to essentially your original
>solution; just the decision semantics are somewhat different to raise my
>comfort level.
>
>>
>>
>>>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.
>
>I am not sure why the feedback processing needs additional ticks. Once
>the data is ready isn't it a pretty linear computation? (I am assuming
>the 7/60 filtering for 60 cycle harmonics is a preprocessing operation
>once one has an adequate set of samples in hand.)
>
>However, if the feedback computations need to march to a drummer, you
>are right that all one needs is a different instance of Timer that is
>initialized with a different set of events.

We might have been throwing past each other here.

>
>>
>> But I don't really think of, say, Thermometer telling Controller what to
>> do. Thermometer just has data for Controller when Controller needs it.
>
>What I am proposing further above is that Thermometer also has a
>responsibility for knowing when enough data has been accumulated (and
>perhaps when it has been preprocessed). It then announces that to
>Controller. Controller then accesses the data to do its thing.
>
>
>*************
>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
>
>
>


--
"Not that there's anything wrong with just lying around on your back. In
its way, rotting is interesing too... It's just that there are other ways
to spend your time as a cadaver." -- Mary Roach, "Stiff", 2003.
.

Relevant Pages

  • Re: Lahman, how ya doing?
    ... >>>so far can be accommodated by the way the events are registered with Timer. ... >>>in the real controller). ... >>>tick is done. ... >>>sequencing of Chart's responsibilities, especially relative to other ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... Straightforward diagram right out of a control theory text. ... Normally Controller would be sent a control event, and would then get a temperature and sample time from Thermometer and calculate a control action. ... But if it had previously received a delay event, it would send a control event to Controller on the next tick. ... 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. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... My assumption was that in the real controller the ... >>>makes at least some sense because I delegated Sampler from Thermometer ... >> simulate a delay, and they express slightly different types of delays. ... And it's the only object besides Timer that generates ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... 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. ... 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. ... Delay gets a temperature and sample time from Thermometer, Controller gets a temperature and sample time from Delay. ...
    (comp.object)
  • Re: Controling Refrigerator Temps
    ... With my controller, the temperature I set it at isn't necessarily the ... temperature my fermenting beer thermometer says. ... I usually set the fridge for 60F in the ... though my wheats seem for some reason to ...
    (rec.crafts.brewing)