A very common way to integrate your own I/O drivers is to use an FB interface inside of a library. A much better way, and much more convenient from the usability is the integration in form of a real I/O driver. This abroach should always been choosen when you decide to share your driver with others.
To implement an I/O driver in CODESYS you need mainly two things:
A device description
An FB, implementing the I/O driver interface
In the following you will find some general rules to follow while implementing your driver. Beside this guide, you should check out the different templates for different kinds of drivers to start from. Because in detail the implementation will be diffferent if you implement an SPI driver or you read a value from a sensor using a REST API.
But independent of the kind of driver, which you plan to implement. If you are not routined in writing such software, it is a good idea to prove the access of the hardware directly in an application.
Every device, which you can add to your CODESYS project, is described in an XML format inside of a Device Description.
For finetuning and to get a deeper understanding of the format, please check out the schema file. In the following we will just explain the basics to enable you to write your first description.
That the device can be uniquely identified in the device repository on every computer in the world, we need to maintain a few IDs. Please register the ID, which you will be using in the Device Database.
Device Type: Either use the matching one from the templates, or use XXXXXX.
VendorID: Use 0004, as this is reserved for all public domain drivers
moduletype: use 8000 + the DeviceID. This way you make sure, that you have no conflicts with other public domain drivers.
interface: For submodules, like SPI, I2C, or similar, use the interface from the template. For all others, you can use Common.PCI. This interface can be easily attached to most PLCs.
ConnectorID: simply enumerate the connectors within your modules. This ID is only used to specify the so called "host path"
Interfaces are symbolic names to match compatible connectors, so to find compatible devices or modules. We have some different concepts to configure our device tree in CODESYS.
You don't see anything in the device tree. But when you click on "Add Device" you get a list of all devices, which are providing an interface, that is compatible to the interfaces of the parent. The number of allowed devices which can be added to a variable connector can be varied.
Fix connectors are very similar to Variable connectors, but the devices are added implicitely and can't be changed.
<ConnectormoduleType="8023"interface="OpenSource:FixConnectorInterface"role="parent"explicit="false"connectorId="2"hostpath="1"><InterfaceNamename="local:internal">Internal</InterfaceName><Fixed><!-- This is an example of a fixed module specified in the same file --><Module><LocalModuleId>8023</LocalModuleId></Module><!-- This is an example of a fixed module specified by DeviceIdentification. The defininition of this module is in another *.devdesc.xml --><Module><DeviceIdentificationdeviceType="40107"deviceId="0001 bcde"version="126.96.36.199"/></Module></Fixed>
Slots are again similar to variable slots. But the user can see the slot in the device tree. Because every slot has a fix place in the tree, and because the user can plug and remove the devices, the specialty for the driver is, that there can be empty slots.
This was a huge preamble for an easy topic. But it was important that you get an idea of how the result will look like.
Interfaces are easy. You define one interface per child connector and one for every parent connector. There are no fix restrictions for the interface names. But it is an unofficial rule, that they should be prefixed with a short or full name of the vendor.
configuration parameters, which are inportant to initialize the I/O system
I/O channels, which can be mapped to variables
Both can be configured with the same structured datatypes.
They can be located globally on device level, then they are called DeviceParameters. If they are part of the device that the user adds to the tree, then, they are called HostParameters and attached to one of its connectors.
You can use virtually every datatype for a parameter, which can be used in IEC61131. This includes especially arrays and structures.
But you have to be aware that you need to define those datatypes consistently twice (in your driver library and your device description). There is no extra check. If they don't match between your device description and your code, it will just not work, crash, or whatever...
Basic datatypes don't need a declaration. They can be used with the namespace prefix "std". So "std:BOOL" is the equivalent of a BOOL datatype in IEC.