I’m the new guy

I am just beginning my journey into plc programming and troubleshooting. I’ve downloaded the Logixpro simulator and I’m already stuck on the student exercise involving the door operation. I’m in desperate need of a mentor. Someone to go to for help, and that can point me in the right direction as far as what to study and train with. Thanks.

Neoabe.lincoln said:

I am just beginning my journey into plc programming and troubleshooting. I’ve downloaded the Logixpro simulator and I’m already stuck on the student exercise involving the door operation. I’m in desperate need of a mentor. Someone to go to for help, and that can point me in the right direction as far as what to study and train with. Thanks.

Click to expand...

Hi Neoabe. You're in a good place. Plenty of folks are more than happy to help.
What parts of the simulator have you done? Where are you stuck at? Can you post what you have so far with explanations on what you think it is doing?

here. Watch that series, especially the first 3-5 videos, over and over again until you understand and can recite @Ron Beaufort's narration before you hear it. Pay particular attention to three concepts:

1. The scan cycle.
   1. It's very simple: I/O scan; program scan; repeat.
   2. PLC programming is about time, and the scan cycle is the clock.
      1. This is the most important concept in PLC programming.
2. The order of evaluation of rungs in a program, of instructions on a rung, and of the branches in a set of parallel branches:
   1. Also very simple: left-to-right and top-to-bottom.
   2. This the second most important concept in PLC programming, because it is again about time
      1. i.e. when an instruction is evaluated relative to any other instruction.
3. @Ron Beaufort's model for describing what a PLC does:
   1. bits have values of 1 or 0;
   2. rungs are True or False;
   3. bits are in memory;
   4. any bit, even an "input" bit, can be changed during the program scan
   5. some bits are proxies for inputs or outputs.
      1. but those bit are in memory and are not the same as those inputs or outputs,
         1. the input bits are read (copied) from the physical inputs, and
         2. the output bits are written (copied) to the physical output,
         3. during the I/O scan, which usually is, and is generally treated as, synchronous (not simultaneous in time) with the program scan
      2. Note item 4 above.
   6. There are many such models ("current" flow, etc.), but this is the best.

here. Almost everything that uses ladder logic to implement relay logic in a PLC uses those patterns. I suggest memorizing them in the following order:

• Input Map pattern
  • Basic in => out rung
  • Note that the "contact" instruction (on the left) could be a Normally Open (-] [-) or a Normally Closed (-] [-) contact
    • Knowing when a bit has a value 0 can be as useful as knowing when it has a value of 1
  • I would argue that almost all ladder logic patterns reduce to this pattern, if we interpret compound atomic instructions as a single "input" contact producing a True or False rung state feeding the output contact
  • Another important point to note is that the output coil instruction is destructive: it always writes a new value
• Sealed in Coil pattern
  • Introduces the construct of a parallel branch as a logical OR.
  • Introduces the concept that previous scan cycles can influence the logic in the current scan cycle.
    • Note especially the time relationship between
      • the Seal-In branch contact instruction reading the output bit from the previous scan cycle,
      • and the output coil instruction writing the output bit for the current scan cycle.
  • Order of evaluation (see above) is important here i.e. the Seal-In branch contact is evaluated before (in time) the output coil instruction.
• State Coil/Fault Coil pattern
  • Introduces the construct of two instructions (or compound instructions) in series as a logical AND
• Start/Stop Circuit pattern
  • Very similar to the State Coil/Fault Coil pattern above
    • To understand the difference, pay particular attention to the discussion of Trigger-dominant vs. Stop-dominant
  • Reinforces the construct of two instructions (or compound instructions) in series as a logical AND.

The sealed-in patterns, particularly the Start/Stop and State Coil/Fault Coil (or a combination of the two), are the most common ladder logic circuits and you will use them over and over again. Because if all logic were the Input Map pattern (in => out), then everything could be implemented with a wire or a relay. But most logic to operate and control a process will be summat

• turn something on when (time) event A happens,
  • leave it on even after (time)event A ends,
• and don't turn it off until (time) event B happens,
  • leave it off, even after (time)event B ends,
    • assuming event A is not still current.

That is a description of the Start/Stop Circuit pattern; reversing the last two bullets converts it the State Coil/Fault Coil pattern.

