How to generate the wake-up request pulse (WURQ) with an L6360?

[JHutt.1511]

I simply can't figure out how to generate this pulse with my STEVAL-IOM001V1 board. Even the supplied code (en.stsw-iom001) doesn't make me any wiser.

[SLee.71]

Sorry. I made a mistake there. Yes, it is "Diagnosis" but it still doesn't work for me. Do I have to switch it OPERATE before this can work?

But I am having a hard time writing to the sensor. I tried writing to "MasterCycleTime" which is both readable and writable but it is not successful.

I'm using this sensor

https://www.wenglor.com/wenglor/catalog/productDetail.jsf?wec-appid=Shop_1000_EXT_EN&wec-locale=en_US&itemKey=P1KH025&ifr=y

[LHaim]

Wait, so you can read from the sensor , for instance can you read the minimum cycle time value ?

But you can't write the master cycle time ?

Bear in mind that the 0xCA message that I am sending was taken specifically from the datasheet of the sensor that I am using, perhaps you need to write a different message to get the process data from the sensor you're using.

I don't know if "OPERATE" is the issue here since I am not sure if I switched to OPERATE myself yet, that is one of the questions that I previously asked @TSerr.1​ .

[SLee.71]

Yes. I can read MinCycleTime but unable to write to MasterCycleTime.

I believe you have not entered into OPERATE mode as the cyclic data exchange is not started.

Have you tried writing the value "0x99" to address "0x00" (MasterCommand)?

[TSerr.1]

@LHaim​ 

1) The only way I can think of to check if the device is in operate mode is to send M-Sequences of type 2. This sequence will only trigger a response if you're indeed in OPERATE mode.

2) Regarding the TYPE_2_V, Table A.1 shows which values you should set according to the sequence type. It only asks for major version of sequence type (0,1, 2) and not its subtype (*_[1,2,3,..,V]).

3) You might have gone lucky by having an answer with MC = 0xCA, the datasheet of your sensor stipulates that 0xCA is the address of the parameter. Given the range of that parameter (>5bits) is an ISDU parameter address (Table A.15). This parameter allows to switch from measurement type to smart-sensor-profile type process data (the two definitions of PD you have at the top of the datasheet). The answer, you get however contains the 3 bytes PD data as it is transmitted at each cycle along the CKS and here with an additionnal OD byte.

4) Regarding the cyclic exchange: The device will never init a cycle and start sending data on its own, the master (your software) is responsible to lead the sensor by operating it in a cycle (and eventually other sensors in the same cycle but different uarts).

This means that you should implement a loop with a timing of MasterCycleTime (in my case for ex. 3.1ms), in each loop, your device has to send an MC + CKT. If your program fails to send a message cyclically or takes too long (>10% of MasterCycleTime) the device will consider that the communication is lost (COMLOST) and will switch back to STARTUP mode, prohibiting you to access to your measurements.

To get my process data I use an ISDU channel, MC = 0xF1, the answer is 4 bytes: 3PD + 1CKS, this should work as well for your sensor.

If you don't have ISDU Support @SLee.7​ , you should be able (untested) to use an MC = [read = 1, comm. channel (process) = 00, address = 0x00] and CKT = [seq. type (2) = 10, ck6]. This message has to be transmitted at each cycle.

Basically, the ARM I am using to control the L6360 is used only as a bridge to another device. The master program runs infinitely on it (with some fallback procedures to auto restart when com is lost for example) reads the sensor's data through IO-Link and sends it through another interface (UART, USB, I2C as you like) to another device which can read the data as it comes without any IO-Link protocol stuff nor strict timing constraints.

A lot of hassle, but usually for next-level sensors, I don't regret :)

[SLee.71]

@TSerr.1​ Thanks for reply. My device does not support Type 1 and Type 2. Only Type 0 is supported.

I have tried writing to "MasterCycleTime" but the value in it is not updated when I read it.

However, when I write to "Direct Parameter Page 2" which contains some parameter to control my sensor, the value in the parameter is updated and my sensor is responding accordingly.

I am out of idea out how to approach my problem.

[TSerr.1]

@SLee.7​  Where have you read that it only supports TYPE_0 ? That seems impossible as your sensor has a 2 byte PD, in any case TYPE_0 won't fit 2 bytes of data.

Are you reading 0x30 for the MinCycleTime ? Your sensor has a 4.8ms min. cycle time, you should try communicating with a loop of cycle >5ms to it. Don't bother writing to MasterCycleTime, but actually reading from it might be more interesting.

[SLee.71]

@TSerr.1​  When I read "M-sequence Capability" (0x03), it return a value of '0'. So I thought that other types other than TYPE_0 is not supported. After I look more carefully into the IO-Link specs, I see that this is not the case.

And your point of my PD being 2 bytes is a legit point to look into. I will check again on this point.

Yes. MinCycleTime has a value of 0x30. When you say communicate, do you mean reading from any parameter or writing to a certain parameter?

Reading MasterCycleTime always return 0x00. Even if I write another value to it, there is no change to the value. Therefore, I try with RevisionID instead, which return with a value of 0x11 (correspond to version 1.1 which is correct). Still no change after I attempt to write a value to it.

[LHaim]

@TSerr.1​ 

1. I do get a response when I send M-Sequence type 2 messages.
2. Cool.
3. True. By the way I tried (and failed) writing to it to change it to smart-sensor-profile.
4. I'm confused. If in cyclic operation the master still needs to initiate each process data reading from the sensor, than what is the difference between cyclic and acyclic ?
   1. Also I should point out that I am able to read from the sensor (in the manner I mentioned before) without paying much attention to timing constraints. I can wait 5 seconds between reads it still works.
   2. As you suggested I tried sending MC = 0xF1 to the device and I still get the same 5 bytes answer as before.

But what really bugs me is this cyclic/acylclic confusion that I have, I don't get it...

In any case, thanks a lot for you help :)

[TBobr.1]

Thanks to all of those who have contributed to this post - it has been extremely helpful in getting oriented with the L6360. I am stuck on communicating with my IO-Link device (LTF Laser Sensor), and I am hoping someone will have some advice for further trouble shooting. I purchased the P-NUCLEO-IOM01M1 which contains the STEVAL-IOM01M1 and the F446RE nucleo. I would like to drive communication w/ an Arduino Uno instead of the Nucleo board, so I have connected the Arduino Uno to the headers on the nucleo board w/ the following pin mapping:

Arduino GND -> CN6-pin6

Arduino SDA -> CN5, pin10

Arduino SCL -> CN5, pin9

Arduino RX -> OUT_C/Q (CN9, pin3)

Arduino TX -> IN_C/Q (CN5, pin1)

Arduino pin 2 -> L_plus_on (CN9, pin6)

Arduino pin 3 -> EN_L_plus (CN5, pin5)

Arduino pin 4 -> EN_C/Q (CN8, pin6 )

I connected my power supply and IO-Link device to the appropriate terminals. Then I uploaded the attached program to the Arduino. It should be powering on the sensor, writing the configuration register to put the device in push-pull mode, reading the status/parity registers, then reading the min-cycle time. I know that the baud-rate of the sensor is 38400, and the min cycle time should be 2.3ms according to the config file for the sensor (attached). Unfortunately, I am getting two replies from the sensor, both of which are "0b11111111". I expect the answer to be "00010111" which corresponds to a 2.3ms min cycle time. Instead, I am getting "11111111" and "11111111" returned.

I am able to write the MSB/LSB for the LEDs to power them on, so the I2C should be working correctly. Now I think it may be an issue with the UART communication. Thanks for any assistance you can provide.

[ASanc.1]

Hi,

it seems that I've been having problems while trying to generate the WURQ.

In my case, it seem the WURQ has been partially generated and I don't know why.

I attach an oscilloscope capture with two signals: YELLOW => C/Q and PINK => I2C DATA.

In the capture you can see that I made a communication through I2C, then the WURQ seems to be partially generated, and then I write the command 0xA2 0x00