Hi Al

The three terminals at the end of the ODMB are +12 Ground -12. The south rail is
the power rail form the throttles via the toggles that switch cabs. The north
rail connects to the track in screw which is the inner most screw on each block
of the ODMB and the last screw is the output of the detector to the CMRI inputs.
Note that the south rail becomes a common rail concept through the ground of the
ODMB which feeds back to all the throttles grounds. the power supply grounds and
the CMRI grounds. Using the one supply will give you the power grounds  for the
CMRI and the throttles. Reverse loops cannot share the ODMB ground bus as they
must be wired as per DC wiring for reverse loops, IE separate from the other
blocks with their own reverse polarity switch. Also looking a Bruce's Reverse
wiring schematic from the build book. The reverse loop detector is after the
reverse switch and needs an opto isolator to connect to the CMRI logic and a
separate power supply for the detector power for each reversing section.

Don
   ----- Original Message -----
   From: albert.drummond<mailto:albert.drummond@...>
   To: CMRI_Users@yahoogroups.com<mailto:CMRI_Users@yahoogroups.com>
   Sent: Monday, May 03, 2010 8:42 PM
   Subject: [CMRI_Users] Power Supply



   Being an engineer, I do know something about electricity. However, I have
learned over the years to ask before plugging in because I am sure that more
than one in this community has learned the hard way and would like to prevent a
fellow hobbiest from uttering non-engineering words.

   I have a Dell power supply Model PS 5201-7D. I believe that I once found a
wiring diagram on google images. This thing has a hornet's nest of wires and I
think that I only need 2 of them for my regulated 5 volts. So I would be most
appreciative if someone could tell me what they did and be willing to share a
wiring diagram.

   The 12 volt side for the Optimized Detector is a little more complicated. I
have not seen any wiring diagrams from the pages that Bruce has sent to me nor
in any articles that have what I am looking for. I have a 30,000 ft view of what
is needed, but now I need the details. The instructios for the OD call for plus
12 v and minus 12 v and there is a ground. By luck I do have a 24 volt centertap
transformer if that is what is needed. What I would really like to see is a
wiring diagram for the required power supply.

   And while we are at it I would like to see a circuit diagram with the required
gaps of how to hook up to the track. Again, I can guess, but why should I?

   Forums are great, we have one at work. I appreciate your help.





[Non-text portions of this message have been removed]

Dear Albert:

As I am confident that others will inform you, your Dell Computer Power
Supply should have not only the +5Vdc but it will also have +12Vdc and ground
and the -12Vdc required for powering your ODs.

Because you are using DC for track/locomotive power, you will have one
common ground for everything. With respect to that ground you will be using the
+5Vdc, +12Vdc and -12Vdc. All 3 voltages plus the ground should be available
from the Dell Power Supply.

Bruce Chubb


[Non-text portions of this message have been removed]

Being an engineer, I do know something about electricity.  However, I have
learned over the years to ask before plugging in because I am sure that more
than one in this community has learned the hard way and would like to prevent a
fellow hobbiest from uttering non-engineering words.

I have a Dell power supply Model PS 5201-7D.  I believe that I once found a
wiring diagram on google images.  This thing has a hornet's nest of wires and I
think that I only need 2 of them for my regulated 5 volts.  So I would be most
appreciative if someone could tell me what they did and be willing to share a
wiring diagram.

The 12 volt side for the Optimized Detector is a little more complicated.  I
have not seen any wiring diagrams from the pages that Bruce has sent to me nor
in any articles that have what I am looking for.  I have a 30,000 ft view of
what is needed, but now I need the details.  The instructios for the OD call for
plus 12 v and minus 12 v and there is a ground.  By luck I do have a 24 volt
centertap transformer if that is what is needed.  What I would really like to
see is a wiring diagram for the required power supply.

And while we are at it I would like to see a circuit diagram with the required
gaps of how to hook up to the track.  Again, I can guess, but why should I?

Forums are great, we have one at work.  I appreciate your help.

Dear Friends I try virtualization under Vmware,
I use a regular dos Machine on a modern laptop and the system
recognize a USB to serial converter cable and I was able to use the Qbasic
program
I wrote 15 years ago.

Bye
Giorgio Calzoni
N scale Clinchfield in Italy

Chris,

I know this is off topic, but what other unimaginable things are they doing, I
did look at the website a little, but I was not overly impressed being a huge
Linux use. However, Open SW of any type is always interesting. So, share some
unimaginable things about FreeDOS.

BTW -  I have not forgot about getting you all access to the Wiki, Just have not
got around to setting it up yet.

Thanks,

John Vaughters





________________________________
From: Chris Ruhl <cdruhl@...>
To: CMRI_Users@yahoogroups.com
Sent: Fri, April 30, 2010 4:13:30 PM
Subject: RE: [CMRI_Users] USB to serial converter


There is one other possible solution depending on how adventurous one is and
if they like to play with odd computer operating systems.   Check out the
FreeDOS project.  Those chaps have DOS doing unimaginable things.  These
guys are so into DOS that they refuse to abdicate.  FreeDOS is a 32-bit
version that saw the entire 80Gb hard drive single partition and all of the
512mb of system RAM.

I used their version to run some industrial processes and got a USB port
running.  I don't know if any of those chaps have a USB to serial driver,
though.  They probably do if you ask.

_____

From: CMRI_Users@yahoogro ups.com [mailto:CMRI_Users@yahoogro ups.com] On
Behalf Of Donald Wood
Sent: Friday, April 30, 2010 8:29 AM
To: CMRI_Users
Subject: [CMRI_Users] USB to serial converter

This was one customer that had an issue getting his system to work. You will
remember that I and Dave asked the group about Dos based programming
languages using the USB port In his words.

Anyway, here was the problem. First, I have chosen to implement C/MRI using
DOS-based Quick Basic. Second, I was using an old laptop as the computer,
which doesn't have a serial port. So I purchased a USB-to-RS232 cable, and
installed the driver that came with it. But the driver software is a Windows
program, so it was not visible to the DOS operating system - so no signal
was sent to or from the serial end of the cable! The solution? I dragged an
old desktop computer out of the attic which does have a serial port, set it
up, and ran the standalone test with perfect results!! I'm on cloud nine -
on to programming!

Good job

