Position Compare with ACC24E3

What is the lower limit for the auto increment when using the position compare feature on the ACC24E? When using the position compare feature according to the manual all registers are in units of 1/4096 of a quadrature count. Applying the same logic as with the Turbo PMAC the smallest permissible auto increment should be 4 (or 1/1028 of a quadrature count). However when trying use the compare feature with auto increments values less than 4096 (or 1 full quadrature count) the position compare output does not fire reliably. What is the reason for this and how to do you determine the smallest permissible auto increment for a given application? This is the PLC code used to initialize the position compare logic: open plc 18 local tmp; tmp = Gate3[0].Chan[0].ServoCapt; Gate3[0].Chan[0].CompAdd = 4096; Gate3[0].Chan[0].CompA = tmp + Gate3[0].Chan[0].CompAdd*0.25 Gate3[0].Chan[0].CompB = tmp - Gate3[0].Chan[0].CompAdd*0.25 disable plc 18 close Thank you, Felix

[quote='Felix' pid='211' dateline='1254328995'] What is the lower limit for the auto increment when using the position compare feature on the ACC24E? When using the position compare feature according to the manual all registers are in units of 1/4096 of a quadrature count. Applying the same logic as with the Turbo PMAC the smallest permissible auto increment should be 4 (or 1/1028 of a quadrature count). However when trying use the compare feature with auto increments values less than 4096 (or 1 full quadrature count) the position compare output does not fire reliably. What is the reason for this and how to do you determine the smallest permissible auto increment for a given application? This is the PLC code used to initialize the position compare logic: open plc 18 local tmp; tmp = Gate3[0].Chan[0].ServoCapt; Gate3[0].Chan[0].CompAdd = 4096; Gate3[0].Chan[0].CompA = tmp + Gate3[0].Chan[0].CompAdd*0.25 Gate3[0].Chan[0].CompB = tmp - Gate3[0].Chan[0].CompAdd*0.25 disable plc 18 close Thank you, Felix [/quote] A few points: 1. Even when you are using arctanenable the compare is based on timers. It is not practical to sample the A to D for every subcount. 2. Because this is based on timers a reversal without a quadrature edge will cause a problem. The vast majority of people who will use this will only be going one direction but if the CompAdd is less than or equal to 2 cts a reversal might cause a problem. 3. The system is designed so that you can compare at a subcount accuracy. What I mean is that you can auto increment 10.3 counts but if you want subcount intervals (increment 0.3 counts) things will get tricky because of point 2 above. Remember that encoder dither is also a reversal and when the increment gets small you must also consider the stablity of the encoder signal. To test your system do the following. 1. Setup the CompA and CompB ahead of your motor. Give enough distance that the motor will be at constant speed when you jog that direction. 2. Because you are not bracketed you must write to the initial state Gate3[0].Chan[2].EquWrite 3. Now Jog the motor and see that the auto increment starts working. On my system, moving the motor by hand, I can get my increment to 512. Let me know what you can get.

[quote] A few points: 1. Even when you are using arctanenable the compare is based on timers. It is not practical to sample the A to D for every subcount. [/quote] 1) I understand that the encoder sampling frequency is determined by setting Gate[3].EncClockDiv which is set to zero in our case to give us an encoder sampling frequency of 100Mhz. With the encoder sampling at this high of a frequency and a axis that is moving sufficiently slow we should be able to sample the encoder signals fast enough to allow for auto increments less than 4096... [quote] 2. Because this is based on timers a reversal without a quadrature edge will cause a problem. The vast majority of people who will use this will only be going one direction but if the CompAdd is less than or equal to 2 cts a reversal might cause a problem. [/quote] 2) I am not sure I am following you here since we are using a sin/cos encoder and therefore have no quadrature counts. When we are using the position compare feature with auto increment we are moving in one direction only (as a matter of fact for testing we simply jog the axis) so there should be no problems with regards to reversal of direction. Furthermore from what I understand of the way the position compare functions we are fundamentally dealing with a simple comparison of the actual position to the CompA and CompB values. Assuming that the encoder is sampled once per encoder clock cycle and therefore the arctan calculation is also executed once per encoder clock cycle there should be no reason for the position not to function with auto increment values much smaller than 4096 if the axis does not move further than the auto increment in one encoder clock cycle. If the A/D converter can not function at this high of a frequency then what is a realistic limit? [quote] 3. The system is designed so that you can compare at a subcount accuracy. What I mean is that you can auto increment 10.3 counts but if you want subcount intervals (increment 0.3 counts) things will get tricky because of point 2 above. Remember that encoder dither is also a reversal and when the increment gets small you must also consider the stablity of the encoder signal. [/quote] 3) I am getting a little bit confused here by your terminology. Do you consider a count an encoder zero crossing (we are dealing with a sin/cos encoder) or are you talking about intervals smaller than 1/4096 quadrature count? Dither should not really matter for the position compare feature as long as the dither frequency and magnitude are such that the encoder sampling can keep track of the dither. [quote] To test your system do the following. 1. Setup the CompA and CompB ahead of your motor. Give enough distance that the motor will be at constant speed when you jog that direction. 2. Because you are not bracketed you must write to the initial state Gate3[0].Chan[2].EquWrite 3. Now Jog the motor and see that the auto increment starts working. On my system, moving the motor by hand, I can get my increment to 512. Let me know what you can get. [/quote] Using your setup, the smallest increment I have observed working was 2048. However it only worked for a few seconds before the position compare output stopped. Furthermore if I increase the speed of our axis the smallest increment I can get to work is 4*4096 which amounts to triggering once per quadrature count/zero crossing of the sin/cos encoder. For smaller increments at high speeds the position compare is not consistent. The position compare either stops all together or the pulses become distorted meaning that the duty cylce and frequency changes. It appears that for these smaller increment the position compare feature can not keep up. Here are some numbers for you to consider. The encoder we are using has 23600 lines per revolution and for high speed testing we are turning the motor at 2400rpm. For an auto increment of 4*4096 this leads to a frequency of about 3.8MHz out of the position compare output. In other words, we are no where near the advertised limit of 100MHz for the position compare output. Comments and thoughts? Thank you, Felix