mikeexplorer

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 Data files blank.pdf

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

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)

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:   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. 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. 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. 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. Looks like a fun project! 

I do not wish to hijack this thread either, but I want to thank you for your feedback. If I were to start a new thread with this information, I would like some input in how I can do this project properly. Mike  

  Using subroutines is how I am doing my model train layout. The plan is the main program will do not much and look for input from the HMI or buttons and then call the needed routine to do what it is told. (such as interchange the main line train with the one on the side track) There are also routines that will be needed in several routines, one example would be to throw the switches to either the throughway or turnout depending on the data bits. Attached is a few of the subroutines (I did not include the forward-reverse one because it is large) These programs are sequence based, What I did was use a binary word (say B3:10) and as each step is completed I latch on the bit (B3:10/0) to indicate it is complete and to do the next step. For these subroutines, since I cannot have a loop, when it calls the subroutine, it will repeatedly call it until the subroutine sets its complete bit, then the program that called it will continue on to the next step) I can provide an example of a complete program if you would like to look it over. I would like feedback on my programming skills or is the way I am doing this not a good way to program. I uploaded it as "Main and Side interchange" I took a video of the program running here:       Mike   BLANK PLC PROJECT.pdf MAIN AND SIDE INTERCHANGE SIMPL.pdf

I have also been learning to program as well. My approach is a bit unusual as I built a model train layout and using the PLC to control the trains. I have had some success but have hit a roadblock with a routine I am trying to write. In the meantime I also picked up an inexpensive C-More HMI panel to start learning how to program and interface a HMI panel. I did recently went back to some basics and did my own version of the traffic light problem. There are several solutions to the problem, perhaps mine isn't the best one but it does work. I wanted a graphical display of the traffic light and have the HMI panel be able to interface with it. I can not only use the real inputs to go to automatic or manual control, but the HMI has soft buttons to do the same. The HMI can also change the cycle time of the traffic light system from 10 to 60 seconds total. This variable timer option may help in your solution to the problem. One other "back to basics" I did was write a routine that where a process needs a compressed gas. two tanks are attached where the system uses one tank until it is empty, then switches  to the other tank of gas and alerts the user the first tank has run out. Once the user replaces the empty tank with a full one, a button is pressed and a valve opens for one second to purge out the atmosphere so only the pure gas is in the system. We actually had a similar system at a former place I worked, so I thought it would be a good idea to replicate the system. I wrote the program two years ago, and recently re-wrote it from scratch. I not only wanted to add the HMI controls but I wanted to see how my skills changed as I learned more. Mike   Traffic Light.pdf

I found this online that could help you   https://library.e.abb.com/public/9e7ae3c8094341488549ef5a3e791064/ABB-1742-WPO_NEC_Tap_Rules.pdf In you case, #14 wire is rated for more then 10% of 50 amps so you would be good according to the rule. Mike    

As a general rule, all safety contacts must be in series. So all conditions must be met for control power to be activated. Attached is a schematic from a machine showing the daisy chain of Emergency stops along the machine, notice all are in series, the extra connections coming off each one goes back to a PLC as input so you can identify what part of the machine has its E-stop triggered. The condition is displayed on a HMI panel. The PLC only reads the condition. The control power is a relay that must be energized to allow operation. Nowadays, this is done with a safety relay that has forced contacts. Example of this is Pilz PNOZ type relays. This machine is older and only uses a standard mechanical relay. Mike  

This is what I used to get started, its a newer edition of the manual then the one I have. https://plc-euniversity.myshopify.com/products/the-complete-plclearn-series-with-the-micrologix-1000-controller At the time, you could purchase the training unit with a small ML 1000 PLC. They are discontinued now. I built my own, I found a cheap one on Ebay used and made my own. This manual I found to be excellent, you can download for free a ML 1000 simulator and simulate the PLC with no hardware.   Mike  

In my prior job the ferrite cores were used on one segment of the profibus where it connected to a DC sputtering power supply to prevent noise. It was standard with the OEM manufacturer to use these where the sputtering supply is located. I have found noise in profibus was caused by two things. One is the connectors, if the cable is damaged and the ground is not secure to the connector it would cause problems. Usually caused by improper installation. The wires have to be stripped perfectly to be installed in the connectors. I had a profibus cable stripper that removed the correct length of insulation to be installed in the DB9 connectors. I have also found noise problems in the cable in several machines where the cable was getting soaked by oil from the rotary vane vacuum pump and had discolored the cable. Since you said it is a long run of cable, I would inspect it for damage or if the cable is getting wet by any liquid. Mike  

I am hoping someone would look over the code I have written to see if I am doing it right. I use a lot of step sequence to write the program routines and I am not sure if this is the best way to go about this. Example program attached. Using a Binary data byte, as each sequence is completed, I set the next bit in the data byte so only a certain section of the program's rungs become true. Since I am writing these for a model railroad layout as a teaching tool, this may be the best way to go about it. When planning a program, I write down on paper all the steps needed to do an operation. Some parts of the program are subroutines. One is to throw the switches, the other I call  "forward - reverse" as I explained in my videos, these trains can run forward or reverse, so I pass data to it to tell it as example, train on the side track, run forward. The video of the main and side interchange shows this well. The train on the throughway track will maintain its forward - reverse sequence no matter how long track power is off (like an older Lionel train) where the one on the side track will revert to forward as its next move if track power is off for more then 10 seconds. I accomplish this by repeatedly jumping to the subroutine until it is finished with its operation (subroutine sets a flag when it completes its program) then I set the next sequence flag and the program moves on.   On a different note, my work might be paying off now as I was recently handed a project to do at work to help prevent a problem on the production line and the best way to do this is with a small PLC and program. My original plan was to use an Allen-Bradley Micro810 PLC, but I had problems installing the connected components workbench software package. Not sure how long this will take to resolve, I changed plans and decided to use a Koyo Click PLC. The software installed with no issues, but it does not allow simulation. So I wrote the program using the Rslogix Micro starter that I have been using, simulated it to make sure all my conditions are working properly, then wrote the logic using the Click software. I have to wait for the parts to arrive at the plant then I can hook up the Click unit and actually test it. In RSlogix, I created a pulse input by use of a timer and condition to simulate an encoder wheel. The project does not care about measuring speed from the encoder, it is only to detect if the product flow stops. STEP TEST.pdf

Hello everyone, my name is Mike and I thought I would introduce myself. I am new to the fourm board but in the past searching online for answers to my questions has lead me here several times, so I thought it would be better to register and become a member.   My project is probably going to seem unusual and not very practical to most. I used to do some computer programming back in the 1980's to 1990's, but only for home use. Over the course of the years with my job as a technician, first with a CD/DVD manufacturing facility, and now plastic sheet and products manufacturing, I have had to troubleshoot PLC's for years. I have had to work on several types, mainly to troubleshoot them and load the programs back into memory when needed. I wanted to learn how to do actual programming. I purchased a small training kit with an Allen-Bradley ML1000 which has six inputs and four outputs attached with several switches and lights. Seemed to go OK, but I wanted to do something more "real world" then just pushing buttons and such. At the time, the DVD plant was closing up and I was allowed to remove parts from the machines to take home since all was being scrapped. I do have a model train layout around the wall of my living room. Documented here, the video links are missing and I have to fix that.   https://www.nepaview.com/the-wall-mount-counstruction.html I thought perhaps a good real world example would be to control the layout using a PLC. I used the parts I was able to obtain from my prior job to build this, I found on Ebay the better Micrologix 1000 that has more I/O. I figured for now to stick with this since I already started using a training kit with Allen-Bradley. I did obtain some PLC modules which do have a few more I/O then the ML1000 does. I also obtained several Proface HMI panels, but have had no luck getting them to communicate to the PLC. I am only using the RSLogix Micro Starter software as it is still free to use. I posted my progress on my website here which also has a few video links for the programs I wrote so far. Since I am using the free software I am limited to the 1000 and 1100 series PLC's Since there is no analog I/O available for these, I cannot control the speeds of the trains. https://www.nepaview.com/model-train-plc-project.html If anyone wants to see any code I have written so far, I would appreciate any feedback on how I am doing. It has been a lot of trial and error so far, but its cool to see a program working and running the trains. I did also incorporate a safety circuit which for a model train layout would be not needed, but since PLC's are used in industrial controls, safety circuits are an integrated part of machines and I wanted to follow that idea in the design of the controls for the layout. Since I had no luck trying to get the Proface panels to work, I purchased a C-more panel since it was not very expensive and the software was free to download. I am having success with the communication with the PLC and the eventual plan is to utilize it to control my layout in my living room. I still have a long way to go to finishing this project, plus plenty to learn about programming, but it has been a good learning tool so far. Mike

Experimenting with finding ways to eliminate or compensate for the chatter on the inputs observed with the programs I wrote so far.      

RSLogix Micro Starter will work for that PLC. Part number is 9324-RLM0100ENE, Price is $151.00 You have to contact a local distributor to get a copy  

The latest program I wrote which runs endless. This will be one of the main routines the PLC will do. This is an early version with plans to expand on it. Video also explains about how the trains act as far as forward & reverse and even some improvements I made to the HMI display. https://youtu.be/PCPA4QjvoE0 main and side interchange simple.RSS

Have you had a chance to look at what I wrote? I am curious for someone to look at it and give me feedback as far as how I am doing so far. I have found the model railroad layout has worked very well as a "real world example" compared to a training unit with pushbuttons and switches. I have had other feedback that I incorporated a safety relay and circuit would seem silly since it is not an industrial control, but I also wanted to follow the principals of industrial controls to have a safety circuit, and that the PLC should NEVER be used as a safety circuit. It has come in useful if a program does not run as expected and two trains are about to collide, I just push the emergency stop button and all power to the track and outputs is cut. The only part that may not follow the standard is the NC contact of the PNOZ relay is tied to the first input of the PLC. It goes high when the safety circuit is not clear. It should probably be high when the safety is clear, but I didn't have a third NO contact on the PNOZ to use. I only use it so the PLC would know that the emergency stop circuit is not clear by seeing a high input. The parts I used to construct this came from machines in a prior job that were being scrapped and I was allowed to take parts off them as I wanted. So the design of this control basically followed what parts I have on hand. Mike  

How can I obtain a copy of the RSlogix that will work with the 1400 series? Is there a way to pay for it online? I heard it is download only software.    

I also recently purchased a C-More HMI panel and started making screens for the layout. These are rather crude as they are the first try to doing this.   Second test, motion detection Third test, showing the check to make sure switches are clear for change.   Mike        

Attached is the latest program I wrote.  The main program is only a test for the subroutines. To help understand it better I attached a diagram of the track layout and the PLC assignments. Originally I wrote the forward-reverse routine as a main program to figure out how to do it, but since I need this for 4 areas on the track, I thought it would be better to make it a subroutine and pass in a binary data which area I want to operate and the direction. I also made a few quick videos of the tests. The first video explains why I need this routine and why the PLC cannot have memory of the trains direction.   Second test   Mike     Data files IO.pdf FWD-REV subroutine test.RSS

The actual .RSS files or PDF's of the report?