Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ScanDevices stucks in endless loop #57

Closed
XzuluX opened this issue Feb 17, 2021 · 9 comments
Closed

ScanDevices stucks in endless loop #57

XzuluX opened this issue Feb 17, 2021 · 9 comments

Comments

@XzuluX
Copy link
Contributor

XzuluX commented Feb 17, 2021

The adapted ScanDevices function stucks in endless loop on my current configuration. I have to investigate further to check the root cause, but it seems commit 9ad66bb Wait for PREOP before accessing EEPROM broke something on ScanDevices logic. If I revert to commit b393404 all is working as expected ... any idea?

@Apollo3zehn
Copy link
Owner

So PREOP is never reached? The only changed lines are: https://github.com/Apollo3zehn/EtherCAT.NET/blob/master/native/SOEM_wrapper/soem_wrapper.c#L562-L566
I need to update these to throw a timeout error instead of looping forever. I´ll check also against my test slaves.

@XzuluX
Copy link
Contributor Author

XzuluX commented Feb 17, 2021

Yes PREOP is never reached, if I comment out these changed lines of code its working ;)

@Apollo3zehn
Copy link
Owner

I found the solution, it is required to check for EC_STATE_PRE_OP | EC_STATE_ACK instead of EC_STATE_PRE_OP alone. I´ll publish an update soon.

@Apollo3zehn
Copy link
Owner

Should be fixed now with commit 4c8a647 :-) Sorry for the confusion.

@XzuluX
Copy link
Contributor Author

XzuluX commented Feb 18, 2021

@Apollo3zehn I just recognized your fix increased the master start time significantly. I currently have four slaves and it now takes approx. 25s compared to 5s before.

If I change the code like this, master start time goes back to 5s. The differece is to explicitly call ecx_writestate(context, 0) and only check for EC_STATE_PRE_OP.

Do you think it's a proper solution ?


// wait for all slaves to reach PREOP state
int counter = 200;
context->slavelist[0].state = EC_STATE_PRE_OP;
ecx_writestate(context, 0);

do
{
    ecx_statecheck(context, 0, EC_STATE_PRE_OP, 5 * EC_TIMEOUTSTATE);
} while (counter-- && context->slavelist[0].state != EC_STATE_PRE_OP);
               
if (context->slavelist[0].state != EC_STATE_PRE_OP)
    return -0x0104;

@Apollo3zehn
Copy link
Owner

Apollo3zehn commented Feb 18, 2021

I have also noticed an increase in startup time but I thought it was caused by my network card driver. I´ll check that tomorrow.

@Apollo3zehn Apollo3zehn reopened this Feb 18, 2021
@Apollo3zehn
Copy link
Owner

We could also skip the automatic state change in SOEM ( https://github.com/OpenEtherCATsociety/SOEM/blob/d9261e801d109eaf99b94907b6d24bac4a123968/soem/ethercatconfig.c#L593) and do it ourselves later. The thing is that I don't know why EC_STATE_ACK is required.

I have slaves devices available for testing on monday, unfortunately not tomorrow.

@Apollo3zehn
Copy link
Owner

I think I found the issue:

At the end of ecx_config_init (called from within ScanDevices), SOEM requests the PreOp state + EC_STATE_ACK flag (0x02 + 0x10) (https://github.com/OpenEtherCATsociety/SOEM/blob/v1.4.0/soem/ethercatconfig.c#L596-L600).

Back in ScanDevices we try to check if that state has been reached within the timeout using ecx_statecheck. The problem is that ecx_statecheck just checks for the actual state (0x02) and not the flag.

Opposed to that, slavelist[0].state contains both, the state and the ACK flag (0x02 + 0x10).

Therefore my previous solution could not work and instead it should probably look like I did it here: 2f1ee3c
With my test slaves, I could reduce the time to a few milliseconds for the INIT->PREOP transition. Does this solution also work for you?

@XzuluX
Copy link
Contributor Author

XzuluX commented Feb 24, 2021

Great, thank's for solving this issue, now the performance is much better! Yes this works for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants