Locked
Re: Easiest turnout reporting?
On 7 Dec 2018, at 9:46 AM, Micheal < mfarley@...> wrote: I have pushbuttons that are run through the NCE Mini-Panel. No direct pushbutton to the Switch-8¡¯s, as mine are all 1st Generation.
Good way to go. A lot less wiring that way. I did select monitoring mode, and that seemed easy enough and accomplished what I wanted.
Glad to hear the easy solution is suitable for your setup.
Dave in Australia
|
Locked
Re: Easiest turnout reporting?
I have pushbuttons that are run through the NCE Mini-Panel. No direct pushbutton to the Switch-8¡¯s, as mine are all 1st Generation. ? I did select monitoring mode, and that seemed easy enough and accomplished what I wanted. Thank you everyone. ? Micheal
|
Locked
Re: MQTT Connection in JMRI
Bob,
I would be interested in helping. MQTT protocol is very light and powerful. It also allows multiple programming languages to get data or pass data to each other.?
To to get a little of educated on MQTT. You can check this out -?
JMRI currently offers MQTT connection and it makes the root topic /trains/ ?and wants a connection to MQTT broker (server) which passes the data to all the connections that subscribe to a topic. I think JMRI should allow to change the ¡°root¡± topic, because it currently does not.?
You asked about how will JMRI know the system name or username. I invasion that the topic for a turnout will be something of the following. I use the root topic of trains for example.
trains/turnouts/username/?
MQTT uses payloads, which can be user friendly, so for a turnout it would be thru or thrown.
if a sensor:
trains/sensors/username/
Payload: Active or Unactive
This could be done for block detectors, signals, lights, etc.
I also think it is a good idea to have the fast clock info published to MQTT.
Also, would like to see the ability for people to expand on MQTT in JMRI with scripts for addition ¡°play¡± value like jynstruments.
Chris
|
Locked
Re: Easiest turnout reporting?
That's all you need for JMRI's Monitoring mode.
The monitoring mode is quite adequate if you don't have local pushbuttons on the Switch-8s.
The monitoring mode is also quite adequate if you use local pushbuttons connected via an NCE Mini Panel rather than the Switch-8. The command station (and hence JMRI) knows what throttles and Mini Panels do as far as changing turnouts.
Do you use local pushbuttons connected to the Switch-8?
--
Dave in Australia
toggle quoted message
Show quoted text
On 7 Dec 2018, at 8:25 AM, Micheal <mfarley@...> wrote:
Currently only the NCE/JMRI interface as provided by the serial cable...
|
Locked
Re: Mac and PC moving data
The short answer is that the files you need to move are found at the User Files Location (from the Help->Locations menu item).
For information on what files do what and what needs to move look at:
<>
<>
<>
The Dropbox page is a worked example with illustrations and is very helpful even if you intend a one-time transfer rather than ongoing sharing. (Many JMRI users and developers take advantage of ongoing sharing using Dropbox.)
--
Dave in Australia
toggle quoted message
Show quoted text
On 7 Dec 2018, at 4:02 AM, dan@... wrote:
I started to look at JMRI n my laptop that will probably be used to run the system on the train set. Then I moved to my 27" IMac because it is easier to see...hehe. So I have my track and switches all set up on the Mac. How can i move all this work from my iMac to my PC laptop? And what files need moved?
Thanks new to the hobby and got a couple of carts before the horse issues because I don't have anyone in the are that I know to go to for help so bare with me please.
|
Locked
Re: Easiest turnout reporting?
Michael:
Okay then we have single vendor the NCE AIU as Dave suggested and some means of detecting (confirming) the switch position.
Another choice is a second vendor or DIY to build some device or other... Into DIY electronics? JMRI can support that too.
Jim Albanowski
|
Locked
Re: Easiest turnout reporting?
Currently only the NCE/JMRI interface as provided by the serial cable...
|
Locked
Re: MQTT Connection in JMRI
Speed Muller has done a lot of work with MQTT including signals and sensors. He is keen to work with you the JMRI side.
-Dave Mc.
|
Locked
Re: Easiest turnout reporting?
Michael:
What I/O do you have to read sensors on the RR? There are many way to read switch position including what I thing would be a way to read the polarity of the motor drive power...
If all the Tort contacts in use I attach a micro switch or two to the Tort case to be activated by the swing arm.
Prototype... throw bar attached to points to an independent switch not using the motor for a higher level of fail safe.
Jim Albanowski
|
I started to look at JMRI n my laptop that will probably be used to run the system on the train set. ?Then I moved to my 27" IMac because it is easier to see...hehe. ?So I have my track and switches all set up on the Mac. ?How can i move all this work from my iMac to my PC laptop? ?And what files need moved?
Thanks new to the hobby and got a couple of carts before the horse issues because I don't have anyone in the are that I know to go to for help so bare with me please.
Dan
|
Locked
Re: Easiest turnout reporting?
Two ways with the NCE Power Pro:
1) As another (unnamed) user has said, enable "Monitoring" feedback mode in the Turnout Table. The Power Pro command station has a 2048 bit non-volatile memory block that stores the last-commanded state of every accessory address. This will follow changes commanded by JMRI computer interface or any NCE device (throttle/Mini Panel/etc.). It will not follow changes made by Switch-8 local pushbuttons or if the turnout fails to move. It is not affected by powering the system down (unless the command station memory battery is flat).
2) Use an NCE AIU (a cab bus device) to monitor the Tortoise by connecting to a spare auxiliary contact set on the Tortoise. Each AIU has 14 inputs and can monitor 14 turnouts. This will show actual Tortoise state but requires a lot more wiring, uses one of the two contact sets on each Tortoise and costs extra.
Note that the Switch-8 is a DCC track bus device (connects to command station and booster output), not a cab bus device (cab bus devices connect to command station input). The AIU provides the missing link back to the cab bus.
--
Dave in Australia
toggle quoted message
Show quoted text
On 7 Dec 2018, at 4:57 AM, Micheal <mfarley@...> wrote:
Windows 10, JMRI, NCE PowerPro, Tortiose machines, NCE Switch-8 control...
What is the easiest way to report turnout position back to JMRI? I already us my auxiliary contacts for other things. Is there a simple device that would read the Toetoise #1 and #8 polarity and use that to report position back? Too bad the Switch-8 can¡¯t report this directly through the cab bus. That¡¯d be too easy I guess.
|
Locked
Re: Easiest turnout reporting?
set the turnout feedback mode to "monitoring"
|
Locked
Re: Panel Block Occupancy
Yes - thanks - it has been a while since I set the panel but I do seem to remember now something about internal sensors. I presume that would still enable loco name to be stored with the occupied block - and recalled if jmri is closed and restarted ?
|
Locked
Easiest turnout reporting?
Windows 10, JMRI, NCE PowerPro, Tortiose machines, NCE Switch-8 control...
What is the easiest way to report turnout position back to JMRI? I already us my auxiliary contacts for other things. Is there a simple device that would read the Toetoise #1 and #8 polarity and use that to report position back? Too bad the Switch-8 can¡¯t report this directly through the cab bus. That¡¯d be too easy I guess.
Micheal
|
Locked
Re: Panel Block Occupancy
Perhaps you could associate that siding block with an internal sensor (taking the place of a hardware detector¡¯s sensor) that your scripts could set active/inactive as they follow the train.
Bob
toggle quoted message
Show quoted text
On Dec 6, 2018, at 8:55 AM, David Smith via Groups.Io <daversmth@...> wrote:
I use a PanelPro panel to display block occupancy, with the name of the loco occupying the block added.
Each block has a hardware sensor and that all works fine.
My layout is operated using my own Jython script to dispatch and route the trains.
For sidings, I am considering not having an occupancy detector in the siding, but using the fact that the script knows where it has routed the train to ( ie which siding ) . so when the previous block sensor goes inactive, I know that the train has then entered the siding. So I can detect its presence in the siding by inference, without the need for a block occupancy hardware detector. But if I do this, is there anyway to show the block as occupied, with the loco name, in the panel. The main application is for a turntable where I do not want to add a hardware detector on each radial track, but just have one for the turntable track.
|
Hi All,
I use a PanelPro panel to display block occupancy, with the name of the loco occupying the block added.
Each block has a hardware sensor and that all works fine.
My layout is operated using my own Jython script to dispatch and route the trains.
For sidings, I am considering not having an occupancy detector in the siding, but using the fact that the script knows where it has routed the train to? ( ie which siding ) . so when the previous block sensor goes inactive, I know that the train has then entered the siding. So I can detect its presence in the siding by inference, without the need for a block occupancy hardware detector. But if I do this, is there anyway to show the block as occupied, with the loco name, in the panel. The main application is for a turntable where I do not want to add a hardware detector on each radial track, but just have one for the turntable track.
|
Locked
Re: Blocks next to Crossovers are inaccessible as transit destinations
Jack,
Was there a specific reason for changing from automatic SML to manual SML? Since you had created sections from the SML, changing the SML resulted in errors during JMRI startup for the sections since they were based on the automatic SML.
I would not include six of the signal masts since they don¡¯t appear to provide any value. They are 15 East, 8 East, 2 West, 4 East, 10 West and 17 West. 2 West and 4 East would be OK if the Block 3 is long enough to hold a complete train.
As a rookie with using Dispatcher, I don¡¯t use SML based sections. I create a section for each block. This provides me with maximum flexibility in creating transits.
Based on the above, I had no problems creating a transit from 20 to 24 and running a train using simulated block occupancy.
Dave
toggle quoted message
Show quoted text
On Dec 5, 2018, at 7:12 PM, Jack Basiago <jbasiago@...> wrote:
JMRI version: 4.13.4
Java version: 1.8.0_191
MacOS: Version 10.13
I've been working on a layout that includes 6 crossovers, 3 left hand and 3 right hand. I've uploaded my layout to Full Yard with Signals. I've been able to create and place signal masts at end blocks, and turnouts on the layout. I've used the auto-generate signal pairs tool to create signal mast logic, which I ultimately had to convert to not use Layout Paths. I also created Sections from the Signal Mast pairs. The signal mast logic looks good to me. I have created auto trains that traverse the layout and return successfully.
However, when creating transits for automatic trains, I ran into one issue that I can't figure out. Because the crossovers only allow you to assign signal masts that face outside looking in, I can't create a transit that includes the block next to a crossover as a destination. For instance, if I create a transit to go from the end of 20 to the end of 24, the last block at 24 is inaccessible because there is no signal mast for 24 East, only 23 West at the open end of block 24. I could create the signal mast, but I have nowhere to attach it because the crossover prevents the mast from being assigned to position C. Only 23 West can be assigned to C of that crossover. As a result, the last block for the transit would then be 23. How do I create a section / transit that allows me to park a train in a block after the crossover; block 24?
Of course, I could create another block beyond 24, but that would require an additional block detection circuit for each end track in the layout.
What am I missing?
Thanks,
Jack Basiago
|
Locked
Re: Blocks next to Crossovers are inaccessible as transit destinations
Have you set Buffer Stops at the end and added Buffer Stop masts?
|
Locked
Re: MQTT Connection in JMRI
Note: I didn¡¯t write the MQTT code in JMRI, so might not know what I¡¯m talking about there.
I think it would be good to add JMRI Sensor code to go alongside the JMRI Turnout code. Some parts of it seem to be there, but large parts are missing. In particular, there¡¯s nothing about mapping MQTT traffic to particular sensors: How to figure out names, states, etc.
Is there somebody with MQTT knowledge interested in working with me on that? I can do the JMRI part, but don¡¯t know enough about how people would want it to work.
Bob
toggle quoted message
Show quoted text
On Dec 5, 2018, at 5:53 AM, Nathan Tableman <nathan@...> wrote:
Now what I really need is for mqtt to be supported for sensors/block detection. Anyone got this to work using python, seems like some people have come close when I hunt around. My goal is to use all these adafruit feathers I have sitting around to send mqtt messages about block detection with a goal being a track powered wireless block detection system. Look, mom, no wires!
|
A timely warning, which Marcus does mention at:
<>
Removal of the posts for testing needs to be done with command station cover removed to ensure no loose hardware and the posts must be replaced after testing/modification in order to avoid stress failure of solder connections etc. on the top board. Leaving them off permanently is not a viable option.
--
Dave in Australia
toggle quoted message
Show quoted text
On 6 Dec 2018, at 11:42 PM, Ken Cameron <kcameron@...> wrote:
A caution about removing the mounting studs is to not leave loose hardware
inside the command station box. If you do decide to remove the external
parts, remove the internal too.
|
Bob Jacobsen