学习PLC编程
如何学习PLC编程？ 不同品牌的PLC会有很大差异吗？ 梯形图编程和PLC编程一样吗？
How do I learn PLC programming? Would it differ greatly for different brands of PLCs? Is ladder programming the same as PLC programming?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
我做了很多 PLC 编程，现在也做了很多 .NET 编程。 无论哪种方式进行转换都是非常危险的，因为许多你认为应该可以转移的技能（模式等）会让你误入歧途。
我告诉人们的最大区别是，PC程序代码应该像其他程序员是观众一样编写，但是PLC程序（梯形图逻辑）必须像维护人员是观众一样编写。 大多数工厂（尤其是制造工厂）的维护人员经常直接连接到 PLC，在在线模式下，他们可以以图形方式观察代码的执行情况，以找出问题所在。
例如，如果输出未打开，他们会将输出电气设备 ID 输入到编程软件的查找功能中，找到该输出线圈，然后从那里开始追溯查找问题。 一些 PLC 程序员经常犯的错误之一是将他们的 I/O“映射”到一个结构中（在 PLC 中，这些称为用户定义类型），并且他们使用复制指令将所有输入或输出移动到立即结构。 从 PC 编程的角度来看这是有道理的，但它会让维护人员想杀了你。 通常，编程软件提供交叉引用功能，他们可以在其中指定输出线圈，并且它会告诉他们程序中的所有位置都使用了该线圈。 如果你使用复制指令将 10 个字的 I/O 移动到一个 10 个字的数据结构中，他必须坐在那里计算位，以找出复制源中的哪个位映射到目标端的哪个位。复制。 诚然，注释可以有所帮助，但也存在一个问题...PLC 存储整个程序，并允许您在紧急情况下从其中上传程序，如果您需要排除故障并且没有原始程序的副本。 问题是由于空间原因，PLC不存储注释。 因此，如果线路出现故障，每分钟的停机成本为 5000 美元，而一个人带着笔记本电脑跑到那里，他可能必须快速上传而不发表评论，并尝试排除故障。 将这些复制指令放在那里，浪费了他 10 分钟的时间，只是让公司损失了 50,000 美元的停机时间。 这些是编写PLC程序时必须注意的事项。
其他一些提示：一些 PLC 支持 FOR 循环。 永远不要使用它们。 出于与上述相同的原因，它们使维护人员很难对代码进行故障排除。 这是因为，如果 PLC 中的一段代码每次扫描都会被扫描多次（例如循环的内容），那么当您进入在线调试模式时，软件无法显示每个代码的值执行此扫描的 10 个循环，因此您实际上不知道您正在查看什么值。 然后，您必须编写所有这些棘手的代码，以将特定循环索引的循环值拉出到您可以监视的其他一些标签（变量）中。 这只是在紧急情况下解决问题的又一个障碍。 每次扫描多次使用子例程也会遇到同样的问题。
间接寻址（我们称之为数组）对于维护人员来说很难理解。 当您处理配方管理（存储和检索如何构建零件的值）时，通常可以使用它们，但您应该尽量在程序的控制部分中远离它们。
在PC编程中，我们当然寻求尽可能多地重用代码。 然而，在PLC和控制系统中，停机成本极其高昂，而且硬件也很昂贵。 内存很便宜，实际上PLC编程器也很便宜。 因此，预计如果您的机器上有 10 个相同的东西（例如传送带驱动器或其他东西），那么您将拥有 10 个不同的文件（子例程），每个驱动器一个，并且每个驱动器将具有与其关联的自己的变量：例如Drive1_Run、Drive2_Run、Drive3_Run 等。当您有 PC 编程背景时，这对您来说会感觉非常“错误”，但这都是因为我上面指出的几点。 当您处于停机状态时，有人说驱动器 3 无法工作，您可以打开笔记本电脑，转到驱动器 3 的文件，然后查看“运行”输出梯级。 当程序执行时，您可以从那里开始排除故障。 没有断点（程序永远不会停止）。
祝你的努力好运。 如果您想查看的话，我还写了一些我多年编程 PLC 的见解。
I did a lot of PLC programming, and now do quite a bit of .NET programming. It's very dangerous to make the switch either way, because a lot of the skills that you think should be transferrable (patterns and such) lead you very far astray.
The biggest difference that I tell people is that PC program code should be written as if other programmers are the audience, but PLC programs (ladder logic) must be written as if maintenance people are the audience. Maintainance in most facilities (particularly manufacturing) frequently connect directly to PLCs and in online mode they can watch the code execute graphically to figure out what's wrong.
For instance, if an output isn't turning on, they'll type the output electrical device ID into the find function of the programming software, find that output coil, and start tracing back from there looking for issues. One of the frequent mistakes that some PLC programmers make is to "map" their I/O into a structure (in PLCs, these are called user-defined types), and they use a copy instruction to move all the inputs or outputs over to the structure at once. Makes sense from a PC programming perspective, but it makes the maintenance person want to kill you. Typically the programming software provides a cross reference feature where they can specify that output coil, and it will tell them everywhere in the program that it's used. If you use a copy instruction to move 10 words of I/O into a 10 word data structure, he's got to sit there and count bits to figure out which bit in the source of the copy maps to which bit on the destination side of the copy. True, comments can help, but there's a problem with that too... PLCs store the whole program and allow you to upload the program from it in an emergency if you need to troubleshoot and you don't have a copy of the original program. The problem is that for space reasons, the PLC doesn't store the comments. So if the line is down, it's costing $5000 per minute in downtime, and a guy runs out there with a laptop, he might have to do a quick upload without comments and try to troubleshoot it. Having those copy instructions in there, wasting 10 minutes of his time, just cost the company $50,000 in downtime. These are the things you have to be aware of when writing PLC programs.
Some other tips: some PLCs have support for FOR loops. Never use them. For the same reason above, they make the code very difficult to troubleshoot for a maintenance person. This is because if you have one piece of code in the PLC that gets scanned more than once per scan (like the contents of a loop), then when you go into online debugging mode, the software can't show you the values for each of 10 loops that executed this scan, so you really have no idea what value you're looking at. Then you have to write all this tricky code to pull the loop values for a specific loop index out into some other tags (variables) that you can monitor. That's just one more impedance to fixing the problem in an emergency. Using a subroutine more than once per scan suffers from the same problem.
Indirect addressing (what we would call Arrays) are very difficult for maintenance people to understand. It's generally OK to use them when you're dealing with recipe management (storing and retrieving values for how to build your part) but you should try to stay away from it in the control part of the program.
In PC programming, of course we seek to re-use code as much as possible. However, in PLCs and control systems, downtime is extremely expensive, and hardware is expensive. Memory is cheap, and actually PLC programmers are cheap. Therefore, it's expected that if you have 10 identical things on your machine (like conveyor drives or something) that you will have 10 different files (subroutines), one for each drive, and each drive will have its own variables associated with them: e.g. Drive1_Run, Drive2_Run, Drive3_Run, etc. This is going to feel very "wrong" to you when you come from a PC programming background, but this is all because of the points I've made above. When you're in a downtime situation, and someone says that Drive 3 isn't working, you crack open the laptop, go to the file for Drive 3 and you look at the Run output rung. You start troubleshooting from there, while the program is executing. There's no breakpoints (the program never stops).
Good luck on your endeavors. I wrote up some more insights from my years of programming PLCs, if you want to check them out.
您可以从互联网上的各种来源学习 PLC 编程，其中之一是此（wikibooks） 或这个
您编写的程序将非常多除非您使用 PLC 特定功能，否则不同品牌的 PLC 的 LLD（梯形逻辑图）都是相同的。 但如果你使用像IL（指令表）这样的语言，就会有更多的差异。 但一旦编写好程序，不同品牌的存储和执行格式差异很大
梯形图逻辑是PLC的5种编程语言之一，其他语言是FBD（功能块图），ST（结构化文本，类似于Pascal编程）语言）、IL（指令表，类似于汇编语言）和SFC（顺序功能图）。 这些只是编程语言的各种表示形式，如果您愿意的话，也可以是各种风格。 但通常，某个品牌仅支持其中一种。 在美国，LLD 被广泛使用，而在欧洲，IL 更受欢迎。
You can learn PLC programming from various sources on the internet, one of which is this(wikibooks) or this
The program that you write will be pretty much the same across different brands of PLCs for LLDs (Ladder Logic Diagrams) unless you use PLC specific functions. But there will be much more differences if you use some language like IL (Instruction List). But once you have written the program, the format of storage and execution differs widely across brands
Ladder logic is one of the 5 programming languages for PLC, the others being FBD (Function block diagram), ST (Structured text, similar to the Pascal programming language), IL (Instruction list, similar to assembly language) and SFC (Sequential function chart). These are just various representations of the programming language, various flavours if you will. But usually, a given brand supports only one of these. In USA, LLDs are widely used, while in Europe, ILs are more popular.
梯形图（通常称为 LD）是 ISO 61131 自动化编程标准中定义的几种语言风格之一。 其他还有SFC（顺序流程图）、FBD（功能框图）、ST（结构化文本）和IL（指令表）。 IL类似于汇编程序，但很少有人使用它。 ST 是一种基于文本的编程，很像早期版本的 BASIC。 它也不常被使用。 LD 的设计类似于电气控制面板（许多 PLC 已取代）上的继电器触点。 FBD 看起来更像是一个电路图。 SFC 基本上是一个流程图。
有的PLC支持全部，有的只支持部分，甚至支持一种。 虽然 LD 最常见，但 FBD 和 SFC 也越来越受欢迎。
不同品牌使用的编程语言确实略有不同。 它们通常非常相似，一旦您了解一个品牌，您就可以使用它们中的任何一个，但您不能直接从一个 PLC 获取代码并在另一个品牌上使用。
Ladder, often call LD is one of several language styles defined in ISO 61131 automation programming standard. Others are SFC (sequential flow chart), FBD (functional block diagram), ST (structured text), and IL (instruction list). IL is similar to assembler and very few people use it. ST is a text based programming much like early versions of BASIC. It is not often used either. LD is designed to resemble relay contacts off an electrical control panel (which many PLC replaced). FBD looks more like a circuit diagram. SFC is basically a flow chart.
Some PLC support all, other only some, or even one. While LD is the most common, FBD and SFC are gain popularity.
Different brands do use slightly different programming languages. They are usually similar enough that once you understand one brand, you can work with any of them, but you cannot directly take code from one PLC and using on another brand.
到目前为止给出的答案非常符合目标。 我发现 PLC 在语言和设置方面存在人格分裂。 他们的核心设计是为电气人员提供一种为其整体设计设置控制逻辑的灵活方法。 PLC 基本上是一堆输入和一堆输出，它们的连接方式由加载到设备中的软件控制。
用于 PLC 的语言的重点之一是具有电气背景的人员可以使用它们。 因此，对于习惯高级语言甚至汇编语言的人来说，这些习惯用法和结构似乎违反直觉。 例如，梯形逻辑对于电气人员来说非常容易理解。
然而近年来，PLC 已支持多种语言以实现最大的灵活性。 然而，在我看来，我工作过的少数 PLC 在编程环境方面非常缺乏。 像将变量名称分配给内存位置这样的简单事情通常不会被设计到所使用的语言中。 那些易于工作的工作通常并不是最具成本效益的工作。
尽管存在这些缺陷，但它们非常适合简化复杂的电气系统。 如果你正在和别人一起做一个项目，你会发现你的编程知识会帮助项目解决棘手的程序。 我能够采用 100 个梯级的梯形逻辑程序并将其重写为三分之一的梯级。 一旦我能够学习梯形逻辑语言，我就能够实现各种优化，从而降低程序的复杂性。
一个提示是您需要了解闭锁。 有时您需要存储或保持一些输出，除非您有锁存器，否则结果将在下一个周期消失。 一旦你理解了这个问题，它就会变得清晰，但一开始这对我来说是一个很大的挫败感来源。
The answers given so far are pretty on target. One thing I found that PLCs have a split personality when it comes to their langauges and setup. Their core design is to give the electrical guys a flexible means of setting up control logic for their overall design. PLCs are basically a bunch of input and a bunch of outputs and how they are connected is controlled by the software you load into the device.
One of the emphasis of the languages that are used for PLCs is that they are accessible to people coming from an electrical background. So the idioms and structures seem counter intuitive for a person used to high level languages or even assembly languages. Ladder Logic for example is very accessible for electrical folks.
However in recent years PLCs have been supporting a multitude of languages for maximum flexibility. However in my opinion the handful of PLCs I worked are very lacking in terms of being a programming environment. Simple things like assigning variable names to memory location are often not designed into the language being used. The ones that are easy to work are often not the most cost effective for the job.
Despite these handicaps they are excellent for simplifying complex electrical systems. If you are working with others on a project, you will find that your knowledge of programming will help the project solve thorny programs. I was able to take a 100 rung ladder logic program and rewrite it into a third of the rungs. Once I was able to learn the ladder logic language I was able implement various optimizations that reduced the complexity of the program.
One tip is that you will need to learn about latching. Sometimes you will need to store or hold some output and unless you have a latch it the result will disappear the next cycle. Once you understand the issue it become clear but at first it was a great source of frustration for me.
PLC 编程应被视为 PLC 软件工程输出的实施活动，除非您将 PLC 纯粹用作机械或电气解决方案的替代组件的一部分。
以此为基础，PLC编程环境通常是IEC61131驱动的，有保证的循环时间，“抢占式”实时，无需处理实时操作系统相关问题，连续代码扫描，非程序指针，与典型计算机任务生成不同的概念一种多任务处理。 代码执行自然是原子的，不需要在任务之间使用监视器。
每种语言都有其与您的代码与您想要实现的逻辑模型的可想象性的接近程度。
梯形图有其电力潮流联锁方式的基本概念。 单个网络中的代码分辨率是水平或垂直扫描（您可以从制造商或其他站点找到有关此主题的资源）。 如果您的代码具有单一扫描分辨率性质并且位于一个网络内，则扫描类型可能会导致一些不可想象的行为（重要的是要记住，梯形图只是电路的模拟，它在执行中仍然是顺序的）。
FBD 或功能块图以前是电子信号流，但现在可以是数据流，具体取决于 PLC 的类型。 FBD在扫描顺序上显示出更清晰的执行顺序，与水平扫描梯形图非常相似。 如今，FBD 通常用作对象功能块的容器，尽管依赖性实现和过程模型的视觉相似性取决于 PLC 类型。
Literal 与 BASIC 非常相似，但只是语法； 执行仍然是扫描通过。 文字语言有利于数学计算。 对于高级实现，使用 Literal 可以更轻松地导出对象内的方法或属性。 使用类似英语的状态表示或常量的状态机编程使程序非常可读。
语句列表看起来与汇编助记符类似，但执行仍然是扫描，而不是程序指针。 它在位运算和括号式离散逻辑方面很强。 如果使用适当的结构和注释，它可能是一种非常高效的语言。
SFC 或顺序流程图是顺序实现的补充语言。 SFC 对动作块激活、状态转换、并行序列激活和合并有固有的规则。 然而，复杂的异常分支或并发操作管理会使实现变得复杂，流程图难以阅读。
PLC 系统管理的 IO 处理、通信、热备份是硬件配置工作，并且取决于产品。 一般来说，可以与软件工程分开对待。 然而，与PLC系统管理相关的数据是“定位”（独立数据寻址区域）类型的，软件工程中良好的数据建模方法有助于系统数据的可管理性。
PLC programming should be viewed as implementation activity of PLC software engineering output, unless you are using PLC as purely part of alternative components to mechanical or electrical solutions.
With this as basis, PLC programming environment is typically IEC61131 driven, gauranteed cycle time, "pre-emptive" realtime, no need to handle realtime OS related issues, continuous code scanning, non-program-pointer, different concept from typical computer task spawning kind of multi-tasking. Code execution is naturally atomic, no need to use monitors between tasks.
Each of the languages has its closeness to how conceivable is your code to the logic model you want to implement.
Ladder has its basic concept on electrical power flow interlocking style. Code resolution within single network is either horizontal or vertical scanning (your can find resource on this topic from manufacturer or other sites). If your code has single scan resolution nature and is within one network, some unconceivable behavior can be due to scanning type (important to remember that ladder is only emulation of electrical circuit, it is still sequential in execution).
FBD or function block diagram was electronic signal flow but today can be data flow depending on type of PLC. FBD shows clearer execution sequence quite similar to horizontal scanning ladder in scanning sequence. Today, FBD is typically used as container for object function blocks, although dependency implementation and visual similarity to process model is dependent on PLC type.
Literal is very similar to BASIC, but syntax only; execution is still scan-through. Literal language is good for mathematical calculation. For high level implementation, methods or derivation of attributes within object can be easier using Literal. State machine programming using English-like state representation or constants makes program very readable.
Statement list looks similar to assembly mnemonics but again execution is still scan-through and not program pointer. It is strong in bit operation and parenthesis-styled discrete logics. It can be a very efficient language to use with proper structuring and commenting.
SFC or sequential flow chart is a complementary language for sequence implementation. SFC has inherent rules on action block activation, state transitions, parellel sequence activation and merging. However, complex exception branching or concurrent action management can make implementation complicated and flow chart difficult to read.
PLC system management on IO handling, communication, hot-standby is hardware configuration effort, and is product dependent. Generally, can be treated separately from software engineering. However, data related to PLC system management are of "located" (independent data addressing area) type, good data modeling approach in software engineering can help in manageability of system data.
在线 PLC 模拟器可能很有用。
The Online PLC Simulator may be useful.
您可以使用结构化文本（ST），它由一系列指令组成，这些指令由高级语言（“IF..THEN..ELSE”）或循环（WHILE..DO）确定）可以执行。
我发现它比梯形图更好，因为它接近标准编程语言。
You can use Structured Text (ST) which consists of a series of instructions which, as determined in high level languages, ("IF..THEN..ELSE") or in loops (WHILE..DO) can be executed.
I find it better than Ladder as it is close to standard programming language.
我在大学学过一点PLC编程。 在我看来，它比组装低一级，但我们使用的设备不是最新的。
我相信您需要有一个 PLC 驱动程序，但我会首先寻找模拟器并在购买之前阅读更多相关信息。
I had a little of PLC programming on University. It seemed to me, to be a one level lower than assembly, but device we were using wasn't the newest one.
I belive you need to have a PLC driver, but I would first look for simulators and read more about it before buying.
Allen-Bradley 有一个免费的基于 dos 的软件 PLC，专门用于培训。 如果你访问他们的网站或谷歌，你可能会找到它。 它用于在学校教授 PLC 编程。
Allen-Bradley has a free dos based software PLC, specifically for training. You can probably find it if you go to their site, or Google it. It's used to teach PLC programming in schools.
对于尝试学习梯形逻辑的初学者来说，最好的方法是参加 http://plcs.net 上的免费在线培训
For a beginner trying to learn ladder logic, the best way is to attend free online training at http://plcs.net
PLC 是用于使用梯形逻辑的设备的术语。 使用更典型的编程语言进行编程的设备通常称为微控制器。 然而，我们中的一些人有时会将它们全部归入 PLC 名称下。 :-) 不确定梯形逻辑有多大变化，但微控制器代码可能会有很大变化。
PLC is the term used for the devices that use ladder logic. The devices that are programmed in more typical programming languages are generally called microcontrollers. However, there are some of us that on occasion lump them all under the PLC name. :-) Not sure how much ladder logic varies, but microcontroller code can vary significantly.