-
Notifications
You must be signed in to change notification settings - Fork 691
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
Strange behavior from EL1259 #566
Comments
Interesting problem. Knowing how TwinCAT is setting up the PDO transfers I think the problem lies in the state where the SYNC0 is enabled on the slave. In this case the ecx_context.manualstatechange = 1 is mandatory. The logic should then be something like:
I hope this helps. |
Dear Arthur, If I add a sleep after starting the ecat thread (as you suggested), the synchronization seems to drift a bit: is it a normal behavior due to the higher cycle time (1 ms) ? |
A 25K warm-up for DC should be ample. The best thing to do is to check 0x092c of your last slave during the warm-up and plot the results. You will find a very fast pull-in to almost zero and then some dampened oscillation towards zero. Your system requirements will dictate the good-enough point. If you do not care about the few last 100th of nanosecond then you could leave the warm-up phase much sooner. The actual behavior of your system depends a lot on the number of slaves and the worst case clock skew in your slave. That is why it pays off to have accurate oscillators/crystals in your slaves when doing precision time measurements.
I do not understand your remark. A sleep in the main task has no influence on the RT task. The RT task should always keep ticking and syncing to the reference slave clock. The sleep is there to insure the slave has seen enough SYNC0 events before the master requests a state change to Operational. For a measurement slave this is not so important, but it is for servo drives. Some servo drives have to check stable SYNC0 and proper phase locking of the master PDO packets before they accept Operational state. |
Dear all,
I am currently having some issues trying to get EL1259 (from Beckhoff company) working with SOEM. The problem arise in the transistion between PRE-OP to SAFE-OP (this is my guess), something to do with DC configuration. I read all the issues about DC (in particular I find very useful #487 and #520), and some of them help me to partially solve the issue. I try to be as concise as possible., trying to explain the problem.
First of all, the code
Firstly, I must clarify that ecx_context.manualstatechange = 0, so SOEM will automatically call INIT->PREOP and PREOP->SAFEOP transistion.
With the code above, the EL1259 works well also with other slaves. What I do not understand is why, if I waste some times (also stupid prints bring the same problem of ALStatusCode = 0x030) between ec_config_map and go to OPerational, the EL1259 stays in state = 0x12 with ALStatusCode = 0x030 (Invalid DC sync configuration)
A little bit of debug
When the above code is executed, what I get from my print is this
. All okay, but only few packets for synchornization are sent (it works, but I don't like and I don't think this is a common behavior).
When I raise chk (line 1) what I get is:
Apparently no problem, but the slave didn't manage to go in SAFE-OP.
When I check for state SAFE-OP (line 2), what I get is:
.
So, I think that the problem is how I configure the DC synchronization, even if I think it is set according to the ESI.
Additional information
While here another outputs from red_test rteth0 rteth0 1000
I am working on this machine:
Wireshark captures
SOEM
When I request the OPERATIONAL state for the network, the EL1259 goes only in SAFE-OP, and it must be manually switched in OPERATIONAL. Here, there is the capture from wireshark.
I can easily provide more materials to debug the problem.
Any help would be really appreciated.
Thanks to all.
The text was updated successfully, but these errors were encountered: