cancel
Showing results for 
Search instead for 
Did you mean: 

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

JHutt.1511
Associate II

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.

48 REPLIES 48

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.

0693W000000VAj8QAG.png

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

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​ .

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

0693W000000VFAwQAO.png

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

0693W000000VFBGQA4.png

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

TSerr.1
Associate II

@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 :)

@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.

@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.

@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.

@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
Associate

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
Associate II

0693W00000AMU2QQAX.pngHi,

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