PLC Project for model railroad layout

The next step was to figure out a way for the PLC to change the switch. The remote switches are activated by a connection from track common to either Throughway or turnout. In my collection I have a lot of solid state relays, but experiments with them proved they will not work for switch throw. Once I connected a mechanical relay, the switch will operate.

The test setup uses two relays, one for throughway, one for turnout. They are connected in a way that both cannot be operated at the same time. The downside to this is it requires two outputs for each switch.

It is also not a good idea to maintain a constant contact to the switch wires. Once the switch is thrown and it activates the small switch inside, the motor will shut off, however if something jams the switch and it does not make the micro switch inside, the motor will continue to be powered and possibly burn up.

Later I will post the solution to this problem.

Mike

Hi Mike,

What are you planning on for hardware?  Relay or sourcing outputs? A relay output would be most versatile, you could use any voltage. They are generally good for around 2 amps.  Using 2 outputs would be easiest. Whats nice is being able to adjust the output pulse time with the logic. 

I was also planning on using a plc on my layout. Originally I was going to use a touchscreen for controlling my layout but after learning whats out there,  MTH and Lionel made it to easy. I still plan on using a Micrologix 1400 for running crossing gates and traffic lights. I have a surplus of this platform since we have switched to Control Logix.

Let me know if I can help you with programming.

I started this project last year and continued this year so I have gotten pretty far with the project and now just starting to post here about it. I am using relays and a Micrologix 1000 since the software for it is free. I also scavenged several HMI panels and later on I plan to use them, IF I can interface them to the PLC. They were originally used on Mitsubishi PLC's and may not have the communication ability for Micrologix. (I am not that far yet)

The HMI panels I have are Proface.

Mike

The next step is to incorporate block detection on the layout.  I have on hand several Omron IO blocks which were used as an interface between machine components. This provides isolation between machines but allows communication. This will provide isolation to the layout track and the PLC.

I used the accessory activator pack as block detection. By isolating one outer rail a train can be detected on a section of track even if track power is off.

I connected the 24volt power supply common to track common. The test track shows when the caboose enters the block, it activates the Omron relay (these are solid state relays)

Mike

The next step is to utilize this operator box. It has six lighted push buttons and an emergency stop. There is also an on-off switch on the side. I rewired it and added a terminal strip for experiments.

I also decided on how to handle the remote switches. My layout has three switches so I used a fourth relay as an "enable" this will use 4 PLC outputs total to control three switches. This will prevent a burnout of the switch in case it is jammed. Basically I select throughway or turnout on the switches, then turn on the enable relay for one second, then shut it off.

The next step is to map out the PLC inputs and outputs. attached is my diagram, the PDF file. I plan to utilize the emergency stop button in case something goes wrong and I need to shut everything down fast. It is never a good idea to use a PLC program for an emergency stop, or a safety circuit. I plan to use a PNOZ safety relay for that. What I accounted for is an input to the PLC to tell it that an emergency stop condition has occurred. I also planned to have an automatic and manual control of the layout, this is also an input to the PLC to indicate it.

I am also allowing for 2 pushbutton inputs, and the rest will be the Omron IO block for 16 block detection and/or optical sensors.

On the output side, I allocated two for pushbutton lights, and two alarm conditions, one a "soft" alarm, the other a "hard" alarm.

4 outputs are used for the track switches. Three are the switch itself using a single pole, double throw relay (throughway/turnout) and the fourth is an enable to connect the relays to track common to allow the switch change. After one second, this relay shuts off to prevent a switch burnout. I timer relay would be ideal, but I don't have one, so the one second enable will be software controlled.

The last four outputs are to control track power in four sections. I decided on the mainline, throughway, side track, and spur track.

The document also shows the alarm conditions. I made up a document which maps out all the PLC's data to keep track of it so as I develop the project and add routines, I can keep track of what data I used so there is not a conflict. This includes binary data, timers, integers, and so forth. I made the alarm code one binary data and split it up into bits. This way, later on when I integrate a HMI panel, it can read this binary data and display an actual alarm.

I forgot to add in the above post the automatic and manual mode. I am using a typical start-stop circuit except I used a second relay for the stop part since the pushbuttons are normally open and not normally closed. The second relay handles the stop part. This way I push one button to latch automatic mode, and the second button unlatches it for manual mode. This also sends an input back to the PLC to show the status. This way, in manual mode, the PLC will know not to do anything and it does not have control of the layout.

