Tieval

Hi Mustafa, I've checked Isx90 and have already checked that I116 is set high enough to allow target velocity to be reached. Thanks

Hi Steve, This does sound like our issue. However, by adjusting TA to achieve the target velocity, the acceleration and deceleration is too sharp. Is there any way around this? We have removed 2 points but would rather use 4 to achieve a smoother curve. Thanks

I had another go at adjusting TA and TS but the acceleration and deceleration at the beginning and end of the scan line ends up being too sharp. I’ve tried using the lookahead feature but it seems to have had a negligible effect (maybe I’m doing something wrong). As per the manual, I’ve done the following: 1. DEFINE COORDINATE SYSTEM #1->1633Z #2->327.6Y 2. CALCULATE POSITION LIMITS (not sure if these are needed but I calculated these values anyway) • I213 = 167076 • I214 = 95004 • I241 = 10 • I113 = -163300 • I114 = -195960 • I141 = 10 • Both I124 & I224 were set to $840401 (to set bit 15 to 1) 3. VELOCITY LIMITS • I116 = 82 • I216 = 350 4. ACCELERATION LIMITS • I117 = 2 • I217 = 3 5. SEGMENTATION TIME & LOOKAHEAD LENGTH • I5113 = 6 (1000/TA) • I5120 = 13 (I216/(2*I217*6)*1.33)) 6. DEFINE LOOKAHEAD • &1 DEFINE LOOKAHEAD 200,20 Is this a limitation of multipoint moves? We have managed to speed up scan lines by reducing the number of points passed to the PMAC. We don’t require precise motion during the scan line so we can reduce the number of waypoints. However, I would rather speed the scan lines up using the lookahead feature if possible?

Hi Richard, Thanks for getting back to me. I've increased Ixx16 and Ixx17 for both motors in the coordinate system however, these variables are not what's causing the system to slow down. I also attempted the following: OPEN PROG 1 CLEAR LINEAR ABS FRAX(Y) TA180 TS90 F800 DWELL0 P96=1 Y350 Y400 Y450 Y500 DWELL0 P97=1 CLOSE Despite removing the Z, the speed over the scan line remained slow. The only way I could increase the speed was by removing waypoints: OPEN PROG 1 CLEAR LINEAR ABS FRAX(Y) TA180 TS90 F800 DWELL0 P96=1 Y400 Y500 DWELL0 P97=1 CLOSE So it would seem that the more points in the line that need to be blended, the slower the axes will travel. Going back to my original post, I believe that the issue is caused by the fact that the PMAC treats each programmed move as the last in the sequence so it keeps the speed low so that it can come to a controlled stop. Does the lookahead feature allow the axes to reach maximum velocity during a blended move? I'm not sure that I used this feature correctly. Thanks again.

Hi all, The majority of our motion is simple and is carried out by moving 2 axes to a point and indexing the remaining axes. See below: OPEN PROG 1 CLEAR LINEAR ABS FRAX(Y,Z) TA180 TS90 F800 DWELL0 P96=1 Y500Z-114 DWELL0 P97=1 CLOSE However, we have a new requirement to synchronise motion between 2 axes through multiple points over a line. I believe the easiest way to do this is using a linear blended move in a motion program. Please see below for my current motion program: OPEN PROG 1 CLEAR LINEAR ABS FRAX(Y,Z) TA180 TS90 F800 DWELL0 P96=1 Y350Z-104.375 Y400Z-100 Y450Z-104.375 Y500Z-114 DWELL0 P97=1 CLOSE This does synchronise the motion of our Y and Z axes however, it slows the motion down to a fraction of the motors capabilities. Having read the linear blended move section of the manual, I believe that the issue is caused by the fact that the PMAC treats each programmed move as the last in the sequence so it keeps the speed low so that it can come to a controlled stop. I have had relative success in speeding this up by: 1) by reducing TA and TS so that it can accelerate and decelerate quicker however, this does make the motion a little jumpy. 2) by reducing the number of points in the motion program thus giving the motors more time to accelerate and decelerate. The only issue is that we have less control on Z positioning during the line. I have also attempted to use the lookahead feature but this seems to have a limited affect. Is there an alternative method of coordinating motion? We do not require great accuracy. Speed is a more important factor and if necessary we will just reduce the number of points in the line but if there is a better method, I would like to try and implement that before opting for the easy option! Many thanks Ben

