[Etherlab-users] ecrt_sdo_request_state : error

Tue Oct 26 00:00:12 CEST 2021

No, in fact you must not call ecrt_sdo_request_write on each cycle; you must call it only to begin a write.

The proper sequence is:

 1.  Call ecrt_sdo_request_index[_complete] to set the SDO to write (not required if this is the same SDO as the previous request / when created).
 2.  Call ecrt_sdo_request_data and write the data value to be written by the request into this buffer.
 3.  Call ecrt_sdo_request_write[_with_size] to begin the write request.
 4.  Each subsequent cycle, call ecrt_sdo_request_state to check the progress - do not call any of the above again on the same object while the status is EC_REQUEST_BUSY.
 5.  After completion, you may stop calling ecrt_sdo_request_state (although it's harmless if you continue), and you may start over at #1 again on any subsequent cycle.

#1-3 happen in the same cycle.  You don't have to do #4 on every cycle, but you must not try to use the request object again in any other way until the request is completed (with success or error).  You can have multiple request objects active for a single slave at a time, but bear in mind that they will happen in series, not parallel.  (Multiple requests for different slaves will happen in parallel, although only up to a preset concurrency limit.)

Since this is asynchronous functionality, you may find it useful to implement it with a state machine, although this is not required.

Gavin Lambert

Senior Software Developer TOMRA Fresh Food

[cid:TOMRAFresh_final_size_times_two_2_99d242b2-ba06-4c25-ab26-020cca7ee6dd.png]
 [cid:TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg] <https://www.facebook.com/TOMRAFreshFood>  [cid:TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg] <https://www.linkedin.com/company/tomra-fresh-food/>  [cid:TOMRA-Vimeo_4673038e-313a-491f-b3a4-0b39ace6df88.jpg] <https://vimeo.com/tomrafreshfood>  [cid:TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg] <https://www.instagram.com/tomrafood/>
 Compac Technologies Ltd | 4 Henderson Place | PO Box 13 516 | Onehunga 1061 | New Zealand

 Phone: +64 96 34 00 88 | https://www.compacsort.com
The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
From: BUSSIERES Vincent
Sent: Monday, 25 October 2021 08:55
To: etherlab-users at etherlab.org
Subject: [Etherlab-users] ecrt_sdo_request_state : error

Dear Etherlab users,

I use a Beckhoff module EL5102 (2 channels encoder interface) and two servodrives to control motors.

I develop a homing sequence as below :

1- Enable counter reset on channel 1 when index encoder is encountered

2- Move axis 1 until index is encoutered

3- Unable counter reset on channel 1

4- Enable counter reset on channel 2 when index encoder is encountered

5- Move axis 2 until index is encoutered

6- Unable counter reset on channel 2

Unabling and disabling counter reset is done using SDOs 0x80n0:01 where n is the channel number.

In my program, I create 2 SDO requests with « ecrt_slave_config_create_sdo_request » before changing master state in OP with « ecrt_master_activate ».

Then, before entering in cyclic task, I write SDOs for the first time and I get « EC_REQUEST_UNUSED » SDO request state (trigger first write), it seems to be OK.

void enableIndexResetCh_n(state)

{

        switch (ecrt_sdo_request_state(mReqIndexResetCh_n)) {

                case EC_REQUEST_UNUSED:

                    ecrt_sdo_request_write(mReqIndexResetCh_n);

                    break;

                case EC_REQUEST_BUSY:

                    break;

                case EC_REQUEST_SUCCESS:

                    EC_WRITE_U8(ecrt_sdo_request_data(mReqIndexResetCh1), static_cast<uint8_t>(state));

                    ecrt_sdo_request_write(mReqIndexResetCh_n);

                    break;

                default:

                    ecrt_sdo_request_write(mReqIndexResetCh_n);

                    break;

                }

                break;

}

Then, I realize homing sequence in the cyclic task as described before.

For the fisrt channel, I write « 1 » into SDO 0x8000:01, request state is « EC_REQUEST_SUCCES » but for the second channel 0x8010:02 I get « EC_REQUEST_ERROR » and SDO value remains at false state.

I don't understand why I get this error.

Moreover I want to let you know that I don't call « ecrt_sdo_request_write » at each loop of cyclic task but only when I need to change sdo state. Perhaps this is not the right way to call this function. Do I have to call this function at each iteration ?

How can I be sure that sdo state corresponds to the right state ? Do I have to read sdo state (if sdo is R/W) also at each iteration ?

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20211025/2f18df8b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRAFresh_final_size_times_two_2_99d242b2-ba06-4c25-ab26-020cca7ee6dd.png
Type: image/png
Size: 13399 bytes
Desc: TOMRAFresh_final_size_times_two_2_99d242b2-ba06-4c25-ab26-020cca7ee6dd.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20211025/2f18df8b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg
Type: image/jpeg
Size: 10123 bytes
Desc: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20211025/2f18df8b/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg
Type: image/jpeg
Size: 10214 bytes
Desc: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20211025/2f18df8b/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRA-Vimeo_4673038e-313a-491f-b3a4-0b39ace6df88.jpg
Type: image/jpeg
Size: 1540 bytes
Desc: TOMRA-Vimeo_4673038e-313a-491f-b3a4-0b39ace6df88.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20211025/2f18df8b/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg
Type: image/jpeg
Size: 10303 bytes
Desc: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20211025/2f18df8b/attachment-0007.jpg>