Jump to content
OMRON Forums

Help with look ahead


bmccarney
 Share

Recommended Posts

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

  • Replies 2
  • Created
  • Last Reply

Top Posters In This Topic

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

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

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...