[etherlab-dev] buffered mode and triple-buffer

[PAUL-SOFTWARE]

Ok i got it. Initial question is solved. Indeed, reading debug output of
the igh-master gave me e.g. a 0x26. By capturing the packets with
wireshark, the syncman outputs are in this case 0x00010026 what just
means, that's ok so far as long as the 16th bit just means enabling. 

On analysing these flags, igh-master surely wants to run a
triple-buffer-mode by default, leading the slave does not recognise it
surely. But this a another case. 

Thanks for your feedback!

 

Regards,

 

dk

 

________________________________

Von: Jeroen Van den Keybus [mailto:jeroen.vandenkeybus at gmail.com] 
Gesendet: Mittwoch, 27. November 2013 11:06
An: Koch Daniel
Cc: etherlab-dev at etherlab.org
Betreff: Re: [etherlab-dev] buffered mode and triple-buffer

 

	I am NOT a twincat-professional, 

 

Me neither, but I believe that by default the IgH master copies the SM
config stored in the SII to the slave. That includes the all-important
control word (the Data field in the Configurator dialog e.g. 0x00010026)
that also defines the buffer mode. So I'd think you must program the SII
EEPROM using the configurator. There is one catch: I see from the source
(master/sync.c) that de direction and watchdog bits get overwritten by
what you specify in the ec_sync_info_t struct, so be sure to set these
right. Also, I think that the physical address and offset are derived
from the PDOs you try to map into them.

 

Increase debugging using 'ethercat debug 1', try to run and look for the
SM: line in the dmesg log to tell you what control, address and length
values were written to the SM. It should match the ones you see in the
configurator.

 

	but if I run this configured twincat-project (see
screenshot_drive_tlgs.png & screenshot_master_tlgs.png).Depending on
analysing the ethercat-configurations runs fine with just the expected
working counter changes with twincat. It does some (IMHO) weird
sync-management with triple-buffers (see
screen_shot_drive_tripple_buffer.png in the attachments). Is there a way
to copy this behaviour with our Ethercat-Master?
	
	When I have a look in the source-code of the master, in theory,
I could change the fmmu-configuration to ask these logical-adresses as
the twincat-project does, but this is not the exact point. I do not see
how I could copy the behaviour having the slave ordered using
"triple-buffers" (what ever this exactly means).

 

The FMMU config is assembled during PDO configuration. No need to
enforce virtual addresses. The only important thing to look for here is
that the same physical addresses are used. They have defaults in the SII
EEPROM as well, but you overwrite them with ec_pdo_info_t. I think
passing NULL for these makes the master use the defaults. Some doc is in
include/ecrt.h. Same as above: check in dmesg at FMMU:.

 

 

	Btw: Ethercat itself seperates it's sync-management into buffer-
and mailbox-mode right? Am I right, If I say, the default behaviour
configuring a syncmanager for, -let's say -just exchanging pdo's, is
buffer mode?

 

The default behaviour for PDOs should be 3-buffer mode (transparant,
coherent access to a memory area) if you can live with duplicated or
skipped frames.

 

	Has anybody else experienced this problem or does anybody have a
idea what I could do?

 

I'm still in the steep part of the learning curve, so I may have said
wrong things here. Since no one answered you for about a week, I thought
to try and help you out with what I learned so far.

 

 

J.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20131203/dc1c4d05/attachment-0001.htm>