Looking back at your first computer programming course, most instructors are adamant about documentation, flowchart, as well as using different tools to design programs. Most programmers start at a young age; some began at age 15 to 18 years old.
Most young programmers thought that anyone could write a program and documentation is not needed. Just write it correctly, and everything is going to be okay. Young programmers as well as people who are new to this kind of work are too naive about making those assumptions. Software programming is rarely fixed. PLC training websites like https://onlineplcsupport.com and other online manual courses helped programmers have a better look at coding and documentation
A lot of customers usually, want something a little different like production numbers, average hourly cast off counts, the list goes on and on. Not to mention debugging is very difficult even without trying to guess the details with no documentation to explain the logic.
A lot of programmers have debugged a lot of programs throughout their working life. Some have proper documentation, making debugging very easy. Others are just awful, making the job very difficult. Listed below are ideas that can help spark a programmer’s creativity while documenting and writing the Programmable Logic Controller program.
The best way to start is by defining your codes. The outline of your systems consists of major program sections and what goes in them. It’s a rough pattern of how to lay out the subordinates or the stages, as well as define the main parts of your program.
Do not forget to lay out a strategy when checking errors in every section as well as shutdowns and alarming that needs to materialize. Correcting mistakes is one of the most ignored parts of any program. A good program needs to be checked for switches that will go out-of-range longer than they should.
It indirectly addresses, pointers that go out of their bounds, as well as monitoring all the analog signals to be validated. There’s much more that needs to go into error checking routine, but most of these examples should help young programmers consider the different types of things you need to include.
To know more about debugging, click here.
Programmers need to design a good map for the variable memory. When you are doing troubleshooting, it is necessary to have a proper guide for your layout. Instead of just assigning register for your memory, you want them to be thought-free, you have to plan simple ideas on how memory works for you.
You have to relate more to address the timer addresses as well as the counter addresses to your permanent address. It does not mean that they have to be the same, but C100 should go well with TO and the CTA100 should go well with V4100. Relating addresses make much more smooth troubleshooting because you can always remember all the relationship without looking it up.
A lot of software packages provide the use of tag names. You should make a descriptive tag name like “Unload.bit, Exhaust or Valve101.” By making descriptive tag names, it will tell you how the tag is used. “Bit” will tell you it is a distinct value on and off. “Unload” will tell the programmers that it is unloading all the valve tied to it.
The “Valve101” will tell you that part which the valve train you are referring to. And lastly, the “Exhaust” will tell you the tag name is part of the exhaust valve. With a Programmable Logic Controller that can support memory that can’t be typed like the DirectLOGIC line of Programmable Logics, it is important to take note that the location of the memory will contain: unsigned integer, floating point data, 16-bit BCD word, and whatever it is in the register.
If you are using the nickname tag to identify memory address, to import your Programmable Logic Controller program name tags into an HMI database, you know automatically knows which name tag needs to change with a different data type without confusion, regardless which kind of data is in PLC register.
Before you start the actual coding, you need to ask yourself a few questions to help you focus your thoughts writing your codes.
To know which programming language is used in PLC, visit https://en.wikipedia.org/wiki/Programmable_logic_controller.
Does it make sense?
Sure, you can indirectly address and save a lot of money as well as coding time, but what about software debugging? How much time will you need to do the debugging? Will the person keeping the machine understands what you will do?
Is this something you will understand under a year?
Unfortunately, the answer to this question is often “no.” If it is challenging to know this now, think of what it will be when you come back after you are away for a while. You need to take time to rewrite your codes that anyone can understand. You will thank me later when it’s installed and operational.
Is saving memory space and time that important?
You can write the elegant little piece of code that will take the lace of 100 rungs of the ladder. But just because you can do it, it does not mean that you should. If the memory space is not limited, the more undemanding approach should be better.
Writing PLC codes with your consumers in mind is a lot more difficult at the start. But if you do all the necessary steps, the payoff is much more significant, especially when your plant manager does not call you in the middle of the night because the machine is not working and no one can understand the code that you programmed.
Doing documentation is very important. Programmers should explain what their codes do in a broad and general way. It should be the priority of your program. Programmers should explain each partition do; hardware and program setup, startup, shutdown, input mapping, run, output mapping, alarming, etc.
The line comments should describe each line that does something distinctive. You need to document all the constants that you compare against. Knowing the “What,” “Why,” and “When” will help you commenting on the rung of ladders.
To make it easier to understand, you can’t have too many documentations. But you need to achieve a perfect balance between the time you invested and the readability. A lot of documentation is better than yours, and documenting every detail will make your job more comfortable in the future.