mikeexplorer

My Model Train Project

17 posts in this topic

This conversation was started in another topic and I did not want to hijack the topic so I copied the last reply. I have been trying to learn programming an Allen-Bradley PLC by making a model train layout and having the PLC control the layout. Attached is the program I wrote for the last working program I was able to complete for the layout but as I was progressing with this project, I started getting a sense that I am not doing this programming properly. Here is a video link of that program running.

 

 

Next reply is the reply from "PLCMentor"

 

MAIN AND SIDE INTERCHANGE.pdf

PLC IO.pdf

Share this post


Link to post
Share on other sites

This was the reply from "PLC Mentor" on that other thread:

 

Kinda on the verge of hijacking the thread, but I guess it is pertinent poop for someone learning programming. 

Took a quick look through your program and do have a couple immediate things that pop out:

  1.   I never use conditional JSR rungs or at least I cant remember a time that I found one helpful.  They are generally a way to get into trouble as all outputs stay in their last condition when you stop scanning the subroutine.  The mantra in PLC programming is "keep it simple."    This is a program just for you, but generally we are programming for the multitude of people that will follow us into the program after we are done.  That is very unique in PLC programming.  Generally in a plant environment the level of proficiency is fairly basic.  Also at 3am in the morning when a line is down, brain functionality is fairly basic.  Imagine the fun of seeing an output on in the program with all of the logic before that output false just because the program file is not being scanned at that time.  Minds have been blown with less.  In my experience, nothing good ever comes from a conditional subroutine.  If you want an output off then put a contact in the rung to make sure it is off.  Then the logic is clear and understandable to just about anyone.  I suspect that is why you have to reset your outputs with the masked move statement.  Another gotcha waiting to happen.

  2. I never use (or extremely rarely) the JMP instruction.  That is a fairly common statement for all high level languages.  Basic has its goto and just about every language has a statement to jump to a location in the program.  Most instructors I have learned from will explain the statement and its purpose and then tell you not to use it.  Those types of statements get you into trouble and are difficult to follow in most programming circumstances.  There is generally another way to do the same thing.  Same goes for MCP.  That has some value possibly in temporarily taking sections of code out of service for testing or maintenance.  As permanent fixtures they just cause confusion when people are troubleshooting.

  3. Rather than latches use seal in circuits.  Latches generally cause problems.  They are necessary if you need to maintain output status through a power failure.  OTE's are reset when the system comes up.  Same with the resets on your timers.  TON's reset automatically when the logic before them goes off.  Resets can be eliminated and everything that controls that timer's function then is on the rung with the timer.  Thats much easier to understand when looking at the rung functionality.  Side note: RTO's do have to be reset and are useful if the timer value has to be maintained such as for a total run time of a system that is starting and stopping.

  4. Even with the subroutines you have, I would move everything from file 2 except for JSR's to a subroutine.  Leave file 2 just for JSR or insignificant overhead logic such as blink timers or such.  That will make the logic much easier to go through.

  5. Looks like a fun project! 

Share this post


Link to post
Share on other sites

First, I want to thank you for your feedback. Although you are correct that this setup is "Just for me" my intention with doing this project is to learn how to do PLC programming. I do have roots in programming in high level languages on older 8 bit microcomputers and I think that has been an influence on how I am writing this project. As I was writing the routines for this project, I was getting a sense that my approach to programming the PLC isn't the right way to do it. This program I posted was that last one I had working "properly" The program worked well and the trains did what they were programmed to do, and any unusual condition was accounted for, as in when the train overshot and blocked the sensor.

I was working on the next routine, to park the train but I hit a wall with the program and could not get it to work properly, I basically hit a wall with it and then I realized that what I am doing is not going to work. I really need to step back and come at this from a whole new angle. Your feedback on using latch/unlatch, conditional JSR, and JMP statements makes sense. Trying to troubleshoot the routine I was writing and looking at the program online, I now see what you mean, I was seeing unexpected results even though the logic looked good. As you pointed out, I do have to do the masked move to the outputs to insure they are shut off because I used latches and unlatches in the code.

 

