你可能想要的答案

实际情况已经改变为与之前的回答相反的情况。

WAGO最近的板级支持包和文档积极支持您对PLC200产品线进行更​​改和扩展。 特别是WAGO 750-8206和17（截至2016年3月）其他PLC：

wago.us – >产品 – >自动化元件 – >模块化WAGO-I / O-SYSTEM，IP 20（750/753系列）

您需要做的就是与他们联系，并要求他们为PLC200产品线提供最新的电路板支持包（BSP）。

我引用了前面的答案，并标记了这些变化，我的补充是粗体的 。

概要

• 你能破解一个PFC200并获得自定义的二进制文件执行？ 可能 绝对是的。 只要程序能够在Linux-3.6.11内核和glibc-2.16上运行，并为“armhf”API编译，任何现有的ARM应用程序，只要您也复制它所使用的库，就会运行甚至没有专门为PFC200编译。
• 这会容易还是快？ 没有 。 是的，如果你不担心Linux命令行。 使用板级支持包（BSP）提供的交叉编译器和提供的C库一样简单，然后运行它将程序传输到PFC的闪存并运行：

   scp your-program root @ PFC200：/ usr / bin ssh root @FC200 / usr / bin / your-program 

  当然，您可以使用Eclipse CDT和PFC200的交叉工具链，并将Eclipse配置为执行远程运行和调试。

• 未来会改变吗？ 也许。 请记住，PFC200在北美是相当新的。 它有，PFC200已于2014年9月出现

公共HOWTO Building FOR Wago描述了如何使用最初的BSP来运行FORTE，这是一个4DIAC的IEC 61499运行环境（link：sf.net/projects/fordiac），这是一个开放源代码的PLC环境，允许实现工业以供应商中立的方式控制解决方案。 4DIAC实施IEC 61499扩展IEC 61131-3，更好地支持控制器到控制器通信和动态重新配置。

如果您想直接访问KBUS（与I / O通信），则必须知道当前只有一个应用程序可以负责KBUS。

因此，CODESYS或FORTE或者您自己的KBUS应用程序都可以负责KBUS。

2015年的BSP有很多例子和演示如何使用PLC200的所有I / O（KBUS，CAN，MODBUS，PROFIBUS以及PFC200上的开关和LED）。 内核以及所有内核驱动程序和其他开源组件的源代码在板级支持包（BSP）中提供并编译。

但是，没有提供WAGO从头开发的，不基于GPL / Open Source代码的库和工具的源代码：这些源包括用于CANopen，PROFIBUS的应用设备接口（ADI）/设备抽象层（DAL）库-Slave和KBus（用于连接到主PLC单元的所有PLC I / O模块）

虽然CANopen使用标准的Linux Socketcan API与内核进行通信，并且可以使用提供的libsocketcan编写一个正常的套接字扫描程序，但是KBus API是一个WAGO特有的发明，在那里，你必须做一些逆向工程如果您不想使用WAGO的DAL来访问PLC的所有电气I / O，但是DAL已经形成文档，并且在BSP中提供了如何使用它的例子。

但是，如果使用CODESYS，则会有一个“codesys_lib_demo-0.1”示例库，显示如何为CODESYS提供一个库供使用。

过期的答案

这个答案在2014年和2015年的情况非常具体。截至2016年，它包含不正确的信息。 现在仍然要离开，以提供背景。

你可能不想要的快速答案

您可以非常合理地使用Codesys编写代码，将JSON数据包放在一起并将其发送到其他位置的服务器。 JSON只是文本，Codesys可以以非常类似于C的方式处理文本。使用Wago提供的附加库，Codesys内部可以使用许多以太网协议。

现在很长的答案

首先是一些背景

既然你对Wago和一般的Codesys的哲学来说似乎是一个新的历史，

Codesys被用来构建和部署硬实时执行环境，重要的是要理解，如果不充分理解其后果，可能会破坏整个系统的性能（使Codesys瘫痪并在程序中引发看门狗错误）。 请记住，许多PLC的控制设备，可以杀死一个人，如果它曾经坠毁。

Wago喜欢使用Linux为低级任务调度提供抢占式RT内核，然后配置Codesys以利用许多经常伴随Linux的标准C库。 Wago已经这样​​做了很长一段时间了，但是如果不经过Codesys（这意味着使用IEC 61131语言，其中不包括C ++），它们将永远不允许您剥离封面 ，这是为了您自己的安全他们的产品形象）。 如果你想在Wago上使用linux的强大功能，你必须得到一个完全裸露的操作系统的专用PLC，几乎没有任何手动或支持，并且放弃了整个Codesys运行时。

新的PFC200具有比最新型号更多的内存和内存，允许包含更多的标准linux 用户级堆栈 （ssh，ftp，http，…），而不会影响Codesys运行时间，并且他们做广告。 但是…他们仍然对编译工具和编译和链接到Codesys库或访问专用硬件（连接您的I / O模块的Wago KBUS）所需的头文件保持关注。

Synapsis

• 你能破解一个PFC200并获得自定义的二进制文件执行？ 可能是。
• 这会容易还是快？ 没有。
• 未来会改变吗？ 也许。 请记住，PFC200在北美是相当新的。

你可能不知道的事情

Codesys不一定知道或关心Wago。 您可以获得针对运行Linux操作系统的Intel处理器的Codesys的目标平台。 Codesys 支持访问外部库（反向通信是危险的），但他们通常期望C风格的接口，并且只能通过定义Codesys将要分析的C头来访问这些库，因此您可能需要做一些魔术让C ++无所不能。 你可以做的是创建一个C ++和Codesys访问的共享内存段，这就是他们如何传递信息（同步是另一个问题）。

你可以得到一个开放的 Wago PLC，在Linux上运行Codesys。 Wago的IPC是专门为此目的而制作的。 他们一般具有更多的权力，记忆力和沟通能力; 但是他们的成本要比典型的Wago PLC贵一倍以上。

如果你想玩弄Wago的想法，你需要拆开Codesys（它自己）的手册，Wago IPC的手册，并且已经熟悉了linux风格的进程间通信和/或动态库。

还有一个老的Wago PLC，它拥有750-8的裸机Linux。 它也有一个非常好的手册，介绍如何使用提供的头文件访问Wago硬件。

您必须首先了解Codesys希望如何与目标操作系统交谈。 然后，你向后工作，使之与位于该操作系统上的Wago特定的图书馆交谈。 你必须小心不要劫持Codesys。

你额外的C ++库应该可以帮助Codesys，而不是接管它。 例如，在同一设备上托管一个sqlite数据库，并使用C ++来管理数据库，并提供一个非常简单的接口，以便Codesys可以使用。 所有的Codesys都会调用一个函数并传递一些值，但是你的C ++实际上会建立一个SQL查询并将它发给数据库（Codesys不需要知道为什么或者怎么会发生这种情况）。

我希望至少有一段在某种程度上是有帮助的。