The other option was to switch to VB or another windows based programming
language so the driver would install and be seen by the programming language
running under Windows. then as Bruce posted the switch to any computer is
simply modifying the serial port address within the program
Don

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]







[Non-text portions of this message have been removed]

Contrary to my friend and our hero, Bruce Chubb's good advice, and others, it is
quite reasonable to get four three color + dark signal heads from only one byte
of data if you're a little bit Nerdy.  Before converting to CMRI, I did that on
my Teton Short Line so it naturally carried over to CMRI because the hardware
was built and had served well for many years. http://tslrr.com/sgnlhome.htm

Two bits, 00, 01, 10 & 11 give us four configs that can easily decode to DARK,
GRN, YEL & RED with about 50 cents worth of TTL.  One byte then can control four
heads.

You can go much further at "packing". 32 heads with only two bytes?  See the
referance.

Some custom software? Of course, but you can really pack it in and NOT cross
boundries.

For a private layout such customization is OK but I'd never consider it for our
HO club layout that others will have to maintain someday.  In that scenario, I
recommend keeping it as close to 100% CMRI as possible because of the very
thorough documentation that will live on beyond the local Nerd.

Wayne in Idaho


Wayne Roderick P.E. (elec-ret)
CEO, Teton Short Line, Pocatello Idaho, USA
http://www.tslrr.com/
(NMRA life-1721)

Thanks to several of you who responded to my question about packing outputs. I
believe I understand how to proceed, and appreciate your advice. Rob W.

Dear Bryan:

What you have noticed is correct. The great majority of the railroads in the USA
use East and West as their employee timetable direction essentially independent
of the actual primary direction of travel. For example, on the Southern Pacific
every train movement headed in the direction toward San Fransisco, the home
office, was Westbound and a route away from San Fransisco was Eastbound.

Thus, for example a train traveling almost exclusively northward from Los
Angeles to San Fransisco would be Westbound. While a train traveling almost
exclusively nortward from San Fransisco to Portland Oregon would be Eastbound.

As a further reinforcemnet of the example a freight going from Los Angeles to
Portland, very prfedominately north geographic direction, would first be going
Westbound and then Eastbound.

Hope this explains the situation and hopefully doesn't add to the possible
confusion of how we do in in the USA <grin>.

Bruce

--- In CMRI_Users@yahoogroups.com, "revolution.morris" <bryan.morris@...> wrote:
>
> Hi Group.  Thanks to everyone who helped with the BLMA question.  I hope that
this does not qualify as the dummest question of the week but here goes.
>
> I have noticed that all of the examples in the 'Big Green Book' refer to
trains travelling in the diection East to West or visa versa.  Do trains ever
travel North to South?  For example  from Bakersfield to Los Angeles seems on
the map to be more North/South than East/West.  What are the rules in this
regard i.e. for numbering the signals and establishing train direction.
>
> Regards
>
> Bryan
>

I have added the code as a text file to the files section.

It is called:

IPIN OPIN code.txt


I have added the code for both the input handling and the output
handling that I use.


All the best

Martyn


On May 2, 2010, at 3:27 PM, Donald Wood wrote:

> Martyn
>
> You could copy the code to notepad and list on the files section.
> Same goes for the USB conversion card information posted earlier
> today. Then if some one asks. we can start referring them to files
> section for answer all ready posted
> Best
> Don
>   ----- Original Message -----
>   From: Martyn Kelly<mailto:martynkelly@...>
>   To: CMRI_Users@yahoogroups.com<mailto:CMRI_Users@yahoogroups.com>
>   Sent: Sunday, May 02, 2010 1:04 PM
>   Subject: Re: [CMRI_Users] Re: Packing across byte boundaries
>
>
>
>   I solved the problem a little differently than the handbook on my
>   layout.
>
>   At the moment I have one SMINI which has 48 outputs and using the
>   standard terminology NO=6.
>
>   I labeled each of these ouputs as an individual output pin. ie. OPIN
>   (1), OPIN(2), ...... OPIN(48)
>
>   If I wanted a signal across bytes I could have:
>
>   Signal 10 red as OPIN(7)
>   Signal 10 yellow as OPIN (8)
>   Signal 10 green as OPIN(9)
>
>   The code would be:
>
>   REM ** Assign values to the output pins
>   IF SIG10=RED THEN OPIN(7)=1 : OPIN(8)=0 : OPIN(9)=0
>   IF SIG10=YEL THEN OPIN(7)=0 : OPIN(8)=1 : OPIN(9)=0
>   IF SIG10=GRN THEN OPIN(7)=0 : OPIN(8)=0 : OPIN(9)=1
>
>   I would then pack the output data using the following code:
>
>   REM ** Packing output data **
>   FOR I=1 TO NO
>   OB(I)=0
>   IF OPIN(((I-1)*8)+1)=1 THEN OB(I)=OB(I)+1
>   IF OPIN(((I-1)*8)+2)=1 THEN OB(I)=OB(I)+2
>   IF OPIN(((I-1)*8)+3)=1 THEN OB(I)=OB(I)+4
>   IF OPIN(((I-1)*8)+4)=1 THEN OB(I)=OB(I)+8
>   IF OPIN(((I-1)*8)+5)=1 THEN OB(I)=OB(I)+16
>   IF OPIN(((I-1)*8)+6)=1 THEN OB(I)=OB(I)+32
>   IF OPIN(((I-1)*8)+7)=1 THEN OB(I)=OB(I)+64
>   IF OPIN(((I-1)*8)+8)=1 THEN OB(I)=OB(I)+128
>   NEXT I
>
>   This code lets me assign signals, switches and lights to any output
>   line that I want to. I just keep a list of which item I have
>   connected to which output line.
>
>   I have similar code for the input pins IPIN(1), IPIN(2) ... IPIN
>   (16). I can let people have the code if they are interested.
>
>   This way of doing things just made sense to me. If it is useful to
>   someone else, great.
>
>   Thanks
>
>   Martyn
>
>   On May 2, 2010, at 12:35 PM, John Plocher wrote:
>
>>> Following this thread for a bit...
>>
>> ... myself, as well...
>>
>> As much as I understand (and appreciate and value...) Bruce's
>> focus on
>> BASIC programming, this illustrates how a change in perspective may
>> have huge consequences.
>>
>> In the "program your own C/MRI software program" world, there is a
>> large amount of effort (and discussion) spent on housekeeping
>> topics -
>> pack/unpack, loop timing, and the like. I did quite a bit of this
>> myself when I wrote BASIC and C/C++ C/MRI programs - and, as Jim
>> said,
>> it frequently led to nightmare "write only" code unless one was
>> extremely careful.
>>
>> This all changed when I moved to JMRI - no longer do I need to focus
>> on the mechanics of communicating with SUSIC nodes, packing bits and
>> variable naming. All I do is say "I want to define a signal that uses
>> C/MRI bits 22, 23, 24, 25, 26, 27, 28, 29 and 30". Moreover, I can
>> also say "it is a 3-headed route indication signal mast as used on
>> the
>> UP, and is protecting the following turnouts and blocks". Voila, the
>> system takes care of figuring out and managing all the details for
>> me!
>>
>> The computer science term for this is abstraction. The abstraction
>> level of Bruce's BASIC code is pretty low, while the abstraction
>> level
>> of JMRI is pretty high - and the difference affects how "easy" it is
>> to leverage and extend the system. To see what a high level
>> abstraction does for the users, just take a look at the topics that
>> are discussed on each forum: packing CMRI bits -vs- automated train
>> operation with JMRI :-)
>>
>> Don't misunderstand - there is nothing Right or Wrong with either
>> approach - both have their own strengths and target audiences,
>> just as
>> both have their own weaknesses and inappropriate application space.
>> Both systems can (and have been) used to automate some amazing
>> layouts, so the difference is not one of capability. Understanding
>> the differences simply gives us more alternatives: If you have never
>> used JMRI, you might want to try it out - and if you have never
>> written your own BASIC program to talk to your C/MRI system, go ahead
>> and try it - both are pretty easy, and you *will* learn something
>> new.
>>
>> -John
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Bryan,
East & West were historically the "railroad compass" direction to the home
office, at least for the SP.  The Coast Daylight (#98) Eastward ran south from
San Francisco to Los Angeles.  Numbering of trains were even for East and odd
for West.

Devices were numbered based upon mile post.  At Coyote, a former signal was
numbered 635.  It was located at MP 63.5 and protected the westward (compass
north) leg of the double track.

On my layout, I use the mile post tens/hundreds value for the major device id
and the units value for an east (even) or west (odd) facing designator.  In the
files section is a picture of one of the control panels with all of this
information displayed.  This works for my software implementation of the layout
control program.

Chuck Catania
www.cpcrr.org


--- In CMRI_Users@yahoogroups.com, "revolution.morris" <bryan.morris@...> wrote:
>
> Hi Group.  Thanks to everyone who helped with the BLMA question.  I hope that
this does not qualify as the dummest question of the week but here goes.
>
> I have noticed that all of the examples in the 'Big Green Book' refer to
trains travelling in the diection East to West or visa versa.  Do trains ever
travel North to South?  For example  from Bakersfield to Los Angeles seems on
the map to be more North/South than East/West.  What are the rules in this
regard i.e. for numbering the signals and establishing train direction.
>
> Regards
>
> Bryan
>

Many railroads travel more distance East and West than they do North and South.
So even though the tracks go North, it is still considered "Railroad East" or
something like that. Mainly it is a convention the railroads use to keep things
standardized. If you have a railroad that is primarily a North-South bridge
route or something like that, you may well decide to use North and South rather
than East-West.

Kevin

Martyn

You could copy the code to notepad and list on the files section. Same goes for
the USB conversion card information posted earlier today. Then if some one asks.
we can start referring them to files section for answer all ready posted
Best
Don
   ----- Original Message -----
   From: Martyn Kelly<mailto:martynkelly@...>
   To: CMRI_Users@yahoogroups.com<mailto:CMRI_Users@yahoogroups.com>
   Sent: Sunday, May 02, 2010 1:04 PM
   Subject: Re: [CMRI_Users] Re: Packing across byte boundaries



   I solved the problem a little differently than the handbook on my
   layout.

   At the moment I have one SMINI which has 48 outputs and using the
   standard terminology NO=6.

   I labeled each of these ouputs as an individual output pin. ie. OPIN
   (1), OPIN(2), ...... OPIN(48)

   If I wanted a signal across bytes I could have:

   Signal 10 red as OPIN(7)
   Signal 10 yellow as OPIN (8)
   Signal 10 green as OPIN(9)

   The code would be:

   REM ** Assign values to the output pins
   IF SIG10=RED THEN OPIN(7)=1 : OPIN(8)=0 : OPIN(9)=0
   IF SIG10=YEL THEN OPIN(7)=0 : OPIN(8)=1 : OPIN(9)=0
   IF SIG10=GRN THEN OPIN(7)=0 : OPIN(8)=0 : OPIN(9)=1

   I would then pack the output data using the following code:

   REM ** Packing output data **
   FOR I=1 TO NO
   OB(I)=0
   IF OPIN(((I-1)*8)+1)=1 THEN OB(I)=OB(I)+1
   IF OPIN(((I-1)*8)+2)=1 THEN OB(I)=OB(I)+2
   IF OPIN(((I-1)*8)+3)=1 THEN OB(I)=OB(I)+4
   IF OPIN(((I-1)*8)+4)=1 THEN OB(I)=OB(I)+8
   IF OPIN(((I-1)*8)+5)=1 THEN OB(I)=OB(I)+16
   IF OPIN(((I-1)*8)+6)=1 THEN OB(I)=OB(I)+32
   IF OPIN(((I-1)*8)+7)=1 THEN OB(I)=OB(I)+64
   IF OPIN(((I-1)*8)+8)=1 THEN OB(I)=OB(I)+128
   NEXT I

   This code lets me assign signals, switches and lights to any output
   line that I want to. I just keep a list of which item I have
   connected to which output line.

   I have similar code for the input pins IPIN(1), IPIN(2) ... IPIN
   (16). I can let people have the code if they are interested.

   This way of doing things just made sense to me. If it is useful to
   someone else, great.

   Thanks

   Martyn

   On May 2, 2010, at 12:35 PM, John Plocher wrote:

   >> Following this thread for a bit...
   >
   > ... myself, as well...
   >
   > As much as I understand (and appreciate and value...) Bruce's focus on
   > BASIC programming, this illustrates how a change in perspective may
   > have huge consequences.
   >
   > In the "program your own C/MRI software program" world, there is a
   > large amount of effort (and discussion) spent on housekeeping topics -
   > pack/unpack, loop timing, and the like. I did quite a bit of this
   > myself when I wrote BASIC and C/C++ C/MRI programs - and, as Jim said,
   > it frequently led to nightmare "write only" code unless one was
   > extremely careful.
   >
   > This all changed when I moved to JMRI - no longer do I need to focus
   > on the mechanics of communicating with SUSIC nodes, packing bits and
   > variable naming. All I do is say "I want to define a signal that uses
   > C/MRI bits 22, 23, 24, 25, 26, 27, 28, 29 and 30". Moreover, I can
   > also say "it is a 3-headed route indication signal mast as used on the
   > UP, and is protecting the following turnouts and blocks". Voila, the
   > system takes care of figuring out and managing all the details for me!
   >
   > The computer science term for this is abstraction. The abstraction
   > level of Bruce's BASIC code is pretty low, while the abstraction level
   > of JMRI is pretty high - and the difference affects how "easy" it is
   > to leverage and extend the system. To see what a high level
   > abstraction does for the users, just take a look at the topics that
   > are discussed on each forum: packing CMRI bits -vs- automated train
   > operation with JMRI :-)
   >
   > Don't misunderstand - there is nothing Right or Wrong with either
   > approach - both have their own strengths and target audiences, just as
   > both have their own weaknesses and inappropriate application space.
   > Both systems can (and have been) used to automate some amazing
   > layouts, so the difference is not one of capability. Understanding
   > the differences simply gives us more alternatives: If you have never
   > used JMRI, you might want to try it out - and if you have never
   > written your own BASIC program to talk to your C/MRI system, go ahead
   > and try it - both are pretty easy, and you *will* learn something new.
   >
   > -John
   >
   >
   > ------------------------------------
   >
   > Yahoo! Groups Links
   >
   >
   >





