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

PDO data mismatch problem #851

Open
Lyamachine opened this issue Aug 25, 2024 · 6 comments
Open

PDO data mismatch problem #851

Lyamachine opened this issue Aug 25, 2024 · 6 comments

Comments

@Lyamachine
Copy link

Lyamachine commented Aug 25, 2024

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

  1. running results capture
WindowsTerminal_t6pR1qxCqa
  1. wireshark capture
    ethercat_capture_1.zip

  2. slave info capture

WindowsTerminal_ijaII0eD91

Sincerely,
Lya

@Lyamachine Lyamachine changed the title PDO data mismatch PDO data mismatch problem Aug 26, 2024
@Lyamachine
Copy link
Author

Lyamachine commented Aug 26, 2024

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
Copy link
Contributor

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
Copy link
Author

Lyamachine commented Aug 29, 2024

Thanks for your reply Arthur, I've already added #pragma pack(1) and pack() for RX/TXPDO struct, now data alignment is okay.
Wireshark_TmuiuTTUpG
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
Copy link
Contributor

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

@Lyamachine
Copy link
Author

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:
WindowsTerminal_xN1HKF1SNT
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
Copy link
Contributor

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.

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