Position vs Velocity mode
07 Jul 2024 11:38 #304575
by Donb9261
Replied by Donb9261 on topic Position vs Velocity mode
Page 6-39 of the ASDL-A3 drive manual shows support for an Inc. scale interface input for CL mode internal to the drive on CN5 pins 1-9.
Please Log in or Create an account to join the conversation.
07 Jul 2024 19:00 - 07 Jul 2024 19:44 #304592
by endian
Replied by endian on topic Position vs Velocity mode
I have doing some experiments today and it is possible to run ethercat sync below 1ms interuption.. I have tried 250us sync and it was fine... but I do not know how it will be outside of bench top ...my prehistoric servo drivers has limit at 250us ... I did not test them with sync motion just communication setup and I have generic ec driver only...
It should be great to test them then anyway..
It should be great to test them then anyway..
Last edit: 07 Jul 2024 19:44 by endian.
The following user(s) said Thank You: COFHAL
Please Log in or Create an account to join the conversation.
- papagno-source
- Offline
- Senior Member
Less
More
- Posts: 67
- Thank you received: 2
08 Jul 2024 18:28 #304685
by papagno-source
Replied by papagno-source on topic Position vs Velocity mode
I followed with interest the initial discussion on the machining precision, with respect to the response delay of the motor position, via PDO to the LNCNC. In reality the numerical controls, for example Siemens 840d, have 2 parameters for each axis, which are the coarse stop and the 'precise stop. The problem arises, for example, when you finish one movement and start the next. Siemens at least waits for the axis interested in making the first movement to return to the precise stop control window.
Only after returning to the precise positioning window will the next line be executed.
LNCNC does not have this parameter, so in reality the passage between one movement and another does not take into account the real position of the axis, unless it is in the following error window.
Therefore, a tracking error that is too high, or an excessive delay in the information via ethercat, will lead to a premature transition to the next line of gcode and therefore a profile that is not perfectly equal to the programmed one, especially when you go faster.
Only after returning to the precise positioning window will the next line be executed.
LNCNC does not have this parameter, so in reality the passage between one movement and another does not take into account the real position of the axis, unless it is in the following error window.
Therefore, a tracking error that is too high, or an excessive delay in the information via ethercat, will lead to a premature transition to the next line of gcode and therefore a profile that is not perfectly equal to the programmed one, especially when you go faster.
Please Log in or Create an account to join the conversation.
Time to create page: 0.107 seconds