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
is too detailed to describe here but a couple of points
are worth mentioning.
is difficult to learn. The documentation is not well organized
and, as a beginner, you may not know exactly to look for
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.
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.
you have working scripts for most of the types of things
you want to do, its not terribly difficult to make another
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.
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. 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.
concept specific to RHJ Rail that has been
developed over time is the concept of RUN or SIMULATION
In RUN mode, everything works as you might expect in real
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
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 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!
information can be provided on request to those interested
in these concepts.
details on any of the above can, of course, by obtained
by contacting RHJ