[Non-text portions of this message have been removed]

I solved the problem a little differently than the handbook on my
layout.

At the moment I have one SMINI which has 48 outputs and using the
standard terminology NO=6.

I labeled each of these ouputs as an individual output pin.  ie.  OPIN
(1), OPIN(2), ...... OPIN(48)


If I wanted a signal across bytes I could have:

Signal 10 red as OPIN(7)
Signal 10 yellow as OPIN (8)
Signal 10 green as OPIN(9)

The code would be:

REM ** Assign values to the output pins
IF SIG10=RED THEN OPIN(7)=1 : OPIN(8)=0 : OPIN(9)=0
IF SIG10=YEL THEN OPIN(7)=0 : OPIN(8)=1 : OPIN(9)=0
IF SIG10=GRN THEN OPIN(7)=0 : OPIN(8)=0 : OPIN(9)=1


I would then pack the output data using the following code:

REM ** Packing output data **
FOR I=1 TO NO
OB(I)=0
IF OPIN(((I-1)*8)+1)=1 THEN OB(I)=OB(I)+1
IF OPIN(((I-1)*8)+2)=1 THEN OB(I)=OB(I)+2
IF OPIN(((I-1)*8)+3)=1 THEN OB(I)=OB(I)+4
IF OPIN(((I-1)*8)+4)=1 THEN OB(I)=OB(I)+8
IF OPIN(((I-1)*8)+5)=1 THEN OB(I)=OB(I)+16
IF OPIN(((I-1)*8)+6)=1 THEN OB(I)=OB(I)+32
IF OPIN(((I-1)*8)+7)=1 THEN OB(I)=OB(I)+64
IF OPIN(((I-1)*8)+8)=1 THEN OB(I)=OB(I)+128
NEXT I

This code lets me assign signals, switches and lights to any output
line that I want to.  I just keep a list of which item I have
connected to which output line.

I have similar code for the input pins IPIN(1), IPIN(2)  ... IPIN
(16).  I can let people have the code if they are interested.

This way of doing things just made sense to me.  If it is useful to
someone else, great.

Thanks

Martyn




On May 2, 2010, at 12:35 PM, John Plocher wrote:

>> Following this thread for a bit...
>
> ... myself, as well...
>
> As much as I understand (and appreciate and value...) Bruce's focus on
> BASIC programming, this illustrates how a change in perspective may
> have huge consequences.
>
> In the "program your own C/MRI software program" world, there is a
> large amount of effort (and discussion) spent on housekeeping topics -
> pack/unpack, loop timing, and the like.  I did quite a bit of this
> myself when I wrote BASIC and C/C++ C/MRI programs - and, as Jim said,
> it frequently led to nightmare "write only" code unless one was
> extremely careful.
>
> This all changed when I moved to JMRI - no longer do I need to focus
> on the mechanics of communicating with SUSIC nodes, packing bits and
> variable naming.  All I do is say "I want to define a signal that uses
> C/MRI bits 22, 23, 24, 25, 26, 27, 28, 29 and 30".  Moreover, I can
> also say "it is a 3-headed route indication signal mast as used on the
> UP, and is protecting the following turnouts and blocks".  Voila, the
> system takes care of figuring out and managing all the details for me!
>
> The computer science term for this is abstraction.  The abstraction
> level of Bruce's BASIC code is pretty low, while the abstraction level
> of JMRI is pretty high - and the difference affects how "easy" it is
> to leverage and extend the system.  To see what a high level
> abstraction does for the users, just take a look at the topics that
> are discussed on each forum:  packing CMRI bits -vs- automated train
> operation with JMRI :-)
>
> Don't misunderstand - there is nothing Right or Wrong with either
> approach - both have their own strengths and target audiences, just as
> both have their own weaknesses and inappropriate application space.
> Both systems can (and have been) used to automate some amazing
> layouts, so the difference is not one of capability.  Understanding
> the differences simply gives us more alternatives:  If you have never
> used JMRI, you might want to try it out - and if you have never
> written your own BASIC program to talk to your C/MRI system, go ahead
> and try it - both are pretty easy, and you *will* learn something new.
>
>   -John
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hi Group.  Thanks to everyone who helped with the BLMA question.  I hope that
this does not qualify as the dummest question of the week but here goes.