I decided to do the layout because I was thinking of it as a "machine" I wanted a real world example of a machine rather then the training units which have the buttons and toggle switches for the inputs. (I do have that, and used that for my initial programs) Even in the design of the hardware for this layout, I even included a safety relay with an emergency stop circuit. I wanted to include a safety circuit in this because all industrial machines need it to protect the person from harm. (in this case, no harm would ever happen other then the trains crashing into each other)

I do understand what you are saying about using the latches and unlatches which does make sense now. From reading a book I purchased on PLC programming sequence logic is used in programs and for this type of setup, I will have to use that, as there are steps to perform to complete a routine. That is the binary bits I am using for the steps and as each sequence is completed, it sets the bit so it can move on to the next step in the routine.

 

I actually only recently did the "traffic light" program because after I hit a wall with my project, I wanted to step back and go back to the basics, plus I also have purchased a C-More HMI panel and I wanted to improve my skills at programming the HMI. I also wrote a program for something we used to have in my old place of employment (the plant is now closed) We used argon gas for a metalization process and there was a PLC which was programmed by someone else (I never saw the code) what it would do is there would be two tanks of argon and the device monitored the pressure in the tanks, the first tank would be in use and when it ran empty, the unit would seamlessly switch to the other tank and then alert the user that the tank has run empty by blinking a light for that tank. Once the user replaced the empty tank with a full one, he would press the button and it would open a valve for a second to purge out the atmosphere from the line and the alarm would go out and that tank was ready for use. I successfully made that program and even did the HMI graphics for it. (It also allowed switching tanks by holding down both buttons for 5 seconds, the HMI does not allow that, so I have a third "button" to act as both buttons)

My ultimate goal is to learn how to program PLC's. Recently I was given a project where I work now to help prevent fires in the embossing process. A sheet of plastic is extruded on the line and as it travels down the line, in some cases the customer wants the surface embossed with a pattern. The sheet passes between heaters on both surfaces to soften it so the roller can emboss a pattern on the sheet. Fires have occurred for several reasons, one is if for any reason the sheet movement stops, the part of the sheet in the heaters melt and then catch on fire. Second is if the movement slows of if the operator is changing to a different thickness, the sheet might soften to the point of bowing down towards the bottom heater and then catching fire. I have successfully written the program for this project.

 

I guess I really need to step back and approach my model train layout from a different angle. What I have learned so far has helped me in writing these smaller programs, but it is clear what I am writing for the train project is "off the rails" (pun intended)

Share this post


Link to post
Share on other sites

Over the past week I have been thinking about the approach I have been taking for this project and done some research online. I have basically hit a wall with this project and the last program I was working on does not work and troubleshooting it has been a nightmare, and for reasons mentioned above  by the reply from "PLC Mentor"

From what I have been able to gather so far is the idea that I am using a binary set of data as steps in the program is probably ok, since the types of programs I am writing are done in a series of steps, a certain combination of inputs must be satisfied then the program can go on to the next step.

From what I have been reading, when it comes to the outputs, that there should only be one rung in the entire program that would allow energizing that output, and latching & unlatching that output is not a good idea. With the interchange program I posted above, in several of the steps, I do latch the output for say, throughway track power, then a few steps below it, I unlatch it. Once the step is complete in the rungs that have the output latched, those rungs go false so it should not latch it again. Then when the program gets to the step where it needs to de-energize the throughway track, it unlatches that output and stops the train. From the feedback I got so far, this is bad practice.

Now when an alarm condition occurs, I do latch the binary bit that is designated for the alarm code. (B3:20) which I figure is ok because I want the alarm flag to be set until there is action taken by the user to clear the alarm and then reset it. (clearing the alarm bits)

Breaking the program down into the steps it performs to interchange the trains this is the text of it

