Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Coordinated Move
#1
What is the best method for determining the limiting parameter(s) in a coordinated move using lookahead and multiple axes. My coordinate system has 14 motors. The system consists of (2) 5 axis gantries within the single coordinate system. When a move is commanded the system does not move at the MaxFeedRate for the FRAX axes nor the AltFeedRate for the other axes.
Reply
#2
Make sure you have set Motor[x].InvAMax, Motor[x].InvJMax and Motor[x].MaxSpeed for each motor involved such that you can achieve the speeds/accelerations you desire.
Reply
#3
Parameters which can affect your speed while in lookahead: motor[x].InvAMax, motor[x].MaxSpeed, Coord[x].SegMoveTime, Coord[x].MaxFeedRate, Coord[x].Ta, Coord[x].Ts, Coord[x].Td (if larger than Ts). Also potentially lookahead size and Coord[x].LHDistance if set too small.
Reply
#4
(06-10-2015, 09:18 AM)CharlesP Wrote: Make sure you have set Motor[x].InvAMax, Motor[x].InvJMax and Motor[x].MaxSpeed for each motor involved such that you can achieve the speeds/accelerations you desire.

Thanks Charles, Vince.

I do check these values. However with the number of motors that are in the coordinate system this can become cumbersome when each axis has different limitations and user units. there is also to problem of having only a sing FRAX command for use with two gantries. I was looking for some way to determine "real time" which axis/motor/CS parameter was limiting the vector move.
Reply
#5
Hi,

Curt wanted me to post the attached app note. It should be helpful.

Something else to note is that if you have more than 3 axes in your FRAX command (e.g. you used FRAX(x, y, z, xx, yy, zz)), the "F" no longer makes sense since it's based off of a square root of the sum of squares. If you have 6 dimensions in that sum, it's no longer representing a physical 3 dimensions.

EDIT: Updated document with typo fix


Attached Files
.pdf   Why Is My Move Too Slow 2015-06.pdf (Size: 187.6 KB / Downloads: 50)
Reply
#6
(06-10-2015, 10:48 AM)CharlesP Wrote: Hi,

Curt wanted me to post the attached app note. It should be helpful.

Something else to note is that if you have more than 3 axes in your FRAX command (e.g. you used FRAX(x, y, z, xx, yy, zz)), the "F" no longer makes sense since it's based off of a square root of the sum of squares. If you have 6 dimensions in that sum, it's no longer representing a physical 3 dimensions.

EDIT: Updated document with typo fix

Thanks Charles, The app note is helpful. I understand the limitation of the single FRAX function. Would it be possible to implement an additional FRAX function (e.g. FRAX(x,y,z) FRAX2(XX,YY,ZZ)) and use the longest move time for the move so that the 3 space vector move calculation would be correct on each gantry.
Reply
#7
We will evaluate this request, but it is not something that can be done immediately. It would add computation time to all F-based moves, even if just to check whether it is used or not, so we have to be very careful.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)