I have noticed that all of the examples in the 'Big Green Book' refer to trains
travelling in the diection East to West or visa versa.  Do trains ever travel
North to South?  For example  from Bakersfield to Los Angeles seems on the map
to be more North/South than East/West.  What are the rules in this regard i.e.
for numbering the signals and establishing train direction.

Regards

Bryan

> Following this thread for a bit...

... myself, as well...

As much as I understand (and appreciate and value...) Bruce's focus on
BASIC programming, this illustrates how a change in perspective may
have huge consequences.

In the "program your own C/MRI software program" world, there is a
large amount of effort (and discussion) spent on housekeeping topics -
pack/unpack, loop timing, and the like.  I did quite a bit of this
myself when I wrote BASIC and C/C++ C/MRI programs - and, as Jim said,
it frequently led to nightmare "write only" code unless one was
extremely careful.

This all changed when I moved to JMRI - no longer do I need to focus
on the mechanics of communicating with SUSIC nodes, packing bits and
variable naming.  All I do is say "I want to define a signal that uses
C/MRI bits 22, 23, 24, 25, 26, 27, 28, 29 and 30".  Moreover, I can
also say "it is a 3-headed route indication signal mast as used on the
UP, and is protecting the following turnouts and blocks".  Voila, the
system takes care of figuring out and managing all the details for me!

The computer science term for this is abstraction.  The abstraction
level of Bruce's BASIC code is pretty low, while the abstraction level
of JMRI is pretty high - and the difference affects how "easy" it is
to leverage and extend the system.  To see what a high level
abstraction does for the users, just take a look at the topics that
are discussed on each forum:  packing CMRI bits -vs- automated train
operation with JMRI :-)

Don't misunderstand - there is nothing Right or Wrong with either
approach - both have their own strengths and target audiences, just as
both have their own weaknesses and inappropriate application space.
Both systems can (and have been) used to automate some amazing
layouts, so the difference is not one of capability.  Understanding
the differences simply gives us more alternatives:  If you have never
used JMRI, you might want to try it out - and if you have never
written your own BASIC program to talk to your C/MRI system, go ahead
and try it - both are pretty easy, and you *will* learn something new.

   -John

Following this thread for a bit...

While not currently writing my own software I have in the past and I must really
strongly agree with those saying that's it's a bad idea to cross bounderies.

A lot of what we write while though still fresh in the mind in the writing phase
can become a nightmare later when adding to correcting code.

The "write once, forget many" concept. True, extensive commenting can help but
that's one of the first things that might get set aside as we think we know what
we're doing.

Computers are enough magic without attempting to use programming tricks.

Back in the computer dark ages when I would try to fit some complex program into
8 thousand bytes, yes that's what you did... not now.

OK you old timers, hand assemble a routine to save 4 bytes...

If space for your code is an issue move to VB from QB. Also I/O bits are cheap
enough in C/MRI land.

If there is a single signal that just will put you into another (unwanted) DOUT
or SMINI there is the possibility of using an off board IC to handle the two to
three issue.

Jim Albanowski

<snip>

Just posting this for future reference.
I'm using JMRI panel pro, I have a usb to rs232 adapter (DB 9 connector)which
then connects to a rs232 to rs485 converter which then connects to smini node 0.
Starting JMRI dose not intialize smini, Smini green led stays in mode 0.
When i do a loopback test using hyperterm, with the smini connected but no loop
back wiring as the smini forms the loop, the green led goes into error mode 5.
I found a little gem on the jmri list that said some of these newer adapters
require the following pins connected together DSR - DTR (4&6 on a DB9) and pins
RTS - CTS (7&8 on a DB9). So i tried it and it now intializes striaght up.
Chris

Problem solved, it was a dodgy usb to rs232 adapter, adapter replaced converter
board working just as it is designed to do.
Thank you all for your suggestions.
Chris

--- In CMRI_Users@yahoogroups.com, "cpelliott100" <cpelliott100@...> wrote:
>
> Right some answers.
> 1. Local echo is selected on in hyperterm and i'm getting 2 of everything i
type
> 2. there are no short circuits between any of the 3 conductors in the rs232
cable
> 3. the output voltage from my computer is positive 5 volts on both the tx and
rx lines when measured to ground.
> Ideas?
> Chris
>
> --- In CMRI_Users@yahoogroups.com, "Nick" <cornwall9@> wrote:
> >
> > Chris,
> >
> > >>>>>
> > 1. With no rs232 or rs 485 connected but converter powered both leds are
dark.
> >
> > 2. With only the rs232 connected and NOTHING connected to the rs485 only the
> > amber led is on.
> > >>>>>
> >
> > Until you have the program running Both LEDs should remain dark. When the
program is running, The Yellow LED should flicker. When the RS 485 cable is
connected to the SMINI, the Red LED should respond with an ack corrosponding to
the sent data. With the loopback, the RED should flash in sync with the Yellow
LED.
> >
> > #2 indicates that you have a solid LED on when you connect the cable. This
indicates a short circuit or constant power to the TX side of the cable to the
converter. This is BAD. The LED should ONLY flicker when communication is
happening, (program running), It shoul;d NEVER be on constantly. It looks like
you have a problem with either your comm port on the computer or the cable you
are using. The cable only needs to have 3 wires from the 9-pin comm port. RX
(pin 2) TX (pin 3) and Ground (pin 7 or 9) I've forgotten the exact one since it
has been almost 15 years since I made up comm cables.
> >
> > Take a VOM and check that there is no short between any of those pins in the
cable (disconnected from the computer). If you used an old comm cable, make sure
it was not a Null Modem cable. They us a crossover between pins 3 and 4 to
satisfy the old "handshake" between modems. The cable should be straight through
with no crossovers.
> >
> > If you needed an extension cable to get to your SMINI, this might also be
the problem.
> >
> > I'll bet you will find the problem there.
> >
> > Regards,
> > Nick Kulp
> >
>

In a message dated 5/1/2010 4:50:56 PM Eastern Daylight Time,
snorkelbob1938@... writes:


> To confirm my understanding from a reading of the User's Manual: Bruce's
> examples of packing for outputs conveniently has devices with bit
> combinations totaling 8; that is, one full byte. Nice and neat.
>
> But many of my signal heads have three lights -- so, for example, if SIG1
> has two heads of three lights each and SIG2 has one head of three lights, I
> need 9 output pins to accommodate those two devices.
>
> If SIG1 used pins 0-5 on OB(1), am I correct in understanding that I
> CANNOT write the pack code for SIG2 as "OB(1) = SIG2 * B6 OR OB(1)", because
the
> third bit for that device would not automatically carry over to the next
> byte? Instead, Im assuming that I must move that device to an output byte
> where there are at least three contiguous open pins, and leave the last two
> pins on OB(1) available for some device that only needs two pins.
>
> Do I have it right? Thanks in advance - Rob W
>

I recommend not letting devices cross 8-bit, 1 byte, port boundaries. For
example, as you point out, have a 3-light over a 3-light signal takes 6 bits
leaving 2 bits still available. Use those for driving a switch motor, or two
switch motors is using SMC12 cards, or a 2-light dwarf, or two display LEDs
on a control panel, or crossing warning flasher-bell-gates, or a multitude
of other items.

The recommended procedure when setting up your I/O tables is to assign all
your higher number of l/O line requirements first, then fill in openings
with the next few line devices, and then the next, and so forth with the last
step fill in with single line devices.

Now for you 3-light over 3-light over 3-light requiring 9 output lines
which does not fit the 8-bit, or 1 byte, port boundary. For this I would
personally cover 2 of the 3-light heads using 6 of the 8-bits of one port and
then
move the third head over to the next port. This makes the software easy.

However, as Jeff Warner and others are rightfully pointing out, it is
possible to cross port boundaries but it just adds a level of complication to
the
software. For example, use IF-THEN statements to separate a given 3-light
signal's aspect into 3 separate bits, one for each color, or into 2-bits for
the green and yellow aspect and then 1-bit for the red aspect.

All this, and other software procedures can be used to effectively cross
port boundaries. However, in most cases, I find that with careful planning of
outputs, it is usually possible to achieve good byte utilization efficiency
without crossing boundaries. The key is to fit in dual and single line
devices to effectively fill the voids left when making the assignments of higher
line utilization devices.

The one overriding example being the 3-light over 3-light over 3-light
signal. In this case, if your signals are not already in place and the prototype
you are modeling does not demand modeling such signals, one might consider
substituting 3-light over 3-light over 2-light, which exactly fits into an
8-bit port.

In summary, let me point out that with the C/MRI and its great flexibility
you can do whatever you desire to accomplish. For example, and I do not
recommend it unless really deemed necessary, it is possible using a little extra
software to have devices cross port boundaries.

I hope this helps clarify the situation.

Bruce Chubb


[Non-text portions of this message have been removed]

Rob,

I used some odd leftover bits in separate ports for a two-head signal
by writing individual code for each lamp (LED).  It made the code a
little more complicated but has worked fine for years.

Steve Bartlett

Robert W wrote:
> To confirm my understanding from a reading of the User's Manual:
Bruce's examples of packing for outputs conveniently has devices with bit
combinations totalling 8; that is, one full byte. Nice and neat.
>
> But many of my signal heads have three lights - so, for example,   if SIG1 has
two heads of three lights each and SIG2 has one head of
three lights,
I need 9 output pins to accommodate those two devices.
>
> If SIG1 used pins 0-5 on OB(1), am I correct in understanding that I CANNOT
   write the pack code for SIG2 as "OB(1) = SIG2 * B6 OR OB(1)", because the
third bit for that device would not automatically carry over to the next
byte?

Instead, I'm assuming that I must move that device to an output byte where
there are at least three contiguous open pins, and leave the last two
pins on OB(1)
available for some device that only needs two pins.
>
> Do I have it right? Thanks in advance - Rob W
>

Rob:

You are correct that you could not use the "automatic" pack code you are
showing...but that doesn't mean that you have to have signals on byte
boundaries.  I use 3-4 wires for each signal (all signals have proceed,
caution, and stop -- some also have restricting) and have them back to
back, not worrying about where they fall.  When you go to pack/unpack
the node, do it 1 bit at a time, using whatever variables you need to
accommodate your signals arrangements.  All you lose is the "automatic"
part.  So, signal 1 can be byte 1, bits 1-6.  Signal 2 can be byte 1
bits 7-8 PLUS byte 2, bit 1.  All this does is make the pack/unpack
routines a little more difficult, but to me, it was well worth it
compared to buying enough boards to have each signal on a byte boundary.

There are many ways you could code this, depending on what exactly your
program later needs.  I'm sure I or someone can help you get started if
you tell us a little more about what language you are using (QBASIC???)
if you need it.

Jeff Warner

On 5/1/2010 4:05 PM, Robert W wrote:
>
> To confirm my understanding from a reading of the User's Manual:
> Bruce's examples of packing for outputs conveniently has devices with
> bit combinations totalling 8; that is, one full byte. Nice and neat.
>
> But many of my signal heads have three lights - so, for example, if
> SIG1 has two heads of three lights each and SIG2 has one head of three
> lights, I need 9 output pins to accommodate those two devices.
>
> If SIG1 used pins 0-5 on OB(1), am I correct in understanding that I
> CANNOT write the pack code for SIG2 as "OB(1) = SIG2 * B6 OR OB(1)",
> because the third bit for that device would not automatically carry
> over to the next byte? Instead, Im assuming that I must move that
> device to an output byte where there are at least three contiguous
> open pins, and leave the last two pins on OB(1) available for some
> device that only needs two pins.
>
> Do I have it right? Thanks in advance - Rob W
>
>


[Non-text portions of this message have been removed]

To confirm my understanding from a reading of the User's Manual:  Bruce's
examples of packing for outputs conveniently has devices with bit combinations
totalling 8; that is, one full byte. Nice and neat.

But many of my signal heads have three lights - so, for example, if SIG1 has two
heads of three lights each and SIG2 has one head of three lights, I need 9
output pins to accommodate those two devices.

If SIG1 used pins 0-5 on OB(1), am I correct in understanding that I CANNOT
write the pack code for SIG2 as "OB(1) = SIG2 * B6 OR OB(1)", because the third
bit for that device would not automatically carry over to the next byte?
Instead, Im assuming that I must move that device to an output byte where there
are at least three contiguous open pins, and leave the last two pins on OB(1)
available for some device that only needs two pins.

Do I have it right? Thanks in advance - Rob W

It looks like the diagrams didn't work well.  I will try and describe
the situation:

There are two main lines, lets call them track 1 and track 2.

There is also a siding called track 3.

Going in a East bound direction, first of all track 1 has a cross
over to track 2 (Operated by Switch lever 5).  Then track 3 joins
track 2 (Operated by Switch lever 3).  Then track 2 has a cross over
to track 1(Operated by Switch lever 1).

The signals on track 1 and Sig 2E and Sig 2W

My question is what are the signals on tracks 2 and 3?  Would they
normally be called Sig 4EA, Sig 4EB and Sig 4W; or would they be
called Sig 6EA, Sig 6EB and Sig 6W  ?


The explanation would have been helped if the track diagram had come
out as well as it looked in the preview.

Martyn


On May 1, 2010, at 9:13 AM, martynkellyphil wrote:

> Thanks to everyone who answered my question on code button
> operation.  I
> learnt a lot about fleeting, panel logic and panel operation.
> I now have a question about panel design.  I have a two track main
> line
> with a siding track joining under signal control.  Both before and
> after
> the siding switch there are cross overs between the main lines.  I
> have
> two options for labeling the signals and I would like to know which
> one
> is normally used in practice.  I am open to the possibility that
> neither
> of these may be correct !  My layout was originally the B&O.  I have
> tried to make drawings of the two options showing the track diagram,
> switch levers and signal levers, hopefully these work in this message
> format.
> Any insight anyone can give would be appreciated.
> Thanks
> Martyn
>
> OPTION A
>
> Sig
> 2W--------------------------------------------------------------------
> --\
> --Sig 2E       \ SW5                          /  SW1      Sig
> 6W--------------------------------------------------------------------
> --\
> --Sig 6EA                    / SW3------------------------------Sig
> 6EB
>
> SWL5  SWL3  SWL1
> SGL6             SGL2
>
>
> OPTION B
>
> Sig
> 2W--------------------------------------------------------------------
> --\
> --Sig 2E       \ SW5                          /  SW1      Sig
> 4W--------------------------------------------------------------------
> --\
> --Sig 4EA                    / SW3------------------------------Sig
> 4EB
>
> SWL5  SWL3  SWL1
>             SGL4   SGL2
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

I will be placing the order on Friday the 7th.  Must have received check
or PayPal payment by Friday.   Checks can be made out to Jay Beckham.
PayPal account is my email address.

Set of 3 24 pins boards (new style) for $25 including shipping.

--
Jay Beckham

http://www.CruisesOnTheSea.com (My Travel Agency)

http://mysouthshoreline.blogspot.com (Layout Blog)

http://photobucket.com/southshoreline (Layout Photos)

http://www.South-Shore-Line.com (Layout Web Site)



[Non-text portions of this message have been removed]

Serial cable - cable to connect serial port of computer to other device.
Various lengths are available.

A 10-year old machine will likely have one or more serial ports,
identifiable as 9-pin connectors with two rows of pins, 5 and 4.

You can also see the serial ports resident in such a machine in both the
bios configuration, and in Windows.  Tell us what flavor of Windows you
have, and it will be easier to tell you how to find out what Windows thinks
it has.

I'll let those with CMRI manuals or experience help you with the last part.

Blair Smith

Thanks to everyone who answered my question on code button operation.  I
learnt a lot about fleeting, panel logic and panel operation.
I now have a question about panel design.  I have a two track main line
with a siding track joining under signal control.  Both before and after
the siding switch there are cross overs between the main lines.  I have
two options for labeling the signals and I would like to know which one
is normally used in practice.  I am open to the possibility that neither
of these may be correct !  My layout was originally the B&O.  I have
tried to make drawings of the two options showing the track diagram,
switch levers and signal levers, hopefully these work in this message
format.
Any insight anyone can give would be appreciated.
Thanks
Martyn

OPTION A
                                                                       Sig
2W----------------------------------------------------------------------\
--Sig 2E       \ SW5                          /  SW1      Sig
6W----------------------------------------------------------------------\
--Sig 6EA                    / SW3------------------------------Sig 6EB

SWL5  SWL3  SWL1
SGL6             SGL2


OPTION B
                                                                       Sig
2W----------------------------------------------------------------------\
--Sig 2E       \ SW5                          /  SW1      Sig
4W----------------------------------------------------------------------\
--Sig 4EA                    / SW3------------------------------Sig 4EB

SWL5  SWL3  SWL1
             SGL4   SGL2




[Non-text portions of this message have been removed]

Thank John (Smith)



That information is very complete and sets my mind at rest.  I will start
wiring on Monday and see how it goes.



Regards



Bryan



From: CMRI_Users@yahoogroups.com [mailto:CMRI_Users@yahoogroups.com] On
Behalf Of John M. Smith
Sent: 01 May 2010 01:38 PM
To: CMRI_Users@yahoogroups.com
Subject: [CMRI_Users] Re: BLMA Signals





That's right, for common-anode signals.

The diodes will take about 2 volts of the 5 volt supply, and the resistor
will see the rest, around 3 volts. A 150 ohm resistor will set the current
near 0.02 amps, or 20 mA (0.02 = 3/150).

You can balance the brightness of the three LEDs by using higher resistance
values to reduce the brightness of some, as needed. The higher the
resistance, the dimmer the light. You can go as high as you wish with the
resistance, without damaging the LEDs.

Using resistors with less than 150 ohms would allow too much current in the
LEDs.

Best regards,
John

--- In CMRI_Users@yahoogroups.com <mailto:CMRI_Users%40yahoogroups.com> ,
"revolution.morris" <bryan.morris@...> wrote:
> ...
> What I understand from Dr Chubb's manual is that the Common wire is
connected to 5 volts and each of the Red, Green and Yellow wires goes to an
output pin of the DOUT32 card via a 150 ohm resistor (one for each color).





[Non-text portions of this message have been removed]

Hi Ralph,

Here are a couple of links that will help you:

http://en.wikipedia.org/wiki/Serial_port

http://en.wikipedia.org/wiki/Serial_cable

Chances are your computer will have the DB9 connections not the DB25 since it is
not that old.  They are the only connections on the computer that have male
plugs.