01- Wait for automatic mode & E-stop is clear
02- Energize main line track (This stays on while in automatic mode)
03- check to make sure trains are in throughway and side
04- Throw switches 1 and 2 to throughway (Ladder 6)
05- Reset counter
06- FWD-REV sequence Throughway to move train forward (Ladder 7)
07- Counter increments when train passes into block #5 (crossing flasher)
08- Count cycle up, pull train into throughway and stop it (Drop track power)
09- Throw switches 1 and 2 to Turnout (side track) (Ladder 6)
10- Reset counter
11- FWD-REV sequence side train to move forward (Ladder 7)
12- Counter increments when train passes into block #5 (crossing flasher)
13- counter up, pull train into side track and stop it (Drop track power)
14- Repeat sequence starting with step 4

So with the steps outlined above, there is interaction for the same outputs in several steps. Attached is the PLC Inputs & Outputs defined. This program will energize and de-energize the throughway and side track power as it proceeds.

I need some suggestions or some ideas on how I can properly write these programs as to have good code, I have used a training book by the "PLC Professor" and it has been very good, but the sample programs are shorter and don't illustrate the situation I am dealing with. Is there a resource or information I can find that can help me figure out a better way to do the programming for the model train layout? I still think the model train layout is a good idea and I do eventually want it to control my around the wall layout in my living room, this is why I made a mock-up of that exact layout so it conforms to the way that layout is designed.

I do realize there are some limitations to my current setup, since I have used all my inputs and outputs, as of now I have no way of sensing the switch's actual position, I just energize the switch throw routine for a half a second to throw the switches and hopefully the switch doesn't jam. There is also no analog I/O so there is no way to sense the throttle being applied to the track and no way to adjust it from the PLC. I do plan later on replacing this Micrologix 1000 with something else that is more "modern" is it is an outdated PLC, but it was an inexpensive way to get started. I am thinking of the Micro series since I will be able to add more I/O to it to have better control of the layout. That is down the road, right now I am faced with this problem and after reading what "PLC Mentor" said about the program, it does make a lot of sense that the way I am going about this is wrong.

 

I would very much appreciate any input or direction on designing and writing these programs better.

Mike

 

 

PLC IO.pdf

Share this post


Link to post
Share on other sites

Well I have to say that you get the planning stage much better than many coming to the PLC programming field.  I see experienced programmers that see no need for any planning document or specification.  I would assume that comes from your previous programming experience.  You have put together a basic plan for program operation and detailed your I/O.  In a real world project a detailed functional specification is recommended.  It takes time and effort and is not really completely necessary in full detail to successfully program, but it is necessary to successfully define to a client or user of a system how you as the programmer and designer of the system see the system working.  Many wrong directions can be figured out early with a good document.  Well.... if someone reads it - but that's a different discussion.  I put a video on youtube a couple years ago on this.  Wasn't real popular as people want to program not plan.  Here is a link:  https://www.youtube.com/watch?v=FedqCBDy-fU&t=33s

You should be able to find lots of information by googling seal-in circuit; however, we have an old article on ladder logic that shows one about half way into the article:

https://www.plcmentor.com/Articles/PLC-Tutorial

Essentially you "seal" around the start pushbutton to maintain the output.  Our article show the seal using a contact off of the output.  Generally with a motor seal in you use the AUX input from the motor starter as your seal.  I always use both the output and the AUX to seal in my motor circuits due to an experience with a faulty PLC5 I/O card that caused my inputs to cycle on and off for no reason.  Nothing like hearing every motor starter in the room cycling on and off together to make an impression. 

As for how to start attacking your program I generally look at it like this. 

  1. Each motor/valve or other defined equipment item is viewed as a module.  Define how each operates independent of anything else. Start/stop, alarming, auto/man, etc.
  2. Define sequences that run.  
  3. Tie the sequences into the motors/valves and other equipment modules.

