ec_slave.outputs is changed in ec_receive_processdata

[alexanderivanov1112]

Hi everyone!

I'm working with Delta servos, and globally it works fine. But sometimes there is strange behaviour - drive falls from ServoOn state without any reason. It just changes StatusWord to previous state.

While debugging this issue I found that reason is that outputs (ec_slave.outputs) are changed in ec_receive_processdata. I added simple code that compares this array before and after calling of this function. And some values (ControlWord in my case) become changed.

If I understand it right, this array should not be changed by drive, because it's data direction is from master to slave. But actually it does. Am I doing something wrong, or is it drive bug, or maybe some SOEM bug that was already fixed? I use SOEM version dated approximately 2019.

[nakarlsson]

No bug in SOEM I’m aware of.

Sounds like something overflows, I suggest you do some deeper debugging. There is a small window in receive process data that read data back to inputs. Outputs are not written to and are in front of inputs.

Also, verify that the .outputs and .inputs pointers don’t change? They are the Source and Destination into the IOmap.

If it happens frequently it should be easy to find if doing some instrumentation.

[NevolinAlexander]

I have spent some time for debugging and found that change of first byte of ec_slave[].outputs happens here: in function ecx_receive_processdata_group, in string:

memcpy(context->idxstack->data[pos], &(context->port->rxbuf[idx][EC_HEADERSIZE]), context->DCl);

(can't give it's number because it was changed while modifying code for debugging purposes)

It's hard for me to undestand what it's doing, can you explain it? And maybe you have some ideas about reasons of my problem.

[NevolinAlexander]

Also I found that problem appears when I change PDO structure (using SDO_write as described in servo manual) AND it's size changes (for example I exclude on of parameters). If I change something and size remains the same (for example I replace on int16 parameter with another uint16 parameter), there is no problem.

[ArthurKetels]

That code line you showed 2 posts above is not part of the current code base. So perhaps update to the latest version?

[NevolinAlexander]

Yes, you're right. I used version of summer 2019 (approximately). In current version this is line 1950 of ethercatmain.c.

I've tried to update code (updated whole folder 'soem'), but problem remains the same.