Once the wiring was done, I ran some tests with RSlogix and connected the operator panel to test automatic and manual mode. Red light is manual mode "Stop" and green is automatic mode "start"

The completed PLC interface is shown, the left terminal strip for the initial tests has the emergency stop and emergency reset jumped. These are connected to the PNOZ relay (yellow relay) which handles the safety circuit. Once an E-stop has been tripped, a button has to be pressed to reset it.  The PNOZ relay has track power and 24 volts ran through it. If this relay trips, it drops all track power and shuts down the relays.

The top row is the terminal strips with the IO and other interface.

Second row, the left two relays are the automatic and manual mode, the four thin white relays are the track switch control (three switches plus enable) The thicker orange relays are for track power, they are rated for a higher current then the white relays.  The yellow relay is the PNOZ safety relay, The green relay block is the input isolation to the PLC.

Bottom row is a terminal strip for 24 volts and common, then there are three fuses to protect the power supply in the event of a short circuit. The PLC unit and then a 5 amp 24 volt power supply with a small breaker for the 120v AC line.

You did a good job of controlling as much as you can with limited I/O.  I take it you are trying to accomplish what you want with the hardware you have available.

Moving up to modular plc like the 1100,1200 or 1400 will allow adding on additional 

I/O and still use Logix 500, not sure how much you can do with 500 lite.

Watch Ebay.  You could use logic instead of many of the relays. Modifying logic is much easier than hardware.

If you can find a 1400 you can use Ethernet instead of DH485 for communicating with your proface. Much easier.

Safety relays are generally used to reduce personal injury risk and not really necessary for protecting hardware.  They add complexity. 

A force guided relay tied to your Estop would make a good MCR.

Interesting! But I don't live in the world of PLC (programmable logic controllers) so I don't know all the acronyms. Please define these (at least once) for those of us who might not know them. What is MCR, HMI? That would help for those who want to follow along.

postwars posted:

You did a good job of controlling as much as you can with limited I/O.  I take it you are trying to accomplish what you want with the hardware you have available.

Moving up to modular plc like the 1100,1200 or 1400 will allow adding on additional 

I/O and still use Logix 500, not sure how much you can do with 500 lite.

Watch Ebay.  You could use logic instead of many of the relays. Modifying logic is much easier than hardware.

If you can find a 1400 you can use Ethernet instead of DH485 for communicating with your proface. Much easier.

Safety relays are generally used to reduce personal injury risk and not really necessary for protecting hardware.  They add complexity. 

A force guided relay tied to your Estop would make a good MCR.

I am using what I have on hand. So far I have been able to do what I need to with the RSlogix Lite,  I figure I still have a lot to learn with what I have, and in the future if I need more, I can upgrade.

I made the layout basically the same as my around the wall layout, with three switches, a side and spur. I hope when I have this completed, that I will use it to operate my around the wall layout. For that, I have enough I/O to do the job.

I am limited by the fact I cannot control the throttle, nor operate the bell and whistle buttons on the CW80.

Mike

Consolidated Leo posted:

Interesting! But I don't live in the world of PLC (programmable logic controllers) so I don't know all the acronyms. Please define these (at least once) for those of us who might not know them. What is MCR, HMI? That would help for those who want to follow along.

MCR = Machine control relay. Typically in an automation environment, a series of buttons are placed around the machine so in the event the machine jams, or some other event, a button can be pushed to cut the power and other sources of energy to a machine. (emergency stop) In my setup, the yellow relay is the safety relay, if I press the emergency stop button, it cuts off all track power and cuts the 24 volts to the external circuits. I admit, this is overkill and probably not needed as the worst thing that will happen is the trains will collide. Once I reset the emergency stop, power is not restored until I press a reset button.

HMI = Human Machine Interface. I attached a photo of a panel I plan to use and an image of a typical one. These are touchscreens that you program with virtual buttons, readouts, and so forth. It reads and writes the data bits in the PLC so I for example can program it to throw a switch by touching an image of the switch.  I can perhaps program an image of my layout and have it highlight the areas where trains are detected, show the status of the switches, etc.

In my above post, where I listed the inputs and outputs. below that is a series of alarm codes I made up. The reason I broke it down like that is for a future use of the HMI panel. The panel will read this data bit, and if a code is set (the data bit is non-zero) the panel's software can display an written alarm on the screen.

"No train detected on side!" as an example. I also have a tower light and audio box, which I have not shown yet.

I can also program virtual buttons, say for example I have a train running on the main, and another one is parked on the side track. I can make a button with a caption like "switch trains with side" and once I touch that button, the program will exchange the trains, pull out the one on the side track, and put the one running into the side track.

Mike

Just as an FYI, and it's been years ago, but I have heard both HMI and MMI (Man Machine Interface) used for describing the 'control panel' or 'computer screen' depending on the system and it's age. I'll add these to the list of acronyms linked below (that probably never gets viewed?). 

The next step was to add a signal tower and audible alarm. The light tower has three colors, Green, Yellow, and Red. I used Green for automatic mode, Yellow for manual mode, and Red for hard alarm. The Patlite can generate four audible alerts, but I am only using two of them. One for a soft alarm, the other a hard alarm.

What I mean by a "soft" alarm, is a condition where I want to unit to have an audible alert, but its not a condition that would shut down the layout. For my experimental code, I activate this soft alarm when the program executes, and stop it when it completes.

A hard alarm would be a condition where something has gone wrong and the program stops executing.

Mike

The next step is to make a control for the layout so I have the track power and remote switches in one place. I have 4 track power and 3 switches. I also want to allow for automatic or manual control, so a few relays were used to accomplish this. When the unit is in manual mode, the switches will work and I can control the layout from this panel. When automatic mode is enabled, control is handed off to the PLC and the switches are disconnected.

At this point enough hardware has been built to start coding. The first program I wrote will simply exchange the running train. There is one sitting on the side track, when the code executes, it will pull the train out of the siding, and put the running train into the siding. The program does check to see if there is a train waiting in the side track, if it is not there, it alarms out and the running train just keeps running. For these first test programs, I locked the locomotives in forward only. I don't have enough hardware built yet to detect forward and reverse moves.  If there is interest, I can post the program code.

https://youtu.be/PVNcV0xu_uA

I would be interested in seeing the PLC code. I have seen a few PLC systems (hardware), but never have seen any code. Would be neat just to look at.

These are a couple snips of a simple machine I made.

There are many different formats that can be used, this is ladder logic.

Whats nice is with logic you can program about anything you can dream up without any wiring.

There are instructions for about anything: Inputs, outputs, bits (virtual relays) timers, counters, math functions and dozens more.

I plan on using one for train detection, crossing gates, and traffic lights. MTH has made controlling the trains and switches to easy.

Scott

Here is the code for the first program. It is written in ladder logic

The throwing of the switches is integrated into the program and since the train only makes one loop to complete the change, the code was not too bad to write. Later, I ran into some problems with the next series of codes.

Mike

After wring that first program, I wanted to change things around and bring the train into the throughway first and stop it. I found that since the train would be making multiple loops before complete, it was screwing up the logic and any program I tried to write failed.

I figured out that to do a sequence such as exchanging the trains, there are specific steps that have to be done to complete the sequence, and it takes a variable time to complete it. I wrote this small program called a step test, which only allows certain rungs to be true until the step is complete, then it latches the step bit and the rung becomes false, and the next rung becomes true. This prevents, in a case, where a block detect is used in multiple rungs, for different reasons, to prevent multiple rungs from becoming true.

Attached also is my written sequence of the program I was trying to write.

The data bits in the rugs were set by hand, using Rslogix's online mode. This way I could test to make sure each step is done in the right order.

This solved that problem

The next thing I wanted to do was to make throwing the switches a subroutine so I don't have to have it multiple times in my ladder logic. I created a subroutine for it, and this is where my old programming days on computers conflicted with ladder logic. I found that you cannot have loops in ladder logic, and when I tried running this, the PLC would fault out for a watchdog timer. All the rungs have to be scanned in a certain time to prevent the fault, this is to prevent a case where the logic gets hung up. I even tried adjusting the watchdog timer, but no no avail.

I will post my solution to this problem.

Mike

mikeexplorer posted:

....I found that you cannot have loops in ladder logic, and when I tried running this, the PLC would fault out for a watchdog timer.

Well, you can loop but if you're trying to build a do loop or For-Nxt (like you would in computer code) yes, you can and will overrun the watchdog timer. What you may want to look at is indexed addressing. 

Say you want to build what amounts to "5" loops. Start first by programming a free running timer that counts 1-5 and then resets. This can be done with the CTU instruction, or ADD. You then take the accumulator register of the counter and use that as the WORD value in your binary address. The /xx bit extension remains unchanged.

Another way to approach this is already illustrated in your image 1119171635  above. Using MUL and EQU instructions, scan "1" process bit one logic, MUL by "2". Scan "2" process bit two logic, MUL by "2 and so forth. You use 16 scans to execute your complete logic.

mikeexplorer posted:

The next thing I wanted to do was to make throwing the switches a subroutine so I don't have to have it multiple times in my ladder logic. I created a subroutine for it, and this is where my old programming days on computers conflicted with ladder logic. I found that you cannot have loops in ladder logic, and when I tried running this, the PLC would fault out for a watchdog timer. All the rungs have to be scanned in a certain time to prevent the fault, this is to prevent a case where the logic gets hung up. I even tried adjusting the watchdog timer, but no no avail.

I will post my solution to this problem.

Mike

 

Not sure why you need a loop, the standard way to access a subroutine in RSLogix is the JSR instruction. When the scan hits the last rung of the subroutine, or alternately a RETURN instruction, the scan returns to the rung immediately following the JSR that called the subroutine. You can nest subroutines up to 8 deep if you want.  Sounds like you are using the JMP and LABEL instructions, that is the hard way, unless you are using them in conjunction with indexed addressing to do array math or something like that. 

How many switches do you have; I think the Micrologix 1000 supports 10 subroutines (program files 6 - 15)

I have three switches, That is an interesting idea to have a subroutine for each switch, instead of one routine for all three. That could simplify the code.

I did resolve it and still kept it as a subroutine. The main program will just keep jumping to it until the subroutine sets a done flag, then the next step is executed. The simple main program just tests it, quick video here too

https://youtu.be/oNSBGbYGMeo

Gilly@N&W posted:

mikeexplorer posted:

....I found that you cannot have loops in ladder logic, and when I tried running this, the PLC would fault out for a watchdog timer.

Well, you can loop but if you're trying to build a do loop or For-Nxt (like you would in computer code) yes, you can and will overrun the watchdog timer. What you may want to look at is indexed addressing. 

Say you want to build what amounts to "5" loops. Start first by programming a free running timer that counts 1-5 and then resets. This can be done with the CTU instruction, or ADD. You then take the accumulator register of the counter and use that as the WORD value in your binary address. The /xx bit extension remains unchanged.

Another way to approach this is already illustrated in your image 1119171635  above. Using MUL and EQU instructions, scan "1" process bit one logic, MUL by "2". Scan "2" process bit two logic, MUL by "2 and so forth. You use 16 scans to execute your complete logic.

The image you reference is a list of steps the program has to take to do the routine. I think I have an idea of what your talking about. Rather then use individual bits as step flags, I could use a counter for steps, and when a part of the logic is done, increment the counter so the next step becomes true and the current step becomes false.

Mike

postwars posted:

These are a couple snips of a simple machine I made.

There are many different formats that can be used, this is ladder logic.

Wow, that brings back memories! Did PLC programming on A-B PLC's in the early 1980's.

Good luck with the rest of the project. Has anybody turned you on to Arduino based systems? Lots of cheap boards, available code and cheap relays available. Won't be as reliable as the Allen Bradley stuff, though.

Jim Waterman posted:

postwars posted:

These are a couple snips of a simple machine I made.

There are many different formats that can be used, this is ladder logic.

Wow, that brings back memories! Did PLC programming on A-B PLC's in the early 1980's.

Good luck with the rest of the project. Has anybody turned you on to Arduino based systems? Lots of cheap boards, available code and cheap relays available. Won't be as reliable as the Allen Bradley stuff, though.

I looked into the Arduino systems available,  the prices are really reasonable, they would be a good source for hobby projects.

The companies I deal with are willing to pay for the extra reliability. Which is a bonus for me, I have an abundance of surplus hardware to choose from.

Now that I had resolved the problem with the switch throw routine and using bits for steps I finally made this third program. Watching it on the screen, the last few steps jumped ahead, which was weird. It ended up not switching the trains. Video here

https://youtu.be/PxAJ5BnBRFQ

Here is the code for that program. Discovered something weird, if I switched locomotives for the test, the program worked fine. Video attached.

https://youtu.be/s3cLbln2AtA

Placing the trains back in the position that caused the problem.  The blue & grey RS3 unit is a D&H, the Yellow grey ones are Erie Lackawanna. The issue is when the D&H unit is running the mainline, so I ran the program again and watched the inputs. The green relays to the left (16 of them) are the block detectors. Starting from the right is: main line, throughway, side track.

At about 22 seconds, you can see flicker in the throughway block detect as the D&H unit exits the throughway and passes through the switch.

https://www.youtube.com/watch?...amp;feature=youtu.be

This is what causes the program to jump ahead. This starts at rung 27, waiting for the throughway to clear, so it can energize the main to bring the train into the throughway, but what happens is run 29 becomes true too soon since the input flickers, causing it to jump ahead and throw the switches back to the side track and put the train that was in the mainline back into the side track instead of the throughway. (rung 32)

When the EL unit is in its place, the input does not flicker, and the program executes correctly. It could be dirty wheels or whatever so it brings up a point that some way, dirty track or wheels must be compensated for.

Mike

I have an around the wall layout, construction of it is here:

https://www.nepaview.com/the-w...t-counstruction.html

There are signals used on the layout and those too also showed flicker with the block detects. What I did to eliminate it on that layout was to add some small capacitors to the block detect to smooth out the block detect signal.

I connected up a few I had on hand for a test and then ordered the parts I needed and built a small board with the caps. This eliminated the flicker on the block detects and then the program ran flawless.

Watching the inputs with the modification:

https://youtu.be/6VrmZlA83gQ

Run of the program with the locomotives in position that caused the problem.

Now its all good

https://youtu.be/NvVFpYUZMp4

The next part of the project is to add in optical sensors. Part of this is to protect the switches from changing if a train is on it, and also to detect if the train is moving forward or reverse, since Lionel trains can do both. For all the test programs I did so far, I had the locomotives locked in forward.

It took some adjustment to get the sensors right, a pretty hard angle across the switch so it didn't see between cars. They are tied into the large block detect module, starting from the high end. The ultimate goal is to control my around the wall layout, so the input block will be a mix of block detect and optical sensors. The test layout still does not mimic my wall layout yet, I built this so far to do some programming before I replicate my layout.

These are all parts I salvaged from my previous job. They were scrapping machines and I was allowed to take parts home. This is why I am using these particular parts and some aspects may be impractical or expensive normally. These Omron sensors would run about $130 a set. Only the Allen-Bradley PLC is something I provided (The machines used Mitsubishi PLC's)

Thanks for posting your progress with the PLC stuff, I am still enjoying following along. Those look like some pretty nice little parts you have gotten there too. Interesting project!!

With optical sensors in place now around the switches, I made some changes to the program. Before when the train entered the block,  I had a timer to delay dropping power to the block to allow the train to enter the block and clear the switch. Now instead of the timers, it looks to see when the train clears the sensors so it knows it is clear of the switch and then shut down power.

I also updated my alarm code data to include the sensors, which is B3:20.

This will detect if a train is too long for the side or spur tracks, and also a mismatch (no train detected in block detect, but optical sensors are blocked)

I also made changes to the switch throw routine to check to make sure the train is clear of the switch before it throws them. Now in most cases not all the switches change so I built in a way to ignore switch sensors for switches that will not be changing. I attached the binary data sheet to illustrate.

If I plan to change switch 1, I set bit 0 and bit 4 in B3:21 to indicate switch 1 will be changing positions. This way if I have a running train on the layout and it happens to be passing by a switch that is not changing, it is ignored.

The program runs the same as before, so for this video I made the train run fast so it does not stop in the right location so its picked up by the sensors and alarms out

https://youtu.be/Hd-o2dHdzvo

Mike

In preparation to replicate my layout, I will need more block detection, so I have several extra sections of track, with some modification, I turned them into block detection sections by isolating one outer rail as done with the accessory activator pack, except this is cheaper.

Up to now, all the programs I wrote required that the locomotives are locked in forward only. Normally the locomotives cycle between forward - neutral - reverse - neutral and forward again. I have seen that some locomotives after power has been down for awhile (around 20 seconds) they revert back to forward as the next movement, where others hold to this sequence. So right there it tells me I can't just set a bit in memory to indicate what the next motion would be since some will revert back to forward.

Now that I have optical sensors protecting the switches, I can also now use them for sensing the trains direction. On my wall layout, I can drop the track power in the throughway, side track, and spur (which I have not built into my test layout yet) Any changing operations would use these sections. So I wrote a program to sense the direction of the train.

First run of the program, set motion to forward

https://youtu.be/1JJra3LM75A

Second run, set motion to reverse

https://youtu.be/3k-kBuGeiOc

Third run, no motion detection

https://youtu.be/9uVTHcHkuT4

Mike

This is a video of my around the wall layout, which includes a "cab view" by placing a video camera on top of the train. This will help show what my eventual plan is for this project.

https://youtu.be/kTBXt-uS2NI

Mike