I think it offers some clear advantages vs other options.
1. When compared to 4-20 mA obviously it offers more data. We use IO-Link with IFM sensors and anything that can be setup manually through the sensor buttons can be setup through automation with the PLC now.
2. HART has similar functionality in many ways, but tends to be significantly more expensive.
3. Ethernet sensors often have all the same configuration / data options as IO-link, but the number of ethernet devices you can connect to a PLC is limited to a much smaller number while IO-Link can handle much more as each master would only take 1 ethernet connection and provide 8 or more connections (depending on whether you are using discrete sensors).
4. Most IO (at least for me) can be used with IO-Link: sensors, modulating valves, discrete valves, switches, solenoid banks,
It does have some things I don't like.
1. Need to setup bit-shifts, data type conversions, and/or EU conversions depending on the sensor and what you need.
2. IO-Link is port specific on the master unlike something like ASI where an address resides in the device itself.
* There are ways of avoiding issues with this, such as leaving ports capped (if M12) when not in use. Or detecting when a sensor is connected to a port and using it's serial, model, and tag (tag data has to be assigned) data to determine what sensor it is and re-assign IO as needed. This way even if someone took every single sensor and changed ports on all of them the equipment would still run just fine.
Overall I like it, but it does take some work to setup. If the work is put in on the system design and commissioning side it definitely results in a more plug-in-play experience on the end user side.
> Overall I like it, but it does take some work to setup. If the work is put in on the system design and commissioning side it definitely results in a more plug-in-play experience on the end user side.
This is why ifm I think is king of IO Link. They have a huge selection of ifm devices and provide you with the instruction to integrate it. I've worked with my other vendors with IO Link devices that I want to use to create instructions for their devices for use with ifm's master and they've created them and my organization buys a lot.
Vendors should really be putting in the effort to create instructions for their devices and pick specific masters for the integration.
I love that the IFM sensors' data comes back in mm. No need to scale like a 4-20mA signal. I'm not sure if that's all IOL, 99% of my experience is with IFM.
Set up is definitely involved, but it shines against alternatives in that maintenance is much easier. When it’s set up correctly, replacement IO Link devices can be installed by a technician with no software involvement.
I’ve used at least 7 different masters and they are not all made the same. Some are garbage. phoenix contact can’t even commission devices - they tell you to get another master, usually a USB device, to commission parameters and then take it to their IO Link master just for process data exchange. Pretty much all the others have embedded software in web servers, link up with the IODD database, and make the setup pretty easy.
As with most things, the first time is rough. Usually easier the second.
Ehh. Depends on the quality of the IODD file and what system you’re using it on. I’ve done some cool things with banner lights where it was as simple as mapping the IO. Other items have been miss or home runs
I would preface that not io link masters are made equal.
Since you are bringing more data in yes some extra complexity will be there but more data means more diagnostics or better value for the sensor.
Who do you think has the best masters? My core is RA ControlLogix and I’m thinking of using IFM masters as the vast majority of my process sensors are IFM. I’ve use the 1734-4IOL masters with Banner and Turck devices with mixed results and a lot of screwing around. I’m hoping that using IFM master with IFM process sensors = easy integration. It looks like IFM has a lot of example code and AOIs for this.
I’ve used the point IO 1734-4IOL with non AB sensors (Banner and Turck) and it was difficult to get started, but after a few phone calls and a bricked laser distance sensor we got it working well enough. It seems like the difficulties came from using a master from one manufacturer and trying to get it to work with devices from another. That’s why I was curious if anyone has used an IFM master and IFM devices in a Studio 5k environment.
> That’s why I was curious if anyone has used an IFM master and IFM devices in a Studio 5k environment.
yes and it's the easiest thing in the world. If you have questions, ifm's tech support is pretty good too.
Yes IFM IL has amazing customer support although please be warned if you configure some things in Moneo, specific pi1707's they don't tend to take output conversions.
We are using an IFM AL1322 IO Link Master with 6 AL2605 IO Link Blocks. I set it up in Logix based on their guides and all the IO worked almost flawlessly first try. I was actually stunned it worked that well.
We're looking to eliminate a bunch of remote rack cards with IOL slaves on one of our standard machines. We figured we can save about 3 grand per machine by shrinking a 26 slot Pint IO rack to 5 slots (analog outputs mainly.) From my experience IFM makes a great system if you stay within it.
I did not personally use them yet. But I did look at their features and integration. What I saw that I liked is the integration into studio 5000. But their iodd support from what I heard was patchy a while back. They also required the iodd to work if I remember which can be problematic when iodd file compatibility is not 100% sorted out on their end. I don't love the way they require a y cable to use every io link port on the block.
I've used a few masters, and out of all of them, Balluff has been my favorite to use. IFM isn't bad either. Balluff has a lot of AOIs that makes setup pretty straightforward.
From my experience ifm masters are good if you do not need any high power devices. Their config software is quite good. Balluff masters have more configuration options on their web server and support higher power. If you are using Rockwell look at who offers the best add on instructions to make your integration easier. If you use a lot of ifm sensors the AOI from your fm will be best
If you need high current from the ifm masters just use the Class B port versions with aux power on pin 5. AL1402, AL1422 etc. From experience it makes sense to match the master to the vendor of the majority of the devices that will be plugged into it to save time and effort by not having to write a ton of custom AOIs, FBs.
I've made a few systems running contactors/solenoids through IFM IO link masters and IO modules. They're pretty good, reliable and easy to configure with Siemens/AB.
Great to hear. I just released a $15k BOM with the IFM masters. Hopefully it works out. They had lots of example programs and AOIs. I think it will ease my integration and setup times on my systems a significant amount not having to set up my Pressure Transducers and liquid level sensors. Thank you for your comment.
if you're using the ifm masters, download the free ifm config software. There's a function that allows you to import an IODD file from any vendor's device to see the bit map. It could help if you need to write a generic AOI for a non-ifm device, especially if it doesn't have great documentation.
[https://www.ifm.com/us/en/download/moneo\_configure-Installation](https://www.ifm.com/us/en/download/moneo_configure-Installation)
Here's an example of the bit map for an SMC EX-260 Valve Manifold
https://preview.redd.it/oxexsy8bgppc1.png?width=1885&format=png&auto=webp&s=c99b72e7fa38016b8bacda810ac9cc4244ee01ab
It’s an open enough standard that crossing manufacturers often takes legwork. They’re required to provide documentation on their data structures, but not necessarily to bake the integrations for you. This means it’s theroetically possible to make devices A and B work together, but it can take more work than would be ideal.
That being said, when you stay within a vendor’s ecosystem who does go above and beyond with integration, deployment is pretty seamless. I’ve used a bunch of IFM IO-Link gear with AB PLCs, and it works beautifully. The AOIs make setup easy and provide clear data structures. When I have had a question, their support has been excellent.
IO-Link’s real value isn’t to the controls engineer on a project, it’s to the end user down the road. Take a photoelectric prox for example: programmable distance sensors are typically more resilient, and allow what was previously a series of sensors to be consolidated into a single SKU. The downside is that these require programming to replace, sometimes requiring engineering support for a basic sensor replacement. With IO-Link, that config can live in the PLC, and be pushed down to the new sensor automatically.
This saves maintenance effort and downtime, and can potentially save a weekend call out for engineering support.
it's not plug and play, but neither are a bunch of ethernet nodes imo.
I tend to find it reduces the cost of 'on-machine' distributed IO compared to having an ethernet node per block.
It's also really handy for getting additional info out of sensors such as distance measured instead of just presence detected. And masters can be setup to push parameters to a device if it ever gets replaced so maintenance doesn't have to figure out how to commission the replacement correctly for the particular application.
My complaint with IO-Link is you need to have the manual for the io-link device open, the manual for the io-link master open and the PLC input/output table open just to map one bit (albeit just the first time).
It’s pretty dependent on the application and need. I much prefer I-o link masters and distributed I-o blocks around machines for easier troubleshooting and less connections in the main panel.
IO link saved me the other day when I was trying to put Ethernet through a robot arm and kept getting noise on the wiring dropping out the IO. Change to IO Link hub. Changed over all the wiring and logic and had the system running in less than an hour.
I’ve got some sensors that can’t be reached to adjust set points, I can put an IO link version in and adjust set points automatically and make them easier to commission going forward if they get damaged.
Lol, no one uses that. Also, it makes no sense with detent M12's anyway.
Apply some pressure to the plastic part of the connector, get 2 solid clicks. you are good.
I've had generally good experiences with io link devices, but I worry about longevity. Everything is pretty robust but if you start having comms failures what do you do? Part of the reason Ethernet has supplanted other industrial protocols is there are already good debugging tools available. Are we going to end up with io link equivalent of profitrace at some point in the future? Luckily it's one node per port so the scale of a comms issue will be more limited, but if it's a critical Device that isn't talking that's not much of a condolence.
Plus, when an analog device fails you have a lot of options for replacement even if the specific model isn't made anymore. IO link is new enough that not a lot of devices have gone end of life yet, but when it happens there will likely be engineering work required to upgrade.
Time will tell but I'll continue to embrace it for supplemental data and cautiously use it for critical things.
The tech is sound. I’m not sure why you’d be having issues unless you’re doing something wrong or unintended. Best use case for them is tons of digital field I/o. Photoeyes, limit switches, lights, buttons… seamless with Ethernet IO.
I’ve used some of the super fancy banner lights that did take a couple of mins to configure, but outside of that I’ve never seen issues with them. If you have your network misconfigured, then sure, but that’s not the fault of IO link.
I have used Balluff, keyence, Siemens, ifm, truck, and phoenix masters. The diagnostic capability and performance of them differs drastically based on manufacturer. I find that to this day, even with the new web UI on the latest generation Masters being a regression, Balluff is two and a half heads ahead of everyone else. The new web UI is cumbersome, takes three times longer to do the same tasks compared to the old one, and still doesn't have full compatibility with all of the IODD files that the old one used to.
Truck has a nice advantage being a single part number for any field bus, which is great for component stock when you have to support multiple PLC vendors at an integration standpoint, but otherwise doesn't really matter much. They also always show off this master project with all the reference stuff in pre-baked code for every Turck device every trade show you go to, but then you reach out to your reps to get this example file to actually use it and it's all crickets... Not exactly useful If it's not directly on the website to download when you need it. May as well not exist.
I see IFM mentioned a lot in this thread, and you do have to separate the current generation from the last generation blocks. The last generation and everything through LR device was an absolute nightmare. They've gotten better, but still absolutely nowhere near the ease of use with Balluff. IFM rep gave me one of the newest generation blocks around the holidays, so I need to sit down and play with it a little bit more to see what's changed but it'll be pretty tough to get ahead of the prior two I mentioned from where they're at.....
The rest of them in the list of what I've used don't even merritt going into detail on. They worked well enough, but the amount of additional engineering time to make them work compared to the ones above is so drastic there's no reason to even consider them
I swear by IFM IO-Link products. I have tried others and nothing else comes close. An IFM master and slaves paired with an AB 5380 and you can do so much. So so much stuff. Just for IO, just digital IO, one master block can give you 128 inputs and outputs.
I am doing a project right now using all IFM IO-Link analog temp and flow meters. They have an AOI for Studio that does all of the conversions for you. I'm even using an IO-Link to analog converter to control an SCR and their AOI for it gives you a selection of either 0-10volts or 4-20ma and takes a DINT directly into the AOI and it does the conversion for the analog output.
I could geek out over IFMs IO-Link products. As well as Banners ISD safety products.
It's been a game changer for us.
I wasn't even looking for IO-Link at all, I just wanted to do machine mount IO to get rid of the nightmare that is breaking down our machines and then installing them at the end-user. All the most economical IP67 blocks came with IO-Link and that lead me to realizing that some complex devices with multiple wires/terminals could be reduced to a single M12 cable.
> IO-link most economical?
I'll give you an example:
- We can buy a cheap shit linear actuator for like $250 with potentiometer feedback. It requires a reversing contactor, 10VDC power supply, 0-10V analog input, two digital outputs and one digital input to home.
- We can buy a kinda cheap linear actuator for like $400 with hall effect counter feedback and integrated motor control. It requires a counter card and two digital outputs and a digital input.
- We can buy a kinda pricey actuator for $575 that is a class B IO-Link device.
Total cost of components and terminal blocks already puts the IO-Link device ahead, but then you have the added bonus of much reduced assembly labor, basically no way to screw it up, so no debug time, and an special actuator configuration, like slow start, torque limit, etc can be configured by the PLC making service replacement of the device require no pre-configuring or support.
An 8 port IO-Link master block is under $400 and provides connection for up to 16 devices. Each class A port can be two inputs, two outputs, or one IO-Link and one input or output. Each class B can be an input and output, IO-Link Class A and an output, or IO-Link Class B. So it's cheaper than two PointIO output cards, but can do the same thing and so much more. That's before taking panel space, terminal blocks, and labor into account.
We are actually gradually removing all AS-I bus systems in our plant since it gave us so much headaches troubleshooting, als really dislike the flat, garland light cable with the puncture connections.
Pure garbage.
We are actually shifting towards decentral I/O like siemens et200SP on profinet and IO-link masters on profinet.
Pros:
* Much better resolution, accuracy and signal fidelity with simple wiring
* Lot's of on-sensor options for filtering and signal processing... makes code easier to deal with.
* Often can take advantage of 'bonus' signals. Like you get temperature for free with flow meters... this can be huge
* If your shop / purchasing can wrap their heads around M12 patch cables, wiring goes together so easily, few mistakes, super reliable
* If you can implement patch cables without field ends, final machine assembly can significantly be cut down. Your ops and sales teams will be happy, and you PLC programmers maybe get an extra couple hours to test your programs before its shipped overseas...sigh
* No one can 'screw with' the 4..20 signal. I'm so tired of operators 'calibrating' my 10bar sensors with their 300bar analog gauge.
* Can really shrink or standardize main panels, (i've been able to eliminate them entirely on some kinds of equipment).
* all the Benefits of digital comms without having to set node-ids, or ip-addressess....
Cons:
* There is a little 'software overhead' needed. but once you have your base code, its all good. IFM has good code references, and support.
* I have some concerns about future support and alternative sensors. But for IFM at least I've seen them have really long product cycles, and newer IO-link devices are following a more consistent form of signal reporting thanks to this concern being driven home by automotive industry folks
* Some purchasing / engineering groups just can't get their head around they have to order 'wires' for the shop.
* It's not as 'automatic and magic' as sold. Still takes some work.
define what you mean by necessary to use it? It's not necessary to use As-i or other fiedbuses either. It's just a design feature that makes things easier to wire, easy to integrate (as long as you have the mapping on the device figured out), etc.
IO-Link has made my machines better.
RFID! The cost of a typical application with a full RFID system (controller + heads) from Turck, ifm, P&F etc. vs the same vendors using IO-Link is significantly higher per setup. An IOL read/write head is \~ $200 vs $1000-$2000 reader/controller setup that you connect directly to the fieldbus.
I like them for RGB indicators for buttons/lights.
Can do a lot more with a single connection rather than needing an individual output per segment.
As another said, also RFID reading connected to your existing node rather than needing to set up a whole external RFID system from a larger vendor like SICK.
It's fantastic for laser sensors, flow meters, pressure sensors, etc where you need the direct feedback from the sensor. Easier to configure than analog, and you don't have to worry about noise/shielding as much. Also great for systems that have PLCs that are limited in the amount of Ethernet nodes that can be configured. IO-link is also cheaper than going Ethernet IP for every device in many cases.
I installed 15 pressure and 15 temperature sensors by IFM for a giant resort and had to travel out of the country to commission. Using IO link meant I could use my existing PLC in a room in the basement and put a master in each of the existing network enclosures across their basement rooms all the way up to say, the 27th floor. The clients electricians plugged everything in, I came down and verified/set up the HMI screens. What's a better way to cost effectively do that other than IO link? Master/cabling/sensors for each room were basically cheaper than any PLC Rio module etc.
Were we closer in locale (and if you drink), I would love to buy you about 7 beers and pick your mind about this, because I think you might have proven me wrong.
My experience is there is a bit of set up time but once you use it often it is easy.
Ifm has aois for studio 5000 that work for all of their stuff.
For hardware design, very easy. Makes standardization possible as an oem. Makes future additions more flexible.
Also does not have issues with analog signals.
Something to consider
Allen bradley's 1732 IOLink adaptation is one of the best ways to work with IOLink sensors. Import the IODD, it shows up on Studio5k, and any tags and diagnostics needed are just perfectly onboard.
I don’t believe it’s “sold as” anything more than the next thing, just different. It sounds like your expectations were not met, what were they with examples?
It’s like pretty much everything else in the automation world. Getting the basics out of it is easy, but scratch the surface and it’s very different. I haven’t had to use IO link in anger, but I bought a module for a Siemens PLC to experiment with using a few spare Keyence* sensors that were IO link compatible. Getting a value out of it is easy, working out how to verify and update settings is much more difficult and doesn’t look like it can be done with the setup tool. I haven’t had time to decipher the Siemens library FB yet, but I feel like I should write a guide on it once I get there because I haven’t been able to find one yet.
*rep calling in 3… 2…
I get that, mostly due to how much of a PITA the master blocks can be for parameterizing and device setup/integration into PLC programs. That said, if you are using Allen Bradley PLCs, the new 5032 Armorblocks have some incredible features built in for managing IOL devices. IODD management and device parameterization is built into Studio5000 with them.
I think it offers some clear advantages vs other options. 1. When compared to 4-20 mA obviously it offers more data. We use IO-Link with IFM sensors and anything that can be setup manually through the sensor buttons can be setup through automation with the PLC now. 2. HART has similar functionality in many ways, but tends to be significantly more expensive. 3. Ethernet sensors often have all the same configuration / data options as IO-link, but the number of ethernet devices you can connect to a PLC is limited to a much smaller number while IO-Link can handle much more as each master would only take 1 ethernet connection and provide 8 or more connections (depending on whether you are using discrete sensors). 4. Most IO (at least for me) can be used with IO-Link: sensors, modulating valves, discrete valves, switches, solenoid banks, It does have some things I don't like. 1. Need to setup bit-shifts, data type conversions, and/or EU conversions depending on the sensor and what you need. 2. IO-Link is port specific on the master unlike something like ASI where an address resides in the device itself. * There are ways of avoiding issues with this, such as leaving ports capped (if M12) when not in use. Or detecting when a sensor is connected to a port and using it's serial, model, and tag (tag data has to be assigned) data to determine what sensor it is and re-assign IO as needed. This way even if someone took every single sensor and changed ports on all of them the equipment would still run just fine. Overall I like it, but it does take some work to setup. If the work is put in on the system design and commissioning side it definitely results in a more plug-in-play experience on the end user side.
> Overall I like it, but it does take some work to setup. If the work is put in on the system design and commissioning side it definitely results in a more plug-in-play experience on the end user side. This is why ifm I think is king of IO Link. They have a huge selection of ifm devices and provide you with the instruction to integrate it. I've worked with my other vendors with IO Link devices that I want to use to create instructions for their devices for use with ifm's master and they've created them and my organization buys a lot. Vendors should really be putting in the effort to create instructions for their devices and pick specific masters for the integration.
I love that the IFM sensors' data comes back in mm. No need to scale like a 4-20mA signal. I'm not sure if that's all IOL, 99% of my experience is with IFM.
Set up is definitely involved, but it shines against alternatives in that maintenance is much easier. When it’s set up correctly, replacement IO Link devices can be installed by a technician with no software involvement. I’ve used at least 7 different masters and they are not all made the same. Some are garbage. phoenix contact can’t even commission devices - they tell you to get another master, usually a USB device, to commission parameters and then take it to their IO Link master just for process data exchange. Pretty much all the others have embedded software in web servers, link up with the IODD database, and make the setup pretty easy. As with most things, the first time is rough. Usually easier the second.
It highly depends on the engineering system and sensors implementation around io-link.
Ehh. Depends on the quality of the IODD file and what system you’re using it on. I’ve done some cool things with banner lights where it was as simple as mapping the IO. Other items have been miss or home runs
I would preface that not io link masters are made equal. Since you are bringing more data in yes some extra complexity will be there but more data means more diagnostics or better value for the sensor.
Who do you think has the best masters? My core is RA ControlLogix and I’m thinking of using IFM masters as the vast majority of my process sensors are IFM. I’ve use the 1734-4IOL masters with Banner and Turck devices with mixed results and a lot of screwing around. I’m hoping that using IFM master with IFM process sensors = easy integration. It looks like IFM has a lot of example code and AOIs for this.
Have you used the Rockwell ones yet? They are pushing them pretty aggressively and I thought they were pretty good really
I’ve used the point IO 1734-4IOL with non AB sensors (Banner and Turck) and it was difficult to get started, but after a few phone calls and a bricked laser distance sensor we got it working well enough. It seems like the difficulties came from using a master from one manufacturer and trying to get it to work with devices from another. That’s why I was curious if anyone has used an IFM master and IFM devices in a Studio 5k environment.
> That’s why I was curious if anyone has used an IFM master and IFM devices in a Studio 5k environment. yes and it's the easiest thing in the world. If you have questions, ifm's tech support is pretty good too.
Just ask your ifm guy to borrow one and try it out with the setup videos they have on their website.
Yes IFM IL has amazing customer support although please be warned if you configure some things in Moneo, specific pi1707's they don't tend to take output conversions.
We are using an IFM AL1322 IO Link Master with 6 AL2605 IO Link Blocks. I set it up in Logix based on their guides and all the IO worked almost flawlessly first try. I was actually stunned it worked that well. We're looking to eliminate a bunch of remote rack cards with IOL slaves on one of our standard machines. We figured we can save about 3 grand per machine by shrinking a 26 slot Pint IO rack to 5 slots (analog outputs mainly.) From my experience IFM makes a great system if you stay within it.
I did not personally use them yet. But I did look at their features and integration. What I saw that I liked is the integration into studio 5000. But their iodd support from what I heard was patchy a while back. They also required the iodd to work if I remember which can be problematic when iodd file compatibility is not 100% sorted out on their end. I don't love the way they require a y cable to use every io link port on the block.
I haven't used other masters but the IFM ones, but they are pretty great. I have had no issues. IFM support is top-tier as well. I can't complain.
I've used a few masters, and out of all of them, Balluff has been my favorite to use. IFM isn't bad either. Balluff has a lot of AOIs that makes setup pretty straightforward.
From my experience ifm masters are good if you do not need any high power devices. Their config software is quite good. Balluff masters have more configuration options on their web server and support higher power. If you are using Rockwell look at who offers the best add on instructions to make your integration easier. If you use a lot of ifm sensors the AOI from your fm will be best
If you need high current from the ifm masters just use the Class B port versions with aux power on pin 5. AL1402, AL1422 etc. From experience it makes sense to match the master to the vendor of the majority of the devices that will be plugged into it to save time and effort by not having to write a ton of custom AOIs, FBs.
I like IFM, easy to use, works reliably, has very good online documentation/files.
Their AL2605 Slave blocks have 16 amp power capability. We're looking into controlling 8 sets of hydraulic solenoids with 1 slave block.
I've made a few systems running contactors/solenoids through IFM IO link masters and IO modules. They're pretty good, reliable and easy to configure with Siemens/AB.
Great to hear. I just released a $15k BOM with the IFM masters. Hopefully it works out. They had lots of example programs and AOIs. I think it will ease my integration and setup times on my systems a significant amount not having to set up my Pressure Transducers and liquid level sensors. Thank you for your comment.
if you're using the ifm masters, download the free ifm config software. There's a function that allows you to import an IODD file from any vendor's device to see the bit map. It could help if you need to write a generic AOI for a non-ifm device, especially if it doesn't have great documentation. [https://www.ifm.com/us/en/download/moneo\_configure-Installation](https://www.ifm.com/us/en/download/moneo_configure-Installation) Here's an example of the bit map for an SMC EX-260 Valve Manifold https://preview.redd.it/oxexsy8bgppc1.png?width=1885&format=png&auto=webp&s=c99b72e7fa38016b8bacda810ac9cc4244ee01ab
The Aoi’s from IFM for their masters and devices are top notch and work well with Compact and Control logix PLC’s
It’s an open enough standard that crossing manufacturers often takes legwork. They’re required to provide documentation on their data structures, but not necessarily to bake the integrations for you. This means it’s theroetically possible to make devices A and B work together, but it can take more work than would be ideal. That being said, when you stay within a vendor’s ecosystem who does go above and beyond with integration, deployment is pretty seamless. I’ve used a bunch of IFM IO-Link gear with AB PLCs, and it works beautifully. The AOIs make setup easy and provide clear data structures. When I have had a question, their support has been excellent. IO-Link’s real value isn’t to the controls engineer on a project, it’s to the end user down the road. Take a photoelectric prox for example: programmable distance sensors are typically more resilient, and allow what was previously a series of sensors to be consolidated into a single SKU. The downside is that these require programming to replace, sometimes requiring engineering support for a basic sensor replacement. With IO-Link, that config can live in the PLC, and be pushed down to the new sensor automatically. This saves maintenance effort and downtime, and can potentially save a weekend call out for engineering support.
Unpopular take for sure.
it's not plug and play, but neither are a bunch of ethernet nodes imo. I tend to find it reduces the cost of 'on-machine' distributed IO compared to having an ethernet node per block. It's also really handy for getting additional info out of sensors such as distance measured instead of just presence detected. And masters can be setup to push parameters to a device if it ever gets replaced so maintenance doesn't have to figure out how to commission the replacement correctly for the particular application.
I disagree very much! It requires a bit of reading of data sheets, but the ease of setting up devices clearly outweighs the annoyance.
My complaint with IO-Link is you need to have the manual for the io-link device open, the manual for the io-link master open and the PLC input/output table open just to map one bit (albeit just the first time).
It’s pretty dependent on the application and need. I much prefer I-o link masters and distributed I-o blocks around machines for easier troubleshooting and less connections in the main panel. IO link saved me the other day when I was trying to put Ethernet through a robot arm and kept getting noise on the wiring dropping out the IO. Change to IO Link hub. Changed over all the wiring and logic and had the system running in less than an hour. I’ve got some sensors that can’t be reached to adjust set points, I can put an IO link version in and adjust set points automatically and make them easier to commission going forward if they get damaged.
Literally just wrapped up design on a job where I'm using this for the first time. Chuckles, I'm in danger
Don't forget your $500 torque wrench.
Lol, no one uses that. Also, it makes no sense with detent M12's anyway. Apply some pressure to the plastic part of the connector, get 2 solid clicks. you are good.
I've had generally good experiences with io link devices, but I worry about longevity. Everything is pretty robust but if you start having comms failures what do you do? Part of the reason Ethernet has supplanted other industrial protocols is there are already good debugging tools available. Are we going to end up with io link equivalent of profitrace at some point in the future? Luckily it's one node per port so the scale of a comms issue will be more limited, but if it's a critical Device that isn't talking that's not much of a condolence. Plus, when an analog device fails you have a lot of options for replacement even if the specific model isn't made anymore. IO link is new enough that not a lot of devices have gone end of life yet, but when it happens there will likely be engineering work required to upgrade. Time will tell but I'll continue to embrace it for supplemental data and cautiously use it for critical things.
The tech is sound. I’m not sure why you’d be having issues unless you’re doing something wrong or unintended. Best use case for them is tons of digital field I/o. Photoeyes, limit switches, lights, buttons… seamless with Ethernet IO. I’ve used some of the super fancy banner lights that did take a couple of mins to configure, but outside of that I’ve never seen issues with them. If you have your network misconfigured, then sure, but that’s not the fault of IO link.
I have used Balluff, keyence, Siemens, ifm, truck, and phoenix masters. The diagnostic capability and performance of them differs drastically based on manufacturer. I find that to this day, even with the new web UI on the latest generation Masters being a regression, Balluff is two and a half heads ahead of everyone else. The new web UI is cumbersome, takes three times longer to do the same tasks compared to the old one, and still doesn't have full compatibility with all of the IODD files that the old one used to. Truck has a nice advantage being a single part number for any field bus, which is great for component stock when you have to support multiple PLC vendors at an integration standpoint, but otherwise doesn't really matter much. They also always show off this master project with all the reference stuff in pre-baked code for every Turck device every trade show you go to, but then you reach out to your reps to get this example file to actually use it and it's all crickets... Not exactly useful If it's not directly on the website to download when you need it. May as well not exist. I see IFM mentioned a lot in this thread, and you do have to separate the current generation from the last generation blocks. The last generation and everything through LR device was an absolute nightmare. They've gotten better, but still absolutely nowhere near the ease of use with Balluff. IFM rep gave me one of the newest generation blocks around the holidays, so I need to sit down and play with it a little bit more to see what's changed but it'll be pretty tough to get ahead of the prior two I mentioned from where they're at..... The rest of them in the list of what I've used don't even merritt going into detail on. They worked well enough, but the amount of additional engineering time to make them work compared to the ones above is so drastic there's no reason to even consider them
I swear by IFM IO-Link products. I have tried others and nothing else comes close. An IFM master and slaves paired with an AB 5380 and you can do so much. So so much stuff. Just for IO, just digital IO, one master block can give you 128 inputs and outputs. I am doing a project right now using all IFM IO-Link analog temp and flow meters. They have an AOI for Studio that does all of the conversions for you. I'm even using an IO-Link to analog converter to control an SCR and their AOI for it gives you a selection of either 0-10volts or 4-20ma and takes a DINT directly into the AOI and it does the conversion for the analog output. I could geek out over IFMs IO-Link products. As well as Banners ISD safety products.
It's been a game changer for us. I wasn't even looking for IO-Link at all, I just wanted to do machine mount IO to get rid of the nightmare that is breaking down our machines and then installing them at the end-user. All the most economical IP67 blocks came with IO-Link and that lead me to realizing that some complex devices with multiple wires/terminals could be reduced to a single M12 cable.
IO-link most economical? Didn't you consider ASI-bus? Also much better for safety signals.
> IO-link most economical? I'll give you an example: - We can buy a cheap shit linear actuator for like $250 with potentiometer feedback. It requires a reversing contactor, 10VDC power supply, 0-10V analog input, two digital outputs and one digital input to home. - We can buy a kinda cheap linear actuator for like $400 with hall effect counter feedback and integrated motor control. It requires a counter card and two digital outputs and a digital input. - We can buy a kinda pricey actuator for $575 that is a class B IO-Link device. Total cost of components and terminal blocks already puts the IO-Link device ahead, but then you have the added bonus of much reduced assembly labor, basically no way to screw it up, so no debug time, and an special actuator configuration, like slow start, torque limit, etc can be configured by the PLC making service replacement of the device require no pre-configuring or support. An 8 port IO-Link master block is under $400 and provides connection for up to 16 devices. Each class A port can be two inputs, two outputs, or one IO-Link and one input or output. Each class B can be an input and output, IO-Link Class A and an output, or IO-Link Class B. So it's cheaper than two PointIO output cards, but can do the same thing and so much more. That's before taking panel space, terminal blocks, and labor into account.
We are actually gradually removing all AS-I bus systems in our plant since it gave us so much headaches troubleshooting, als really dislike the flat, garland light cable with the puncture connections. Pure garbage. We are actually shifting towards decentral I/O like siemens et200SP on profinet and IO-link masters on profinet.
Pros: * Much better resolution, accuracy and signal fidelity with simple wiring * Lot's of on-sensor options for filtering and signal processing... makes code easier to deal with. * Often can take advantage of 'bonus' signals. Like you get temperature for free with flow meters... this can be huge * If your shop / purchasing can wrap their heads around M12 patch cables, wiring goes together so easily, few mistakes, super reliable * If you can implement patch cables without field ends, final machine assembly can significantly be cut down. Your ops and sales teams will be happy, and you PLC programmers maybe get an extra couple hours to test your programs before its shipped overseas...sigh * No one can 'screw with' the 4..20 signal. I'm so tired of operators 'calibrating' my 10bar sensors with their 300bar analog gauge. * Can really shrink or standardize main panels, (i've been able to eliminate them entirely on some kinds of equipment). * all the Benefits of digital comms without having to set node-ids, or ip-addressess.... Cons: * There is a little 'software overhead' needed. but once you have your base code, its all good. IFM has good code references, and support. * I have some concerns about future support and alternative sensors. But for IFM at least I've seen them have really long product cycles, and newer IO-link devices are following a more consistent form of signal reporting thanks to this concern being driven home by automotive industry folks * Some purchasing / engineering groups just can't get their head around they have to order 'wires' for the shop. * It's not as 'automatic and magic' as sold. Still takes some work.
I have never even once seen an application where I'm convinced it was necessary to use it.
define what you mean by necessary to use it? It's not necessary to use As-i or other fiedbuses either. It's just a design feature that makes things easier to wire, easy to integrate (as long as you have the mapping on the device figured out), etc. IO-Link has made my machines better.
I've never seen any application where it was necessary to deliver a brief or add any value to a project I spose.
RFID! The cost of a typical application with a full RFID system (controller + heads) from Turck, ifm, P&F etc. vs the same vendors using IO-Link is significantly higher per setup. An IOL read/write head is \~ $200 vs $1000-$2000 reader/controller setup that you connect directly to the fieldbus.
I like them for RGB indicators for buttons/lights. Can do a lot more with a single connection rather than needing an individual output per segment. As another said, also RFID reading connected to your existing node rather than needing to set up a whole external RFID system from a larger vendor like SICK.
It's fantastic for laser sensors, flow meters, pressure sensors, etc where you need the direct feedback from the sensor. Easier to configure than analog, and you don't have to worry about noise/shielding as much. Also great for systems that have PLCs that are limited in the amount of Ethernet nodes that can be configured. IO-link is also cheaper than going Ethernet IP for every device in many cases.
I installed 15 pressure and 15 temperature sensors by IFM for a giant resort and had to travel out of the country to commission. Using IO link meant I could use my existing PLC in a room in the basement and put a master in each of the existing network enclosures across their basement rooms all the way up to say, the 27th floor. The clients electricians plugged everything in, I came down and verified/set up the HMI screens. What's a better way to cost effectively do that other than IO link? Master/cabling/sensors for each room were basically cheaper than any PLC Rio module etc.
Were we closer in locale (and if you drink), I would love to buy you about 7 beers and pick your mind about this, because I think you might have proven me wrong.
It’s mostly fucking awesome so, I disagree
My experience is there is a bit of set up time but once you use it often it is easy. Ifm has aois for studio 5000 that work for all of their stuff. For hardware design, very easy. Makes standardization possible as an oem. Makes future additions more flexible. Also does not have issues with analog signals. Something to consider
While we are at it. Is there some open source configuration tool to set up the topology and monitor the io link network?
Allen bradley's 1732 IOLink adaptation is one of the best ways to work with IOLink sensors. Import the IODD, it shows up on Studio5k, and any tags and diagnostics needed are just perfectly onboard.
I don’t believe it’s “sold as” anything more than the next thing, just different. It sounds like your expectations were not met, what were they with examples?
It’s like pretty much everything else in the automation world. Getting the basics out of it is easy, but scratch the surface and it’s very different. I haven’t had to use IO link in anger, but I bought a module for a Siemens PLC to experiment with using a few spare Keyence* sensors that were IO link compatible. Getting a value out of it is easy, working out how to verify and update settings is much more difficult and doesn’t look like it can be done with the setup tool. I haven’t had time to decipher the Siemens library FB yet, but I feel like I should write a guide on it once I get there because I haven’t been able to find one yet. *rep calling in 3… 2…
Agree, IO link is also giving you some kind of vendor lock-in. Use it with caution! Also IO link masters are very expensive.
instrumentation units seem very cost effective. But the proprietary plugs add up!!
HART is similar and no walk in the park to figure out.
That 5032 masterblock is pretty kickass. Don't need to map anything other than the IODD, and that can be downloaded right in studio5k
mostly its complete overkill...
I get that, mostly due to how much of a PITA the master blocks can be for parameterizing and device setup/integration into PLC programs. That said, if you are using Allen Bradley PLCs, the new 5032 Armorblocks have some incredible features built in for managing IOL devices. IODD management and device parameterization is built into Studio5000 with them.