Thank you Gavin, It is entirely clear to me now.
Regards Vincent BUSSIERES Responsable Technique Logiciel [1572337113342] ZE Ma Campagne 36, Impasse Félix Nadar 16000 ANGOULEME Tel: 33 (0)9.72.40.36.52 www.hemeria-group.com<https://webmail.nexeya.fr/owa/redir.aspx?C=GK_BqKCZef7LtPZnqnd_LGYr1NG9sz4Smy3iKIwO-pXqtJC7VgzXCA..&URL=http%3a%2f%2fwww.hemeria-group.com%2f> P Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de nécessité. Ce message et les fichiers pouvant être attachés sont confidentiels, réservés à l'usage unique des destinataires et n'engagent HEMERIA sous aucune forme que ce soit. This email and any files transmitted with it are confidential, intented solely for the unique use of the recipients and don't commit HEMERIA. De : Gavin Lambert <gavin.lamb...@tomra.com> Envoyé : mardi 26 octobre 2021 00:00 À : BUSSIERES Vincent <vincent.bussie...@hemeria-group.com>; etherlab-users@etherlab.org Objet : RE: ecrt_sdo_request_state : error 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:image002.png@01D7CA4D.A92425D0] [tomra facebook] <https://www.facebook.com/TOMRAFreshFood> [tomra linkedin] <https://www.linkedin.com/company/tomra-fresh-food/> [tomra vimeo] <https://vimeo.com/tomrafreshfood> [tomra instragram] <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@etherlab.org<mailto:etherlab-users@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
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
