PDO data mismatch problem

[Lyamachine]

Hi there, Recently, I've made a simple demo to control a servo motor wth SOEM. Everything seems fine except that the motor fails to run. Then, I did littile research about ethercat frame, PDO Configurations, Sync state etc but still no results. The inconsistency I found is that the data in RxPDO does not match the data in RxPDO that's why I choose this title. By the way, the status code 0x210 means power on and CANopen control according to motor manual. I just wonder did anyone encounter the same issue. Code and wireshark captures attached below.

1.source code motor.zip

2. running results capture

   

3. wireshark capture ethercat_capture_1.zip

4. slave info capture

   

Sincerely, Lya

[Lyamachine]

As you can see from 1.source code and 2. running results capture, status word and mode display did not make any change after I specify control word with 0x06->0x07->0xf and mode 0x03. At least I think the motor should be in an enabled state, but it doesn't respond at all.

[ArthurKetels]

Common mistake in the motor.cpp code. The PDO structs for input and output need to be packed, otherwise the compile will adjust all elements of the struct to 32bit or 64bit boundaries. See how it is used is the example code. For GCC you need PACKED and for visual studio PACKED_BEGIN and PACKED_END. You can also search the issues for these keywords to see more.

[Lyamachine]

Thanks for your reply Arthur, I've already added #pragma pack(1) and pack() for RX/TXPDO struct, now data alignment is okay.

But the motor still doesn't move. So i read about issue #692 and checked about some parameters like position window, there is nothing wrong with them. My doubt is that why all parameters have been set successfully in ec_slave[1].outputs(RXPDO) e.g control word, mode etc whreaz ec_slave[1].inputs(TXPDO) makes no change. Then I mapped target position(0x607a) both into RXPDO and TXPDO. This parameter remains zero in TXPDO no matter what value I specified in RXPDO. F.Y.I ec_SDOwrite manages to set the target position and been read by TXPDO.

[ArthurKetels]

A first check should be to rotate the motor by hand and see if your position inputs are updating.

[Lyamachine]

After rotating motor by hands, it is clear to see changes of Position Actual Value(0x6064). The PDO configuration is fine. I revised my state check thread function like below, ec_statecheck() added:

OSAL_THREAD_FUNC stateRecheck() {
    while (run) {
        ec_statecheck(1, EC_STATE_OPERATIONAL, 20000);
        printf("\ncurrent state: %x", ec_slave[1].state);
        if (ec_slave[1].state != EC_STATE_OPERATIONAL && checkstate) {
            ec_slave[1].state = EC_STATE_OPERATIONAL;
            ec_writestate(1);
            printf("\nRe-enter into op state: %2.2x\n", ec_slave[1].state);
        }
        else {
        }
        osal_usleep(22000);
    }
}

Then I got results:

Now the real problem is Sync Loss. 0x1c32:02 and 0x1c33:02 indicates both cycle time equals 0 which is not correct. I will search for all sync related issue and probably hints will show up.

[ArthurKetels]

Sigh, inventing solutions for problems you do not understand is mostly not very effective. First understand your problems. I have very little to go on, but from the above conversation it seems you could do with some more basic understanding of EtherCAT in general. And more specific about implementations of EtherCAT motor controller slaves.

Key points:

• Windows is possibly the worst OS to implement a real time controller on. The likelihood of failure is very high.
• Check the slave manual about the operation modes available, freerun and/or synchronous.
• If only synchronous is supported you have to provide a strict sync between master and slaves. Rule of thumb is that master packet jitter is below 10% of cycle time.
• Second you have to program the SYNC0/1 generator in the slave to fire in regular intervals. This is what's probably wrong in your application, the slave can not go to operational until it sees a few SYNC0 pulses.
• Third you have to maintain sync between mater application and slave during the whole OP state.