JohnR Posted June 10, 2015 Share Posted June 10, 2015 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. Link to comment Share on other sites More sharing options...
Omron Forums Support Posted June 10, 2015 Share Posted June 10, 2015 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. Link to comment Share on other sites More sharing options...
Omron Forums Support Posted June 10, 2015 Share Posted June 10, 2015 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. Link to comment Share on other sites More sharing options...
JohnR Posted June 10, 2015 Author Share Posted June 10, 2015 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. Link to comment Share on other sites More sharing options...
Omron Forums Support Posted June 10, 2015 Share Posted June 10, 2015 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 fixWhy Is My Move Too Slow 2015-06.pdf Link to comment Share on other sites More sharing options...
JohnR Posted June 11, 2015 Author Share Posted June 11, 2015 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. Link to comment Share on other sites More sharing options...
curtwilson Posted June 12, 2015 Share Posted June 12, 2015 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. Link to comment Share on other sites More sharing options...
Recommended Posts