How to Interface a sensor using IO-Link - Ethernet Master

[Ryan_Wright_]

Thanks for this additional information. I wanted people to be aware of another possible solution in the event that it worked, which obviously it doesn't based on your feedback.

[grezoo]

I found a very easy solution. For example, Nass Magnet - IFM produces an IO-Link Master that communicates with the PC via a simple HTTP request. All you need to do is download a Http library. And everything works perfectly. Currently 4 sensors and actuators can be connected to such a Master. Fast, super. Real time control loop cannot be inserted as feedback due to the Http protocol. But it is excellent for data collection.

Not needed 3rd party software.  Very simple: You can see a blue link in the picture, you can type it in your browser and Master will reply 🙂 It will send you the requested information in a Json format package.

[grezoo]

And Json data is very easy to extract with a Json library. see the picture

[SteenSchmidt]

Yeah, easy, you just need to:

- Read the IO-Link standard to understand what you should be looking for (find and get access to the right standards first - there are multiple, and they change).

- Locate 8 different parameters in a 1000-line XML file for your device (the device's IODD-file).

- Read your specific IO-Link master's guide on how to access its IoT interface through HTTP.

- Code the HTTP access in LabVIEW with the right URL for the variable (make this robust for all the network, device, and timing error cases).

- Now you have a string of bits.

- Read the IO-Link standard to understand how to decode your variable's value from the bit-string into a LabVIEW datatype.

- Code the bit-banging in LabVIEW (make this robust for the funny corner cases, range limits, special values and what else the IODD-file tells you this variable can have).

- Done (and that doesn't consider default values, language specific decoding, offsets and much more).

Now you realize:

- There are 5 different categories of variables in IO-Link, all treated differently even though they may be similar datatypes.

- And many different datatypes. Yours was a U32, it could have been nested records (clusters in LabVIEW), or a type where you need to consider endianness.

- And then you want to read a different variable or a different device, so you have to do it all over again because all the addresses and decoding is different.

- Or write instead of read, which is also different.

- Or you want to use another master that doesn't have an HTTP interface.

- Or you need to do streaming, because point-by-point is too slow.

Or you could use our IO-Link toolkit and not bother with any of that (in both LabVIEW and TestStand):

Do you see why a good LabVIEW toolkit costs money? We have spent thousands of hours (literally), and continue to spend hundreds of hours each year, so you can save hundreds of hours - and you can get that for the value of a handful of your working hours. But all I see is "open source wanted"... Ain't gonna happen, so stuff like that is going to disappear in our community 🙂

[grezoo]

With an HTTP Master, if you don't want to tie the application into a control loop (timing), you don't need just one HTTP Master that I mentioned. There is no need to deal with the IO-Link protocol. Nor with the IODD files. I use the Http master for testing, multiplexer, and data collection. He's perfectly suited for it. These tasks don't require the kind of complexity you mention. For example, you have 10 sensors and you collect data, and you have 10 relays and solenoids that you switch. Besides, every Master takes care of this for you. indexes must be specified for the query, command 🙂 Inex 101 - databits pls set the counter limit. e.g. it doesn't have to be too complicated. And it is standard that the characteristic data of each device is available under the Process data bit (in the same place) And the location of the ID and the other available data are also standard. 🙂 
Your tools are great, but I didn't need them. An Http Master was cheaper for the tasks. Considering working hours and subscription. If I am creating a realtime (engine - pump, tank) level control or a time-sensitive application, I would not miss the PLC. I need these for control and supervision. Http Master is more than enough for that.

[grezoo]

Http Master is not open source. TE concept, the developer of IO-link, was so kind and made the data of the IO-link sensors available with a simple Http interface. 🙂 It's not free. The Master is not free. 🙂 But significantly simpler for basic tasks (85%) By the way, Nodered can also be used pleasantly under Linux. But I don't use it, because NI systems use multimeters, servos, evaluations and more, a lot of data, in which Nodered is weak. But I can easily connect compact IO-link peripherals with this. I tried your software but didn't need it. Where do you connect the IO-link sensor? In hardware? What do you make or buy with it? How much does it cost? 🙂 Isn't an Http - UTP cable, an IP address simpler? 🙂 And the Master also performs the interpretation. It's not just a hardware match. with waterproof connection.

[grezoo]

In fact, Baluff has already made an RS232 adapter for IO Link devices. That could be a pretty good solution, although I think it's a bit complicated. So far, Http or other PC standard Master has worked best. Which doesn't require wiring. Just plug it in. 

The flaw of the RS232 - IO link is that it is not a direct converter. It does not flow through the stream conversion, but you have to constantly give an instruction to read, every time. In 4 steps. Imagine if you were to query the temperature 🙂 In order to get to 2 letters (23) you have to send 4 lines of messages 🙂 Read mode, Is there any info in the buffer, what exactly is the info in the buffer, and clear buffer, then reset 🙂 useless 🙂 I write to the Http Master, index 20, and it sends the data found there. 🙂 "TE concept" made an IODD interpreter. It will be a readable PDF.

Usually I am interested in specific things in an application. And I don't change sensors to different types every day on the production line. (I need a different IODD) This has to be written once. I started with your application. But I realized that there is a better way for me. With Http Master, you only need one sensor instruction manual. And it is very easy to use all IO-Link devices. Because the PC communicates with it via the factory Http interface (debug) Debug is very important. With Http Master, you can easily parameterize IO-Link sensors and actuators on a factory interface with a PC, and then easily implement them. If something doesn't work, you can quickly fix it and analyze it.

[grezoo]

You basically ignore the IO-LINK levels. If you connect a sensor directly, that's a cheap looking Hack. Not the Master. The most logical form of IO link levels is to use a Master. And use a PLC. After that comes the PC and Labview. In a professional implementation, we don't wire an IO-link sensor to the PC 🙂 The HTTP Master, and the HTTP Masters of the Future, with logic (IN-HUB EN 200) represent the future. Which is the corresponding IO-link Interface. At the corresponding level. The advantage of IO-Link is that it is Plug and play. This is what you need to keep in mind. Have you created a software IO-link Master, but what about the hardware? If you buy one, the Hardware is given. And it is standard. For all IO-link devices. (By the way, a New IO-link protocol was released.. The Master is ready for it that day!!! Because the IO-link Community provides updates immediately.

[SteenSchmidt]

I'm sorry, but what you write is rather confusing. I'll comment some of your statements in no particular order:

- TEConcept GmbH isn't "the developer of IO-Link". They are great contributors to the IO-Link community for sure, but are "just" a member of the IO‑Link Consortium like GPower is. IO-Link was created in a joint venture of about 20 companies in the early 2000's, counting Siemens, Balluff, IFM, Sick, Festo, and others, but not TCConcept. Not a problem at all, just a clarification.

- You ARE using an IO-Link Master. Your "HTTP Master" from IFM is an IO-Link Master, it just offers IFM's IoT interface between it and a PC. Other masters offer other computer interfaces, such as Modbus, EtherCAT, or EthernetIP. But they are all IO-Link masters.

- We always use an IO-Link master between a PC and the IO-Link devices, of course never IO-Link devices directly connected to a PC. A PLC isn't required, but could be used instead of a PC if it fits the appllication.

You wouldn't have to do ANY of the below steps if you used our IO-Link toolkit:

1) You are only able to do the HTTP URL you set up in LabVIEW because you've read your IFM master's user guide.

2) If you want to change device, move the device from one IO-Link channel to another, want to read a different variable from your device, want to write instead of read from your device, or want to change IO-Link master, you'd have to make changes to your HTTP URL, forcing you to read your IFM master's user guide some more.

3) You are only able to do the bitbanging on the JSON string you set up in LabVIEW because you've spent many hours with the IO-Link references and used the IODD file interpreters.

