Are you a JMRI user ?

[Andy Reichert]

I am on several yahoo elists, most for 10 years or more, and haven't yet come across the "neo" interface so many seem concerned about. But then I don't expect any more features than a list of shared emails, which I can save if I choose.

 

OTOH, I did find it necessary to join a facebook group, which I find very crude to use and has no useful features I can ascertain.  It acts like a daily single page tabloid, with no sense or memory of what happened more than one issue back.

[ThePurplePrimer]

Thanks for the information Nigel

 

It does sound a bit like my chosen DCC system is going to make this a little bit harder that it could have been.

 

Could you offer any suggestions as to how I could get information from any sensors into JMRI then as I am certainly going to want some detection at some point. I am also interested in the idea of block detection.

[Phil S]

It might be worth waiting until Hornby have released their new detector system - outlined in the 2014 catalogue.

Detection basically falls into 3 groups:  Magnetic, Optical or Electrical: [ To this should be added RFid - with its identifying ability too - now cheaper than ever ]

Magnetic:  Magnets on rolling stock (usually locos)  operate reed-relays or Hall-Effect switches in the track.

Optical: Infra Red or Visible light - Beam break or reflection

Electrical: Redividing your 'now unified' dcc railway into separate electrical sections - designed to monitor train position and therefore NOT NECESSARILLY in the same locations or numbers that ananlogue-cab sections may have been previously.

RFid tags - supported by several software programs - provides identification as well as detection at each reader position.

Other 'combined' systems - reading bar codes or similar - also offer identification as well as simply detection of 'a train'.

 

THESE THEN have to be 'channelled' back into the 'Feedback Bus'  Modules of your chosen type: Eg Lenz, Roco, MergRFid, MergCBUS, HS88...... and the network-based types ....  These modules may not be inexpensive - but note - they can be totally spearate from whatever system is used to CONTROL the track .... although Railcom® actually uses the track/dcc as its return path.

 

Railcom feedback information might come from on board dcc-fitted locos or from lineside accessory boxes (point decoders/ digital point motors etc)

 

Cost increases proportionally with the size or complexity of the model railway.  No Feedback = 'no cost' : s/w offers a glass screen with track display to operate points/signals - without position/train detection ......>> ..... all trains tracked and automated time table running possible with automatic operation of signalling and lineside asccessories including station announcements.

Edited October 14, 2014 by Phil S

[boc]

I have lost my reply three times tonight, so coupled with my love-hate relationship with BBC's The Apprentice I am becoming quite grumpy!

Are you familiar with arduinos? Rather than retype everything in overview and detail, I'll keep it brief and elaborate if this is an avenue you wanted to go down. I planned to write up my experiences for the forum at a later stage.

I am using an arduino to read the state of sensors and feed this into JMRI. I'm also using it to respond to commands from JMRI too, in lieu of a DCC accessory decoder - controlling a point and some lights. A CMRI library exists which outlines how the arduino needs to communicate with JMRI. The only programming required is to define what 'sensors' are connected and how to respond to a state change eg if button 1 is on tell JMRI that CMRI address 1 is on. You could, if you so wished, program more complicated conditions eg if button 1 is pressed tell JMRI that address 1 is on, then wait 5 secs and tell JMR that address 1 is off. I believe you could achieve something similar by scripting or using conditions within JMRI too.

Although I already owned it, the arduino cost around £10. which isn't bad considering I could connect 10-13 sensor inputs as a trial. Arduinos or equivalent microprocessors can be bought/built for much less or there are alternative means of expanding the numbers of inputs, so the cost per input (not including sensor itself) could be reduced significantly.

I'm unable to include links or copy and paste, as this keeps crashing my messages,  but googling 'utrania CMRI', 'ArduinoCMRI' and the posts on this forum about the arduino servo point control (for details on arduinos rather than JMRI) maybe of interest.

Chris

[boc]

Just to clarify - I've only used the sensor inputs with my setup with the JMRI scripts  to get rudimentary automation

 

go forwards at 10% speed until left hand sensor is triggered.

wait for 5 seconds

go backwards at 10% speed until right hand sensor is triggered.

wait for 5 seconds.

repeat.

 

I'd like to try block detection too and plan to use some optical sensors. I'm in no rush so I'm waiting to order some from China at 25% of what I'd pay in the UK when I next order some other components. If I get the time I may continue to experiment using buttons instead to at least simulate the optical sensors and carry on learning how to use JMRI.

[Crosland]

As well as Phil's three/four technology based groups you should also consider the operational differences that mean different systems can tell you;

- who is at a particular point (RFID, LISSY)

- who is on a particular section (railcom, transponding?)

- someone is at a particular point (magnetic, optical)

- someone is in a section (block detectors)

 

RFID is a little different as it can detect across multiple tracks at the same time giving a "who" is nearby. This can be a advantage or disadvantage.

 

