Re: Lahman, how ya doing?

In article <TMKhe.1694$Vu6.1593@trndny03>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>Responding to Hansen...
>
>> So in other words, the time is not sent to SlopeCalculator (or the
>> controller, or etc.) when an event is sent to it. The thermometer records
>> both the temperature and the time when a Get Sample event is sent to it.
>> When a Calculate Slope event is sent to SlopeCalculator, it receives both
>> the temperature and the time that the temperature was recorded from
>> Thermometer, not from Timer, and not passed in the event. I want to
>> assign the primary acquisition and storage of the time of a sample with
>> the thing that takes the sample, they're a matched pair. When something
>> uses the sample to calculate a slope, control action, filtering, etc., it
>> gets the time of sample from the same place that it got the value of the
>> sample.
>
>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.


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

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.

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.

--
Irony: "Small businesses want relief from the flood of spam clogging their
in-boxes, but they fear a proposed national 'Do Not Spam' registry will
make it impossible to use e-mail as a marketing tool."
http://www.bizjournals.com/houston/stories/2003/11/10/newscolumn6.html
.

Relevant Pages

  • 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: keggerator setup and dispensing
    ... keg inside. ... have my brew thermometer inside to measure the air temperature, ... where I have the fridge's temperature knob set. ... A temperature controller will allow you to set the desired ...
    (rec.crafts.brewing)
  • Re: DDR controller - best device to perform
    ... to clock a DDR controller. ... to add/subtract a small delay around the 90 degrees. ... I think the trace length on the ddr signals is about 2-3 inches. ...
    (comp.arch.fpga)
  • Re: DDR2 controller V4 vs V5 differences ?
    ... The controller is based on MiG generated ... calibration doesn't work there because the maximum delay the IDELAY can ... would just never find the second edge because it could not delay by more ...
    (comp.arch.fpga)
  • [PATCH 04/10] usb,early_printk: EHCI debug controller initialization delays
    ... When using the EHCI host controller as a polled device, ... where as the typical delay is 1-5ms for an EHCI ... int loop; ...
    (Linux-Kernel)