Re: [etherlab-dev] Beckhoff AX5000 SoE drive: The PDI has no access rights to the ESC eeprom.

2015-07-12 Thread Gavin Lambert
On 11 July 2015 12:38, quoth Nuno Gonçalves:
> I'm running etherlab master default branch and it is making the Beckhoff
> AX5000 SoE drive unhappy.
> 
> When changing state to PREOP the drive complains with the following error:
> 
> External Periphery - Control card: Reading the ESC-eeprom failed: The PDI
> has no access rights to the ESC eeprom.
> 
> This happens before any IDN and DC configuration are due (transition to
> SAFEOP).
> 
> Trusting the error message, what kind of ESC-eeprom reading are we
> requesting on the transition to PREOP that can be causing this issue?
> 
> I can try to Wireshark this and TwinCAT initialization to compare both,
and
> see if I can spot the issue, but I don't think that will work very
easily...

It's not Etherlab trying to read the EEPROM, it's the slave itself trying
to.  ("PDI" is the slave's interface to its own ESC.)

By default, Etherlab reserves SII (EEPROM) access to ECAT only; the PDI can
only access its EEPROM before it brings the ESC out of reset.

Try passing "--enable-sii-assign" to configure; this tells Etherlab to grant
the PDI access to its EEPROM at specific times, including during PREOP.

At the moment the implementation of this is not standards-compliant, but it
should hopefully be sufficient for most cases; so it should resolve your
issue.


___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev


Re: [etherlab-dev] [PATCH] My patchset roundup July 2015

2015-07-12 Thread Gavin Lambert
On 13 July 2015 10:20, quoth Graeme Foot:
> Re: gavinl-2004-sdo_write_size.
> 
> What I have been doing to allow one SDO Request object for all data sizes
is
> to call ecrt_sdo_request_read() every time before calling
> ecrt_sdo_request_write().  This sets the size specific to the object you
are
> about to write at the expense of extra time and processing.  It does
however
> ensure the size is matched correctly to the object you are about to write
to.

Sure, that would work too, given the way that reading changes the next write
size.  And it's true that most of the time I do a read first in any case to
check the current value (which may affect whether I do the write at all).

But writing without a prior read still seems like something you should be
able to do, and the read changing the write size is technically an
implementation bug that I wouldn't want to rely on.

> Also as you say, the SDO Request must be created with the largest expected
> data size.  The largest I have come across so far is a STRING[16] (16
bytes).
> Has anyone seen larger?

Strings can be longer than that of course, but the other time that you may
get larger values is when using Complete Access (via the other patches).
The motivating example was reading an entire array at once, which was about
40 bytes.


___
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev


Re: [etherlab-dev] [QUARANTINE] [PATCH] My patchset roundup July 2015

2015-07-12 Thread Graeme Foot
Hi,

Re: gavinl-2004-sdo_write_size.

What I have been doing to allow one SDO Request object for all data sizes is to 
call ecrt_sdo_request_read() every time before calling 
ecrt_sdo_request_write().  This sets the size specific to the object you are 
about to write at the expense of extra time and processing.  It does however 
ensure the size is matched correctly to the object you are about to write to.

I like the idea of this change for speed but I would probably still be calling 
ecrt_sdo_request_read() before the first write to confirm things are as 
expected.

Also as you say, the SDO Request must be created with the largest expected data 
size.  The largest I have come across so far is a STRING[16] (16 bytes).  Has 
anyone seen larger?


Regards,
Graeme.


-Original Message-
From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of 
Gavin Lambert
Sent: Friday, 10 July 2015 7:14 p.m.
To: etherlab-dev@etherlab.org; Florian Pose
Subject: [QUARANTINE] [etherlab-dev] [PATCH] My patchset roundup July 2015
Importance: Low

Hi all,

It's been a while since I last posted my current patchset for Etherlab, so it 
seemed like a good time to share the newest ones.

As with the last set, this is based on stable-1.5 (specifically
4b0b906df1b40a1b5610282117b2c22581890575) and contains both my own patches and 
patches from others in the community, and I'm sharing them in case people find 
them useful and that hopefully they'll make it into mainline.

Having said that, it appears that some of the patches in here have made it into 
the default branch already; I haven't had time yet to inspect them and rebase 
my patchset onto that branch, but it's on my TODO list. :)

The series file included in the archive shows the intended application order 
(though you'll probably want to skip some of them if you're on default already).

Short descriptions (commit notes) are at the top of each patch; detailed 
descriptions for the older patches can be found in previous emails, but I'll 
give a bit more background on the newer patches below.  The older patches are 
unchanged except for possible defuzzing.

Before that though, just a reminder that patch 0006 "dc_sync_vs_sys_time" is 
only a partial fix; it works for slaves that have AssignActivate bits 0x3000 
set, and that don't mind the offset between SM events and SYNC events changing, 
but won't help other slaves -- they'll need a more comprehensive fix (fully 
recalculating the Sync Start Time).  It's probably not something I will do 
because my slaves do work with this, and I'm not sufficiently familiar with the 
way DC sync is calculated in Etherlab.

The new patches are the gavinl-2000 series, as follows:

gavinl-2001-reg_readwrite:
This adds an API "ecrt_reg_request_readwrite" and tool command 
"reg_readwrite" which will write register data and read back the values before 
the write in a single FPRW datagram.  This can be useful to ensure that the 
data is coherent and you don't miss an update.  It assumes Knud's rt-mutex 
patch has been applied; if not you'll have to switch the locking calls back.

gavinl-2002-reg_req_info:
This enhances some of the debug-level logging for register requests.

gavinl-2003-sdo_complete_upload:
This adds an API "ecrt_master_sdo_upload_complete" and extends tool 
command "upload" to support reading entire objects from a slave via SDO 
Complete Access (where supported by the slave).  As with the existing download 
functionality only Complete Access from subindex 0 is supported; future 
extension might be to support access from index 1 as well.  Note that when 
using the tool "upload" it will default to the "octet_string" data type, so you 
can use something like "ethercat upload -p0 INDEX | hd" to see the data 
formatted nicely.  It also assumes use of Knud's rt-mutex patch.

gavinl-2004-sdo_write_size:
This might be a little more controversial. :)  This modifies the 
"ecrt_sdo_request_write" API (so it's a breaking change) to also include the 
size of data to be written (this must be less than or equal to the size 
specified at the time the request was created).  Combined with the existing 
"ecrt_sdo_request_index" API, this allows you to re-use one request object for 
any SDO on the same slave, provided the initial size is large enough.
Previously you had to use at least one object per different object size, as 
there was no way to set the write size other than at creation time, and the 
write size was also altered whenever you did a read.  (Possible non-breaking 
alternative would be to make "ecrt_sdo_request_set_data_size" or something, but 
that seems messier.)

gavinl-2005-sdo_async_complete:
This is another breaking API change, which adds a boolean "complete"
parameter to "ecrt_slave_config_create_sdo_request" and 
"ecrt_sdo_request_index".  This allows realtime requests to use Complete 
Access; prior to this patch this was only available to the non-realtime API.
(If this