Software can (potentially at least) track the trains using simple "someone" single point detectors around the layout once the layout is calibrated so you only need to detect "who" at particular pinch points (or enter the information manually), so long as the hand of god does not intervene.

 

Andrew

[ThePurplePrimer]

Phew

 

It looks like I have a lot of research to do but thanks for the replies - it all sounds very interesting.

 

I thought that JMRi was the obvious choice ( actually its the only choice I know about )

 

Should I be looking at ( for ) any alternatives ?

Edited October 15, 2014 by ThePurplePrimer

[Nigelcliffe]

Thanks for the information Nigel

 

It does sound a bit like my chosen DCC system is going to make this a little bit harder that it could have been.

 

Could you offer any suggestions as to how I could get information from any sensors into JMRI then as I am certainly going to want some detection at some point. I am also interested in the idea of block detection.

 

[......]

 

It looks like I have a lot of research to do but thanks for the replies - it all sounds very interesting.

 

I thought that JMRi was the obvious choice ( actually its the only choice I know about )

 

Should I be looking at ( for ) any alternatives ?

Picking up on several questions from a couple of postings

 

Gaugemaster/MRC,  probably not the best choice for automated running, but suggest you are cautious about throwing out and getting something else.   The main constraint is that for Gaugemaster/MRC the only software option is JMRI.    With other hardware there is a much wider range of options. 

 

Automated running comes in various forms; an entire layout running to a timetable, with trains going across each other without collision, is one extreme.   But what you described (run onto a turntable, select road, run off and park,  then repeat) is much simpler.     For the former, the common software choice is TrainController.  But for the turntable idea, JMRI will do it fine, and in some cases, it could be done with just hardware and an appropriate DCC system. 

 

Detection,  people like Phil and Andrew have outlined the types of detector.  What is also required is a means to get the information into the computer.  This will need some more hardware.  From where you are starting, I think there are three main options for hardware to report detection back to the computer:  LocoNet, MERG's CBUS, and S88.  

• The CBUS option means joining MERG and building your own electronic devices from kits, and to an extent you need to engage in the hobby electronics arena (ie. being interested in how it works, rather than just that it does work).   Supported in JMRI, RocRail.  But, not supported in TrainController.  
• LocoNet is Digitrax' network, well established, with a number of third-party makers (both ready to use and in kit form), so it is possible to buy things "off the shelf" to do the detection you require;  if you run a LocoNet and wish to keep the Gaugemaster system for control, then you are setting up a "stand alone LocoNet" (search on that term) - the difference is that "throttle" devices don't work on it.  LocoNet is very well supported in JMRI, RocRail, TrainController, and numerous other software products.
• I know least about S88,  its a bus system used by ESU and some other European makers.  There are devices for it from third-party makers.  And support in some software packages.   Beyond that, suggest searching !

 

Identification is another matter,  Andrew discussed it above (main systems are RailCom, RFID,  secondary options include Lissy, Transponding).  If you know the starting point on a layout (ie. where the trains are to begin with), then identification isn't needed,  the software would be able to track movement by "detection".   Identification can be useful, and can simplify things, but you'll need more hardware, and it tends to be moderately expensive. 

 

 

If you're going to Warley, make your way to the large Computer Control of Layouts demonstration stand where there will be lectures, demonstrations and people to discuss things with.  I'll be there, as will others with a connection with David Townend's "McKinley Railway".     It is also worth searching YouTube for the four videos about the McKinley railway, it introduces a lot of concepts which are needed for automation, but you don't need to use the same hardware or software as David selected. 

 

 

 

- Nigel

[Deev]

I've been doing some notice JMRI position detection and have written a simple script.  There seems to be a significant delay (3000ms+) between the input coming from the Arduino to the loco responding (via XpressNet.

 

Does anyone experience the same issue and is there any way of fixing it?

[RAF96]

Rocrail is also open-source, fully featured, and is free to download, supports almost every bit of hardware ever or likely to be made and has a very knowledgeable and helpful proper forum.

... even I can understand and use it at basic level to set up a trackplan, establish loco and rolling stock databases and setup turnout switching using 2 separate controllers.

JMRI I am sorry to say defeated me at the trackplan stage, although Decoder-Pro is a handy bit of kit.

[Nigelcliffe]

I've been doing some notice JMRI position detection and have written a simple script.  There seems to be a significant delay (3000ms+) between the input coming from the Arduino to the loco responding (via XpressNet.

 

Does anyone experience the same issue and is there any way of fixing it?

Sounds like your hardware. I don't experience any measurable delays unless I've deliberately set a delay in software somewhere.

 

 

- Nigel

[Deev]

Sounds like your hardware. I don't experience any measurable delays unless I've deliberately set a delay in software somewhere.

 

 

- Nigel

Interesting - what DCC hardware do you use?  I use a Lenz Set 100 with LI-USB.

[Deev]

Rocrail is also open-source, fully featured, and is free to download, supports almost every bit of hardware ever or likely to be made and has a very knowledgeable and helpful proper forum.

