Re: [Jmri-developers] Fast Clock Design Questions

[<pau...@ac...>]

On  2 Jun, David Duchamp wrote:
> The initial use for this on my layout is to control
> scenery lighting on a fast 24-hour schedule.  I
> understand that there is other functionality that can
> be controlled by a Fast Clock, for example, triggering
> running a train across the layout.

If we want to keep this more generic, wouldn't we really want something
more along the lines of a Scheduled Event?  The event would trigger some
scripted function, which could be any function JMRI is capable of
performing.

Generically These actions are highly layout dependent, so I don't feel
it should be tied to any specific object (like you light objects).

> I only understand Fast Clock functionality in a very
> basic sense, and haven't used one previously.  I don't
> have a design yet, and would welcome input.  All
> comments and suggestions are welcome, but I would
> especially like input on:
> 1) clock functionality from a user point of view, 

It works like a clock, only the time moves at a quicker rate.  Typically
ratios to normal time are 2:1,4:1,6:1, and 8:1.  I've even seen a few
people who use 12:1 fastclocks.  Faster rates are possible, though not
common.

A Fastclock is really an operations device to make it seem like the
compressed distances between two points on a model railroad are larger
than they actually are.  

> 2) how a Fast Clock might interact with systems other
> than Digitrax and C/MRI, and 

Some systems support a fastclock in the hardware (Digitrax is one of
them), but from my own research, most do not.  On systems that don't, 
JMRI would have to provide it's own fastclock implementation.

> 3)any implementation suggestions (both global and
> detailed).

Minimally, you need to have methods for:
	setting the clock parameters (mainly the time, and the ratio to
        "normal time").
	starting the clock
	stoping the clock
	syncronizing the clock with interfaced hardware (if supported) (this 
	should probably be two functions, one to pull the time from
        the hardware , and one to set the time on the hardware).	

> I won't necessarily implement a "full featured" Fast
> Clock, but I will design whatever I do implement to be
> extensible in that direction.  Please help me
> understand what "that direction" should be.

The generic clock almost has to be a full featured clock, with any
system specific clock implementations overriding the functionality of
the generic clock.

Paul
-- 
______________________________________________________________________________

	"Quality is a Characteristic of thought and statement that 
	is recognized by a nonthinking process. Because 
	definitions are a product of rigid formal thinking, 
	quality cannot be defined."
		Robert M. Pirsig
			Zen and The Art of Motorcycle Maintenance