[etherlab-users] write_sdo() function

[ronaldo.mercado at diamond.ac.uk]

Hi Ali,

Have you read sdos successfully already? Are you writing code using user space or in kernel space? Are you using a cyclic task?

What is the purpose of
ec_sdo_request_copy_data(sdo_server, data, size)
on success?

Are you attempting to read at the end of a successful write?
That is not really "writing" functionality.
ec_sdo_request_copy_data is not part of the user space API and the symbol shows on the master side of the code only.

HTH.
Ronaldo


From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Gavin Lambert
Sent: 28 July 2015 02:22
To: 'HASSAN ZAHRAEE Ali'
Cc: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] write_sdo() function

It's not that easy - even the read in the example is oversimplified (it assumes you always want to read), and reads are quite different from writes.

I'm not sure where you got ec_sdo_request_copy_data from, but the correct way to access the data memory of a request is with ecrt_sdo_request_data, which simply returns a pointer that you can read from or write to, eg. with memcpy or one of the EC_READ/WRITE_* macros (as shown in the example).  Although I would hope that it's obvious that you're also doing it at the wrong time.

But you're trying to create something that looks like a synchronous function, and your colleagues will probably try to use it like one if you do that, which won't work.  So don't go there.  You need to have a state machine that knows whether a write is pending or not, and your function needs to expose the fact that it's asynchronous, otherwise people will use it incorrectly.

If you really don't want to deal with asynchrony then you can still use the synchronous ecrt_master_sdo_download method to do writes - but you have to call this on a different thread than the realtime thread and it may still increase latency (and disturb the cyclic performance) of the realtime thread.  Depending on your cyclic interval and how performance-critical your EtherCAT system is, this may not be an issue for you.

From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of HASSAN ZAHRAEE Ali
Sent: Tuesday, 28 July 2015 03:47
To: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: [etherlab-users] write_sdo() function

Hi all,

I am trying to write a simplified ethercat communication module on top of Igh master for some of my colleagues who do not want to know the details of how the master works.
Based on the sdo_read() function in the examples provided with the master, I have written the following write_sdo() function:

int write_sdo(        ec_sdo_request_t *sdo,       uint8_t *data)
{
  int sdo_write_ret = 0;
  size_t size = ecrt_sdo_request_data_size(sdo);

  switch (ecrt_sdo_request_state(sdo)) {
    case EC_REQUEST_UNUSED:
      ecrt_sdo_request_write(sdo); // trigger first read
      break;
    case EC_REQUEST_BUSY:
      fprintf(stderr, "Still busy...\n");
      break;
    case EC_REQUEST_SUCCESS:
      if(!(sdo_write_ret = ec_sdo_request_copy_data(sdo_server, data, size))) {
        printf("Failed to write to SDO channel.\n");
      }
      ecrt_sdo_request_write(sdo); // trigger next read
      break;
  case EC_REQUEST_ERROR:
    fprintf(stderr, "Failed to write to SDO channel!\n");
    ecrt_sdo_request_write(sdo); // retry reading
    break;
  }

  return sdo_write_ret;
}


When compiling I get an undefined reference to `ec_sdo_request_copy_data' error. I tried adding
EXPORT_SYMBOL(ec_sdo_request_copy_data);
at the end of /master/sdo_request.c and rebuild the master, but it didn't help.

It would be great if someone could help with this issue.

Best Regards,
Ali

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20150730/f6b58097/attachment-0004.htm>