Recent Bruce Chubb C/MRI Articles in Model Railroader

[Anonymous]

Would someone be kind enough to tell me which issues of Model Railroader contain the articles on the C/MRI system?

Thanks!

Tony

[FJ and G]

Tony,

The current one and the last 3 or 4. My beagle at my 2nd or 3rd issue so I'm hopelessly lost now.

[Anonymous]

Dave

Grazi!

Tony

[Big_Boy_4005]

Tony, the original articles were done back in the mid 80's. The current series is on the new updates and redesign. Most of what you'll need to know should be in this series, but the books Chubb sells have everything. Are you thinking about using it?

My plan is to use it for detection, signaling, and turnouts on the mainline. This will give me realistic traffic control logic. When combined with TMCC train control, the mainlines will be fully automated. If a human operator wants to use the mainline, he will have to request clearence from the computer.

I have been discussing some of this stuff with Keith Brigode who I met over on the OGR forum a couple months back. What I think I'm going to do is use the Cab-1 and have the operator send a command sequence that would have no effect under my operating scheme, basicly anything but an engine command, and let the software do the rest.

If you want to hear more, let me know. Until all of these new "faces" showed up, I was really the only techie over here, or at least that was the impression I got. I asked one high tech question, got no response and stopped asking. Maybe its time to ask again!!![;)]

[Anonymous]

Elliot:

I don't know what I'm going to use on my eventual layout. Trying to do the research to make an informed decision. As I've stated in the thread you "resurrected", TAS has a product coming on the market, and C/MRI is on the market. Not having either system, I'd like to compare & then decide which one I'm going to use. If either.

If I do use a computer controlled signaling system, it would also have to have the ability to run something like a passenger train automatically. It might also be cool if it could make routing decisions on its own. My interest is to make it possible to run more trains by myself, or when it's must me & my son. I can see a situation where I'm breaking down trains & building new ones in a yard, while my son is delivering "freight" on the main line.

Anyway, it's time for me to get back to work.

Tony

[Big_Boy_4005]

Tony, I've been picking up bits and pieces of your layout situation as I read your posts. I ran across a really old topic while I was searching for something else. Have you got your space figuerd out and built, or are you just still thinking and gathering ideas in general. If you ever want design help, I would be happy to work directly with you. I have done this with a couple of members here including ChiefEagles.

I understand that generally the point of a model railroad is so that you (the human) can run the trains. However, in my case I am planning a layout so large, that I could have 8-10 friends helping and still have more traffic moving while everyone is busy operating. It means that I will need that many Cab-1's, so that each human can have one for his train.

No sharing controls or juggling trains. One person per train, one remote per person, equals remote per train. When its only me, I can still run a bunch of trains, but only have to worry about one.

Layout design is important for this kind of operation, and I think it makes it easier the closer your track plan gets to a real railroad. The use of Gargraves or Atlas track makes detection using CMRI simple and very effective, as you can devote any number of inputs to the task. More inputs means finer resolution as to the location of the train, and that translates into better speed control by the computer. This was a part of the OGR discussion, but I haven't finished reading all of it yet, and I'm not sure if anyone has carried it that far since they aren't using CMRI for detection.

The use of the software being developed may not help me do what I want, but I am watching. So far everything I am talking about is still theory, but I don't see any reason why it won't all work together, with the right software.[;)]

[FJ and G]

Elliot or others,

I currently use DCS but would be interested in learning of any benefits that CMRI could do in addition to what I already have.

Besides being in MR, perhaps a CMRI article in one of the toy train mags detailing specifics for our AC operation of toy trains would be welcomed.

[Anonymous]

Elliot:

We've had to postpone building our addition. The estimates we've received were higher than we were expecting. This is partly due to the increased cost of plywood since the Iraqi war started.

I'm still playing around with layout designs. I appreciate your offer of help with the layout design, and I just might take you up on it. The space I'll have, eventually, will measure 10' 4" x 20'. I'm working on a plan now that has a yard in the middle of the room, connected by an O54 wye to the rest of the layout.

Anyway, I've got over a year before the room will even exist, so I've got lots of time to try things. I just need th eenergy & inspiration.

Tony

[Anonymous]

Hi guys,

There was a layout in CTT last year (May 2003) built by John Shankland that uses C/MRI. John really didn't buy the C/MRI components as much as he built them, although there are companies that sell the basic building blocks.

Basically, a C/MRI layout is a block control layout (it was called "cab control" in the old days). But instead of an operator throwing a toggle switch to choose between transformer A or transformer B to power a given block, a computer does the thinking, using input from train detectors on each block of the layout. Also, there are numerous transformers (or cabs), not just A or B. If I recall correctly, John had 8.

The trains run in conventional-control mode (not command control), and their ability to move into the next block is governed by the computer, which processes data from the rest of the layout to determine if an adjacent block is clear or not. John and others add signalling to this, and the signals give a visual representation of what the computer is doing as far as distributing power to blocks. I know of some HO hobbyists who use this concept for their signalling, but acutually run their trains with DCC.

It's all very slick and the signalling is prototypical, but John's layout used an astonishing amount of wires and, if I recall correctly, more than a dozen C/MRI circuit "cards", each about the size of a sheet of notebook paper. It made me think of what you see when a telephone repairman is working on the junction box of a large office building. I looked at John's C/MRI reference manual (C/MRI is not just for trains) and it is 800-900 pages long.

John has since moved from Chicago and now lives in Florida. He has a website showing his new layout: jnstrains.com.

Sincerely,
Neil Besougloff
editor

[Big_Boy_4005]

Thanks Neil, I saw that article, and found it quite interesting. My goal is to take that to the next and possibly final level, using CMRI and TMCC together for full automation of selected trains, while others would remain under operator control.

I like to think of it as "smart trains" and "smart track", and when blended together it forms an Artificial Intelligence. The computer knows where the trains are, AND can control them. My goal is not to replace humans in the operation, but to supliment them in order to enhance the realism.[;)]

[Anonymous]

Neil:

Actually, the issue of CTT you mention was the first issue of the magazine I ever saw, and that cover story on John Shankland's layout is what prompted me to buy it. It was also that issue which helped me to decide to stick to O guage (I had been contemplating going to HO), and which also prompted me to subscribe to CTT.

The rest is history [;)]

Elliot:

I managed to find the February, March & April issues of Model Railroader at my local hobby shop on the way home from work last night. They did not have the January issue, so I'll be off to the back issues page here in a few to order that one.

I also visited the MS Developer Network web site and printed out some articles on RS232 programming. I haven't read them yet, but I do know that VB 6 comes with an ActiveX component called MSCOMM. This is an object class which you instantiate & can use to communicate with the serial ports.

I also had an idea about using TMCC & the computer. You get one Command Base & connect it to the computer, but don't connect it to the track. You get a second Command Base & change the crystal so it can't receive CAB-1 commands. You hook this to the track & the computer. The computer is then programmed to receive the commands from the first Command Base, and then pass them through to the other. this allows the computer to intercept commands without them going to the trains & it can substitute or embellish or run scripts on command.

Tony

[pmsteamman]

What is the largest scale that C/MRI can be used?

[FJ and G]

I recall the article Neil mentions but don't recall much in the way of explanation of how it was put together.

I think Elliot might be on to something in combining the best of computer with the best of TMCC. In my case, that would be DCS.

One area where I might wi***o dabble in would be a computer-controlled signalling system rather than hard-wired relays.

Another area I'd like to explore is programming accessories with a timing device to dim the lights and randomly start turning on lights in buildings and accessories.

While TMCC is nice and DCS has lots of functions, you really can't beat computers for the flexibility that they offer and innumerable options using simple "if, then, and or" commands. This is something in the distant distant future that I definitely will explore and tinker with, once everything is up and running.

Dave V

[Big_Boy_4005]

QUOTE: Originally posted by pmsteamman

What is the largest scale that C/MRI can be used?

I'm not sure what you mean by scale in this context. CMRI has nothing to do with train size, in fact it was originally designed as an industrial control system but adapted specificly for trains. You could use it to control things around your entire home if you wanted to. Control lights, music, appliances, whatever.

If you mean how large a system, I may still hold that record form my days at the Mall of America. That layout used a distributed serial version of the system with 10 seperate control locations called nodes. Each node had up to 20 cards, and each card had 24 switches on it, some for input and some for output.

[Anonymous]

I've read some threads somewhere about DCS's current inability to be controlled by a computer. As I understand it, there's an RS232 type connector on the TIU, but there's no documentation on connecting it to a computer, or what commands to send to that port should one get a computer connected to it. One of the posters mentioned seeing MTH folks doing a demo with the TIU plugged into a laptop, and the laptop seemed to be playing back an earlier recorded session.

But without documentation, you can't write a program to control trains in real time.

You CAN do this with TMCC now. It just won't work with any of your PS2 engines.

Tony

