I appreciate your patience with an outsider like me.
In one way or another, we are all outsiders from time to time. Certainly I am an outsider when it comes to understanding the documentation of RailCom or any of the other implementations of the collection of DCC transmitter-receiver pairs that are collectively called Reporters in the JMRI context. Also, there is much more of the JMRI software that I don't understand, than there is of the PanelPro sections that I do have a working grasp of.
I feel that I
could make such a use of AutomatonExample and its refinement, but your example
seemed to me too long and complicated at first sight to do this.
Your original post referenced both "AutomatonExample.py" and "BackAndForth.py" and I took those as the beginning of a common vocabulary. No software code of more than a few lines has ever made sense to me "at first sight" and I used to teach Computer Science back when that was an embryonic field of study.
So, let me start from scratch. There is a single loco I want to move back and
forth between two blocks. No other train can touch its route. The only
intrusion can occur in either of the terminal blocks that can accommodate
another train, but physically these blocks are long enough to cause any
collision.
A single loco automatically trundles back and forth between locations named D and G perhaps going through locations E and F. Other trains can intrude at either or both D and G but cannot go into E or into F. Someone is controlling each of those other trains and watching to prevent a collision with the automatically controlled train. Is this an over simplification? Or did you also want the automatically controlled train to wait at E if D is occupied?
A RailCom current sensing detector is attached to each of these terminal
blocks.
In the simplification, "each of these terminal blocks" means locations D and G? JMRI uses "blocks" with a subtly different meaning and often someone on this list will interchange Sensor for Block when there is a one-to-one correlation.
Also, I am no longer convinced that each RailCom Sensor is the same as each RailCom Reporter as I was when working on this script a few days ago. Is there a one-to-one Sensor to Reporter matching as I inferred from the JMRI help webpages at that time?
Can your example handle this situation? If so, I am going to make a more
thorough effort to grasp it. You may facilitate my effort by pointing out part
of the script where the sensor reporter, also referred to by Paul in the
second of this series of posts, is used to trigger the change of movement of
my train ignoring, however, whether or not another train enters, stays or
leaves there.
The portion of the script that is intended to do what you describe is only sketched at this stage since I remain ignorant of the workings of RailCom. In particular, some of the documentation that I have found uses the apparent interchange of the words "Sensor" and "Detector" and "Reporter" as if they have the same meaning in this context.
Starting at line # 168 with the text:
def AreWeThereYet ( self, fpSensor ) :
temP_Int = 0
while not ( temP_Int == self.LocoAddress ) :
self.waitSensorActive( fpSensor )
...
an endless loop of wait until the Sensor identified as "fpSensor" changes to ACTIVE and the DCC loco number matches.
Since the method named "AreWeThereYet()" is called for each direction the train is moving and is supplied with the predetermined destination Sensor for that direction, only one effort is needed to debug the RailCom portion of the script. The intention was that once the Sensor becomes ACTIVE, the code could determine what the loco DCC address was and change the value of "temP_Int" to that address. IF that DCC address matches the value of "self.LocoAddress" then the condition requested at line # 170 becomes True and we then stop the automatically controlled locomotive and return to the calling procedure to continue.
That section contains numerous links to JMRI documentation webpages but is largely based on wishful thinking and perhaps even dead end misunderstanding. After looking at "ReporterFormatter.py" that Paul identified, it is now likely that what is happening in the while -- loop is waiting for the wrong information.
If you are serious about understanding the syntax and indentation rules that drive Python programmers crazy, it is important to get a good editor that understands most of the rules of the language. My favorite is NotePad++ that is free and I discovered at a long time ago. There are a lot of other good choices available. When I was in the software business, we used to claim it was easier to start a war by claiming one editor was best than any other way.
If this is beginning to help, we can discuss what would be next. It was my hope that some RailCom or Reporter experts would have pointed out what you needed to know in this area and let them proceed. The example scripts that refer to Reporters do not yet make much connection to what I can find in the help webpages.
Cliff
