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.

[MG.1]

@TSerr.1​ I haven't tried it yet, I'll try it sometime.

But my MasterCycleTime is at about 8.8ms.

[MG.1]

@TSerr.1​ I haven't tried it yet, I'll try it sometime.

But my MasterCycleTime is at about 8.8ms.

[JHutt.1511]

I agree with @TSerr.1​ on the comment that the RPI is not perfect on communication and ENCQ swithing. The switching sometimes occurs too late, causing reception of carbage. @Raghava​ I have an STM nucleo-L476RG board but haven't found the time to work with it.

Nevertheless the ENCQ switching issue on the RPI, I still would expect to see the WURQ on my oscilloscope.

Got today an update of my case: STM support simply closed it. No info/links/etc; just closed it without any comment. And than they dared to ask for a satisfaction rating. Guess what I gave them :)

[LHaim]

Hi, I am also having difficulties generating the wake up sequence.

I am using the P-NUCLEO-IOM01M1 EVBs pack (https://www.st.com/en/ecosystems/p-nucleo-iom01m1.html).

I am trying to establish an IO-Link connection with an FT-10 distance sensor from SENSOPART (https://www.sensopart.com/en/products/distance-sensors/distance-sensors/ft-10-rla-60-pnsl-k4.html).

I am able to receive binary information from the sensor but not IO-Link data.

I've tried what @TSerr.1​ suggested without success, I've also tried a bunch of different configurations and nothing worked so far.

Does anyone have another suggestion on how this can be done?

[TSerr.1]

@LHaim​  are you able to communicate with the L6360 through I2C correctly (computing parity, reading/writing to registers) ? The best way to check would be to toggle the LED on the evaluation board. For example by setting LSB & MSB of LED1 which are respectively at register addresses 0x04 and 0x05 to value 0xFF (default is off at 0x00).

If not what ARM are you using to control the L6360 ?     

[LHaim]

I think I am communicating with the I2C successfully, I will try the LED thing tomorrow to make sure.

I am using a NUCLEO-F446RE board (https://www.st.com/en/evaluation-tools/nucleo-f446re.html) which uses an STM32F446RET6U (Arm® Cortex®-M4 32-bit) processor (https://www.st.com/en/microcontrollers-microprocessors/stm32f446re.html).

[SLee.71]

@LHaim​ Thank you. I am using a different stack.

However, I have found the source of my problem. I did not set the word length to "9 bits" in the UART configuration.

It worked after I correct this and nothing else.

Do you know what is the command to access the "Process Data"? I have been digging into "IO-Link Interface and System - Specification" but there is no clear instruction.

I have been using "Comm Channel = 1" and "Address = 1" but there is not response.

Apart from reading from "Direct Parameter", I can't get the device to perform anything else.

[LHaim]

@SLee.7​ 

As I stated previously this is the data I am transmitting to read process data:

dataBuffer[0] = 0xCA;   // M.C octet

dataBuffer[1] = 0xB6;   // CKT octet = type + checksum

Unfortunately this is acyclic reading (did not succeed reading cyclically yet) and in any case this might be sensor specific.

[SLee.71]

@LHaim​ This does not work for me as "dataBuffer[0] = 0xCA" has the "Comm Channel" set to "ISDU" and my device does not support "ISDU".

Thanks a lot for your help. I will see if I can come across the information to set up the device cyclically and will update you.

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

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

[DMato.1]

I am sorry.

May be my comment unsufficient. But, do you setup EVEN parity?

In your source code I seen only 38400 Bd for ioLink...

[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

[DMato.1]

Hi.

You generate to long WURQ, but amplitude is O.K..

Please, set up I2C bit rate to 400 kHz. Then WURQ will by 80 us approx..

Second problem may by with configuration of UART. You must use EVEN parity. DATA + PARITY = 9 bites.

Result for 0xA2, 0x00 you may seen bellow.

[ASanc.1]

Got it!

[ASanc.1]

I have a IFM PP7554 sensor. I want to get the pressure data and nothing else.

I've triggered the WakeUp request and I can send commands like 0xA2 0x00 (MinCycleTime), 0xA7 03 (Vendor ID), and so on.

The point is that I don't know how to get ProcessDataIn (the one in the picture)

Could anyone show an example of a byte sequence Tx and Rx to get these data?? I would be very pleased if so.

Thanks in advance