Re: Lahman, how ya doing?

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.

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.

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.


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

  • 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?
    ... >> controller, or etc.) when an event is sent to it. ... >> both the temperature and the time when a Get Sample event is sent to it. ... >> Thermometer, not from Timer, and not passed in the event. ... I can think of two ways now of simulating a delay if I decide I want to ...
    (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)
  • [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)