... even I can understand and use it at basic level to set up a trackplan, establish loco and rolling stock databases and setup turnout switching using 2 separate controllers.

JMRI I am sorry to say defeated me at the trackplan stage, although Decoder-Pro is a handy bit of kit.

 

I'm impressed by RocRail as well, I'm persevering with JMRI as it allows me to interface directly to devices via a RS485 us, which isn't something I've found that RocRail can do.

 

Dave 

[Nigelcliffe]

Interesting - what DCC hardware do you use?  I use a Lenz Set 100 with LI-USB.

Mostly LocoNet based hardware, some home made, others various makers.

 

If you want technical assistance with JMRI, head over to Yahoo and the "jmriusers" group. If you provide the details (hardware used, possibly a copy of the data in the system console) someone with relevant experience is likely to help.

 

Large delays between data received and command sent shouldn't be happening inside the computer, so the question is where the delay is happening.

 

- Nigel

[Deev]

Indeed, I can't work it out.  It seems that the sensor signal needs to be high for over 1500ms for anything to be registered.

 

You can see on this video that JMRI receives the command when the LED is illuminated, but it takes a while to send a command to stop the loco.
 
https://www.youtube.com/watch?v=25814O0xUBE

 

Somethings not right so I'll check the JMRI user group - thanks for the tip.

 

Dave

[Deev]

Solved it!

 

The problem lay with the Arduino code.  I reprogrammed it to call an interrupt when the Hall Effect Sensor went high, and hey presto, it worked!

[Simond]

Hi

 

Please excuse me if not the right place to post this.

 

I have a Lenz USB/LAN interface connected to Xpressnet. It works with the Lenz software on the Dell E4200 laptop running W7Ulitmate 64 bit & connected via COM5. After a fight with my BTHomeHub yesterday, it also works with TouchCab Free, giving me control of locos. So the hardware is ok, the wiring is ok, and the firmware is ok.

 

I am struggling to get the JMRI Decoder Pro to talk to it. Actually, I'm failing...

 

I have stopped both the Lenz kit and laptop, restarted the Lenz equipment & then the laptop. I have flow control set to "no", and the baud set to 57600, 8 data bits & no parity. I'm assuming this is ok, as the Lenz s/w talks to the interface with these settings.

 

The truly irritating issue is that before I dismantled the old layout, it worked, and it doesn't now.

 

Help!

 

Thanks

Simon

[Nigelcliffe]

Hi

 

Please excuse me if not the right place to post this.

 

I have a Lenz USB/LAN interface connected to Xpressnet. It works with the Lenz software on the Dell E4200 laptop running W7Ulitmate 64 bit & connected via COM5. After a fight with my BTHomeHub yesterday, it also works with TouchCab Free, giving me control of locos. So the hardware is ok, the wiring is ok, and the firmware is ok.

 

I am struggling to get the JMRI Decoder Pro to talk to it. Actually, I'm failing...

 

I have stopped both the Lenz kit and laptop, restarted the Lenz equipment & then the laptop. I have flow control set to "no", and the baud set to 57600, 8 data bits & no parity. I'm assuming this is ok, as the Lenz s/w talks to the interface with these settings.

 

The truly irritating issue is that before I dismantled the old layout, it worked, and it doesn't now.

 

Help!

 

Thanks

Simon

 

An old known issue was that the Lenz supplied software used to keep some parts running (started automatically) so this could prevent other software from gaining control of the Lenz interface.   I don't know if that's still the case.

 

Some recent JMRI releases have been messing up preferences for some users.  On the "defaults" tab of the "preferences" window/dialogue, and check that all relevant buttons are attributed to your Lenz setup and not something else. 

 

Otherwise, if you get no specific advice here, its off to Yahoo and the "jmriusers" group.  Post the issue there, probably with a copy of the system console (a window within JMRI) which will almost certainly give an expert Lenz user the clues to debug for you.

 

 

 

- Nigel  (no Lenz kit).

[Simond]

Nigel

 

Thanks for taking the time to reply. I knew about the "old" issue, hence the restart. I have done the preferences until blue in the head!

 

Ironically, now the damn Lenz s/w won't connect via USB, though it will via the LAN...

 

I'll hope for some responses on here, as I really don't want to go down the Yahoo route unless necessary

 

Fingers crossed!

Simon

[w124bob]

Regardless of what dcc system you use the most common cause of run aways(in my experience) when using wifi,is loss of the wifi link or a dying battery in a throttle. I and a friend both use the Engine Driver app, I installed the free version but I assume the paid for version is required for route setting. Make sure Java is upto date as I experienced an issue which was traced back to missed update. I run mine via dedicated 2nd hand ex schools laptop(windows7) and an old Ipod touch, my DCC system is a MERG one, total outlay less than £250 all in. As for Yahoo, well haven't been near any of my groups since the up(ruin)dated the whole thing afew years back.

Edited July 7, 2017 by w124bob