This document describes the EPICS device support for Koyo Direct Logic 205 PLCs connected to a serial port via the Message Passing Facility.
Other Koyo PLCs which provide a DirectNet slave port might also work, but these have not been explored.
If you are already familiar with the directNetBug support application, the main differences you should be aware of are documented in these sections:
Release 1-0 of the software has been built with EPICS base R3.13.5, although it should build with R3.13.2 and possibly against earlier versions too. It was designed for MPF 1-7 and mpfSerial 1-3, although some earlier versions may work as well.
This software can act as a DirectNet Master through any mpfSerial RS232 port. It should be possible to drive several PLCs from a single RS422 line through a suitable RS232/RS422 converter, but this configuration has not been tested. See the DirectNet documentation for information on network design considerations. To achieve the highest data throughput between the IOC and more than one PLC it is recommended that a separate serial line be used for each PLC, rather than connecting multiple PLCs through the same line.
The standard cables sold to connect the DL250 CPU up to a PC can be used, although a Male-Male gender changer may be needed depending on the wiring to your OctalSerial RS232 module (with the APS IP8E 100 connection module a this is the case).
The PLC must be configured to use the DirectNet protocol on the port to which MPF is to be connected; communication will not be established otherwise. The serial format for Port 1 of the DL250 CPU is fixed (by the PLC) to be 9600 baud, 8 bits, odd parity, although the format of the second serial port can be modified as required. The serial format used by MPF is defined in the startup file st.cmd.
For safety reasons, the device support only allows the IOC to write to a 512 word = 1024 byte region of the PLC's address map, locations V2000 to V2777. The IOC can only change a PLC output if the PLC is scanning a ladder logic program to validate the data in this area and copy it to the hardware outputs desired. There is no equivalent restriction on reading any location in the PLC memory map, thus digital inputs can be addressed directly by binary input records and so on.
The PLC program must communicate with the IOC in binary, which may require additional programming steps as the PLC arithmetic is generally performed with BCD numbers. This software does not support conversions to or from BCD.
Some ladder logic code is required to support the reading of ADC inputs by the IOC - see the DL205 Analog I/O Modules manual for details. If the ADC readings are just for communication to the IOC then it is recommended that the multiplexing method be used, without the BCD conversion rung; the pointer method performs automatic conversion to BCD and would need extra rungs to convert the readings back to binary for use by the IOC.
This software is a new-style support application available in the APS iocapps CVS respository at support/directNetMpf. The file revisions needed have been tagged with the CVS tag R1-0. Installation is in two parts:
This release should be installed in <support>/directNetMpf/1-0. The instructions in this section will have to be carried out by the operations manager before the software can be correctly used within IOC applications. The first step is replaced by extracting the software from the tar file if it is used elsewhere. To install the software at APS:
% cd /usr/local/iocapps/R3.13.5/support % cvs export -r R1-0 -d directNetMpf/1-0 support/directNetMpf
% cd directNetMpf/1-0/config % vi RELEASE
% cd .. % gnumake
An IOC applications developer who needs to use this DirectNet device support must make the following changes to the application concerned:
DIRECTNET_MPF=$(SUPPORT)/directNetMpf/1-0
include "devDnMpf.dbd"
LIBOBJS += $(DIRECTNET_MPF_BIN)/devDnMpf
startDirectNetServer("server", "portname", 50)
createDnMpfPLC("PLCname", ID, "server", location)
The device type (DTYP) field of a PLC record should be set to "DirectNet PLC via MPF". The basic INP or OUT record hardware address is an Instrument I/O type and comprises a string which starts with an @ character followed by the name of the PLC being addressed. This name must have been registered with the IOC using createDnMpfPLC in the startup file. Note that although the name may contain spaces this is not recommended, and that upper case letters are regarded as different to lower case in the name.
The name must be followed by a space, and the remaining string is examined by the device support for the corresponding address within the PLC. This address can be specified in the same way it would be given to the PLC programming software DirectSoft. The following table details the address types available. Note that just as when programming the PLC, all addresses and bit numbers must be given in octal, a leading zero being unnecessary (this address format is identical to that used by the directNetBug driver).
Address Range Description Size X0 - X777 Input point Bit Y0 - Y777 Output point Bit C0 - C1777 Control relay Bit SP0 - SP777 Special relay Bit T0 - T377 Timer status bit Bit TA0 - TA377 Timer current value Word CT0 - CT177 Counter status bit Bit CTA0 - CTA177 Counter current value Word V0 - V41237 Data word Word B0.0 - B41237.15 Bit of data word Bit S0 - S1777 Stage bit Bit
Device support is split into two separate modules, input records and output records.
All input records share a common read data cache, to reduce the amount of DirectNet traffic which could otherwise be generated by multiple reads of the same or nearby locations. When an input record is processed and the device support layer is asked to read the hardware, the data currently in the cache for the relevent location is examined. The scan period of the record is compared to the age of the cached data. If the cache data is old (ie was received more than half a scan period ago) then a read request is sent to the PLC for new data, but otherwise the cache data is returned immediately.
Up to 16 words (32 bytes) will be read from the PLC from each request, so if any nearby locations are used then these data may be collected as well. Note that this cache size is larger than the 6 word/12 byte limit of the directNetBug support, thus the definition of "nearby" is different and the grouping of particular I/O locations will change. A record which has SCAN="I/O Intr" will be processed automatically whenever new data is available as a result of read requests made by other records (at least one record in the "local group" must get processed for this to work though).
Support is provided for the following input record types:
Reads from a single bit at the given hardware address.
Reads up to 16 bits at the given hardware address. The bit pattern cannot cross a 16-bit word boundary, but may start anywhere within the PLC data word. This restriction applies to the bit address types too; for example an input address of X17 (octal = 15 decimal) should not be specified with NOBT=2. The current implementation will silently return zero for all bits beyond the MSB of the word addressed.
As mbbi.
Reads a whole word from the given memory location. Any bit offsets in the hardware address will be silently ignored. The use of input conversions (LINR="LINEAR" etc.) is not recommended until a means of specifying the data width has been implemented. Values read by an IOC must be stored as binary numbers in the PLC, not as BCD. Also note that the ADC input modules available for the 205 series PLCs cannot be addressed directly without some intermediate ladder logic to de-multiplex the channels (see 2.3 PLC Setup).
Output record types have only a restricted range of PLC memory which they can address. This range does not include any of the PLC output space, just an area of general data storage from V02000 to V02777. The application designer must be careful to ensure that memory words written to by the PLC ladder logic are not also the destination of PLC output records, as the smallest writable object is a word. The IOC maintains its own buffer of the values in each output location which allows several records to point to different bits or bit ranges within the same V-memory location and for the correct combined output to be send to the PLC, although every record processing will result in a separate write request to the PLC. Note that there is no link between this output buffer and the read data cache described above for input records, other than via the PLC's memory.
Support is currently provided for the following output record types:
Writes to a single bit at the given hardware address.
Writes to up to 16 bits at the given hardware address. The bit pattern cannot cross a 16-bit word boundary, but may be placed anywhere within the PLC data word. This restriction applies to the bit address types too; for example an output address of X17 (octal = 15 decimal) cannot be specified with NOBT=2. The current implementation will silently discard any bits beyond the MSB of the word addressed.
As mbbo.
Writes a whole word to the given memory location. Any bit offsets in the hardware address will be silently ignored. The use of output conversions (LINR="LINEAR" etc.) is not recommended until a means of specifying the DAC width has been implemented. The value placed in the PLC memory is in a binary format, not BCD. The ladder logic which is required to drive a DAC is described in the `DL205 Analog I/O Modules' manual from PLC Direct.
If a communication with the PLC via MPF fails, the record which caused the transaction to occur will be set into an alarm state. If the error is with the RS232 communication between MPF and the PLC then the alarm severity used is INVALID_ALARM; if the error occurs with the IOC to MPF communication path the severity MAJOR_ALARM is used. The alarm status will indicate WRITE_ALARM or READ_ALARM according to whether the problem was with sending the request or receiving a reply.
Two kinds of interaction are possible within a running IOC. The standard EPICS dbior I/O Report provides running status information collected from normal device support operations, and a program has been written that provides interactive read/write access to the PLC's memory via directNet operations.
Device support report functions are provided which allow the current status of the read and write data caches to be studied. Different interest levels result in different reports being printed. The following table defines the information given for each interest level:
Interest
LevelInformation Displayed 0 Addresses of connected PLCs 1 Communication statistics counters 2 Read & write cache summaries 3 Read cache buffer contents 4 Read cache record addressing
To access these status reports, use the standard dbior command at the vxWorks shell prompt. Without any parameters this produces interest level 0 information:
ioctest> dbior Driver: drvDnMpf PLC "DL250" via MPF server "dnMpf0" (0) with DirectNet ID 1 Device Support: devBiDnMpf Device Support: devBoDnMpf value = 0 = 0x0
For higher interest levels two parameters are required. The first should be either zero, or a driver or device support table name in quotes. The second parameter is the interest level:
ioctest> dbior 0,1
Driver: drvDnMpf
PLC "DL250" via MPF server "dnMpf0" (0) with DirectNet ID 1
alarm = 0, nRdReqs = 30, nWrReqs = 0
nSuccess = 30, nDnFail = 0, nMpFail = 0
Device Support: devBiDnMpf
Device Support: devBoDnMpf
value = 0 = 0x0
In the above, alarm indicates the alarm severity from the most recent communication with this PLC. nRdReqs and nWrReqs are the number of bitbus requests sent out for reading and writing respectively. nSuccess gives the number of responses with no errors; nDnFail counts any errors reported from the directNet protocol, and nMpFail any reported in the MPF communications path.
ioctest> dbior 0,2
Driver: drvDnMpf
Device Support: devBiDnMpf
PLC "DL250" via MPF server "dnMpf0" (0) with DirectNet ID 1
RdCache for V2000 - V2000 last updated at tick 0
RdCache for V7751 - V7765 last updated at tick 12024
RdCache for V7775 - V7777 last updated at tick 11732
RdCache for V41200 - V41202 last updated at tick 12028
RdCache for V40400 - V40400 last updated at tick 0
Device Support: devBoDnMpf
PLC "DL250" via MPF server "dnMpf0" (0) with DirectNet ID 1
WrCache for V2000 - V2777 starts at 0x1f34088
value = 0 = 0x0
Note that the same cache is used for all input record types, but only the bi device support provides a report function to avoid duplicate information being printed. The same is true of output record types, although much less information is stored in the device tables so the report outputs are much shorter.
Interest levels 3 and for provide more detailed information about the values in the cache buffer and the input records which use each buffer.
The interactive program `DNI' can be used to connect to a registered PLC and perform memory and I/O dumps and also modify PLC locations. This is started by typing DNI followed by the registered PLC name in quotes at the vxWorks shell prompt:
ioctest> DNI "DL250" DirectNet Interaction program Connected to PLC "DL250" on MPF server "dnMpf0" (0), DirectNet ID 1 Enter a command, ? gives help DNI:DL250>
The help command `?' lists most of the available commands:
DNI:DL250> ?
The DNI commands available are:
? [cmd] - Display help [on cmd]
c <plcName> - Connect to PLC <plcName>
d <addr> [n] - Display PLC data at <addr>
m <addr> - Modify PLC data at <addr>
q - Quit DNI
r - Print database I/O Report for all PLCs
s - Get PLC communications status
<addr> is a PLC data type followed by the address, eg V02000
[n] is an optional element count
Note that the `unprotect' command (see below) is not shown to prevent casual users from making changes to PLC variables that are not normally writable by the IOC. The command `c' can be used to connect to a different PLC without having to leave DNI:
DNI:DL250> c PLC2 Connected to PLC "PLC2" on MPF server "dnMpf1" (0), DirectNet ID 1 DNI:PLC2>
See how the PLC currently connected to is shown in the new command prompt. The display command `d' takes an address and an optional number of elements and shows the current value of those locations in the PLC:
DNI:DL250> d V7750 027 V07750: 0000 0000 0000 0000 0000 0000 0000 0000 V07760: 0000 0000 0000 0000 0000 30DF 0034 0053 V07770: 0003 0001 0006 0009 0000 0004 0002 DNI:DL250> d X0 X000: 1 1 1 0 0 1 0 1 0 0 0 0 0 0 0 0 X020: 0 0 0 0 0 0 0 0 DNI:DL250>
Many different kinds of address can be used, and the output format reflects the kind of data to which the address refers - where the address is of an input, output or status bit the display uses binary digits, otherwise hexadecimal is used. For a full list of the available address types and the valid range, ask for help on the `d' command thus:
DNI:DL250> ? d
The 'd' can command dump the contents of various PLC locations.
Valid DL250 PLC address types and ranges are:
V-memory V00000 - V41237
Counter value CTA000 - CTA177
Counter status CT000 - CT177
Control relay C0000 - C1777
Special relay SP000 - SP777
Stage status S0000 - S1777
Timer value TA000 - TA377
Timer status T000 - T377
Digital input X000 - X777
Digital output Y000 - Y777
Ladder program L0000 - L1DFF
Scratchpad Z0000 - Z5101
L and Z addresses are in hex, other addresses in octal.
Word data values are output in hex, Bit data in binary.
V-memory locations can be modified using the `m' command, which takes an address argument, displays the current location contents and prompts for a new data value:
DNI:DL250> m 2000
V02000: 0x0004 > ?
The 'm' command modifies VMEM locations so addr must be octal.
Data values from the PLC are displayed in hex.
At the '>' prompt, a number entry (with leading 0 or 0x for octal
or hex values respectively) will be written back to the location,
or the following subcommands can be used:
^ - Set direction backwards (decreasing addresses)
= - Set direction stationary (same address)
v - Set direction forwards (increasing addresses)
- - Move to preceeding address (direction setting is ignored)
+ - Move to following address (direction setting is ignored)
? - Prints this help message
. - Quit (unrecognized commands also quit)
V02000: 0x0004 > 0x1234
V02001: 0x0002 > ^
V02000: 0x1234 >
End of unprotected area
DNI:DL250>
Pressing return without entering a number will move onto the next location in the current direction without writing anything back to the previous location. The subcommands can be given on their own, or immediately after a value to be written to the current location. Setting the direction to be stationary makes it easy to monitor the value in a single location. The `m' command exits when the current address runs beyond the protected V-memory range V2000 thru V2777. It is possible to change memory outside of the protected range by first giving the `unprotect' command:
DNI:DL250> unprotect VMEM Write protection is OFF DNI:DL250> m V40500 V40500: 0x0010 > 0x30= V40500: 0x0030 > . DNI:DL250> u VMEM Write protection is ON
The remaining commands provide additional PLC status information. The command `r' gives the standard EPICS Database I/O report for all registered PLCs:
DNI:DL250> r
PLC "DL250" via MPF server "dnMpf0" (0) with DirectNet ID 1
alarm = 0, nRdReqs = 2040, nWrReqs = 0
nSuccess = 2040, nDnFail = 0, nMpFail = 0
PLC "PLC2" via MPF server "dnMpf1" (0) with DirectNet ID 1
alarm = 0, nRdReqs = 40, nWrReqs = 0
nSuccess = 40, nDnFail = 0, nMpFail = 0
The `s' command requests and displays some communications statistics from the PLC. If the number of erroneous communications or retries rises significantly there may be problems with the RS232 line to the PLC:
DNI:DL250> s
Last error code: 0x00
Prev error code: 0x00
Successful comms: 7797
Erroneous comms: 0
Header retries: 0
Data retries: 0
A PLC does not have to be in RUN mode for DirectNet communication to work, thus it is possible for the IOC to read and report the current run state of the PLC. An example database template and some MEDM screens are provided for the DL250 CPU to demonstrate this, and these can be used in applications if desired. They utilise the CPU special relays which are described in Appendix D of the DL205 User Manual. The error codes in Appendix B may also be a useful reference.
The status database can be found in the db subdirectory of the support application, named DL250statMpf.db. It contains 28 records which scan the CPU's special relays (bi records) and system memory locations (ai records) relating to its run state and error flags. The record names all start with `$(name):', and their INP fields with `@$(plc) '. Records will enter an alarm state in the event of the PLC indicating errors. In this release the following records are provided:
Record Name Scan Description Notes $(name):SP11 5 second Forced run mode $(name):SP12 I/O Intr Terminal run mode $(name):SP13 I/O Intr Test run mode $(name):SP15 I/O Intr Test program mode $(name):SP16 I/O Intr Terminal program mode $(name):SP17 I/O Intr Forced stop mode $(name):mode I/O Intr CPU mode mbbi giving run mode as text $(name):SP40 5 second Critical error $(name):SP41 I/O Intr Warning $(name):SP43 I/O Intr Battery low $(name):SP44 I/O Intr Program memory error $(name):SP45 I/O Intr I/O error $(name):SP46 I/O Intr Communications error $(name):SP47 I/O Intr I/O config error $(name):SP50 I/O Intr Fault instruction $(name):SP51 I/O Intr Watch Dog timeout $(name):SP52 I/O Intr Grammatical error $(name):V7751 5 second FAULT error code Scan disabled by SP50 $(name):V7752 10 second Correct module ID Scan disabled by SP47 $(name):V7753 10 second Incorrect module ID Scan disabled by SP47 $(name):V7754 10 second Configuration Base & Slot Scan disabled by SP47 $(name):V7755 5 second Fatal Error code $(name):V7756 5 second Major Error code $(name):V7757 5 second Minor Error code $(name):V7765 10 second Scan count $(name):V7775 10 second Scan time (msec) $(name):V7776 10 second Fastest scan $(name):V7777 10 second Slowest scan
An MEDM display associated with the above database is provided in the adl subdirectory (this file is identical to the equivalently named display provided with the directNetBug support). DL250stat.adl expects a name macro to be defined exactly as in the database, and displays some of the critical PLC information from the associated records: