bmccarney Posted October 24, 2016 Share Posted October 24, 2016 I'm hoping for an explanation of how look ahead works in a Turbo PMAC2 (Brick Controller). We're controlling a rotator in either a 'Track' or 'Slew' mode with the code listed below. Segmentation is disabled and blending is on, so my impression is that Acceleration and Velocity I-variables would dictate the response regardless of the Ts value specified. For a Slew move, P250 is updated once with the destination and we have found that the rotator will accelerate at the I217 rate to the max speed of i216, but then essentially abort and decelerate at I215 once it gets to the final position. Why? If this is a look ahead interference, what is it looking ahead to when only one destination is provided? Oddly enough, by disabling blending we've been able to get the move profile for Slews correct however Tracking behavior suffers. Does that make sense? For Tracking moves, updated position information is provided at 2Hz which was then originally provided to the PMAC via P250 interpolated to 100Hz. We've found that over time the rotator seems to fall behind and our position error will grow. We've reproduced this issue on a benchtop setup, even when removing the interpolation and just providing the PMAC updates at 2Hz (InFreq is updated accordingly). We've experimented with specifying move times using Tm at 2Hz as well without success. What's odd is that the following error the PMAC reports makes it seem as though we're staying on target. Should it matter whether we set TM versus Ts? If a new position is arriving every 2Hz, should that dictate our TM/Ts settings? Our Tracking rates can vary pretty widely, from 10asec/sec up to 0.45deg/sec depending on elevation so we would like to have the smoothest response between updates (so in motion during the entire period as opposed to arriving at the destination and waiting). //////////////////////////////// &2 ; define coordinate system 2 #2->10922.667X ; cts/deg #define InFreq 100 ; Input Frequency [Hz] Open prog 2 Clear P253=1 ; indicate motion program running DWELL 0 ABS LIN TA 0 TS (1000/(2*InFreq)) TM 0 P252=0 WHILE (P251=0) WAIT WHILE (P251 > 0) ; do while we want to track P252=P252+1 X(P250) ; move to position specified by P250 EndW DWELL 0 P253=0 ; indicate motion program not running Close ////////////////////////////////////// Any assistance is appreciated, and please let me know if you need more information on the configuration. Don't assume I know what I'm talking about! Thanks, Ben Link to comment Share on other sites More sharing options...
bmccarney Posted October 25, 2016 Author Share Posted October 25, 2016 Maybe just to back up my question a bit, how does the PMAC handle look ahead given the while loop in the motion program? When look ahead is discussed in the manuals I have a hard time telling whether the reference is to actual moves (and associated calculations) or to executing lines within the motion program. Link to comment Share on other sites More sharing options...
steve.milici Posted October 26, 2016 Share Posted October 26, 2016 With segmentation off (Isx13=0) PMAC will limit velocity to Ixx16 and acceleration (when it can) to Ixx17 by virtue of looking ahead two moves. There are situations where Ixx17 cannot be observed as in a final move that is very small – PMAC MUST stop at the final point. I am concerned about the “abort” you see at the end of your move sequence. An “abort” is only caused by hitting a limit or the explicit abort command, not from normal program execution. Your final move should still be using Ixx17 unless it is in fact EXACTLY too small as to result in the Ixx15 rate. In the ongoing while loop the lookahead is evaluating P250 two moves ahead to blend the moves. It can be tricky to “synchronize” this with an outside source updating this variable. When you disable blending your while loop “synchronizes” better. Give me a call in support (818-717-5656) and I can help you find better results. Link to comment Share on other sites More sharing options...
Recommended Posts