[Big_Boy_4005]

Bingo Tony, add to that the fact that if you want to use both TMCC and DCS together the ports are both tied together. The mystery code issue of DCS, combined with the dual language issue makes it difficult, if not impossible for me to do what I want using both.

There is one possibility though. We know that the TIU speaks the TMCC language because it uses it to control the TMCC engines. The real question is, can it listen to and understand TMCC. If the answer is yes then all of the problems are solved. Unfortunately, I have a feeling that the answer is no.

[Anonymous]

I don't know much about DCS, but I believe it only transmitts TMCC commands. I very well could be wrong, though.

I've read the first two parts of the Chubb C/MRI article. I got a little lost in the current source / current sinking discussion, but other than that I followed everything OK. Given the rather small current carrying limitations of the "super mini-node's" output switches, it seems that most O guage accessories, if they were to be controlled by C/MRI, would need to be wired to the node through relays. Which is OK.

Being the software engineer that I am, I'm currently envisioning in my head some objects. I won't get to part 3 of the article, which deals with software, until tonight at the earliest. That isn't stopping me from thinking, in general terms, of some properties & methods.

I'm thining of a base object that would represent one "thing" to be controlled. It's properties would be the node address, the number of output pin(s) associated with it, and the number of the first output pin it controls. It would have a property to return the current state and a method for changing that state. From this basic object, you could use inheritance to create new classes that represent switch motor controllers & signal controllers.

Then there'd have to be another object class, similar to the base output class, that represents an input. This would have as properties the node address & the number of the input pin associated with it.

Once you have these two base classes, and the ones for signals, you can then create classes for switches & blocks. And once you have those, you can start to implement logic for controlling occupancy, etc.

If you set up the command bases like I indicated in my other post, you can then write logic to intercept commands to a train that's awaiting a green signal to prevent the operator from overrunning the signal. If you care to go that far.

Tony

[Big_Boy_4005]

Tony, the whole thing about sourcing and sinking is explained better in in the CMRI manual. I have a copy of the old version, and I will need to review it before I could explain it. I can't remember which way it was at the mall, but it will be the same on the new layout.

The software is the key. Once the data is gathered, it has to be processed and acted upon. Code I can write, but I'm rusty. It is the entire windows concept that is very hazey. If you could please define "object" that would really go a long way toward my understanding your theory. Is it a chunk of code that deals with a certain task as a stand alone process? My problem is that I learned programming back in the early 80's, and never kept up, especially with windows.

This diagram is of the hardware arangement that I'm going for. I'm posting it as a bit of a test to see how it shows up. I drew it with paint then transformed it into a jpeg. Click on it to enlarge it and it clears right up.

[Anonymous]

Elliot:

Thanks. I've emailed you about object oriented programming. Sorry, but I was thinking like a software developer at the time, and not like a train guy.

Tony

[Big_Boy_4005]

No problem Tony. My thing is that I've been out of the loop so long that I don't know the buzz words that are being used today. The concepts aren't forign, just the terminology. I should catch up fairly quickly.[%-)][;)][:D]

[Anonymous]

Elliot:

I'm sure you'll have no problem catching up. And if you're not sure of anything, just ask.

I still haven't gotten to the third article in the series yet, maybe later today. Spent the weekend doing stuff around the yard (it was the first warm, good weather weekend o fthe spring here) & the family took my mom out to dinner for her 80th birthday on Saturday. Not much time for trains.

However, based upon what I've read so far, the system seems simple to use. I like the fact that you use RS-232 to talk to the cards & you can daisy chain them together easily. The inputs seem to be of the "On/Off" variety, as opposed to analog. Unless they make a card with an analog input? Not sure what you'd use one for...

Tony

[Big_Boy_4005]

Analog output is available I believe, but I have no need for it with what I'm doing. The mall layout had 10 nodes all daisy chained together. I don't think I will be using more than 4. RS 232 is what the computer sees, but there is a converter between it and the nodes. I have the old 422, but with the new stuff in the articles 485 is available.

[Anonymous]

Elliot:

I can see analog output, maybe, I was thinking of analog input.

I still want to see what TAS is coming out with before I make a decision, but I kinda like the "roll your own" mentality of C/MRI.

