Limitations
The
number of elements in a master script list has no theoretical
limit but experience has shown that it is better to keep
the total time an entire master script list requires to
something practical, say 5, 10, or maybe 15 minutes of real
time.
Script
Development
This
is too detailed to describe here but a couple of points
are worth mentioning.
JMRI/Jython
is difficult to learn. The documentation is not well organized
and, as a beginner, you may not know exactly what to look
for anyway.
A
good approach is the classic "take something that works
and modify it to do your thing". There are a number
of example scripts on the JMRI web site and this is a good
place to start.
One
concept to watch out for is initialization. Such things
as sensors, turnouts, and their associated tables in JMRI
Panel Pro or Decoder Pro should be set up and tested before
anything very complicated is undertaken.
After
you have working scripts for most of the types of things
you want to do, its not terribly difficult to make another
one.
Python
is a powerful programming language and you can do a lot
in Jython/Python beyond just starting an engine and sounding
its horn. There are many functions (mathematical, logical,
time, and so on) that can help calculate, format, process
and handle many different things.
A
good tip to note is that when you find you need to do something
that is not readily apparent from the JMRI examples, do
a Python search for what you need. Things like tables, arrays,
array processing, output formatting, and so on come to mind.
Remember,
Python is not aware of your model railroad environment but
does have many powerful programming elements including everything
from file processing, mathematical, statistical functions,
and many, many other useful methods.
Testing
One
concept specific to RHJ Rail that has been
developed over time is the concept of RUN or SIMULATION
mode.
In RUN mode, everything works as you might expect in real
time.
In
SIMULATION mode, time flies. To do this in a script, time
is defined in milliseconds and for RUN mode, one second=1000
milliseconds, just like in real life. In SIMULATION mode,
one second=100 milliseconds and layout power is automatically
turned off, all sensors are active (so the script doesn't
wait indefinitely for a sensor to become active) and so
on.
Thus
for debugging scripts, SIMULATION mode is at least 10 times
faster than RUN mode, plus the script doesn't have to wait
for the time it takes for a train to travel to the next
sensor, so you can do testing and find script or logic errors
in a much shorter time. Also, the wear and tear on equipment
is reduced.
There
is nothing worse than being 15 minutes into a session and
then having a script error occur. It can take a very long
time to get equipment back into its original starting locations
in order to try again, not to mention tracking down and
fixing the script error that caused things to go wrong in
the first place!
Further
information can be provided on request to those interested
in these concepts.
continued
on Technical - Page 8
More
details on any of the above can, of course, be obtained
by contacting RHJ
Rail.