I tried to explain these two issues in a single article today.
First, let's state a conclusion: The first issue is the foundation for the second one; without solving the first problem, the second one cannot be accomplished.
To standardize PLC programming, an important prerequisite is to avoid using M and T in your programs. When implementing logic, do not use global variables like M and T for state transmission and function execution.
M and T are essentially global variables, commonly used as codes in German PLC systems. In Japanese systems, you might see D, H, etc., or pure tag-based programming where variables are user-defined strings. All are global variables and should be avoided.
If M and T are used in a program, that program can only be used for the current project with the current PLC module. It cannot be reused in future projects. Even if the functionality is exactly the same, you would still need to perform at least some conflict checks on variable usage. For three, four, or even a hundred projects, each time you need to create a new program from scratch rather than using an existing one, you'll need to check and debug, ensuring not to miss any details. Missing something will cause you trouble.
Therefore, the solution to both issues is the same: pain.
Because the pain becomes evident and uncomfortable, you must find ways to avoid this pain rather than enduring it indefinitely, even if it's tough.
About 3-4 years ago, I was advising a company where one of the engineers had resigned, and a new one hadn't been hired yet. A project he worked on, which had been operational for 1-2 years, encountered issues. The client reported that a particular function was not working, causing erratic behavior during automatic operation.
This type of equipment and its processes were traditional for the company. The main logic was based on a template I had developed for them years ago. Over the years, they've adapted this template for over a hundred devices. Hence, the engineers' capabilities were not in question; they wouldn't produce substandard work.
Due to the shortage of staff, the boss asked me to help out. The project was in a suburb of Tianjin. I bought a ticket to Tianjin, rented a car at the airport, and drove to the location.
Upon arriving, I learned about the specific function, the failure symptoms, and asked the lead technician if this function had been used before and if it worked well. He replied that since commissioning, other modes had been used, this function was never utilized until a recent change in production plan necessitated its use, revealing it didn't work.
I then asked if this function was verified during initial commissioning. The answer was, "It seems not."
I understood then. Since this wasn't a primary function, it might have been overlooked during debugging, leaving a bug due to variable use.
I opened the program, found the relevant blocks, traced the logic, checked cross-references of variables, and quickly identified a conflicting M variable. After fixing it and having the client test it, the issue was resolved within half an hour.
However, it was late, and the factory was in a remote area. They arranged accommodation for me, and I stayed overnight, flying back the next day.
Two days, nearly two thousand dollars for round-trip flights and car rental, just to fix an oversight with an M variable. That's pain.
Why did the previous engineer resign? Constant travel, dealing with similar issues non-stop. There's little time for a regular 9-to-5 job because the company's operation depends on you, yet there's no room for promotion, leading to years of repetitive work.
Who wouldn't feel the pain? If you still don't understand, let's continue.
Some might argue this is just a case of carelessness; if one were more diligent, testing every function thoroughly during debugging, such issues wouldn't occur.
I'd say this perspective is naive. Once a production system is running, there's pressure to keep production going, not to allow full-scale debugging. For auxiliary functions? Wait for conditions, which might take days or weeks. Normal project debugging takes about ten days; would you wait another ten?
Do impeccably careful people exist? Yes. The engineer's supervisor, my apprentice, is extremely meticulous. He reviews and double-checks everything multiple times for each project, ensuring stability. His projects rarely need revisiting, earning great trust from clients.
But at what cost? His wife often complains because he works late into the night for years, going gray prematurely.
Isn't this bitter, painful?
However, does the pain end here? No.
Many engineers might be in this situation, working for years hoping for salary increases, which should be reasonable.
From the boss's perspective, though, your contribution hasn't increased over the years while costs have, competition has intensified, and profits have shrunk. You've already had several raises, yet you demand more, possibly leading the boss to consider hiring a fresh graduate instead.
You might argue that new graduates lack experience, but remember, you started from the same place. Moreover, with mature processes now, top experience might not be as crucial.
If salary is your pain, the boss also feels pain over high salaries not matching contributions. If not addressed, the ultimate pain might be getting laid off.
To solve this, more than just reducing bugs is needed. The typical career path for relief is promotion. For most technical personnel, lacking in social skills can hinder management opportunities, so the only way is to increase efficiency.
For example, if you're a machinist increasing part production from 10 to 100 per hour with a better fixture, you're not just improving your efficiency but also that of others. This should naturally lead to salary increases.
For automation engineers, this efficiency comes from program standardization. Even for those aiming for management, creating a standardized system is key performance.
Standardization significantly reduces travel and increases efficiency, but many might not understand or be able to implement it. We're not talking about creating universal standards for PLC manufacturers but about engineers using PLCs as tools to create modular, reusable programs within their company or industry.
How standardized? To the point where assembly involves only simple, low-skill coupling, where even an electrician with minimal training could handle it after 30 minutes.
In an ideal scenario, once a process logic is mature, engineers don't need to travel for installation; on-site workers can install from design documents. The program runs reliably without further testing or debugging.
This is the ultimate goal. Before this, engineers might still travel occasionally, perhaps just to reassure clients used to month-long debugging, but these trips would be more like business trips with minimal pressure, taking only days instead of weeks or months.
An engineer who previously managed 5-6 projects a year could now handle 20-30 with reduced effort. If the boss doesn't raise your salary then, it's unreasonable.
Standardized programming isn't just an idea; it's simple: object-oriented. Those who understand already do.
However, standardization is an ability. I started exploring this over a decade ago but couldn't fully implement it until recent advancements in S7-1500 systems supported object-oriented programming better, allowing me to standardize even in S7-200 SMART.
Back at my previous job, another department tried standardization with S7-300, but without my capability or experience, they failed. I could only provide a sample project.
Last month, I checked in with a former colleague about their standardization effort. It was abandoned because no one used it.
This shows that capability and growth are paramount.
Standardized program architecture has been absent in the industry's 40-year history, so skepticism is common:
- Those who don't believe standardization in PLC programming is possible.
- Those who believe it's possible but doubt my ability or see no difference from traditional methods.
Challengers often demand proof, saying, "Show us an example program, or we won't believe you."
After this analysis, it should be clear that standardization is company-specific, not tied to PLC manufacturers. It's about engineering efficiency, workload, travel, and salary pain points not directly related to me.
Like the story's engineer who returned after two years, wanting to work again even with travel, but was coldly rejected because standardization had made such positions redundant. One engineer now suffices for similar projects, with electricians handling smaller ones.
The efficiency gain is evident, isn't it?