Dear All, but in a difficult spot and I appreciate your advise.
I have decided to separate the train operation (currently Lenz LH100 set) from the operation of turnouts/signalling/feedback etc. where I expect to use JMRI for control logics (I think). In order to do so I have a few options I understand, but here it gets a bit difficult.
Option one would be to use an easily obtainable secondary DCC system, without controls etc, but the assessory decoders and such linked to a computer connection (would a PR3XTRA USB Programmer do?) Advantage would be a large quantity of aftermarket kit to achieve maximum functionality.
Second option as I see it would be the use of an Arduino based system. This would allow for a lot of functionality at low cost, but the learning curve is rather steep for a new starter. I note that more and more sketches become available, but it'll still require quite some familiarity to tie it all together.
Third would be the LCC/OpenLCB set-up, which seems very promising, but regretfully not a lot of equipment available and at a rather high entry cost it seems. Basic 'starter set' of one manufacturer is about 180 USD (power point/connection point/assessory point with connecting bits). From the onset the possibilities look great, but the slow take-off doesn't give me a good feeling it is the final step.
I'm slowly building away at a fairly simple lay-out (my first and no doubt not my last...), but it's about time to start putting the signals in and start thinking of appropriately wiring them, which brings me to a decission on the equipment to be used.
If you have been at the same crossroards and made a decission I'd appreciate your information and reasoning, or anyone else that can carify the choises better.
Thanks, Rene
ReneZSecond option as I see it would be the use of an Arduino based system. This would allow for a lot of functionality at low cost, but the learning curve is rather steep for a new starter.
DCC has a well defined and narrow purpose: locomotive control. Decoders offer lots of features for this purpose. DCC has also been extended to control turnouts, which is on/off.
LCC is promising to control lots of things (e.g. signalling, turnouts control and position sensing, occupancy detection, ...). Lots of communication detail, but how does everyone expect it to work (different types of signalling, human interfaces, automation, ...).
A USB to 485 bus interface is cheap ($2). But what does the PC do (e.g. graphics) and what do arduinos/pics do on the layout?
are you willing to learn and develop your own sytem or do you want to buy off-the-shelf components?
the capability required for a small layout is simple and a learning opportunity for more complex larger layouts. Large layouts have customized systems. JMRI isn't for everyone.
greg - Philadelphia & Reading / Reading
Yeah and you guys are now doing more with Arduino than I am - I have some ambitious projects and have done working prototypes but nothing final yet, as I keep experimenting and designing. Of course I doon;t have a layout at the moment to use it on anyway...
I am doing my own Arduino bsed system using a simplified CMRI protocol (the nodes will be all pretty much identical and/or since I am writing the host application myself, I will know how many inputs and outputs a given node will have so there is no need for the Initialize messages, for example). This sort of thing is definitely for the faint of heart.
A alternate system is a good idea, since the Lenz bus is not designed to support signals and detection. One option used by many is setting up a standalone Digitrax Loconet. No command station is needed, a PR3 or Locobuffer-USB is all you need to start. Detection and signalling components are available from a variety of sources, including but not limited to Digitrax. RR-CirKits makes a number of interesting interface devices and also has a variation on Loconet that only uses 3 wires instead of 6. Advantage of a commercial system is you can use already available software like JMRI or RR&Co to control it.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Dear Mel, Greg and Randy, appreciate your comments!
i feel that I'm thinking in the right direction and looking at options I found the rr-cirkits site. That's where I noticed the price of admission to LCC and that parts with (assumed?!) similar functionality does come at a substantially lower price for a digi version than for a LCC function.
Arduino is not too big a hurdle, it'll just require the initial time to get up to speed. Having a rather busy job in shipping that comes at a premium . But we all have to make sacrifices for this hobby I guess...
Arduino would allow the use of cheaper servo's for turnout control.
need to read up a bit more I guess.
thanks all! Brgds, René
There are off the shelf (and even Loconet-compatible) controllers for servos, you don't HAVE to roll your own for servo turnout motors. This will be my second layout with servos, it's hard to not to, since they are so inexpensive. Tam Valley has many different ones, the Quad-LN is Loconet, the others use buttons and could be fed by the output of some of the other RR-CirKits devices.
It is interesting how the same device for LCC is more than the device for Loconet - especially considering that to commercially sell a Loconet device you have to get it certified by Digitrax and pay a (small) royalty since Loconet is not open-source. All in the demand and design - plus I suspect the actual interface components cost more - Loconet uses a basic bipolar transistor and a cheap as chips comparator IC for the interface.
Hello,
As far I'm concerned and beleive me I'm not an electrolician and certainly not a programmer but for sure if you want a versatile system which you could adapt at your demands and upgrade at any moments and the most important anyway cheap and affordable, use arduino"s and JMRI programming.
The possibilities are endless and the system is open for everybody.
You can drive motors,servos, step by step motors, make any animation which need a lot of simultaneous action and this is just a very few examples.
Sharing information is aviable on all trains forum from Europe to US and upcoming infos is published every day on the subject.
By example you could drive 7 servo/ turnout with one arduino mini for something under 12$ you can't find such thing on the train market.....here is the best answer!
If interested in Arduino and CMRI without learning ALL the details about Arduinos, there's always cpNode:
http://www.modelrailroadcontrolsystems.com/cpnode/
All you need to know hoow to do Arduino-wise is load a sketch the provide, and modify a couple of lines to set the address of each board. JMRI can provide the control and logic so no need to write your own software (applies to any CMRI hardware - JMRI fully supports the CMRI protocol along with all the DCC ones).
Thanks team! Indeed, with the potential cost savings in arduino it's worth the try. If I fail or lose steam I can always do one of the other options. Arduino here I come
Thanks, René
gregcLCC is promising to control lots of things (e.g. signalling, turnouts control and position sensing, occupancy detection, ...). Lots of communication detail, but how does everyone expect it to work (different types of signalling, human interfaces, automation, ...).
LCC products currently available use the same communication protocol as your car, a Controller Area Network. https://en.wikipedia.org/wiki/CAN_bus
Here are two videos of LCC working, demonstrating turnout control, signaling and grade crossing, and detection circuitry (this layout uses current sensing).
https://www.rr-cirkits.com/LCC/NMRA%20LCC%20Demo%20Layout.html
Each device learns which other device(s) it is to talk to, all other messages are ignored and pased on. You do the teaching. (extremely simplified explanation)
A video showing how this is all set up (3hrs) can be found here:
https://www.youtube.com/watch?v=00pYUJ7xqSo
That all being said, expense is a factor.
You might also look into Iowa Scaled Engineering.
http://www.iascaled.com/an-introduction-to-mrbus/
I believe their stuff is somewhat arduino based.
BMMECNYCLCC products currently available use the same communication protocol as your car, a Controller Area Network. https://en.wikipedia.org/wiki/CAN_bus Here are two videos of LCC working, demonstrating turnout control, signaling and grade crossing, and detection circuitry (this layout uses current sensing).
LCC doesn't decribe how to make all these devices work together.
Perhaps new companies like NCE or Digitrax will build LCC command stations with PC or touchscreen interfaces that will tie block detection, turnout control, interlocking, signalling, ... together using JMRI or similar to describe your layout and the rules for turnout/signal behavior (ABS, APB, CTC, ...).
imagine having touchscreen panels at different layout locations connected to the LCC command station via WIFI. No wiring and can easily be changed or relocated.
This is a blog where you can find many versatile answer about Arduino and JMRI software.
http://model-railroad-hobbyist.com/blog/geoff-bunza
You could also find already written Arduino programs for many purposes in this blog and upgrading about them
There is also many answers and tips about Arduino and JMRI use in this blog.
Most of the devices are schratchbuild electronics with the cheapest rates and easy to build.
Good luck.
Marc
gregcLCC doesn't decribe how to make all these devices work together
Im not sure what you are getting at. You connect the applicable components to the LCC node. You tell the node what that component is, and what other nodes cause the state of that component to change. Then you unplug JMRI and let it run (again, it is a little more indepth than that). You can use a push button, or a touch screen (in fact I think those are the only two human interface options besides a mouse and keyboard when a computer is needed).
http://www.rr-cirkits.com/Clinics/NMRA-2017-Signaling%20with%20LCC-A.pdf
http://www.rr-cirkits.com/Clinics/NMRA-2017-Signaling%20with%20LCC-B.pdf
Only the Signaling node is shown.
gregcimagine having touchscreen panels at different layout locations connected to the LCC command station via WIFI.
Check out page 36 of part B.. its a thing thats being worked on at the moment.
Not trying to say that LCC is cheaper than Arduino or anthing (actually there is a CAN shield for Arduino, so maybe an Arduino LCC node could be a thing, but you would need to be an NMRA member of a manufacturer to get an unique ID number for your node).
Edit:
More thinking, you could possibly use an Arduino as a daughter board for a Tower LCC node. The Arduino would turn 5v on/off connected to the pins on the node. You just tell it what each pin on/off signal means, then the node sends that to the whole network. You then add in a CAN-Wifi component (something homemade or possibly a upcoming product).
BMMECNYC gregc LCC doesn't describe how to make all these devices work together
gregc LCC doesn't describe how to make all these devices work together
Rene:
assuming you are confident in your ability to do some electronics assembly and to modify some Arduino code (it's really C), you have a lot of options. Most DCC accessories are easy to use but get expesnsive if you use a lot, so if we're only talking about a simple interlocking there are excellent controllers from the likes of Team Digital and Tam Valley (not an exclisive list) and some DIY items which do the job.
If you get beyond about 8 devices to be controlled, DCC based solutions start to get expensive on a "per device controlled" basis. Arduino based solutions, (full disclosure I'm Coordinator of the CMRI SIG) using CMRI as a "code line", or layout control bus, or other buses are very inexpensive on a per line basis as the Arduinos are comodities and can be purchased for around 10 or 15 cents per i/o line. Of course you need to add line drivers for the comm line, detectors, switch motor controllers etc, but for the most part you are just driving LEDs in signals, so the cost is very low. Check out the CMRI-USERS and ARDUINI yahoo groups for more information.
LCC has some very laudable goals, but manufacturer uptake has been very slow (really just Dick Bronson of RR-Cirkits, who is great) and there isn't a lot of volume driving innovation or competition keeping costs down. So if you go the LCC route you are likely to be a pioneer (the guy with arrows in his back <g>) and while there are a bunch of enthusiastic young people working on it, they are very technical and you'll need at least the skills you would to build something out of Arduinos just to communicate with folks doing the work.
If you just want ABS signaling and don't need full CTC, you might look at the Modular Signal System (MSS) which is a Fremo standard. It plugs together with CAT5 cables, no processors and does basic signals.
Hope this helps
Seth Neumann
www.modelrailroadcontrolsystems.com
gregci wonder how difficult it would be to develop a spec for describing a layout in terms of a trackplan, blocks and signals that could be used to determine the relationships between block occupancy, turnout position and signal aspects. And could such a description make less complicated the use LCC, C/MRI, ... nodes to control turnouts and signaling of a layout of any size. I would guess there would be optional details than can be specified if needed. Such a spec would allow different software to be used with the same decription file.
I think the issue there is the same one Neil B. talked about in his editorial this month. Each layout is kind of like a fingerprint electrically. I think the how will (and possibly should) be left up to the individual manufacturers (to an extent).
Im have been using JMRI and Robert Heller's Model Railroad System to configure my LCC setup. I went through the first few steps and got a node to do simple things with little more experience than basic CV programming. The longest part was actually wiring up the individual components (signals, detectors and the like, and figuring out the proper locations of said components).
The longest leg I have found with signaling is the actual learning how prototype signaling works, so that I can figure out which system best fits my railroad needs, then I can condense that into something useable on a model railroad.
BMMECNYCEach layout is kind of like a fingerprint electrically. I think the how will (and possibly should) be left up to the individual manufacturers (to an extent).
I think that most signaling falls into just a few very common patterns. A system can provide these common pattern as well as customizable methods for describing more complicated situations, if the don't already.
BMMECNYCThe longest leg I have found with signaling is the actual learning how prototype signaling works, so that I can figure out which system best fits my railroad needs, then I can condense that into something useable on a model railroad.
Did you see Bruce Chubb's 14 part article on signaling in RMC? Some of the articles were pretty long. In his book on how to operate a railroad the signaling chapter was only 15 pages.
gregc BMMECNYC Each layout is kind of like a fingerprint electrically. I think the how will (and possibly should) be left up to the individual manufacturers (to an extent). I think that most signaling falls into just a few very common patterns. A system can provide these common pattern as well as customizable methods for describing more complicated situations, if the don't already. BMMECNYC The longest leg I have found with signaling is the actual learning how prototype signaling works, so that I can figure out which system best fits my railroad needs, then I can condense that into something useable on a model railroad. Did you see Bruce Chubb's 14 part article on signaling in RMC? Some of the articles were pretty long. In his book on how to operate a railroad the signaling chapter was only 15 pages.
BMMECNYC Each layout is kind of like a fingerprint electrically. I think the how will (and possibly should) be left up to the individual manufacturers (to an extent).
BMMECNYC The longest leg I have found with signaling is the actual learning how prototype signaling works, so that I can figure out which system best fits my railroad needs, then I can condense that into something useable on a model railroad.
I saw the 14 part article. I kind of felt like every other one after the first 5 was a CMRI sales pitch/detailed how do to that with CMRI. Which, while interesting, was not 100% useful to me.
I started making a truth table for an Arduino based signaling system (something that need not be done with LCC), and found that if you wanted to write one sketch that you could load onto a bunch of unos, you needed to cover every possible condition, even incorrect hook up of inputs/outputs, so that you can throw error codes. Huge pain, and very time consuming. Personally I prefer configuring each individual situation separately.
BMMECNYCI started making a truth table for an Arduino based signaling system (something that need not be done with LCC), and found that if you wanted to write one sketch that you could load onto a bunch of unos, you needed to cover every possible condition
somethings need to be broken into steps, translating/selecting/combining inputs into a different form that easier to process by the next stage.
for example, first looking at turnout position(s) to determine the inputs for a particular signal and then applying the logic for those inputs to the signal may be simpler.
have you considered bulding a simulation on your laptop?
I'm not sure why your logic would have to catch every possible wiring fault, if this is just something you are doing for yourself. For a commercial product that anyone might try to hook up, sure. But if you set up a logic table of what conditions trigger what outputs, you can cross all the invalid ones off the list right away. Things like a turnout set both normal and reverse. Not possible, not going to happen. There's no need to test for such a condition. I don't see where LCC makes that any easier, the logic has to be somewhere in the system and just because a device interfaces via LCC doesn't make it immune to wiring faults, if you hook the red output for the signal to the yellow LED and vice-versa, you're going to get an incoorrect indication - regardless of the device or interface being used.
Still, trying to centralize it all in one piece of hardware is IMO silly. It's too easy to distribute smaller segments of the system these days. Same with a DCC system. A rack full of half a dozen boosters and power supplies with rows of volt and amp meters looks cool, but now you have one booster feeding track 2 feet from the power rack and another powering the track that's 40 feet away on the other side of the room. I'm sure there are fans of voltage drop, but why?
Thanks all, great discussion and lots of info.
Re Arduino use, yes, a logics table to prepare is normal for these type of arrangements and I'm certain once it is set-up its scalable easily if you follow the logic.
thanks all!
rrinker I'm not sure why your logic would have to catch every possible wiring fault, if this is just something you are doing for yourself. For a commercial product that anyone might try to hook up, sure. But if you set up a logic table of what conditions trigger what outputs, you can cross all the invalid ones off the list right away. Things like a turnout set both normal and reverse. Not possible, not going to happen. There's no need to test for such a condition. I don't see where LCC makes that any easier, the logic has to be somewhere in the system and just because a device interfaces via LCC doesn't make it immune to wiring faults, if you hook the red output for the signal to the yellow LED and vice-versa, you're going to get an incoorrect indication - regardless of the device or interface being used.
The truth table was for a modular club signaling project, where unos would be given to people pre-programmed, with the idea that if you had configuration A you attach gray wire to pin 1, etc. Config B gray wire goes to pin 3, etc. The idea being that with a key you could swap out a faulty board at a show with minimal effort because every case possible was already in place. We planned to keep half a dozen spares in case someone were to find a way to break one.
If you define invalid inputs, you can figure out what was hooked up incorrectly faster, and fix it.
Yes it was to be distributed, across about 100 arduino unos. The idea was to make it cheap as possible.
With LCC, each node contains its own logic, and knows which other nodes communicate with it, and which nodes to ignore and pass on the message. An turnout node need not listen to an occupancy detector on the other side of the railroad, likely only the occupancy detector that covers the same turnout (lockout of turnout when train is running over it) <this is a feature that every club layout should have.
gregcfor example, first looking at turnout position(s) to determine the inputs for a particular signal and then applying the logic for those inputs to the signal may be simpler.
I identified 8 unique cases (on our modular layout) that would change the inputs. I think what you are describing is what I was trying to do. Look at turnout position to determine which block detectors were of concern.
All of the cases of turnout/detection were graphically produced on a computer then printed out. I had not considered doing a simulation on the computer.
I guess I'm not seeing why the Arduinos couldn't do the same as the LCC modules. About the only thing you'd need to pass between modules would be block occupancy status, and as far as that goes, any given module only needs to see the occupancy of the track feeding it - doesn't matter if that's Joe's station module or Steve's cement plant module. If it's an end of the line module, pullups or pulldowns would mean the unconnected (because there are no more modules) line would always report occupied. If you need to pass back a turnout position - again that line would have a pullup or pulldown, so if attached to a module with just a block detector, one wire gets connected, if hooked to a module with a block detector and a turnout, both lines get connected. Since either turnout reversed or block occupied would cause the next module to restrict its signal aspect, those two could be simply ORed together and even if someone hooks the turnout to the block side and the block to the turnout side, or in the case of just a block detector, plugged it into the turnout input of the next one by mistake, it would still work. That probably covers 90% of the different arrangements. Since out club layout is sectional, and we use a Loconet based detection and signalling system, there are actually different JMRI panels created for different configurations. That's what you'd have to do with LCC as well. Putting all the logic in each individual controller, it could be pretty universal without a ridiculous number of cases to manage. Also more for things liek APB, for CTC you still need a connection back to the dispatcher console, so might as well use Loconet or CMRI or LCC and put the logic in the controlling computer.
Im not saying it cant be done.
The main creator of different cases is diverging route into signaled or not signaled track, and crossing of a signaled track. Thats three right there, add no diverging route (4), and trailing point versions of different divering routes.
You then need to look at occupancy status on the opposite line (assuming single direction of travel, RH running). We discovered 8 unique signaling cases. This created 11 columns on the truth table (track configuration plus occupancy). Likely this could be paired down somewhat because a trailing point is a trailing point no matter what the track connected to it is doing.
This resulted each column needs every possible combination that could be seen, and IMO the correct way to do this is to create a line for each posible combination of 1 and 0 in each column, resulting in over a couple of hundred lines of code. If you go the other way, only putting in the actual cases, you might end up with an undefined configuration if you forget something. We are just doing ABS for the the moment, treating each main line as a single track in each direction. I was hoping for more (APB or CTC bi-directional), but the cost was going to be too high.
rrinkerAlso more for things liek APB, for CTC you still need a connection back to the dispatcher console, so might as well use Loconet or CMRI or LCC and put the logic in the controlling computer.
Yep,
My thought on that is to use the Arduinos as daughter cards to the LCC nodes if it ever comes to that.