wilco7

Firstly, thank you for all the reply. And I want to add one more thing to make my situation clearer. I know there is a time delay of Actual Position feedback in CSP mode and thus FE is proportional to the speed, (70 FE per cycle @ F866 in my case) and it is not the point. The crux of my problem is why do some motors have 5 cycles of delay while others only have 4, and why those additional delay appears on random motors each time I reset EtherCAT. (the delay once appeared on a motor will remain constant until the network is reset) @leandro.martins Thank you for your reply, but I don't think this issue is related to the problem you've linked to. @DaveBarnett This is why I wrote that "I noticed a strange delay in the actual position ($6064, PDO) feedback" and not in the Following Error. But the reason I chose to show FE on the plot is just because it makes it much easier to identify the delay this way. I know why motors have huge FE which is proportional to speed in CSP mode. And while you explained why there are 4 cycles of delay in the first place, it doesn't answer the question of why some random motors, like in my case, have a delay of 5 cycles and not 4 like others. My problem is that when there is not much difference in configuration and all motors run at the same speed, the amount of the delay should be the same for all motors but which was not, and the fact that this strange extra delay appears on random motors each time the EtherCAT network is reset. @Sanjay_RSS Yes, I'm aware of this parameter, and I actually found this problem while trying to compensate for the "delay" with it. And yes, while this parameter has little to do with the problem we're discussing, it's still worth mentioning when we're talking about FE in CSP mode, I suppose

Hello, My current setup is five 1S servo motors connected to a CK3E running in CSP mode, and it's worked pretty well so far. However, I recently noticed that some motors have strange extra delay in the actual position ($6064, PDO) feedback. The reason I call this 'strange' is that whenever I reset the EtherCAT controller, this delay comes and goes on random motors without any indication (no status errors, etc.). My current system info is - CK3E, FW 2.7.0 - IDE 4.5.2.9 - 5 of 1S servo motor (R88D-1SN) - 2kHz servo/EtherCAT frequency with Master Shift mode Here are the gathering results. The plot was gathered by running all 5 motors FRAX with F1500 (Approx F866 for each motor) and the following error (about 290 mu) shows that EtherCAT feedback latency is approximately 2msec (thus 4 servo cycles @ 2kHz, approx 70 FE per cycle). And this can be considered as a normal state. However, as shown in the plot, motor 1 has 360 mu all alone, this translates to being one cycle behind from other motors (290mu). And this is what I call "strange extra delay". Moreover, if I reset EtherCAT network, random motors will have this "strange extra delay". (but once it appears, it will remain.) Below is the plot after resetting the EtherCAT network. Now motors 2,3,4 have this "strange extra delay". Here are some more results after resetting the EtherCAT network Sometimes no motor has this extra delay (all have only 4 cycles of delay) and this is what I expected. Lastly, simplified EtherCAT resetting procedure I took was as following. (I left this just for the records. The problem appears even when I turn the device off and on) > &1disable > disable plc 1..31 > ECAT[0].enable = 0 // wait for some moment > ecat reset // after "Sys.EcatMasterReady" set to 1 > ECAT[0].enable = 1 // wait for "ECAT[0].MasterState" become OP When I first saw this delay occurring on some motors, I thought it was caused by a misconfiguration. However, after some testing, I found that when I rebooted the device, random motors were having this delay. Any suggestions would be helpful, and thank you in advance.

So, you mean MoMo was right. Because the "two lines of programs at the same position" is actually meaning a 'zero distance move'. Thank you for confirmation. And it would be way better if this condition was written in the manual, since SegLinToPvt is automatic conversion and this means non-problematic move command in linear mode could become problematic move command 'automatically'

Thanks for the info MoMo Yes, I already know the code line number where the error occurred, and I have added a comment on that line above. Do you mean the duplicated code blocks like a bunch of "G0 Y-4.358 X35.464 Z65.0" starting from the 14th line in the snippet above? If it is, It might be the case since the line number -at the end of duplicated move codes- where the error occurred was exactly the same every time, but actually I can't confirm the actual conversion error was occurred right there since I don't even know whether Look-Ahead feature is got involved or not on SegLinToPvt conversion because of lack of the documentation about that feature. Nevertheless, I think It could be a good clue on finding differences between working and not working codes.

My machine setup is a CNC Milling machine with CK3E Motion controller and the machine will mainly run with CAM generated NC codes with high-block rate. I'm currently testing several features that the controller provides for more accurate machined results, and I faced a somewhat mysterious error code "Coord[x].LinToPvtError" while I'm testing "SegLinToPvt" mode. I've searched through manuals and forums but there was not so much about this error except just simple information like "Error in automatic linear-to-PVT-mode conversion". To be more precise, I've successfully milled several models with the feature turned on without any problem, but one specific NC code started causing this problem and motion always halts at the very same code line, but I can't find any problematic moves from there. Can anyone tell me what situation can cause this kind of error? I want to know specific rules and conditions that this kind of error can occur if it's available, or if the error could be popping up somewhat randomly, I should turn it off permanently and forget about this feature, since my customers cannot reach to this kind of motion parameters, the machine should work well per se. My current settings below, and please let me know if more information is needed. - FW version: 2.7.0.0 - servo frequency = 2KHz - coord[x].segmovetime = 1 - coord[x].lhdistance = 1024 - lookahead buffer 10240 - coord[x].seglintopvt = 1 - coord[x].pvateanble = 1 and 0 (both not works) - Compensation tables and trajectory pre-filters are in use Code snippet from problematic NC codes below (comments at the line where the error occurs) """ G0 Z43.1 G0 Z53.1 G53 G0 G90 Z0 G54 G0 G90 A0 B0 G43 H1 Z65 F1200 G0 Z65.0 G0 Y10.0 G0 X-55.0 G0 B0.0 A0.000 G0 Y0.0 X0.0 G0 B-15.56 A-16.143 G0 Y-4.358 X35.464 G0 Y-4.358 X35.464 Z65.0 G0 Y-4.358 X35.464 Z65.0 G0 Y-4.358 X35.464 Z65.0 G0 Y-4.358 X35.464 Z65.0 G0 Y-3.961 X35.862 Z65.0 G0 Y-2.072 X37.754 Z58.473 G0 Y-2.072 X37.754 Z58.473 G0 Y-2.072 X37.754 Z14.609 G1 Y-2.072 X37.754 Z14.609 ;;Coord[x].LinToPvtError = 1 Y-2.26 X37.602 Z14.609 Y-2.227 X37.562 Z14.597 Y-2.184 X37.534 Z14.584 Y-2.136 X37.515 Z14.572 Y-2.085 X37.507 Z14.559 Y-2.033 X37.51 Z14.547 Y-1.983 X37.524 Z14.534 Y-1.937 X37.547 Z14.522 Y-1.896 X37.579 Z14.509 Y-1.896 X37.579 Z14.509 Y-1.864 X37.619 Z14.509 Y-1.841 X37.666 Z14.509 Y-1.827 X37.716 Z14.509 Y-1.826 X37.767 Z14.509 Y-1.834 X37.818 Z14.509 Y-1.852 X37.866 Z14.509 Y-1.88 X37.91 Z14.509 Y-1.917 X37.946 Z14.509 Y-1.96 X37.974 Z14.509 Y-2.008 X37.992 Z14.509 Y-2.059 X38.0 Z14.509 Y-2.11 X37.997 Z14.509 Y-2.16 X37.985 Z14.509 Y-2.206 X37.961 Z14.509 Y-2.245 X37.928 Z14.509 Y-2.278 X37.888 Z14.509 Y-2.301 X37.842 Z14.509 Y-2.314 X37.792 Z14.509 Y-2.317 X37.741 Z14.509 Y-2.31 X37.69 Z14.509 Y-2.292 X37.642 Z14.509 Y-2.263 X37.599 Z14.509 Y-2.227 X37.562 Z14.509 ... """