Hi all, I'm using ABB drives so I am unable to use position compare. Instead, I'm using the following PLCC to generate a pulse output every 0.5mm: OPEN PLCC 0 CLEAR #define TRIGOUT L1 L1->Y:$78402,8 #define MOVE L2 L2->X:$130,17 #define YENC F1 F1->D:$10B #define ENA P81 #define INCREMENT P82 #define STARTENC P83 #define GRID P84 #define RATIO P85 #define TRIGPOS P86 #define TRIGNEG P87 #define TRIGCOUNT P88 #define PULS P89 #define LINESTART P90 #define LINEEND P91 While (ENA = 1) If (MOVE = 0) STARTENC = (LINESTART*RATIO)*3072 INCREMENT = (GRID*RATIO)*3072 TRIGPOS = STARTENC + INCREMENT TRIGNEG = STARTENC - INCREMENT PULS = (LINEEND-LINESTART)/GRID TRIGCOUNT = 0 Else If (YENC > TRIGPOS) Or(YENC < TRIGNEG) TRIGOUT=1 TRIGCOUNT = TRIGCOUNT + 1 TRIGOUT=0 TRIGPOS = TRIGPOS + INCREMENT TRIGNEG = TRIGNEG - INCREMENT EndIf EndIf EndWhile CLOSE This works great whilst the system is on. If I leave the system on, it is consistent. However, if the system is reset or the PMAC reset, the timing changes slightly. I have set I5 to 3 and I8 to 0. Am I doing something wrong? Thanks

Hi all, I'm using ABB drives so I am unable to use position compare. Instead, I'm using the following PLCC to generate a pulse output every 0.5mm: OPEN PLCC 0 CLEAR #define TRIGOUT L1 L1->Y:$78402,8 #define MOVE L2 L2->X:$130,17 #define YENC F1 F1->D:$10B #define ENA P81 #define INCREMENT P82 #define STARTENC P83 #define GRID P84 #define RATIO P85 #define TRIGPOS P86 #define TRIGNEG P87 #define TRIGCOUNT P88 #define PULS P89 #define LINESTART P90 #define LINEEND P91 While (ENA = 1) If (MOVE = 0) STARTENC = (LINESTART*RATIO)*3072 INCREMENT = (GRID*RATIO)*3072 TRIGPOS = STARTENC + INCREMENT TRIGNEG = STARTENC - INCREMENT PULS = (LINEEND-LINESTART)/GRID TRIGCOUNT = 0 Else If (YENC > TRIGPOS) Or(YENC < TRIGNEG) TRIGOUT=1 TRIGCOUNT = TRIGCOUNT + 1 TRIGOUT=0 TRIGPOS = TRIGPOS + INCREMENT TRIGNEG = TRIGNEG - INCREMENT EndIf EndIf EndWhile CLOSE This works great whilst the system is on. If I leave the system on, it is consistent. However, if the system is reset or the PMAC reset, the timing changes slightly. I have set I5 to 3 and I8 to 0. Am I doing something wrong? Thanks

Thanks for everyone's help. Have managed to get a PLCC 0 working as a trigger.

Sorry, I should also have mentioned that I am using ABB Drives. I fear this may make position compare impossible? Are there any other methods of generating a precise trigger based on the movement of the Y axis? Or, perhaps a method of improving the precision of our virtual motor?

Currently I'm using the Turbo PMAC2 Ethernet Ultralite, although we do also use the PCI card as well.

Hi Curt and Richard, Thanks for this. I'm currently trying to set up a position compare output as described in the Turbo PMAC user manual. I've checked I4902 and I4903 for the presence of DSPGATE2 IC. They are $3 and $1 respectively which I believe indicates the presence of 2 IC's, one of which is a DSPGATE2 IC. Do I68n1/I69n1 need to be set? Using "Position compare examples" and the "Using the Position-Compare Feature on Turbo PMAC" I have established that register: M108->Y:$078007,0,24,S ; Position compare A value (counts) M109->X:$078007,0,24,S ; Position compare B value (counts) However, my motion program is unable to change these from a set value of -1. I have also tried to alter these values manually in the M-Variables but they revert back to -1. I imagine I'm missing something very simple here. Many thanks

Hi all, Currently, we obtain a 5V trigger generated using a virtual axis which is synchronised with a moving axis in the same coordinate system. We're obtaining a trigger approximately every 0.5mm that the axis moves. The trouble is, it is not accurate enough and as speed settings are altered, there are issues with synchronisation. I assume that this is because, despite being in the same coordinate system, the PMAC still treats them independently. Does anyone have any suggestions as to how I could generate a pulse? Perhaps an output every given number of counts? Thanks