[etherlab-users] problem in using new BeckHoff encoder EL5101
Jason Xu
jason at motiondesign.co.nz
Fri Jul 24 06:22:58 CEST 2009
Hi Florian:
On Tue, Jul 14, 2009 at 03:30:04PM +1200, Jason Xu wrote:
> > I've found EL5101 modules with the following serial numbers have this
> > problem:
> >
> > Serial number: 27091510
> > Serial number: 20091510
>
> Ok, these are quite new. It seems to be a bug in the slave
> implementation. Just to be sure, please cross-check it with the newest
> master version available.
>
> http://etherlab.org/download/ethercat/ethercat-devel-r1812.tar.bz2
>
> If it shows the same behaviour, please tell Beckhoff about this.
>
> BTW, you should probably be able to configure the slave with the 'old'
> PDO configuration from the former slave versions. The master will
> complain, because the PDO configuration will fail, but the process data
> should be exchanged. Have a try.
>
Now, this problem has been worked around by modifying ethercat master code.
Just like you said that the pdo data in the module seems very wrong, and we
cannot do anything about it. Therefore, we modified the master code in a
place where the pdo entry is checked, and overwrite with the correct pdo
data in there (if it is a EL5101 module). And this makes the module working
as expected.
The modified function "ecrt_slave_config_reg_pdo_entry" of
master/slave_config.c is added below.
int ecrt_slave_config_reg_pdo_entry(
ec_slave_config_t *sc,
uint16_t index,
uint8_t subindex,
ec_domain_t *domain,
unsigned int *bit_position
)
{
uint8_t sync_index;
const ec_sync_config_t *sync_config;
unsigned int bit_offset, bit_pos;
ec_pdo_t *pdo;
ec_pdo_entry_t *entry;
int sync_offset;
int entry_count = 0 ;
if (sc->master->debug_level)
EC_DBG("ecrt_slave_config_reg_pdo_entry(sc = 0x%x, index = 0x%04X, "
"subindex = 0x%02X, domain = 0x%x, bit_position = 0x%x)\n",
(u32) sc, index, subindex, (u32) domain, (u32)
bit_position);
for (sync_index = 0; sync_index < EC_MAX_SYNC_MANAGERS; sync_index++) {
sync_config = &sc->sync_configs[sync_index];
bit_offset = 0;
// ================= added =====================
if (sc->product_code == 0x13ED3052){
list_for_each_entry(pdo, &sync_config->pdos.list, list) {
list_for_each_entry(entry, &pdo->entries, list) {
EC_DBG("debug 0x%08X",sc->product_code) ;
if (entry_count == 0) {
entry_count ++ ;
entry->index = 0x7000 ;
entry->subindex = 1 ;
entry->bit_length = 8 ;
}
else if (entry_count == 1) {
entry_count ++ ;
entry->index = 0x7000 ;
entry->subindex = 2 ;
entry->bit_length = 16 ;
}
else if (entry_count == 2) {
entry_count ++ ;
entry->index = 0x6000 ;
entry->subindex = 1 ;
entry->bit_length = 8 ;
}
else if (entry_count == 3) {
entry_count ++ ;
entry->index = 0x6000 ;
entry->subindex = 2 ;
entry->bit_length = 16 ;
}
else if (entry_count == 4) {
entry_count ++ ;
entry->index = 0x6000 ;
entry->subindex = 3 ;
entry->bit_length = 16 ;
}
}
}
}
// =================== end ======================
list_for_each_entry(pdo, &sync_config->pdos.list, list) {
list_for_each_entry(entry, &pdo->entries, list) {
EC_DBG("entry_debug(index = 0x%04X, "
"subindex = 0x%02X, bit_length = 0x%x)\n",
entry->index, entry->subindex,entry->bit_length );
if (entry->index != index || entry->subindex != subindex) {
bit_offset += entry->bit_length;
} else {
bit_pos = bit_offset % 8;
if (bit_position) {
*bit_position = bit_pos;
} else if (bit_pos) {
EC_ERR("PDO entry 0x%04X:%02X does not byte-align "
"in config %u:%u.\n", index, subindex,
sc->alias, sc->position);
return -EFAULT;
}
sync_offset = ec_slave_config_prepare_fmmu(
sc, domain, sync_index, sync_config->dir);
if (sync_offset < 0)
return sync_offset;
return sync_offset + bit_offset / 8;
}
}
}
}
EC_ERR("PDO entry 0x%04X:%02X is not mapped in slave config %u:%u.\n",
index, subindex, sc->alias, sc->position);
return -ENOENT;
}
If you think there is a better way to fix or work around this problem, we'd
appreciate your advice. But, ultimately, our understanding is Beckhoff would
need to change the firmware in future.
Thanks for all your help.
Jason Xu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20090724/e5f653a3/attachment-0004.htm>
More information about the Etherlab-users
mailing list