Communicate with Codesys Program on a Linux-Based Wago Pfc200 Plc

Communicate with CoDeSys program on a Linux-based WAGO PFC200 PLC

The answer you might want

The actual situation has changed into the opposite of the previous answer.

WAGO's recent Board Support Packages and Documentation actively support you in making changes and extensions to the PLC200 line. Specifically the WAGO 750-8206 and 17 (as of March 2016) other PLCs :

wago.us -> Products -> Components for Automation -> Modular WAGO-I/O-SYSTEM, IP 20 (750/753 Series)

What you have to do is get in touch with them and ask for their latest Board Support Package (BSP) for the PLC200 line.

I quote from the previous answer and mark the changes, my additions are in bold.

Synopsis

• Could you hack a PFC200 and get custom binaries executed? Probably Absolutely yes. As long as the program is content to run on the Linux-3.6.11 kernel and glibc-2.16 and is compiled for the "armhf" API, any existing ARM application, provided you also copy the libraries it uses as well, will just run without even compiling it specifically for the PFC200.
• Would it be easy or quick? No. Yes, if you have no fear of the Linux Command line. It is as easy as using the Cross Compiler provided by the Board Support Package (BSP) with the provided C-libraries and then run this to transfer your program to the PFC's flash and run it:

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

  Of course, you can use Eclipse CDT with the Cross Toolchain for the PFC200 and configure Eclipse to do do remote run and debug.
• Will this change in the future? Maybe. Remember that PFC200 is fairly new in North America.It has, PFC200 has appeared in September 2014

The public HOWTO Building FORTE for Wago describes how to use the initial BSP to run FORTE, which is the IEC 61499 run-time environment of 4DIAC (link: sf.net/projects/fordiac ), an open source PLC environment allowing to implement industrial control solutions in a vendor neutral way. 4DIAC implements IEC 61499 extending IEC 61131-3 with better support for controller to controller communication and dynamic reconfiguration.

In case you want to access the KBUS (which talks to the I/Os) directly, you have to know that currently only one application can be in charge of KBUS.

So either CODESYS, or FORTE, or your own KBUS application can be in charge of the KBUS.

The BSP from 2015 has many examples and demos how to use all the I/O of the PLC200 (KBUS, CAN, MODBUS, PROFIBUS as well as the Switches and LEDs on the PFC200 directly). Sources for the kernel and with all kernel drivers and the other Open Source components is provided and compiled in the Board Support Package (BSP).

But, the sources for the libraries and tools developed from scratch by WAGO and are not based on GPL/Open Source code are not provided: These include the Application Device Interface(ADI)/Device Abstraction Layer(DAL) libraries which do CANopen, PROFIBUS-Slave and KBus (which is used all PLC I/O modules connected to the main PLC unit)

While CANopen is using the standard Linux Socketcan API to talk to the kernel and you could just write a normal socketcan program using the provided libsocketcan, the KBus API is an WAGO-specific invention and there, you'd have to do some reverse-engineering if you'd not want to use WAGO's DAL for accessing all the electrical I/O of the PLC, but the DAL is documented and examples how to use it are provided in the BSP.

If you use CODESYS however, there is an "codesys_lib_demo-0.1" example library which shows how to provide a library for CODESYS to use.

Track program change on WAGO PLC with CoDeSys

The variable declaration type should be VAR RETAIN PERSISTENT in your case. Variables declared under RETAIN only will lose their values (intentionally) with a program change.

I believe the builtin Codesys library SysLibProjectInfo.lib has what you are looking for with the function SysGetProjectID. If you store SysGetProjectID as a RETAIN PERSISTENT and then compare against it, you can track changes (or, this unique value may be exactly what you wanted in the first place, without manually creating an ID).

Note: Depending on how you declare your variables, changing the I/O configuration can have unexpected changes even on VAR RETAIN PERSISTENT variables (as all dynamically allocated addresses are shifted and may not point where they used to).

Compiling CoDeSys project using the command line

The Script Engine does support this:

Execute

start /b /wait "C:\Program Files (x86)\CODESYS V3.5 SP16\CODESYS\Common\CODESYS.exe" --profile="CODESYS V3.5 SP16" --runscript="build.py" --noUI

See https://help.codesys.com/webapp/_cds_commandline;product=codesys;version=3.5.16.0#option-runscript-execute-script

build.py

import scriptengine

project = projects.open(r"CodesysProject.project", primary = True)
application = project.active_application
application.generate_code()
messages = system.get_messages("97f48d64-a2a3-4856-b640-75c046e37ea9")
// check messages

See https://help.codesys.com/webapp/ScriptApplication;product=ScriptEngine;version=3.5.16.0

---

Related Topics