|
I'm progressing on entering my railroad in Layout Editor. I've set the track blocks and my names for the turnouts. When adding one, there's a dialog box for labeling its control signal. But, I'm not sure how to use it, and am having trouble finding a way to edit it for existing turnouts. I did find a way a few times, but when I labeled the control for more than one, all those with labeled control signals ended up with whatever signal name I'd given the last one!
So far, I've been unable to find anything in the Layout Editor turnout help that explains why they're all the same, or how to give each a unique control. On my railroad, there will be nearly 64 controlled turnouts, with turnout addresses of 0 to 63. For example, the first turnout, IT00, is labelled Denver 01, and will be controlled and its position read at turnout address 00. IT01 is Denver 02, addressed at 01. IT02 and IT03 are a crossover, and linked logically in the turnout table and mechanically on the railroad. The board will operate them at either address 02 or 03. Most of the turnout's control addresses are the same as their IT number, but will not always be so.
So, how is unique control information entered for turnouts, as a step in mapping them to the railroad's control hardware? Is there a short answer to that, or can someone guide me to a site with a longer one?
Don Weigt
|
Hi Don,
If Dave Sand does not answer this I will have a go tomorrow morning. Happy New Year to you.
toggle quoted message
Show quoted text
I'm progressing on entering my railroad in Layout Editor. I've set the track blocks and my names for the turnouts. When adding one, there's a dialog box for labeling its control signal. But, I'm not sure how to use it, and am having trouble finding a way to edit it for existing turnouts. I did find a way a few times, but when I labeled the control for more than one, all those with labeled control signals ended up with whatever signal name I'd given the last one!
So far, I've been unable to find anything in the Layout Editor turnout help that explains why they're all the same, or how to give each a unique control. On my railroad, there will be nearly 64 controlled turnouts, with turnout addresses of 0 to 63. For example, the first turnout, IT00, is labelled Denver 01, and will be controlled and its position read at turnout address 00. IT01 is Denver 02, addressed at 01. IT02 and IT03 are a crossover, and linked logically in the turnout table and mechanically on the railroad. The board will operate them at either address 02 or 03. Most of the turnout's control addresses are the same as their IT number, but will not always be so.
So, how is unique control information entered for turnouts, as a step in mapping them to the railroad's control hardware? Is there a short answer to that, or can someone guide me to a site with a longer one?
Don Weigt
|
Don,
What hardware are you using to drive the turnouts? As a general rule, the hardware defines the turnout system name.
For example, a Digitrax DS64 can drive 4 switch machines. The default JMRI turnouts will be LT1 thru LT4. The DS64 can be programmed to use any number between 1 and 2048. LT stands for LocoNet Turnout. NCE would be NT, CMRI would be CT, etc.
Dave Sand
toggle quoted message
Show quoted text
On Dec 31, 2018, at 2:42 PM, Don Weigt <dweigt47@...> wrote:
I'm progressing on entering my railroad in Layout Editor. I've set the track blocks and my names for the turnouts. When adding one, there's a dialog box for labeling its control signal. But, I'm not sure how to use it, and am having trouble finding a way to edit it for existing turnouts. I did find a way a few times, but when I labeled the control for more than one, all those with labeled control signals ended up with whatever signal name I'd given the last one!
So far, I've been unable to find anything in the Layout Editor turnout help that explains why they're all the same, or how to give each a unique control. On my railroad, there will be nearly 64 controlled turnouts, with turnout addresses of 0 to 63. For example, the first turnout, IT00, is labelled Denver 01, and will be controlled and its position read at turnout address 00. IT01 is Denver 02, addressed at 01. IT02 and IT03 are a crossover, and linked logically in the turnout table and mechanically on the railroad. The board will operate them at either address 02 or 03. Most of the turnout's control addresses are the same as their IT number, but will not always be so.
So, how is unique control information entered for turnouts, as a step in mapping them to the railroad's control hardware? Is there a short answer to that, or can someone guide me to a site with a longer one?
Don Weigt
|
Dave,
My railroad interface is home brew. I'm looking for a way to map the turnouts into a few bytes of data in computer RAM, where an interrupt driven interface will write it to a board to control turnouts, each with its own simple decoder card.
I just need a way to identify data to (and from) each to map it into the turnout control (and position feedback) RAM. So, I need to identify two output bits in a specific byte for each turnout (and two more input bits for position feedback. Both are active for a short time as the points pass midway between the two normal positions.) I could just define them as ones and zeros for 128 bit locations, and let the computer arrange them eight per byte. My turnouts have addresses from 00 up to about 60.
Right now, I have program default IDs, and have added my own text label names for the turnouts. They're assigned to blocks. But, I don't know how to get data from them for the railroad, and in turn, get returning position data connected to the panel symbols to show turnout positions.
|
Don,
Where does your home brew sit in the following simplified Digitrax map? While this example is Digitrax specific, the basic concepts apply to most JMRI to layout connections.
JMRI <-> FTDI Drivers <-> LocoBuffer-USB <-> LocoNet <-> DS64 <-> Tortoise
The LocoBuffer-USB provides the bridge between the computer hosting JMRI and the Digitrax LocoNet.
Dave Sand
toggle quoted message
Show quoted text
On Dec 31, 2018, at 10:36 PM, Don Weigt <dweigt47@...> wrote:
Dave,
My railroad interface is home brew. I'm looking for a way to map the turnouts into a few bytes of data in computer RAM, where an interrupt driven interface will write it to a board to control turnouts, each with its own simple decoder card.
I just need a way to identify data to (and from) each to map it into the turnout control (and position feedback) RAM. So, I need to identify two output bits in a specific byte for each turnout (and two more input bits for position feedback. Both are active for a short time as the points pass midway between the two normal positions.) I could just define them as ones and zeros for 128 bit locations, and let the computer arrange them eight per byte. My turnouts have addresses from 00 up to about 60.
Right now, I have program default IDs, and have added my own text label names for the turnouts. They're assigned to blocks. But, I don't know how to get data from them for the railroad, and in turn, get returning position data connected to the panel symbols to show turnout positions.
|
On approach that¡¯s been used in the past: *) Define internal sensors (with names like IS1, IS2, IS3) and internal turnouts (with names like IT1, IT2, IT3) *) Put those into Layout Editor as desired *) Write a script that interfaces your homebrew interface to those internal sensors and turnouts: When the scripts sees IT1 change state, the script does the right thing to make that happen on the layout, and when the layout indicates that some input has changed, the script sets the appropriate state in the appropriate internal sensor. I don¡¯t quite understand how your interface really works. RAM isn¡¯t generally visible from one program to another in a modern PC. But people have made the general approach work for multiple kinds of hardware interfaces, so it seems a reasonable place to start. Bob On Dec 31, 2018, at 8:36 PM, Don Weigt <dweigt47@...> wrote:
My railroad interface is home brew. I'm looking for a way to map the turnouts into a few bytes of data in computer RAM, where an interrupt driven interface will write it to a board to control turnouts, each with its own simple decoder card.
I just need a way to identify data to (and from) each to map it into the turnout control (and position feedback) RAM. So, I need to identify two output bits in a specific byte for each turnout (and two more input bits for position feedback. Both are active for a short time as the points pass midway between the two normal positions.) I could just define them as ones and zeros for 128 bit locations, and let the computer arrange them eight per byte. My turnouts have addresses from 00 up to about 60.
Right now, I have program default IDs, and have added my own text label names for the turnouts. They're assigned to blocks. But, I don't know how to get data from them for the railroad, and in turn, get returning position data connected to the panel symbols to show turnout positions.
-- Bob Jacobsen rgj1927@...
|
Dave,
Thanks for the reply. Happy New Year!
First, I'm not using Digitrax, I'm using EasyDCC. I think Digitrax just got into this conversation as an example system. I'm not sure how much that matters. JMRI supports EasyDCC, so that should be no problem, except a different JMRI driver.
I'm not sure how to fit my stuff into your diagram. Here's an attempt, showing where I'm confused, stuck, or just ignorant...
Your example: JMRI <-> FTDI Drivers <-> LocoBuffer-USB <-> LocoNet <-> DS64 <-> Tortoise
My plan: JMRI <-> Drivers/JMRI interface <-> Serial cable <-> Layout control computer <-> Serial cable <-> EasyDCC ????????????????????????????? ? ?????????????????????????????????????????? or network?????? 486-33 with expansion slots ??????????????????????????? ?????????????????????????????????????????????????????????????????????? MD-DOS
?????????????????????????????????????????????????????????????????????????????????????????????????? Compiled BASIC control program
???????????????????????? ? ? ?????????????????????????????????????????????????????????????????????? Assembly language I/O driver
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ^ ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? v
?????????????????????????????????????????????????????????????????????? ? ????? Railroad interface I/O board <-> Parallel cable <-> Railroad hardware
In the layout control computer, the I/O is passed between the control program and I/O driver by mapping the data in shared RAM tables. The control program puts data in the output RAM area, and inputs data from the input ram area. The interrupt triggered I/O driver sends output data from the shared output RAM to the railroad hardware, and reads input data from the railroad hardware and stores it in the shared input RAM.
If I can connect the computer to JMRI, then the compiled BASIC control program would just pass I/O data between RAM and the JMRI interface.
The PC may be too out of date and not powerful enough to run JAVA and JMRI, so may need to be on a different computer. I can't upgrade it very far, as I need an "IBM AT" expansion slot to hold my Railroad I/O board. All my newer old computers don't have any. JAVA on another computer is acceptable, I could use a newer one for dispatching and to host JMRI.
My original question was about how to identify the data in JMRI so it could be mapped into my I/O RAM. All the turnouts on my JMRI panel are labelled by JMRI as TO1, TO2, TO3, and so on. All the photodetectors are labelled as ISPD00, ISPD01, ISPD02, and so on. Layout Editor added the IS prefix to all my typed in designators when I was adding them to the panel. I don't know how to identify block occupancy, photodetector, and turnout position input data so it displays on my LE panel, or how to get turnout position, reverse loop phase control, and block power control data output from JMRI, and map it into my I/O.
I think Bob Jacobsen's following message may help me there.
Don Weigt
|
Thanks, Bob, and Happy New Year!
I think you are saying I could use my compiled BASIC program to map my I/O input data bits to the LE names and pass that info to the JMRI panel(s) as turnout position or detector state inputs; and control signals from JMRI identified by their source panel elements to put that data in the correct places in my I/O output RAM for the interrupt routine to pass it to the railroad.
That sound like what I want to do. I still will need to learn how JMRI formats that I/O data, and how to access it. Then, I'll be able to write the code to pass it to and from my layout I/O RAM. I think with revision, my compiled program can take the place of the script you mentioned.
Don
Don Weigt
|
Don,
Your explanation is perfect.
I created a simulated EasyDCC connection on JMRI. Only the turnout table is supported. I also reviewed the CVP document on computer interfacing and I did not find any support for layout to computer sensor type messages.
It looks to me that the solution is a separate serial connection from the JMRI computer to the 486. A script on the JMRI computer interacts with JMRI and sends and receive commands to/from the 486 by talking to the Basic Control program. The Basic Control program receives turnout commands from JMRI and sends turnout feedback and other sensor inputs back to JMRI via the script.
In the jython directory is SerialPortTest.py which shows sending and receiving data on the serial interface.
Since you would be controlling the command structure at both ends of the serial interface, you can design your own.
Another idea: Implement CMRI communication into the Basic Control program and configure JMRI to talk to a ¡°CMRI¡± device. This eliminates the script and creating your own command structure. It would still be a separate serial interface.
Dave Sand
toggle quoted message
Show quoted text
On Jan 1, 2019, at 10:50 AM, Don Weigt <dweigt47@...> wrote:
Dave,
Thanks for the reply. Happy New Year!
First, I'm not using Digitrax, I'm using EasyDCC. I think Digitrax just got into this conversation as an example system. I'm not sure how much that matters. JMRI supports EasyDCC, so that should be no problem, except a different JMRI driver.
I'm not sure how to fit my stuff into your diagram. Here's an attempt, showing where I'm confused, stuck, or just ignorant...
Your example: JMRI <-> FTDI Drivers <-> LocoBuffer-USB <-> LocoNet <-> DS64 <-> Tortoise
My plan: JMRI <-> Drivers/JMRI interface <-> Serial cable <-> Layout control computer <-> Serial cable <-> EasyDCC
or network 486-33 with expansion slots
MD-DOS
Compiled BASIC control program
Assembly language I/O driver
^
v
Railroad interface I/O board <-> Parallel cable <-> Railroad hardware
In the layout control computer, the I/O is passed between the control program and I/O driver by mapping the data in shared RAM tables. The control program puts data in the output RAM area, and inputs data from the input ram area. The interrupt triggered I/O driver sends output data from the shared output RAM to the railroad hardware, and reads input data from the railroad hardware and stores it in the shared input RAM.
If I can connect the computer to JMRI, then the compiled BASIC control program would just pass I/O data between RAM and the JMRI interface.
The PC may be too out of date and not powerful enough to run JAVA and JMRI, so may need to be on a different computer. I can't upgrade it very far, as I need an "IBM AT" expansion slot to hold my Railroad I/O board. All my newer old computers don't have any. JAVA on another computer is acceptable, I could use a newer one for dispatching and to host JMRI.
My original question was about how to identify the data in JMRI so it could be mapped into my I/O RAM. All the turnouts on my JMRI panel are labelled by JMRI as TO1, TO2, TO3, and so on. All the photodetectors are labelled as ISPD00, ISPD01, ISPD02, and so on. Layout Editor added the IS prefix to all my typed in designators when I was adding them to the panel. I don't know how to identify block occupancy, photodetector, and turnout position input data so it displays on my LE panel, or how to get turnout position, reverse loop phase control, and block power control data output from JMRI, and map it into my I/O.
I think Bob Jacobsen's following message may help me there.
Don Weigt
|
I think I wasn¡¯t entirely clear in my prior message, because there seems to be some misconceptions in the following. Internally, JMRI has Sensor and Turnout objects. There is no ¡°I/O data¡± to format. Your compiled program, unless it¡¯s in Java and built into JMRI _cannot_ take the place of the script I mentioned. That script would run _inside_ JMRI, look at JMRI¡¯s Sensor and Turnout objects, and then talk to your program via a serial, USB or network connection. Because you¡¯d be coding both ends of that connection (in the JMRI-resident script and your control program), you¡¯re free to define the exchanged information as you¡¯d like. Alternately, JMRI can already do input and output to _lots_ of various hardware systems via serial or USB connections. If you want to run a serial link to your control computer and have it understand one of those protocols, then JMRI can talk to that. EasyDCC is, well, easy to implement, but doesn¡¯t do input (sensors); C/MRI is also reasonably simple and can do both input and output. Bob On Jan 1, 2019, at 9:05 AM, Don Weigt <dweigt47@...> wrote:
I still will need to learn how JMRI formats that I/O data, and how to access it. Then, I'll be able to write the code to pass it to and from my layout I/O RAM. I think with revision, my compiled program can take the place of the script you mentioned.
-- Bob Jacobsen rgj1927@...
|
Thanks, Bob.
The little light bulb is beginning to turn on dimly! My script running in JMRI will need to take the data identified for the JMRI labeled device, and translate that into something I can use to map inputs and outputs into my computer's railroad I/O RAM space. Is that right? The data are identified in JMRI by the JMRI IDs I'm creating when I generate tables for sensors, turnouts, blocks, and so on?
I'm planning to use EasyDCC for only train control, not for controlling turnouts or other devices. I'd rather control turnouts and other things from facia mounted control panels or tablets or smart phone type throttles. I've been using EasyDCC plug in throttles. I have six. EasyDCC wireless costs more than I want to spend. Using tablets or smart phones and JMRI instead, seems very attractive.
Using a C/MRI protocol would reduce the amount of programing I'd need to do. I haven't paid much attention to it, I'd started my computer control project before C/MRI was published. I considered using C/MRI, but didn't because I thought its hardware was inefficient, with separate power and? boards for each block. My hardware has (less) power control and occupancy detection for for blocks on each track board.I'm also multiplexing switch and detector inputs and LED driving outputs, not using static boards with separate hardware for each device. But, that doesn't mean the protocol won't work to transfer my data to and from JMRI and save me some work!
Don Weigt
|
On Jan 1, 2019, at 10:30 PM, Don Weigt <dweigt47@...> wrote:
The little light bulb is beginning to turn on dimly! My script running in JMRI will need to take the data identified for the JMRI labeled device, and translate that into something I can use to map inputs and outputs into my computer's railroad I/O RAM space. Is that right? The data are identified in JMRI by the JMRI IDs I'm creating when I generate tables for sensors, turnouts, blocks, and so on? Right! I'm planning to use EasyDCC for only train control, not for controlling turnouts or other devices. I'd rather control turnouts and other things from facia mounted control panels or tablets or smart phone type throttles. I've been using EasyDCC plug in throttles. I have six. EasyDCC wireless costs more than I want to spend. Using tablets or smart phones and JMRI instead, seems very attractive.
Using a C/MRI protocol would reduce the amount of programing I'd need to do. I haven't paid much attention to it, I'd started my computer control project before C/MRI was published. I considered using C/MRI, but didn't because I thought its hardware was inefficient, with separate power and boards for each block. My hardware has (less) power control and occupancy detection for for blocks on each track board.I'm also multiplexing switch and detector inputs and LED driving outputs, not using static boards with separate hardware for each device. But, that doesn't mean the protocol won't work to transfer my data to and from JMRI and save me some work! Using JMRI for throttles makes it a bit more complicated. You want three things: Throttle control, turnout control, and sensor readback. Unfortunately, neither EasyDCC (no sensor support) nor C/MRI (no throttle support) can do all three. Maybe two serial links to your PC? Bob -- Bob Jacobsen rgj1927@...
|
Thanks, Bob. I'm a little closer to understanding. All of your reply was clear, until the final question about two serial links to the PC. Does C/MRI always and only use a serial link to the computer? Or, where else were you envisioning it? I didn't expect to duplicate C/MRI interface hardware, only mimic enough to use the same message structures.
It seems I should research C/MRI before asking anyone on this list to answer questions about connecting JMRI to it with my hardware.
Don Weigt
|
A serial link, with JMRI thinking its talking to a C/MRI system and your hardware-control PC emulating a C/MRI system, will work for Turnouts and Sensor. But it won¡¯t work for throttle control from JMRI. C/MRI, hence the C/MRI protocol, doesn¡¯t know how to do that. So you can either use a 2nd serial link from JMRI to the EasyDCC system directly, bypassing your PC, or you can use a 2nd serial link from JMRI to your PC that¡¯s carrying the EasyDCC protocol. Bob On Jan 2, 2019, at 1:31 PM, Don Weigt <dweigt47@...> wrote:
Thanks, Bob. I'm a little closer to understanding. All of your reply was clear, until the final question about two serial links to the PC. Does C/MRI always and only use a serial link to the computer? Or, where else were you envisioning it? I didn't expect to duplicate C/MRI interface hardware, only mimic enough to use the same message structures.
It seems I should research C/MRI before asking anyone on this list to answer questions about connecting JMRI to it with my hardware.
Don Weigt
-- Bob Jacobsen rgj1927@...
|
Bob Jacobsen