Keep in mind with a controller like the micrologix, slc or even PLC5, AB makes it really easy to organize your data similar to how you organize your program files.  You can create bit files or integer files (and others of course) for specific purposes and have organized data as well as program files.  My general rule of thumb is not to use the generic default data files for anything other than extraneous data that just doesn't fit with anything else.  I always create data files to fit my program needs.  How you organize it is up to you.  Just do so!

The micrologix 1100 and 1400 are both great little processors.  They both have ethernet ports that can be used for programming and the 1100 can still be programmed with the Micro Starter Lite.  Also both allow online programming which is an essential tool in real world programming.  We dont take a system down to make small changes to the program in production systems.  Might as well practice that way also.

Hope this all helps.  Have fun!

 

1 person likes this

Share this post


Link to post
Share on other sites

I like the documentation that you did. To my way of thinking that's the heart of a good program and pre-planning is the soul. 

Quote

  I see experienced programmers that see no need for any planning document or specification.

Sad but true.

I start every program with a spreadsheet that has an IO sheet tab, remote IO sheets in tabs after that, transmitter list tab, Shutdown and Alarm list tab, and last, the cause and effect which is linked to the Shutdown and Alarm list. My programming world centers around the oil and gas business so my spreadsheet and programming layout is a function of that business. I probably get 75% or more of the program documentation from the IO sheet (copy, paste, import) and the Cause and Effect keeps on track for when an output is supposed to be off.

Share this post


Link to post
Share on other sites

The PLC IO document I posted is actually only one page of a complete document. The complete document is shown below. Whenever I plan to use a data type in the PLC I document what its being used for so I don't accidentally re-use it in a different routine or program. I also drew out a diagram of the track layout and all the PLC I/O on the layout.

I do understand the concept of seal in logic, the simple start-stop logic is a basic example of that and I do have a training manual that does illustrate that.

For any given routine, it is completed in a series of steps, as shown in the program I uploaded, as each step completes, I latch a bit to indicate it is complete and it is used as a condition on the following rungs to allow those rungs to become true. I think I see where I got into trouble and my programming went off the rails is it also forced me to use latches and unlatches on the outputs.  This I see now as bad programming practice as it caused unexpected results and made troubleshooting difficult.

What I am having trouble wrapping my head around is for a given routine, let me use my "Forward - Reverse" routine as an example, I explained it in the video I posted above about how the trains can act when track power is applied. Since I am using Lionel O scale trains, they can run in both forward and reverse direction. The video shows a good example of this and I used these two different locomotives because the smaller one will automatically revert to forward after track power has been off for so many seconds, where as the other locomotive will retain its forward-reverse sequence no matter how long track power is off.

I think what I need to do is focus on this routine and find a better way to write it before trying to re-do any of the other programs. This routine like many others for this project will depend on a set of sequences to complete a task. The conditions of the inputs and outputs depend on what "step" the program is in. (examples would be track power, and the optical sensors) The block detect would always have to be high (train sensed in that section of track) but it would be a needed condition because if the train were to not be sensed while it is running, that would be an alarm condition (say for example if the train derailed)

 

Now in my training manual there is a section on sequence logic, I took a picture from one of the pages showing a simple machine and a sequence for it to complete a task, in this case it is to load a part into a clamp, drill a hole, then eject it on the outfeed convener. I am wondering if this might be a better approach since from what I am reading about this, there would only be one "Output energize" rung needed, the conditions all have to be met in sequence for the output to turn on. In the example of my forward-reverse routine, track power on the throughway or side track is conditionally on depending on what step the program is in in getting the train to move forward or reverse direction as needed.

 