I visited the JLC Enterprises website today (http://jlcenterprises.net), and I looked over & printed out their price list. I read the product discriptions, but some of them are clear as mud. I need to study things a bit more. I'm thinking of spending the $30 and getting the manual.

Can someone point me to a book on prototypical signaling?

Tony

[Big_Boy_4005]

Tony, Bruce covers a bunch of prototype issues in the manual, including signaling. You may do just fine with the information found there.

Bruce also has a Kalmbach book out called How To Operate Your Model Railroad. It discusses all kinds of things, schedules, waybills, dispatching, and there is a chapter on signaling too. This may be the even better place to start, and makes an excellent companion to the CMRI manual.

I think there is an analog input device as well, but even if there isn't you could find one and use it to drive as many digital inputs as you want or need. this system doesn't really care what you hook to it as long as you follow the basic rules. That's part of what's so cool about it.[swg]

[Anonymous]

Eliot:

I just finished reading the third article in the series. I'm going to have to go back over it. I need to study the logic for determining direction of travel in his program a bit more.

I have to say I don't care for his programming style, but then again, I generally don't care for anyone's style but my own. For me, how the code is formatted adds a lot to understanding it, or not understanding it. I will say that other programmers who have read my code think that I do a good job of documenting it in place & making it readable.

I'm not very crazy about the "build a custom program for your pike" concept, as any changes to the layout could cause extensive coding changes. I much prefer the approach where the logic is fixed but depends on data. That is, you describe the layout to the program using input screens, which would be a (tedious but) one time set up process, and then save it. Every time you start up the program after that, it pulls up the file & is ready to go.

Then, if you make changes to the layout, you edit the data & save it again, then you're ready to go. It's been my experience that coding changes cause more work trouble shooting than this other approach.

I have a few ideas in the back of my head, and I just might go with C/MRI so I can expand on those ideas. Lessee, with my current rinky-dink 4 block layout, I could buy some signals and one of the super-mini cards, then use insulated rails for occupancy detection. I can also probably wire in the four 022s some how. I think I should be able to do the whole thing with the one card, maybe 2 max.

The only problem is that the layout is in the dining room & the computer is one level down on the opposite side of the house!

Tony

[Big_Boy_4005]

I think Bruce is from the really old school, back when processor time was charged, and and tape drives had to be loaded by attendants. I was exposed to punch cards, though not for long. The mall computer was a 286 12 years ago, we have come a long way since then. The weak link is no longer, the processor speed, it is the baud rate, and at 9600 it should be just fine for everything we want to do.

Chubb's method of representing the layout to the computer is very rigid, which is OK, but I was thinking in terms of building blocks. He may still be using very old hardware to run the system, so he may feel the need to be very efficient in code reduction and subroutine calls.

As far as controling an 022 turnout with CMRI, that's a piece of cake. Worst case, an SPDT relay, and one output bit, done. tie the relay contacts to the non derailing feature or even the controller posts.

[Anonymous]

Elliot:

Yeah, I agree with you about Bruce's school affiliation. it kind of shows.

I did a couple of Fortran programs on punched cards in my undergrad days. I'll take a CRT any day!

I also see where he's going with the I/O. Read all the devices, parse the info, process the logic, construct the output, write to all the devices. Minimize the I/Os = maximize processing time. It's a structure that makes sense, even with faster processors. It probably takes just as long to read/write one port as it would to read all of them, for the small to average pike.

Tony

Tony

[Big_Boy_4005]

You and I can't be too far apart in age. I'll be 43 in May. There is something to be said for the old school, but I think we can do better with the new stuff, Lets go for it![;)]

[Anonymous]

Elliot:

Your birthday is in May? So is mine! I'll be 44 on May 28.

All I need to do is lose the 100 lbs I've put on in the 20 years since I graduated college.

And get our addition built.

Oh, BTW, I thought of a use for analog input/output. Computerized throttle control. It's the only place it makes sense that I can think of. There might be others, though.

Tony

[Big_Boy_4005]

Tony, mine is the 18th, you have 355 days on me. Oh, and ditto to the 100 pounds, but I would settle for 50.[;)]

Why bother with a computerized throttle when using TMCC, unless you are doing conventional. I don't plan to! I have a bunch of conventional locomotives, and see 3 options for them.

• Retrofit for TMCC
• Turn into slaves / helpers
• Retirement

I have some Williams F7's that are really good runners, that will probably get repainted, and retrofitted. Beyond that I'm not sure.

The slave option is best for the roadnames and engine types that fit my railroad. A simple 4 pin connector plug would be perfect. 2 pins from the slave would be tied to the wheels and rollers, giving the combo extra pickups. The other 2 pins would bring the motor output from the TMCC board. One board shouldn't have any trouble driving up to 4 can motors. These would be semi-permenant lash ups.