Distributed Clock with Groups

Wanga commented 1 year ago

Hi,

We group the slaves in the system by blockLRW flag and send process data by ec_send_overlap_processdata_group(OVERLAP_GROUP) and ec_send_processdata_group(NON_OVERLAP_GROUP).

Topology

1st slave (EK1100) : in OVERLAP_GROUP, support DC, no PDO input and output 2nd ~ 5th slave (motor) : in NON_OVERLAP_GROUP, support DC.

Issue

DC system time and diff (reg 0x910, 0x92C) in slave 2nd~5th is always zero after PDO cycle started

Cause

Since 1st slave has DC, ec_configdc() set

context->slavelist[0].DCnext = 1
context->grouplist[OVERLAP_GROUP].hasdc = true // note that NON_OVERLAP_GROUP will not be true even it has dc

In ecx_main_send_processdata(), no FRMW is sent because:

with use_overlap_io = true, no EC_CMD_LWR and EC_CMD_FRMW sent because length is 0
with use_overlap_io = false, no EC_CMD_FRMW sent because grouplist[NON_OVERLAP_GROUP].hasdc is false

A workaround is adding a card with PDO input/output under OVERLAP_GROUP, since it makes length not 0.

ArthurKetels commented 1 year ago

The configuration makes no sense. Why make a group with IO length zero? Simply add the EK1100 to the non overlap group. The other solution is to remove the DC flag from the EK1100. Then the second slave will be automatically become the clock reference.

Wanga commented 1 year ago

We understand there are serveal ways fix the issue on this particular topology.

Master has to handle 3 types of slaves

Slave need to be overlap (blockLRW = false, #666)
Slave can be both (blockLRW = false)
Slave need to be non-overlap (blockLRW = true)

The reason we group the slaves by blockLRW flag is that master don't have to record all type 1 slaves, just treat as type 2. This rule with this particular topology creates the grouping in this issue. Hope this make sense.

We can surely add serval rules to group device differently like your 1st suggestion. But comaparing to make group base on topology/device type/group length/DC, maybe it's make more sense to require master to know which devices need DC then assign the reference slave with an API.

Removing hasDC flag will work. We didn't manipulate data in ec_context since we think it's designed to record the status, not to affect the behavior of SOEM. If hasDC flag is designed to be manipulated between ec_config_init and ec_configdc, we will follow.

One suggestion for troubleshooting is the return value, with zero group length, ec_receive_processdata_group returns wkc 0. maybe it should change to -1, because "no read/write" is not the same as "no command sent/receive (including FRMW)".

OpenEtherCATsociety / SOEM