IFM Proof-Of-Concept project, need help on connecting to a DIO hub to Ignition

Morning. I am new to using IFM I/O link products and currently working on a proof-of-concept project.

The project has an Ethernet/IP master (AL1326) with several IFM 'smart' sensors. Using IFM's supplied UDT's I have all of these devices communication with our local Ignition instance.

This master is also connected to a hub (AL2301) which provides 8 DIO ports which are planned to be used for various analog inputs and some discrete inputs. IFM helped us set these up and they appear to be successfully communicating.

My question is with the hub. How do I get values from it? there's no UDT on the website for this (the AL2301).

ANy guidance and suggestions are very much appreciated. Thanks!!

I'm not sure I have any help for you, but I do want to clarify...

Your setup is something like this?

Ignition -> ControlLogix PLC -> AL1326 -> AL2301

Or some other ENIP-enabled PLC that Ignition has a driver for.

Morning, Kevin. There is no PLC is the mix right now... it's all strictly IoT for data collection. We ordered the Ethernet/IP to test (later) local annunication of alarms etc (but may use IFM's output device for this purpose).

The POC contemplates multiple use-cases, from consuming the data via local Ignition, a remote Ignition, or a Logix PLC.

Does that help?

What UDTs are you talking about? How is Ignition communicating with these right now, and which is it communicating with if you don't actually have the AL1326?

Kevin, here's the kink to the UDT's (as provided by IFM)....

IFM has some UDT's which are available from the Ignition Exchange that are tailored to their devices.

They use UDT parameters to configure an httpPost message to the devices. The devices provide a JSON response that will have the requested information, which then according to the IODD file for that device may need some conversion to get to a useable value.

The nice thing about the UDT's is you give it the Ip address of the IO-Link master, and the port the device is connected to, and as long as the device is recognized it will do all the work for you.

@jkelleyus I'm guessing that they are polling the port that the AL2301 is connected to on the Master, and then they know how to parse the response down to the needed information from there.

Have you looked into this at all?

This allows for a direct OPC connection.

1 Like

I have not looked at this, but it appears we purchased one and the plant says it's configured and connected.

So this device is a OPC server.... how do I connect to it in Ignition?

Thank you for your help!

I haven’t yet done this, in fact I was just informed of its existence yesterday. However, it can be connected as a client to Ignitions OPC UA server.

On that page there is a download available for instructions to set up a connection to an OPC server.

For reference, the IFM IO-Link masters are coming out with a second ethernet PHY that is fully set up with a REST API for IIoT data collection.
IFM have provided some very clunky basic components for Ignition that bypass the need for a PLC and use httpRequest() as linked above.
I have had a play around with these units previously, a sample below.

I have actually written more utilities for the IO-Link masters using scripting and such, and have an intention to make a full tag system for these units based on Travis Cox's API Module.

Glad you guys seem to know what's going on here :slight_smile:

Is this REST API documented? Are the DIO from the connected AL2301 available via the API on the master?

I kind of gave up when I tried to download their docs and it required an account.

Basically the process data from each IO-Link device is accessible as a pdin process data input and pdout process data output data blocks. As a Hub is essentially an IO-link device that provides the sub device data as a sub structure under those data blocks, you would likely map the pdin and pdout data to a udt in ignition that can be chosen when the deviceid (Unique device identifier that specifies the device is that particular hub) matches the Hub.

It looks like I'd need their AE2100 to just be able to add that IP into the UDT as they show in their video, or am I misunderstanding. I saw you haven't dont anything yet with it, just wondering what you've seen.

From what I understand, what they are doing in the video, is accessing the IO-Link master through the IIoT port on the master. In theory, you do not need the AE2100, that just facilitates an OPC connection, rather than using httpRequest() as their UDT's do.

@David_Stone Probably has more insightful information as he has actually worked with these.

I personally used a Modbus TCP connection, but that was because I didn't know about the UDT's or the AE2100 at the time.

Thanks. Hopefully he can bring some clarity to that. We are going to be deploying a bunch of temperature sensors as well as flow sensors and other devices for building monitoring etc and we are planning on bringing them into an AB PLC to get them into OPC and then into Ignition, but if theres a simpler option that might make sense for our application.

If you bring them into an AB PLC via a generic ETHERNET_MODULE, that processor's L5X export can be dropped into my EtherNet/IP Class1 Host Device to configure direct Ignition scanning. (With a few tweaks to connection path, usually. And prune all the unused stuff.)

So, it is relatively easy to use this system to get your values into Ignition without the PLC.

As you have seen, the UDTs from IFM work really well for the IO-Link sensors.
The reason that they don't have one for the hub (AL2301) is because the hub has "dumb" devices on it.
When you get the data from the a device on the master using the IFM UDTs, you will see a PDIN tag that is a memory tag under the nested UDT Poll.
This is the process data input from the device, and it is described in the IODD file that explains the data format that the device is outputting into PDIN.
For a TDXXXX temperature sensor this data contains the temperature in degrees in the first four characters of the PDIN.

This is easy to write a script for, as every temperature sensor in that series sends the data in exactly the same way.
The problem with the hub is that you can configure the inputs and outputs individually and that changes how you need to interpret the PDIN data.
If you know exactly what the inputs and outputs are set up for on all your hubs, you can make your own device UDT by copying one of the IFM ones, and just edit the tag change script that is on the PDIN tag. In this script you access the process data with currentValue.value and you do your transformations before writing it to the top level memory tags that you create to match the tags you want to see.
This is the tag change script from the TDXXXX device for reference:

def valueChanged(tag, tagPath, previousValue, currentValue, initialChange, missedEvents):
   
   topTagPath = "/".join(tagPath.split("/")[:-2])
   dataValue = currentValue.value
   
   temperature = int(dataValue[0:4], 16) * 0.1
   
   if int(dataValue[0], 16) >= 8:
   	rawValue = int(dataValue[0:4], 16) - 65536
   	temperature = (rawValue * 0.1) 
   
   tempC = (temperature -32) * 5/9
   tempF = temperature
   	
   system.tag.writeBlocking(["%s/TemperatureC" % topTagPath, "%s/TemperatureF" % topTagPath], [tempC, tempF])

As you can see, it is pretty simple.
The data format for the AL2301 is described in here:

Essentially it has a 240 bit long register that contains not only space for 8 digital inputs, 8 digital outputs and 8 analog inputs, but also configuration status indicators to show what each port has been configured to do.

If I had a hub in front of me, I would write a device UDT for this, but I do not have hardware.

3 Likes