My goal is to learn how to program and apply it. I have been given a project at work to design a system to help prevent fires in the embossing section of the sheet line. The program is not complicated and does not require any sequence. It looks for certain conditions (sheet is moving, and photoeyes above the embossing heaters are clear of obstruction) If one of these conditions is detected, I do latch a bit on to create the alarm condition and the operator has to press a reset button to clear the condition once he checked the line. So even though I am at a roadblock with my model train project, what I have learned so far has allowed me to design this project. Another one I designed is for a process that requires bottled compressed gas, two tanks would be connected and the process draws on one of the tanks, when the tank runs empty, it switches to the other full tank automatically and alerts the operator that the empty tank needs to be changed and then a button is pressed to purge out the atmosphere and then the tank is considered ready for use. I also made an HMI screen for this as practice since I also want to include a HMI panel with my layout.

 

The video you posted is very good, I agree it is very important to document. I have made design changes and improvements to equipment before and I wrote documentation for both the operators and technicians so they know how to operate the changed equipment, and for the technicians to help troubleshoot, in the event of a problem.

Once this embosser project is more complete, I do plan to write up a complete document on how it works and what it does. (I used a Click PLC for this project)

 

Mike

 

BLANK PLC PROJECT.pdf

Track Diagram.jpg

Data files blank.pdf

Sequencer example.jpg

Share this post


Link to post
Share on other sites

Last year, I had to program a mechanism that would pick up an engine bearing, rotate it, and put it back down. It's a simple sequence with 3 pneumatic cylinders, 2 solenoid coils and 2 sensors per cylinder. I made a simple state diagram flow chart to illustrate the process so it was easier to follow and easier to code. Instead of using a bit for each state, I used an integer register. Each step's completion wrote the next step's value into that register. The value for each step is shown on the flow chart. The text inside the flow chart boxes tells me what state each solenoid valve output needs to be in during that step while the text on the arrows tells me what sensor condition triggers the next step.

Facer_07_UnloadRotatorSequence.pdf

Note that the flow chart shows how the system works in auto when everything works. I don't have great software for making flowcharts, so even making this was a pain. I didn't have time to add manual transitions and error conditions. Thankfully, I had just enough time with the machine before it went into the line to do some extensive simulation and testing to add code to handle errors and interruptions.

At the end of the sequence code, there's a rung controlling an intermediate bit for each output that has a branch for each step in the sequence. This bit is used later to control the PLC output, based on whether the mechanism is in auto or manual.

Here are the rungs for the first 2 steps in the sequence (wait for a part, then move down). The "BrgUnldRot_Posxx" bits are controlled elsewhere by looking at the cylinder sensors to determine which position the rotator is in. I use that information in another section of the code to make better transitions between manual and auto modes. I added a timer to each step, so I could slow it down during debug/development. It doesn't need time delays while actually running, so the timer presets are 0. They can be easily changed later if needed.

Sequence1.thumb.PNG.df03a60fd0b3e7736566

 

This rung controls the "auto down" bit, which is used later to control the actual PLC output:

Sequence2.thumb.PNG.fc936ad7cdbb0e797556

 

Here's the rung that actually controls the PLC output:

Sequence4.PNG.ebee4e4d12b05cd05e18a54542

Sequence3.PNG

Share this post


Link to post
Share on other sites

Sounds like you are heading in the right direction.  As for sequencers, I am not usually a fan.  As I am generally programming in ladder somewhat because it's easier for the techs to understand, the sequencer flies against this logic.  I prefer to use something like a counter to step through sequence steps and operate logic based on what step I'm in.  This works particularly well with each of my equipment pieces being a looked at as a module.  So i might activate a bit that is defined as step 1 when my counter accumulator is 1.  I will use that bit in my valve, pump or other equipment logic to activate required equipment when the equipment is running in automatic.  It's very easy to see what happens in that step 1 with a cross reference of the address.  In addition when someone is looking at a valve operation (for example), they can immediately see that it is active in step 1.  Finally it is very easy to see what cycles the system to the next step.  I think it's more clear than a sequencer.  This is all programming preference.  There are times when I have used the sequencer when the end user preferred it.  PLC programming is very much programming to your audience. Program in a way that works for the expected user. 

Share this post


Link to post
Share on other sites

