Re: [Jmri-developers] Fast Clock Design Questions

[David D. <djd...@ya...>]

Hi Paul,

Thanks again for your comments and suggestions.

--- pau...@ac... wrote:
> 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.

A scripted function is certainly something that could
be triggered--that's what I had in mind for "running a
train across the layout."  I am reluctant, however, to
force users to write a script to turn on a scenery
light, when it's so simple to do it all automatically
in code.

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

Definitely it should not be tied to one object alone,
but having different options, e.g. lights (outputs),
scripted functions, and ??? should be possible.

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

Good information for me. 

> On systems that don't, 
> JMRI would have to provide it's own fastclock
> implementation.

Definitely.  Even on systems that do (Digitrax), we
should allow the option of not using the system fast
clock.
 
> > 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

Looks clear.

> 	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 understand the functionality, but would welcome
ideas on how to set this up from a user's view point.
	
> > 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.

Sounds reasonable--I leave hooks so others can provide
system specific clock implementations that I don't.

I'll have to think a while about how to accomplish
this.  Can anyone think of something similar,
implementation-wise, in the current JMRI?

Dave.



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/