How to Interface a sensor using IO-Link

[SteenSchmidt]

---

@grezoo wrote:

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

---

What do you mean by "quasi software IO-link master"? GPower's IO-Link toolkits aren't IO-Link masters. The software communicates with the IO-Link masters with protocols, addresses, and bitwise encoding/decoding you then don't have to dig information out for yourself. It doesn't replace any hardware, it replaces hours and hours of work you'd have to do yourself otherwise.

Let me ask you: How many hours of work have you spent, from before you knew anything at all about IO-Link, and until your first succesful U32 was available to you from your IO-Link device?

[grezoo]

When I got my hands on the first IO -link sensor, I wanted to read it with Labview , ARM , whatever.
Then I read up on the possibilities.
That was one day.
For the IO link protocol. because I was looking for more options.
It was also one day. in man hours about 20.
One of the viable paths became GPower, the other became ethernet master. I tried G Power. It was a week because I had to understand it as an unknown. What exactly the software does. Is there a bug in it.
In the meantime I tried the Ethernet Master. And since I could read the ethernet master data right out of the box in the browser of my office computer, I stuck with that solution. And while using it, I learned the IO -Link. During the application, I went out to TE concept with suggestions for improvement, to learn. It was a two week process to the finished application. I had never heard of IOlink before. And the application worked. I've been doing this for almost 3 years, I've installed a lot of actuators - sensors since then. i don't need any more.
And I have put it into practice, with software for parts testing. (interfaced to other measuring instruments.) After software validation it has been implemented. One month... And the learning curve is not linear. At the beginning my zero flow is naturally slower 🙂 Then it is exponential. No need to worry.

As a developer, you need to understand IODD xml whether you like it or not 🙂 If you use Canalyzer, you also need to count CAN cheksum. And test with oscilloscope. Learning is inevitable 🙂

[grezoo]

What do I mean by quasi-software Master?
Canalyzer is a similar system. It takes the bits and puts them into a specific frame by software (see IODD as a frame). It parses the bit stream and puts the right data in the right place. That's fine. That's good. By frame software Master I mean (possible I didn't word it right) that you upload the IODD file to it , and you get ready data. That's great. Currently PLC can do that and there is a niche in the market for your software. But that's not what I needed. I assumed that there might be people like me for whom the Ethernet master would be the solution. 

[SteenSchmidt]

---

@grezoo wrote:

What do I mean by quasi-software Master?
Canalyzer is a similar system. It takes the bits and puts them into a specific frame by software (see IODD as a frame). It parses the bit stream and puts the right data in the right place. That's fine. That's good. By frame software Master I mean (possible I didn't word it right) that you upload the IODD file to it , and you get ready data. That's great. Currently PLC can do that and there is a niche in the market for your software. But that's not what I needed. I assumed that there might be people like me for whom the Ethernet master would be the solution.

---

You are doing manually what our IO-Link LabVIEW software does automatically. I fail to see how doing it manually is an advantage, sorry. I do not throw away DAQmx and bitbang my communication to a C-module in a cDAQ chassis either. I could from NI's whitepapers, but it's much easier to use the DAQmx driver.

The "Ethernet master" isn't different from a Modbus IO-Link master for instance. Same story, you can just send it strings and get strings back. You just need to learn what strings to send it, and how to interpret the strings you get back.

It's all great that you want to spend all that time learning it yourself - but it is that: Spending time learning something you chose to, but didn't have to. Each time you added new devices, you had to look up new adresses and decodning/encoding of new datatypes (unless they were all U32 of course). That's all time you could have saved, if you used GPower's IO-Link toolkit.

What about device validation with the ProductID, DeviceID, VendorID, serial numbers? Those are not just fields to read, there are standards and practices on how these field values are combined and presented, and how and when they are returned from different masters.

And device operational modes and settings? If your device is configured wrong, you don't get any data. That could happen if your device fails, or you need to replicate a system. When you get a replacement device, it may have a different firmware from the one you had earlier, or it may be factory configured in test mode. In an industrial setting, you don't stop the production line and whip out the IO-Link standards (if they can get hold of the "IO-Link engineer" at all to interpret those standards). They plug the device in, and press "run". That's industrial grade software.

It's awesome that you take the time to show how it looks under the hood - that is a great reference to get an idea of what IO-Link (or any industrial protocol) is. But with that you have just scratched the surface of using IO-Link. You are describing a hobby project. For professional traceability, repeatability, redundancy, stability, and minimal downtime, you need much more.

Let's call it quits, and celebrate that you are willing to spend a lot of time explaining these things. We are engineers here, primarily, after all. I definitely appreciate your contribution and patience.

[grezoo]

Yes. A very big advantage of your software is that it can automatically read the indexes in the IODD.
And I cannot recommend a better tool for users than your software. LV for fitting!

However, I needed it for a specific task, which does not change. It has not been discarded yet. Not scrapped.

I took the IODD file, and Made a VIPM. library. a couple of Sub Vi - sub.

• 1 that reads out counters,
• ID,
• error flags,
• one that reads current,
• one that reads ON OFF status etc.

that's max 30 params in total.(full extra - and use 5 parameter / sensors)

Make sub VI s - 5 minutes per piece. I'm done with this.

The Main program always uses these Sub VI's. I don't need to do this anymore. Indeed, this should be done for all sensors. It's 5 -6 different types on one machine.. e.g. a tank with a level sensor valve is 2 types (2 level sensors that are the same, and 2 valves that are the same). Add a flow sensor, proportional valve actuator, relays .. then 4 types.

If there were 30 - 40 variable types, such and such sensor, actuator, I might have chosen the IODD scan. Fair enough. For projects like that, there is no better software than yours. That's a fact. This not a hobby projects. 🙂  IOT .. System monitoring, daq.  Thank you too.

[grezoo]

" What about device validation with the ProductID, DeviceID, VendorID, serial numbers?" 

Each IO link device has ca 16 -26 indexes in a row of identifiers. I scan them all with a for loop. 🙂 And store them in a claster. It takes 2 minutes.

whichever index you enter, you will get the result. It's not complicated.

But what is complicated, and that's why your software is good, because the result is hexadecimal. And some parameters, like the temperature, are complicated. From the result. If you are not good at math 🙂 The IODD includes the method of decryption. I had to find that out. I had to read the datasheet. Your software does this automatically. Great.
My choice to do it this way is simple. I don't have to deal with 100 different products. And the ethernet master is more convenient than Profibus and all the rest. For simple projects. That don't endanger human life. Data collection, and IOT .. 

Temperature data conversion: 

Your software, if I set the IODD file, will automatically calculate based on the bit values in the IODD. I like it, but it wasn't such a big calculation that I was afraid of it 🙂 I might use it for bigger, more tasks.