Yeah I actually use the register method more than the counter method for keeping track of steps.  You see that Joe has each step 10 apart, ie,  10, 20, 30, etc.  Similar to the way we used to have to program in BASIC when you had to put line numbers.  That way you could insert lines without having to renumber your whole program.  The same applies in the code he has.  He can easily insert another step, say 15, without screwing up his whole numbering scheme.

1 person likes this

Share this post


Link to post
Share on other sites

I have been thinking about all this and the sample code posted above should be helpful. Although a model train layout is unusual and not practical for a PLC project, I still think it can be a good learning tool. In my first post the "Main and side interchange" routine was written in ladder 2, but the plan is to move it to a subroutine later on. I wrote it that way to test it and develop it.

My overall plan is ladder 2 won't do a whole lot, run any free running timers like blinkers and such and interact with the HMI panel. The train would just be running around the track and I plan to have a subroutine to do "something" One would be an interchange like I illustrated above. Input from the HMI would select that I want to interchange the running train with the one sitting on the side track. Another one would be to interchange with a train sitting on the spur track, this would work different since the train on the spur has to back out onto the main track, where the one sitting on the side track can simple run forward to get onto the main track.

I can see conditional jumps being an issue and I think I can eliminate them. As for latching and unlatching outputs I think the code posted above can be helpful in figuring a way to eliminate them. A register or a value in an integer would be a better way to sequence a program rather then latching bits.

Conditional subroutine calls I am not sure if I can eliminate them. Two routines come to mind, the first is my switch throw routine, during the interchange routine, the switches must be changed as the program is running. The limitations on the routine is the lack of inputs where I modified a solid state I/O card to read the LED in the switch and provide a 24 volt output to indicate the position the switch is in, but I do not have the inputs on the PLC for it at this time. So that is why I am using timers. I don't have a way to sense a jammed switch.

One unconditional subroutine would be my chatter routine which uses timers to debounce the inputs from input flicker. Ladder 2 would just always call this and the input bits are simply stored in a defined B3 data.

The forward-reverse routine is probably going to be the hardest to fix. Since these trains can run in forward and reverse and some trains will revert to forward on their own when they don't have track power for so many seconds, its not possible for the PLC to maintain memory bits of what forward-reverse sequence each locomotive is in. So it has to sense it by applying track power and seeing which optical sensor gets blocked. (sense its direction) Like higher level programming, I set bits to indicate which area of track I want to move the locomotive since this routine is needed in 4 areas (throughway, side, spur, main) so it is like passing variable data to it to select which region of track I want the train to move.

Perhaps in the end to do this project I can't write the program exactly as it should be written for proper programming practices due to the unusual nature of what the PLC is controlling, I don't want to abandon the project as the intent is to control my around the wall layout and this would be "just for me" I have learned quite a bit from doing this project

This is a project I am doing for work to help prevent embosser heater fires. Now the actual build I used a Click PLC, not a Micrologix, but I first wrote the program in RSlogix using the emulator (Click software does not have an emulation mode) So the first few rungs set up a simulated pulse train from an encoder wheel that I control with a binary bit to simulate the wheel turning or stopped. The only latches I use is when an alarm condition occurs, it is reset by a press of a button after the operator checks the line. Granted this program is pretty simple, but its a start and a project I can do for the company to improve machine safety.

 

Mike

 

 

 

 

 

EMBOSSER PROJECT ML1000.pdf

0214190952 (Medium).jpg

0218191700 (Medium).jpg

Embosser Project Click.pdf

Edited by mikeexplorer

Share this post


Link to post
Share on other sites

I would have used the Click branded power supply, there are only two models, one of which is only strong enough to power the plc, but the 

C0-01AC 1.3A is a whopping $39.50 and much smaller and looks nicer.

 
 

Share this post


Link to post
Share on other sites

This one is 2.5 amp output which is needed because it has to power 3 air valves plus the three photoelectric sensors.

Mike

 

Share this post


Link to post
Share on other sites

I was wondering how the full scale controllers work and I came across these when I googled "supervised railroad interconnect circuit": 

