Skip to content

Omron FINS

Jump to bottom Edit New page
Alexandru Dascalu edited this page Jul 16, 2020 · 48 revisions

Wiki > The Backend System > Specific Device IOC > PLCs > Omron FINS

Introduction

Most of the work done by the IOCs for the various FINS PLCs at ISIS consists of reading and writing to various places in the memory of that particular PLC. Some IOCs also perform some internal logic.

The manuals referenced on this page can be found on the shares drive, in Manuals\OMRON_FINS_PLCs. There you can also find the images on this page.

The Omron FINS is a PLC controlled via a driver first written at Diamond, see here. The IOC works by loading an instrument specific FINS_01.cmd in configurations/fins, which will load an instrument specific db from ioc/master/FINS/db. The dbs in here are usually created from a number of templates matching specific memory addresses to PVs. This is the case because PLCs used for different applications have different things stored in their memory, and to read/write various pieces of data the IOC needs to know the exact memory address for that data. Each individual PLC has its own memory map, which shows what memory address stores what thing, and each specific IOC is based on that.

Currently the following specific FINS PLC installations are supported in IBEX:

  • IMAT FINS PLC
  • LARMOR air PLC
  • SANS2D vacuum PLC
  • WISH vacuum PLC
  • ZOOM vacuum PLC
  • Helium Recovery PLC - stores information needed for the Helium Level Monitoring project

The FINS protocol

The FINS protocol is an applications layer communications protocol designed for industrial applications and made by Omron. FINS stands for Factory Interface Network Service.

Throughout this guide, when I mention a manual, it can be found on the shares drive in Manuals/OMRON_FINS_PLCs .

FINS communications can be done over a serial connection or over a network. For serial connections, it uses the Host Link protocol on the Data Link layer of the OSI model. If used over a network, FINS can be used over a wide variety of Data Link layer protocols, including Controller Link and Ethernet. At ISIS, FINS PLC communication is done via Ethernet. FINS PLCs also supports another protocol instead of FINS, called C-mode, which is specialised for Host Link, but we do not use that. For more information, see Section 1 of the Comms Reference manual.

When using FINS over Ethernet, it can work with both TCP and UDP. FINS over TCP though is only supported on the CS1W-ETN21 and CJ1W-ETN21 models. The default UDP/TCP port number is 9600.

FINS Frames

When using FINS over UDP, the FINS frame is the part of the UDP packet after the UDP protocol specific header. The first 10 bytes of the FINS command frame represent the FINS frame header, and the rest of the frame represent either a command or a response, which have different formats. For FINS over TCP, after the TCP header and before the FINS frame there is a special FINS/TCP header used by FINS to handle TCP connections.

Most of the FINS PLCs at ISIS use FINS over TCP ?. The Helium recovery PLC uses UDP. For more information about FINS in general, look at section 7-1 of the Ethernet manual. Section 7-3 offers detailed information about FINS over UDP.

There are some very useful diagrams showing the structure of FINS frames and FINS/TCP headers in the same folder as the manuals on the shares drive.

FINS header

The first 10 bytes of the FINS command frame represent the FINS frame header, and the rest of the frame represent the command.

The structure of the FINS frame header is as follows (each of the elements take up one byte):

  • Information Control Field or ICF: Displays whether the frame is for a command or a response, and whether a response is required or not. For our purposes, this byte should 0x80 for a command and 0xC1 for a reply.
  • Reserved or RSV byte: should always be 0.
  • Gate Count or GCT: The number of network bridges the frame needs to pass through. For our purposes, it should always be 0x02.
  • Destination Network Address or DNA: The address of the network to which the receiver belongs. This address is of the entire network, and not of just the machine, and is different from the IP address. It is 0 for Local Network, and 1 to 127 for remote networks.
  • Destination Node Address or DA1: The node of the receiver, which is an address needed by the FINS protocol, and is different from the IP address. It has values from 0 to 256, with 0 for the local PLC unit and 256 for broadcasting.
  • Destination Unit Address or DA2: The number of the unit of the destination node to which the command is addressed. It will typically be 0, for the CPU unit. A unit is one of the modules mounted on rails that make up the PLC.
  • Source network address or SNA: The network address of the sender. The possible values of SNA are the same as of DNA.
  • Source node address or SA1: The node of the sender. The possible values of SA1 are the same as for DA1.
  • Source unit address or SA2: The unit address of the sender. It will typically be 0, for the CPU unit.
  • Service ID or SID: a number used to identify the FINS processes generating the transmission. It can have values from 0 to 255.

If you need more detail about the FINS header, look at section 7-2 of the Ethernet manual.

FINS Command body

The first two bytes after the header represent the command code. All the FINS command codes can be found in section 5-1 of the Comms Reference manual. Most of the commands used at ISIS are Memory Area Read, with code 0x0101, and Memory Area Write, with code 0x0102.

The rest of the body consists of command parameters and perhaps data. It can be up to 2000 words in length. The length and format depends on the command code. For reference, in section 5-3 of the Comms Reference Manual you can find the parameter formats and other details for each command.

The first byte after the command code represents the I/O memory area code. The next three bytes indicate the start address from which it will read or write. Of these three, the first two bytes indicate the memory address of the first word from where to read/write, and the third byte indicates the individual bit from where reading or writing starts. This third byte is 0 for word designated memory addresses, where each word is considered an element. If it is not 0, then each individual bit is considered an element. After this address, two more bytes represent the number of elements to read/write. For write commands, what folows after is the data which you want to write.

You can find a list of all I/O memeory area codes in section 5-2-2 of the Comms Reference manual, and more details about the memory start address in section 5-2-1 of the same manual.

FINS response body

Just as with the command body, the first two bytes represent the code of the command which is being replied to. After that, two bytes represent the error code. It is 0 for no erros, and all the other error codes are detailed in section 5-1-3 of the Comms Reference Manual. Following the error codes are a number of words equal to the number of words given in the read command representing the data you want to read. For write commands, the reponse ends with the error code.

FINS/TCP header

Unlike UDP, TCP is a connection based protocol. Since a virtual connection needs to be established before you can send packets, for FINS over TCP there is an extra FINS/TCP header before the FINS frame that helps to handle the virtual connection. For establishing a connection, besides the usual TCP packets, the client and server need to exchange FINS node addresses so that the PLC can manage the connections properly.

The structure of the of the FINS/TCP header is as follows, with each element taking up 4 bytes:

  • Header: is always 0x46494E53, which is ASCII for FINS.
  • Length: specifies length of data from the FINS/TCP command code onwards, including the FINS frame as well.
  • Command code: There a couple of commands for FINS/TCP for exchaning node addresses, sending FINS frames and managing errors and connections.
  • Error code: It is 0 for no errors, and for some commands it is not even used.
  • Client Node address: only part of the FINS/TCP header for some commands.
  • Server Node address: only part of the FINS/TCP header for the FINS NODE ADDRESS DATA SEND (SERVER TO CLIENT) command.

The FINS/TCP connections and commands should be handled by the C driver orignally written at Diamond and we should not worry about the FINS/TCP header. If you need more information, section 7-4-2 of the Ethernet Manual gives details for each command, and section 7-4-1 gives a more detailed overview about FINS over TCP.

Connection

PLC init

The fins PLC communication is set up with the following:

finsUDPInit(<port Name>, <address>, <protocol>, <simulate>)

where:

  • port name: ASYN port name (usually PLC)
  • address: ip address of the PLC
  • protocol: which protocol to use
    • "TCP": use TCP communication
    • "TCPNOHEAD": use TCP comms, but without FINS-TCP header. This is required (and should only be used for) the devsim IOC tests
    • anything else: use UDP protocol
  • simulate: whether to simulate calls
    • 0: Do not simulate (real device or devsim)
    • 1: Simulate (don't send commands), this is required for recsim as it lets device initialisation complete successfully with no device

Configuration

In order to run this IOC and talk to the real PLC, you need to have the correct instrument specific FINS_01.cmd in configurations/fins. See below an example:

#Init and connect
finsUDPInit("PLC", "$(PLC_IP)", "UDP", 0, "$(PLC_NODE=)")

## Load our record instances
dbLoadRecords("${TOP}/db/he-recovery.db","P=$(MYPVPREFIX),Q=EXAMPLE:)

In the IBEX GUI, make sure to set the two macros for the FINS IOC, PLC_IP and PLC_NODE. PLC_IP refers to the IP address of the PLC, and the node is a FINS protocol application layer specific address that differentiates between nodes (such as PLCs or host computers). By default, it corresponds to the last byte of the IP address, but for some FINS PLCs this is not the case.

For running the IOC for testing, see below.

Testing the FINS IOC in the Ioc Test Framework

In contrast to the normal operation of a FINS PLC, the instrument specific FINS_01.cmd file that should be used for the IOC Tests for a FINS PLC should be placed in an instrument specific folder in ioc\master\FINS\exampleSettings. This cmd file should have the appropriate finsUDPInit calls for devsim or recsim, as detailed below, and also the usual dbLoadRecords call to load the instrument specific db.

Testing the FINS IOC in DevSim

If you want to test the IOC for a FINS PLC in devsim mode, you need to add to the FINS_01.cmd file used by that specific FINS IOC the line:

$(IFDEVSIM) finsUDPInit("PLC", "$(PLCIP):$(EMULATOR_PORT=)", "TCPNOHEAD", 0, "$(PLCNODE=)")

At the same time, the file should either not have any other finsUDPInit call for talking with the real PLC, or have $(IFNOTDEVSIM) $(IFNOTRECSIM) before that call.

Testing the FINS IOC in RecSim

If you want to test the IOC for a FINS PLC in recsim mode, you need to add to the FINS_01.cmd file used by that specific FINS IOC the line:

$(IFRECSIM) finsUDPInit("PLC", "$(PLCIP):$(EMULATOR_PORT=)", "TCPNOHEAD", 1, "$(PLCNODE=)")

At the same time, the file should either not have any other finsUDPInit call for talking with the real PLC, or have $(IFNOTDEVSIM) $(IFNOTRECSIM) before that call.

Add a custom footer
Add a custom sidebar
Clone this wiki locally