Statusword doesn't change value. Slave keeps going forever.

[dariolisi]

Hello everyone!
I'm pretty much new to SOEM and I'm using it on single robotic joint to make some tests.

So, the issue is that I'm able to set the joint up and communicate with it pretty well: I set the mode of operation (profile position) and he receives the right parameters and starts moving in the right direction. The state machine should be good from the documentation.

The only problem is that once it starts moving, it never stops except for position 0. It is able to return at 0 and stopping but, even in that case, bit 10 of statusword (target reached) never goes to 1. It looks like it is trying to follow an infinite point.

Moreover, if I print the actual position (and also velocity) it always carries out incoherent numbers (one positive and the next negative) except, again, for zero.

I also want to add that I have tested it on TwinCAT and it works perfectly fine in all its aspects but i wanted to use it with SOEM for more flexibility.

Thank you in advance to those who will help and have a great day!

[ArthurKetels]

From the top of my mind this looks like a data type issue. Like int32 or float mixed up. For zero both are the same, for other values this is not the case. Or you have forgotten to make the data structure packed, what results in alignment issues. Or you have forgotten to set enough torque to reach the intended velocity and position.

I do not think this is a SOEM issue, as the communication seems to work fine.

[dariolisi]

Thanks a lot! I already thought about that issue but maybe I didn't notice something. I'll look into that as soon as I get to the lab! I have also seen that statusword now, after setting position window (which I didn't before), changes value of bit 10 when it gets to 0. This does not happen on other positions because the reading of the position is still fuzzy.
In the meantime thank you again!

[dariolisi]

The statusword issue was solved by applying a position window explicitly (because default value was 0). Meanwhile, the fuzziness of the reading was due to the exact issue that Arthur was pointing out! The data alignment was not good for the struct. I solved just by:
#pragma pack(1)
before the struct and:
#pragma pack(reset)
after the struct.

Thanks a lot again.