Dear team,
This is the first time I write then let me congratulate for the forum and for all the support Dyno and users provides with this excelent toolªª
I am making a setup where I need to actualize the position of a motor continuislly. The motor can turn from -60 degres to + 60 degres and I continuislly need to tell him the new position, for example using .NET or with a C program actulizing a user varible.
The problem I have is that faster I send the new position command with "Move0" command slower the axis moves. For example, If I send to position 54 degrees (100000 steps) and then I execute a loop with a simple code that continuislly send "move" command to 0 the stage moves very very slow until the loop finish and then move fast to 0:
int num;
main()
{
// EnableAxis(0);
// Zero(0);
num=1;
ch0->Accel=100000;//80000 fast
ch0->Jerk=1000000;//
MoveAtVel(0,100000,100000);
for(num = 1; num < 10000; num =num +1)
{
MoveAtVel(0,0,100000);
}
}
If I add "wait" commands inside the for bucle to send with lower frequency the target position, the stage goes faster and faster, meaning that telling continuislly the target position create a huge delays, making the stage very slow response.
My problem is that at least I need to tell the stage 10 to 20 times per second a new position (similar to a fast joystick) then the new target position should change "on the fly" the previus target postion, recalculating the steps to make "on the fly". I believe this is very common but I don´t find any command that let me do that, can anyone help me???
Many thanks for your support
Big delay positioning for Move commands
Moderators: TomKerekes, dynomotion
- TomKerekes
- Posts: 2677
- Joined: Mon Dec 04, 2017 1:49 am
Re: Big delay positioning for Move commands
Hi gonzalo,
That is correct, there is a problem if KFLOP is commanded new Move/Jog commands continuously. Calculating a new 3rd-order blended trajectory takes some time to calculate. KFLOP holds the current motion state for several milliseconds to allow for the calculations to be performed. If KFLOP is constantly told to calculate new trajectories, the result is basically a continuous state of hold.
For a continuously changing target positions it usually works out well to use MoveExp. This will exponentially move toward a target position while honoring Acceleration and Velocity limits and has no such restriction. You might look at the MPG C Program Examples.
HTH
That is correct, there is a problem if KFLOP is commanded new Move/Jog commands continuously. Calculating a new 3rd-order blended trajectory takes some time to calculate. KFLOP holds the current motion state for several milliseconds to allow for the calculations to be performed. If KFLOP is constantly told to calculate new trajectories, the result is basically a continuous state of hold.
For a continuously changing target positions it usually works out well to use MoveExp. This will exponentially move toward a target position while honoring Acceleration and Velocity limits and has no such restriction. You might look at the MPG C Program Examples.
HTH
Regards,
Tom Kerekes
Dynomotion, Inc.
Tom Kerekes
Dynomotion, Inc.
Re: Big delay positioning for Move commands
Many thanks!! I will try it tomorrow. Great support.