Reducing each component of your process (e.g. the door exercise) to a model that fits one of those Ladder Logic patterns will almost always be the most efficient, successful, and maintainable way to write a PLC program that controls that process.




The only other thing you need to know is that the PLC cares not a whit what you want it to do, but it will mercilessly and inexorably do exactly what you tell it to do. So

1. If the PLC is doing something other than what you want it to do, then you told it to do that something other than what you want it to do,
   1. taking this as a presupposition when debugging will save you a ton of time
2. The entire trick to programming a PLC is to figure out to tell it to do exactly what you want it to do, for all possible input conditions on every scan cycle.
3. This is actually true universally in all computer programming, not just PLCs, so if you have successful experience programming you already know this.

this may not fit your post, but it will help you in the long run.

For any given homework assignment or task at work, you must consider these instructions as the customers specifications.
1. read the specifications several times.
2. write down your understanding of what you read in a step by step fashion.
3. review what you wrote down and see if it makes since, modify if necessary.
4. Get with the mechanical designer and discuss the project openly and honestly. When your opinions differ in regards to an operation, discuss it, don't ignore it.
there must be a reason for a difference of opinion. modify your instructions and i/o to accommodate the mechanical design if possible. Mechanical design may have to be changed due to plc programming limitations.
YOU BOTH MUST be in agreement on all points of operation before going to step 5. you may have to modify/rewrite step 2 and 3 based on the discussion.
5. step through your notes again this time, you are the one following the instructions. In other words, you are the plc. Write down on paper the events you are doing.
For example, turn on hydraulic motor 1, write down hydraulic motor 1 on. If a sensor is needed, write that down.
6. continue through the instructions. When you turn off the motor, mark a line thru it.
7. go through your instructions with all the sensors, motor aux. contacts, outputs documented. Modify if necessary.
8. repeat step 6 until no changes are made.
9. Try to group your data words into some organized fashion. The more programs you write, the more organized you become
10. write the plc program using your notes in a step by step manner.
10A Over half way through writing the program you WILL realize a different/better way of doing something you are almost done writing
(or a new spec will require it) and you will completely rewrite it
10B It WILL happen more than once.
Note: 10A and 10B added to list. thanks Aabeck, member plctalk.net forum



11. DOCUMENT EVERYTHING!!! You may remember things today, but in 5 years and hundreds of programs later, you won't
remember, especially at 2 am, so DOCUMENT EVERYTHING. use easy to understand tags and rung comments.
12. MAINTENANCE is your best friend and your worst enemy.
if you work with them and find out what they can do, write the program where they can trouble shoot the program. they will be able to fix the problem and everyone will be happy.
BUT
if you write the program to where you are the only one who understands what is going on, maintenance can't fix the issue, the machine is down, production is down,
management hears about it, your boss hears about it, then you hear about it - rewrite the program or else. you get calls all hours of the day and night.
this still holds true, a machine can cost a billion dollars, but it's not worth 10 cents if maintenance cannot trouble shoot the issue and fix the issue.
everyone has their own style of programming and you must develop your own way as well.
13. when the customer is in your shop and brings maintenance, discuss things with them, let them see your code, be open.
if they make suggestions, write them down, don't ignore them. their ideas may save you days of programming.
14. install the program and leave in program mode if possible so you can to debug your i/o
15. when writing your instruction manual(s), use your notes from step 9. Use easy to understand English language. specify the i/o, timers, counters, outputs when possible.
this will help maintenance even more to see what is going on.
16. Question for you, when is a machine and plc the most dangerous and why?
When it’s first powered on – when power is first applied to a machine, you don’t know how things are wired.
When you energize the plc outputs, you don’t know how they are wired.
When the plc is put into run mode the first time, it will do what you told it to do, NOT what you wanted it to do.


17. debug the program.
Remember, the program will always do what you told it to do, NOT what you wanted it to do.
18. IF you can ask a what if this happens type of question, YOU MUST have an answer, EVEN IF its a 1 in a million chance. that what if situation will happen in the first 30 minutes of production runoff in front of the customer.

regards,
james

Thanks James. Your reply was very comprehensive and instructional. Though I've yet to get used to the language of PLCs, and that will just take time, i grabbed almost all of what you said. Thanks again.

If anyone can point me in the direction of any other resources to aid me in self-learning, affordable resources, please feel free to pass them on. after looking at all of the formal education options, i have decided to give a go at it on my own. i have a technical mind and figure if it comes from books, "why cant i learn it for myself from that?" Thank you Brian T. Carcich.

Download a copy of PLCNext , CodeSys or some of the Bechhoff TWIN CAT tools they all allow simulators of "real" environment to be run, and you can built a real machine in virt.

For affordable resources, you cannot beat free versions of PLC IDEs with simulators.

Allen-Bradley has their RSLogix Micro Starter Lite with RSEmulate 500. Also CCW, but that has a Fisher-Price feel.

Siemens TIA has a trial mode, and I think they have a simulator with it. Their LOGO! line also has freebie IDE and simulator; it's okay for relay logic but awkward beyond that.

AutomationDirect's DoMore line has a freebie IDE with simulator.

There are others (Horner, etc.).

Contact and Coil has a great patterns of ladder logic write-up.


99% of your programs will involve these patterns when you are starting out. (and when you are a pro, for that matter) Go through each one and try to match them up with what you are trying to do.


Contact and Coil - Patterns of Ladder Logic

Neoabe.lincoln,

you are more than welcome.
keep in mind that maintenance works on the equipment you program.
they are not programmers, find out what they know and work with them.
train them on how the program works, be respectful, and they will bend over backwards to fix the issue. when they call, you know they have a problem.
if you say, here is the machine and walk away, it will never run !!!
good luck,
james

A Click PLC from Automation direct is an inexpensive way to get started. The software is free. They offer a simulator input module which has 8 switches on it to toggle inputs.

I agree with James, documentation is key for yourself when you have to re-visit, also important for others to decipher your code or understand how it works.
I would like to add a few things:
Simulators are great, however, some have limited ability or difficult to set up for a realtime simulation i.e. getting things to trigger as they would in a real application.
I tend to only use the simulator (or real PLC) without any configuration in the simulator i.e. do not use the real I/O.
The best way is to create seperate program blocks for mapping the I/O to & from internal bits but disable the call to those blocks so the real I/O does nothing. I use the mapped bits (internal relay contacts/coils) as the I/O then create a program that simulates the (sets/reads the mapped bits) this is called while testing & then either deleted or disabled & the mapped I/O enabled.
The simulation code does things like the real world I/O seeing or controlling the equipment for example:
Map the real i/O into internal bits like AND I0.0 = M0.0 (map it to an internal bit give them both a similar name (Tag or symbol)) like "PE01 Door Closed" as the real Input & "PE01 Door Closed_M" as the mapped bit & so on
The simulation code can use spare timers etc. to simulate the door opening & triggering the sensor.
for example
AND "Door Close Motor Run_M Start a timer, Timer up SET or equal "PE01 Door Closed_M" so in effect when you tell the door to close after a time delay the mapped I/O sensor comes on you can set the timers to approximate the time it would take to close the door in real life.
Originally, in my Siemens S5 days we used a program called Prosis, this simulated the real I/O on a PC that interfaced directly with the PLC, the simulation used two methods to simulate the I/O changing one was simple instructions like above the other for more complex operations used programs written in Pascal. Another was PICS this used ladder programs to simulate the above.

Here is a very simple bit of code that demonstrates how I often do simulations regardless if on a real PLC or simulator.
The idea is you create a mapping program to map the real inputs to internal bits, internal bits to outputs & use those in the program (so effectively the mapping block is not called during simulation), Then create your logic to do the control using the mapped bits.
Finally, create another program block that simulates the reations of the real I/O.
In simulation mode the call to the mapping block is disabled or not called & a call to the simulation block is used instead, the simulation uses the mapped bits to control how the outputs & inputs work in this case simple logic with timers so when the door is opened, the bottom limit is reset & after a time delay the top limit is set, on closing the door the opposite occurs. you can also simulate things like analogs, just do not call the analog blocks & use simple maths or increments to simulate the analogs increasing or falling in value.
As I stated, this was just a very simple idea to get you going without having loads of switches on the real I/O, if you have an HMI things like push buttons interlocks etc. can read/write the data rather than having to wire real buttons.