http://www.dot.state.mn.us/trafficeng/signals/worksheets/preemtionmanual2004.pdf

https://static.tti.tamu.edu/tti.tamu.edu/documents/1439-9.pdf

It might not be helpful or scale-able but I thought it was interesting, Starting around page 127 (first link) they get into calculating the amount of time it takes a vehicle to accelerate through an intersection after the signal starts to flash. I only skimmed it so there's probably more info (useful? Maybe. Maybe Not). The photo on page 50 of the first link is worth a look :)

The old school switchers are made up of simple relays and switches (very robustly constructed though) so definitely something a PLC could do.

Power supplies- If for some reason you find yourself needing a lot of DC power you can find used Astron power supplies online fairly cheap. Ham operators (NE5U) need a lot of 12VDC power , at least we think we do. I just picked up an Astron RS20A in what seems to be like new condition (I load tested it and it'll do the full 20A with no issues) for $50 including shipping. 12VDC / 20A . Powerwerx also sells power supplies but they'll set you back a bit:  https://powerwerx.com/power-supplies  I've been running their 30A supply for a few years.

1 person likes this

Share this post


Link to post
Share on other sites
23 hours ago, Michael Lloyd said:

Ham operators (NE5U) need a lot of 12VDC power , at least we think we do

LOL spoken like a true Ham op!

1 person likes this

Share this post


Link to post
Share on other sites
On 5/12/2019 at 11:10 PM, Michael Lloyd said:

Power supplies- If for some reason you find yourself needing a lot of DC power you can find used Astron power supplies online fairly cheap. Ham operators (NE5U) need a lot of 12VDC power , at least we think we do. I just picked up an Astron RS20A in what seems to be like new condition (I load tested it and it'll do the full 20A with no issues) for $50 including shipping. 12VDC / 20A . Powerwerx also sells power supplies but they'll set you back a bit:  https://powerwerx.com/power-supplies  I've been running their 30A supply for a few years.

They say life is to short for QRP :-2

1 person likes this

Share this post


Link to post
Share on other sites
On 5/12/2019 at 9:10 AM, Michael Lloyd said:

I was wondering how the full scale controllers work and I came across these when I googled "supervised railroad interconnect circuit": 

http://www.dot.state.mn.us/trafficeng/signals/worksheets/preemtionmanual2004.pdf

https://static.tti.tamu.edu/tti.tamu.edu/documents/1439-9.pdf

It might not be helpful or scale-able but I thought it was interesting, Starting around page 127 (first link) they get into calculating the amount of time it takes a vehicle to accelerate through an intersection after the signal starts to flash. I only skimmed it so there's probably more info (useful? Maybe. Maybe Not). The photo on page 50 of the first link is worth a look :)

The old school switchers are made up of simple relays and switches (very robustly constructed though) so definitely something a PLC could do.

Power supplies- If for some reason you find yourself needing a lot of DC power you can find used Astron power supplies online fairly cheap. Ham operators (NE5U) need a lot of 12VDC power , at least we think we do. I just picked up an Astron RS20A in what seems to be like new condition (I load tested it and it'll do the full 20A with no issues) for $50 including shipping. 12VDC / 20A . Powerwerx also sells power supplies but they'll set you back a bit:  https://powerwerx.com/power-supplies  I've been running their 30A supply for a few years.

 

In a town near me there is a railroad switching tower that has not been used in years, but it is amazingly intact. Normally they strip out anything of value when they are not used anymore but this one still has all the relay logic and electrical. The actual switches are disconnected from the track. A historical society is preserving it for tours.

I have integrated signals on my layout but they are not PLC controlled. they just act on the block detects as simple electrical circuits. It is the actual train movements that I am trying to do with the PLC controls. As shown above, they way I have been going about programming it is not the right way and I have hit a wall with it.

Mike

 

PA170118 (Medium).JPG

PA170123 (Medium).JPG

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now