mikeexplorer

MrPLC Member
  • Content count

    27
  • Joined

  • Last visited

Community Reputation

2 Neutral

About mikeexplorer

  • Rank
    Sparky
  • Birthday October 20

Contact Methods

  • Website URL http://www.nepaview.com

Profile Information

  • Gender Male
  • Location Scranton,PA
  • Country United States
  1. My Model Train Project

      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  
  2. My Model Train Project

    This one is 2.5 amp output which is needed because it has to power 3 air valves plus the three photoelectric sensors. Mike  
  3. REQUIRED PROFACE HMI CABLE PINOUTS

    Here is the diagram for the tool cable for Proface. I have several proface HMI panels that I scavenged from my previous job as they were scrapping machines they let me take any parts I wanted. My intention was to use these for a PLC project but I never could get these to communicate with an Allen-Bradley PLC. I didn't build my own cables, I found on Ebay USB to Proface cables "GPW-CB03" for about $25 each. They worked well and was able to interface to the software. I just couldn't make heads or tails of the Proface software as it is an old version. I do know they support the PLC, but I just couldn't get it to talk to the PLC.  I do know these cables I bought work.   Mike   HardwareRefGuide.pdf
  4. My Model Train Project

    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 Embosser Project Click.pdf
  5. My Model Train Project

    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
  6. My Model Train Project

    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
  7. My Model Train Project

    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)
  8. My Model Train Project

    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! 
  9. My Model Train Project

    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
  10. Traffic Intersection with 3 second inductive sensor

    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  
  11. Traffic Intersection with 3 second inductive sensor

      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
  12. Traffic Intersection with 3 second inductive sensor

    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
  13. Power Distribution block

    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    
  14. Parallel conditions of Safety Relay Input

    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  
  15. PLC Programing Beginne

    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