[etherlab-users] Domain offset overlap
Gavin Lambert
gavinl at compacsort.com
Thu Apr 10 01:34:09 CEST 2014
Hi Steve,
Typically you don't need to worry about data overlaps at all. I'm not sure
if the Etherlab master generates them in the first place (though your XML
output suggests that it does), but even if it does it should only do so in
cases when it is "safe". (In particular, if you have a single slave with
inputs and outputs, or you have an output-only slave followed by an
input-only slave, then it's possible to use the same physical memory in the
EtherCAT packet to store both - once the output data is "used" by a slave
that space in the packet is free to have input data filled in afterwards.)
Regarding your confusion about ecrt_slave_config_reg_pdo_entry reporting
values higher than ecrt_domain_size, this is because they are reporting
different information. The former tells you where to read or write the
values in master-internal memory to have them copied to the right place in
the EtherCAT packet. The latter tells you the size of the data in the
EtherCAT packet itself. Thus the former refers to the non-overlapped data
and the latter refers to the overlapped data.
Just don't worry about it, and use the offsets returned from reg_pdo_entry
to read/write the data. The master library will do the right things to get
that data to the slaves and back.
Regards,
Gavin Lambert
From: etherlab-users-bounces at etherlab.org
[mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Steve Hartmann
Sent: Thursday, 10 April 2014 09:52
To: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Domain offset overlap
Another confusing thing I see is ecrt_slave_config_ret_pdo_entry() reports
offsets as large as 10, but when I call ecrt_domain_size(), it reports a
size of 7. Since the PD buffer is a pointer to uint8_t, I am assuming the
size reported is in bytes.
Thanks,
Steven
From: Steven Hartmann <shartmann at militho.com>
Date: Wednesday, April 9, 2014 2:49 PM
To: Dave Page <dave.page at gleeble.com>, Etherlab Users
<etherlab-users at etherlab.org>
Subject: Re: [etherlab-users] Domain offset overlap
Hi Dave,
Thanks for the reply. I am not using TwinCAT at all. Also, please forgive
my ignorance, but what is the "LRW command".
I'm not sure how to deal with this with the etherlab stack. If it give me a
domain offset of 3 for two different slices (one input and one output), how
do I deal with this overlapped data?
Thanks,
Steven
From: Dave Page <dave.page at gleeble.com>
Date: Wednesday, April 9, 2014 2:45 PM
To: Etherlab Users <etherlab-users at etherlab.org>
Subject: Re: [etherlab-users] Domain offset overlap
In order to reduce process data size, TwinCAT overlaps the RxPDO and
TxPDO for each module, then uses the LRW command to effect the transfer. So,
I believe what you're seeing is normal.
Best regards - Dave Page
On 09-Apr-14 15:41, etherlab-users-request at etherlab.org wrote:
Message: 1
Date: Wed, 9 Apr 2014 19:41:29 +0000
From: Steve Hartmann <mailto:shartmann at militho.com> <shartmann at militho.com>
To: Etherlab Users <mailto:etherlab-users at etherlab.org>
<etherlab-users at etherlab.org>
Subject: [etherlab-users] Domain offset overlap
Message-ID: <mailto:CF6B0C97.F827%25shartmann at militho.com>
<CF6B0C97.F827%shartmann at militho.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I have written some code to parse the generated XML file from "ethercat xml"
and use that to configure the ethercat stack. The problem I am having is
the output from ecrt_slave_config_ret_pdo_entry produces overlapped offsets.
I also tried using ecrt_slave_config_reg_pdo_entry_pos with the same
results. This is a very simple test rig that has one each of DO, DI, AO,
and AI slices - all beckhoff. I have attached a file which includes the
generated XML file, the code in question, and the log output. Does anyone
know what I am doing wrong?
Best regards,
Steven Hartmann
--
_____
David Page, Chief Embedded Architect
Dynamic Systems Inc.
PO Box 1234
Poestenkill, NY 12140
Telephone: +1 (518) 283-5350 | Fax: +1 (518) 283-3160 |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20140410/d6b2f688/attachment-0003.htm>
More information about the Etherlab-users
mailing list