I found an old serial cable in a junk drawer at work and used that for the
connection to my SMINI.  I cut the male plug off and stripped the cable jacket
back to expose the individual wires.  I then used my VOM meter to identify which
wires correspond with the 2, 3, & 5 pin.  I used 3 connections of a 5 pin molex
terminal for the card end of my cable.  The diagram on page 4-27 of the User's
Manual shows how to hook up the cable to the converter.  It is a simple thing to
make (except for dealing with the crimping of the molex terminals!!!)

I use a small piece of CAT5 cable (with Molex connectors on each end) to connect
the converter card with my SMINI while on my test bench.  Once I have all of my
programming tidied up I will use a longer piece of CAT5 to connect with the
SMINI in its final (layout) location.

Hope this helps.

Cheers,

Hugh

--- In CMRI_Users@yahoogroups.com, "RSDCPA" <rsdcpa@...> wrote:
>
> OK, here goes.
>
> What is a serial cable? How do I identify the proper one? Where do I buy one?
Is there a special type I need? I ask this because I am supposed to get one to
go from my computer to the RS-232 485 converter. Correct?
>
> Which leads to my next question. What is a serial port? How can I identify it
on my computer to see if I have one. I think I do as this is a 10 yr old Compaq
486 machine.
>
> Finally what kind of cable do I need to buy to connect the 485 converter to
the SMINI and from there to a SUSIC upstairs and another SMINI downstairs? I
have some extra CAT 5 cable at my office. Can I use this?
>
> Thanks for filling in the blanks. I really am lost on this part of subject.
>
> Ralph
>

If you want to match each signal for intensity and best color, you can build a
simple resistor setup. take a 500 ohm pot and put 150 ohm resistor in series
with it IE connect to an outside leg of the pot. Attach one end to  ground and
the other to the signal led you are testing with the 5 Volts connected to the
common of the three led. Adjust the pot for color and intensity and measure the
after removing the test set resistance and see what the ideal resistance is for
that led. Then just match as close as possible to that measurement. You will
probably find that the 150 to 220 ohm range will be best. 330 ohms will give a
lot less intensity. Since most led drive at about 2.2 Volts the formula is (5-
2.2)/resistance = current through the load resistor and led. Caution be sure to
have the 150 ohms in series with the led and potentiometer else you can blow the
led. The max current would (5-2.2) / 150 . It should be noted that the 2.2 Volts
is about the average for a led. Some are 2.4 Volts or higher. Usually below 4 mA
and the led is too dim to see under normal lighting conditions. Test one led at
a time and DO NOT connect the other two leads to ground without the resistor in
place

Don
   ----- Original Message -----
   From: revolution.morris<mailto:bryan.morris@...>
   To: CMRI_Users@yahoogroups.com<mailto:CMRI_Users@yahoogroups.com>
   Sent: Saturday, May 01, 2010 2:57 AM
   Subject: [CMRI_Users] BLMA Signals



   I am now ready to instal signals on my layout using DOUT 32 cards. The card is
configured for current sinking. The signals are BLMA searchlight signals which
are three Leds in one case i.e. separate diodes for Red, Green and Yellow. On
the box it says 'wired in the common anode configuration' and the wires are
labelled with the common wire marked +. There is a caution on the box that the
voltage must not exceed 2.0 - 2.2 volts DC. There are no further installation
instructions and the BLMA website has no instructions that I can find.

   What I understand from Dr Chubb's manual is that the Common wire is connected
to 5 volts and each of the Red, Green and Yellow wires goes to an output pin of
the DOUT32 card via a 150 ohm resistor (one for each color).

   I don't want to blow an expensive signal so I would appreciate it if someone
can confirm that this is the correct hook-up and resistor value.

   Thanks and regards

   Bryan





[Non-text portions of this message have been removed]

Hi Ralph

To start check the back of the machine and look for a 9 pin male connector. This
will be the serial port. A 486 will probably have two of them. Next you need to
either find a female 9 pin cable (they were sold in about 6 foot lengths) at a
local computer store or flea market. Optionally you can buy the connector from
RS and make your own. PINS 2, 3 and 5 are needed to go to the RS323 converter
card. The numbers are marked on the casing as to the pins on this connectors.
Premade cable cut one end offand ohm the wires to find the 3 mentioned. The
opposite end you will solder a 3 pin Molex connector onto these 3 wires. Pins 2
and 3 are the outside wires and pin 5 is the center wire. User's manual has the
details. The Cat 5 cable can be used to make the 4 wire plus shield cables. Make
all the cables with 5 pin Molex connectors using two twisted pairs and the
shield. These are straight line cables meaning if you have a blue green pair,
then the same two wires are in the same position on both ends. Throughout the
entire nod connections this will not change when plugged into the SUSIC or SMINI
cards and onto the RS485 end of the conversion card. So from the computer you
have a short cable going to the conversion card. From the conversion card,  the
cable runs to each node connecting to the 5 pin connectors on the SMINI or SUSIC
card. You run them daisy chain to each node. Since the nodes are addressed, the
data is seen by the node you are talking to via the address. You can connect up
to 128 nodes within 4000 feet of cable length. The order you connect will depend
upon the computer location. I will assume the computer is upstairs by the CTC
machine. then you would go down the wall to the railroad room and connect the
next nearest node and so on. The last node is advised to make a plug with two
120 ohm resistors as terminators of the line. I advise getting one node
connected and testing it for proper communication with the node and computer
software and proceeding from there

Don
www.easeeinterfaces.com<http://www.easeeinterfaces.com/>





   From: RSDCPA<mailto:rsdcpa@...>
   To: CMRI_Users@yahoogroups.com<mailto:CMRI_Users@yahoogroups.com>
   Sent: Saturday, May 01, 2010 7:25 AM
   Subject: [CMRI_Users] Stupid question time



   OK, here goes.

   What is a serial cable? How do I identify the proper one? Where do I buy one?
Is there a special type I need? I ask this because I am supposed to get one to
go from my computer to the RS-232 485 converter. Correct?

   Which leads to my next question. What is a serial port? How can I identify it
on my computer to see if I have one. I think I do as this is a 10 yr old Compaq
486 machine.

   Finally what kind of cable do I need to buy to connect the 485 converter to
the SMINI and from there to a SUSIC upstairs and another SMINI downstairs? I
have some extra CAT 5 cable at my office. Can I use this?

   Thanks for filling in the blanks. I really am lost on this part of subject.

   Ralph





[Non-text portions of this message have been removed]