4) If you change hardware, you might change away from JSON. If you need to read a different datatype you need to investigate all over how to do the bitbanging in a different way. This can get VERY complicated once you have variable-length compound container datatypes.

5) If you are not satisfied with the performance of HTTP, or point-by-point sampling, then you are in for some long evenings of investigation and low-level implementation.

So, I'm not suggesting you can't do what you did with IO-Link, completely manually and hardcoded for each use case. I have done that for years. Just like you don't "need" an OPC client and server setup to communicate with a PLC. Now you just have an option not to spend all that time reading up on IO-Link specs and fiddling with bits. When our customers want to change something in their IO-Link setup, we literally went from 40 hours to 10 seconds of work. Feel free to spend this time, it can be great fun 🙂 But you can't convince me you're saving time by not using plug'n'play tools 😉

[grezoo]

That's exactly why I wrote here. Maybe the solution will help someone.

Because Plug&Play. IMF and Nass magnet Ethernet - Http Master are plug & play.

You don't need a Gpower quasi software IO-link master written in Labview.

The optimal project, not your business. The optimal solution in some cases is Ethernet Master, in some cases is your solution. It depends on the project. Ethernet Master worked for me. IFM is 8 channels class B, Nass is 4 channels Class A. 

I think it's positive and I really liked the G Power code. Very Cool.  And I was looking for it back then because I wanted something similar. Convenient. However, once I understood how the IO-link system works, it was easy to use Ethernet Master. You have to understand what you're developing 🙂 I can use code written by someone else like a fool, but if something doesn't work, I have to understand it anyway. This can't be avoided. Unfortunately. So it's an option. Use it. If the project allows it. It's very simple.