In the world of PLCs, you have to change your paradigm in several respects. First and most important thing to wrap your mind around is the fact that the PLC program is one continuous infinite loop. The program runs over and over again as fast as it can and never stops. Matter of fact, if something goes wrong and the program is unable to reach the end and start over, there will be a watchdog fault and it will shut down and turn off all the outputs. Each loop is called a PLC scan, or scan cycle, or logic scan cycle.

The next important thing to understand is that in between scan cycles is when the PLC reads the real physical inputs and copies the results to memory locations. Also, the PLC will look at the memory locations assigned to each output address and write that value to the hardware controlling those physical output points. I am generalizing here, there is a lot more going on between scans and the details can vary among different makes and models.

You can break your program up into subroutines and you can call them conditionally, but most PLC programmers would have reservations about conditional calls to routines that control real world outputs.

Most ladder logic that controls discrete output points uses what A/D software calls a "coil instruction". That instruction, when the preceding logic is true, will put a "1" in the memory location that ends up turning on the output and when the preceding logic is false, it will write a "0" to that memory location. This last point is sometimes lost on beginners. If you stop calling the subroutine that was controlling that memory location and it already contains a "1", then that output will stay on until the PLC scans some other instruction that changes it. The bottom line is that if you have two or more programs that control the same output points, they need to not only be mutually exclusive, but they must both be inclusive of all the affected outputs in order to avoid leaving some of them in an uncontrolled state.

In order to design a PLC program for a system with multiple different modes of operation, most folks will build that functionality into the design of how the data is laid out and how the instructions operate on that data rather than write completely separate programs that control the same output devices depending on which mode of operation the machine is set up for.

And the PLC code will be segmented in such a way as to make navigation easy and to divide the logical sections of the machinery up.

Personally, the only time I use conditional routines is for data manipulation (like sorting, or initializing a block of memory).

If you can describe what each of your cycles consists of (how many steps, are they all sequential steps, etc.) we can probably advise a way to lay out the code to avoid the pitfalls of conditional routines and help you get good results.

+1 @OkiePC (Customer)​ 

Hi @nanok66 (Customer)​,

The best practice to start programming a PLC is clearly defining the tasks. Here is a post that may help you out.

https://accautomation.ca/five-steps-to-plc-program-development/

This post comes from the following beginner's guide.

https://accautomation.ca/programming/plc-beginners-guide/

Once you understand the basic concepts of how the PLC is scanning and solving the logic then it is a matter of applying this to your particular hardware. It is best to think of the HMI as just an interface to the logic in the PLC. I would develop the PLC program basics first then add the HMI.

https://accautomation.ca/series/click-plc/

https://accautomation.ca/series/c-more-hmi-series-panel/

Regards,

Garry

https://accautomation.ca/